О технологии
Caché Database Mirroring появилась в продуктах InterSystems Caché и Ensemble в 2010 году.
Технология позволяет снабдить информационные системы(ИС), построенные на Caché и Ensemble, опцией FAILOVER — возможностью преодоления некоторых неисправных состояний СУБД, операционной системы или аппаратного обеспечения.
Для чего информационной системе необходим failover — вопрос давно изученный, но в двух словах failover позволяет минимизировать время простоя пользователей в случае неисправностей, приводящих к отказу обслуживания сервера с информационной системой.
InterSystems Database Mirroring бывает синхронный и асинхронный. Синхронный позволяет создавать failover-решения из систем Caché и Ensemble. Асинхронный решает задачу построения катастрофо-устойчивых решений, с помощью резервного копирования данных на территориально разнесенные серверы.
Подробности о характеристиках решения InterSystems Database Mirroring можно почитать в этом документе. Настоящая статья посвящена настройке синхронного мирроринга “с нуля”, воспроизведению сценариев отказов и “советам бывалых” по эксплуатации систем с Mirroring.
Синхронный Mirroring. Как это работает?
Для использования синхронного зеркалирования (Mirroring) необходимо создать Failover-узел — связку из двух отдельных серверов Caché. Один из серверов является Primary и с ним работают пользователи информационной системы. Второй — Backup-сервер, который имеет актуальную копию данных Primary-сервера и ждет выхода его из строя, готовый стать Primary-сервером и продолжить обслуживать пользователей ИС.
Чтобы серверы, участники Failover-узла всегда знали о состоянии друг-друга, используется служба ISC Agent, которая постоянно работает на каждом из серверов Failover-узла.
Для Failover-узла назначается виртуальный IP (VIP), с которым и работают клиенты информационной системы: ECP-клиенты, серверы приложений, JDBC/ODBC подключенния, терминалы и проч.
При штатной работе Failover-узла клиенты работают через 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, выполняем тот же список плановых работ.
Создание зеркала с “нуля”
Конфигурация
Failover-узел — это две машины с 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-сервер в “дауне”.
Режим подтверждения (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. Убедимся, что приложение работает.
Итого
Теперь все готово, можно разрушать тестировать сервер, чтобы проверить функциональность failover-узла. Но об этом в следующей части. Продожение следует…
Автор: intersystems
