Управление группами обеспечения доступности баз данных

  • Статья

Область применения: Exchange Server 2013 г.

Группа обеспечения доступности баз данных (DAG) — это набор из не более 16 серверов почтовых ящиков Microsoft Exchange Server 2013, которые обеспечивают автоматическое восстановление на уровне базы данных в случае сбоя базы данных, сервера или сети. В группах DAG используется непрерывная репликация и подмножество технологий отказоустойчивых кластеров Windows, чтобы обеспечить высокий уровень доступности и устойчивость сайта. Почтовые серверы в группе доступности базы данных отслеживают сбои в работе друг друга. Добавленный в эту группу сервер почтовых ящиков работает вместе с другими серверами DAG, что обеспечивает автоматическое восстановление на уровне базы данных после возникновения ошибок в ней.

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

Создание групп обеспечения доступности баз данных

DaG можно создать с помощью мастера создания группы доступности баз данных в Центре администрирования Exchange (EAC) или с помощью командлета New-DatabaseAvailabilityGroup в командной консоли Exchange. При создании группы обеспечения доступности базы данных необходимо указать ее имя, а также необязательные параметры следящего сервера и следящего каталога. Кроме того, группе можно назначить один или несколько IP-адресов, используя статические IP-адреса или разрешив группе автоматически получить необходимые IP-адреса с помощью протокола DHCP. IP-адреса можно назначить группе daG вручную с помощью параметра DatabaseAvailabilityGroupIpAddresses . Если этот параметр не указан, группа попытается получить IP-адрес с помощью DHCP-сервера в сети.

Если вы создаете группу обеспечения доступности баз данных, которая содержит серверы почтовых ящиков, работающих под управлением Windows Server 2012 R2, у вас также есть возможность создания группы обеспечения доступности баз данных без точки административного доступа кластера. В этом случае у кластера не будет объекта имени кластера (CNO) в Active Directory, а группа основных ресурсов кластера будет без ресурса сетевого имени или ресурса IP-адреса.

Дополнительные сведения о создании группы обеспечения доступности баз данных см. в разделе Создание группы обеспечения доступности баз данных.

При создании группы обеспечения доступности баз данных в службах Active Directory создается пустой объект, представляющий группу доступности с указанным именем, и класс объекта msExchMDBAvailabilityGroup.

В DAG используется подмножество технологий отказоустойчивых кластеров Windows, таких как пульс кластера, сети кластеров и база данных кластер (для хранения данных, которые могут быстро изменяться, например, при изменении состояния базы данных из активного на пассивное или наоборот, либо с подключенного на отключенное или наоборот). Поскольку группы DAG опираются на отказоустойчивую кластеризацию Windows, их можно создавать только на серверах почтовых ящиков Exchange 2013 в системе Windows Server 2008 R2 Enterprise или DataCenter, Windows Server 2012 DataCenter или Standard либо Windows Server 2012 R2 Standard или Datacenter.

Примечание.

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

Следящий сервер и следящий каталог группы обеспечения доступности баз данных

При создании группы обеспечения доступности базы данных необходимо указать ее имя (не более 15 символов), которое является уникальным в пределах леса Active Directory. Кроме того, настраивается каждая группа доступности с помощью следящего сервера и следящего каталога. Следящий сервер и каталог на нем используются только в том случае, если в группе DAG четное число членов, и только в целях формирования кворума. Нет необходимости заранее создавать следящий каталог. Он будет автоматически создан и защищен системой Exchange на следящем сервере. Каталог не должен использоваться ни для каких других целей, кроме следящего сервера группы обеспечения доступности базы данных.

Для следящего сервера существуют следующие требования:

  • Следящий сервер не должен быть членом группы DAG.
  • Следящий сервер должен располагаться в том же лесу Active Directory, что и группа DAG.
  • Следящий сервер должен работать под управлением поддерживаемой версии Windows Server. Дополнительные сведения см. в статье Требования к системе Для Exchange 2013.
  • Один сервер может быть следящим сервером для нескольких групп DAG. Однако для каждой группы DAG требуется собственный следящий каталог.

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

Важно!

Если указанный следящий сервер не является сервером Exchange 2013 или Exchange 2010, перед созданием группы обеспечения доступности баз данных следует добавить универсальную группу безопасности доверенной подсистемы Exchange к локальной группе администраторов на следящем сервере. Эти разрешения безопасности необходимы для создания каталога и файлового ресурса на следящем сервере в приложении Exchange.

Следящий сервер использует SMB-порт 445.

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

Примечание.

