次の方法で共有

Альтернативная File Share Witness и переключение между ЦОДами

  • [アーティクル]

Недавно у одного из Заказчиков возник вопрос по способу переключения на альтернативный файловый ресурс-свидетель (File Share Witness, FSW), определяемый в настройках Database Availability Group (DAG). Заказчик считал, что при выходе из строя сервера, на котором базируется основная FSW, DAG автоматически реконфигурирует себя, активируя в качестве основной FSW ранее указанную альтернативную.

Говоря более конкретно, в Организации есть два Центра Обработки Данных (ЦОД), находящиеся в одном городе, но разнесенные по разным адресам. Инфраструктура построена так, что оба ЦОД разделяют одну локальную сеть, один сайт Active Directory. В каждом из ЦОДов располагается один сервер Exchange 2010 роли MailBox – член единого DAG. Т.е. DAG состоит из двух MBX. Для полной картины скажем, что в каждом ЦОДе есть по одному почтовику роли CAS+HUB, хотя это к делу совершенно не относится. Общая папка FSW располагается на сервере CAS+HUB ЦОД №1. Альтернативный путь к FSW настроен на CAS+HUB ЦОД №2.

Рассматривается вариант, когда все серверы ЦОД №1 выходят из строя. Заказчик ожидал, что в этом случае кластер автоматически активирует в качестве FSW альтернативную папку, т.е. файловый ресурс-свидетель переедет в ЦОД №2, и поэтому кластер не развалится, MBX во втором ЦОД продолжит обслуживать пользователей. Потому что есть же правило, что кворум существует при (V/2+1) участниках, в конфигурации DAG с двумя нодами их должно быть ровно два, что выполняется: MBX и новый FSW.

Однако на практике выходило, что если выключить MBX и FSW в первом ЦОДе, MBX во втором ЦОДе переставал обслуживать клиентов, DAG разваливался.

Здесь произошло недопонимание. На самом деле, случилось то, что и должно было. Потому что… Про это и другие возможные недопонимания, которые, вероятно, есть у Вас по отношению к средствам высокой доступности Exchange 2010, почитайте эту замечательную статью (англ). В ней рассказывается, почему определение альтернативного FSW не создаёт избыточности механизму Witness Server, почему вынос FSW в альтернативную площадку, к которой подключены оба ЦОДа, тоже не поможет поддержать работу MBX-2 при выходе из строя первого ЦОД.

Вообще, автоматического переключения в случае выхода из строя одного из двух ЦОДов в данном случае – нет. Чтобы обеспечить работу MBX второго ЦОДа, без выполнения администратором вручную команд не обойтись. В Интернете есть подробная инструкция по “Datacenter Switchower”. Вкратце, порядок действий должен быть такой:

При активированном режиме “database activation coordination (DAC)”

1) Если «неисправный» ЦОД с FSW ещё доступен, то в неисправном ЦОДе в консоли Exchange PowerShell надо ввести команду 

stop-databaseavailabilitygroup -Identity <имя DAG> -MailboxServer <mbx1>   – если этот MBX еще работает –

либо  stop-databaseavailabilitygroup -Identity <имя DAG> -MailboxServer <mbx1> -ConfigurationOnly  - если AD работает, а MBX уже нет.

2) В «здоровом» ЦОДе в консоли Exchange PowerShell надо ввести команды

net stop clussvc

stop-databaseavailabilitygroup -Identity <имя DAG> -MailboxServer <mbx1> -ConfigurationOnly 

Restore-DatabaseAvailabilityGroup -Identity <имя DAG> –ActiveDirectorySite <имя AD-сайта>

В результате выполнения очень важной команды Restore-DatabaseAvailabilityGroup   (доступной только при использовании DAC) происходит:

  • Принудительное признание альтернативного кворума для DAG, позволяющее ее оставшимся членам запускаться и продолжать работу.
  • Изменение свидетеля группы обеспечения доступности баз данных с основного следящего сервера на дополнительный следящий сервер.
  • Удаление всех отказавших членов в группе доступности базы данных.

Таким образом, заранее заданное значение пути для альтернативного FSW здесь активируется без необходимости настройки. Это единственная причина, по которой определяется альтернативный файловый ресурс-свидетель. Во всех других случаях его перенастройка автоматически НЕ происходит.

Команда Restore-DatabaseAvailabilityGroup сама стартует службу кластера. DAG должен подняться ОК, базы должны подмонтироваться.

Если режим DAC не используется:

На втором сервере MBX, находящемся во втором ЦОДе, дать команду  Net stop clussvc и затем  Net start clussvc /forcequorum  –  работоспособность DAG для пользователей ЦОД "№2 восстановится.