Балансировка нагрузки в Exchange Server

Балансировка нагрузки в Exchange 2016 и более поздних версиях основана на платформе Майкрософт для обеспечения высокой доступности и устойчивости сети, доступной в Exchange 2013. В сочетании с доступностью сторонних решений для балансировки нагрузки (аппаратного и программного обеспечения) существует несколько вариантов реализации балансировки нагрузки в организации Exchange.

С изменениями архитектуры Exchange в Exchange 2013 появились роли сервера почтовых ящиков и сервера клиентского доступа. Для сравнения, в Exchange 2010 службы клиентского доступа, почтовые ящики, транспортный концентратор и единая система обмена сообщениями находились на разных серверах.

Используя минимальные роли сервера, Exchange 2016 и 2019 обеспечивает:

• упрощенное развертывание, так как на сервере почтовых ящиков устанавливаются службы клиентского доступа и роли пограничных транспортных серверов;

• Поток обработки почты управляется в транспортном конвейере, который представляет собой коллекцию служб, подключений, очередей и компонентов, которые направляют сообщения в классификатор транспортной службы на сервере почтовых ящиков.

• высокий уровень доступности за счет развертывания подсистем балансировки нагрузки для распределения клиентского трафика.

Стандарт протокола HTTP, представленный в Exchange 2013, означает, что сходство сеансов больше не требуется в Exchange 2016 и Exchange 2019. Сходство сеансов обеспечивает постоянное подключение к службам с поддержкой обмена сообщениями, чтобы пользователю не нужно было повторно ввести имя пользователя и пароль несколько раз.

Ранее Exchange 2007 и Exchange 2010 поддерживали протокол RPC через HTTP для Мобильный Outlook. В Exchange 2013 появился протокол MAPI через HTTP, но по умолчанию он был отключен. Теперь он включен по умолчанию в Exchange 2016 и Exchange 2019.

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

Роли сервера в Exchange Server

Сокращение числа ролей сервера для Exchange 2016 и Exchange 2019 упрощает реализацию Exchange и требования к оборудованию. Число ролей сервера в Exchange 2016 и 2019 сокращается с семи до двух: сервера почтовых ящиков и пограничного транспортного сервера. Роль сервера почтовых ящиков включает службы клиентского доступа, а пограничный транспортный сервер обеспечивает безопасный поток обработки почты в Exchange 2016 и Exchange 2019, как и в более ранних версиях Exchange.

В Exchange 2013 роль сервера клиентского доступа гарантировала, что когда пользователь пытался получить доступ к своему почтовому ящику, сервер проксировал запрос обратно на сервер почтовых ящиков, обслуживающий почтовый ящик этого пользователя. В связи с этим такие службы, как Outlook в Интернете (предыдущее название — Outlook Web App), отрисовывались в самом почтовом ящике, избавляя от необходимости в сходстве.

Те же функции остаются в Exchange 2016 и Exchange 2019. Если на двух серверах почтовых ящиков размещены разные почтовые ящики, при необходимости они могут проксировать трафик друг для друга. Сервер почтовых ящиков, на котором размещена активная копия почтового ящика, обслуживает пользователя, получающего доступ к нему, даже если этот пользователь подключается к другому серверу.

Дополнительные сведения об изменениях роли сервера в Exchange Server см. в статье Exchange Server архитектуре.

Хотя пограничный транспортный сервер и не является обязательным, он находится в сети периметра, как и в более ранних версиях Exchange, для обеспечения безопасного входящего и исходящего потока почты для организации Exchange.

Дополнительные сведения о транспортной службе см. в статье Общие сведения о транспортной службе на пограничных транспортных серверах.

Протоколы в Exchange Server

Начиная с Exchange 2016, все собственные клиенты Exchange используют протокол HTTP для подключения к указанной службе с файлами cookie HTTP, предоставляемыми пользователю при входе в систему, которые шифруются с помощью SSL-сертификата служб клиентского доступа. Вошедший пользователь может возобновить сеанс на другом сервере почтовых ящиков, где работают службы клиентского доступа, не проходя проверку подлинности заново. Серверы, использующие тот же SSL-сертификат, могут расшифровать файл cookie для проверки подлинности клиента.

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