Если следящий сервер утратил свое хранилище или кто-либо изменил следящий каталог или разрешения для общего ресурса, для настройки следящего сервера и следящего каталога в исходном расположении можно использовать командлет Set-DatabaseAvailabilityGroup.

Варианты размещения следящего сервера

Размещение следящего сервера группы обеспечения доступности баз данных зависит от требований компании и вариантов, доступных в организации. Exchange 2013 включает поддержку новых параметров конфигурации группы обеспечения доступности баз данных, нерекомендованных или недоступных в предыдущих версиях Exchange. Такие параметры включают использование третьего расположения, например третьего центра обработки данных, филиала или виртуальной сети Microsoft Azure.

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

Сценарий развертывания Рекомендации
Один сервер DAG, развернутый в одном центре обработки данных. Удаленный следящий сервер в том же центре обработки данных, в котором находятся члены DAG
Одна DAG, развернутая для двух центров обработки данных; другие расположения недоступны Расположите следящий сервер в виртуальной сети Microsoft Azure для автоматической отработки отказа центра данных. Или

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

Расположите следящий сервер в центре обработки данных, являющемся главным для каждой DAG. Доступны следующие дополнительные параметры.
  • Использование одного следящего сервера для нескольких DAG
  • Использование члена DAG в качестве следящего сервера для другой DAG
Одна или несколько DAG, развернутых для более чем двух центров обработки данных В данной конфигурации следящий сервер может быть расположен в центре обработки данных, в котором требуется разместить большую часть голосов кворума.

При развертывании DAG в двух центрах обработки данных новый вариант конфигурации в Exchange 2013 заключается в использовании третьего расположения для размещения следящего сервера. Если в вашей организации есть третье расположение с сетевой инфраструктурой, изолированной от сетевых сбоев, влияющих на два центра обработки данных, в которых развернута группа доступности баз данных, можно развернуть следящий сервер DAG в этом третьем расположении, тем самым настроив daG возможность автоматической отработки отказа баз данных в другой центр обработки данных в ответ на событие сбоя на уровне центра обработки данных. Если в вашей организации два физических местоположения, вы можете использовать виртуальную сеть Microsoft Azure как третье расположение для размещения следящего сервера.

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

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

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

  • Можно указать только имя для DAG и оставить поля Следящий сервер и каталог свидетеля пустыми. В этом сценарии мастер выполняет поиск на локальном сайте Active Directory сервера клиентского доступа, на котором не установлен сервер почтовых ящиков, и автоматически создает каталог по умолчанию (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) и общую папку по умолчанию (<DAGFQDN>) на этом сервере и использует этот сервер клиентского доступа в качестве следящего сервера. Например, рассмотрим следящий сервер CAS3, на котором установлена операционная система на диск C. DaG с именем DAG1 в домене contoso.com будет использовать каталог-свидетель по умолчанию C:\DAGFileShareWitnesses\DAG1.contoso.com, который будет использоваться как \\CAS3\DAG1.contoso.com.

  • Пользователь может указать имя для группы обеспечения доступности баз данных, для используемого следящего сервера, а также для каталога, созданного и открытого для совместного доступа на следящем сервере.

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

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

После формирования группы обеспечения доступности баз данных в ней первоначально используется модель кворума "Большинство узлов". После добавления второго сервера почтовых ящиков в группу обеспечения доступности баз данных кворум автоматически меняется на модель кворума "Большинство сайтов и общих файловых ресурсов". После этих изменений кластер группы обеспечения доступности баз данных будет использовать следящий сервер для сохранения кворума. Если следящего каталога не существует, сервер Exchange автоматически создаст его, включит для него общий доступ и предоставит для общего ресурса разрешения на полный доступ для учетной записи компьютера сетевого объекта кластера (CNO) в группе доступности баз данных.

Примечание.

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

Если брандмауэр Windows включен на следящем сервере до создания группы обеспечения доступности баз данных, он может блокировать ее создание. Сервер Exchange использует инструментарий управления Windows (WMI) для создания каталога и общего файлового ресурса на следящем сервере. Если брандмауэр Windows включен на следящем сервере и для инструментария управления Windows не настроены исключения брандмауэра, произойдет сбой командлета New-DatabaseAvailabilityGroup. Если указан следящий сервер, а не следящий каталог, отобразится следующее сообщение об ошибке:

| Задаче не удалось создать каталог следящего сервера по умолчанию на <сервере Имя> сервера. Вручную укажите следящий каталог.|

Если указаны следящий сервер и следящий каталог, отобразится следующее предупреждение:

