пятница, 12 октября 2012 г.

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

imageВ прошлой статье мы посмотрели на то, какой простой теперь стала настройка 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)

clip_image002

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

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

clip_image003

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

Сеть

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

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

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

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

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

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

clip_image005

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

Имя кластера

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

clip_image007

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

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

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

clip_image009

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

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

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

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

clip_image011

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

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

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

clip_image012

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

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

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

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

Заключение

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

11 комментариев:

Sergey комментирует...

Почему коментарий удалили ?

Алексей Богомолов (Alexx) комментирует...

Если вы про этот пост, то я не знаю куда он делся, я его не удалял. "Есть вопрос. У меня два хоста EX1 и EX2 со всеми ролями Exchange 2013 и хост свидетель WS. WS и EX1 находятся в офисе, а EX2 на хостинг провайдере. Допустим я теряю связь между EX1 и EX2 и у меня выключается WS. Что будет во время происшествия и что случится после включения ? "

Отвечая на вопрос - если у вас упадет сеть для всех нод Exch`a, то я не знаю что будет (это легко проверить в лабе). Отвечает за перезключение РАМ, как он себя поведет в данном случае - я не знаю (http://www.alexxhost.ru/2012/07/dag-active-manager.html)

Alex комментирует...

Что будет, если пропадет доступ к папке Witness Directory?

Анонимный комментирует...

Если я правильно понимаю, что при потери доступа к папке на сервере-свидетеле ничего не случится до поры до времени.
В этой конфигурации кластера допускается потеря половины узлов, если имеется доступ к папке на сервере-свидетеле, или имеется более половины узлов без доступа к хранилищу на сервере-свидетеле.

Анонимный комментирует...

при попытке добавить сервера в группу выкидывает ошибку:

ошибка

The fully qualified domain name for node 'SRV-MAIL-DAG' could not be found.

в DNS имя создал вручную, в АД комп создался автоматом, ip группы не пингуется и папка на сервере-свидетеле, даже если я ее создал в ручную через какое-то время пропадает сама не известно куда...

Анонимный комментирует...

по поводу ошибки:

The fully qualified domain name for node 'SRV-MAIL-DAG' could not be found.

забыл уточнить, DHCP у меня в сети нет!

Анонимный комментирует...

Алексей, день добрый!

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

Алексей Богомолов (Alexx) комментирует...

Это было в RTM версии, похоже что в последующих CU данное поведение поменялось и теперь так не происходит.

Unknown комментирует...

по поводу ошибки:

The fully qualified domain name for node 'SRV-MAIL-DAG' could not be found.

попробуйте это:
http://technet.microsoft.com/en-us/library/ff367878.aspx

Анонимный комментирует...

по поводу ошибки:

The fully qualified domain name for node 'SRV-MAIL-DAG' could not be found.

Помимо рекомендаций по указанной выше ссылке надо зайти в свойства учетной записи кластера в AD, на вкладке "Редактор атрибутов" (при включенной опции Вид -> Дополнительные компоненты), в атрибуте "dNSHostName" прописать FQDN имени кластера.

Анонимный комментирует...

Приветствую, Алексей!

В каких ситуациях необходимо создавать 2 и более DAG групп?

Отправить комментарий