Transport Hight Avaliability в Exchange 2007-2010

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

Будет рассмотрено:

• Transport Dumpster
• Shadow Redundancy
• Acknowledgement Delay

Transport Dumpster

Это механизм, анонсированный в Exchange 2007 для обеспечения надежной доставки сообщений в кластеризованные базы данных, соответственно работает только в том случае, когда в организации есть настроенные кластера Exchange 2007 - CCR / LCR, Exchange 2010 - DAG. Основная проблема, с которой в данном случае "борется" Transport Dumpster, состоит в том, что копия базы данных, в которую было доставлено сообщение может испытывать проблемы с репликацией и соответственно, если сообщение будет доставлено в неё, и сразу после этого произойдет переключение баз (lossy failover), то велика вероятность того, что письмо будет потеряно.

Для того, чтобы избежать потери сообщений в момент lossy failover-а в кластерах Exchange 2007 / 2010, служба транспорт держит письмо у себя в корзине в течении некоторого времени.

С физической точки зрения, Transport Dumpster - это специальный раздел в базе очереди mail.que. В Exchange 2007 для каждой Storage Group был свой собственный Transport Dumpster, в Exchange 2010 он один для всех баз, но если DAG растянут между АД сайтами, то корзина находится на HUB-х во всех этих сайтах.

Как это работает:

Когда происходит переключение на пассивную копию, Mailbox сервер, в лице Replication Service`a, по RPC опрашивает все HUB сервера в его Active directory сайте и пытается получить из Transport Dumpster-а все не доставленные сообщения с момента времени, когда у него был записан в базу последний лог файл (commited) и до момента, когда сервер был активирован.

Размер и время хранения

Основных настроек Transport Dumpster-а всего две:

• Врем хранения - MaxDumpsterTime (по умолчанию 7 дней)
• Размер корзины - MaxDumpsterSizePerStorageGroup / MaxDumpsterSizePerDatabase для Ecxhange 2007 и 2010 соответственно (по умолчанию 18 Мб)

Проверить подобные параметры можно через Get-Transportconfig | fl *dumpster*

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

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

Exchange 2010

В Exchange 2010 разработчики пошли дальше и обратили свое пристальное внимание в сторону вероятных потерь данных при работе по протоколу SMTP и внедрили сразу два механизма:

• Shadow Redundancy - отказоустойчивость при пересылке по SMTP между "своими"
• Acknowledgement Delay - надежный прием данных от "всех остальных"

Shadow Redundancy

Shadow Redundancy - анонсирован в Exchange 2010 и представляет из себя механизм, который сохраняет сообщения в транспортной очереди до тех пор, пока сервер, которому письмо было отправлено, сам не доставит письмо на следующих шаг (hop) и не оповестит первый сервер об успешной доставке.

http://technet.microsoft.com/en-us/library/dd351027(v=exchg.141).aspx

Для того, чтобы было понятнее, посмотрим на схему:

Коротко основные термины:

• Primary Server - сервер, которому отправлено письмо
• Shadow Server - сервер, который отправил письмо
• Shadow message - отправленное сообщение, лежит в базе mail.que на Shadow Server`e и содержит в себе meta-data с информацией о том, куда, но было доставлено.

Алгоритм работы:

1. Сервер отправляет письмо другому серверу по SMTP:
   1. Отправитель будет Shadow Server, получатель - Primary Server
   2. В момент установки SMTP сессии, на команду EHLO отправляется глагол XSHADOW, который свидетельствует о том, что получатель поддерживает Shadow Redundancy
   3. HUB отправляет письмо
   4. HUB двигает копию письма у себя в Shadow очередь (в данном случае это будет Shadow\Edge1)
2. Edge доставляет письмо дальше и в данном случае сервер-получатель не транслирует XSHADOW в сессии, т.к. он не поддерживает эту технологию, соответственно на Edge`e сообщение в Shadow очередь не складывается.
3. HUB запрашивает состояние доставки у Edge сервера. Происходит это в момент отправки следующего письма, т.е. установления следующей SMTP сессии, либо инициируется отдельная сессия (п.4).
4. Если ничего не отправлялось в течении ShadowHeartbeatTimeoutInterval, то HUB поднимает "пустую" сессию специально, чтобы запросить статус, это называет Heartbeat и контролируется ключами:

Get \ Set-TransportConfig

ShadowHeartbeatTimeoutInterval (default: 5 минут в RTM и 15 минут в SP1)
ShadowHeartbeatRetryCount (default: 3 в RTM и 12 в SP1).

Если Edge не ответил на количество запросов, указанное в ShadowHeartbeatRetryCount то принимается решение о пересылке письма по другому маршруту.

Если посмотреть на состояние очереди Shadow\Edge1, то она должна быть в состоянии Ready и будет переключена в состояние Active только в случае инициирования повторной доставки.

Сообщения удаляются из очереди в случае:

1. Когда будет получен ответ от всех серверов, которые отправили XSHADOW

Важно! Если письмо после категорайзера отправилось по нескольким маршрутам, например в Mailbox базу, на Edge 2010, на HUB 2007 и на Foreign Connector, то будет ожидаться только один ответ от Edge 2010, потому что все остальные не поддерживают XSHADOW.

1. Когда истечет время ShadowMessageAutoDiscardInterval - через 2 дня (по умолчанию после SP1). Настраивается это время через

Set-TransportConfig - ShadowMessageAutoDiscardInterval 1.00:00:00

За работу Shadow Redundancy отвечает компонент Redundancy Manager, который "живет" внутри процесса EdgeTransport.exe на всех транспортных серверах.

Включить \ отключить Shadow Redundancy в организации в целом можно командой

Set-TransportConfig –ShadowRedundancyEnabled $true \ $false

Кроме того, Send и Receive Connector`ы будут транслировать команду XSHADOW в SMTP сессии если только у них есть права ms-Exch-SMTP-Send-XSHADOW и ms-Exch-SMTP-Accept-XSHADOW (по умолчанию есть у всех коннекторов).

В результате Exchange 2010 может достаточно "надежно" доставлять сообщения по SMTP в сторону Exchange 2010 либо Exchange 2013, а как же быть со всеми остальными почтовыми серверами?

Acknowledgement Delay

Для того, чтобы снизить вероятность потери данных на стороне транспортных серверов, в Exchange 2010 существует ещё один механизм Acknowledgement Delay. Работает он чрезвычайно просто - в случае когда входящая SMTP сессия не поддерживает Shadow Redundancy (нет поддержки XSHADOW отправителем), то служба транспорта не оповещает отправитель о том, что сообщение было успешно получено (командой 250 2.6.0 Queued mail for delivery) до тех пор, пока оно не будет доставлено далее, или максимум в течении 30 секунд. Таким образом, в обычной ситуации, если "упадет" данный транспортный сервер до того как успеет передать письмо дальше, то письмо будет потеряно, а в случае подобной задержки, отправитель так и не получит оповещения и будет вынужден искать другие маршруты.

Здесь также участвует Redundancy Manager, как и в прошлом случае. Только здесь он помечает сообщение как "delayed ack message" и ждет пока оно будет доставлено на следующий hop, только после этого "разрешает" receive connector`y ответить 250 2.6.0 Queued mail for delivery. Если доставка занимает более 30 секунд, то 250 2.6.0 acknowledgement все равно отправляется.

Настраивается интервал ожидания здесь:

Set-ReceiveConnector –Identity <connector name> - MaxAcknowlegmentDelay <hh:mm:ss>

Redundancy Manager далеко не всегда может отследить успешность последующей доставки и в таком случае delayed acknowledgement будет отправлен сразу, также он будет сразу отправлен, если очередь сессий, которые ждут 250 2.6.0 больше 100 (по умолчанию)

Shadow redundancy promotion

Далеко не все third-party SMTP сервера готовы "мириться" с такими таймаутами при доставке и некоторые из них могут начать самостоятельно разрывать сессии, не дождавшись 30 секунд, и пытаться доставить письмо ещё раз, тем самым очень сильно нагружая транспорт и создавая много дубликатов. Чтобы подобного поведения избежать, в Exchange 2010 SP1 появилась функция Shadow redundancy promotion. Смысл в том, что HUB, получив письмо, сразу делает его relay на другой HUB в Active Directory сайте путем складывания его в Shadow Redundancy pipeline.

По умолчанию Shadow redundancy promotion отключено для on-premise инсталляций и включить его можно через Edgetransport.exe.config файл - ключ <add key=” ShadowRedundancyPromotionEnabled” value=”False” />

http://technet.microsoft.com/en-us/library/dd351046(v=exchg.141).aspx

На этом про 2007-2010 все, в следующие статье поговорим про то, что изменилось в Transport HA в Exchange 2013