| Не удается получить доступ к общим папкам на сервере-свидетеле ServerName. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Ошибка: не найден сетевой путь.|

Если брандмауэр Windows включен на следящем сервере после создания группы обеспечения доступности баз данных, но перед добавлением серверов, он может блокировать добавление или удаление членов группы обеспечения доступности баз данных. Если брандмауэр Windows включен на следящем сервере и для инструментария управления Windows не настроены исключения брандмауэра, командлет Add-DatabaseAvailabilityGroupServer вернет следующее предупреждение:

| Не удалось создать каталог-следитель общей папки "C:\DAGFileShareWitnesses\DAG_FQDN" на сервере-свидетеле ServerName. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Ошибка: произошло исключение WMI на сервере ServerName: сервер RPC недоступен. (Исключение из HRESULT: 0x800706BA)|

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

  • Вручную создайте следящий каталог и общий ресурс на следящем сервере и назначьте для них разрешения на полный доступ для объекта CNO в группе DAG.
  • Включите исключение WMI в брандмауэре Windows.
  • Отключите брандмауэр Windows.

Членство в группы обеспечения доступности базы данных

После создания группы обеспечения доступности баз данных в нее можно добавлять или удалять из нее серверы с помощью мастера управления группами обеспечения доступности баз данных в центре администрирования Exchange или с помощью командлетов Add-DatabaseAvailabilityGroupServer или Remove-DatabaseAvailabilityGroupServer в командной консоли. Подробные инструкции по управлению членством в DAG см. в разделе Управление членством в группе доступности базы данных.

Примечание.

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

Если на сервере почтовых ящиков, добавляемом в группу обеспечения доступности баз данных, не установлен компонент отказоустойчивой кластеризации, то с помощью метода, используемого для добавления сервера (например, командлета Add-DatabaseAvailabilityGroupServer или мастера управления группами обеспечения доступности баз данных), будет установлено средство отказоустойчивой кластеризации.

При добавлении первого сервера почтовых ящиков в daG выполняются следующие действия:

  • Устанавливается компонент отказоустойчивости кластера Windows, если он еще не установлен.
  • Создается отказоустойчивый кластер с помощью имени группы DAG. Отказоустойчивый кластер используется только группой DAG и должен быть выделен для этой группы. Использование кластера в других целях не поддерживается.
  • Создается объект CNO в контейнере компьютеров по умолчанию.
  • Регистрируется имя и IP-адрес группы обеспечения доступности баз данных в качестве записи узла (A) в службе DNS.
  • Добавляется сервер к объекту DAG в Active Directory.
  • Обновляется база данных кластера информацией о базах данных, установленных на добавленный сервер.

В крупных средах или средах с несколькими сайтами, особенно в которых группа DAG расширена на несколько сайтов Active Directory, необходимо дождаться завершения репликации Active Directory объекта DAG, содержащего первый член группы DAG. Если этот объект Active Directory не реплицирован во всей среде, при добавлении второго сервера может быть создан новый кластер (и новый объект CNO) для группы DAG. Это происходит потому, что объект DAG является пустым с точки зрения второго добавляемого сервера, в результате чего командлет Add-DatabaseAvailabilityGroupServer создает новый кластер и объект CNO для группы DAG, даже если эти объекты уже существуют. Чтобы убедиться, что объект DAG, содержащий первый сервер DAG, реплицирован, используйте командлет Get-DatabaseAvailabilityGroup на втором добавляемом сервере, чтобы проверить, что первый добавленный сервер включен в список членов группы обеспечения доступности баз данных.

При добавлении второго и последующих серверов в DAG выполняются следующие действия:

  • Сервер присоединяется к отказоустойчивому кластеру Windows для группы DAG.
  • Автоматически настраивается модель кворума:
    • Используется модель кворума "Большинство узлов" для групп DAG с нечетным количеством участников.
    • Используется модель кворума "Большинство узлов и общих файловых ресурсов" для групп DAG с четным количеством участников.
  • При необходимости Exchange автоматически создает следящий каталог и общий ресурс.
  • Добавляется сервер к объекту DAG в Active Directory.
  • Обновляется база данных кластера информацией об установленных базах данных.

Примечание.

Автоматически меняется модель кворума. Однако если модель кворума не меняется автоматически на правильную модель, можно запустить командлет Set-DatabaseAvailabilityGroup только с параметром Identity, чтобы исправить параметры кворума для группы обеспечения доступности базы данных.

Регистрация объекта имени кластера для группы DAG

