Балансировка нагрузки и отказоустойчивость Exchange Server

Балансировка нагрузки и отказоустойчивость Exchange Server 01
www.microsoft.com

Балансировка нагрузки и отказоустойчивость 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 принимает непосредственное участие в работе механизма 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 и они назначаются в зависимости от того, какой сервер держит кворум.

Балансировка нагрузки и отказоустойчивость Exchange Server 02

Примечание: если вдруг вам придется столкнуться с задачей переноса одного сервера Exchange в другую подсеть, рекомендую прочитать мою статью Переезд сервера Exchange 2013.

В итоге у вас получается постоянно меняющаяся А-запись ресурса кластера и проблемы с устаревшим кэшем клиентов.

Да, переезд ip DAG на другой сервер может быть не частым событием, но приятного вы будете испытывать мало.

Причина №4: DAG ip может уйти в offline

Есть упоминания 2 о том, что DAG может уйти в offline, но сами серверы Exchange будут работать нормально. Это поведение я не тестировал, поэтому представляю вам как есть.

Причина №5: Решение не поддерживается

Действительно, нигде в официальных мануалах вы не найдете никаких упоминаний об использовании DAG ip как адреса для клиентских подключений.

Отсюда вытекает один неприятный вывод — возиться и разгребать последствия вашего архитектурного решения придется вам самим, а окружающие смогут помочь лишь советом переделать все по-человечески и будут правы.

Как нужно делать

Суть этой статьи — рассказать как делать не нужно, но все же я не могу оставить вас на произвол судьбы и не направить на истинный путь. Поэтому сейчас коротко о best practice без углубления в технические нюансы.

Самое простое и понятное решение балансировки клиентов — использование всем известного Round Robin. Оно и работает отлично, и Outlook поддерживает из коробки.

Примечание: хочу отметить, что поднять бесплатный балансировщик со связкой Linux + HAProxy/Nginx проще простого. Ещё проще сделать его отказоустойчивым, развернув на другом железе сервер-клон и подняв на них failover ip. Кстати, такое решение я подробно рассматривал в статье Простейший отказоустойчивый балансировщик layer 4.

Решение для крупных контор — платные аппаратные/программные балансировщики, желательно в отказоустойчивой конфигурации.

Как быть с балансировкой внешних подключений

Если у вас один сервер, на него идет один проброс с любого внешнего корпоративного ip. Все просто.

Если у вас два сервера, вы в силе сделать два проброса. Outlook отлично умеет работать с RR.1

Как быть с клиентами OWA

Тем не менее, с клиентами OWA вам в любом случае придется решать проблемы внешних подключений, ведь браузеры обычно не умеют работать с RR.

Примечание: если у вас будет два сервера, на каждый из которых идут пробросы с внешних адресов, то при выходе из строя одного сервера браузеры клиентов будут по очереди (в зависимости от выдачи сервера DNS) ломиться то на один адрес, то на другой. В тот момент, когда они попадут на проброс с неработающим сервером, отклика они не получат. Это вариант а. на рисунке ниже.

Единственный вариант — использование отказоустойчивого балансировщика (вариант b. на рисунке выше), о котором я упоминал выше.

В этом случае, при выходе из строя одного сервера, OWA останется доступной для внешних клиентов.

comments powered by HyperComments
Яндекс.Метрика