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

Привлекательность балансировки нагрузки

Один из аргументов в пользу физической или виртуальной подсистемы балансировки нагрузки по сравнению с другими решениями, такими как циклический перебор DNS или Windows Network Load Balancing (NLB) состоит в большей гибкости при проверке работоспособности. Циклический перебор DNS не предусматривает никакой проверки работоспособности. Поэтому пользователи могут быть перенаправлены на неисправный сервер, так как DNS не имеет никаких сведений о доступности сервера. NLB предпочтительнее, но возможности ограничены выполнением команды PING для каждого сервера в массиве. Поэтому сведения NLB о сервере ограничены. Если сервер откликается на проверку работоспособности, он считается активным и потому доступным для запросов, даже если одна или несколько служб (не связанных с проверкой работоспособности) не функционируют.

Как и NLB, подсистемы балансировки нагрузки периодически проверяют доступность базовых серверов Exchange. Обычно эти запросы более развитые и потому позволяют точнее определить работоспособность сервера. Если сервер недоступен, то он изымается из массива, и новые клиентские запросы не будут пересылаться ему до тех пор, пока неисправность не будет устранена.

Уровень 4 или уровень 7?

Модель OSI концептуально описывает сетевое взаимодействие путем разделения потока связи на семь разных уровней. Уровень 4 соответствует транспортному уровню, который описывает способность надежно передавать пакеты между узлами сети. Хороший пример протокола уровня 4 — TCP. Уровень 7 — прикладной. Он взаимодействует с программным обеспечением, обменивающимся данными через сеть. HTTP — удачный пример протокола уровня 7.

При балансировке нагрузки устройство, функционирующее на уровне 4, сможет выполнять только простые действия, в частности, получать и переадресовывать трафик. Однако на уровне 7 устройство может взаимодействовать с протоколами более высокого уровня, такими как HTTP и SMTP. При этом открываются широкие возможности, в том числе чтения и изменения URL-адресов на ходу.

Выпуская Exchange 2013, компания Microsoft утверждала, что продукт будет балансировать нагрузку на уровнях 4 и 7. Эта новость вызвала множество вопросов. Действительно, Exchange 2013 (в отличие от Exchange Server 2010) успешно работает на уровне 4, но вряд ли это решение оптимальное. Объясню, почему.

Балансировка нагрузки на уровне 4, в сущности, представляет собой очень простой способ обработки. Подсистема балансировки нагрузки принимает решения по переадресации только на основе IP-адреса и порта, на котором получен клиентский запрос на подключение. Подсистема балансировки нагрузки не обращает внимания на тип передаваемого трафика. Например, безразлично, подключается пользователь к Outlook Web App (OWA) или Outlook Anywhere.

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

На уровне 7 подсистема балансировки нагрузки распознает тип передаваемого трафика. Анализируется содержимое обмена между клиентами и сервером Exchange, а затем эта информация используется для принятия решений о переадресации. Таким образом, можно выбирать маршрут трафика на основе виртуального каталога, к которому пытается подключиться клиент.

Этот сценарий проиллюстрирован на рисунке 1. Когда трафик поступает на подсистему балансировки нагрузки, используется другая логика маршрутизации, в зависимости от URL-адреса, по которому отправлен клиентский запрос.

 

Балансировка нагрузок на?уровне 7
Рисунок 1. Балансировка нагрузок на? уровне 7

У каждого поставщика подсистем балансировки нагрузки есть собственное имя для этого компонента. Например, в KEMP Technologies его называют Sub-Virtual Services. Основная виртуальная служба определена комбинацией IP-адреса и TCP-порта, к которому подключается клиент, а Sub-Virtual Services определяется виртуальным каталогом. Как правило, используется правило на базе регулярного выражения для определения виртуального каталога, к которому подключается клиент.

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

Однако в традиционных сценариях на уровне 4 решение о работоспособности сервера и его способности получать трафик принимается в результате единственной проверки работоспособности. Проблема этого подхода заключается в отсутствии стандартного набора критериев, характеризующего работоспособность сервера Exchange. Во многих случаях развертывания проверяется доступность виртуального каталога /owa. Но одно то, что OWA проходит проверку работоспособности, не означает, что другие службы на том же сервере исправны. Аналогично, можно проверить связь с этим сервером с помощью команды Ping, но это не гарантирует, что Exchange работает. Приемлемы все варианты, но ни один из них не безупречен, поскольку вместо расширения возможностей сервера и принятия решений на основе доступности Exchange решения о маршрутизации основываются на доступности сервера вообще. Более того, решение принимается не об Exchange в целом, а об одном его компоненте. Как говорит мой коллега Поль Робишо, врач не оценивает здоровье пациента единственным числовым значением. Он проверяет сердечно-сосудистую систему, легкие, опорно-двигательный аппарат и другие органы. Все эти части организма могут быть здоровыми или больными, иногда независимо друг от друга.