Объект имени кластера — это учетная запись компьютера, создаваемая в службе Active Directory и связываемая с ресурсом имени кластера. Ресурс имени кластера связан с объектом имени кластера, который является объектом с включенной поддержкой Kerberos, действующим как идентификатор кластера и обеспечивающим контекст безопасности кластера. Формирование базового кластера группы обеспечения доступности баз данных и объекта CNO для этого кластера выполняется при добавлении первого члена в группу DAG. После добавления первого сервера в группу DAG удаленная среда Powershell подключается к службе репликации Microsoft Exchange на добавляемом сервере почтовых ящиков. Служба репликации Microsoft Exchange устанавливает средство отказоустойчивой кластеризации (если оно не установлено) и запускает процесс создания кластера. Служба репликации Microsoft Exchange работает в контексте безопасности LOCAL SYSTEM, и создание кластера выполняется в этом контексте.

Предупреждение

Если члены группы обеспечения доступности баз данных используют Windows Server 2012, необходимо подготовить объект CNO до добавления первого сервера в группу DAG. Если члены группы обеспечения доступности баз данных используют Windows Server 2012 R2, и она создана без точки административного доступа кластера, объект CNO не создается, и создавать объект CNO для группы обеспечения доступности баз данных не требуется.

В средах, в которых создание учетной записи компьютера ограничено или учетные записи компьютеров создаются в контейнере, отличном от контейнера компьютеров по умолчанию, необходимо зарегистрировать и подготовить объект CNO. Пользователь создает и отключает учетную запись компьютера для объекта CNO, а затем выполняет одно из следующих действий.

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

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

Дополнительные сведения о регистрации и подготовке объекта CNO для группы обеспечения доступности баз данных см. в разделе Регистрация объекта имени кластера для группы обеспечения доступности баз данных.

Удаление серверов из DAG

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

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

  • Выполнение операции восстановления сервера. Если сервер почтовых ящиков, который является членом DAG, потерян или иным образом завершается сбоем и не восстанавливается и требует замены, можно выполнить операцию восстановления сервера с помощью параметра Setup /m:RecoverServer . Однако перед выполнением операции восстановления необходимо сначала удалить сервер из DAG с помощью командлета Remove-DatabaseAvailabilityGroupServer с параметром ConfigurationOnly .

  • Удаление группы доступности базы данных. Могут возникнуть ситуации, в которых необходимо удалить DAG (например, при отключении режима репликации сторонних производителей). Перед удалением группы DAG необходимо сначала удалить из нее все серверы. Попытка удаления группы DAG, содержащей члены, завершится неудачей.

Настройка свойств DAG

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

Настраиваемые свойства включают в себя следующее:

  • Сервер-свидетель. Имя сервера, на котором вы хотите разместить общую папку для общей папки-свидетеля. Мы рекомендуем указать сервер клиентского доступа в качестве следящего сервера. Это позволяет системе автоматически формировать, защищать и использовать общий ресурс по мере необходимости, а также позволяет администратору контролировать доступность следящего сервера.

  • Следящий каталог. Имя каталога, который будет использоваться для хранения данных следящего файла общей папки. Этот каталог будет автоматически создан системой на указанном следящем сервере.

  • IP-адреса группы доступности базы данных. Группе доступности необходимо назначить один или несколько IP-адресов, если только члены группы daG не работают Windows Server 2012 R2 и вы создаете группу daG без IP-адреса. В противном случае IP-адреса DAG можно настроить с помощью назначенных вручную статических IP-адресов или их можно автоматически назначить группе daG с помощью DHCP-сервера в вашей организации.

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

Дополнительные сведения о настройке свойств группы DAG см. в разделе Настройка свойств группы обеспечения доступности баз данных.

Шифрование в сети группы обеспечения доступности баз данных

DaG поддерживают использование шифрования, используя возможности шифрования операционной системы Windows Server. Группы доступности баз данных используют проверку подлинности Kerberos между серверами Exchange. API DecryptMessage и EncryptMessage поставщика поддержки безопасности (SSP) Microsoft Kerberos отвечают за шифрование сетевого трафика группы DAG. Поставщик поддержки безопасности Microsoft Kerberos поддерживает несколько алгоритмов шифрования. (Полный список см. в разделе 3.1.5.2, "Типы шифрования" расширений протокола Kerberos). При подтверждении проверки подлинности Kerberos выбирается самый надежный поддерживаемый протокол шифрования из указанных в списке: обычно стандарт AES с 256-разрядным ключом, возможно, вместе с кодом проверки подлинности сообщения на основе хэша (HMAC) по алгоритму SHA для сохранения целостности данных. Дополнительные сведения см. в разделе HMAC.