Благодаря тому, что для клиентского доступа используется только протокол HTTP, балансировка нагрузки также становится проще. При желании для балансировки нагрузки трафика Exchange можно использовать DNS. Вы предоставите клиенту IP-адрес каждого сервера почтовых ящиков, а HTTP-клиент будет обрабатывать работу. В случае отказа сервера Exchange протокол пытается подключиться к другому серверу. Однако существуют недостатки балансировки нагрузки в DNS, описанные в следующем разделе Параметры балансировки нагрузки в Exchange Server.

Дополнительные сведения о HTTP и Exchange Server см. в статье MAPI через HTTP в Exchange Server.

Параметры балансировки нагрузки в Exchange Server

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

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

Использование DNS — самый простой способ балансировки нагрузки трафика Exchange. При балансировке нагрузки с помощью DNS достаточно предоставить клиентам IP-адреса всех серверов почтовых ящиков. После этого DNS распределит трафик на серверы почтовых ящиков путем циклического перебора. В случае полного отказа одного сервера Exchange HTTP-клиент может подключиться к другому.

Простота достигается дорогой ценой, однако в этом случае циклический перебор DNS не является действительно балансировкой нагрузки трафика, так как нет способа программно убедиться, что каждый сервер получает справедливую долю трафика. Кроме того, отсутствует мониторинг уровня обслуживания, поэтому при сбое одной службы клиенты не будут автоматически перенаправляться в доступную службу. Например, если Outlook в Интернете находится в режиме сбоя, клиенты видят страницу ошибки.

Для балансировки нагрузки с помощью DNS при внешней публикации требуется больше внешних IP-адресов. Это означает, что каждому серверу Exchange в организации потребуется внешний IP-адрес.

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

Для управления трафиком службы балансировки нагрузки могут использовать 4-й или 7-й уровень либо их сочетание. У каждого решения есть свои преимущества и недостатки.

• Подсистемы балансировки нагрузки 4-го уровня работают на транспортном уровне, направляя трафик без проверки содержимого.

  Так как эти подсистемы не проверяют содержимое трафика, передача занимает меньше времени. Однако для этого приходится идти на компромиссы. Подсистемам балансировки нагрузки 4-го уровня известны только IP-адрес, протокол и TCP-порт. Зная только один IP-адрес, подсистема балансировки нагрузки может наблюдать только за одной службой.

  Преимущества балансировки нагрузки уровня 4:

  • низкие требования к ресурсам (проверка содержимого не выполняется);

  • распределение трафика на транспортном уровне.

    Риск использования решений 4-го уровня состоит в том, что если в случае сбоя службы сервер по-прежнему будет доступен, клиенты смогут подключаться к неисправной службе. Это означает, что для устойчивой реализации 4-го уровня необходимо несколько IP-адресов с отдельными пространствами имен HTTP для каждой службы, например owa.contoso.com, eas.contoso.com, mapi.contoso.com, чтобы обеспечить мониторинг на уровне служб.

• Подсистемы балансировки нагрузки 7-го уровня работают на прикладном уровне. Они могут проверять содержимое трафика и направлять его соответствующим образом.

  Подсистемы балансировки нагрузки 7-го уровня не предоставляют повышенную производительность, характерную для балансировки нагрузки на 4-м уровне, но обеспечивают простоту за счет единого пространства имен (например, mail.contoso.com) и мониторинга отдельных служб. Подсистемы балансировки нагрузки 7-го уровня анализируют HTTP-путь, например /owa or /Microsoft-Server-ActiveSync, or /mapi,, и могут направлять трафик на рабочие серверы в соответствии с данными мониторинга.

  Преимущества балансировки нагрузки уровня 7:

  • требуется только один IP-адрес;

  • проверка содержимого и возможность направления трафика;

  • уведомления об отказе служб, которые можно переводить в автономный режим;

  • завершение SSL-запросов в подсистеме балансировки нагрузки;

  • распределение трафика на прикладном уровне и анализ целевого URL-адреса.

SSL-запросы должны завершаться в подсистеме балансировки нагрузки, которая будет центральным расположением для защиты от атак с использованием SSL.

Некоторые порты, для которых требуется балансировка нагрузки (например, для протоколов IMAP4 и POP3), могут даже не использоваться в организации Exchange.

Сценарии развертывания балансировки нагрузки в Exchange Server

Exchange 2016 предоставляет значительную гибкость для пространства имен и архитектуры балансировки нагрузки. Учитывая разнообразие вариантов развертывания для подсистем балансировки нагрузки в организации Exchange — от простого DNS до сложных сторонних решений 4-го и 7-го уровней, — рекомендуем изучить их все, исходя из потребностей организации.

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

