Высокая доступность и балансировка нагрузки соединителей и приложений частной сети
В этой статье объясняется, как распределение сетевого трафика работает с развертыванием прокси для приложения. Узнайте, как распределяется трафик между пользователями и соединителями, а также советы по оптимизации производительности соединителя. Узнайте, как осуществляется поток трафика между соединителями и серверами приложений во внутренней сети, а также ознакомьтесь с рекомендациями по балансировке нагрузки между несколькими такими серверами.
Распределение трафика между соединителями
Соединители устанавливают подключения с учетом принципов обеспечения высокого уровня доступности. Нет никакой гарантии, что трафик равномерно распределяется по коннекторам, и отсутствует привязка сессии. Однако использование меняется, и запросы отправляются случайным образом в экземпляры приложения службы прокси. Обычно это приводит к примерно равномерному распределению трафика между соединителями. На схеме и шагах показано, как устанавливаются подключения между пользователями и соединителями.
- Пользователь на клиентском устройстве пытается получить доступ к локальному приложению, опубликованному через прокси приложения.
- Запрос проходит через Azure Load Balancer, чтобы определить, какой экземпляр службы прокси приложения должен принимать запрос. В наличии десятки экземпляров, которые могут принимать запросы для всего регионального трафика. Такой метод позволяет равномерно распределять трафик между экземплярами службы.
- Запрос отправляется в шину обслуживания.
- Service Bus сигнализирует о доступности соединителя. Затем соединитель получает запрос из шины сервисов.
- На шаге 2 запросы отправляются в разные экземпляры службы прокси приложения, поэтому подключения, скорее всего, будут выполняться с различными соединителями. В результате соединители используются в пределах группы практически равномерно.
- Соединитель передает запрос внутреннему серверу приложения. Затем приложение отправляет ответ обратно в соединитель.
- Соединитель завершает ответ, открывая исходящее подключение к службе, откуда пришел запрос. Затем это подключение немедленно закрывается. По умолчанию каждый соединитель поддерживает не более 200 одновременных исходящих подключений.
- Затем ответ передаётся обратно клиенту от экземпляра сервиса.
- Последующие запросы из того же подключения повторяют шаги.
Приложение часто имеет много ресурсов и открывает несколько подключений при загрузке. Каждое подключение проходит этапы, чтобы быть назначено экземпляру службы. Если подключение не связано с соединителем, выберите новый доступный соединитель.
Рекомендации по обеспечению высокого уровня доступности соединителей
Из-за способа распределения трафика между соединителями для обеспечения высокой доступности важно всегда иметь как минимум два соединителя в группе соединителей. Предпочтительно использовать три соединителя для обеспечения дополнительного буфера между соединителями. Чтобы определить правильное число соединителей, воспользуйтесь документацией по планированию ресурсов.
Размещайте соединители на разных исходящих соединениях, чтобы избежать единой точки отказа. Если соединители используют одно и то же исходящее подключение, проблема сети с подключением влияет на все соединители, использующие его.
Избегайте принудительного перезапуска соединителей при подключении к производственным приложениям. Это может негативно повлиять на распределение трафика между соединителями. Перезапуск соединителей приводит к тому, что другие соединители становятся недоступными и принудительно подключаются к оставшемуся доступному соединителю. В результате соединители изначально используются неравномерно.
Избегайте всех форм инспекции на лету в исходящих коммуникациях по протоколу TLS между соединительными каналами и Azure. Этот тип встроенной проверки приводит к ухудшению потока обмена данными.
Убедитесь, что для ваших соединителей запущены автоматические обновления. Если служба обновления соединителя частной сети запущена, соединители обновляются автоматически и получают последнее обновление. Если служба обновления соединителей не отображается на сервере, для получения обновлений необходимо переустановить соединитель.
Поток трафика между соединителями и внутренними серверами приложений
Другим ключевым процессом, для которого важна высокая доступность, является подключение между соединителями и внутренними серверами. Когда приложение публикуется через прокси приложения Microsoft Entra, трафик от пользователей к приложениям проходит через три прыжка:
- Пользователь подключается к общедоступной конечной точке службы прокси приложения Microsoft Entra в Azure. Подключение устанавливается между исходящим IP-адресом клиента (общедоступным) клиента и IP-адресом конечной точки прокси приложения.
- Соединитель частной сети извлекает HTTP-запрос клиента из службы прокси приложения.
- Соединитель частной сети подключается к целевому приложению. Соединитель использует для создания подключения собственный IP-адрес.
Рекомендации по использованию поля заголовка X-Forwarded-For
В некоторых ситуациях (например, аудит, балансировка нагрузки и т. д.), предоставление общего доступа к исходному IP-адресу внешнего клиента с локальной средой является обязательным требованием. Чтобы устранить требование, соединитель частной сети Microsoft Entra добавляет поле заголовка X-Forwarded-For с исходным IP-адресом клиента (общедоступным) в HTTP-запрос. Соответствующее сетевое устройство (подсистема балансировки нагрузки, брандмауэр), веб-сервер или серверное приложение может затем прочитать и использовать эту информацию.
Рекомендации по балансировке нагрузки между несколькими серверами приложений
Балансировка нагрузки важна, если группе соединителей, назначенной приложению прокси, назначено два или более соединителя. Балансировка нагрузки также важна при запуске серверного веб-приложения на нескольких серверах.
Сценарий 1. Серверное приложение не требует сохраняемости сеансов
В этом простейшем сценарии серверное веб-приложение не требует сохранения сеансов. Экземпляр бэкенд-приложения обрабатывает запросы пользователей в ферме серверов. Вы можете использовать балансировщик нагрузки уровня 4 и настроить его без привязки. Некоторые варианты включают компонент балансировки сетевой нагрузки Майкрософт и Azure Load Balancer или подсистему балансировки нагрузки от другого поставщика. Настройте стратегию кругового обхода в системе доменных имен (DNS).
Сценарий 2. Серверное приложение требует сохранения сеансов
В данной ситуации серверное веб-приложение требует привязки сессий (постоянства сессий) во время сеанса аутентификации. Серверный экземпляр приложения обрабатывает запросы пользователей. Запросы, которые выполняются на том же сервере в ферме серверов. Этот сценарий может быть более сложным, так как клиент обычно устанавливает несколько подключений к службе прокси приложения. Запросы, направленные через разные подключения, могут поступать на разные соединители и разные серверы в ферме. Так как каждый соединитель использует для этого обмена данными собственный IP-адрес, подсистема балансировки нагрузки не может обеспечить сохранение сеансов на основе IP-адресов соединителей. Также нельзя использовать сходство по исходному IP. Ниже описаны некоторые варианты для сценария 2.
Вариант 1: Используйте сохранение сеанса, основанное на файле cookie сессии, установленном балансировщиком нагрузки. Этот вариант рекомендуется, так как он позволяет более равномерно распределять нагрузку между внутренними серверами. Для этого варианта требуется подсистема балансировки нагрузки уровня 7 с этой возможностью, которая может обрабатывать HTTP-трафик и завершать TLS-подключение. Вы можете использовать шлюз приложений Azure (с привязкой сеанса) или балансировщик нагрузки от другого поставщика.
Вариант 2: Основывайте персистентность сеанса на поле заголовка X-Forwarded-For. Для этого варианта требуется подсистема балансировки нагрузки уровня 7, которая может обрабатывать HTTP-трафик и завершать TLS-подключение.
Вариант 3. Настройте серверное приложение так, чтобы оно не требовало сохранения сеансов.
Чтобы понять требования к балансировке нагрузки внутреннего приложения, ознакомьтесь с документацией поставщика программного обеспечения.