Балансировка нагрузки и отказоустойчивость Exchange Server обеспечивается разными средствами и у большинства на слуху прежде всего группы доступности баз данных (Database Availability Group — DAG). Но это если речь идет о БД, а как же балансировать клиентские подключения? Какие средства из коробки предлагает Exchange для обеспечения избыточности массивов серверов CAS?Ответ прост и банален — никаких. Именно поэтому в интернете встречается так много разных подходов и «лайфхаков» на этот счет и зачастую в ход идут уж очень сомнительные решения.
Балансировка нагрузки и отказоустойчивость Exchange Server
Суть в следующем: а можно ли использовать ip-адрес DAG в качестве основного адреса клиентских подключений? Ответ: можно, но не нужно.Если говорить более развернуто, то технически использование адреса DAG вполне возможно и у вас даже все будет работать, но с практической точки зрения так лучше не делать, а почему именно, читайте дальше.Как всегда начнем с солидной порции теории.
Как работает DAG?
На верхушке иерархии DAG находится сервер-держатель роли PAM (Primary Active Manager). Он определяет какие копии баз на каком сервере будут активными, а какие пассивными. Именно сервер с ролью PAM держит кворум кластера и он является единственным в группе обеспечения доступности.Примечание: кстати, именно роль PAM принимает непосредственное участие в работе механизма Best Copy Selection.На всех оставшихся серверах вместо PAM выполняется роль SAM (Standby Active Manager), которая информирует другие локальные службы о том, какая база и где именно активна и, таким образом, трафик перенаправляется на соответствующие серверы.Если сервер-держатель роли PAM вдруг отключается, его задачи перехватывает кто-то из серверов SAM и работа идет дальше.При создании кластера DAG вам нужно указать его ip-адрес и именно он будет являться единой административной точкой подключения (Administrative Access Point — AAP), к которой будет привязано сетевое имя кластера (которое полностью идентично имени самого кластера, которое вы указываете при создании DAG).Примечание: хочу чтобы вы знали, что с версии Exchange SP1 в сочетании с Windows Server 2012 R2 появилась возможность создавать DAG без ip-адреса. Такая конфигурация, как утверждают разработчики, значительно упрощает администрирование и уменьшает поверхность атаки для злоумышленников. Но это все теория, а нас интересует тот момент, что в этом случае Exchange уже сильно меньше завязан на роли Windows Failover Clustering и по сути предоставляет DAG как независимый от этой роли сервис. Для любителей экспериментов на всякий случай напомню, что администрирование DAG через оснастку Отказоустойчивых кластеров категорически не поддерживается!Ну и, разумеется, этот ip-адрес держит хост, на котором выполняется роль PAM. То есть, вы можете пинговать этот адрес, подключаться к нему и выполнять любые другие операции, доступные для самого обычного адреса, привязанного к серверу.Именно этот адрес так и тянутся руки использовать в качестве точки подключения для клиентов.
Почему так делать не надо
Ну а теперь рассмотрим основные причины.
Причина №1: Распределение нагрузки
Это наиболее очевидный момент из всех. Поскольку адрес DAG может находиться только на одном сервере, то и логично предположить, что все клиентские подключения будет обслуживать единственный сервер. Все остальные эксчи, сколько бы их ни было, будут частично или полностью простаивать.Эта ситуация не столь драматична для пары серверов в DAG, но все становится иначе, когда речь идет о четырех+ серверах (когда в архитектуру решения изначально не заложено, что всю нагрузку гипотетически способен выдержать один сервер).
Причина №2: Переключение между серверами
После переезда DAG ip на другой сервер, лавина клиентов хлынет за ним и далеко не факт, что у них не будет проблем с подключением. В этом случае даже не столь важно разные подсети у двух серверов или нет.
Причина №3: Разные подсети на серверах
Чтобы разобрать эту ситуацию, нужно пояснить один нюанс: дело в том, что часто встречаются инфраструктуры, в которых серверы Exchange размещены в разных подсетях, например разнесены между датацентрами. В таком случае сервер из подсети А не сможет назначить себе адрес из подсети сервера В (да даже если бы смог, толку от этого было бы все равно мало). Для устранения такой проблемы вы добавляете несколько адресов в объект DAG и они назначаются в зависимости от того, какой сервер держит кворум.
В итоге у вас получается постоянно меняющаяся А-запись ресурса кластера и проблемы с устаревшим кэшем клиентов.Да, переезд ip DAG на другой сервер может быть не частым событием, но приятного вы будете испытывать мало.
Причина №4: DAG ip может уйти в offline
Есть упоминания о том, что DAG может уйти в offline, но сами серверы Exchange будут работать нормально. Это поведение я не тестировал, поэтому представляю вам как есть.
Причина №5: Решение не поддерживается
Действительно, нигде в официальных мануалах вы не найдете никаких упоминаний об использовании DAG ip как адреса для клиентских подключений.Отсюда вытекает один неприятный вывод — возиться и разгребать последствия вашего архитектурного решения придется вам самим, а окружающие смогут помочь лишь советом переделать все по-человечески и будут правы.
Как нужно делать
Суть этой статьи — рассказать как делать не нужно, но все же я не могу оставить вас на произвол судьбы и не направить на истинный путь. Поэтому сейчас коротко о best practice без углубления в технические нюансы.Самое простое и понятное решение балансировки клиентов — использование всем известного Round Robin. Оно и работает отлично, и Outlook поддерживает из коробки.Примечание: хочу отметить, что поднять бесплатный балансировщик со связкой Linux + HAProxy/Nginx проще простого. Ещё проще сделать его отказоустойчивым, развернув на другом железе сервер-клон и подняв на них failover ip.Решение для крупных контор — платные аппаратные/программные балансировщики, желательно в отказоустойчивой конфигурации.
Как быть с балансировкой внешних подключений
Если у вас один сервер, на него идет один проброс с любого внешнего корпоративного ip. Все просто.
Если у вас два сервера, вы в силе сделать два проброса. Outlook отлично умеет работать с RR.1
Как быть с клиентами OWA
Тем не менее, с клиентами OWA вам в любом случае придется решать проблемы внешних подключений, ведь браузеры обычно не умеют работать с RR.Примечание: если у вас будет два сервера, на каждый из которых идут пробросы с внешних адресов, то при выходе из строя одного сервера браузеры клиентов будут по очереди (в зависимости от выдачи сервера DNS) ломиться то на один адрес, то на другой. В тот момент, когда они попадут на проброс с неработающим сервером, отклика они не получат. Это вариант а. на рисунке ниже.
Единственный вариант — использование отказоустойчивого балансировщика (вариант b. на рисунке выше), о котором я упоминал выше.
В этом случае, при выходе из строя одного сервера, OWA останется доступной для внешних клиентов.
Вы всегда можете обратиться за помощью в настройке и администрированию серверов в компанию КипСервис
по тел. +7(952) 2277164
или по электронной почте: support@ldktech.ru