Шифрование в сети является свойством группы DAG, а не сети DAG. Настроить шифрование в сети DAG можно с помощью командлета Set-DatabaseAvailabilityGroup в командной консоли. Возможные параметры для установления связи в сети DAG показаны в следующей таблице.

Параметры шифрования связи в сети DAG

Setting Описание
Отключено Шифрование сети не используется.
Включено Шифрование в сети используется во всех сетях DAG для репликации и заполнения.
InterSubnetOnly Шифрование в сети используется в сетях DAG при репликации в разных подсетях. Это настройка по умолчанию.
SeedOnly Шифрование в сети используется во всех сетях DAG только для заполнения.

Сжатие в сети DAG

В группах DAG поддерживается встроенное сжатие. Если сжатие включено, при установлении связи в сети DAG используется сжатие XPRESS, которое является реализацией Microsoft для алгоритма LZ77. Дополнительные сведения см. в разделе Объяснение алгоритма deflate и в разделе 3.1.4.11.1.2.1 "Алгоритм сжатия LZ77" статьи Спецификация протокола формата провода. Это тот же тип сжатия, который используется во многих протоколах Майкрософт, в частности, в сжатии MAPI RPC между Microsoft Outlook и Exchange.

Как и шифрование в сети, сжатие в сети является свойством группы DAG, а не сети DAG. Сжатие в сети DAG можно настроить с помощью командлета Set-DatabaseAvailabilityGroup в командной консоли. Возможные параметры сжатия для установления связи в сети DAG показаны в следующей таблице.

Параметры сжатия для связи в сети DAG

Setting Описание
Отключено Сжатие в сети не используется.
Включен Сжатие в сети используется во всех сетях DAG для репликации и заполнения.
InterSubnetOnly Сжатие в сети используется в сетях DAG при репликации в разных подсетях. Это настройка по умолчанию.
SeedOnly Сжатие в сети используется во всех сетях DAG только для заполнения.

Сети групп обеспечения доступности баз данных

Сеть DAG — это коллекция из одной или нескольких подсетей, используемых либо для трафика репликации, либо для трафика MAPI. Каждая группа DAG содержит не более одной сети MAPI и 0 или более сетей репликации.

Конфигурации с одним сетевым адаптером

В конфигурациях с одним сетевым адаптером одна и та же сеть используется для трафика MAPI и репликации. Чтобы снизить сложность, один сетевой адаптер является рекомендуемой конфигурацией для серверов Exchange, поэтому можно использовать трафик MAPI и репликации в одной сети.

Конфигурации с двумя сетевыми адаптерами

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

В конфигурации с двумя сетевыми адаптерами одна сеть обычно выделяется для трафика репликации, а другая сеть в основном используется для трафика MAPI. Кроме того, вы можете добавить сетевые адаптеры для каждого члена группы DAG и настроить дополнительные сети DAG как сети репликации.

Примечание.

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

В Exchange 2010 во многих сценариях необходима ручная настройка сетей DAG. По умолчанию в Exchange 2013 сети DAG будут настроены автоматически системой. Перед созданием или изменением сетей DAG необходимо сначала включить ручное управление сетью DAG, выполнив следующую команду:

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

После включения ручной настройки сети DAG можно использовать командлет New-DatabaseAvailabilityGroupNetwork в командной консоли для создания сети группы обеспечения доступности баз данных. Подробные инструкции по созданию сети DAG см. в статье Создание сети группы доступности базы данных.

Можно использовать командлет Set-DatabaseAvailabilityGroupNetwork в командной консоли Exchange для настройки свойств сети группы обеспечения доступности базы данных. Подробные инструкции по настройке свойств сети DAG см. в разделе Настройка сетевых свойств группы доступности базы данных. В каждой сети DAG есть необходимые и дополнительные параметры для настройки:

  • Имя сети: уникальное имя для сети DAG из 128 символов.

  • Описание сети: необязательное описание для сети DAG длиной до 256 символов.

  • Сетевые подсети: одна или несколько подсетей, введенных в формате IPAddress/Bitmask (например, 192.168.1.0/24 для подсетей IPv4; 2001:DB8:0:C000::/64 для подсетей протокола IPv6).

  • Включить репликацию. В EAC установите флажок, чтобы посвятить сеть DAG трафику репликации и заблокировать трафик MAPI. Снимите флажок, чтобы запретить использование сети группы DAG для репликации и включить трафик MAPI. В оболочке используйте параметр ReplicationEnabled в командлете Set-DatabaseAvailabilityGroupNetwork , чтобы включить и отключить репликацию.

