Переключение между центрами обработки данных в предыдущей версии Exchange 2010 было непростым, поскольку пространства имен для подключения клиентов и почтовых ящиков (DAG) были тесно соединены между собой. Если происходил сбой значительной части CAS, или Virtual IP массива, или части DAG, приходилось выполнять переключение между ЦОДами. В Exchange 2010 возможно самой большой единой точкой отказа в почтовой системе являлось полное доменное имя , которое сообщалось пользователям для входа. С точки зрения Exchange 2010, изменение этого FQDN происхоило непрозрачно, поскольку необходимо было внести изменения в DNS и выждать определенное время. А также могло потребоваться еще больше времени, поскольку кэширование имен в браузерах обычно может занимать около 30 минут или более.

В Exchange 2013, клиент может получить несколько IP адресов для одного полного доменного имени.

В Exchange 2013 пространство имен больше не нужно передвигать вместе с группой высокой доступности DAG. Exchange использует встроенную отказоустойчивость единого пространства с множеством IP адресов, распределяя и нагрузку, и, когда этого требуется, высокую доступность сервиса.

Это означает, что пространство имен больше не является единой точкой отказа, как это было в Exchange 2010.

Поскольку сейчас все клиентские подключения основаны на HTTP (Outlook, Outlook Anywhere, EAS, EWS, OWA, и EAC), и если первый IP адрес в стеке HTTP недоступен, клиент HTTP попытается использовать следующий и так далее.

Если  недоступен VIP или CAS, клиент автоматически пере подключится к тому же сервису на другом IP адресе через несколько секунд, вместо ожидания минут для обработки отказа непосредственно с помощью DNS. Например, если клиент пробует первый адрес и он не может установить соединение, он  ожидает 20 секунд и пробует следующий адрес в списке. Таким образом, при сбое VIP или CAS, пере подключение клиентов произойдет полностью автоматически, и менее чем за полминуты!

Если же из строя выходит массив CAS, вам не нужно выполнять переключение центра обработки данных. Клиенты автоматически перенаправляются в резервный ЦОД, управляемый вторым CAS, который остается незатронутым (поскольку вы не выполняете переключение вручную) Вместо того чтобы выполнять  работы для восстановления службы, служба восстанавливается сама и вы теперь можете сосредоточиться на устранении основной проблемы.

Если не отвечает балансировщик в основном сайте, его просто можно выключить (или сменить ему адрес), и спокойно чинить или полностью заменить устройство. Клиенты, которые не используют его будут переключаться на использование VIP во втором ЦОДе автоматически без изменений в DNS. Это не только говорит о том, что не нужно больше проводить переключение, но и о том, что обычное время, затраченное на работы по переключению не будет потрачено.

Пример дизайна DAG для Exchange 2013: Поскольку вы можете сейчас обрабатывать отказы пространства имен между центрами обработки данных, все, что нужно теперь для такой обработки сбоя в одной из площадкок- это сервер с ролью Mailbox  в каждом дата центре. Чтобы добиться автоматического переключения, просто спланируйте решение где группа DAG будет растянута между двумя ЦОДами, и поместите сервер свидетель на третьей площадке, для  выполнения арбитража членов группы независимо от состояния сетевого соединения между участниками DAG.

Как бороться с кратковременными отказами в Exchange 2013: Непредвиденный сбой может случиться из-за отказа оборудования или ПО. В этом случае, администратор может просто удалить VIP из DNS. Затем выполнить обслуживание сервиса, и после нужных исправлений добавить адрес обратно, а клиенты автоматически начнут его использовать.

http://blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx

http://blogs.technet.com/b/exchange/archive/2014/03/05/load-balancing-in-exchange-2013.aspx