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

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

В этом разделе описаны несколько конфигураций устойчивых сайтов для окончательной первоначальной версии (RTM) сервера Microsoft Exchange Server 2007 и Exchange 2007 с пакетом обновления 1 (SP1). Прежде чем начать изучение решений для обеспечения устойчивости сайтов, рекомендуется ознакомиться с приведенными ниже терминами.

Термины рабочий, теплый и выделенный могут использоваться в любом сочетании для описания развертывания устойчивых сайтов. Например, рабочий центр обработки данных, который поддерживается выделенным и большей частью настроенным резервным центром обработки данных, можно назвать «Рабочий:теплый (выделенный)».

Средства поддержки устойчивости сайта

Существует несколько возможностей Exchange 2007, которые можно использовать в качестве стандартных элементов решения для устойчивости сайта. Эти элементы перечислены ниже.

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

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

  • Распределенные сайты Active Directory, которые можно использовать для поддержки распределенных кластеров или резервного центра обработки данных.

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

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

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

В Exchange 2007 с пакетом обновления 1 (SP1) добавлена новая возможность под названием «резервная непрерывная репликация», которая предназначена для обеспечения устойчивости сайтов. Как следует из названия, резервная непрерывная репликация предназначена для сценариев, предусматривающих использование или включение резервных серверов восстановления. Эта модель репликации расширяет возможности репликации, присутствовавшие в окончательной первоначальной версии (RTM) сервера Exchange 2007, и позволяет реализовывать новые сценарии обеспечения доступности данных для серверов почтовых ящиков с Exchange 2007 с пакетом обновления 1 (SP1). При резервной непрерывной репликации используются те же технологии доставки и преобразования журналов, что при локальной непрерывной репликации и в кластере с непрерывной репликацией. Это расширяет возможности развертывания и настройки кластеров.

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

Дополнительные сведения о резервной непрерывной репликации см. в разделе Резервная непрерывная репликация.

Решения для обеспечения устойчивости сайтов

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

  • Рабочий: холодный (выделенный).

  • Рабочий: теплый (выделенный).

  • Рабочий: теплый (общего назначения) — два сайта Active Directory.

  • Рабочий: рабочий (общего назначения) — один сайт Active Directory.

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

Рабочий: холодный (выделенный)

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

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

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

Рабочий: теплый (выделенный)

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


Производство:Теплое развертывание (специальное)

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

Ниже перечислены возможные решения для обеспечения избыточности сервера почтовых ящиков.

  • Кластер с непрерывной репликации в конфигурации с распределенным кластером Кластер с непрерывной репликацией использует доставку журналов для создания второй копии данных почтовых ящиков. Таким образом, кластер с непрерывной репликацией, состоящий из двух узлов, имеет по одному узлу в каждом центре обработки данных. В этой конфигурации служба кластера Windows работает с двумя подсетями, распределенными между двумя объектами. Использование распределенного кластера позволяет переключить кластерный сервер почтовых ящиков при сбое, просто перерегистрировав назначенный ему IP-адрес на узел в другом центре обработки данных.

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

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

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

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

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

Ниже описана нормальная работа системы при использовании кластерного решения.

  1. Весь поток почты Интернета идет через пограничный транспортный сервер в центре обработки данных А.

  2. Весь поток почты, предназначенный для серверов почтовых ящиков сайта Active Directory Redmond-Prod, обрабатывается транспортными серверами-концентраторами в Redmond-Prod.

  3. Кластерные серверы почтовых ящиков на сайте Active Directory Redmond-Prod должны располагаться на настроенных узлах центров обработки данных А и В. Узлы NodeA и NodeВ принадлежат сайту Redmond-Prod и обслуживаются транспортными серверами-концентраторами и серверами клиентского доступа Redmond-Prod.

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

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

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

  • Требования службы кластеров к задержкам. Службе кластеров требуется время приема-передачи между кластерами, не превышающее 0,5 секунды.

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

    • Доставка журналов

    • Уведомления файловой системы, которые сообщают службе репликации Microsoft Exchange о том, что новый файл журнала готов к доставке.

    • Трафик сервера каталогов

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

    • Трафик подтверждений соединения кластера

    • Обновления кластерной базы данных

    • Любые другие приложения, использующие сетевые ресурсы

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

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

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

  • Перенос серверов почтовых ящиков в резервный центр обработки данных на сайт Active Directory Redmond-DR.

  • Перенос транспортных серверов-концентраторов, серверов клиентского доступа и серверов каталогов в резервный центр обработки данных на сайт Active Directory Redmond-Prod.

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

