Планирование, развертывание и тестирование решения устойчивости сайта Exchange 2010 Site-Resilient Solution для средних организаций (часть 7)

В шестой части этого цикла статей мы начали с настройки внутренних и внешних URL адресов для служб CAS на каждом сервере Exchange 2010 на обоих сайтах Active Directory. Затем мы создали группу доступности баз данных (DAG) и выполнили ее основную настройку.

В этой части мы продолжим с того места, на котором остановились в предыдущей части. Мы добавим 4 Exchange 2010 сервера с несколькими ролями в группу DAG, свернем сети DAG, включим координацию доступности баз данных (DAC) для группы DAG и перераспределим копии активных баз данных.

Добавление участников в группу DAG

После создания группы DAG мы можем добавить в нее четыре сервера почтовых ящиков в качестве серверов-участников. Для этого нажимаем правой клавишей на созданной группе DAG и выбираем опцию Управление членством в группе доступности базы данных (Manage Database Availability Group Membership) в контекстном меню, как показано на рисунке 1 ниже.

Рисунок 1: Выбор опции управления членством в группе доступности базы данных

В результате откроется мастер Manage Database Availability Group Membership. Нажимаем Добавить.

Увеличить

Рисунок 2: Мастер управления членством в группе доступности баз данных

Выбираем четыре сервера и нажимаем OK.

Рисунок 3: Добавление серверов в группу DAG

Нажимаем Управление (Manage).

Рисунок 4: Серверы добавлены в группу DAG

Компонент аварийного кластера теперь будет установлен на каждый сервер. Затем группа DAG будет создана и настроена соответствующим образом. Это займет несколько минут, так что наберитесь терпения.

Рисунок 5: Ожидание завершения работы мастера управления членством в группе DAG

После добавления серверов в DAG нажимаем Готово для выхода из мастера 'Manage Database Availability Group Membership'.

Сворачивание и переименование сетей группы DAG

После добавления серверов в группу DAG служба кластера перечислит все обнаруженные сети. Когда у вас есть серверы-участники группы DAG с двумя сетевыми интерфейсами, расположенными в двух центрах данных с разными подсетями, будет создано четыре сети DAG. По умолчанию сети DAG будут названы DAGNetwork02, DAGNetwork02 и т.д. (рисунок 6).

Рисунок 6: Сети DAG

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

Рисунок 7: По умолчанию репликация включена по сети MAPI

Причина такого поведения связана с принципом работы службы репликации 'Microsoft Exchange replication'. Однако здесь мы не будем подробно говорить об этом.

Чтобы свернуть сети MAPI, нам нужно открыть страницу свойств сети 'DAGNetwork01' и добавить подсеть MAPI сети, используемой в другом центре данных (в нашем примере это будет 192.168.2.0/24).

Рисунок 8: Сворачивание сетей MAPI

Когда все готово, нажимаем 'OK', чтобы закрыть страницу свойств 'DAGNetwork01'.

Затем повторяем вышеописанные шаги для сетей репликации. Открываем страницу свойств сети 'DAGNetwork02' и добавляем подсеть сети репликации другого центра данных (рисунок 9).

Рисунок 9: Сворачивание сетей репликации

Вышеописанные шаги автоматически удалят сети 'DAGNetwork03' и 'DAGNetwork04' и вы увидите то, что показано на рисунке 10.

Рисунок 10: Неиспользуемые сети DAG

Поскольку 'DAGNetwork03' и 'DAGNetwork04' больше не используются, мы можем удалить их, нажав правой клавишей на каждой из них и выбрав опцию 'Удалить (Delete)' в контекстном меню (рисунок 11).

Рисунок 11: Удаление неиспользуемых сетей DAG

Теперь давайте переименуем две оставшиеся сети DAG, чтобы было проще отличить сеть MAPI от сети репликации. Для переименования сети DAG просто открываем страницу свойств и вводим новое имя сети, после чего жмем 'OK'.

Лично я люблю использовать следующие стандарты именования сетей DAG:

Сеть MAPI: DAG_name ' MAPI Network

Сеть репликации: DAG_name ' Replication Network

Это означает, что сети DAG будут называться 'DAG01 ' MAPI Network' и 'DAG01 ' Replication Network' соответственно, как показано на рисунке 12 и 13.

