Развертывание высокого уровня доступности и устойчивости сайта в Exchange Server

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

Обзор процесса развертывания

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

  1. Создайте DAG. Дополнительные сведения см. в разделе Create a database availability group. Важно отметить, что все серверы в daG должны работать под управлением одной и той же версии Exchange. Например, нельзя смешивать серверы Exchange 2013 и Exchange 2016 в одной группе daG.

  2. При необходимости подготовьте объект имени кластера (CNO). При развертывании DAG с серверами почтовых ящиков под управлением Windows Server 2012 требуется предварительная промежуточная подготовка CNO. Если вы развертываете DAG без административной точки доступа с помощью серверов почтовых ящиков, работающих Windows Server 2012 R2, вам не нужно предварительно создавать CNO. Предварительная промежуточная подготовка также требуется в средах, где создание учетной записи компьютера ограничено или учетные записи компьютера создаются в контейнере, отличном от контейнера компьютеров по умолчанию. Дополнительные сведения см. в разделе Pre-stage the cluster name object for a database availability group.

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

  4. Настроить свойства группы DAG в соответствии с требованиями.

  5. При необходимости настройте шифрование и сжатие DAG, порт репликации, IP-адреса DAG и другие свойства DAG. Подробные инструкции см. в разделе Настройка свойств группы доступности базы данных.

  6. Включите режим координации активации центра обработки данных (DAC) для daG. Это защищает DAG от условий разделенного мозга на уровне базы данных во время переключения в основной центр обработки данных после переключения центра обработки данных и позволяет использовать встроенные командлеты восстановления DAG. Дополнительные сведения см. в разделе Режим координации активации центра обработки данных.

  7. Добавление копий базы данных почтовых ящиков между серверами почтовых ящиков в DAG. Дополнительные сведения см. в статье Add a mailbox database copy.

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

В этом примере описано, как организация Contoso, Ltd. настраивает и развертывает группу DAG из четырех участников, которая будет расширена в двух физических расположениях: Бостоне и Оклахома-Сити.

Базовая инфраструктура

Каждое расположение содержит элементы инфраструктуры, необходимые для работы инфраструктуры обмена сообщениями на основе Exchange Server, а именно:

  • Службы каталогов (доменные службы Active Directory или Active Directory (AD DS)).

  • Разрешение имени системы доменных имен (DNS).

  • Несколько серверов Exchange, на которых запущены службы клиентского доступа

  • Несколько серверов почтовых ящиков Exchange

На следующем рисунке показана конфигурация Contoso.

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

Конфигурация сети

Как показано на рисунке выше, решение включает в себя использование нескольких подсетей и нескольких сетей. Для каждого сервера почтовых ящиков в группе DAG предусмотрены сетевые адаптеры в различных сетях. На каждом сервере почтовых ящиков для сети MAPI (192.168) будет использоваться один сетевой адаптер. x. x) и один сетевой адаптер будет использоваться для сети репликации (10.0). x. x). Только сеть MAPI обеспечивает подключение к службам Active Directory, службам DNS, другим серверам и клиентам Exchange. Адаптер, используемый для сети репликации в каждом участнике, обеспечивает подключение только к адаптерам сети репликации в других участниках группы DAG.

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

Имя IPv4-адрес Маска подсети Шлюз по умолчанию
MBX1 (MAPI) 192.168.1.4 255.255.255.0 192.168.1.1
MBX2 (MAPI) 192.168.1.5 255.255.255.0 192.168.1.1
MBX3 (MAPI) 192.168.2.4 255.255.255.0 192.168.2.1
MBX4 (MAPI) 192.168.2.5 255.255.255.0 192.168.2.1
MBX1 (репликация) 10.0.1.4 255.255.255.0 Нет
MBX2 (репликация) 10.0.1.5 255.255.255.0 Нет
MBX3 (репликация) 10.0.2.4 255.255.255.0 Нет
MBX4 (репликация) 10.0.2.5 255.255.255.0 Нет

Как показано в таблице выше, адаптеры, используемые для сетей репликации, не используют шлюзы по умолчанию. Для обеспечения сетевого соединения между всеми сетевыми адаптерами репликации в компании Contoso используются постоянные статические маршруты, которые настраиваются с помощью средства Netsh.exe.

Для настройки маршрутизации для сетевых адаптеров репликации на MBX1 и MBX2 на каждом сервере была выполнена следующая команда.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Для настройки маршрутизации для сетевых адаптеров репликации на MBX3 и MBX4 на каждом сервере была выполнена следующая команда.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

Также были настроены следующие дополнительные параметры сети:

  • Флажок Зарегистрировать адреса этого подключения в DNS устанавливается для каждого сетевого адаптера MAPI члена группы обеспечения доступности базы данных и снимается для каждого сетевого адаптера репликации.

  • Для каждого сетевого адаптера MAPI члена группы DAG настраивается по меньшей мере один адрес DNS-сервера, а для сетевых адаптеров репликации такие адреса не задаются. В целях избыточности в Contoso используется несколько адресов сервера DNS для их адаптеров сети MAPI.

  • В Contoso брандмауэр Windows не используется, он отключен на серверах.

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

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

Администратор принял решение создать сценарий интерфейса командной строки Windows PowerShell, который выполняет несколько задач.

  • Для создания группы DAG он использует командлет New-DatabaseAvailabilityGroup. Так как boston считается основным центром обработки данных, компания Contoso решила использовать сервер-свидетель в том же центре обработки данных, а именно MBX5.

  • Компания использует командлет Set-DatabaseAvailabilityGroup для предварительной настройки альтернативного следящего сервера и каталога на случай необходимости переключения ЦОД.

  • Для добавления каждого из четырех серверов почтовых ящиков в группу DAG используется командлет Add-DatabaseAvailabilityGroupServer.

  • Для настройки DAG для режима DAC используется командлет Set-DatabaseAvailabilityGroup . Дополнительные сведения о режиме DAC см. в разделе Режим координации активации центра обработки данных.

