Каждую новую версию Exchange Server специалисты Microsoft наделяют новыми возможностями. Некоторым из них не суждено стать объектами всеобщего внимания, и от них в конце концов отказываются — помните сервер Exchange NNTP (Network News Transfer Protocol)? Другие, например кластеры в режиме «активный/активный», озаряет яркий, но недолгий фейерверк славы. А третьи олицетворяют фундаментальные изменения в методах проектирования и развертывания систем Exchange. К этой последней категории и относятся реализованные в Exchange 2010 новые группы доступности баз данных (DAG). Идея обеспечения отказоустойчивости доступа к почтовым ящикам за счет распределения нескольких копий баз данных почтовых ящиков по всей организации Exchange весьма плодотворна, и ее воплощение в системе Exchange 2010 — важный этап эволюции структур с высоким уровнем доступности. Технические основы DAG представлены в статье Тони Редмонда «Exchange 2010: обеспечение высокой доступности с использованием групп DAG».

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

Предварительные условия для работы групп DAG

Первое — и важнейшее — предварительное условие функционирования групп DAG формулируется просто: у вас должна быть установлена система Windows Server 2008 или 2008 R2 Enterprise Edition. Те, кто работает с версией Standard Edition, не смогут развернуть на сервере группы DAG без переустановки Windows. Возможность обновления на месте с уровня Standard до уровня Enterprise не предусмотрена. К сожалению, это означает, что, если у вас есть сервер Standard Edition, на котором уже выполняется Exchange, этот сервер сможет работать как сервер DAG только после обновления. Такова участь многих узлов, администраторы которых экспериментировали с ранними версиями Exchange 2010 на серверах Server 2008 Standard, предполагая в дальнейшем обновить свои почтовые серверы до уровня членства в DAG.

В контексте функционирования сети предварительные условия для использования DAG достаточно просты. Надо сказать, что термины, применяемые при эксплуатации Exchange 2010 и Exchange 2007, несколько отличаются. Сеть MAPI на сервере, входящем в группу DAG, предназначена для взаимодействия с другими серверами Exchange и Active Directory (AD), тогда как сеть репликации используется для передачи трафика репликации баз данных. Одно из существенных отличий Exchange 2010 от Exchange 2007 состоит в том, что Exchange 2010 теперь допускает применение единого интерфейса как для сети MAPI, так и для сети репликации, хотя по-прежнему считается, что для этих двух функций лучше задействовать раздельные сетевые интерфейсные платы и отдельные сети. В случае сбоя в работе сетевого интерфейса MAPI сервер передаст свои базы данных другому члену DAG. Если же выйдет из строя интерфейс репликации, трафик репликации будет без предупреждения переведен в сети MAPI и вернется в сеть репликации, когда последняя вновь станет работоспособной.

Администратор может задать несколько сетей репликации, что полезно в случае применения сложных топологий. Однако на каждом сервере группы DAG должно быть указано одно и то же число сетей. Все члены DAG должны иметь возможность взаимодействовать с сетевой задержкой не более 250 мс, но специалисты Microsoft предупреждают, что большое значение имеет и производительность сети, то есть дело не только в показателях задержки.

Следует иметь в виду и несколько других ограничений. Все члены данной группы DAG должны быть членами одного домена AD, хотя разные группы DAG могут входить в различные домены. Имена групп DAG должны быть уникальными внутри организации и состоять не более чем из 15 символов. Группы DAG — это рудимент службы WINS, все еще представленный в Exchange. Возможно, в следующей версии продукта мы не увидим и его.

Требуется свидетель

Прежде чем вы займетесь формированием первой группы DAG, нам следует обсудить вопрос о роли сервера-свидетеля. Если вы знакомы с технологией кластеризации, вам известна базовая концепция ресурса кворума. В сущности, кворум — это механизм, посредством которого все узлы кластера узнают, каково общее число узлов в кластере и какие узлы функционируют, а какие неисправны на данный момент. Несмотря на то обстоятельство, что при обсуждении групп DAG специалисты Microsoft предпочитают не использовать слово «кластер», факт остается фактом: члены DAG должны иметь механизм для определения того, какие узлы DAG являются активными, а какие — нет. За статусом узлов следит специальный компонент Active Manager, но он должен иметь возможность сохранять эту информацию о статусе в группах DAG, располагающих четным числом членов.