Рисунок 12: Переименование сети MAPI

Рисунок 13: Переименование сети репликации

Как вы видите на рисунке 14, это обеспечивает менее сложную визуальную репрезентацию сетей DAG.

Рисунок 14: Сворачивание и переименование сетей DAG

Добавление копий баз почтовых ящиков

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

Для этой цели мы могли бы воспользоваться консолью управления Exchange Management Console, но поскольку у нас есть четыре сервера-участника DAG и двенадцать баз почтовых ящиков, гораздо быстрее сделать это с помощью оболочки Exchange Management Shell. В настоящее время у нас есть копия базы почтовых ящиков на EX01. Для добавления копии каждой базы данных на серверы EX02, EX03 и EX04, мы воспользуемся командой Add-MailboxDatabaseCopy.

Базы данных почтовых ящиков с 1 по 6:

Для добавления копии баз почтовых ящиков с 1 по 6 на сервер 'EX03', мы используем следующую команду:

Add-MailboxDatabaseCopy DAG01-MDB001 -MailboxServer EX03 'ActivationPreference 2

Рисунок 15: Добавление копий баз почтовых ящиков

Для сервера 'EX02' используем команду:

Add-MailboxDatabaseCopy DAG01-MDB001 -MailboxServer EX02 'ActivationPreference 3

Для сервера 'EX04' используем:

Add-MailboxDatabaseCopy DAG01-MDB001 -MailboxServer EX04 'ActivationPreference 4

Базы данных почтовых ящиков с 7 по 12:

Для баз почтовых ящиков с 7 по 12 нам нужно задать сервер 'EX03' с предпочтением активации в '1' и 'EX01' с предпочтением в '2', чтобы активные копии баз данных перераспределялись между двумя серверами Exchange 2010 в основном центре данных. Мы сделаем это в следующем разделе.

Когда все готово, список копий баз данных должен выглядеть следующим образом для баз с 1 по 6:

Рисунок 16: Список предпочтений активации для баз почтовых ящиков с 1 по 6

Для баз с 7 по 12 список должен выглядеть, как показано на рисунке 17 ниже:

Рисунок 17: Список предпочтений активации для баз почтовых ящиков с 7 по 12

Обратите внимание на предпочтения активации для каждой копии базы данных. Копии баз данных в основном центре данных имеют предпочтение активации 1 и 2. Две копии базы данных в аварийном центре данных имеют предпочтения активации 3 и 4.

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

Когда active manager определяет, какую копию активировать, он смотрит не только на номер предпочтения, он также анализирует несколько других параметров, таких как политика активации копий баз данных, очередь копий, длина очереди преобразования и состояние индекса содержимого. Подробное объяснение процесса выбора копии не входит в рамки этого цикла статей, однако эта тема подробно раскрыта в Exchange 2010 documentation on TechNet.

Перераспределение активных копий баз данных

В настоящее время все активные копии баз данных хранятся на сервере 'EX01' в основном центре данных. Поскольку в основном центре данных у нас есть два сервера, нам нужно перераспределить активные копии баз данных так, чтобы 50% (базы данных с 1 по 6) хранилось на сервере 'EX01' и 50% (базы данных с 7 по 12) хранилось на сервере 'EX02'. В Exchange 2010 SP1 был добавлен сценарий под названием 'RedistributeActiveDatabases.ps1', который поможет нам перераспределить базы данных между серверами группы DAG на основе номера предпочтения активации, настроенного для каждого члена группы DAG.

Для запуска сценария нужно воспользоваться следующей командой из каталога сценариев Exchange (C:\Program Files\Microsoft\Exchange Server\V14\Scripts):

RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference 'ShowFinalDatabaseDistribution 'Confim:$false

При выполнении команды мы сначала получим обзор имеющихся сайтов AD и мест текущего хранения активных копий баз данных. Затем сценарий начнет перемещение активных копий баз данных на основе номеров предпочтения активации, настроенных для каждой базы почтовых ящиков (рисунок 18).

Рисунок 18: Перераспределение активных копий баз данных с помощью сценария RedistributeActiveDatabases.ps1

После перемещения активных копий баз данных сценарий предоставит нам обзор нового распределения копий баз данных.

Рисунок 19: Отчет о распределении активных копий баз данных

Включение режима координации активации баз данных (Database Activation Coordination Mode - DAC)