Примечание.

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

Начальные сети DAG (например, MapiDagNetwork и ReplicationDagNetwork01), создаваемые системой, основаны на подсетях службы кластеров. Каждый член группы DAG должен иметь идентичное количество сетевых адаптеров, а каждый сетевой адаптер должен иметь адрес IPv4 (а также, возможно, и адрес IPv6) в уникальной подсети. Несколько членов группы DAG могут иметь адреса IPv4 в одной подсети, но IP-адрес каждого сетевого адаптера определенного сервера группы DAG должен принадлежать уникальной подсети. Кроме того, шлюз по умолчанию должен использоваться только адаптером сети MAPI. Сети репликации не должны настраиваться на использование шлюза по умолчанию.

Например, рассмотрим группу DAG1 с двумя членами, каждый из которых имеет по два сетевых адаптера (один выделен для сети MAPI, а другой — для сети репликации). Примерные параметры конфигурации IP-адреса представлены в следующей таблице.

Пример настройки параметров сетевого адаптера

Плата "сервер-сеть" IP-адрес/маска подсети Шлюз по умолчанию
EX1-MAPI 192.168.1.15/24 192.168.1.1
EX1-Репликация 10.0.0.15/24 Неприменимо
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Репликация 10.0.0.16 Неприменимо

В следующей конфигурации группа DAG содержит две настроенные подсети: 192.168.1.0 и 10.0.0.0. При добавлении серверов EX1 и EX2 в группу DAG обе подсети будут пронумерованы и будет создано две сети DAG: MapiDagNetwork (192.168.1.0) и ReplicationDagNetwork01 (10.0.0.0). Эти сети будут настроены, как показано в следующей таблице.

Параметры нумерованных сетей DAG для группы DAG с одной подсетью

Имя Подсети Интерфейсы Доступ MAPI включен Репликация включена
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)

EX2 (192.168.1.16)		 Да Да
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)

EX2 (10.0.0.16)		 Нет Да

Чтобы завершить настройку Replicationdagnetwork01 в качестве выделенной сети репликации, отключите репликацию для MapiDagNetwork, выполнив следующую команду.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false

После отключения репликации для MapiDagNetwork служба репликации Microsoft Exchange использует ReplicationDagNetwork01 для непрерывной репликации. Если произойдет сбой ReplicationDagNetwork01, то служба репликации Microsoft Exchange вернется к использованию MapiDagNetwork для непрерывной репликации. Это преднамеренное действие системы для обеспечения высокого уровня доступности.

Развертывание нескольких подсетей и сетей группы обеспечения доступности баз данных

В предыдущем примере несмотря на использование в группе DAG двух различных подсетей (192.168.1.0 и 10.0.0.0) эта группа считается группой DAG с одной подсетью, потому что все члены группы используют одну подсеть для формирования сети MAPI. Когда члены группы DAG используют различные подсети для сети MAPI, такая группа называется группой DAG с несколькими подсетями. В группах DAG с несколькими подсетями соответствующие подсети будут автоматически назначаться каждой сети DAG.

Например, рассмотрим группу DAG2 с двумя членами, каждый из которых имеет по два сетевых адаптера (один выделен для сети MAPI, а другой — для сети репликации) и расположен на отдельном сайте Active Directory, а их сети MAPI находятся в различных подсетях. Примерные параметры конфигурации IP-адреса представлены в следующей таблице.

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

Адаптер "сервер-сеть" IP-адрес/маска подсети Шлюз по умолчанию
EX1-MAPI 192.168.0.15/24 192.168.0.1
EX1-Репликация 10.0.0.15/24 Неприменимо
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Репликация 10.0.1.15 Неприменимо

В следующей конфигурации в DAG настроены четыре подсети: 192.168.0.0, 192.168.1.0, 10.0.0.0 и 10.0.1.0. При добавлении EX1 и EX2 в DAG будут перечислены четыре подсети, но будут созданы только две сети DAG: MapiDagNetwork (192.168.0.0, 192.168.1.0) и ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Эти сети будут настроены, как показано в следующей таблице.

Параметры нумерованных сетей DAG для группы DAG с несколькими подсетями

Имя Подсети Интерфейсы Доступ MAPI включен Репликация включена
MapiDagNetwork 192.168.0.0/24

192.168.1.0/24		 EX1 (192.168.0.15)

