Общие сведения о теневой избыточности

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

Последнее изменение раздела: 2010-01-25

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

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

В системе Microsoft Exchange Server 2007 для роли транспортного сервера-концентратора реализована функция транспортной корзины. Транспортный сервер-концентратор Exchange 2007 поддерживает очередь сообщений, недавно доставленных получателям, чьи почтовые ящики находятся на кластерном сервере почтовых ящиков. Если в результате сбоя происходит отработка отказа, кластерный сервер почтовых ящиков автоматически отправляет каждому транспортному серверу-концентратору на сайте Active Directory запрос на повторную отправку сообщений, находящихся в очереди транспортной корзины. Это позволяет предотвратить потерю почты во время передачи управления кластером. Хотя при этом и создается некоторый уровень транспортной избыточности, данный способ применим только для доставки сообщений в среде с непрерывной репликацией в кластере и не затрагивает возможность потери сообщений при их передаче между транспортным сервером-концентратором и пограничным транспортным сервером.

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

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

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

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

Необходимы сведения о других задачах управления, связанных с управлением транспортными серверами? См. раздел Управление транспортными серверами.

Содержание

Компоненты теневой избыточности

Поток сообщений с теневой избыточностью

Диспетчер теневой избыточности

Обработка сообщений после простоя

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

Компоненты теневой избыточности

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

Компоненты теневой избыточности

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

В начало

Поток сообщений с теневой избыточностью

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

Поток сообщений при теневой избыточности

В этом сценарии поток сообщений проходит следующие этапы.

1. Транспортный сервер-концентратор доставляет сообщение на пограничный транспортный сервер.
   1. Транспортный сервер-концентратор открывает с пограничным транспортным сервером сеанс SMTP.
   2. Пограничный транспортный сервер объявляет поддержку теневой избыточности.
   3. Транспортный сервер-концентратор уведомляет пограничный транспортный сервер об отслеживании состояния удаления.
   4. Транспортный сервер-концентратор передает сообщение на пограничный транспортный сервер.
   5. Пограничный транспортный сервер подтверждает получение сообщения и сохраняет имя транспортного сервера-концентратора для отправки сведений об удалении для этого сообщения.
   6. Транспортный сервер-концентратор перемещает сообщение в теневую очередь для пограничного транспортного сервера и помечает этот сервер как основной. Транспортный сервер-концентратор становится теневым сервером.
2. Пограничный транспортный сервер доставляет сообщение для следующего прыжка.
   1. Пограничный транспортный сервер передает сообщение на сторонний почтовый сервер.
   2. Сторонний почтовый сервер подтверждает получение сообщения.
   3. После доставки пограничный транспортный сервер обновляет состояние удаления для сообщения.
3. Транспортный сервер-концентратор запрашивает у пограничного транспортного сервера состояние удаления (при успешном выполнении операции).
   1. В конце каждого сеанса SMTP с пограничным транспортным сервером транспортный сервер-концентратор запрашивает у пограничного транспортного сервера состояние удаления для ранее переданных сообщений. Если транспортный сервер-концентратор еще не открыл ни одного сеанса SMTP с пограничным транспортным сервером после передачи первоначального сообщения, он через некоторое время открывает сеанс SMTP с пограничным транспортным сервером просто для запроса состояния удаления.
   2. Пограничный транспортный сервер проверяет локальное состояние удаления и отправляет назад список доставленных сообщений, а затем удаляет сведения об удалении.
   3. Транспортный сервер-концентратор удаляет указанные в списке сообщения из своей теневой очереди.
4. Транспортный сервер-концентратор запрашивает у пограничного транспортного сервера состояние удаления и передает сообщение повторно (при сбое).
   1. Если транспортному серверу-концентратору не удается связаться с пограничным транспортным сервером, он продолжает выполнять роль основного сервера и повторно отправляет сообщения из теневой очереди.
   2. Повторно переданные сообщения доставляются на другой пограничный транспортный сервер, и рабочий процесс начинается с этапа 1.

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

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

Сценарий для нескольких прыжков

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

Пример топологии для сценария нескольких прыжков

Предположим, что сообщение отправлено пользователем с сайта в Чикаго пользователю с сайта в Дублине. Чтобы попасть на сайт в Дублине, это сообщение должно пройти через сайты в Нью-Йорке и Лондоне. В этом случае происходит следующее.

1. Транспортный сервер-концентратор в Чикаго отправляет сообщение на транспортный сервер-концентратор в Нью-Йорке и сохраняет теневую копию этого сообщения.
2. Транспортный сервер-концентратор в Нью-Йорке отправляет сообщение на транспортный сервер-концентратор в Лондоне и помещает в очередь состояние удаления для концентратора в Чикаго.
3. Концентратор в Чикаго запрашивает у концентратора в Нью-Йорке состояние удаления и получает для данного сообщения уведомление об удалении. После этого он может удалить теневое сообщение из своей базы данных. Тот факт, было ли сообщение доставлено из Лондона в Дублин, никак не влияет на удаление теневого сообщения на сервере в Чикаго.

Взаимодействие систем

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

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

1. Exchange устанавливает SMTP-подключение к целевому серверу.
2. Целевой сервер не объявляет поддержку теневой избыточности.
3. Поскольку целевой сервер не поддерживает избыточность, Exchange выполняет для каждого сообщения следующие операции:
   1. доставляет сообщение на целевой сервер;
   2. диспетчер теневой избыточности отмечает, что это сообщение доставлено для следующего прыжка;
   3. удаляет сообщение после его доставки для всех следующих прыжков.

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

1. Отправляющий сервер устанавливает SMTP-подключение к Exchange.
2. Exchange объявляет поддержку теневой избыточности.
3. Отправляющий сервер не поддерживает теневую избыточность и поэтому не использует ее. Он доставляет сообщения на сервер Exchange.
4. Для каждого получаемого сообщения Exchange выполняет следующие действия:
   1. доставляет сообщения для следующего прыжка или создает его теневую копию;
   2. отправляет подтверждение на отправляющий сервер.

Отложенное подтверждение

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

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

Значение тайм-аута отложенного подтверждения управляется с помощью атрибута MaxAcknowledgementDelay каждого соединителя получения. Значение по умолчанию: 30 секунд. Дополнительные сведения о настройке данного атрибута см. в разделе Настройка теневой избыточности.

В начало

Диспетчер теневой избыточности

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

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

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

Диспетчер теневой избыточности осуществляет следующие операции для всех теневых сообщений, находящихся в теневых очередях сервера:

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

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

Пульс

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

Для пульса имеется значение тайм-аута. Если в течение этого периода подключения к серверу, для которого диспетчер теневой избыточности сохраняет теневую очередь, отсутствуют, этот сервер пытается выполнить SMTP-подключение к основному серверу только для запроса состояния удаления и сброса таймера. Значение тайм-аута управляется с помощью параметра ShadowHeartbeatTimeoutInterval командлета Set-TransportConfig и по умолчанию равно 300 секундам.

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

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

В начало

Обработка сообщений после простоя

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

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

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

Обработка сообщений при сценариях восстановления

Сценарий восстановления	Действия для сообщений с альтернативными маршрутами	Действия для сообщений без альтернативных маршрутов
Hub01 возобновляет работу с новой базой данных.	Когда Hub01 становится недоступен, каждый сервер, на котором в очереди есть теневые сообщения для Hub01, вступает во владение ими и повторно передает их. После этого сообщения доставляются в назначения по альтернативным маршрутам. Общая задержка для сообщений равна произведению интервала тайм-аута и числа повторных попыток для пульса, настроенных в организации.	Эти сообщения остаются в теневой очереди на каждом сервере, на котором в очереди имеются теневые сообщения для Hub01. Когда Hub01 возобновляет работу с новым идентификатором базы данных, теневые серверы определяют эту базу данных как новую и повторно передают на Hub01 сообщения из теневой очереди. Это равнозначно внезапному обнаружению альтернативного маршрута для этих сообщений. Общая задержка для сообщений зависит от длительности простоя.
Hub01 возобновляет работу с той же самой базой данных.	Hub01 доставляет сообщения, находящиеся в его очередях. Это приводит к дублирующейся доставке данных сообщений. Пользователи почтовых ящиков Exchange не увидят дублирующиеся сообщения из-за работы функции поиска повторяющихся данных. Однако получатели, использующие другие системы, могут получить дублирующиеся копии. Общая задержка для сообщений равна произведению интервала тайм-аута и числа повторных попыток для пульса, настроенных в организации.	Hub 01 доставляет сообщения, находящиеся в его очередях, а затем отправляет уведомления об удалении на теневые серверы. Общая задержка для сообщений зависит от длительности простоя.

В начало

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

Exchange 2010 представляет два следующих экземпляра расширенных прав, которые необходимы для теневой избыточности:

• ms-Exch-SMTP-Accept-XSHADOW;
• ms-Exch-SMTP-Send-XSHADOW.

После установки SMTP-подключения к транспортному серверу Exchange 2010 он объявляет поддержку теневой избыточности, если на используемом соединителе получения имеется расширенное право ms-Exch-SMTP-Accept-XSHADOW. Кроме того, на соединителе получения должен использоваться механизм проверки подлинности «Проверка подлинности Exchange Server» или «Внешняя защита».

Когда транспортный сервер Exchange 2010 устанавливает SMTP-подключение с другим сервером, который объявляет поддержку теневой избыточности, он передает команду XSHADOW только в том случае, если сеансу предоставлено расширенное право ms-Exch-SMTP-Send-XSHADOW.

По умолчанию эти расширенные права предоставляются группе «Серверы Exchange» для всех внутренних соединителей отправки и соединителей получения.

Примечание.

Теневую избыточность можно включить и выключить для всей организации с помощью параметра ShadowRedundancyEnabled командлета Set-TransportConfig. Этот параметр переопределяет описанные в данном разделе расширенные права. Если теневая избыточность в организации выключена, Exchange не объявляет поддержку теневой избыточности и не передает команды XSHADOW даже в том случае, когда SMTP-сеансу предоставлены необходимые расширенные права.

В начало