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

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

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

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

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

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

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

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

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

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

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

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

DaG доступны в Exchange 2013 Standard и Exchange 2013 Enterprise. Кроме того, DAG может содержать набор серверов под управлением Exchange 2013 Standard и Exchange 2013 Корпоративный.

Каждый член DAG также должен работать под управлением одной и той же операционной системы. Exchange 2013 поддерживается в операционных системах Windows Server 2008 R2, Windows Server 2012 и Windows Server 2012 R2. Все члены определенного DAG должны работать под одной операционной системой. Windows Server 2012 R2 поддерживается только для участников DAG под управлением Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии.

Помимо выполнения предварительных требований для установки Exchange 2013, необходимо выполнить требования к операционной системе. Группы обеспечения доступности баз данных используют технологию отказоустойчивых кластеров Windows, поэтому им требуется ОС Windows Server 2008 R2 версии Enterprise или Datacenter либо Windows Server 2012 (Windows Server 2012 R2) версии Standard или Datacenter.

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

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

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

При проектировании сетевой инфраструктуры для daG учитывайте следующие факторы:

• Для каждого участника группы обеспечения доступности баз данных необходимо настроить по крайней мере один сетевой адаптер, который может устанавливать соединение со всеми остальными участниками данной группы. При использовании одного сетевого пути рекомендуется использовать по крайней мере подключение 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 и наоборот, или между несколькими сетями для репликации в группе доступности базы данных.

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

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

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

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

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

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

Для каждой группы доступности баз данных под управлением Windows Server 2008 R2 или Windows Server 2012 необходим как минимум один IP-адрес в сети MAPI. DaG требует больше IP-адресов, если сеть MAPI расширена по нескольким подсетям. Для групп обеспечения доступности баз данных под управлением Windows Server 2012 R2, созданных без административной точки доступа кластера, IP-адрес не требуется.

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

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

На следующем рисунке показана группа daG с сетью MAPI, которая распространяется на две подсети: 172.19.18.*x_ и 172.19.19.*x_.

В этом примере сеть 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 следящего сервера не обязательно должна совпадать с версией операционной системы, используемой участниками группы обеспечения доступности баз данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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