Вот тут-то на сцене и появляется сервер-свидетель, представляющий собой не что иное, как файловый ресурс на любом сервере Windows в данном лесу. Microsoft рекомендует размещать его на центральном транспортном сервере, чтобы роль свидетеля оставалась под контролем администратора Exchange. Свидетель для группы DAG не может запускаться на сервере почтовых ящиков, который является членом той же группы DAG. Если вы запустите роль свидетеля для одной DAG на сервере другой группы DAG, это не будет нарушением, но с точки зрения обеспечения отказоустойчивости это не лучший вариант. Сервер, на котором запускается роль свидетеля, должен быть членом группы безопасности Exchange Trusted Subsystem. Серверы Exchange 2010 включаются в эту группу в процессе установки, но, если вы запускаете роль свидетеля на сервере другого типа, нужно убедиться в том, что данный сервер включен в эту группу.

В процессе формирования DAG при желании можно указать сервер и каталог, где будет размещен свидетель. Если вы не укажете названные параметры, Exchange попытается запустить роль свидетеля на центральном транспортном сервере, которому не назначена также роль сервера почтовых ящиков; роль свидетеля будет запущена на первом же подходящем сервере, обнаруженном системой.

Когда администратор создает DAG с четным числом узлов, Exchange автоматически формирует ресурс свидетеля и относящиеся к нему данные на сервере, указанном администратором. Если вы измените DAG с четным числом узлов, а именно добавите или удалите узел, так что их общее число станет нечетным, Exchange удалит роль свидетеля. К чему это ведет — понятно: если вы будете наращивать группы DAG, добавляя отдельные узлы, будьте готовы к лишней суете; Exchange будет добавлять и удалять роль свидетеля при каждом изменении числа серверов.

Допустим, вы хотите создать DAG из двух узлов — это простейшая возможная конфигурация. Группа будет иметь уникальное имя и IP-адрес, который может быть статическим или назначаемым через DHCP. Если в вашей сети MAPI имеется несколько подсетей, в каждой подсети для группы DAG нужно будет иметь один IP-адрес. Для простоты будем исходить из того, что в нашей сети MAPI имеется одна подсеть — 172.16.250.x.

Итак, первый шаг: нам нужно установить на серверах DAG систему Windows Enterprise Edition. После этого мы можем приступать к установке серверной роли Mailbox системы Exchange 2010. В этот момент начинаются интересные вещи. Процесс установки DAG и запуска ее в работу состоит из нескольких четко выраженных этапов. Сначала создается сама группа, затем к ней добавляются серверы, после чего администратор дает санкцию на завершение процедур присвоения начальных значений и репликации. Рассмотрим эти этапы по порядку.

Создание новой группы DAG

Группы DAG можно создавать с помощью составной команды New-DatabaseAvailabilityGroup или посредством мастера New Database Availability Group wizard в консоли Exchange Management Console (EMC). На экране 1 показана первая страница мастера с указанными именем DAG, именем сервера-свидетеля и каталогом свидетеля. Нажав кнопку New, создайте объект DAG в AD, и он немедленно отобразится в консоли EMC на вкладке Database Availability Groups представления Mailbox узла Organization Configuration, как показано на экране 2. Это представление демонстрирует группы DAG, существующие в организации, и серверы, входящие в их состав. Чтобы выяснить, какие базы данных почтовых ящиков входят в состав тех или иных групп DAG, воспользуйтесь вкладкой Database Management, на которой перечислены все известные базы данных почтовых ящиков и показано, на каком сервере (или серверах) размещается каждая из них.

Экран 1. Мастер New Database Availability Group wizard

Экран 2. Представление нескольких групп DAG