• Сценарий А. Одно пространство имен без сходства сеансов: уровень 4 или 7

• Сценарий Б. Одно пространство имен без сходства сеансов: уровень 7

• Сценарий В. Одно пространство имен со сходством сеансов, уровень 7

• Сценарий Г. Несколько пространств имен без сходства сеансов, уровень 4

Сценарий А. Одно пространство имен без сходства сеансов: уровень 4 или 7

В этом сценарии 4-го уровня в клиентах HTTP развертывается одно пространство имен — mail.contoso.com. Подсистема балансировки нагрузки не сохраняет сходство сеансов. Так как это решение уровня 4, подсистема балансировки нагрузки настроена для проверки работоспособности только одного виртуального каталога, так как она не может отличить Outlook в Интернете запросов от запросов RPC.

С точки зрения подсистемы балансировки нагрузки в этом примере работоспособность выполняется для каждого сервера, а не для каждого протокола для указанного пространства имен. Администраторы должны будут выбрать, какой виртуальный каталог они должны выбрать для пробы работоспособности. Рекомендуется выбрать широко используемый виртуальный каталог. Например, если большинство пользователей используют Outlook в Интернете, выберите виртуальный каталог Outlook в Интернете в пробе работоспособности.

Пока ответ проверки работоспособности Outlook в Интернете работоспособности, подсистема балансировки нагрузки сохраняет целевой сервер почтовых ящиков в пуле балансировки нагрузки. Однако если проверка работоспособности Outlook в Интернете по какой-либо причине завершается сбоем, подсистема балансировки нагрузки удаляет целевой сервер почтовых ящиков из пула балансировки нагрузки для всех запросов, связанных с этим пространством имен. Это означает, что в случае сбоя пробы работоспособности все запросы клиента для этого пространства имен направляются на другой сервер независимо от протокола.

Сценарий Б. Одно пространство имен без сходства сеансов: уровень 7

В этом сценарии 7-го уровня для всех клиентов HTTP развертывается одно пространство имен — mail.contoso.com. Подсистема балансировки нагрузки не сохраняет сходство сеансов. Так как подсистема балансировки нагрузки настроена для уровня 7, происходит завершение SSL, а подсистема балансировки нагрузки знает URL-адрес назначения.

Мы рекомендуем эту конфигурацию для Exchange 2016 и Exchange 2019. Подсистема балансировки нагрузки настроена для проверки работоспособности конечных серверов почтовых ящиков в пуле балансировки нагрузки, а проба работоспособности настраивается для каждого виртуального каталога.

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

Сценарий В. Одно пространство имен со сходством сеансов, уровень 7

В этом сценарии 7-го уровня для всех клиентов HTTP развертывается одно пространство имен — mail.contoso.com. Так как подсистема балансировки нагрузки настроена для 7-го уровня, SSL-запросы завершаются, а подсистеме балансировки нагрузки известен целевой URL-адрес. Подсистема балансировки нагрузки также настроена для проверки работоспособности целевых серверов почтовых ящиков в пуле балансировки нагрузки. Для каждого виртуального каталога настроен зонд проверки работоспособности.

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

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

Сценарий Г. Несколько пространств имен без сходства сеансов

Последний сценарий с несколькими пространствами имен без сходства сеансов обеспечивает проверку работоспособности отдельных протоколов и возможности 4-го уровня. Для каждого клиента HTTP развертывается уникальное пространство имен. Например, можно настроить клиенты HTTP по адресам mail.contoso.com, mapi.contoso.com и eas.contoso.com.

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

Балансировка нагрузки и управляемая доступность в Exchange Server

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

Exchange 2016 и Exchange 2019 включают встроенное решение для мониторинга, известное как управляемая доступность. Управляемая доступность, также известная как активный мониторинг или локальный активный мониторинг, представляет собой интеграцию встроенных действий мониторинга и восстановления с платформой высокого уровня доступности Exchange.

Служба управляемой доступности включает автономное отвечающее устройство. При вызове автономного отвечающего устройства соответствующий протокол (или сервер) удаляется из службы.

Чтобы подсистемы балансировки нагрузки не направляли трафик на сервер почтовых ящиков, управляемый доступностью, помеченный как автономный, необходимо настроить пробы работоспособности подсистемы балансировки нагрузки для проверки <virtualdirectory>/healthcheck.htm, например <https://mail.contoso.com/owa/healthcheck.htm>.

Дополнительные сведения об управляемой доступности см. в статье Управляемое обеспечение доступности.