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

Статья
05/13/2016

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2015-03-09

Для создания высокодоступного сервера почтовых ящиков в предыдущих версиях Exchange требовалось устанавливать систему Exchange на сервер, настроенный в качестве участника отказоустойчивого кластера Microsoft Windows. Чтобы получить высокодоступный сервер почтовых ящиков, требовалось построить и настроить кластер перед выполнением настройки Exchange. Программа установки Exchange (и другие компоненты Exchange, например хранилище Exchange и служба системного автосекретаря Microsoft Exchange) имела поддержку кластеров, и поэтому ее работа отличалась от работы при запуске на автономном сервере. Если система Exchange была уже установлена на автономном сервере Windows, то настройка высокого уровня доступности сервера без предварительного удаления Exchange, построения кластера и последующей переустановки Exchange с помощью программы установки с поддержкой кластера была недоступна.

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

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

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

Создать группу DAG. Дополнительные сведения см. в разделе Создание группы доступности базы данных.
При необходимости подготовить объект имени кластера (CNO). Предварительное размещение объекта CNO требуется при развертывании группы обеспечения доступности баз данных с серверами почтовых ящиков, работающими под управлением Windows Server 2012. Предварительное размещение также требуется в средах, где ограничено создание учетных записей компьютеров или такие учетные записи создаются в контейнере, отличном от контейнера компьютеров по умолчанию. Дополнительные сведения см. в разделе Регистрация объекта имени кластера для группы доступности баз данных.
Добавить два или несколько серверов почтовых ящиков в группу DAG. Дополнительные сведения см. в разделе Управление членством в группе доступности базы данных.
Настроить свойства группы DAG в соответствии с требованиями:
1. Дополнительно настроить шифрование и сжатие группы DAG, порт репликации, IP-адреса группы DAG и другие свойства группы DAG. Дополнительные сведения см. в разделе Настройка свойств группы доступности базы данных.
2. Если группа DAG содержит три и более серверов почтовых ящиков, развернутых на нескольких сайтах Служба каталогов Active Directory, необходимо включить режим координации активации центра данных (DAC). Дополнительные сведения см. в разделе Общие сведения о режиме координации активации центра обработки данных.
3. Дополнительные сведения о создании сети группы обеспечения доступности баз данных см. в разделе Создание сети группы доступности базы данных. Дополнительные сведения об управлении сетью группы DAG см. в разделе Настройка свойств сети группы доступности базы данных.
Добавить копии базы данных почтовых ящиков на серверы почтовых ящиков в группе DAG. Дополнительные сведения см. в разделе Добавление копии базы данных почтовых ящиков.

Пример развертывания. Группа DAG из четырех участников в двух центрах данных

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

Инфраструктура базы

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

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

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

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

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

Группа доступности базы данных (DAG) на два сайта

Группа доступности базы данных (DAG) на два сайта

За исключением серверов почтовых ящиков, все серверы в среде Contoso работают под управлением ОС Windows Server 2008 R2 Standard. Серверы почтовых ящиков, запланированные с учетом групп DAG, работают под управлением Windows Server 2008 R2 Enterprise.

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

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

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

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

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

Как показано в таблице выше, адаптеры, используемые для сетей репликации, не используют шлюзы по умолчанию. Для обеспечения сетевого соединения между всеми сетевыми адаптерами репликации в компании Contoso используются постоянные статические маршруты, настраиваемые с помощью средства Netsh.exe. Его можно применять для настройки и отслеживания компьютеров под управлением ОС Windows через командную строку. Средство Netsh.exe позволяет направлять введенные контекстные команды в соответствующую вспомогательную службу, которая непосредственно будет их выполнять. Вспомогательная служба — это файл динамической библиотеки (DLL), который расширяет функциональные возможности средства Netsh.exe путем обеспечения возможности настройки, отслеживания и поддержки одной или нескольких служб, служебных программ или протоколов.

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

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

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

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

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

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

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

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

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

Для создания группы DAG он использует командлет New-DatabaseAvailabilityGroup. Так как SITEA рассматривается как основной центр данных, в Contoso было выбрано использование следящего сервера в том же центре данных, а именно в HUB-A.
Для предварительной настройки альтернативного следящего сервера и альтернативного следящего каталога на тот случай, если потребуется переключение сайта, используется командлет Set-DatabaseAvailabilityGroup.
Для добавления каждого из четырех серверов почтовых ящиков в группу DAG используется командлет Add-DatabaseAvailabilityGroupServer.
При настройке группы DAG для режима DAC используется командлет Set-DatabaseAvailabilityGroup. Дополнительные сведения о режиме DAC см. в разделе Общие сведения о режиме координации активации центра обработки данных.

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

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

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

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

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

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

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B

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

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

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

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

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

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

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

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

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

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

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

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

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly

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

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly

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

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly

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

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly

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

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

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

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

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

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

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

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

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

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

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

Отключить шнур питания MBX1A, что приводит к сбою сервера. После этого администратор проверяет активацию DB1 на другом сервере (предпочтительно на MBX2A на основе значений приоритета активации).
Отключить сетевой кабель для сетевого адаптера MAPI на MBX2A, что приводит к сбою сервера. После этого администратор проверяет активацию DB2 на другом сервере (предпочтительно на MBX1A на основе значений приоритета активации).
Перевести диск, используемый активной копией DB3, в автономный режим, что приводит к сбою базы данных. После этого администратор проверяет активацию DB3 на другом сервере (предпочтительно на MBX2B на основе значений приоритета активации).

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

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

Переход к эксплуатации

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

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

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