Вновь созданная группа DAG представляет собой простой объект «контейнер AD»; пока что ей не назначены ни серверы, ни сети. По умолчанию новая группа DAG получит IP-адрес через DHCP. Вы можете назначить ей IP-адрес и после формирования группы. Для этого используется команда Set-DatabaseAvailabilityGroup (с переключателем DatabaseAvailability­GroupIpAddresses), которая позволяет устанавливать IP-адреса только для сети MAPI. Не стоит пользоваться описанным методом для назначения IP-адресов сети репликации. Это проще сделать при создании DAG в командной консоли Exchange Management Shell (EMS) следующим образом:

New-DatabaseAvailabilityGroup -name
   Seattle01 WitnessServer einstein
   -DatabaseAvailabilityGroupIPAddresses
   172.16.241.105

Управление членством в группе DAG

Разумеется, новая группа DAG не сможет ничего сделать до тех пор, пока вы не добавите в нее серверы. Добавление выполняется с помощью мастера Manage Database Availability Group Membership wizard в консоли EMC (для ее запуска нужно щелкнуть на объекте DAG правой кнопкой мыши) или с помощью команды Add-DatabaseAvailabilityGroupMember. В любом случае от вас требуется только указать те серверы почтовых ящиков, которые вы хотите добавить в DAG, а все остальное сделает Exchange.

Как будто бы все просто. Но на самом деле незаметно для пользователя Exchange выполняет огромный объем работ:

  1. В случае если Windows Failover Cluster (WFC), компонент Windows Server еще не установлен, система устанавливает его. По сложности эта задача сопоставима с созданием кластера Windows, так что ее лучше выполнять в автоматическом режиме.
  2. Создается новый объект «отказоустойчивый кластер» с использованием имени, указанного для DAG. Exchange поддерживает только синхронизацию кластера, базу данных кластера и список сетей кластера.
  3. Система регистрирует новую запись A с именем и IP-адресом группы DAG в DNS.
  4. Система добавляет сервер в качестве члена объекта DAG в AD.
  5. Система обновляет базу данных WFC, включая в нее данные о новом сервере и базах данных, которые на нем установлены.
  6. Диспетчер Active Manager получает сведения о копиях новой базы данных на только что добавленном узле.

Когда вы включаете в группу DAG другие узлы, все базовые шаги повторяются. Впрочем, при этом необходимо сделать еще одно: возможно, службу WFC придется перевести в режим «большинство узлов» (если DAG на данный момент состоит из нечетного числа членов) или в режим «большинство узлов плюс свидетель» (если DAG на данный момент состоит из четного числа членов). Вы можете удалять узлы DAG, но перед этим необходимо удалить реплицированные копии баз данных почтовых ящиков, которые узел содержит. Для этого воспользуйтесь командой Remove-DatabaseAvailabilityGroupMember или консолью EMC.

Управление базами данных почтовых ящиков

По завершении формирования группы DAG и перед тем, как эта группа начнет защищать данные почтовых ящиков, предстоит сделать еще кое-что. Вы должны указать, какие базы данных почтовых ящиков должны быть реплицированы в группе. Для этого необходимо добавить копии базы данных почтовых ящиков в DAG с помощью команды Add-MailboxDatabaseCopy или другим способом: щелкнув правой кнопкой мыши на базе данных в консоли EMC и выполнив команду Add Mailbox Database Copy.

Добавляя копию базы данных почтовых ящиков к серверу группы DAG, вы тем самым предписываете серверу приступить к обслуживанию реплицированной копии базы данных. Эта процедура осуществляется в две фазы. Во-первых, копии базы данных нужно присвоить начальные значения: Exchange копирует данные из существующей копии в новую. Когда система завершает передачу всего содержимого базы данных по новому целевому адресу, она выполняет копирование каждого нового журнального файла, сгенерированного через подключение к сокету TCP, а затем воспроизводит его в реплицированной копии.

