Теневая избыточность
Область применения: Exchange Server 2013 г.
Теневая избыточность была введена в Microsoft Exchange Server 2010 году для предоставления избыточных копий сообщений перед их доставкой в почтовые ящики. В Exchange 2010 теневая избыточность отложила удаление сообщения из транспортной базы данных на транспортном сервере до тех пор, пока сервер не проверит следующий прыжок пути доставки сообщения. Если следующий прыжок завершился сбоем, прежде чем сообщить об успешной доставке на транспортный сервер, транспортный сервер повторно перенаправит сообщение на следующий прыжок. Серверы Exchange 2010 использовали команду XSHADOW для объявления поддержки теневой избыточности. Если SMTP-сервер не поддерживал теневое избыточность, Exchange 2010 использовал отложенное подтверждение на основе заданного интервала времени в соединителе получения для создания избыточной копии сообщения.
Основное улучшение теневой избыточности в Microsoft Exchange Server 2013 года заключается в том, что транспортный сервер теперь создает избыточные копии всех получаемых сообщений, прежде чем он подтвердит успешное получение сообщения обратно на отправляющий сервер. Поддержка отправляющего сервера или отсутствие поддержки теневой избыточности не имеет значения. Это помогает гарантировать, что все сообщения в транспортном конвейере Exchange 2013 становятся избыточными во время их передачи. Если Exchange 2013 определяет, что исходное сообщение было потеряно при передаче, избыточные копии сообщения повторно доставлялись.
Компоненты теневого резервирования
В следующей таблице описаны компоненты теневой избыточности. Эти термины используются во всей статье.
| Термин | Описание |
|---|---|
| Транспортный сервер | Сервер Exchange Server с очередями сообщений и отвечающий за маршрутизацию сообщений. В Exchange 2013 транспортный сервер — это сервер почтовых ящиков (транспортная служба на сервере почтовых ящиков). |
| Транспортная база данных | База данных очереди сообщений на транспортном сервере Exchange 2013. Теневые очереди и Safety Net также хранятся в транспортной базе данных. |
| Граница высокой доступности транспорта | Группа доступности базы данных (DAG) в средах DAG или сайт Active Directory в средах, отличных от DAG. Когда сообщение поступает на транспортный сервер в пределах границы высокой доступности транспорта, Exchange пытается сохранить 2 избыточные копии сообщения на транспортных серверах в пределах границы. Когда сообщение покидает границу высокого уровня доступности транспорта, Exchange прекращает обслуживание избыточных копий сообщения. |
| Основное сообщение | Сообщение, отправленное в транспортный конвейер для доставки. |
| Теневое сообщение | Избыточная копия сообщения, которую теневой сервер сохраняет, пока не убедится, что основное сообщение было успешно обработано основным сервером. |
| Основной сервер | Транспортный сервер, который в настоящее время обрабатывает основное сообщение. |
| Теневой сервер | Транспортный сервер, на котором хранится сообщение тени для сервера-источника. Транспортный сервер может быть основным сервером для некоторых сообщений и теневым сервером для других сообщений одновременно. |
| Теневая очередь | Очередь доставки, где теневой сервер хранит теневые сообщения. Для сообщений с несколькими получателями каждый следующий прыжок для основного сообщения требует отдельной теневой очереди. |
| Состояние удаления | Сведения, которые транспортный сервер сохраняет для теневых сообщений, которые указывают, что основное сообщение успешно обработано. |
| Уведомление об удалении | Ответ, который теневой сервер получает от основного сервера, и который указывает, что теневое сообщение готово к отклонению. |
| Сеть безопасности | В Exchange 2013 улучшена версия контейнерной корзины транспорта. Сообщения, которые были успешно обработаны или доставлены в почтовый ящик получателя транспортной службой на сервере почтовых ящиков, перемещаются в сеть безопасности. Дополнительные сведения см. в разделе Система безопасности. |
| Диспетчер теневой избыточности | Компонент транспорта, управляющий теневой избыточностью. |
| Пульс | Процесс, который позволяет основным серверам и теневым серверам проверять доступность друг друга. |
Требования для теневого резервирования
Хотя это может показаться очевидным, для теневой избыточности требуется несколько серверов почтовых ящиков Exchange 2013. Сервер почтовых ящиков может быть автономным сервером или серверами почтовых ящиков и серверами клиентского доступа, установленными на одном компьютере.
- Если сервер почтовых ящиков не является членом daG, другие серверы почтовых ящиков должны находиться на локальном сайте Active Directory.
- Если сервер почтовых ящиков является участником DAG, другие серверы почтовых ящиков должны принадлежать той же самой DAG. Другие серверы почтовых ящиков, принадлежащие daG, могут находиться на локальном сайте Active Directory или на удаленном сайте Active Directory. Если DAG охватывает несколько сайтов Active Directory, теневая избыточность предпочитает создавать избыточные копии сообщения на удаленном сайте Active Directory для обеспечения устойчивости сайта.
Ниже указаны ситуации, в которых системе теневого резервирования не удается защитить сообщения, находящиеся в пути.
- В средах с одним сервером Exchange.
- В DAG, подготовка которых не завершена.
- При одновременном сбое двух или более транспортных серверов, участвующих в теневой избыточности сообщения.
Теневое резервирование включено по умолчанию
По умолчанию теневая избыточность включена глобально в транспортной службе на всех серверах почтовых ящиков с помощью параметра ShadowRedundancyEnabled в командлете Set-TransportConfig . По умолчанию, если транспортной службе на сервере почтовых ящиков не удается создать избыточную копию сообщения, сообщение не отклоняется. Однако можно настроить Exchange 2013 для отклонения сообщения, если избыточная копия сообщения не создана с помощью параметра RejectMessageOnShadowFailure в командлете Set-TransportConfig . Сообщение отклоняется с временным сбоем, но отправляющий сервер может передать сообщение снова. Код ответа SMTP: 451 4.4.0 Message failed to be made redundant. Следует настроить Exchange 2013 на отклонение сообщений, которые нельзя сделать избыточными только в том случае, если в вашей организации доступно несколько серверов почтовых ящиков Exchange 2013.
В следующей таблице описаны параметры, обеспечивающие теневое избыточность.
Параметры, обеспечивающие теневое избыточность
| Параметр | Значение по умолчанию | Описание |
|---|---|---|
| ShadowRedundancyEnabled по Set-TransportConfig | $true |
|
| RejectMessageOnShadowFailure в Set-TransportConfig | $false |
Этот параметр имеет смысл только в том случае, если ShadowRedundancyEnabled имеет значение |
Порядок создания теневых сообщений
Главная цель теневого резервирования состоит в том, чтобы всегда хранить две копии сообщения в пределах границы высокой доступности транспорта, пока сообщение находится в пути. Место и время создания избыточной копии сообщения зависит от того, откуда пришло сообщение и куда оно идет. Существует три основных определяющих фактора:
- Сообщения, полученные за пределами границы высокой доступности транспорта.
- Сообщения, отправленные за пределы границы высокой доступности транспорта.
- Сообщения, полученные от службы отправки транспорта почтовых ящиков с сервера почтовых ящиков в пределах границы высокой доступности.
Граница высокого уровня доступности транспорта является одной из следующих:
- DaG для серверов почтовых ящиков, являющихся членами daG. Сюда входит DAG, охватывающая несколько сайтов Active Directory.
- Сайт Active Directory для серверов почтовых ящиков, которые не принадлежат группе daG.
Теневая избыточность никогда не отслеживает теневые сообщения через границу высокой доступности транспорта. Когда сообщение пересекает границу высокой доступности транспорта, начинается или перезапускается теневая избыточность. Это сокращает трафик обслуживания теневых сообщений и предотвращает повторы теневых сообщений через границу высокой доступности транспорта. Транспортные серверы-концентратор Exchange 2010 — это особый случай, который рассматривается далее в этом разделе.
Сообщения, полученные из-за границы высокой доступности транспорта
Когда транспортная служба на сервере почтовых ящиков Exchange 2013 получает сообщение за пределами границы высокого уровня доступности транспорта, сервер почтовых ящиков не обеспокоен поддержкой или отсутствием поддержки теневой избыточности отправляющего сервера. Пока теневое резервирование включено, сервер почтовых ящиков, принимающий сообщение, создает резервную копию сообщения на другом сервере почтовых ящиков в пределах границы высокой доступности транспорта, прежде чем отправить подтверждение получения сообщения на отправляющий сервер. Ниже показан пример такого процесса.
.gif "Создание теневых сообщений")
SMTP-сервер передает сообщение в транспортную службу на сервере почтовых ящиков. Сервер почтовых ящиков является основным сервером, а сообщение — основным сообщением.
Хотя исходный сеанс SMTP с SMTP-сервером по-прежнему активен, транспортная служба на сервере-источнике открывает новый одновременный сеанс SMTP со службой транспорта на другом сервере почтовых ящиков в организации для создания избыточной копии сообщения.
- Если основной сервер является участником DAG, он подключается к другому серверу почтовых ящиков в той же DAG. Если daG охватывает несколько сайтов Active Directory, по умолчанию рекомендуется использовать сервер почтовых ящиков на другом сайте Active Directory. Этот параметр управляется параметром ShadowMessagePreference в командлете Set-TransportService . Значение по умолчанию —
PreferRemote, но его можно изменить наRemoteOnlyилиLocalOnly. - Если сервер-источник не является членом DAG, сервер-источник подключается к другому серверу почтовых ящиков на том же сайте Active Directory независимо от значения параметра ShadowMessagePreference .
- Если основной сервер является участником DAG, он подключается к другому серверу почтовых ящиков в той же DAG. Если daG охватывает несколько сайтов Active Directory, по умолчанию рекомендуется использовать сервер почтовых ящиков на другом сайте Active Directory. Этот параметр управляется параметром ShadowMessagePreference в командлете Set-TransportService . Значение по умолчанию —
Сервер-источник передает копию сообщения в транспортную службу на другом сервере почтовых ящиков, а транспортная служба на другом сервере почтовых ящиков подтверждает, что копия сообщения успешно создана. Копия сообщения является теневым сообщением, и сервер почтовых ящиков, на котором она находится, является теневым сервером по отношению к основному серверу. Сообщение присутствует в теневой очереди на теневом сервере.
После того как сервер-источник получит подтверждение от теневых серверов, сервер-источник подтверждает получение основного сообщения исходному SMTP-серверу в исходном сеансе SMTP, и сеанс SMTP закрывается.
Сообщения, отправленные за пределы границы высокой доступности транспорта
Когда транспортный сервер Exchange 2013 передает сообщение за пределы границы высокой доступности транспорта, а SMTP-сервер с другой стороны подтверждает успешное получение сообщения, транспортный сервер перемещает сообщение в Safety Net. После успешной передачи основного сообщения через границу высокой доступности транспорта повторная отправка сообщения из сети безопасности не выполняется. Дополнительные сведения о сети безопасности см. в статье Safety Net.
Сообщения, передаваемые внутри границы высокой доступности транспорта
Маршрутизация сообщений оптимизирована в Exchange 2013, поэтому, когда конечное назначение находится на сайте DAG или Active Directory, несколько прыжков между транспортной службой на серверах почтовых ящиков в этой daG или на сайте Active Directory обычно не требуются. После того как сообщение будет принято службой транспорта на сервере почтовых ящиков в DAG или на сайте Active Directory, который содержит конечное место назначения сообщения, следующий прыжок сообщения обычно является конечным местом назначения. Цель теневой избыточности, связанная с сохранением двух копий сообщения при передаче, выполняется, если одна теневая копия сообщения существует в любом месте сайта DAG или Active Directory. Как правило, только в сценариях отработки отказа в daG, в которых командлет Redirect-Message требуется для очистки активных очередей на сервере почтовых ящиков, потребуется несколько прыжков в пределах одной границы высокой доступности транспорта.
Теневая избыточность с помощью транспортных серверов-концентраторов Exchange 2010 на том же сайте Active Directory
Когда транспортный сервер-концентратор Exchange 2010 передает сообщение на сервер почтовых ящиков Exchange 2013 на том же сайте Active Directory, транспортный сервер-концентратор Exchange 2010 объявляет о поддержке теневой избыточности с помощью команды XSHADOW, но сервер почтовых ящиков не объявляет о поддержке теневой избыточности. Это предотвращает создание теневой копии сообщения на сервере почтовых ящиков Exchange 2013 на транспортном сервере-концентраторе Exchange 2010.
Когда транспортная служба на сервере почтовых ящиков Exchange 2013 передает сообщение на транспорт-концентратор Exchange 2010 на том же сайте Active Directory, сервер почтовых ящиков Exchange 2013 затеняет сообщение для транспортного сервера концентратора Exchange 2010. После того как сервер почтовых ящиков Exchange 2013 получит подтверждение от транспортного сервера-концентратора Exchange 2010 о том, что сообщение было успешно получено, сервер почтовых ящиков Exchange 2013 перемещает успешно обработанное сообщение в Safety Net. Однако успешно обработанные сообщения, хранящиеся в службе Safety Net почтовым ящиком Exchange 2013, никогда не отправляются повторно на транспортные серверы концентратора Exchange 2010.
Время ожидания SMTP
Во время попытки создания избыточной копии сообщения smtp-соединение между отправляющий SMTP-сервером и сервером-получателем или сеанс SMTP между сервером-получателем и теневым сервером может истекать. Соединители получения и соединители отправки имеют параметр ConnectionInactivityTimeOut, указывающий на фактическую передачу данных через соединитель. Соединители получения также имеют абсолютный параметр ConnectionTimeOut.
Если какой-либо из сеансов SMTP истекает до успешного создания и подтверждения теневой копии сообщения, результат управляется параметром RejectMessageOnShadowFailure в командлете Set-TransportConfig . По умолчанию значение этого параметра равно $false, что означает, что основное сообщение принимается без создания теневой копии. Если значение этого параметра равно $true , основное сообщение отклоняется с временной ошибкой 451 4.4.0.
Если теневая копия сообщения успешно создана, но время ожидания сеанса SMTP между отправляющий SMTP-сервером и сервером-получателем истекает, сервер-источник принимает и обрабатывает основное сообщение. Отправляющий SMTP-сервер повторно доставляет непризнанное сообщение, но обнаружение повторяющихся сообщений помешает пользователям почтовых ящиков Exchange увидеть дубликаты сообщений. Когда отправляя smtp-сервер повторно отправляет сообщение, сервер-источник создаст еще одну теневой копию сообщения. Связь между теневыми сообщениями, созданными во время повторной отправки сообщений отправляемым SMTP-сервером, отсутствует.
В таблице ниже описаны параметры, управляющие процессом создания теневых сообщений
Параметры создания теневых сообщений
| Source | Значение по умолчанию | Описание |
|---|---|---|
| ShadowMessagePreferenceSetting в Set-TransportConfig | PreferRemote |
Этот параметр имеет смысл только в том случае, если сервер-источник, который пытается создать теневую копию сообщения, является сервером почтовых ящиков, который является членом daG, охватывающего несколько сайтов Active Directory. |
| MaxRetriesForRemoteSiteShadow в Set-TransportConfig | 4 | Этот параметр используется, если сервер почтовых ящиков является членом daG, охватывающего несколько сайтов Active Directory.
Если теневая копия сообщения не может быть успешно создана:
|
| MaxRetriesForLocalSiteShadow в Set-TransportConfig | 2 | Этот параметр используется в следующих случаях:
Если теневая копия сообщения не может быть успешно создана:
|
| ConnectionInactivityTimeout в Set-ReceiveConnector | 5 минут в транспортной службе на серверах почтовых ящиков 5 минут в службе внешнего транспорта на серверах клиентского доступа. 1 минута на пограничных транспортных серверах. |
Этот параметр указывает максимальное время, в течение чего открытое SMTP-подключение с исходным сервером обмена сообщениями может оставаться в состоянии простоя до закрытия подключения. Значение этого параметра должно быть меньше значения, указанного параметром ConnectionTimeout . |
| ConnectionTimeout в Set-ReceiveConnector | 10 минут в транспортной службе на серверах почтовых ящиков 10 минут в службе внешнего транспорта на серверах клиентского доступа. 5 минут на пограничных транспортных серверах. |
Этот параметр указывает максимальное время, когда SMTP-подключение с исходным сервером обмена сообщениями может оставаться открытым, даже если исходный сервер обмена сообщениями передает данные. Значение этого параметра должно быть больше значения, указанного параметром ConnectionInactivityTimeout . |
| ConnectionInactivityTimeOut в Set-SendConnector | 10 минут | Этот параметр задает максимальное количество времени, в течение которого подключение по протоколу SMTP к конечному серверу обмена сообщениями может оставаться открытым при его бездействии. |
Как хранятся теневые сообщения
После успешного создания теневого сообщения работа теневой избыточности только начинается. Основной и теневой серверы должны постоянно находиться в контакте друг с другом, чтобы отслеживать ход сообщения.
Когда основной сервер успешно передает сообщение для следующего прыжка и следующий прыжок подтверждает прием сообщения, основной сервер обновляет состояние удаления сообщения, указывая, что оно доставлено. Состояние удаления по сути представляет собой сообщение, содержащее список отслеживаемых сообщений. Успешно доставленное сообщение не обязано находиться в теневой очереди, поэтому когда теневой сервер узнает, что основной сервер успешно передал сообщение для следующего прыжка, теневой сервер перемещает теневое сообщение из теневой очереди в систему безопасности.
Теневой сервер определяет состояние удаления теневых сообщений в теневой очереди путем опроса основного сервера. Если теневой сервер открывает сеанс SMTP с основным сервером по какой-либо причине, включая передачу других несвязанных сообщений, теневой сервер выдает команду XQDISCARD , чтобы определить состояние отмены основных сообщений. Если теневой сервер не открыл сеанс SMTP на сервере-источнике после предварительно настроенного интервала времени, теневой сервер откроет сеанс SMTP с основным сервером и выполнит команду XQDISCARD . Интервал времени управляется параметром ShadowHeartbeatFrequency командлета Set-TransportConfig . Значение по умолчанию — 2 минуты. После того как теневой сервер откроет сеанс SMTP с основным сервером, основной сервер отвечает уведомлениями об удалении для сообщений, относящихся к запрашивающему теневому серверу. В Exchange 2013 уведомления об отмене хранятся на диске, а не в памяти. Таким образом, если служба транспорта Microsoft Exchange перезапускается, уведомления об отмене сохраняются. После запуска службы основной сервер по-прежнему знает о сообщениях, которые он успешно обработал, и эти сведения доступны теневому серверу.
SMTP-связь между теневым сервером и основным сервером используется в качестве пульса, определяющего доступность серверов. Если теневой сервер не может открыть сеанс SMTP с сервером-получателем после предварительно настроенного интервала времени или если транспортная база данных сервера-источника имеет другой идентификатор базы данных, теневой сервер продвигает себя в качестве основного сервера, продвигает теневые сообщения в качестве основных сообщений и передает сообщения на следующий прыжок. Интервал времени управляется параметром ShadowResubmitTimeSpan в командлете Set-TransportConfig . Значение по умолчанию — 3 часа.
Диспетчер теневой избыточности — это основной компонент транспортного сервера Exchange 2013, который отвечает за управление теневой избыточностью. Диспетчер теневого резервирования отвечает за хранение указанных ниже сведений для всех основных сообщений, обрабатываемых в настоящее время сервером.
- Теневой сервер для каждого основного сообщения, обрабатываемого.
- Состояние удаления, которое необходимо отправить на теневые серверы.
Диспетчер теневой избыточности отвечает за все теневые сообщения, которые теневой сервер имеет в своих теневых очередях:
- сохранение списка основных серверов для каждого теневого сообщения;
- сравнение исходного идентификатора базы данных и текущего идентификатора базы данных очереди, где хранится основная копия сообщения;
- проверка доступности каждого основного сервера, в очередь для которого помещено теневое сообщение;
- обработка уведомлений об удалении для основных серверов.
- удаление теневых сообщений из теневых очередей после получения всех ожидаемых уведомлений об удалении;
- принятие решений о том, когда теневой сервер должен вступить во владение теневыми сообщениями и стать основным сервером.
- Отслеживание бифуркации сообщений и других сообщений с побочными эффектами, таких как уведомления о состоянии доставки (DSN) и отчеты журнала, чтобы убедиться, что избыточное копирование сообщения не будет освобождено, пока не будут полностью обработаны все вилки сообщения.
В следующей таблице описаны параметры, определяющие способ обслуживания теневых сообщений.
| Параметр | Значение по умолчанию | Описание |
|---|---|---|
| ShadowHeartbeatFrequency в Set-TransportConfig | 2 минуты | Максимальный период времени, в течение которого теневой сервер ждет перед открытием SMTP-подключения к основному серверу, чтобы проверить состояние удаления из сообщения. |
| ShadowResubmitTimeSpan в Set-TransportConfig | 3 часа | Время ожидания сервера до принятия решения о том, что на основном сервере произошел сбой, и присвоения владения теневыми сообщениями в теневой очереди для недоступного основного сервера. |
| ShadowMessageAutoDiscardInterval в Set-TransportConfig | 2 дня | Время, в течение которого сервер сохраняет события удаления для успешно доставленных сообщений. Основной сервер ставит в очередь события отмены, пока не последует запрос теневого сервера. Однако, если теневой сервер не запрашивает основной сервер в течение периода, указанного в этом параметре, основной сервер удаляет события отмены, поставленные в очередь. |
| SafetyNetHoldTime по Set-TransportConfig | 2 дня | Время, в течение которого успешно обработанные сообщения хранятся в сети безопасности. Непризнанные теневые сообщения в конечном итоге истекают из Safety Net после суммы значений SafetyNetHoldTime и MessageExpirationTimeout в Set-TransportService. |
| MessageExpirationTimeout по Set-TransportService | 2 дней | Как долго сообщение может оставаться в очереди до истечения срока его действия. |
Обработка сообщений после сбоев
Теневая избыточность сводит к минимуму потерю сообщений из-за сбоев сервера. Когда транспортный сервер возвращается в режим "в сети" после сбоя, существует два сценария:
Сервер возвращается в режим "в сети" с новой транспортной базой данных. В этом сценарии транспортная база данных невосстановима из-за повреждения данных или сбоя оборудования. В этом случае, так как транспортный сервер будет иметь новый идентификатор базы данных, он будет распознана как новый маршрут другими транспортными серверами в организации. Это также относится к ситуации, когда не удалось восстановить сервер, а новый сервер был подготовлен в качестве замены.
Сервер возвращается в режим "в сети" с той же транспортной базой данных. В этом сценарии конкретный транспортный сервер не завершился сбоем, но находился в автономном режиме достаточно долго, чтобы теневой сервер взял на себя ответственность за сообщения и повторно их отправить. Например, сбой сетевой карты или длительное обслуживание сервера приведет к этому сценарию.
В следующей таблице показано, как теневая избыточность реагирует на эти два сценария. Для ясности предположим, что сервер, на который был сбой, называется Mailbox01.
Обработка сообщений в сценариях восстановления
| Сценарий восстановления | Выполняемые действия |
|---|---|
| Mailbox01 возвращается к сети с новой базой данных. | Когда Mailbox01 становится недоступным, каждый сервер с теневыми сообщениями, помещенными в очередь для Mailbox01, возьмет на себя ответственность за эти сообщения и повторно их выдаст. Затем сообщения доставляются в места назначения. Максимальная задержка сообщений — это значение параметра ShadowHeartbeatFrequency в командлете Set-TransportConfig . Значение по умолчанию — 2 минуты. |
| Mailbox01 возвращается к сети с той же базой данных. | После того как сервер Mailbox01 возобновит работу, он доставит сообщения, находящиеся в его очередях, которые уже были доставлены серверами, хранящими теневые копии сообщений для сервера Mailbox01. Это приведет к дублированию всех таких сообщений. Пользователи почтовых ящиков Exchange не будут видеть повторяющиеся сообщения из-за обнаружения повторяющихся сообщений. Однако получатели в системах обмена сообщениями, отличных от Exchange, могут получать дубликаты сообщений. Максимальная задержка сообщений — это значение параметра ShadowResubmitTimeSpan в командлете Set-TransportConfig . Значение по умолчанию — 3 часа. |