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

 

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

Последнее изменение раздела: 2016-11-28

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

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

Содержание

Общие требования

Требования к оборудованию

Требования к хранилищу

Требования к программному обеспечению

Требования к сети

Требования к следящему серверу

Планирование устойчивости сайта

Планирование переключений центров данных

Общие требования

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

• Служба доменных имен (DNS) запущена. В идеальном случае DNS-сервер должен принимать динамические обновления. Если DNS-сервер не принимает динамические обновления, необходимо создать запись DNS Host (A) для каждого сервера Exchange. Иначе Exchange будет работать неправильно.

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

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

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

Требования к оборудованию

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

• Общие сведения о конфигурациях процессоров и производительности Exchange

• Общие сведения о конфигурациях памяти и производительности Exchange

• Проектирование системы хранения сервера почтовых ящиков

• Общие сведения о соотношениях ролей сервера и производительности Exchange

Требования к хранилищу

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

Требования к программному обеспечению

Группы доступности базы данных доступны как в выпуске Exchange 2010 Standard Edition, так и в Exchange 2010 Enterprise Edition. Кроме того, группы доступности базы данных содержат смешанные типы серверов под управлением Exchange 2010 Standard Edition и Exchange 2010 Enterprise Edition.

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

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

Требования к сети

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

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

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

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

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

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

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

  • При возникновении сбоя в сети для репликации, если сеть MAPI не повреждена сбоем, операции доставки и заполнения журналов будут выполняться в сети MAPI, даже если ее свойство ReplicationEnabled имеет значение False. После того как работоспособность сети для репликации будет восстановлена и она будет готова возобновить операции доставки и заполнения журналов, необходимо переключиться на эту сеть вручную. Чтобы переключить репликацию с сети MAPI на восстановленную сеть для репликации, можно либо приостановить и затем возобновить непрерывную репликацию с помощью командлетов Suspend-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy, либо перезапустить службу репликации Microsoft Exchange. Рекомендуется использовать первый вариант во избежание кратковременного периода недоступности, связанного с перезапуском службы репликации Microsoft Exchange.

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

• Для каждой группы доступности базы данных должно быть настроено не более одной сети MAPI. Сеть MAPI должна обеспечивать подключение к другим серверам Exchange и службам, таким как Служба каталогов Active Directory и DNS.

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

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

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

  • каждая сеть MAPI на сервере участника группы доступности базы данных может устанавливать связь с другими сетями MAPI участника группы доступности базы данных;

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

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

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

• Для конфигурации с несколькими центрами обработки данных требования к задержке приема-передачи могут и не быть определяющими требованиями к пропускной способности и задержке сети. Чтобы определить необходимые требования к сети для конкретной среды, следует оценить общую нагрузку сети, которая включает клиентский доступ, Служба каталогов Active Directory, передачу данных, непрерывную репликацию и другой прикладной трафик.

• Сети группы доступности базы данных поддерживают протокол IP версии 4 (IPv4) и IPv6. Протокол IPv6 поддерживается только при использовании IPv4; использование в среде только IPv6 невозможно. IPv6-адреса и диапазоны IP-адресов поддерживаются, только если на компьютере включены протоколы IPv6 и IPv4, а сеть поддерживает IP-адреса обеих версий. Если сервер Exchange 2010 развернут в этой конфигурации, все роли сервера могут обмениваться данными с устройствами, серверами и клиентами, использующими IPv6-адреса.

• Автоматическое назначение частных IP-адресов (APIPA) — это функция Microsoft Windows, которая автоматически назначает IP-адреса при отсутствии в сети доступных DHCP-серверов (Dynamic Host Configuration Protocol). Использование APIPA-адресов (включая адреса, назначенные вручную из диапазона APIPA-адресов) в группах доступности базы данных или Exchange 2010 не поддерживается.

Требования к имени группы доступности базы данных и IP-адресам

При создании каждая группа доступности базы данных получает уникальное имя, а также один или несколько статических IP-адресов или настраивается для использования протокола DHCP. Независимо от использования статических или динамически назначенных адресов любой IP-адрес, назначенный группе доступности базы данных, должен находиться в сети MAPI.

Для каждой группы доступности базы данных необходим по меньшей мере один IP-адрес в сети MAPI. При расширении сети MAPI на несколько подсетей группе доступности базы данных требуются дополнительные IP-адреса. На следующем рисунке изображена группа доступности базы данных, для всех узлов которой сеть MAPI настроена в одной и той же подсети.

Группа доступности базы данных с сетью MAPI в одной и той же подсети