EX2 (192.168.1.15)		 Да Да
ReplicationDagNetwork01 10.0.0.0/24

10.0.1.0/24		 EX1 (10.0.0.15)

EX2 (10.0.1.15)		 Нет Верно

Сети DAG и iSCSI

По умолчанию в группах DAG выполняется поиск всех сетей, обнаруженных и настроенных для использования с помощью базового кластера. При этом учитываются любые сети Internet SCSI (iSCSI), которые используются в результате применения хранилища iSCSI для одного или нескольких членов DAG. Рекомендуется использовать для хранилища iSCSI выделенные сети и сетевые адаптеры. Эти сети не должны управляться группами DAG и ее кластерами или использоваться в качестве сетей DAG (MAPI или репликация). Вместо этого для них необходимо вручную отключить использование группой DAG и выделить их для трафика хранилища iSCSI. Для отключения обнаружения и использования сетей iSCSI в качестве сетей DAG, настройте DAG так, чтобы игнорировать любые обнаруженные сети iSCSI, с помощью командлета Set-DatabaseAvailabilityGroupNetwork, как показано в следующем примере:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Эта команда также отключит использование сети кластером. Хотя сети iSCSI по-прежнему будут отображаться как сети DAG, они не будут использоваться для трафика репликации или MAPI после выполнения предыдущей команды.

Настройка членов DAG

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

  • Automatic database mount dial
  • Database copy automatic activation policy
  • Maximum active databases

Автоматическое подключение базы данных

Параметр AutoDatabaseMountDial определяет поведение при автоматическом подключении базы данных после отработки отказа базой данных. С помощью командлета Set-MailboxServer можно настроить параметр AutoDatabaseMountDial с любым из следующих значений:

  • BestAvailability: если указать это значение, база данных автоматически подключается сразу после отработки отказа, если длина очереди копирования меньше или равна 12. Длина очереди копирования — это число журналов, определяемых пассивной копией, для которых необходимо выполнить репликацию. Если значение длины очереди копирования превышает 12, база данных не будет подключаться автоматически. Если длина очереди копирования не превышает 12, Exchange попытается реплицировать оставшиеся журналы на пассивную копию и подключит базы данных.

  • GoodAvailability: если указать это значение, база данных автоматически подключается сразу после отработки отказа, если длина очереди копирования меньше или равна шести. Длина очереди копирования — это число журналов, определяемых пассивной копией, для которых необходимо выполнить репликацию. Если значение длины очереди копирования превышает 6, база данных не будет подключаться автоматически. Если длина очереди копирования не превышает 6, Exchange попытается реплицировать оставшиеся журналы на пассивную копию и подключит базу данных.

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

Значение по умолчанию — GoodAvailability. Если указать или BestAvailabilityGoodAvailability, а все журналы из активной копии не удастся скопировать в активируемую пассивную копию, вы можете потерять некоторые данные почтового ящика. Тем не менее, функция системы безопасности (которая включена по умолчанию) обеспечивает защиту от потери данных благодаря повторной отправке сообщений в очереди системы безопасности.

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

В следующем примере сервер почтовых ящиков настраивается с параметром GoodAvailabilityAutoDatabaseMountDial .

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

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

Параметр DatabaseCopyAutoActivationPolicy указывает тип автоматической активации, доступной для копий базы данных почтовых ящиков на выбранных серверах почтовых ящиков. С помощью командлета Set-MailboxServer можно настроить параметр DatabaseCopyAutoActivationPolicy с любым из следующих значений:

  • Blocked: если указать это значение, базы данных не могут быть автоматически активированы на выбранных серверах почтовых ящиков.

  • IntrasiteOnly: если указать это значение, копию базы данных можно активировать на серверах на том же сайте Active Directory. Это предотвращает отработку отказа или активацию между сайтами. Это свойство предназначено для входящих копий базы данных почтовых ящиков (например, пассивная копия становится активной). Базы данных не могут быть активированы на этом сервере почтовых ящиков для копий баз данных, которые активны на другом сайте Active Directory.

  • Unrestricted: если указать это значение, нет особых ограничений на активацию копий баз данных почтовых ящиков на выбранных серверах почтовых ящиков.

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

В следующем примере сервер почтовых ящиков настраивается с параметром BlockedDatabaseCopyAutoActivationPolicy .

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Максимальное количество активных баз данных

Параметр MaximumActiveDatabases (также используемый с командлетом Set-MailboxServer) указывает количество баз данных, которые можно подключить к серверу почтовых ящиков. Для соблюдения требований развертывания серверы почтовых ящиков можно настроить таким образом, чтобы не превышалась нагрузка на отдельные серверы почтовых ящиков.

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

