Избыточность теней в Exchange Server

В Exchange 2010 г. была введена избыточность для предоставления избыточных копий сообщений перед их доставкой в почтовые ящики. В Exchange 2010 г. избыточность теней задерживала удаление сообщения из базы данных очереди на транспортном сервере hub, пока сервер не подтвердил, что следующий переход на пути доставки сообщений завершил доставку. Если следующий переход не удалось, прежде чем сообщить об успешной доставке обратно на транспортный сервер Hub, сервер повторно возвращает сообщение на следующий переход. Exchange 2010 г. Транспортные серверы hub использовали глагол XSHADOW для рекламы своей поддержки избыточности теней. Если сервер исходных сообщений не поддерживает избыточность теней, Exchange 2010 г. используется задержка подтверждения на основе установленного интервала времени в соединители приемнике, чтобы сделать избыточную копию сообщения.

Exchange 2016 и Exchange 2019 г. имеют те же улучшения, которые были сделаны для теневой избыточности в Exchange 2013 г. Транспортные службы на сервере почтовых ящиков теперь делают резервную копию любого сообщения, которое оно получает до подтверждения получения сообщения на отправляющий сервер. Сохранение избыточных копий сообщений в транзите — это более чем лучшее усилие, которое может работать или не работать, так как теперь избыточность теней не зависит от поддерживаемых функций сервера отправки (поддержка или отсутствие поддержки избыточности теней не имеет значения). Это гарантирует, что пока все сообщения в конвейере транспорта находятся в пути, для них имеются резервные копии. Если Exchange определяет, что исходное сообщение было потеряно при транзите, резервная копия сообщения будет переделана.

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

Компоненты теневого резервирования

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

Термин Описание
Граница высокой доступности транспорта Группа доступности базы данных (DAG) в средах DAG или сайт Active Directory в средах без DAG. Для DAG, охватывающих несколько сайтов Active Directory, сам DAG по-прежнему является границей (а не сайта).

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

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

Требования для теневого резервирования

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

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

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

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

  • В одной Exchange серверных средах.

  • В DAG, подготовка которых не завершена.

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

Теневое резервирование включено по умолчанию

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

Параметр Значение по умолчанию Описание
ShadowRedundancyEnabled по Set-TransportConfig $true $true: Избыточность теней включена на всех серверах почтовых ящиков в организации.

$false. Избыточность теней отключена на всех серверах почтовых ящиков в организации.

RejectMessageOnShadowFailure on Set-TransportConfig $false $false: Если теневая копия сообщения не может быть создана, основное сообщение все равно принимается серверами почтовых ящиков в организации. Когда эти сообщения находятся в пути, их резервные копии не сохраняются.

$true. Сообщение не принимается или не признается любым сервером почтовых ящиков в организации, пока не будет успешно создана теневая копия сообщения. Если не удается создать теневую копию сообщения, основное сообщение будет отклонено с временной ошибкой, но отправляющий сервер может еще раз передать сообщение. Код ответа SMTP .451 4.4.0 Message failed to be made redundant Для всех сообщений в организации, находящихся в пути, сохраняются резервные копии.

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

Этот параметр имеет смысл только при параметре ShadowRedundancyEnabled $true.

Порядок создания теневых сообщений

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

  • Сообщения, полученные из-за границы высокой доступности транспорта (DAG или сайта Active Directory в средах без DAG).

  • Сообщения, отправленные за пределы границы высокой доступности транспорта.

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

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

Сообщения, полученные из-за границы высокой доступности транспорта

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

Создание теневых сообщений.

  1. Отправляющий сервер передает сообщение в службу транспорта на сервере почтовых ящиков. Сервер почтовых ящиков является основным сервером, а сообщение — основным сообщением.

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

    • Если основной сервер является участником DAG, он подключается к другому серверу почтовых ящиков в той же DAG. Если DAG охватывает несколько сайтов Active Directory, сервер почтовых ящиков на другом сайте Active Directory предпочтительный по умолчанию (значение параметра ShadowMessagePreferenceSetting в комлете Set-TransportConfig PreferRemoteявляется , RemoteOnly LocalOnlyно его можно изменить или ).

    • Если основной сервер не является членом DAG, основной сервер подключается к другому серверу почтовых ящиков на том же сайте Active Directory (независимо от значения параметра ShadowMessagePreferenceSetting ).

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

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

Сообщения, отправленные за пределы границы высокой доступности транспорта

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

Сообщения, передаваемые внутри границы высокой доступности транспорта