В этом примере сеть MAPI для каждого участника группы доступности базы данных находится в подсети 172.19.18.x. Поэтому группе доступности базы данных требуется один IP-адрес в этой подсети.

На следующем рисунке изображена группа доступности базы данных, сеть MAPI которой расширяется на две подсети: 172.19.18.x и 172.19.19.x.

Группа доступности базы данных с сетью MAPI в нескольких подсетях

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

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

В определенный момент времени кластером группы доступности базы данных используется только один из назначенных IP-адресов. Отказоустойчивый кластер Windows регистрирует этот IP-адрес в системе доменных имен при переводе IP-адреса кластера и ресурсов сетевых имен в оперативный режим работы. Кроме использования IP-адреса и сетевого имени в Служба каталогов Active Directory также создается объект имени кластера (CNO). Имя, IP-адрес и CNO используются внутри системы для обеспечения безопасности группы доступности базы данных и осуществления внутренней связи. Администраторам и конечным пользователям нет необходимости обращаться или подключаться к имени группы доступности базы данных или IP-адресу.

Примечание.

Хотя IP-адрес кластера и сетевое имя используются внутри системы, доступность этих ресурсов не зависит от Exchange 2010. Даже если IP-адрес базового кластера и ресурсы сетевого имени используются в автономном режиме, внутренняя связь в группе доступности базы данных осуществляется посредством имен сервера участника группы доступности базы данных. Тем не менее, рекомендуется периодически проверять доступность этих ресурсов, чтобы убедиться, что они не находятся в автономном режиме более 30 дней. Если базовый кластер находится в автономном режиме более 30 дней, учетная запись CNO кластера становится недействительной в процессе сборки мусора в Служба каталогов Active Directory.

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

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

Настройка сетевого адаптера MAPI

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

Сетевые компоненты	Параметр
Клиент для сетей Microsoft	Включено
Планировщик пакетов QoS	При необходимости включить
Служба доступа к файлам и принтерам сетей Microsoft	Включить
Протокол IP версии 6 (TCP/IP v6)	При необходимости включить
Протокол IP версии 4 (TCP/IP v4)	Включено
Драйвер в/в тополога канального уровня	Включено
Ответчик обнаружения топологии канального уровня	Включено

Свойства TCP/IP v4 для сетевого адаптера MAPI настраиваются следующим образом.

• IP-адрес для сети MAPI участника группы обеспечения доступности баз данных может быть назначен вручную или настроен для использования DHCP. При использовании DHCP рекомендуется регулярно выполнять резервирование для IP-адресов сервера.

• Сетью MAPI обычно используется шлюз по умолчанию, хотя он не является обязательным.

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

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

Настройка адаптера сети для репликации

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

Сетевые компоненты	Параметр
Клиент для сетей Microsoft	Отключено
Планировщик пакетов QoS	При необходимости включить
Служба доступа к файлам и принтерам сетей Microsoft	Отключено
Протокол IP версии 6 (TCP/IP v6)	При необходимости включить
Протокол IP версии 4 (TCP/IP v4)	Включено
Драйвер в/в тополога канального уровня	Включено
Ответчик обнаружения топологии канального уровня	Включено

Свойства TCP/IP v4 адаптера сети для репликации настраиваются следующим образом.

• IP-адрес для сети репликации участника группы обеспечения доступности баз данных может быть назначен вручную или настроен для использования DHCP. При использовании DHCP рекомендуется регулярно выполнять резервирование для IP-адресов сервера.

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

• Адреса DNS-серверов настраивать не следует.

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

Общие требования

Требования к следящему серверу

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

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

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

Планирование устойчивости сайта

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

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

Архитекторы и администраторы решения также определяют группу пользователей, для которых требуется защита устойчивости сайта, а также конфигурацию решения «активный-пассивный» или «активный-активный» для нескольких сайтов. Как правило, в конфигурации «активный-пассивный» пользователи не размещаются в резервном центре обработки данных. В конфигурации «активный-активный» пользователи размещаются в обоих местоположениях, а некоторое количество от общего числа баз данных в решении в основном хранятся во втором центре обработки данных. Если происходит сбой обслуживания пользователей одного центра обработки данных, они автоматически активируются в другом.

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

• Какой уровень обслуживания требуется после сбоя основного центра обработки данных?

• Нужны ли пользователям их данные или достаточно только возможности обмена сообщениями?

• Насколько быстро потребуются эти данные?

• Какое количество пользователей необходимо поддерживать?

• Каким образом пользователи получат доступ к своим данным?

• Каким должно быть соглашение об уровне обслуживания резервного центра обработки данных?

• Каким образом производится переключение обслуживания обратно на основной центр обработки данных?

• Выделены ли ресурсы для обеспечения устойчивости сайтов?

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

Планирование пространства имен

В Exchange 2010 изменен способ создания пространства имен при развертывании конфигурации устойчивых сайтов. Правильное планирование пространства имен необходимо для успешных переключений центра обработки данных. Что касается пространства имен, каждый центр данных, используемый в конфигурации устойчивости сайтов, должен находиться в активном состоянии. В результате для каждого центра данных требуется уникальное пространство имен для различных служб Exchange 2010 на данном сайте, включая пространства имен для Outlook Web App, Outlook Anywhere, Exchange ActiveSync, веб-служб Exchange, клиентского доступа к удаленному вызову процедур, протокола POP3, IMAP4, а также для протокола SMTP. Кроме того, один из центров данных также содержит пространство имен для службы автообнаружения. Такой подход позволяет также выполнять переключение одной базы данных с основного центра данных на второй для проверки конфигурации второго центра данных в ходе проверки работы переключения центра данных.

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

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

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

Как показано выше, для каждого центра данных используется отдельное уникальное пространство имен, и в каждом содержатся серверы DNS в конфигурации разделения DNS для этих пространств имен. Центр данных Редмонд, который считается основным центром данных, настроен с пространством имен протокол.contoso.com. Центр данных Портленд настроен с пространствами имен протокол.standby.contoso.com. Пространства имен могут включать в себя обозначения режима ожидания, как на рисунке в примере, могут основываться на регионе (например, протокол.portland.contoso.com) или других соглашениях об именах, соответствующих потребностям организации. Основным требованием является наличие собственного уникального пространства имен центра данных независимо от используемого соглашения об именах.

Настройка параметра FailbackURL

Некоторые веб-браузеры, в том числе Microsoft Internet Explorer, поддерживают кэш DNS-имен во время каждого сеанса браузера, который является отдельным от кэша DNS, предоставляемого операционной системой. Во время восстановления размещения после переключения на другой центр обработки данных использование веб-браузером этого отдельного кэша может приводить к образованию циклов при входе в систему пользователей приложения Outlook Web App, когда происходит перенаправление пользователей на один и тот же URL-адрес по замкнутому пути.

В процессе восстановления размещения IP-адрес для пространства имен Outlook Web App в службе DNS изменяется с конечной точки в резервном центре обработки данных обратно на исходную конечную точку в основном центре. После истечения срока жизни (TTL) для DNS-записи и даже после очистки кэша DNS в операционной системе веб-браузеры, которые поддерживают собственный отдельный кэш имен, могут продолжать подключаться к конечной точке в резервном центре, даже если пространство имен размещается в основном центре обработки данных.

Как правило, закрытия веб-браузера достаточно для очистки его отдельного кэша имен и предотвращения циклов при входе в систему. Тем не менее, чтобы облегчить эту проблему для всех веб-браузеров и пользователей Outlook Web App, можно настроить свойство FailbackURL виртуального каталога Outlook Web App. Параметр FailbackUrl задает имя узла, которое используется в приложении Outlook Web App для подключения к серверу клиентского доступа после переключения на основной сайт при сбое. Для этого пространства имен необходимо, чтобы отдельная DNS-запись указывала на IP-адрес исходного сервера клиентского доступа. Значение параметра FailbackUrl должно отличаться от значения параметра ExternalUrl для виртуального каталога Outlook Web App. Когда пользователь Outlook Web App предоставляет свои учетные данные, сервер клиентского доступа определяет, совпадает ли URL-адрес перенаправления с тем адресом, который посещает пользователь. Если URL-адреса идентичны, то сервер клиентского доступа проверяет, настроен ли параметр FailbackUrl:

• Если параметр FailbackUrl настроен, то выполняется перенаправление пользователя на URL-адрес, по которому можно получить доступ к приложению Outlook Web App.

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

Планирование сертификата

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

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

Для клиентов Outlook Anywhere рекомендуется использовать один сертификат дополнительного имени субъекта для каждого центра данных и включить в него несколько имен узлов. Чтобы обеспечить подключение Outlook Anywhere после переключения базы данных, сервера или центра данных, необходимо использовать имя участника сертификата для каждого сертификата, а также настроить объект конфигурации поставщика OutlookСлужба каталогов Active Directory с тем же именем участника в форме по стандарту Microsoft (MSSTD). Например, при использовании имени участника сертификата mail.contoso.com атрибут настраивается следующим образом:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Некоторые приложения, взаимодействующие с Exchange, имеют определенные требования к сертификатам, для чего может потребоваться использование дополнительных сертификатов. Сервер Exchange 2010 может сосуществовать с Office Communications Server (OCS). Для OCS требуется использование сертификатов размером 1024 бита или больше с именем сервера OCS в качестве имени участника сертификата. Поскольку использование имени сервера OCS в качестве имени участника сертификата не позволяет Outlook Anywhere работать правильно, может потребоваться дополнительный отдельный сертификат для среды OCS.

Дополнительные сведения об использовании сертификатов SAN для сервера клиентского доступа Exchange 2010 см. в разделе Настройка SSL-сертификатов для использования нескольких имен узлов серверов клиентского доступа.

Планирование сети

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

• Сети MAPI должны быть изолированы от сетей для репликации Для блокировки трафика между сетями MAPI и сетями для репликации необходимо использовать политики сети Windows, политики брандмауэра Windows или списки управления доступом. Такая конфигурация необходима для предотвращения перекрестных помех сети при подтверждении соединения.

• Время действия клиентских записей DNS должен составлять 5 минут Время простоя клиентов зависит не только от скорости выполнения переключения, но также и от скорости выполнения репликации DNS и запросов клиентов на обновленные сведения о DNS. Для записей DNS всех служб клиента Exchange, включая Outlook Web App, Exchange ActiveSync, веб-службы Exchange, Outlook Anywhere, SMTP, POP3, IMAP4 и клиентский доступ RPC как на внутренних, так и внешних DNS-серверах, должно быть установлено время действия 5 минут.

• Использование статичных маршрутов для настройки соединения через сети для репликации Чтобы обеспечить соединение между всеми адаптерами сети для репликации, используйте постоянные статичные маршруты. Это быстрая, разовая настройка, выполняемая для каждого участника группы доступности базы данных при использовании статичных IP-адресов. Если для приобретения IP-адресов для сетей для репликации используется сервер DHCP, его можно также использовать для назначения статичных маршрутов для репликации, что упрощает процесс конфигурации.

Планирование устойчивости общего сайта

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

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

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

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

• Во втором центре обработки данных должны быть включены все службы, представленные в основном центре обработки данных (в случае, если служба не входит в состав соглашения об уровне обслуживания устойчивости сайта). Сюда входят: Служба каталогов Active Directory, инфраструктура сети (DNS, TCP/IP и т. д.), службы телефонии (при использовании единой системы обмена сообщениями) и инфраструктура сайта (питание, охлаждение и т. д.).

• Чтобы пользователи центров обработки данных со сбоем могли иметь доступ к некоторым службам, необходимо настроить для них соответствующие сертификаты сервера. В некоторых службах запрещено использование экземпляров (например, POP3 и IMAP4), а разрешено только использование одного сертификата. В таких случаях сертификат должен являться сертификатом дополнительного имени субъекта с несколькими именами, или несколько имен должны быть достаточно схожими для использования группового сертификата (при условии, что политики безопасности организации позволяют использование группового сертификата).

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

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

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

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

Общие требования

Планирование переключений центров данных

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

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

Чтобы лучше понять процесс переключения центра обработки данных, необходимо рассмотреть основные операции при переключении центра обработки данных Exchange 2010.

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

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

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

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

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

Примечание.
Одно из требований, необходимых для устойчивости к дополнительным сбоям, — это наличие минимум четырех участников группы доступности базы данных, распределенных между двумя сайтами Служба каталогов Active Directory (например, минимум два участника в каждом центре обработки данных).

Это основной процесс, используемый для восстановления работы роли сервера почтовых ящиков во втором центре обработки данных. Активация других ролей во втором центре обработки данных не требует определенных действий на затрагиваемых серверах. Вместо этого серверы во втором центре обработки данных становятся конечными точками служб, расположенных в основном центре обработки данных. Например, пользователь, расположенный в основном центре обработки данных, может использовать адрес http://mail.contoso.com/owa для подключения к Outlook Web App. После сбоя центра обработки данных эти конечные точки служб перемещаются в конечные точки во втором центре обработки данных как часть процесса переключения. Во время операции переключения конечные точки службы для основного центра обработки данных переназначаются на другие IP-адреса для тех же служб во втором центре обработки данных. Благодаря этому уменьшается количество изменений, которые необходимо внести в данные о конфигурации, хранящиеся в Служба каталогов Active Directory, во время процесса переключения. Выполнить это действие можно двумя способами.

• Обновление записей DNS, или

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

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

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

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

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

Общие требования

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