Теневая избыточность в Exchange Server
Теневая избыточность была введена в Exchange 2010 для предоставления избыточных копий сообщений перед их доставкой в почтовые ящики. В Exchange 2010 теневая избыточность отложила удаление сообщения из базы данных очереди на транспортном сервере-концентраторе до тех пор, пока сервер не проверит доставку следующего прыжка в пути доставки сообщений. Если следующий прыжок завершился сбоем, прежде чем сообщить об успешной доставке обратно на транспортный сервер-концентратор, сервер повторно перенаправил сообщение на следующий прыжок. Транспортные серверы-концентратор Exchange 2010 использовали команду XSHADOW для объявления поддержки теневой избыточности. Если исходный сервер обмена сообщениями не поддерживал теневой избыточности, Exchange 2010 использовал отложенное подтверждение на основе заданного интервала времени в соединителе получения для создания избыточной копии сообщения.
В Exchange 2016 и Exchange 2019 реализованы те же улучшения, которые были внесены в теневой избыточности в Exchange 2013: служба транспорта на сервере почтовых ящиков теперь создает избыточное копирование любого сообщения, которое она получает, прежде чем подтверждает получение сообщения на сервер отправки. Поддержание избыточных копий сообщений при передаче — это не просто лучшие усилия, которые могут или не могут работать, так как теперь теневая избыточность не зависит от поддерживаемых функций отправляющего сервера (поддержка или отсутствие поддержки теневой избыточности не имеет значения). Это гарантирует, что пока все сообщения в конвейере транспорта находятся в пути, для них имеются резервные копии. Если Exchange определяет, что исходное сообщение было потеряно при передаче, избыточное копирование сообщения будет повторно выполнено.
Дополнительные сведения о функциях высокого уровня доступности транспорта в Exchange Server см. в статье Высокий уровень доступности транспорта в Exchange Server. Дополнительные сведения об избыточности сообщений после успешной доставки сообщения см. в разделе Safety Net в Exchange Server.
Компоненты теневого резервирования
В таблице ниже описаны компоненты системы теневого резервирования в службе транспорта на сервере почтовых ящиков. Эти термины используются во всей статье.
| Термин | Описание |
|---|---|
| Граница высокой доступности транспорта | Группа доступности базы данных (DAG) в средах DAG или сайт Active Directory в средах, отличных от DAG. Для групп доступности баз данных, охватывающих несколько сайтов Active Directory, само DAG по-прежнему является границей (а не сайтом). Когда сообщение поступает на сервер почтовых ящиков в пределах границы высокой доступности транспорта, Exchange пытается сохранить две избыточные копии сообщения на серверах почтовых ящиков в пределах границы. Когда сообщение покидает границу высокого уровня доступности транспорта, Exchange прекращает обслуживание избыточных копий сообщения. |
| Основное сообщение | Сообщение, отправленное в транспортный конвейер для доставки. |
| Теневое сообщение | Избыточная копия сообщения, которую теневой сервер сохраняет, пока не убедится, что основное сообщение было успешно обработано основным сервером. |
| Основной сервер | Сервер почтовых ящиков, который в настоящее время обрабатывает основное сообщение. |
| Теневой сервер | Сервер почтовых ящиков, хранящий теневое сообщение для основного сервера. Сервер почтовых ящиков может одновременно быть основным сервером для некоторых сообщений и теневым сервером для других сообщений. |
| Теневая очередь | Очередь доставки, где теневой сервер хранит теневые сообщения. Для сообщений с несколькими получателями каждый следующий прыжок для основного сообщения требует отдельной теневой очереди. |
| Состояние удаления | Информация, которую сервер почтовых ящиков хранит для теневых сообщений, указывающая на то, что основное сообщение было успешно обработано. |
| Уведомление об удалении | Ответ, который теневой сервер получает от основного сервера, и который указывает, что теневое сообщение готово к отклонению. |
| Сеть безопасности | Улучшенная версия контейнерной корзины транспорта в Exchange 2013 или более поздней версии. Сообщения, которые были успешно обработаны или доставлены в почтовый ящик получателя транспортной службой на сервере почтовых ящиков, перемещаются в сеть безопасности. Дополнительные сведения см. в разделе Safety Net в Exchange Server. |
| Диспетчер теневой избыточности | Компонент транспорта, управляющий теневой избыточностью. |
| Пульс | Процесс, который позволяет основным серверам и теневым серверам проверять доступность друг друга. |
Требования для теневого резервирования
Хотя это может показаться очевидным, для теневой избыточности требуется несколько серверов почтовых ящиков:
Если сервер почтовых ящиков не является членом daG, другие серверы почтовых ящиков должны находиться на локальном сайте Active Directory.
Если сервер почтовых ящиков является участником DAG, другие серверы почтовых ящиков должны принадлежать той же самой DAG. Другие члены DAG могут находиться на локальном сайте Active Directory или на удаленном сайте. По умолчанию, если DAG охватывает несколько сайтов Active Directory, теневая избыточность предпочитает создание избыточной копии сообщения на удаленном сайте для обеспечения устойчивости сайта.
Ниже указаны ситуации, в которых системе теневого резервирования не удается защитить сообщения, находящиеся в пути.
В средах с одним сервером Exchange.
В DAG, подготовка которых не завершена.
При одновременном отказе двух или большего количества серверов почтовых ящиков, участвующих в работе функции теневого резервирования сообщения.
Теневое резервирование включено по умолчанию
По умолчанию теневое резервирование включено глобально в службе транспорта на всех серверах почтовых ящиков. В таблице ниже описаны параметры, которые позволяют использовать теневое резервирование.
| Параметр | Значение по умолчанию | Описание |
|---|---|---|
| ShadowRedundancyEnabled по Set-TransportConfig | $true |
$true: на всех серверах почтовых ящиков в организации включена теневая избыточность.
|
| RejectMessageOnShadowFailure в Set-TransportConfig | $false |
$false: если теневая копия сообщения не может быть создана, основное сообщение в любом случае принимается серверами почтовых ящиков в организации. Когда эти сообщения находятся в пути, их резервные копии не сохраняются.
Примечание. Используйте Этот параметр имеет смысл только в том случае, если ShadowRedundancyEnabled имеет значение |
Порядок создания теневых сообщений
Главная цель теневого резервирования состоит в том, чтобы всегда хранить две копии сообщения в пределах границы высокой доступности транспорта, пока сообщение находится в пути. Место и время создания резервной копии сообщения зависит от того, откуда прибыло сообщение и куда оно направляется. Существует три указанных ниже определяющих фактора, используемых при создании теневых сообщений.
Сообщения, полученные за пределами границы высокого уровня доступности транспорта (daG или сайта Active Directory в средах, отличных от DAG).
Сообщения, отправленные за пределы границы высокой доступности транспорта.
Сообщения, полученные от службы отправки транспорта почтовых ящиков с сервера почтовых ящиков в пределах границы высокой доступности.
Теневая избыточность никогда не отслеживает теневые сообщения через границу высокой доступности транспорта. Когда сообщение пересекает границу высокой доступности транспорта, начинается или перезапускается теневая избыточность. Это сокращает трафик обслуживания теневых сообщений и предотвращает повторную отправку теневых сообщений через границу высокого уровня доступности транспорта. Транспортные серверы-концентратор Exchange 2010 — это особый случай, который рассматривается далее в этом разделе.
Сообщения, полученные из-за границы высокой доступности транспорта
Когда служба транспорта на сервере почтовых ящиков получает сообщение из-за границы высокой доступности транспорта, то для этого сервера почтовых ящиков неважно наличие поддержки теневого резервирования на отправляющем сервере. Пока теневое резервирование включено, сервер почтовых ящиков, принимающий сообщение, создает резервную копию сообщения на другом сервере почтовых ящиков в пределах границы высокой доступности транспорта, прежде чем отправить подтверждение получения сообщения на отправляющий сервер. Ниже показан пример такого процесса.
Отправляющий сервер передает сообщение в службу транспорта на сервере почтовых ящиков. Сервер почтовых ящиков является основным сервером, а сообщение — основным сообщением.
Если исходный сеанс SMTP с сервером обмена сообщениями все еще активен, служба транспорта на основном сервере открывает новый параллельный сеанс SMTP со службой транспорта на другом сервере почтовых ящиков в организации, чтобы создать резервную копию сообщения.
Если основной сервер является участником DAG, он подключается к другому серверу почтовых ящиков в той же DAG. Если daG охватывает несколько сайтов Active Directory, по умолчанию предпочтителен сервер почтовых ящиков на другом сайте Active Directory (значение по умолчанию параметра ShadowMessagePreferenceSetting в командлете Set-TransportConfig —
PreferRemote, но его можно изменить наRemoteOnlyилиLocalOnly).Если сервер-источник не является членом DAG, сервер-источник подключается к другому серверу почтовых ящиков на том же сайте Active Directory (независимо от значения параметра ShadowMessagePreferenceSetting ).
Основной сервер передает копию сообщения в службу транспорта на другом сервере почтовых ящиков, а служба транспорта на другом сервере почтовых ящиков подтверждает, что копия сообщения успешно создана. Копия сообщения является теневым сообщением, и сервер почтовых ящиков, на котором она находится, является теневым сервером по отношению к основному серверу. Сообщение присутствует в теневой очереди на теневом сервере.
После того как основной сервер получает подтверждение от теневого сервера, он отправляет подтверждение получения основного сообщения на исходный сервер обмена сообщениями в исходном сеансе SMTP, и сеанс SMTP будет закрыт.
Сообщения, отправленные за пределы границы высокой доступности транспорта
Когда сервер почтовых ящиков передает сообщение за границу высокой доступности транспорта, сервер обмена сообщениями на другой стороне подтверждает успешное получение сообщения, и сервер почтовых ящиков перемещает это сообщение в сеть безопасности. После успешной передачи основного сообщения через границу высокой доступности транспорта повторная отправка сообщения из сети безопасности не выполняется. Дополнительные сведения о Safety Net см. в разделе Safety Net в Exchange Server.
Сообщения, передаваемые внутри границы высокой доступности транспорта
Маршрутизация сообщений оптимизирована таким образом, что, когда конечное место назначения находится на сайте DAG или Active Directory, несколько прыжков между серверами в целевом DAG или сайте обычно не требуются. После того как сообщение будет принято службой транспорта на сервере почтовых ящиков в целевой DAG или Active Directory, следующий прыжок сообщения обычно является конечным назначением (например, сервер почтовых ящиков, на котором хранится активная копия целевого почтового ящика). Цель теневой избыточности, связанная с сохранением двух копий сообщения при передаче, выполняется, если одна теневая копия сообщения существует в любом месте сайта DAG или Active Directory. Обычно несколько прыжков в пределах одной и той же границы высокой доступности транспорта требуются только в сценариях отработки отказа в DAG, для которой необходимо, чтобы командлет Redirect-Message опустошал очереди активных сообщений.
Теневая избыточность с помощью транспортных серверов-концентраторов Exchange 2010 на том же сайте Active Directory в организациях Exchange 2016
Когда транспортный сервер-концентратор Exchange 2010 передает сообщение на сервер почтовых ящиков Exchange 2016 на том же сайте Active Directory, транспортный сервер концентратора Exchange 2010 объявляет о поддержке теневой избыточности с помощью команды XSHADOW, но сервер почтовых ящиков не объявляет поддержку теневой избыточности. Это предотвращает создание теневой копии сообщения на сервере почтовых ящиков Exchange 2016 на сервере почтовых ящиков Exchange 2010.
Когда транспортная служба на сервере почтовых ящиков Exchange 2016 передает сообщение транспорту-концентратору Exchange 2010 на том же сайте Active Directory, сервер почтовых ящиков Exchange 2016 затеняет сообщение для транспортного сервера концентратора Exchange 2010. После того как сервер почтовых ящиков Exchange 2016 получит подтверждение от транспортного сервера концентратора Exchange 2010 о том, что сообщение было успешно получено, сервер почтовых ящиков Exchange 2016 перемещает успешно обработанное сообщение в Safety Net. Однако успешно обработанные сообщения, хранящиеся в Safety Net почтовым ящиком Exchange 2016, никогда не отправляются повторно на транспортные серверы концентратора Exchange 2010.
Время ожидания SMTP
Во время попытки создания резервной копии сообщения может истечь время ожидания для соединения SMTP между серверами (между передающим и основным серверами либо между основным и теневым серверами). Соединители получения и соединители отправки имеют параметр ConnectionInactivityTimeOut, указывающий на фактическую передачу данных через соединитель. Соединители получения также имеют абсолютный параметр ConnectionTimeOut.
Если какой-либо из сеансов SMTP истекает до успешного создания и подтверждения теневой копии сообщения, результат управляется параметром RejectMessageOnShadowFailure в командлете Set-TransportConfig . По умолчанию значение этого параметра равно $false, что означает, что основное сообщение принимается без создания теневой копии. Если значение этого параметра равно $true , основное сообщение отклоняется с временной ошибкой 451 4.4.0.
Если теневая копия сообщения успешно создана, но истекло время ожидания для сеанса SMTP между отправляющим и основным серверами, основной сервер принимает и обрабатывает основное сообщение. Отправляющий сервер повторно доставит неподтвержденное сообщение, но функция обнаружения дублирующихся сообщений не позволит отобразить дублирующиеся сообщения для пользователей почтовых ящиков Exchange. Когда отправляющий сервер повторно передает сообщение, основной сервер создает еще одну теневую копию сообщения. При этом нет никакой связи между теневыми сообщениями, созданными во время повторных отправок сообщений с отправляющего сервера.
В таблице ниже описаны параметры, управляющие процессом создания теневых сообщений
| Source | Значение по умолчанию | Описание |
|---|---|---|
| ShadowMessagePreferenceSetting в Set-TransportConfig | PreferRemote |
Этот параметр используется только в том случае, если сервер-источник, который пытается создать теневую копию сообщения, является членом daG, охватывающего несколько сайтов Active Directory.
|
| MaxRetriesForRemoteSiteShadow в Set-TransportConfig | 4 | Этот параметр указывает максимальное число попыток создания теневой копии сообщения на другом сервере в DAG, если значение параметра ShadowMessagePreferenceSetting равно PreferRemote (значение по умолчанию) или RemoteOnly. Этот параметр используется только в том случае, если сервер почтовых ящиков является членом daG, охватывающего несколько сайтов Active Directory. Если не удалось создать теневую копию сообщения после указанного количества попыток, результат зависит от параметра RejectMessageOnShadowFailure.
|
| MaxRetriesForLocalSiteShadow в Set-TransportConfig | 2 | Этот параметр указывает максимальное число попыток создания теневой копии сообщения на другом сервере почтовых ящиков на локальном сайте Active Directory в следующих случаях:
Если не удалось создать теневую копию сообщения после указанного количества попыток, результат зависит от параметра RejectMessageOnShadowFailure.
|
| 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 с основным сервером, основной сервер отвечает уведомлениями об удалении для сообщений, относящихся к запрашивающему теневому серверу. Уведомления об отмене хранятся на диске (не в памяти), поэтому при перезапуске службы транспорта Microsoft 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 минуты). |
| Mailbox01 возвращается к сети с той же базой данных после прохождения значения параметра ShadowResubmitTimeSpan (по умолчанию 3 часа). Этот сценарий возможен после сбоя сетевого адаптера или продолжительного сеанса технического обслуживания на сервере. |
После того как сервер Mailbox01 возобновит работу, он доставит сообщения, находящиеся в его очередях, которые уже были доставлены серверами, хранящими теневые копии сообщений для сервера Mailbox01. Это приведет к дублированию всех таких сообщений. Пользователи почтовых ящиков Exchange не будут видеть повторяющиеся сообщения из-за обнаружения повторяющихся сообщений. Тем не менее для получателей в других системах обмена сообщениями дублирующиеся сообщения, возможно, будут отображены. Максимальная задержка отправки сообщения — это значение параметра ShadowResubmitTimeSpan . |