Масштабы применения Exchange в Office 365 огромны, поэтому естественно, что компания Microsoft столкнулась с данной проблемой и постаралась найти решение. Но для начала следует напомнить о существовании обходного пути, обеспечивающего балансировку нагрузки на уровне 4 и применение нескольких проверок работоспособности.

Как уже отмечалось, ограничение балансировки нагрузки на уровне 4 заключается в том, что подсистема балансировки нагрузки может принимать решения только на основе IP-адреса, по которому получен клиентский запрос на подключение. Учитывая это обстоятельство, можно создать отдельное пространство имен для каждой рабочей нагрузки Exchange и сформировать отдельную виртуальную службу для каждой рабочей нагрузки, как показано на рисунке 2.

 

Создание отдельной виртуальной службы для каждой нагрузки
Рисунок 2. Создание отдельной виртуальной службы для каждой нагрузки

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

Улучшения

Как отмечалось выше, подсистема балансировки нагрузки может выполнить несколько проверок работоспособности на уровне 7, но это не означает, что каждая проверка работоспособности представляет собой надежный способ определить корректность функционирования приложения. Работая с поставщиками подсистем балансировки нагрузки, Microsoft дополнила Exchange 2013 двумя новыми компонентами: Managed Availability и веб-страницей проверки работоспособности.

Managed Availability — встроенная платформа мониторинга Exchange. Она состоит из трех основных компонентов:

  • зонды;
  • мониторы;
  • ответчики.

Эти компоненты тесно взаимодействуют друг с другом, чтобы проверять, обнаруживать и снижать остроту возможных проблем, по сути формируя самовосстанавливающуюся систему внутри Exchange. Сначала Managed Availability запускает зонд. В зависимости от используемого зонда (существуют сотни различных зондов) будет собрана информация или выполнена последовательность тестов для определенного компонента. Затем монитор анализирует результаты применения зонда и использует собранную информацию, чтобы определить работоспособен компонент или нет. Если компонент признан неработоспособным, то ответчик предпринимает соответствующие контрмеры, чтобы вернуть его в работоспособное состояние. Существует множество ответчиков, которые, в зависимости от типа отказа, могут предпринимать различные действия, от простого перезапуска службы до перехода базы данных на другой ресурс и даже полной перезагрузки сервера. Дополнительные сведения о принципах Managed Availability приведены в статье «Server heal thyself — Managed Availability and Exchange 2013» в блоге Exchange Unwashed Blog Тони Редмонда (http://windowsitpro.com/blog/server-heal-thyself-managed-availability-and-exchange-2013).

После того, как функция Managed Availability определяет, что сервер исправен, Exchange 2013 динамически формирует веб-страницу с именем healthcheck.htm, показанную на рисунке 3. Эту веб-страницу проверки работоспособности можно найти в каждом виртуальном каталоге (например, /owa/healthcheck.htm, /ecp/healthcheck.htm).

 

Генерируемая веб-страница показывает состояние сервера
Рисунок 3. Генерируемая веб-страница показывает состояние сервера

Если сервер неисправен, веб-страница не формируется и выдается ошибка с кодом 403. В результате, если направить подсистему балансировки нагрузки на эту веб-страницу, сервер будет признан недоступным, только если страница не обнаружена, а это случается лишь в том случае, если Exchange считает рабочую нагрузку неподходящей.

В конечном итоге достигается значительное углубление проверки работоспособности. На новой веб-странице раскрывается истинное состояние рабочей нагрузки, с учетом многочисленных внутренних проверок работоспособности, выполняемых Managed Availability. Преимущество этого подхода в том, что возможности Managed Availability по определению состояния сервера намного выше, чем у любого другого средства. Более того, определенные рабочие нагрузки совсем не обязательно переводятся в автономный режим, если другие по-прежнему выполняются корректно.

Достойные внимания усовершенствования

Добавление Managed Availability и веб-страницы проверки работоспособности — не самое значительное изменение в Exchange 2013, но благодаря ему подсистема балансировки нагрузки (и любое другое приложение) получает гораздо более полное представление о состоянии сервера. В результате вы не обязательно потеряете сервер при отказе единственной рабочей нагрузки или трафик не будет перенаправлен на сервер, на котором данная рабочая нагрузка (например, OWA) недоступна из-за того, что подсистема балансировки нагрузки не заметила неисправности.