Создание кластера DAG MS Exchange Server 2010

Настоящая статья посвящена ошибкам, которые могут возникнуть при создании группы обеспечения доступности баз данных (DAG) почтового сервера MS Exchange Server 2010.

По сути DAG представляет собой кластер, построенный на основе службы кластеров ОС Windows Server, предназначенный для автоматического переключения копий баз данных почтовых ящиков в случае отказа одного из серверов. Принцип действия заключается в том, что на нескольких серверах-членах кластера размещаются копии одной и той же базы данных, при этом на одном из серверов БД находится активная копия, а на остальных серверах - пассивные копии. При этом синхронизация изменений в копиях БД осуществляется путем репликации журналов транзакций, по этой причине данное обстоятельство важно учесть при резервном копировании.

Сама процедура достаточно подробно описана в интернете, поэтому расписывать не стану, опишу лишь основное и приведу ошибки, с которыми мне пришлось столкнуться в процессе создания

Обязательные условия

Создание кластера DAG закончится ошибкой, если приведенные ниже условия не будут выполнены. Поэтому перед созданием кластера важно выполнить следующие условия:

На всех серверах кластера, за исключением сервера-свидетеля, должна быть установлена одна и та же редакция и версия операционной системы;
На всех серверах кластера, за исключением сервера свидетеля, должен быть установлен одинаковый набор обновлений. По этой причине желательно создавать кластер из новых серверов, дабы избежать возможных ошибок из-за несовпадения набора обновлений. Конечно, 100% совпадение установленного набора обновлений на серверах будущего кластера не требуется, но желательно, ибо что никакой конкретики мне найти не удалось, да и при создании кластера новым был лишь один из двух серверов. Поэтому "подгонять" пришлось экспериментальным путем.
В домене не должно быть иных учетных записей, имя которых совпадает с именем добавляемого в кластер сервера. С именем сервера может быть только учетная запись самого сервера!
В работе AD DS и DNS не должно быть никаких проблем, имена серверов должны ПРАВИЛЬНО разрешаться службой DNS

Возможные ошибки

Первая ошибка, с которой мне пришлось столкнуться, и судя по тому, что пишут на различных профильных форумах, не я первый столкнулся с этой ошибкой, звучала так:

Сбой административной операции группы обеспечения доступности баз данных. Ошибка: The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster operation. Error: Cluster API ‘”AddClusterNode() (MaxPercentage=100) failed with 0x5b4.

Эта ошибка кроется в проблемах с авторизацией, однако найти в интернете причину данной ошибки мне не удалось. Так как возникла она при попытке добавить в кластер второй узел, я решил удалить из кластера единственный на тот момент сервер, и повторить процедуру добавления серверов в кластер в обратном порядке. И это, можно считать, сработало, поскольку на сей раз я получил другую ошибку:

A database availability group administrative operation failed. Error: Windows Failover Clustering timed out while trying to validate server ‘MBS1’. If this is in a disjoint DNS namespace, the DNS suffixes for all servers in the database availability group must be present on every server.

Исходя из текста ошибки, причина может быть связана с невозможностью разрешения имени сервера службой DNS, однако это не единственная причина возникновения такой ошибки. В моем случае проблема не была связана с DNS, просто в AD имелась пользовательская учетная запись с именем "MBS1", точно также как и у сервера, который я пробовал добавить в кластер.

Осмелюсь предположить, что и предыдущая ошибка также была связана с наличием в AD учетной записи, имя которой совпадало с именем сервера.

После того, как в кластер были добавлены все сервера, которые планировалось добавить, можно приступать к добавлению копий баз данных почтовых ящиков. Как я уже писал выше, синхронизация изменений в копиях БД осуществляется посредством репликации журналов транзакций. При создании копии БД на другом сервере тоже используется журнал транзакций активной копии базы. Поэтому, если ранее осуществлялось резервное копирование единственной копии базы данных, создание дополнительных копий завершится ошибкой копирования журналов, поскольку резервное копирование усекает журналы транзакций. Выходом из этой ситуации является создание новой базы данных, с последующим переносом в нее всех почтовых ящиков, включая скрытые системные.

Важно отметить, что копии базы данных на всех серверах всегда находятся по одному и тому же пути. Поэтому, перед добавлением копий БД важно позаботиться, чтоб на других серверах кластера имелся том (диск) с точно такой же буквой, как и на первом сервере. То есть буквы дисков, использующихся для хранения копий баз данных, должны совпадать на всех серверах кластера.

Заключение

Несмотря на кажущуюся простоту, создание кластера DAG MS Exchange Server является довольно сложной процедурой, в основном из-за большого количества условий, которые необходимо выполнить непосредственно перед созданием кластера и добавлением в него серверов, а также чувствительности самого Exchange Server ко всяким мелочам.

Учитывая то, что синхронизация изменений между копиями баз данных осуществляется путем репликации журнала транзакций с сервера, на котором находится активная копия БД на другие сервера, важно чтоб используемое средство резервного копирования поддерживало работу с DAG.

Встроенное в ОС Windows Server решение для резервного копирования Windows Server Bacup (WSB) может делать бэкап только активной копии БД. По этой причине я бы не рекомендовал использовать WSB вместе с DAG.

Кто-то может подумать, что при использовании DAG резервное копирование становится необязательным, ведь у каждой БД в данном случае есть несколько копий. Но это не так.

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

Полезные ссылки: