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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый член daG должен работать под управлением одной и той же операционной системы. Exchange Server 2016 поддерживается в Windows Server 2012, Windows Server 2012 R2 и Windows Server 2016. Exchange Server 2019 поддерживается в операционной системе Windows Server 2019 и Windows Server 2022. В рамках определенного daG все члены должны работать под управлением одной поддерживаемой операционной системы.

Помимо выполнения предварительных требований для установки Exchange Server, необходимо выполнить требования к операционной системе. Группы доступности данных используют технологию отказоустойчивой кластеризации Windows, поэтому им требуется стандартная версия Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 или Windows Server 2022.

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

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

В предыдущих версиях Exchange мы рекомендовали по крайней мере две сети (одну сеть MAPI и одну сеть репликации) для групп обеспечения доступности баз данных. В Exchange 2016 и Exchange 2019 поддерживается несколько сетей, но наша рекомендация зависит от вашей физической топологии сети. Если между участниками группы обеспечения доступности баз данных существует несколько сетей, которые полностью физически отделены друг от друга, то использование отдельной сети MAPI и сети репликации обеспечивает дополнительную избыточность. Если вы используете несколько физически разделенных сетей, но которые при этом объединены в одну физическую сеть (например, один канал глобальной сети), то рекомендуется использовать одну сеть (желательно Ethernet 10 Гбит/с) для трафика MAPI и репликации. Это позволит упростить работу с сетью.

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

• Для каждого участника группы обеспечения доступности баз данных необходимо настроить по крайней мере один сетевой адаптер, который может устанавливать соединение со всеми остальными участниками данной группы. При использовании одного сетевого пути рекомендуется использовать по крайней мере подключение Ethernet 1 Гбит/с, но желательно — Ethernet 10 Гбит/с. Кроме того, при использовании одного сетевого адаптера для каждого участника группы доступности базы данных рекомендуется создать общее решение с учетом использования одного сетевого адаптера и пути.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждой daG, работающей в Windows Server 2012, требуется как минимум один IP-адрес в сети MAPI. При расширении сети MAPI на несколько подсетей группе доступности базы данных требуются дополнительные IP-адреса. Группы доступности базы данных, работающие на Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 или Windows Server 2022, созданные без административной точки доступа кластера, не требуют 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-адрес и сетевой объект кластера используются внутри системы, чтобы гарантировать безопасность группы обеспечения доступности баз данных и осуществления внутренней связи. Администраторам и конечным пользователям нет необходимости обращаться или подключаться к имени группы обеспечения доступности баз данных или IP-адресу.

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

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

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

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

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

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

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

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

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

Конфигурация репликации сетевого адаптера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Клиентские записи DNS должны иметь значение Time to Live (TTL) (TTL) 5 минут. Время простоя, которое испытывают клиенты, зависит не только от того, как быстро может произойти переключение, но и от того, как быстро выполняется репликация DNS и клиенты запрашивают обновленные сведения о DNS. Записи DNS для всех клиентских служб Exchange, включая Outlook в Интернете (прежнее название — Outlook Web App), Exchange ActiveSync, веб-службы Exchange, Outlook Anywhere, SMTP, POP3 и IMAP4 на внутреннем и внешнем DNS-серверах, должны быть настроены с сроком жизни в 5 минут.

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

Общее планирование устойчивости сайтов

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

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

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

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

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

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

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

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

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

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