Пример. Настройка максимального количества активных баз данных

В следующем примере показана настройка сервера почтовых ящиков для поддержки не более 20 активных баз данных.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Обслуживание участников DAG

Перед выполнением любого вида обслуживания программного или аппаратного обеспечения для члена группы DAG необходимо сначала перевести этого члена DAG в режим обслуживания. Это подразумевает перемещение всех активных баз данных с сервера и запрет на перемещение активных баз данных на сервер. Сценарий также обеспечивает перемещение всех важных средств поддержки группы DAG, находящихся на сервере (например, роль основного диспетчера Active Manager (PAM)), на другой сервер и блокирует их перемещение назад. В частности, не выполнять следующие задачи:

  1. Чтобы начать процесс очистки транспортных очередей, выполните команду Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Чтобы инициировать очистку транспортных очередей, выполните команду Restart-Service MSExchangeTransport

  3. Чтобы начать процесс очистки всех вызовов единой системы обмена сообщениями, выполните команду Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Чтобы перенаправить сообщения, ожидающие доставки в локальных очередях, на сервер почтовых ящиков, указанный параметром Target, выполните команду Redirect-Message -Server <ServerName> -Target <MailboxServerFQDN>

  5. Чтобы приостановить работу узла кластера, что не позволит узлу быть и стать PAM, выполните команду . Suspend-ClusterNode <ServerName>

  6. Чтобы переместить все активные базы данных, размещенные в элементе DAG, в другие члены DAG, выполните команду Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $True

  7. Чтобы предотвратить размещение на сервере активных копий базы данных, выполните команду Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Blocked

  8. Чтобы поместить сервер в режим обслуживания, выполните команду Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

Чтобы убедиться в готовности сервера к обслуживанию, выполните следующие задачи.

  1. Чтобы убедиться, что сервер переведен в режим обслуживания, выполните команду. Get-ServerComponentState <ServerName> | ft Component,State -Autosize

  2. Чтобы убедиться, что на сервере не размещены активные копии базы данных, выполните команду Get-MailboxServer <ServerName> | ft DatabaseCopy* -Autosize

  3. Чтобы убедиться, что узел приостановлен, выполните команду Get-ClusterNode <ServerName> | fl

  4. Чтобы убедиться, что все очереди транспорта были истощены, выполните команду Get-Queue

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

  • Чтобы указать, что сервер выходит из режима обслуживания, выполните команду Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  • Чтобы разрешить серверу принимать вызовы единой системы обмена сообщениями, выполните команду Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  • Чтобы возобновить работу узла в кластере и включить полную функциональность кластера для сервера, выполните команду Resume-ClusterNode <ServerName>

  • Чтобы разрешить базам данных стать активными на сервере, выполните команду Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $False

  • Чтобы удалить блоки автоматической активации, выполните команду Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Unrestricted

  • Чтобы включить очереди транспорта и разрешить серверу принимать и обрабатывать сообщения, выполните команду Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  • Чтобы возобновить транспортную деятельность, выполните команду Restart-Service MSExchangeTransport

Чтобы убедиться, что сервер готов к использованию в производственной среде, выполните следующие действия.

  • Чтобы убедиться, что сервер не находится в режиме обслуживания, выполните команду Get-ServerComponentState <ServerName> | ft Component,State -Autosize

  • Если вы устанавливаете обновление Exchange и процесс обновления завершается сбоем, некоторые серверные компоненты могут остаться в неактивном состоянии, которое будет отображаться в выходных данных приведенного выше командлета Get-ServerComponentState. Чтобы устранить эту проблему, выполните следующие команды:

    • Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional
    • Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional
    • Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Завершение работы участников группы обеспечения доступности базы данных

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

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

Установка обновлений на членах группы DAG

Установка обновлений Microsoft Exchange Server 2013 на сервере, который входит в группу обеспечения доступности баз данных, является относительно простым процессом. При установке накопительного пакета обновления на сервере, который является членом группы DAG, выполняется остановка нескольких служб, в том числе всех служб Exchange и службы кластеров. Общий процесс применения обновлений для участника группы DAG выглядит следующим образом.

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

  2. Установите обновление.

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

  4. Как вариант, можно с помощью сценария RedistributeActiveDatabases.ps1 выполнить балансировку активных копий баз данных в группе DAG.

Вы можете скачать последнее обновление для Exchange 2013 на веб-сайте Центра загрузки Майкрософт.