- PVSM.RU - https://www.pvsm.ru -
Caché Database Mirroring появилась в продуктах InterSystems Caché и Ensemble в 2010 году.
Технология позволяет снабдить информационные системы(ИС), построенные на Caché и Ensemble, опцией FAILOVER — возможностью преодоления некоторых неисправных состояний СУБД, операционной системы или аппаратного обеспечения.
Для чего информационной системе необходим failover — вопрос давно изученный [1], но в двух словах failover позволяет минимизировать время простоя пользователей в случае неисправностей, приводящих к отказу обслуживания сервера с информационной системой.
InterSystems Database Mirroring бывает синхронный и асинхронный. Синхронный позволяет создавать failover-решения из систем Caché и Ensemble. Асинхронный решает задачу построения катастрофо-устойчивых решений, с помощью резервного копирования данных на территориально разнесенные серверы.
Подробности о характеристиках решения InterSystems Database Mirroring можно почитать в этом документе [2]. Настоящая статья посвящена настройке синхронного мирроринга “с нуля”, воспроизведению сценариев отказов и “советам бывалых” по эксплуатации систем с Mirroring.
Для использования синхронного зеркалирования (Mirroring) необходимо создать Failover-узел — связку из двух отдельных серверов Caché. Один из серверов является Primary и с ним работают пользователи информационной системы. Второй — Backup-сервер, который имеет актуальную копию данных Primary-сервера и ждет выхода его из строя, готовый стать Primary-сервером и продолжить обслуживать пользователей ИС.
Чтобы серверы, участники Failover-узла всегда знали о состоянии друг-друга, используется служба ISC Agent, которая постоянно работает на каждом из серверов Failover-узла.
Для Failover-узла назначается виртуальный IP (VIP), с которым и работают клиенты информационной системы: ECP-клиенты, серверы приложений, JDBC/ODBC подключенния, терминалы и проч.
При штатной работе Failover-узла клиенты работают через VIP с Primary-сервером, изменения на Primary собираются в журнал, который он-лайн воспроизводится Backup-сервером.
Рассмотрим сценарий преодоления отказа (failover).
1. Primary-сервер останавливается по причине сбоя или по плану.
2. Backup-сервер посредством ISC Agent “понимает”, что Primary-сервер уже не работает.
3. Backup-сервер становится Primary.
4. Клиенты ИС и ECP подключаются по тому же VIP уже новому Primary-серверу с минимальной задержкой.
5. Бывший Primary-сервер переводится в состояние Backup-сервер.
Синхронный Mirroring позволяет устранить или уменьшить простои информационной системы при отказах.
Кроме того, это решение позволит администраторам выполнять плановые работы по обслуживанию информационной системы без перерыва в работе пользователей. Все плановые работы можно выполнять на Backup-сервере, пока Primary обслуживает клиентов. Примеры работ:
После этого Backup-сервер делаем primary, а для бывшего primary, ставшего новым backup, выполняем тот же список плановых работ.
Failover-узел — это две машины с Caché/Ensemble. В нашем случае создано две виртуальные машины Failover1 и Failover2 c Windows 8 и Caché 2012.2.RC на борту.
Для создания зеркала серверы также должны иметь опцию Multi-сервер в параметрах лицензии.
В первую очередь на обоих серверах необходимо включить службу ISC Agent. Служба должна работать в режиме “авто”, а также иметь опцию автоматического перезапуска. На Windows-машине служба ISC Agent настраивается в Администрирование/Службы. В Linux для старта/останова исполняем скрипт
/etc/init.d/ISCAgent start // для старта
/etc/init.d/ISCAgent stop // для останова
На машине 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. Далее мы отдельно обговорим сценарии при различных значениях этого важного параметра. По умолчанию равен “да”.
Переходим на виртуальную машину Failover2, запускаем панель управления/Администрирование — выбираем пункт “Подключиться как Failover”.
Указываем Primary-сервер, порт ISC Agent и название конфигурации Cache на Primary-сервере. Соединяем серверы.
После этого идем снова на первый сервер, и добавляем Backup-сервер в настройки зеркала.
Соединим — и проверим, что зеркало работает. Статус зеркала можно посмотреть во вкладке Системная операция/Монитор Зеркала.
Следующий этап настройки — включение базы данных, с которой работает информационная система, в зеркало. Это то, ради чего собственно служит зеркало — для синхронизации баз данных между двумя серверами. У нас в системе Caché создана база данных ASU, которую мы и будем зеркалировать. Вы можете выбрать любую локальную базу данных, например предустановленную БД USER или тоже создать БД с именем ASU.
Вносим базу данных в зеркало на Primary-сервере.
Далее выполняем полный бэкап базы. На Backup-сервере восстанавливаем данные из терминала в области %SYS с помощью программы ^BACKUP или любой другой утилиты восстановления БД [3].
При этом база данных будет сразу же включена в зеркало на Backup-сервере, т.к. информация о принадлежности зеркалу уже содержится в бэкапе.
После восстановления бэкапа, базу данных необходимо активизировать (Activate) и привести в актуальное состояние с primary-сервером (catch-up). Заходим в Монитор зеркала Backup-сервера и выполняем для базы Activate и Catch-up.
База данных включена в зеркалирование и готова к работе — это можно видеть на мониторе зеркала.
Подключимся по виртуальному IP-адресу зеркала к веб-приложению, которое установлено в базе ASU. Убедимся, что приложение работает.
Теперь все готово, можно разрушать тестировать сервер, чтобы проверить функциональность failover-узла. Но об этом в следующей части. Продожение следует…
Автор: intersystems
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/administrirovanie/11538
Ссылки в тексте:
[1] изученный: http://en.wikipedia.org/wiki/Failover
[2] документе: http://intersystems.ru/cache/whitepapers/pdf/database_mirroring.pdf
[3] утилиты восстановления БД: http://docs.intersystems.com/cache20121/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_backup#GCDI_backup_restore
Нажмите здесь для печати.