Поделиться через

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

  • Статья

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

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

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

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

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

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

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

Группы доступности баз данных используют подмножество технологий отработки отказа Windows кластеризация в Windows Server 2008 R2 или более поздних версий, таких как пульс кластера, сети кластера и база данных кластера (для хранения данных, которые изменяются или могут быстро изменяться, например изменение состояния базы данных с активного на пассивное или обратное, с подключенного к отключенному или обратному). Таким образом, группы доступности доступности можно создавать только на серверах почтовых ящиков Exchange, установленных в поддерживаемых версиях Windows, включающих отработку отказа Windows кластеризация.

Примечание.

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

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

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

Примечание.

В топологии зеркального отображения базы данных можно использовать третий сервер под названием "следящий сервер". Следящий сервер включает автоматическую отработку отказа с субъекта на сервер зеркало или наоборот. В отличие от основного и зеркало серверов, сервер-свидетель не обслуживает базу данных. Роль следящего сервера заключается в том, чтобы проверить, работает ли данный сервер-партнер. Поддержка автоматической отработки отказа является единственной функцией для следящего сервера и определяет, на каком сервере хранится копия субъекта, а на каком — зеркало копия базы данных.

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

  • Следящий сервер не должен быть членом группы DAG.

  • Следящий сервер должен располагаться в том же лесу Active Directory, что и группа DAG.

  • Следящий сервер должен работать под управлением Windows Server 2008 или более поздней версии.

  • Один сервер может быть следящим сервером для нескольких групп DAG. Однако для каждой группы DAG требуется собственный следящий каталог.

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

Важно!

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

При создании 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. Если указать следящий сервер, но не следящий каталог, появляется следующее сообщение об ошибке:

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

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

Unable to access file shares on witness server '<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. Error: The network path was not found.

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

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<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. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

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

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

  • Включите исключение WMI в брандмауэре Windows.

  • Отключите брандмауэр Windows.

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

После создания daG можно добавлять серверы в daG или удалять их из нее с помощью мастера управления группой доступности базы данных в EAC или командлетов Add-DatabaseAvailabilityGroupServer или Remove-DatabaseAvailabilityGroupServer в командной консоли Exchange. Подробные инструкции по управлению членством в 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.

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

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

Предостережение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сетевое шифрование — это свойство daG, а не сети DAG. Вы можете настроить шифрование сети DAG с помощью командлета Set-DatabaseAvailabilityGroup в командной консоли Exchange. Возможные параметры шифрования для сетевых подключений DAG приведены в следующей таблице:

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

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

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

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

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

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

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

Примечание.

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

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

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

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

Для настройки свойств сети 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. В командной консоли Exchange используйте параметр 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 для непрерывной репликации. Возврат к 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.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, имеют несколько свойств, относящихся к обеспечению высокого уровня доступности, которые необходимо настроить, как описано в следующих разделах.

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

Параметр 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, необходимо сначала перевести этого сервера в режим обслуживания. Следующие скрипты предоставляются с Exchange Server для помощи в процедурах обслуживания DAG:

  • StartDagServerMaintenance.ps1. Помогает перемещать все активные базы данных с сервера. Он также перемещает все критически важные функции поддержки DAG, такие как роль основного активного диспетчера (PAM), и блокирует их перемещение обратно на сервер до завершения обслуживания.

  • StopDagServerMaintenance.ps1: помогает вывести член DAG из режима обслуживания и сделать его активным целевым объектом для всех баз данных и всех критически важных функций поддержки DAG.

Оба приведенных выше скрипта принимают параметр ServerName (который может быть именем узла или полным доменным именем (FQDN) члена DAG) и параметры WhatIf . Оба сценария можно выполнять локально или удаленно. На сервере, на котором выполняются сценарии, должны быть установлены средства управления отказоустойчивым кластером Windows (RSAT-Clustering).

Примечание.

Также доступен скрипт RedistributeActiveDatabases.ps1 , который помогает подключать базы данных почтовых ящиков к определенным членам DAG, как указано в номере предпочтения активации для каждой базы данных. Однако в Exchange 2016 с накопительным пакетом обновления 2 (CU2) или более поздней версии новое свойство DAG с именем PreferenceMoveFrequency автоматически распределяет копии базы данных по daG. Поэтому вам потребуется использовать RedistributeActiveDatabases.ps1 скрипт, только если вы отключили эту функцию или хотите сбалансировать копии базы данных вручную.

Скрипт StartDagServerMaintenance.ps1 выполняет следующие задачи:

  • Задает для параметра DatabaseCopyAutoActivationPolicy в члене BlockedDAG значение , что предотвращает активацию любых копий базы данных на сервере.

  • Приостанавливает работу узла в кластере, что не позволяет этому узлу быть (или становиться) основным диспетчером Active Manager (PAM).

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

  • Если в данный момент член группы DAG владеет кластерной группой по умолчанию, сценарий переместит ее (и роль PAM) на другой сервер-член группы DAG.

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

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

  1. Чтобы очистить очереди транспорта, выполните следующую команду:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Чтобы инициировать очистку транспортных очередей, выполните следующую команду:

    Restart-Service MSExchangeTransport

  3. Чтобы начать процесс очистки всех вызовов единой системы обмена сообщениями (только в Exchange 2016), выполните следующую команду:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Чтобы получить доступ к сценариям обслуживания DAG, выполните следующую команду:

    CD $ExScripts

  5. Чтобы запустить скрипт StartDagServerMaintenance.ps1 , выполните следующую команду:

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    Для значения параметра MoveComment можно сделать любую нотацию. В приведенном выше примере используется "Обслуживание".

    Примечание.

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

  6. Чтобы перенаправить сообщения, ожидающие доставки в локальных очередях, на сервер Exchange Server, указанный параметром Target, выполните следующую команду:

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

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

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

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

  1. Чтобы убедиться, что сервер переведен в режим обслуживания, убедитесь, что только Monitoring и RecoveryActionsEnabled находятся в активном состоянии при выполнении следующей команды:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

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

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

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

    Get-ClusterNode <ServerName> | Format-List

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

    Get-Queue

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

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

  • Задает для параметра DatabaseCopyAutoActivationPolicy в члене UnrestrictedDAG значение .

  • Запускает командлет Resume-MailboxDatabaseCopy для каждой копии базы данных, размещенной на сервере-члене группы DAG.

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

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

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  2. Чтобы разрешить серверу принимать вызовы единой системы обмена сообщениями (только в Exchange 2016), выполните следующую команду:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. Чтобы получить доступ к сценариям обслуживания DAG, выполните следующую команду:

    CD $ExScripts

  4. Чтобы выполнить скрипт StopDagServerMaintenance.ps1 , выполните следующую команду:

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

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

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. Чтобы возобновить работу транспорта, выполните следующую команду:

    Restart-Service MSExchangeTransport

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

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

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

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

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

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

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

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

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

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

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

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

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

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

Дополнительные сведения о последних обновлениях Exchange см. в разделе Exchange Server номера сборки и даты выпуска.

Примечание.

Всегда следует запускать все члены DAG в одной и той же версии Exchange Server (включая накопительные обновления и обновления для системы безопасности). Выполните последовательное обновление всех членов DAG и не запускайте daG с участниками в другой версии Exchange в течение длительного времени.