При активации центра обработки данных В выполняются указанные ниже высокоуровневые действия.

  1. Инфраструктура сети переходит в оперативный режим.

  2. Инфраструктура Active Directory переходит в оперативный режим.

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

  4. На сайте Active Directory Redmond-Prod используются IP-адреса транспортных серверов-концентраторов, серверов клиентского доступа и серверов каталогов с сайта Redmond-DR.

  5. В МХ-запись для доменов организации вносится IP-адрес пограничного транспортного сервера из центра обработки данных В.

  6. Только что перенесенный сервер клиентского доступа добавляется в конфигурацию балансировки сетевой нагрузки.

  7. Служба обмена сообщениями центра обработки данных А восстанавливается в центре обработки данных В.

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

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

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

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

  4. В МХ-запись для доменов организации вносится IP-адрес пограничного транспортного сервера из центра обработки данных A.

  5. Затем выполняются все необходимые обновления сетевой инфраструктуры.

  6. Перемещение кластерного сервера почтовых ящиков в центр обработки данных А.

  7. Добавление для сайта Active Directory Redmond-DR IP-адресов серверов, перенесенных во время активации.

  8. Служба обмена сообщениями центра обработки данных А восстановливается.

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

Преимущество решения типа «Рабочий: теплый (выделенный)Л заключается в том, что выделенные серверы обеспечивают предсказуемый уровень обслуживания.

Рабочий: теплый (общего назначения) — два сайта Active Directory

При конфигурации «Рабочий: теплый (выделенный)» пограничные транспортные серверы, транспортные серверы-концентраторы и серверы клиентского доступа резервного центра обработки данных были выделены в качестве резервных ресурсов центра обработки данных А. Такая конфигурация предполагает значительные вложения в оборудование, которое потом используется не полностью. На рисунке ниже представлена альтернативная модель.


Пример производства:Теплое развертывание (общего назначения)

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

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

Например, как показано на рисунке Пример развертывания схемы «Рабочий: теплый (общего назначения)», когда в центре обработки данных А происходит сбой, транспортный сервер-концентратор 4, сервер клиентского доступа 4 и сервер глобального каталога 4 добавляются к сайту Active Directory Redmond. Совместно с узлом NodeB сайта Redmond они предоставляют службу обмена сообщениями пользователям центра обработки данных А. При этом после сбоя сайта две рабочие среды работают с усеченной производительностью и усеченным резервированием по сравнению с нормальным режимом. Если текущая нагрузка выдерживается, такая конфигурация является допустимой. Например, поток почты Интернета поступает через пограничный транспортный сервер в центр обработки данных В. На случай длительного простоя центра обработки данных, организация может заключить контракт с производителем на быструю поставку дополнительного оборудования по запросу. Дополнительное оборудование может затем использоваться для восстановления избыточности или увеличения мощности.

При таком решении нормальная работа сайтов Active Directory Redmond и Dublin будет такой же, как и при использовании решения типа «Рабочий: теплый (выделенный)». Аналогичным образом, пропускная способность между двумя объектами определяется теми же факторами, если не считать того, что в данном примере надо постоянно поддерживать серверы сайтов Redmond и Dublin.

Активация резервного центра обработки данных выполняется одним из следующих способов:

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

  • переносом транспортных серверов-концентраторов, серверов клиентского доступа и серверов каталогов резервного центра обработки данных на сайт Active Directory сбойного центра обработки данных.

Рекомендуется использовать решение с переносом транспортных серверов-концентраторов и серверов клиентского доступа на сайт Active Directory сбойного центра обработки данных. Такое решение является самым простым и наименее деструктивным способом активации.

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

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

  2. Подключается инфраструктура Active Directory центра обработки данных А (сайт Active Directory Redmond).

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

  4. На сайте Active Directory Redmond обновляются IP-адреса транспортного сервера-концентратора 4, сервера клиентского доступа 4 и сервера глобального каталога 4.

  5. Сервер клиентского доступа 3 добавляется в конфигурацию балансировки сетевой нагрузки для сайта Redmond.

  6. Служба обмена сообщениями центра обработки данных А восстанавливается.

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

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

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

  3. Сервер клиентского доступа 4 выводится из конфигурации балансировки сетевой нагрузки. Клиенты по-прежнему смогут подключаться к серверам центра обработки данных А.

  4. Затем выполняются все необходимые обновления сетевой инфраструктуры.

  5. Перемещение кластерного сервера почтовых ящиков в центр обработки данных А.

  6. Добавление для сайта Active Directory Dublin IP-адресов серверов, перенесенных во время активации.

  7. Оба центра обработки данных восстановлены в исходное состояние.

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

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

Рабочий: рабочий (общего назначения) — один сайт Active Directory

Если организации потребуется решение с автоматической активацией резервного сайта, тогда ей придется развертывать решение типа «Рабочий: рабочий (общего назначения)». Это решение предполагает развертывание резервных серверов на одном сайте Active Directory, который охватывает оба центра обработки данных (см. рисунок ниже).


Производство:Развертывание в производственной среде (общего назначения)

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

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


Пример развертывания схемы «Рабочий: рабочий (общего назначения)»
Пример развертывания схемы «Рабочий: теплый (общего назначения)»
Пример развертывания схемы «Рабочий: теплый (выделенный)»