Exchange 2010 DAG: убрали кластер и не пожалели

Exchange 2007 с CCR-кластером (Cluster Continuous Replication) - конструкция рабочая, но специфическая. Два узла, Windows Server Failover Cluster, общий диск для кворума, отдельная служба кластера, которую нужно мониторить параллельно с самим Exchange. Когда что-то идёт не так, не всегда сразу понятно - это Exchange или это кластер. Отлаживать приходится в двух местах сразу.

Exchange 2010 вышел в RTM в ноябре 2009 года, и главной инфраструктурной фичей там были Database Availability Groups. Мы долго смотрели на это с интересом, а в апреле взялись за миграцию одного из клиентов - финансовая компания, около 300 почтовых ящиков, Exchange 2007 SP2 на двухузловом CCR.

Что такое DAG по сравнению с CCR

В CCR у вас одна активная база и одна пассивная копия на втором узле. Переключение - через механизм Windows Cluster, с соответствующим журналом событий и процедурой failover, которую кластер контролирует сам.

DAG работает принципиально иначе. Каждая база Exchange может иметь несколько копий на разных серверах-членах DAG. Репликация - через log shipping, встроенный в Exchange, без Windows Cluster в классическом смысле. Технически под DAG всё равно скрыт WSFC (Windows Server Failover Cluster), но он используется только для кворума и witness-узла - вы не управляете им напрямую, Exchange делает это сам.

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

Как делали миграцию

Прямого upgrade-пути с Exchange 2007 на 2010 нет - только новые серверы и постепенное перемещение ящиков. Для клиента взяли два новых сервера под Windows Server 2008 R2, развернули Exchange 2010 SP1 Beta (уже был доступен и стабилен для наших задач), создали DAG.

Основные этапы были такие:

• Создание DAG и добавление членов. Несколько командлетов PowerShell. New-DatabaseAvailabilityGroup, Add-DatabaseAvailabilityGroupServer. Witness-сервер - отдельная машина для кворума при двух узлах DAG.
• Добавление копий баз. Add-MailboxDatabaseCopy - указываешь базу и сервер-назначение. Начинается первоначальная синхронизация, статус видно через Get-MailboxDatabaseCopyStatus.
• Перемещение ящиков. Move-Mailbox с Exchange 2007 на новые серверы 2010. Делали порциями, в нерабочее время. Почта в процессе недоступна несколько минут на ящик.
• Переключение коннекторов и клиентского доступа. CAS-роль на 2010, обновление DNS, переключение Autodiscover.

Занял весь процесс около трёх недель с учётом тестирования и согласования окон.

Что стало лучше

Управление переключением баз. Move-ActiveMailboxDatabase - и активная копия переключается на другой сервер. Без вызова оснастки кластера, без вопроса «а кластер это видит?». Тестировать плановое переключение теперь не страшно - делается за секунды, Outlook перестраивает соединение практически незаметно для пользователя.

Видимость состояния репликации. Get-MailboxDatabaseCopyStatus даёт текущий статус каждой копии каждой базы: отставание в очереди на запись, отставание по репликации, последний проверенный checkpoint. В CCR это тоже было, но через другие инструменты и менее наглядно.

Witness и кворум без боли. При двух узлах DAG нужен witness-сервер для кворума - мы использовали сервер с ролью Hub Transport, который уже был в инфраструктуре. Настройка - одна команда. В классическом WSFC настройка кворума - это отдельный разговор с дисковыми ресурсами.

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

Что не стало проще

Честно - миграция с 2007 нетривиальная. Если на 2007 CCR работало годами, трогать это ради DAG только ради красоты - спорное решение, особенно если инфраструктура небольшая. Смысл появляется там, где нужна гибкость: добавить третий сервер с ещё одной копией базы, разнести копии по разным площадкам, управлять несколькими базами с разным уровнем защиты.

Ещё момент - два сервера в DAG без witness фактически не имеют кворума при потере связи между узлами. Это ситуация split-brain, и Exchange её обрабатывает консервативно - обе стороны могут отказаться быть активными. Witness-сервер решает это, но его тоже нужно держать живым.

Первые впечатления

После завершения миграции первые несколько недель работы показали: плановые переключения для обслуживания серверов стали рутиной. Раньше «перезагрузить активный узел кластера» - это мероприятие с уведомлением и координацией. Сейчас - Move-ActiveMailboxDatabase, подождать переключения, перезагрузить, вернуть обратно.

Сопровождение почтовой инфраструктуры на Exchange 2010 с DAG объективно требует меньше времени на административные операции, чем тот же Exchange 2007 на CCR. Не потому что Exchange стал умнее в каком-то абстрактном смысле - просто меньше мест, где что-то может разъехаться в разные стороны.