Exchange 2013 Transport HA

Как работают механизмы отказоустойчивости транспорта в Exchange 2007-2010, мы рассмотрели ранее, теперь давайте обратимся в к Exchange 2013. Основная идея отказоустойчивости транспорта в Exchange 2013 - "надо хранить копию всех писем до и после их доставки".

В результате, в Exchange 2013 бывший Transport Dumpster превратился в Safety Net и теперь хранит письма доставляемые не только в кластеризованые базы данных, но и вообще все письма, обработанные транспортом! При этом механизм Shadow Redundancy изменился не значительно. Что же касается Acknowledgement Delay, то теперь такого понятия в явном виде нет, но несколько измененный механизм – есть , т.е. сервер не ждет доставки письма на другой hop прежде чем отправить Acknowledgement, но при этом он отправляет Acknowledgement только после того, как письмо будет отправлено на другой транспортный сервер в Shadow копию (подробнее ниже).

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

Shadow Redundancy

В Exchange 2013 появилось такое понятие как границы высокой доступности транспорта (transport high availability boundaries), это:

• Active Directory site, если нет DAG`a
• DAG, в том числе растянутый между сайтами.

Соответственно для работы механизма Shadow redundancy или Safety Net надо как минимум 2 Mailbox сервера в рамках transport high availability boundaries, при этом Shadow Messages НЕ будут копироваться на сервера за этими границами.

Пожалуй, ни что лучше не проиллюстрирует работу всех механизмов вместе, чем картинка с TechNet`a:

Здесь:

1. Mailbox01 получает по SMTP сообщение с сервера за границами отказоустойчивости транспорта и прежде чем ответить 250 2.6.0 Queued mail for delivery (т.е. Acknowledgement), он отправляет это письмо на другой сервер. Если есть сервер в другом АД сайте (в пределах этого DAG`a), то на него.
2. Mailbox03 получает письмо и складывает его в Shadow-очередь (Shadow Redundancy). Таким образом Mailbox01 - Primary Server, Mailbox03 - Shadow Server.
3. Mailbox01 обрабатывает письмо:
   1. 3а, 3b - доставляет в ящик
   2. Помечает письмо доставленным (чтобы потом "рассказать" об этом 02-му серверу) и перемещает его в Primary Safety net.
4. Mailbox03 в следующей SMTP сессии запрашивает статус письма и
5. Перемещает его в свою Shadow Safety Net.

В результате письма будут лежать в Primary Safety Net и Shadow Safety Net до тех пор, пока не истечет настроенный таймаут. В случае переключения баз данных, письма будут запрошены из Primary Safety Net Active Manger`ом.

Конфигурирование - основные настройки:

• Shadow Redundancy включено по умолчанию

Set-TransportConfig -ShadowRedundancyEnabled $true / $false - включить / отключить механизм

Set-TransportConfig -ShadowMessagePreference PreferRemote / RemoteOnly / LocalOnly - где предпочтительнее хранить shadow-сообщения (работает только в рамках DAG-a, PreferRemote - default)

Set-TransportConfig -RejectMessageOnShadowFailure $True - сообщения будут отклоняться с ошибкой (451 4.4.0 Message failed to be made redundant), если shadow-сообщение не может быть создано. По умолчанию отключено.

ShadowResbumitTimeSpan и ShadowHeartbeatFrequency - настраивают поведение Heartbeat`ов

Что если Shadow-сообщение не может быть создано?

Если Primary сервер не может “достучаться” до Shadow сервера в момент приема сообщения, то он предпринимает несколько повторных попыток, контролируется это следующими ключами:

• MaxRetriesForLocalSiteShadow - если Mailbox сервер в том же АД сайте (Default 2)
• MaxRetriesForRemoteSiteShadow- если Mailbox сервер в другом АД сайте (Default 4)

Если эти значения будут достигнуты, то включается настройка RejectMessageOnShadowFailure (см. выше)

Особенности работы Shadow Redundancy - обратите внимание, что Mailbox 2013 не отвечает глаголом XSHADOW серверу Exchange 2010, когда тот пытается ему доставить письмо! Хотя в случае самостоятельной отправки писем в сторону 2010-го, XSHADOW используется т.е.:

Exchange 2010 -> Exchange 2013 - Shadow Redundancy НЕ работает

Exchange 2010 <- Exchange 2013 - Shadow Redundancy работает

 

Safety Net

Как уже было сказано выше, это последователь Transport Dumpster-а, и пришел данный механизм из Office 365. Письма хранятся в той же транспортной базе mail.que. Существует Primary Safety Net и Shadow Safety Net.

Особенности работы Safety Net.

Важно знать, что нет возможности настроить размер Safety Net, конфигурируется только время хранения. В разных Cumulative Updates это значение разное (SafetyNetHoldTime), но довольно большое - до 2 дней! Соответственно, это означает, что все письма, прошедшие через сервер, будут храниться в базе mail.que до 2-х дней. Следовательно, надо серьезно просчитать количество свободного места на диске, где у вас лежит транспортная очередь. Настраивается время хранения так:

Set-TransportConfig -SafetyNetHoldTime days.hours:min:sec

Resubmit

Повторная доставка сообщений из Safety Net инициируется компонентом Active Manager, который работает в рамках службы Microsoft Exchange Replication. Кроме того, вы можете использовать PowerShell, чтобы получить информацию по этому поводу - Get\Set\Add\Remove-ResubmitRequest http://technet.microsoft.com/en-us/library/jj215718(v=exchg.150).aspx