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

Развертывание с высоким уровнем доступности и устойчивости сайта

  • Статья

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

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

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

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

  1. Создайте DAG. Дополнительные сведения см. в разделе Create a database availability group.

  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 в соответствии с требованиями.

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

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

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

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

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

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

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

  • Службы каталогов (доменные службы Active Directory или Active Directory (AD DS)).
  • Разрешение имени системы доменных имен (DNS).
  • Несколько серверов клиентского доступа Exchange 2013.
  • Несколько серверов почтовых ящиков Exchange 2013.

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

Группа доступности базы данных расширена до двух сайтов.

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

Как показано на рисунке выше, решение включает в себя использование нескольких подсетей и нескольких сетей. Для каждого сервера почтовых ящиков в группе 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.0.0 Нет
MBX2 (репликация) 10.0.1.5 255.255.0.0 Нет
MBX3 (репликация) 10.0.2.4 255.255.0.0 Нет
MBX4 (репликация) 10.0.2.5 255.255.0.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. Поскольку REDMOND считается главным центром данных, компания Contoso решила использовать следящий сервер в том же центре данных, а именно CAS1.

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

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

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

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

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

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

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

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

Примечание.

Использование того же пути не требуется; в 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.

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

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

На 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 2013 использовать пассивную копию базы данных в качестве источника для заполнения. Использование командлета 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 на основе значений приоритета активации).

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

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

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

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

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