О технологии

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

В первую очередь на обоих серверах необходимо включить службу ISC Agent. Служба должна работать в режиме “авто”, а также иметь опцию автоматического перезапуска. На Windows-машине служба ISC Agent настраивается в Администрирование/Службы. В Linux для старта/останова исполняем скрипт

/etc/init.d/ISCAgent start    // для старта

/etc/init.d/ISCAgent stop    // для останова

Настройка Primary-сервера

На машине Failover1 заходим в Портал управления Caché/Ensemble в раздел Администрирование/Конфигурация/Настройки Зеркала, выбираем Создать зеркало.

Для зеркала определяем имя, виртуальный 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-сервера

Переходим на виртуальную машину Failover2, запускаем панель управления/Администрирование — выбираем пункт “Подключиться как Failover”.

Указываем Primary-сервер, порт ISC Agent и название конфигурации Cache на Primary-сервере. Соединяем серверы.

После этого идем снова на первый сервер, и добавляем Backup-сервер в настройки зеркала.

Соединим — и проверим, что зеркало работает. Статус зеркала можно посмотреть во вкладке Системная операция/Монитор Зеркала.

Включение базы данных в зеркало

Следующий этап настройки — включение базы данных, с которой работает информационная система, в зеркало. Это то, ради чего собственно служит зеркало — для синхронизации баз данных между двумя серверами. У нас в системе Caché создана база данных ASU, которую мы и будем зеркалировать. Вы можете выбрать любую локальную базу данных, например предустановленную БД USER или тоже создать БД с именем ASU.
Вносим базу данных в зеркало на Primary-сервере.

Далее выполняем полный бэкап базы. На Backup-сервере восстанавливаем данные из терминала в области %SYS с помощью программы ^BACKUP или любой другой утилиты восстановления БД.

При этом база данных будет сразу же включена в зеркало на Backup-сервере, т.к. информация о принадлежности зеркалу уже содержится в бэкапе.
После восстановления бэкапа, базу данных необходимо активизировать (Activate) и привести в актуальное состояние с primary-сервером (catch-up). Заходим в Монитор зеркала Backup-сервера и выполняем для базы Activate и Catch-up.

База данных включена в зеркалирование и готова к работе — это можно видеть на мониторе зеркала.

Подключимся по виртуальному IP-адресу зеркала к веб-приложению, которое установлено в базе ASU. Убедимся, что приложение работает.

Итого

Теперь все готово, можно ~~разрушать~~ тестировать сервер, чтобы проверить функциональность зеркала. Но об этом в следующей части. Продожение следует…

InterSystems Database Mirroring. Создание и тестирование зеркала. Часть 1