Следует отметить несколько аспектов о данной конфигурации.

• В этой структуре совместно расположены только роли сервера клиентского доступа, сервера почтовых ящиков и транспортного сервера-концентратора. Хотя возможность совместного расположения с ролью сервера единой системы обмена сообщениями поддерживается, такая конфигурация не рекомендуется из соображений производительности.
  
  
• Для обеспечения высокой доступности для ролей сервера клиентского доступа и транспортного сервера-концентратора, необходимо сбалансировать нагрузку между клиентами и этими ролями сервера. Так как данные роли сервера располагаются совместно с сервером почтовых ящиков, который является членом группы обеспечения доступности баз данных, то использование балансировки сетевой нагрузки Windows невозможно (балансировка сетевой нагрузки и служба отказоустойчивого кластера Windows не могут устанавливаться на один сервер). Вместо этого необходимо использовать решение балансировки сетевой нагрузки, не относящееся к Windows (например, аппаратную подсистему балансировки нагрузки или стороннюю программную подсистему балансировки нагрузки).
  
  
• Так же как для всех групп доступности базы данных, содержащих четное число участников, группе доступности базы данных из двух участников требуется использование следящего сервера для поддержания кворума. Следящий сервер (не показан) — это сервер Windows, который не является и никогда не будет являться членом группы обеспечения доступности баз данных. Например, в небольших организациях, в которых применяется такая конфигурация, в качестве следящего сервера можно использовать файловый сервер или сервер каталогов. Кворум сохраняется до тех пор, пока более половины участников кворума доступны и находятся на связи. Группа DAG из двух членов вместе со следящим сервером обеспечивают три голоса для кворума. (Каждый член группы DAG и следящий сервер могут голосовать всегда, когда они доступны и с ними установлена связь.) Таким образом, группа доступности базы данных из двух участников способна переносить сбои или отключение отдельного участника кворума (например, участников группы доступности базы данных или только следящий сервер) без прерывания службы. Тем не менее, потеря двух голосов (например, члена группы DAG и следящего сервера) будет приводить к потере кворума и, как следствие, к прерыванию обслуживания.
  
  

В начало

Группа обеспечения доступности баз данных с четырьмя членами в одном центре обработки данных или сайте Active Directory

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

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

С помощью группы доступности базы данных из четырех участников можно создавать до четырех копий каждой базы данных. Это достаточное количество копий базы данных для использования альтернативных сценариев защиты данных, таких как гибкая защита почтового ящика. Гибкая защита почтовых ящиков позволяет сочетать функции высокой доступности Microsoft Exchange Server 2010 и устойчивости расширенного обработчика хранилищ (ESE) с другими встроенными функциями защиты, например копиями базы данных запаздывающих почтовых ящиков, политиками хранения, папкой «Элементы для восстановления» и политикой удержания, для создания решения, которое может снизить потребность в других формах защиты, таких как RAID-массивы или создание резервных копий данных. Дополнительные сведения о гибкой защите почтовых ящиков см. в разделе Общие сведения об архивации, восстановлении и аварийном восстановлении. Дополнительные сведения об использовании репликации для резервных копий и использовании просто несколько жёстких дисков см. в разделе Проектирование системы хранения сервера почтовых ящиков.

В начало

Группа обеспечения доступности баз данных с четырьмя членами в двух центрах обработки данных или сайтах Active Directory

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

Следует отметить несколько аспектов о данной конфигурации.

• Следящий сервер для группы доступности базы данных должен располагаться в основном центре данных. Как правило, основным центром данных является центр данных, который содержит большее количество пользователей. Использование следящего сервера в основном центре данных позволяет большинству пользователей продолжать работу при отключении глобальной сети. Можно использовать несколько групп обеспечения доступности баз данных для исключения глобальной сети как единственной точки сбоев и сохранения функциональности доступа к службам и данным для нескольких центров обработки данных в случае сбоя в глобальной сети. Дополнительные сведения см. в следующем примере.
  
  
• Не существует прямой маршрутизации, в которой допускался бы трафик из сети репликации на одном сервере из группы DAG в сеть MAPI на другой сервер из этой группы, или наоборот, или между несколькими сетями репликации в группе DAG. Например, может потребоваться заблокировать трафик между сетью MAPI на каждом сервере из группы DAG и сетями репликации в каждой другой сети группы DAG. (На предыдущем рисунке сеть MAPI на сервере MBX1A не должна иметь никаких связей с сетями репликации на серверах MBX1B или MBX2B.) Для блокировки такого трафика можно использовать списки управления доступом (ACL) на маршрутизаторе. Помимо этого, если для сети репликации применяется протокол DHCP, то его же можно использовать и для настройки статических маршрутов для членов группы DAG.
  
  
• Поскольку такая конфигурация группы DAG предназначена для обеспечения устойчивости сайта, то значение срока жизни (TTL) для пространств имен клиентского доступа Exchange (Microsoft Office Outlook Web App, автообнаружение, Microsoft Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4, SMTP и массив клиентского доступа) должно быть равно 5 минутам как во внутренней, так и во внешней зонах DNS.
  
  
• В этом примере роли сервера Exchange развертываются на выделенном оборудовании. Так как роли сервера клиентского доступа и транспортного сервера-концентратора не располагаются совместно с сервером почтовых ящиков в группе обеспечения доступности баз данных, то используется балансировка сетевой нагрузки Windows между указанными ролями.
  
  

В начало

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

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

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

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

Активная база данных почтовых ящиков пользователей, находящихся в Портленде, будет располагаться на сервере PDXMBX3 и/или PDXMBX4, а пассивные копии баз данных — на сервере REDMBX3 и/или REDMBX4. Аналогично, активная база данных почтовых ящиков пользователей в Редмонде будет располагаться на сервере REDMBX1 и/или REDMBX2, а пассивные копии баз данных — на сервере REDMBX2 и/или PDXMBX2. Если теряется связь между Портлендом и Редмондом, происходит следующее:

• в группе DAG1 члены REDMBX1 и REDMBX2 окажутся в большинстве и будут продолжать обслуживать пользователей в центре обработки данных в Редмонде, так как они могут устанавливать связь со следящим сервером группы DAG1 с именем HUB1;
  
  
• в группе DAG2 члены PDXMBX3 и PDXMBX4 окажутся в большинстве и будут продолжать обслуживать пользователей в центре обработки данных в Портленде, так как они могут устанавливать связь со следящим сервером группы DAG2 с именем HUB2.
  
  

В начало

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

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

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

Используя в этом примере те же самые серверы, можно добавить роль сервера почтовых ящиков на транспортные серверы-концентраторы REDHUB1, REDHUB2 и PDXHUB1, а затем добавить их в группу DAG1 (при условии, что эти серверы поддерживают службу отказоустойчивого кластера Windows).

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

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

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

В начало

© Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены. Юридические сведения

---

• English-to-Russian translation

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

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

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

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

Группа доступности базы данных из четырех участников