Балансировка нагрузки и отказоустойчивость Exchange Server обеспечивается разными средствами и у большинства на слуху прежде всего группы доступности баз данных (Database Availability Group – DAG). Но это если речь идет о БД, а как же балансировать клиентские подключения? Какие средства из коробки предлагает Exchange для обеспечения избыточности массивов серверов CAS?
Ответ прост и банален – никаких. Именно поэтому в интернете встречается так много разных подходов и “лайфхаков” на этот счет и зачастую в ход идут уж очень сомнительные решения. Одно из них совсем недавно довелось обсуждать на форумах technet в интересном топике.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.
Содержание
Балансировка нагрузки и отказоустойчивость Exchange Server
Суть в следующем: а можно ли использовать ip-адрес DAG в качестве основного адреса клиентских подключений? Ответ: можно, но не нужно.
Если говорить более развернуто, то технически использование адреса DAG вполне возможно и у вас даже все будет работать, но с практической точки зрения так лучше не делать, а почему именно, читайте дальше.
Как всегда начнем с солидной порции теории.
Как работает DAG?
На верхушке иерархии DAG находится сервер-держатель роли PAM (Primary Active Manager) 1. Он определяет какие копии баз на каком сервере будут активными, а какие пассивными. Именно сервер с ролью PAM держит кворум кластера и он является единственным в группе обеспечения доступности.
На всех оставшихся серверах вместо PAM выполняется роль SAM (Standby Active Manager), которая информирует другие локальные службы о том, какая база и где именно активна и, таким образом, трафик перенаправляется на соответствующие серверы.
Если сервер-держатель роли PAM вдруг отключается, его задачи перехватывает кто-то из серверов SAM и работа идет дальше.
При создании кластера DAG вам нужно указать его ip-адрес и именно он будет являться единой административной точкой подключения (Administrative Access Point – AAP), к которой будет привязано сетевое имя кластера (которое полностью идентично имени самого кластера, которое вы указываете при создании DAG).
Ну и, разумеется, этот ip-адрес держит хост, на котором выполняется роль PAM. То есть, вы можете пинговать этот адрес, подключаться к нему и выполнять любые другие операции, доступные для самого обычного адреса, привязанного к серверу.
Именно этот адрес так и тянутся руки использовать в качестве точки подключения для клиентов.
Почему так делать не надо
Ну а теперь рассмотрим основные причины.
Причина №1: Распределение нагрузки
Это наиболее очевидный момент из всех. Поскольку адрес DAG может находиться только на одном сервере, то и логично предположить, что все клиентские подключения будет обслуживать единственный сервер. Все остальные эксчи, сколько бы их ни было, будут частично или полностью простаивать.
Эта ситуация не столь драматична для пары серверов в DAG, но все становится иначе, когда речь идет о четырех+ серверах (когда в архитектуру решения изначально не заложено, что всю нагрузку гипотетически способен выдержать один сервер).
Причина №2: Переключение между серверами
После переезда DAG ip на другой сервер, лавина клиентов хлынет за ним и далеко не факт, что у них не будет проблем с подключением. В этом случае даже не столь важно разные подсети у двух серверов или нет.
Причина №3: Разные подсети на серверах
Чтобы разобрать эту ситуацию, нужно пояснить один нюанс: дело в том, что часто встречаются инфраструктуры, в которых серверы Exchange размещены в разных подсетях, например разнесены между датацентрами. В таком случае сервер из подсети А не сможет назначить себе адрес из подсети сервера В (да даже если бы смог, толку от этого было бы все равно мало). Для устранения такой проблемы вы добавляете несколько адресов в объект DAG и они назначаются в зависимости от того, какой сервер держит кворум.
В итоге у вас получается постоянно меняющаяся А-запись ресурса кластера и проблемы с устаревшим кэшем клиентов.
Да, переезд ip DAG на другой сервер может быть не частым событием, но приятного вы будете испытывать мало.
Причина №4: DAG ip может уйти в offline
Есть упоминания 2 о том, что DAG может уйти в offline, но сами серверы Exchange будут работать нормально. Это поведение я не тестировал, поэтому представляю вам как есть.
Причина №5: Решение не поддерживается
Действительно, нигде в официальных мануалах вы не найдете никаких упоминаний об использовании DAG ip как адреса для клиентских подключений.
Отсюда вытекает один неприятный вывод – возиться и разгребать последствия вашего архитектурного решения придется вам самим, а окружающие смогут помочь лишь советом переделать все по-человечески и будут правы.
Как нужно делать
Суть этой статьи – рассказать как делать не нужно, но все же я не могу оставить вас на произвол судьбы и не направить на истинный путь. Поэтому сейчас коротко о best practice без углубления в технические нюансы.
Самое простое и понятное решение балансировки клиентов – использование всем известного Round Robin. Оно и работает отлично, и Outlook поддерживает из коробки.
Решение для крупных контор – платные аппаратные/программные балансировщики, желательно в отказоустойчивой конфигурации.
Как быть с балансировкой внешних подключений
Если у вас один сервер, на него идет один проброс с любого внешнего корпоративного ip. Все просто.
Если у вас два сервера, вы в силе сделать два проброса. Outlook отлично умеет работать с RR.1
Как быть с клиентами OWA
Тем не менее, с клиентами OWA вам в любом случае придется решать проблемы внешних подключений, ведь браузеры обычно не умеют работать с RR.
Единственный вариант – использование отказоустойчивого балансировщика (вариант b. на рисунке выше), о котором я упоминал выше.
В этом случае, при выходе из строя одного сервера, OWA останется доступной для внешних клиентов.