Процесс присвоения начальных значений в том виде, в каком он представлен в статье Managing Mailbox Database Copies (technet.microsoft.com/en-us/library/dd335158.aspx), состоит из 28 этапов. Коротко их можно описать так:

  1. Exchange выполняет несколько проверок, дабы удостовериться, что исходная база данных и журнальные файлы существуют и что целевой каталог может принимать начальные данные.
  2. Служба Microsoft Exchange Replication на целевой системе формирует запрос на начало процесса присвоения начальных значений.
  3. Служба Microsoft Exchange Replication на исходной системе приостанавливает репликацию исходной базы данных.
  4. Целевая система направляет запрос на начало фактической передачи потока начальных значений.
  5. Исходный сервер начинает сеанс резервного копирования с помощью известного интерфейса прикладного программирования для потокового резервного копирования Extensible Storage Engine (ESE).
  6. Данные, полученные из исходной базы, передаются службе репликации Microsoft Exchange, которая отправляет их по сети репликации службе репликации на целевой системе.
  7. Когда полная база данных получает все первоначальные значения, вновь созданная база данных переносится на свое окончательное место.

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

Иногда копия базы данных отличается от оригинала. Это может случиться, к примеру, в результате прерывания в работе сети или отказа аппаратного компонента. Когда копия не соответствует оригиналу, процедуру присвоения начальных значений следует повторить. Exchange выполняет такую процедуру лишь после создания новой базы данных; если копия не соответствует оригиналу базы данных, присвоение начальных значений нужно проводить вручную. Для этого можно либо выполнить составную команду Update-MailboxDatabaseCopy, либо запустить мастер обновления копий Update Database Copy wizard в консоли EMC.

Работа с группой DAG

После формирования группы DAG и добавления в нее копий баз данных в обычных условиях эксплуатации администратору не остается ничего иного, кроме как отслеживать состояние реплицированных базы данных. На экране 3 показана вкладка Database Management консоли EMC. На этой вкладке отображается состояние каждой копии базы данных: присвоение начальных значений, работоспособность, состояние подключения и т.  д. В случае выхода из строя активной копии базы данных активацию соответствующей реплики базы данных берет на себя диспетчер Active Manager.

Экран 3. Представление Database Management

Кроме того, администратор может активировать индивидуальную копию базы данных вручную с помощью команды Move-ActiveMailboxDatabase (или с консоли EMC). Активация копии базы данных вручную называется переключением (switchover); когда же Exchange выполняет эту операцию в автоматическом режиме, она именуется обработкой на другом ресурсе (failover). Но как бы ни называлась эта операция, инфраструктура Active Manager берет на себя заботу об извещении других компонентов Exchange (таких, как уровень клиентского доступа RPC), с тем чтобы клиенты могли подключаться ко вновь активированной копии почтового ящика.

Что же в результате?

Так работает ли эта технология? Вне всякого сомнения. Недавно мне довелось развертывать систему Exchange 2010 в компании, где ранее эксплуатировался почтовый сервер Linux. Не прошло и недели после развертывания, как кто-то нечаянно отключил и перенес в другое место одну из физических систем, на которой выполнялся виртуализованный сервер почтовых ящиков. Представьте — никто этого и не заметил! На работе пользователей переключение никак не отразилось, а факт перехода на другой ресурс был обнаружен лишь после того, как один из сотрудников обнаружил, что там, где раньше стоял физический сервер, теперь ничего нет.

Группы DAG предоставляют администраторам богатый выбор. Стоит ли использовать массив RAID или взять «просто кучу дисков» (Just a Bunch of Disks, JBOD)? Сколько понадобится серверов в группе DAG? Сколько нужно копий базы данных? Целесообразно ли разместить серверные роли Hub Transport, Mailbox и Client Access в двухузловых группах DAG? И если да, то как организовать переход на другой ресурс и балансировку нагрузки для роли Client Access? Одна из замечательных особенностей технологии, лежащей в основе набора средств DAG, состоит в том, что ее можно адаптировать под широкий диапазон ситуаций, включая и отказоустойчивость узла, и высокий уровень доступности почтовых ящиков.

С течением времени организации набираются опыта в проектировании, развертывании и эксплуатации систем Exchange 2010 с группами DAG, и, по-моему, недалек тот день, когда на свет появится несколько конструкций из базовых «компоновочных блоков», которые можно будет приспосабливать к различным обстоятельствам, и это станет важным событием в эволюции проектирования и развертывания систем Exchange с высоким уровнем доступности.

Поль Робишо (getting-started@robichaux.net) — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT