О технологии
Caché Database Mirroring появилась в продуктах InterSystems Caché и Ensemble в 2010 году.
Технология позволяет снабдить информационные системы(ИС), построенные на Caché и Ensemble, опцией FAILOVER — возможностью преодоления некоторых неисправных состояний СУБД, операционной системы или аппаратного обеспечения.
Для чего информационной системе необходим failover — вопрос давно изученный, но в двух словах failover позволяет минимизировать время простоя пользователей в случае неисправностей, приводящих к отказу обслуживания сервера с информационной системой.
InterSystems Database Mirroring бывает синхронный и асинхронный. Синхронный позволяет создавать highr availability решения для систем Caché и Ensemble. Асинхронный решает задачу построения катастрофо-устойчивых решений, с помощью резервного копирования данных на территориально разнесенные серверы.
Подробности о характеристиках решения InterSystems Database Mirroring можно почитать в этом документе. Настоящая статья посвящена настройке синхронного зеркала “с нуля”, воспроизведению сценариев отказов и “советам бывалых” по эксплуатации систем с Mirroring.
Синхронный Mirroring. Как это работает?
Для использования синхронного зеркала (Mirroring) необходимо создать связку из двух отдельных серверов Caché. Один из серверов является Primary, и с ним работают пользователи информационной системы. Второй — Backup-сервер, который имеет актуальную копию данных Primary-сервера и ждет выхода его из строя, готовый стать Primary-сервером и продолжить обслуживать пользователей ИС.
Чтобы серверы, участники зеркала всегда знали о состоянии друг-друга, используется служба ISC Agent, которая постоянно работает на каждом из серверов.
Для зеркала удобно назначить виртуальный IP (VIP), с которым и работают клиенты информационной системы: ECP-клиенты, серверы приложений, JDBC/ODBC подключенния, терминалы и проч.
При штатной работе зеркала клиенты работают через VIP с Primary-сервером, изменения на Primary собираются в журнал, который он-лайн воспроизводится Backup-сервером.
Отработка Failover-ситуации
Рассмотрим сценарий преодоления отказа (failover).
1. Primary-сервер останавливается по причине сбоя или по плану.
2. Backup-сервер посредством ISC Agent “понимает”, что Primary-сервер уже не работает.
3. Backup-сервер становится Primary.
4. Клиенты ИС и ECP подключаются по тому же VIP уже новому Primary-серверу с минимальной задержкой.
5. Бывший Primary-сервер переводится в состояние Backup-сервер.
Синхронный Mirroring. Польза?
Синхронный Mirroring позволяет устранить или уменьшить простои информационной системы при отказах.
Кроме того, это решение позволит администраторам выполнять плановые работы по обслуживанию информационной системы без перерыва в работе пользователей. Все плановые работы можно выполнять на Backup-сервере, пока Primary обслуживает клиентов. Примеры работ:
- обновление ОС,
- обновление Caché/Ensemble,
- выполнение backup-процедур,
- починка/апгрейд железа.
После этого Backup-сервер делаем primary, а для бывшего primary, ставшего новым backup, выполняем тот же список плановых работ.
Создание зеркала с “нуля”
Конфигурация
Зеркало — это две машины с Caché/Ensemble. В нашем случае создано две виртуальные машины Failover1 и Failover2 c Windows 8 и Caché 2012.2.RC на борту.
Для создания зеркала серверы также должны иметь опцию Multi-сервер в параметрах лицензии.
Включение ISC Agent
![image](https://habrastorage.org/getpro/habr/post_images/577/b6e/123/577b6e123dc71a0bbfedb08c2b3ad9ff.jpg)
В первую очередь на обоих серверах необходимо включить службу ISC Agent. Служба должна работать в режиме “авто”, а также иметь опцию автоматического перезапуска. На Windows-машине служба ISC Agent настраивается в Администрирование/Службы. В Linux для старта/останова исполняем скрипт
/etc/init.d/ISCAgent start // для старта
/etc/init.d/ISCAgent stop // для останова
Настройка Primary-сервера
![image](https://habrastorage.org/getpro/habr/post_images/784/3f0/d5a/7843f0d5ad27be8634e6ff9d542a3549.jpg)
На машине Failover1 заходим в Портал управления Caché/Ensemble в раздел Администрирование/Конфигурация/Настройки Зеркала, выбираем Создать зеркало.
![image](https://habrastorage.org/getpro/habr/post_images/9c3/311/726/9c33117266a3f9706fe0cb856e46d74f.jpg)
Для зеркала определяем имя, виртуальный IP(VIP) адрес. Связь между серверами рекомендуется организовывать через SSL/TLS соединение, т.к. через него будут передаваться данные информационной системы в незашифрованном виде. Если в подсети серверов адреса раздаются по DHCP, исключаем VIP из раздаваемых адресов.
Задаем имя Primary-сервера в формате Имя/название конфигурации Caché (здесь FAILOVER1/CACHE) и порт для агента (по умолчанию 2188).
Дополнительные настройки
Таймаут качества обслуживания (QoS timeout) — таймаут, после которого Primary-сервер считает, что Backup-сервер в “дауне”, а Backup-сервер начинает выяснять, действительно ли Primary-сервер не работает.
Режим подтверждения (Acknowledgement mode) — received/commited. Влияет на логику синхронизации журнала данных: сразу писать, как только получили данные, или учитывать транзакции. received(сразу писать) — по умолчанию.
Контакты Агента обязательны для отказоустойчивой конфигурации (Agent Contact Required for Failover) — да/нет. Параметр, который определяет, требуется ли наличие функционирующего ISC Agent для операции автоматического FAILOVER. Далее мы отдельно обговорим сценарии при различных значениях этого важного параметра. По умолчанию равен “да”.
Настройка Backup-сервера
![image](https://habrastorage.org/getpro/habr/post_images/67b/8f5/a81/67b8f5a81caa2974d5fa02e1350e972c.jpg)
Переходим на виртуальную машину Failover2, запускаем панель управления/Администрирование — выбираем пункт “Подключиться как Failover”.
![image](https://habrastorage.org/getpro/habr/post_images/695/181/5f5/6951815f5f38c8a6b77d2112bf765363.jpg)
Указываем Primary-сервер, порт ISC Agent и название конфигурации Cache на Primary-сервере. Соединяем серверы.
![image](https://habrastorage.org/getpro/habr/post_images/0e1/0eb/b6b/0e10ebb6b6b3ddfb81528ce10e7677e0.jpg)
После этого идем снова на первый сервер, и добавляем Backup-сервер в настройки зеркала.
![image](https://habrastorage.org/getpro/habr/post_images/91f/72f/807/91f72f8076ab521ec5f013a16d68acb5.jpg)
Соединим — и проверим, что зеркало работает. Статус зеркала можно посмотреть во вкладке Системная операция/Монитор Зеркала.
Включение базы данных в зеркало
![image](https://habrastorage.org/getpro/habr/post_images/116/6ee/e88/1166eee881d23279977a8fdeee752086.jpg)
Следующий этап настройки — включение базы данных, с которой работает информационная система, в зеркало. Это то, ради чего собственно служит зеркало — для синхронизации баз данных между двумя серверами. У нас в системе Caché создана база данных ASU, которую мы и будем зеркалировать. Вы можете выбрать любую локальную базу данных, например предустановленную БД USER или тоже создать БД с именем ASU.
Вносим базу данных в зеркало на Primary-сервере.
![image](https://habrastorage.org/getpro/habr/post_images/efe/e29/ccb/efee29ccb7f9813435b1cd977d850bf5.jpg)
Далее выполняем полный бэкап базы. На Backup-сервере восстанавливаем данные из терминала в области %SYS с помощью программы ^BACKUP или любой другой утилиты восстановления БД.
![image](https://habrastorage.org/getpro/habr/post_images/7db/477/ee4/7db477ee4c18b431eb7836607013f1cf.jpg)
![image](https://habrastorage.org/getpro/habr/post_images/bd9/9a4/e88/bd99a4e88770169ca4eec68cc9d84ff5.jpg)
При этом база данных будет сразу же включена в зеркало на Backup-сервере, т.к. информация о принадлежности зеркалу уже содержится в бэкапе.
После восстановления бэкапа, базу данных необходимо активизировать (Activate) и привести в актуальное состояние с primary-сервером (catch-up). Заходим в Монитор зеркала Backup-сервера и выполняем для базы Activate и Catch-up.
![image](https://habrastorage.org/getpro/habr/post_images/0ab/aa2/3cd/0abaa23cd5cb55991e3765fb2919c90b.jpg)
База данных включена в зеркалирование и готова к работе — это можно видеть на мониторе зеркала.
![image](https://habrastorage.org/getpro/habr/post_images/e68/d29/37a/e68d2937a42c5dbc6d4ac1783e6c20aa.jpg)
Подключимся по виртуальному IP-адресу зеркала к веб-приложению, которое установлено в базе ASU. Убедимся, что приложение работает.
Итого
Теперь все готово, можно