При настройке групп DAG с несколькими центрами данных рекомендуется включать режим координации активации баз данных (DAC) для группы DAG. DAC представляет собой специальное свойство DAG, защищающее группу DAG от так называемого синдрома разделения мозга. В случае возникновения аварийной ситуации в основном центре данных и падения двух серверов Exchange 2010, а также имеющегося здесь сервера-свидетеля, нам нужно будет выполнить ряд шагов по восстановлению службы в аварийном центре данных. Одним из шагов будет повторная настройка группы DAG для подключения баз данных в аварийном центре данных, поскольку здесь нам нужно получить кворум. В данном конкретном сценарии во время отказа основной центр данных имеет кворум, так как у нас есть два участника DAG и сервер-свидетель (в отличие от двух участников группы DAG в аварийном центре данных).

Примечание: Мы рассмотрим шаги восстановления в следующих частях этого цикла статей.

Давайте представим, что в аварийном центре данных у нас есть подключенная база данных, и что мы восстановили рабочее состояние серверов в основном центре данных. Обычно серверы приводятся в рабочее состояние до того, как восстанавливается сетевое подключение между центрами данных. В такой ситуации active manager в основном центре данных будет считать, что у него есть кворум, и будет пытаться подключить локальные базы данных. Это означает, что, в конечном счете, мы окажемся в ситуации, где у нас будут подключены базы данных в обоих центрах данных (синдром разделения мозга), в результате чего возникнет разногласие, которого нам, конечно же, нужно избежать любыми способами.

Именно здесь на помощь приходит DAC. При включенном режиме DAC, когда служба active manager запускается на участнике группы DAG, она может взаимодействовать (посылать пакеты пульса) со всеми другими участниками группы DAG по протоколу, известному под названием Datacenter Activation Coordination protocol (DACP). Подробности логики, используемой DAC, не входят в рамки этой статьи, но этот процесс хорошо описан в Exchange 2010 TechNet документации, но, говоря простым языком, когда DAC включен для группы DAG, служба active manager на каждом участнике DAG будет хранить бит/флаг в памяти, который используется для разрешения или запрещения подключения локальных баз данных на сервере. Бит/флаг может принимать значение '0' или '1', и он всегда будет иметь значение '0' при запуске active manager. Если active manager на участнике группы DAG может взаимодействовать со всеми другими участниками DAG и один из них сообщает, что его бит/флаг имеет значение '1', то участнику DAG, на котором запускается active manager, разрешается подключать локальные базы данных. Если сетевое подключение между центрами данных не восстановлено, участники DAG, восстановленные в основном центре данных, не смогут взаимодействовать с участниками DAG в аварийном центре данных, и поэтому они не подключают локальные базы данных. Проблема синдрома разделения мозга решена!

По умолчанию DAC режим отключен ('off'). Его состояние можно посмотреть с помощью команды:

Get-DatabaseAvailabiltyGroup DAG01 | fl

Рисунок 20: DAC отключен для группы DAG по умолчанию

Включение DAC – это простой процесс. Просто выполняете следующую команду:

Set-DatabaseAvailabilityGroup DAG01 'DatacenterActivationMode DagOnly

Рисунок 21: Включение координации активации баз данных

Настройка межсайтового RPC Client Access для DAG

Некоторые из вас, возможно, читали о новом свойстве DAG под названием 'AllowCrossSiteRpcClientAccess', которое было представлено в Exchange 2010 SP1. Задачей этого свойства было позволить администраторам Exchange настраивать поведение межсайтового RPC Client Access.

Необходимо, однако, отметить, что, несмотря на то, что вы можете посмотреть это свойство, выполнив команду 'Get-DatabaseAvailabilityGroup', и даже изменить параметр по умолчанию 'False' на 'True', оно не оказывает никакого влияния на общее поведение DAG. Причина в том, что команда Exchange решила вырезать эту возможность перед самым выходом версии Exchange 2010 SP1 в RTM.

Рисунок 22: Свойство AllowCrossSiteRpcClientAccess

Говоря другими словами, не тратьте свое время на это свойство.

На этом завершаем 7 часть данного цикла статей. В следующей части мы подробнее рассмотрим то, как настраивать роль сервера Hub Transport для получения полной избыточности на транспортном уровне.