Если вам свойственно помышлять о создании высокодоступных решений очень дешевым способом, то, возможно, вы думаете о подготовке группы доступности баз данных Database Availability Group (DAG) с использованием в качестве сервера-свидетеля на рабочей станции Windows 7/8/10. Если так, то немедленно выбросите эту идею из головы. И не столько потому, что данное решение не поддерживается, сколько потому, что оно не обеспечит высокую доступность.

Среди ИТ-специалистов уже давно ходит легенда о том, что рабочую станцию Windows 7/8/10 можно использовать в качестве сервера-свидетеля для групп доступности баз данных Exchange Server. Однако это всего лишь теория, и, насколько мне известно, никто пока не взял ее на вооружение и не попытался реализовать такую конфигурацию. Позвольте мне здесь публично заявить, что данное решение является неподдерживаемым, опрометчивым, непредсказуемым и, наконец, просто нелепым.

. И на практике все не совсем так, как было показано в 1996 году, когда Марк Русинович обнаружил, что изменение нескольких ключей реестра превращает рабочую станцию Windows NT в сервер. Конечно, Марк сейчас — важная персона в Microsoft, где он посвящает свое время Azure, а не написанию триллеров типа «Rogue Code: A Jeff Aiken Novel» (http://www.amazon.com/gp/product/1250035376/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1250035376&linkCode=as2&tag=though0f-20&linkId=E4NCKGBPADPVRDKR).

Сейчас ситуация немного другая, и между сервером и рабочей станцией есть важные различия. За долгие годы было сделано немало для создания «единой Windows», и в самом деле ядро у всех систем семейства Windows одно и то же, однако серверы и рабочие станции предназначались для выполнения очень разных задач. Даже самый «маленький» сервер Windows 2012 разработан для предоставления более надежной рабочей среды, чем способна обеспечить самая мощная рабочая станция с Windows 8.1 Pro. Признайтесь, если вы создаете DAG, которая должна обеспечивать высокую доступность для критически важных почтовых ящиков, то зачем вам использовать рабочую станцию? Это не имеет никакого смысла.

В любом случае группа разработчиков Exchange требует, чтобы для размещения файлового ресурса-свидетеля file share witness (FSW) использовалась серверная редакция Windows. Сервер-свидетель не может быть членом группы DAG, которая использует файловый ресурс-свидетель, размещенный на данном сервере, но один и тот же сервер при необходимости может играть роль сервера-свидетеля для нескольких групп DAG. Подходящими кандидатами на роль сервера-свидетеля могут быть, например, сервер Exchange, не входящий в группу DAG, или сервер печати, и даже контроллер домена, если у вас нет под рукой другого сервера.

FSW применяется для поддержки кворума для службы Windows Failover Cluster только в схеме большинства узлов и файлового ресурса (a node and file share majority). Больше ни для чего этот ресурс не используется. FSW управляется кластером так же, как и все остальные ресурсы, от которых зависит кластер.

Если посмотреть на содержимое папки ресурса-свидетеля (настроенного в свойствах группы DAG), то можно увидеть два текстовых файла, см. экран. Один из этих файлов, VerifyShareWriteAccess.log, используется службой Windows Failover Cluster для периодических проверок состояния ресурса-свидетеля. Второй файл, Witness.log, используется кластером для блокировки ресурса-свидетеля, когда кластеру необходим голос для кворума. Windows использует так называемый алгоритм Паксос (Paxos, http://en.wikipedia.org/wiki/Paxos_(computer_science)) для обеспечения согласованности внутри кластеров. Любое изменение в кластере приводит к обновлению значений тэгов Паксос для узлов кластера. Файл witness.log будет содержать обновленную информацию о тэгах Паксос для кластера (https://support.microsoft.com/kb/947713). Если файл может быть заблокирован, то кластер определяет, что он может использовать голос ресурса-свидетеля для обеспечения кворума.

 

Cодержимое папки ресурса-свидетеля
Экран. Cодержимое папки ресурса-свидетеля

Несмотря на то что Microsoft изучает новые схемы для FSW в группе DAG, вроде так и не реализованной пока попытки размещения FSW в среде Azure (http://blogs.technet.com/b/exchange/archive/2013/08/07/database-availability-groups-and-windows-azure.aspx), нет никакой необходимости использовать для хранения FSW рабочую станцию. Опять же, DAG — это решение для обеспечения высокой доступности. Использование в данном сценарии рабочей станции — верный путь к превращению данного решения в низкодоступное.