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

    О технологии


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

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


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

    image
    На машине Failover1 заходим в Портал управления Caché/Ensemble в раздел Администрирование/Конфигурация/Настройки Зеркала, выбираем Создать зеркало.
    image
    Для зеркала определяем имя, виртуальный 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
    Переходим на виртуальную машину Failover2, запускаем панель управления/Администрирование — выбираем пункт “Подключиться как Failover”.

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

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

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

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

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

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

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

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

    Теперь все готово, можно разрушать тестировать сервер, чтобы проверить функциональность зеркала. Но об этом в следующей части. Продожение следует…
    InterSystems
    InterSystems IRIS: СУБД, ESB, BI, Healthcare

    Comments 0

    Only users with full accounts can post comments. Log in, please.