Exchange 2013 - Database Availability Group (DAG), часть 2

В прошлой статье мы посмотрели на то, какой простой теперь стала настройка DAG`a в Exchange 2013. К сожалению, только собрать кластер зачастую бывает не достаточно, да и не всегда он нормально собирается, в связи с этим, нужно хотя бы примерно представлять, как он работает и как его ремонтировать / тестировать в случае проблем. Вот именно с этой целью я постараюсь далее чуть более подробно рассказать про DAG.

Witness-server

Для начала ещё раз уясним, что работа DAG основана на компонентах службы Failover Cluster, следовательно, как и в любом Failover Cluster`e, в нем должен быть кворум. В качестве кворума в DAG используется папка на сервере-свидетеле (witness). Через эту папку узлы обмениваются между собой служебной информацией. В качестве сервера-свидетеля может выступать любой сервер, не входящий в группу DAG, версия Windows Server операционной системы этого не обязательно должна совпадать с версией операционной системы, используемой участниками группы доступности базы данных.

Примечание: В случае организации DAG из нечетного числа участников, сервер-свидетель не используется в работе кластера, но указать его все равно придется!

В качестве папки (Witness Directory) может выступать любая папка на сервере-свидетеле. Нужно понимать, что для успешной работы кластера все узлы должны иметь право писать в эту папку и читать из неё. Для обеспечения этой возможности вам следует в группу локальных администраторов добавить доменную группу Exchange Trusted Subsystem. (см. рис.1)

Рис. 1: Группа Exchange Trusted Subsystem.

Во время настройки кластера вы можете самостоятельно указать папку на сервере-свидетеле, в противном случае, мастер создаст её сам (см. рис. 2)

Рис. 2: Автоматически созданная папка кворума.

Сеть

Что касается сети, то здесь ни чего с версии Exchange 2010 не изменилось - желательно, чтобы каждая группа доступности базы данных имела две сети:

1. сеть MAPI - используется другими серверами (другими серверами Exchange 2013, серверами каталогов и т. д.) для связи с участниками группы доступности базы данных;

2. сеть Replication - для организации репликации баз данных (доставки и заполнения журналов).

Но поддерживается работа и в одной сети (как и было настроено в первой части статьи).

Если вы настроили больше одной сети в DAG, то на одной из сетей надо отключить возможность репликации. Для этого в свойствах DAG`a ставим галку «Configure database availability group network manually» и у нас появляется возможность редактировать настройки сетей.

Создать новую сеть можно нажав на первый «кружочек» сверху (см. рис.3 ).

Рис.3: Настройка сетей в DAG.

Имя кластера

Когда вы указываете имя кластера, мастер автоматически пытается создать объект Компьютер в Active Directory и соответствующую запись в DNS (если этого по какой-то причине не произошло, попробуйте сделать это самостоятельно). В свойствах объекта Active Directory будет храниться некоторая служебная информация настроек кластера. (см. рис. 4)

Рис. 4: Объект кластера в AD и DNS.

Убедиться, что нужные записи были созданы успешно, можно заглянув в консоль ADUC и найдя компьютер с именем кластера DAG. Также можно открыть консоль Failover Cluster на любой из нод DAG`a и заглянуть в раздел Cluster Core Resources. Все объекты там должны быть в состоянии Online!

Кроме того, для проверки состояния кластера можно запустить его тест – в консоли управления Failover Cluster нажмите ссылку Validate This Cluster… и пройдите по шагам мастера. (см. рис. 5)

Рис. 5: Проверка работоспособности кластера.

Обслуживание кластера

Очень интересный момент заключается в том, что при выхода из строя одного из серверов и после его восстановления, активная копия базы данных в Exchange 2013 автоматически возвращается на него (если конечно до падения она была активирована там), в отличие от Exchange 2010, где базу данных можно было «вернуть» только в ручном режиме.

Проведем тест - на рис. 5 мы инициируем процесс падения активной копии базы данных путем остановки её сервиса (про работу сервиса Information Store читайте здесь). Далее база активируется на второй ноде и продолжает там жить до тех пор, пока на первой ноде сервис Information Store не «поймет», что он был остановлен по ошибке (сервисы в Exchange 2013 имеют свойство восстанавливать (запускаться) самостоятельно, но об этом позже…), после чего он сам запустится и запросит себе базу обратно. В результате база вернется на «родную» ноду и все это происходит примерно за 10-15 минут!

Рис. 5: Возвращение базы данных на “родной” сервер.

Замечу, что можно настроить сервер на который в случае выхода из строя текущего будут переключены базы данных (см. рис. 6).

Из этого можно сделать вывод, что в процесс выбора лучшей копии Exchange 2010 (о  котором мы говорили ранее в статье Автоматическая активация копий базы в DAG: Best Copy Selection (BCS)) снова внесены изменения (о них поговорим позже).

Рис. 6: Настройка приоритетного сервера для переключения баз в случае аварии.

При этом обслуживание базы данных при помощи скрипта StartDagServerMaintenance.ps1 все также поддерживается (по крайней мере этот скрипт в папке Bin присутствует). Напомню, что при помощи скрипта StartDagServerMaintenance.ps1 можно:

- перевести ноду в maintenance mode;

- перераспределить базы данных по нодам, например по параметру Activetion Preferecne.

Заключение

Как обычно, самые интересные настройки производятся через командную консоль управления (EMS), так что учите PowerShell, коллеги :)