В предыдущей статье я обзорно пробежался по процедуре переключения почтового сервиса на резервный дата центр в случае сбоя основного. Есть ещё один сценарий, который возникает в случае, если наш DAG растянут между двумя и более дата центрами. Речь идёт о так называемом Database Failover – который отрабатывает в случае сбоя базы и переводит активную базу в другой дата центр. Картинка с технета прекрасно показывает данную ситуацию:
В данном сценарии интересен момент с поведением клиента, в случае когда активная база перемещается в другой дата центр. Получается, что для клиента доступны конечные точки в обоих дата центрах. Но, сразу же после переезда активной базы, клиент будет подключаться к конечной точке в основном дата центре. Разделим клиентов по их типам:
- MAPI
- OWA
- ECP/AS
- POP3/IMAP4
- EWS/Availability
MAPI
В случае с MAPI-клиентами важно понимать, что конечная точка, к которой подключается клиент достаточно статична. При создании локального почтового профиля она вытаскивается через атрибут legacyExchangeDN/RpcClientAccessServer конкретной почтовой базы, которая прописана в атрибуте homeMDB ящика, который указывается при настройке почтового профиля. По рекомендациям лучших собаководов в качестве конечной точки для MAPI-клиента лучше использовать CAS Array.
В результате того, что активная база переехала в другой дата центр (который, как мы договорились в предыдущей статье, представляет собой отдельный сайт AD), то база начинает в параметре RpcClientAccessServer показывать не совсем правильную конечную точку. База находится в резервном дата центре, а конечная точка, указанная в RpcClientAccessServer ссылается на CAS Array, привязанный к основному дата центру. Есть два варианта развития событий.
Первый. Так как конечная точка в основном дата центре продолжает работать, то для клиента ровным счётом ничего не меняется. Он продолжает подключаться к ней. При этом, все серверы клиентского доступа через клиента Active Manager получают информацию о том, что активная база переехала в другой сайт. Фактически, взаимодействие Client Access Server ↔ Mailbox Server не завязано на какие-либо сайты, и в нашем случае сервер клиентского доступа из основного дата центра просто подключится по MAPI RPC к серверу почтовых ящиков с активной базой в резервном дата центре. Клиент восстановит подключение к своему почтовому ящику.
Данное поведение верно для Outlook 2010/2007.
Второй. Начиная с Exchange 2010 SP2 RU3 поведение клиента немного меняется. DAG получил новый параметр – AllowCrossSiteRPCClientAccess. Мы по прежнему наблюдаем, что RpcClientAccessServer активной базы не совпадает с CAS Array резервного сайта. Если значение AllowCrossSiteRPCClientAccess – $false (значение по умолчанию), то сервер клиентского доступа вернёт клиенту ответ ecWrongServer. После получения ecWrongServer клиент (Outlook) запустит процедуру обновления локального почтового профиля через службу автообнаружения. И в данной ситуации CAS вернёт клиенту в качестве конечной точки CAS Array в том сайте, где находится активная база, то есть CAS Array резервного дата центра. После обновления профиля Outlook потребует перезагрузку и в итоге подключится к новой конечной точке в резервном дата центре.
OWA
В общем случае, клиент Outlook Web App будет редиректиться на конечную точку в сайте, в котором находится активная база. Конечная точка в случае с веб-клиентом находится в параметре ExternalUrl настроек соответствующей клиенту виртуальной директории на веб-сервере. Для Outlook Web App так же имеется два варианта развития события.
Первый. Manual redirection. В этой ситуации, при попытке подключиться к конечной точке в основном дата центре клиент получит от веб-сервера адрес конечной точки во втором дата центре (там где находится активная база) и должен будет перейти по полученной ссылке.
Второй. Silent redirection. Этот вариант доступен, начиная с Exchange 2010 SP2. Настраивается через ключ CrossSiteRedirectType командлета Set-OWAVirtualDirectory. При включении silent redirection клиент автоматически подключится к конечной точке в резервном дата центре после получения её адреса от конечной точки из основного дата центра.
Если используется FBA, то необходимо использовать SSL.
ECP/AS
В зависимости от настроек конечной точки (ExternalUrl) клиентское подключение будет либо редиректиться, либо проксироваться в резервный дата центр.
POP3/IMAP4
Всегда будет использоваться проксирование в резервный дата центр.
EWS/Availability
Служба автообнаружения всегда будет возвращать конечную точку того сайта, где находится активная база.
Полезные ссылки:
Understanding Database Availability Groups
RPC Client Access Cross-Site Connectivity Changes
Exploring Exchange 2010 RPC Client Access Service
Understanding Proxying and Redirection