Маршрутия сообщений оптимизирована таким образом, что, когда конечный пункт назначения находится на сайте DAG или Active Directory, обычно не требуется несколько переходов между серверами в пункте назначения DAG или на сайте. После того как сообщение принимается службой транспорта на сервере почтовых ящиков в пункте назначения DAG или Active Directory, следующий переход для сообщения обычно является конечным пунктом назначения (например, сервер почтовых ящиков, на который хранится активная копия почтового ящика назначения). Цель избыточности теней, которая заключается в том, чтобы сохранить две копии сообщения в транзите, выполняется, когда одна теневая копия сообщения существует в любом месте на сайте DAG или Active Directory. Обычно несколько прыжков в пределах одной и той же границы высокой доступности транспорта требуются только в сценариях отработки отказа в DAG, для которой необходимо, чтобы командлет Redirect-Message опустошал очереди активных сообщений.

Теневая избыточность с Exchange транспортными серверами hub 2010 на том же сайте Active Directory в Exchange 2016 г.

Когда транспортный сервер Exchange 2010 г. передает сообщение на сервер почтовых ящиков Exchange 2016 г. на том же сайте Active Directory, транспортный сервер Exchange 2010 г. рекламирует поддержку избыточности теней с помощью команды XSHADOW, но сервер почтовых ящиков не рекламирует поддержку избыточности теней. Это не позволяет Exchange транспортному серверу hub 2010 создать теневую копию сообщения на сервере почтовых ящиков Exchange 2016 г.

Когда служба транспорта на сервере почтовых ящиков Exchange 2016 г. передает сообщение на транспортный узел Exchange 2010 г. на том же сайте Active Directory, сервер почтовых ящиков Exchange 2016 г. затеняет сообщение для транспортного сервера hub 2010 Exchange 2010 г. После того как сервер почтовых ящиков Exchange 2016 г. получает подтверждение от транспортного сервера Exchange 2010 г. об успешном получении сообщения, сервер почтовых ящиков Exchange 2016 г. перемещает успешно обработанное сообщение в сеть безопасности. Однако успешно обработанные сообщения, хранимые в сети безопасности Exchange 2016 г., никогда не будут повторно отправлены на транспортные Exchange 2010 г.

Время ожидания SMTP

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

Если какой-либо из сеансов SMTP будет завершен до успешного создания и подтверждения теневой копии сообщения, результат контролируется параметром RejectMessageOnShadowFailure в комлете Set-TransportConfig . По умолчанию значение этого $falseпараметра означает, что основное сообщение принимается без создания теневой копии. Если значение этого параметра основное $true сообщение отклоняется с переходной ошибкой 451 4.4.0.

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

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

Источник Значение по умолчанию Описание
ShadowMessagePreferenceSetting on Set-TransportConfig PreferRemote Этот параметр используется только в том случае, если основной сервер, который пытается сделать теневую копию сообщения, является членом DAG, охватывающего несколько сайтов Active Directory.
  • PreferRemote. Попробуйте сделать теневую копию сообщения на члене DAG на другом сайте Active Directory на основе количества попыток, заданных параметром MaxRetriesForRemoteSiteShadow . В случае сбоя операции попробуйте сделать теневую копию сообщения на члене DAG на локальном сайте Active Directory на основе количества попыток, заданных параметром MaxRetriesForLocalSiteShadow .
  • LocalOnly. Попробуйте сделать теневую копию сообщения только на члене DAG на локальном сайте Active Directory на основе количества попыток, заданных параметром MaxRetriesForLocalSiteShadow .
  • RemoteOnly. Попробуйте сделать теневую копию сообщения только на члене DAG на другом сайте Active Directory на основе количества попыток, заданных параметром MaxRetriesForRemoteSiteShadow .
MaxRetriesForRemoteSiteShadow на Set-TransportConfig 4 Этот параметр указывает максимальное количество попыток создания теневой копии сообщения на другом сервере в DAG, когда значение параметра ShadowMessagePreferenceSetting PreferRemote (значение по умолчанию) RemoteOnlyили .

Этот параметр используется только в том случае, если сервер почтовых ящиков является членом DAG, охватывающего несколько сайтов Active Directory.

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

  • $true. Основное сообщение отклоняется с переходной ошибкой.
  • $false. Основное сообщение принимается в любом случае, но не является избыточным.
MaxRetriesForLocalSiteShadow на Set-TransportConfig 2 Этот параметр указывает максимальное количество попыток создания теневой копии сообщения на другом сервере почтовых ящиков на локальном сайте Active Directory, когда:
  • Сервер почтовых ящиков является членом DAG, охватывающего несколько сайтов Active Directory, и значение параметра ShadowMessagePreferenceSetting PreferRemote (значение по умолчанию) LocalOnlyили .
  • Сервер почтовых ящиков является членом DAG, который находится на одном сайте Active Directory.
  • Сервер почтовых ящиков не является участником DAG.

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

  • $true. Основное сообщение отклоняется с переходной ошибкой.
  • $false. Основное сообщение принимается в любом случае, но не является избыточным.
