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

О технологии

Cache Database Mirroring появилась в продуктах InterSystems Cache и Ensemble в 2010 году.
Технология позволяет снабдить информационные системы(ИС), построенные на Cache и Ensemble, опцией FAILOVER – возможностью преодоления некоторых неисправных состояний СУБД, операционной системы или аппаратного обеспечения.
Для чего информационной системе необходим failover – вопрос давно изученный, но в двух словах failover позволяет минимизировать время простоя пользователей в случае неисправностей, приводящих к отказу обслуживания сервера с информационной системой.

InterSystems Database Mirroring бывает синхронный и асинхронный. Синхронный позволяет создавать highr availability решения для систем Cache и Ensemble. Асинхронный решает задачу построения катастрофо-устойчивых решений, с помощью резервного копирования данных на территориально разнесенные серверы.
Подробности о характеристиках решения InterSystems Database Mirroring можно почитать в этом документе. Настоящая статья посвящена настройке синхронного зеркала “с нуля”, воспроизведению сценариев отказов и “советам бывалых” по эксплуатации систем с Mirroring.

Синхронный Mirroring. Как это работает?

Для использования синхронного зеркала (Mirroring) необходимо создать связку из двух отдельных серверов Cache. Один из серверов является 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 обслуживает клиентов. Примеры работ:

  • обновление ОС,
  • обновление Cache/Ensemble,
  • выполнение backup-процедур,
  • починка/апгрейд железа.

После этого Backup-сервер делаем primary, а для бывшего primary, ставшего новым backup, выполняем тот же список плановых работ.

Создание зеркала с “нуля”

Конфигурация

Зеркало – это две машины с Cache/Ensemble. В нашем случае создано две виртуальные машины Failover1 и Failover2 c Windows 8 и Cache 2012.2.RC на борту.
Для создания зеркала серверы также должны иметь опцию Multi-сервер в параметрах лицензии.

Включение ISC Agent

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

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

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

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

image
На машине Failover1 заходим в Портал управления Cache/Ensemble в раздел Администрирование/Конфигурация/Настройки Зеркала, выбираем Создать зеркало.
image
Для зеркала определяем имя, виртуальный IP(VIP) адрес. Связь между серверами рекомендуется организовывать через SSL/TLS соединение, т.к. через него будут передаваться данные информационной системы в незашифрованном виде. Если в подсети серверов адреса раздаются по DHCP, исключаем VIP из раздаваемых адресов.
Задаем имя Primary-сервера в формате Имя/название конфигурации Cache (здесь FAILOVER1/CACHE) и порт для агента (по умолчанию 2188).

Дополнительные настройки

Таймаут качества обслуживания (QoS timeout) – таймаут, после которого Primary-сервер считает, что Backup-сервер в “дауне”, а Backup-сервер начинает выяснять, действительно ли Primary-сервер не работает.
Режим подтверждения (Acknowledgement mode) – received/commited. Влияет на логику синхронизации журнала данных: сразу писать, как только получили данные, или учитывать транзакции. received(сразу писать) – по умолчанию.
Контакты Агента обязательны для отказоустойчивой конфигурации (Agent Contact Required for Failover) – да/нет. Параметр, который определяет, требуется ли наличие функционирующего ISC Agent для операции автоматического FAILOVER. Далее мы отдельно обговорим сценарии при различных значениях этого важного параметра. По умолчанию равен “да”.

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

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

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

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

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

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

image
Следующий этап настройки – включение базы данных, с которой работает информационная система, в зеркало. Это то, ради чего собственно служит зеркало – для синхронизации баз данных между двумя серверами. У нас в системе Cache создана база данных ASU, которую мы и будем зеркалировать. Вы можете выбрать любую локальную базу данных, например предустановленную БД USER или тоже создать БД с именем ASU.
Вносим базу данных в зеркало на Primary-сервере.
image
Далее выполняем полный бэкап базы. На Backup-сервере восстанавливаем данные из терминала в области %SYS с помощью программы ^BACKUP или любой другой утилиты восстановления БД.
image

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

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

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

Итого

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *