В этой статье я постараюсь немного заглянуть "под капот" механизмов, обеспечивающих отказоустойчивость работы службы транспорта, в версиях сервера 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 с информацией о том, куда, но было доставлено.
Алгоритм работы:
- Сервер отправляет письмо другому серверу по SMTP:
- Отправитель будет Shadow Server, получатель - Primary Server
- В момент установки SMTP сессии, на команду EHLO отправляется глагол XSHADOW, который свидетельствует о том, что получатель поддерживает Shadow Redundancy
- HUB отправляет письмо
- HUB двигает копию письма у себя в Shadow очередь (в данном случае это будет Shadow\Edge1)
- Edge доставляет письмо дальше и в данном случае сервер-получатель не транслирует XSHADOW в сессии, т.к. он не поддерживает эту технологию, соответственно на Edge`e сообщение в Shadow очередь не складывается.
- HUB запрашивает состояние доставки у Edge сервера. Происходит это в момент отправки следующего письма, т.е. установления следующей SMTP сессии, либо инициируется отдельная сессия (п.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 только в случае инициирования повторной доставки.
Сообщения удаляются из очереди в случае:
- Когда будет получен ответ от всех серверов, которые отправили XSHADOW
Важно! Если письмо после категорайзера отправилось по нескольким маршрутам, например в Mailbox базу, на Edge 2010, на HUB 2007 и на Foreign Connector, то будет ожидаться только один ответ от Edge 2010, потому что все остальные не поддерживают XSHADOW.
- Когда истечет время 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
Комментариев нет:
Отправить комментарий