ConnectionInactivityTimeout на Set-ReceiveConnector 5 минут для соединителей получения в службе транспорта на серверах почтовых ящиков Этот параметр указывает максимальное время, в течение которого открытое подключение SMTP к исходному серверу обмена сообщениями может находиться в состоянии бездействия, прежде чем оно будет закрыто. Значение данного параметра должно быть больше значения параметра ConnectionTimeout.
ConnectionTimeout на Set-ReceiveConnector 10 минут для соединителей получения в службе транспорта на серверах почтовых ящиков Этот параметр указывает максимальное время, в течение которого подключение SMTP к исходному серверу обмена сообщениями может оставаться открытым, даже если сервер передает данные. Значение данного параметра должно быть больше значения параметра ConnectionInactivityTimeout.
ConnectionInactivityTimeOut на set-SendConnector 10 минут Этот параметр задает максимальное количество времени, в течение которого подключение по протоколу SMTP к конечному серверу обмена сообщениями может оставаться открытым при его бездействии.

Как хранятся теневые сообщения

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

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

Теневой сервер определяет состояние удаления теневых сообщений в теневой очереди путем опроса основного сервера. Если теневой сервер создает сеанс SMTP с основным сервером по какой-либо причине (в том числе при передаче других несвязанных сообщений), теневой сервер отправляет команду XQDISCARD, чтобы определить состояние удаления основного сообщения. В противном случае теневой сервер автоматически откроет сеанс SMTP с первичным сервером после предварительного интервала времени (параметр ShadowHeartbeatFrequency в комлете Set-TransportConfig , значение по умолчанию — 2 минуты).

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

SMTP-связь между теневым сервером и основным сервером используется в качестве пульса, определяющего доступность серверов. Если теневому серверу не удается открыть сеанс SMTP с основным сервером после предварительно заданного интервала времени (параметр ShadowResubmitTimeSpan в командлете Set-TransportConfig; значение, используемое по умолчанию: 3 часа), теневой сервер объявит себя основным сервером, объявит теневые сообщения основными сообщениями и передаст сообщения в следующий прыжок. Но каждый раз, когда теневой сервер обнаруживает, что идентификатор базы данных очереди основного сервера изменился, теневой сервер также объявляет себя основным сервером, объявляет теневые сообщения основными сообщениями и передает сообщения в следующий прыжок. Это может произойти перед передачей значения параметра ShadowResubmitTimeSpan.

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

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

  • Состояние удаления, которое необходимо отправить на теневые серверы.

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

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

  • сравнение исходного идентификатора базы данных и текущего идентификатора базы данных очереди, где хранится основная копия сообщения;

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

  • обработка уведомлений об удалении для основных серверов.

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

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

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

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

Параметр Значение по умолчанию Описание
ShadowHeartbeatFrequency на Set-TransportConfig 2 минуты Максимальный период времени, в течение которого теневой сервер ждет перед открытием SMTP-подключения к основному серверу, чтобы проверить состояние удаления из сообщения.
ShadowResubmitTimeSpan на Set-TransportConfig 3 часа Время ожидания сервера до принятия решения о том, что на основном сервере произошел сбой, и присвоения владения теневыми сообщениями в теневой очереди для недоступного основного сервера.

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

ShadowMessageAutoDiscardInterval на Set-TransportConfig 2 дней Время, в течение которого сервер сохраняет события удаления для успешно доставленных сообщений. Основной сервер ставит события удаления в очередь, пока не получит запрос от теневого сервера. Тем не менее если теневой сервер не запрашивает основной сервер в течение периода, указанного в этом параметре, основной сервер удаляет события удаления, поставленные в очередь.
SafetyNetHoldTime по Set-TransportConfig 2 дней Время, в течение которого успешно обработанные сообщения хранятся в сети безопасности. Неподтвержденные теневые сообщения в конечном итоге будут удалены сети безопасности после истечении определенного срока — суммы значений параметров SafetyNetHoldTime и MessageExpirationTimeout в командлете Set-TransportService.
MessageExpirationTimeout по Set-TransportService 2 дней Как долго сообщение может оставаться в очереди до истечения срока его действия.

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

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

Сценарий восстановления Выполняемые действия
Сервер Mailbox01 возобновляет работу с использованием новой базы данных очереди до того как было передано значение параметра ShadowResubmitTimeSpan (по умолчанию 3 часа).

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

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

Максимальная задержка при отправке сообщений после обнаружения новой базы данных очереди определяется значением параметра ShadowHeartbeatFrequency (по умолчанию 2 минуты).

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

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

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

Максимальная задержка отправки сообщений — это значение параметра ShadowResubmitTimeSpan .