Ниже приведены использованные в сценарии команды.

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MBX5 -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

Предыдущая команда создает DAG DAG1, настраивает MBX5 в качестве следящего сервера, настраивает конкретный следящий каталог (C:\DAGWitness\DAG1.contoso.com) и настраивает два IP-адреса для DAG (по одному для каждой подсети в сети MAPI).

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer MBX10

Предыдущая команда настраивает DAG1 для использования альтернативного следящего сервера MBX10 и альтернативного следящего каталога в MBX10, который использует тот же путь, который был настроен для MBX5.

Примечание.

Использование того же пути не требуется; в Contoso данное действие было выбрано для стандартизации их конфигурации.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4

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

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

Приведенная выше команда включает режим DAC для группы DAG.

Базы данных почтовых ящиков и копии базы данных почтовых ящиков

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

Такая конфигурация обеспечивает наличие четырех копий для каждой базы данных (одной активной, двух неизолированных пассивных и одной изолированной пассивной). В Contoso планируется наличие четырех активных баз данных для каждого сервера. Таким образом, решение Contoso содержит 16 копий базы данных.

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

Структура копии базы данных для Contoso, Ltd

Макет копирования базы данных для Contoso, Ltd, ключевые слова: высокий уровень доступности DAG Exchange.

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

Чтобы создать эту конфигурацию, администратор выполняет несколько команд.

На MBX1 выполните следующие команды.

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment "Seed from MBX4" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -ActivationOnly

На MBX2 выполните следующие команды.

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -SuspendComment "Seed from MBX3" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX4 -SourceServer MBX3
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -ActivationOnly

На MBX3 выполните следующие команды.

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -SuspendComment "Seed from MBX2" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1 -SourceServer MBX2
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -ActivationOnly

На MBX4 выполните следующие команды.

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -SuspendComment "Seed from MBX1" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2 -SourceServer MBX1
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -ActivationOnly

В предыдущих примерах для командлета Add-MailboxDatabaseCopy параметр ActivationPreference не указан. В задаче автоматически увеличивается значение приоритета активации с каждой добавляемой копией. Значение приоритета исходной базы данных всегда равно 1. Для первой копии, добавляемой с помощью командлета Add-MailboxDatabaseCopy, автоматически назначается значение приоритета 2. Если предположить, что ни одна копия не удаляется, для следующей добавляемой копии будет автоматически назначаться значение приоритета 3 и так далее. Таким образом, в приведенных выше примерах показано, что пассивная копия, расположенная том же центре данных, что и активная копия, имеет значение приоритета активации 2, неизолированная пассивная копия в удаленном центре данных — 3, а изолированная пассивная копия в удаленном центре данных — 4.

Несмотря на наличие двух копий каждой активной базы данных в глобальной сети в другом местоположении, заполнение в глобальной сети было выполнено только один раз. Это связано с тем, что компания Contoso использует Exchange Server возможность использовать пассивную копию базы данных в качестве источника для заполнения. Использование командлета Add-MailboxDatabaseCopy с параметром SeedingPostponed предотвращает автоматическое заполнение создаваемой новой копии базы данных. Затем администратор может приостановить незасеянную копию, а с помощью командлета Update-MailboxDatabaseCopy с параметром SourceServer администратор может указать локальную копию базы данных в качестве источника операции заполнения. В результате этого заполнение второй копии базы данных, добавленной к каждому местоположению, выполняется локально, а не по глобальной сети.

Примечание.

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

В Contoso была настроена одна из пассивных копий каждой базы данных почтовых ящиков в качестве изолированной копии базы данных, что позволяет обеспечить защиту от крайне редкого, но серьезного логического повреждения базы данных. В результате администратор настраивает отстающие копии как заблокированные для активации с помощью командлета Suspend-MailboxDatabaseCopy с параметром ActivationOnly . Это гарантирует, что изолированные копии базы данных не будут активированы в случае возникновения сбоя базы данных или сервера.

Проверка решения

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

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

Чтобы проверить действия репликации и воспроизведения, администратор запускает командлет Get-MailboxDatabaseCopyStatus . Этот командлет может в режиме реального времени предоставлять сведения о состоянии конкретной копии базы данных почтовых ящиков или для всех копий базы данных почтовых ящиков на определенном сервере. Дополнительные сведения о мониторинге работоспособности и состояния реплицированных баз данных в DAG см. в разделе Мониторинг групп доступности баз данных.

Чтобы убедиться, что переключения срабатывают должным образом, администратор использует командлет Move-ActiveMailboxDatabase для выполнения серии переключений базы данных и сервера. После успешного выполнения этих задач администратор использует тот же командлет для перемещения активных копий базы данных обратно в исходное местоположение.

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

  • Отключить шнур питания на MBX1, что приводит к сбою сервера. После этого администратор проверяет активацию DB1 на другом сервере (предпочтительно на MBX2 на основе значений приоритета активации).

  • Отключить сетевой кабель для сетевого адаптера MAPI на MBX2, что приводит к сбою сервера. После этого администратор проверяет активацию DB2 на другом сервере (предпочтительно на MBX1 на основе значений приоритета активации).

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

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

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

Перевод в рабочую среду

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

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