В Exchange 2010 появилась возможность достаточно просто собрать отказоустойчивую конфигурацию для почтовой системы организации на базе нескольких дата центров, которые физически разнесены друг от друга. Для данной конфигурации существует одна неразрешимая проблема, которую не совсем получается логически описать, а следовательно автоматизировать. Эта проблема – какой дата центр считать выжившим после сбоя? В связи с наличием данной проблемы и существует процедура переключения активного дата центра (Datacenter Switchover), которую должен выполнять администратор почтовой системы в случае глобального сбоя, приведшего к недоступности одного из дата центров, который использовался пользователями почтовой системы.
Процедура переключения дата центра хорошо описана. Так что я перенесу её, немного сократив.
Стандартный список действий при переключении дата центра:
- Остановка вышедшего из строя основного дата центра.
- Проверка готовности резервного дата центра.
- Активация серверов почтовых ящиков в резервном дата центре.
- Активация остальных серверных ролей в резервном дата центре.
Всё ниже описанное верно в том случае, если мы включаем режим Datacenter Activation Coordination, который позволяет задействовать протокол DACP при запуске серверов-узлов DAG. Важно помнить, что при его включении базы могут быть подключены на конкретном узле только в следующих случаях:
- Сервер может связаться с остальными узлами DAG (которые отображены в StartedMailboxServers)
- Сервер может связаться хотя бы с одним сервером-узлом DAG, состояние бита DACP которого равно единице
Остановка вышедшего из строя основного дата центра
Это основная реперная точка, в которой нам необходимо решить считать ли основной дата центр вышедшим из строя. Каких либо советов по этому поводу дать, к сожалению, не могу. Если мы действительно решаем, что основной дата центр вышел из строя, то имеет смысл выключить оставшиеся в нём серверы Exchange (если это возможно).
Следующим шагом будет остановка DAG, который растянут между дата центрами. Причём, останавливать необходимо хитро, чтобы узлы DAG в резервном дата центре после этого смогли запустить DAG только на узлах из резервного дата центра. Выполняется это следующим командлетом на одном из серверов в резервном дата центре:
Stop-DatabaseAvailabilityGroup -Identity DAG -ActiveDirectorySite Site-A -ConfigurationOnly $True
В нашем случае, DAG – имя растянутой между дата центрами группы доступности баз данных, Site-A – имя сайта AD в основном дата центре. Список сайтов можно посмотреть через командлет Get-ADSite. Результатом выполнения данной команды будет перемещение серверов из основного дата центра (Site-A) из параметра StartedMailboxServers в StoppedMailboxServers нашей группы доступности. Например, для четырухузлового DAG, распределённого по двум дата центрам с разными сайтами
В результате выполнения команды свойства DAG будут выглядеть следующим образом:
Get-DatabaseAvailabilityGroup -Identity DAG | fl name, servers, stop*, start*
Name : DAG
Servers : {MBX-2, MBX-3, MBX-4, MBX-1}
StoppedMailboxServers : {MBX-1, MBX-2}
StartedMailboxServers : {MBX-4, MBX-3}
Эстеты могут перемещать в StoppedMailboxServers по одному серверу:
Stop-DatabaseAvailabilityGroup -Identity DAG -MailboxServer MBX-1 -ConfigurationOnly $True
Завершающий шаг – остановка сервиса отказоустойчивого кластера на всех доступных узлах DAG:
Stop-service ClusSvc
В дальнейшем, при восстановлении DAG в резервном дата центре он (и отказоустойчивый кластер) будет пересобираться на базе серверов, оставшихся в StartedMailboxServers. Поэтому, важно не ошибиться, и оставить в нём только серверы из резервного дата центра.
Проверка готовности резервного дата центра
Здесь можно дать только общие рекомендации. Очевидно, что перед переключением на резервный дата центр мы должны быть уверены, что он работает в штатном режиме. Можно для этого использовать системы мониторинга (OpsMgr, например) либо какой-то набор проверок, которые дадут нам однозначный ответ, что дата центр готов для запуска сервиса. Так следует помнить, что почтовая инфраструктура сильно интегрирована с инфраструктурными сервисами (AD, DNS, CA). Поэтому необходимо проверять и инфраструктурные сервисы.
Активация серверов почтовых ящиков в резервном дата центре
После того, как мы получили утвердительный ответ на вопрос о том, может ли резервный дата центр принять сервис, можно начинать его активацию. Фактически процесс представляет собой сборку DAG из узлов, оставшихся в StartedMailboxServers, в качестве сервера-свидетеля будет использоваться сервер, указанный в параметре AlternateWitnessServer группы доступности.
- Проверяем, что ClusSvc остановлен на узлах DAG резервного дата центра:
Get-Service ClusSvc
- Активируем DAG на серверах резервного дата центра:
Restore-DatabaseAvailabilityGroup -Identity DAG -ActiveDirectorySite Site-B
Если при создании DAG не указывался альтернативный сервер-свидетель, то можно его в этом же командлете указать через ключи AlternateWitnessDirectory и AlternateWitnessServer. После завершения восстановления DAG использование альтернативного сервера-свидетеля можно посмотреть через:
Get-DatabaseAvailabilityGroup DAG -Status | fl name,oper*,prim*,WitnessShare*
Name : DAG
OperationalServers : {MBX-3, MBX-4}
PrimaryActiveManager : MBX-3
WitnessShareInUse : Alternate
Видно, что рабочими серверами остались только серверы из резервного сайта, причём один из них взял на себя роль PAM.
- Активируем базы на серверах в резервном дата центре. После активации серверов-узлов DAG мы получаем работающую в обычном режиме группу доступности баз данных. Тут следует помнить о том, что если мы какие-то серверы переключили в режим хранить только пассивные копии баз (значение ключа DatabaseCopyAutoActivationPolicy – Blocked), то на них нужно будет это отменить (переключить DatabaseCopyAutoActivationPolicy в IntrasiteOnly или в Unrestricted). Принудительную активацию баз на конкретном сервере можно запустить, например, так:
Get-MailboxDatabase | ?{$_.MasterServerOrAvailabilityGroup -like "DAG"} | Move-ActiveMailboxDatabase -ActivateOnServer MBX-3
- Проверяем ошибки/предупреждения возникшие в процессе активации. Смотрим EventLog, смотрим вывод командлетов, участвовавших в процессе Datacenter Switchover.
Активация остальных серверных ролей в резервном дата центре
Для клиента остальные серверные роли представлены так называемыми конечными точками подключения. Для MAPI-клиентов – это имя CAS Array. Для веб-клиентов (OA/AS/EWS) – это имя балансировщика, который распределяет HTTP/HTTPS-трафик. Для POP3/IMAP4 – это имена конкретных серверов CAS. Активация во всех этих случаях будет представлять собой простую замену ip-адресов в DNS для этих конечных точек на ip-адреса резервного дата центра. Как вариант, можно рассмотреть создание алиаса (CNAME) для этих конечных точек. И в случае сбоя основного дата центра указывать в алиасе имя конечной точки из резервного дата центра.
Возможная таблица замен в случае с алиасом может выглядеть следующим образом:
| Type | EndPoint | Site-A | Site-B |
| MAPI | outlook.dom.loc | outlook-a.dom.loc | outlook-b.dom.loc |
| Web | webcl.dom.loc | webcl-a.dom.loc | webcl-b.dom.loc |
| POP3 | pop.dom.loc | pop-a.dom.loc | pop-b.dom.loc |
В ExternalUrl/InternalUrl мы указываем webcl.dom.loc. И в случае замены конечной точки для клиента ничего не поменяется.
Для CAS Array используем outlook.dom.loc. В случае замены для клиента тоже ничего не поменяется.
Остальные конечные точки будут меняться по аналогичному сценарию.
Восстановление доступности почтового сервиса в основном дата центре
Данный пункт полезен исключительно в том случае, если наш основной дата центр подвергся временному сбою (например длительный сбой подачи электропитания при отсутствии своих генераторов) и, через некоторое время после устранения причины сбоя, будет работать в штатном режиме. Очевидно, что если дата центр был полностью уничтожен, то восстановить его будет можно только на новом месте, и это уже совсем другая история.
Проверка готовности сервера почтовых ящиков
При запуске командлета Stop-DatabaseAvailabilityGroup серверы первого дата центра временно исключаются из кластера DAG. Если процедура исключения прошла успешно, то должны выполняться следующие условия для каждого сервера почтовых ящиков в основном дата центре:
- В System Log должны присутствовать события 7040, 4621, 7036.
- Cluster Service должен быть в состоянии Disabled.
- В реестре должна отсутствовать ветка HKLMCluster.
Если хотя бы одно из этих условий не выполняется, то процедура исключения была выполнена по какой-то причине не до конца. На проблемном узле необходимо запустить следующее:
Import-Module FailoverCluters Clear-CluserNode MBX-1 –Force
Обратная активация роли сервера почтовых ящиков (Switchback)
- Серверы почтовых ящиков должны быть первыми активированы в основном дата центре.
При выполнении процедуры переключения на резервный дата центр серверы в первом дата центре должны были быть выключены. Необходимо включить их назад. После того как серверы загрузятся, выполняем на любом из них:
Start-DatabaseAvailabilityGroup -Identity DAG -ActiveDirectorySite Site-A
После выполнения командлета серверы первого сайты перейдут из StoppedMailboxServers в StartedMailboxServers, а следовательно могут быть использованы как обычные узлы в DAG.
Get-DatabaseAvailabilityGroup -Identity DAG | fl name, servers, stop*, start*
Name : DAG
Servers : {MBX-2, MBX-3, MBX-4, MBX-1}
StoppedMailboxServers : {}
StartedMailboxServers : {MBX-4, MBX-3, MBX-1, MBX-2}
Для пересчёта модели кворума запускаем:
Set-DatabaseAvailabilityGroup -Identity DAG
- Ждём завершения синхронизации копий баз между дата центрами.
- Запускаем саму процедуру обратной активации баз
Процедура полностью аналогична той, которая использовалась при активации баз в резервном дата центре:
Get-MailboxDatabase | ?{$_.MasterServerOrAvailabilityGroup -like "DAG"} | Move-ActiveMailboxDatabase -ActivateOnServer MBX-1
Обратная активация остальных ролей
Так же как и в процессе активации остальных ролей в резервном дата центре при их возвращении в основной дата центр достаточно будет в DNS поменять имена для конечных точек на те, которые находятся в основном дата центре.
Возможные ошибки
- Если при остановке DAG указать неправильный сайт
В этом случае в StoppedMailboxServers попадут не те серверы. Придётся повторно запустить остановку DAG, указав при этом правильный сайт. Неправильно помещённые в StoppedMailboxServers перемещаются в StartedMailboxServers комадлетом Start-DatabaseAvailabilityGroup с ключом ActiveDirectorySite, в котором нужно будет указать резервный сайт.
- Если при остановке DAG забыть указать ключ -ConfigurationOnly
В случае, если основной сайт частично доступен, то в этом случае будет попытка удалить службу Failover Cluster с серверов основного дата центра. При обратной активации основного дата центра придётся отказоустойчивый кластер собирать вручную.
Полезные ссылки:
Datacenter Switchovers
Planning for High Availability and Site Resilience
Understanding Datacenter Activation Coordination Mode
Part 8: Datacenter Activation Coordination: Stop! In the Name of DAG…
Part 7: Datacenter Activation Coordination: When to run start-databaseavailabilitygroup to bring members back into the DAG after a datacenter switchover…
Part 4: Datacenter Activation Coordination and the Prevention of Split Brain
Part 1: My databases do not automatically mount after I enabled Datacenter Activation Coordination
1 thought on “Exchange 2010 Site Resiliense: Datacenter Switchover”