Высокая доступность и балансировка нагрузки соединителей и приложений частной сети

В этой статье объясняется, как распределение трафика работает с развертыванием прокси приложения. Узнайте, как распределяется трафик между пользователями и соединителями, а также советы по оптимизации производительности соединителя. Узнайте, как потоки трафика между соединителями и серверами внутренних приложений, а также рекомендации по балансировке нагрузки между несколькими внутренними серверами.

Распределение трафика между соединителями

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

1. Пользователь на клиентском устройстве пытается получить доступ к локальному приложению, опубликованному через прокси приложения.
2. Запрос проходит через Azure Load Balancer, чтобы определить, какой экземпляр службы прокси приложения должен принимать запрос. Существует десятки экземпляров, которые могут принимать запросы для всего трафика в регионе. Такой метод позволяет равномерно распределять трафик между экземплярами службы.
3. Запрос отправляется в Служебную шину.
4. Служебная шина передает сигнал доступному соединителю. Соединитель затем получает запрос от Служебной шины.
   • На шаге 2 запросы отправляются в разные экземпляры службы прокси приложения, поэтому подключения, скорее всего, будут выполняться с различными соединителями. В результате соединители используются в пределах группы практически равномерно.
5. Соединитель передает запрос внутреннему серверу приложения. Затем приложение отправляет ответ обратно в соединитель.
6. Соединитель завершает ответ, открывая исходящее подключение к экземпляру службы, из которого пришел запрос. Затем это подключение немедленно закрывается. По умолчанию каждый соединитель поддерживает не более 200 одновременных исходящих подключений.
7. Затем ответ возвращается клиенту из экземпляра службы.
8. Последующие запросы из того же подключения повторяют шаги.

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

Рекомендации по обеспечению высокого уровня доступности соединителей

• Из-за способа распределения трафика между соединителями для обеспечения высокой доступности важно всегда иметь как минимум два соединителя в группе соединителей. Три соединителя предпочтительнее предоставить дополнительный буфер между соединителями. Чтобы определить правильное число соединителей, воспользуйтесь документацией по планированию ресурсов.

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

• Избегайте принудительного перезапуска соединителей при подключении к производственным приложениям. Это может негативно повлиять на распределение трафика между соединителями. Перезапуск соединителей приводит к тому, что другие соединители становятся недоступными и принудительно подключаются к оставшемуся доступному соединителю. В результате соединители изначально используются неравномерно.

• Избегайте всех форм встроенной проверки исходящего трафика tls между соединителями и Azure. Этот тип встроенной проверки приводит к ухудшению потока обмена данными.

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

Поток трафика между соединителями и внутренними серверами приложений

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

1. Пользователь подключается к общедоступной конечной точке службы прокси приложения Microsoft Entra в Azure. Подключение устанавливается между исходящим IP-адресом клиента (общедоступным) клиента и IP-адресом конечной точки прокси приложения.
2. Соединитель частной сети извлекает HTTP-запрос клиента из службы прокси приложения.
3. Соединитель частной сети подключается к целевому приложению. Соединитель использует для создания подключения собственный 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. Настройте серверное приложение так, чтобы оно не требовало сохранения сеансов.

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

Следующие шаги

• Включение прокси приложения
• Единый вход с помощью прокси приложения
• Включение условного доступа
• Устранение неполадок с прокси приложениями
• Узнайте, как архитектура Microsoft Entra поддерживает высокий уровень доступности