Варианты балансировки нагрузки

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

Azure предоставляет различные службы балансировки нагрузки, которые можно использовать для распределения рабочих нагрузок между несколькими вычислительными ресурсами. К этим службам относятся управление API Azure, шлюз приложений Azure, Azure Front Door, Azure Load Balancer и диспетчер трафика Azure.

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

Классификации служб

Службы балансировки нагрузки Azure можно разделить на два измерения: глобальные и региональные и HTTP(S) и не HTTP(S).

Глобальный и региональный

• Глобальный: Эти службы балансировки нагрузки распределяют трафик между региональными внутренними серверами, облаками или гибридными локальными службами. Эти службы предоставляют единый уровень управления, который направляет трафик конечных пользователей в доступные серверные части глобально. Они реагируют на изменения надежности службы или производительности, чтобы повысить доступность и производительность. Их можно рассматривать как системы, которые балансируют нагрузку между метками приложений, конечными точками или единицами масштабирования, размещенными в разных регионах или географических регионах.
• Региональный: Эти службы балансировки нагрузки распределяют трафик в виртуальных сетях между виртуальными машинами или зональными и зональными конечными точками службы, избыточными между зонами в пределах региона. Их можно рассматривать как системы, которые выполняют балансировку нагрузки между виртуальными машинами, контейнерами или кластерами в пределах региона в виртуальной сети.

HTTP(S) и не HTTP(S)

• HTTP(S): Эти службы балансировки нагрузки — это подсистемы балансировки нагрузки уровня 7 , которые принимают только трафик HTTP(S). Они предназначены для веб-приложений или других конечных точек HTTP(S). К ним относятся такие функции, как разгрузка SSL, брандмауэр веб-приложений, балансировка нагрузки на основе пути и сходство сеансов.
• Не HTTP(S): Эти службы балансировки нагрузки — это службы TCP или UDP уровня 4 или балансировка нагрузки на основе DNS.

В следующей таблице перечислены службы балансировки нагрузки Azure.

Службы балансировки нагрузки Azure

Ниже приведены основные службы балансировки нагрузки, доступные в Azure:

• Управление API — это управляемая служба, которая позволяет публиковать, защищать, преобразовывать, поддерживать и отслеживать API HTTP(S). Он предоставляет шлюз для API и может балансировать трафик между узлами в указанном серверном пуле с балансировкой нагрузки. Вы можете выбрать три различных метода балансировки нагрузки: циклический перебор, весовый вес и приоритет.

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

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

• Load Balancer — это высокопроизводительная служба балансировки нагрузки уровня 4 с низкой задержкой (входящие и исходящие) для всех протоколов UDP и TCP. Она разработана для обработки миллионов запросов в секунду, обеспечивая высокую доступность решения. Load Balancer является избыточным по зонам, обеспечивая высокий уровень доступности в зонах доступности. Она поддерживает как топологию регионального развертывания, так и топологию между регионами.

• Диспетчер трафика — это подсистема балансировки нагрузки на основе DNS, которая позволяет оптимально распределять трафик между службами в глобальных регионах Azure, обеспечивая высокую доступность и скорость реагирования. Так как Диспетчер трафика является службой балансировки нагрузки на основе DNS, балансировка нагрузки выполняется только на уровне домена. По этой причине он не может выполнять отработку отказа так быстро, как Azure Front Door, из-за распространенных проблем при кэшировании DNS и системах, не использующих значения времени жизни DNS (TTL).

Дерево принятия решений для балансировки нагрузки в Azure

При выборе решения балансировки нагрузки учитывайте такие факторы, как следующие факторы:

• Тип трафика: Это веб-приложение HTTP(S)? Это общедоступное или частное приложение?
• Глобальный и региональный: Требуется ли балансировка нагрузки виртуальных машин или контейнеров в одной виртуальной сети или единиц масштабирования нагрузки или развертываний в разных регионах или обоих регионах?
• Наличие: Что такое соглашение об уровне обслуживания?
• Стоить: Дополнительные сведения см. в ценах на Azure. Помимо стоимости самой службы, рассмотрите операционные затраты на управление решением, построенным на этой службе.
• Функции и ограничения: Какие возможности поддерживаются каждой службой и каковы ограничения служб каждой службы?

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

Каждое приложение имеет уникальные требования, не захваченные в простых деревах принятия решений. Рассмотрим эту блок-схему или рекомендацию Azure Copilot в качестве отправной точки. Затем выполните более подробную оценку.

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

Определения

• Веб-приложение (HTTP/HTTPS): Это обозначение относится к возможности принятия решения о маршрутизации для данных уровня 7, таких как путь URL-адреса, поддержка проверки полезных данных связи (например, текст HTTP-запроса) или обработка функций TLS.

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

• Глобальный или развернутый в нескольких регионах: Если этот подсистема балансировки нагрузки должна иметь один высокодоступный уровень управления, который направляет трафик к общедоступным конечным точкам в глобально распределенном приложении. Это может поддерживать топологии active-active или active-passive в разных регионах.

  Примечание.

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

  Этот сценарий не является основной точкой этого решения.

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

• Платформа как услуга (PaaS) предоставляет управляемую среду размещения, где можно развернуть приложение без необходимости управлять виртуальными машинами или сетевыми ресурсами. В этом случае PaaS относится к службам, которые обеспечивают интегрированную балансировку нагрузки в пределах региона. Дополнительные сведения см. в разделе "Выбор службы вычислений — масштабируемость".

• Служба Azure Kubernetes (AKS) позволяет развертывать контейнерные приложения и управлять ими. AKS предоставляет бессерверные Kubernetes, интегрированную интеграцию и непрерывную доставку, а также безопасность и управление корпоративным классом. Дополнительные сведения об архитектурных ресурсах AKS см. в Служба Azure Kubernetes архитектуре.

• Инфраструктура как услуга (IaaS) — это вычислительный параметр, в котором вы подготавливаете необходимые виртуальные машины, а также связанные компоненты сети и хранилища. Приложения IaaS требуют внутренней балансировки нагрузки в виртуальной сети с помощью Load Balancer.

• Обработка на уровне приложений относится к специальной маршрутизации в виртуальной сети. Примеры включают маршрутизацию на основе путей между виртуальными машинами или масштабируемыми наборами виртуальных машин. Дополнительные сведения см. в статье О том, как развернуть шлюз приложений за Azure Front Door?

• Только API-интерфейсы относятся к api балансировки нагрузки HTTP(S), которые не являются веб-приложениями. В этом случае следует рассмотреть возможность управления API Azure для балансировки трафика между внутренними концами API, которые еще не балансируют нагрузку с помощью другого механизма.

• Ускорение производительности относится к функциям, которые ускоряют веб-доступ. Ускорение производительности можно достичь с помощью сетей доставки содержимого (CDN) или оптимизированной точки присутствия для ускорения подключения клиента к целевой сети. Azure Front Door поддерживает как CDN, так и ускорение трафика Anycast. Преимущества обоих функций можно получить с помощью шлюза приложений или без нее в архитектуре.

Дополнительные рекомендации

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

• Поддержка WebSocket
• Поддержка событий, отправленных сервером
• Поддержка HTTP/2 (как получение, так и продолжение серверных узлов)
• Поддержка липких сеансов
• Механизм мониторинга работоспособности внутреннего узла
• Взаимодействие с клиентом или задержка между неработоспособным обнаружением и удалением из логики маршрутизации.

Разгрузка возможностей подсистемы балансировки нагрузки

Некоторые параметры балансировки нагрузки в Azure позволяют выгружать возможности с внутренних узлов на подсистему балансировки нагрузки, так как некоторые реализуют шаблон облачной разработки шлюза . Например, шлюз приложений может выгрузить TLS, поэтому общедоступный сертификат рабочей нагрузки управляется в одном расположении вместо внутренних узлов. Управление API можно настроить для разгрузки некоторых основных проблем авторизации, таких как проверка утверждений в маркерах доступа JWT. Разгрузка перекрестных проблем может помочь снизить сложность логики в внутренних концах и повысить их производительность.

Примеры

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

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

• Создание общедоступной подсистемы балансировки нагрузки для балансировки нагрузки виртуальных машин
• Прямой веб-трафик с Шлюз приложений
• Настройка Диспетчер трафика для глобальной балансировки нагрузки на основе DNS
• Настройка Azure Front Door для высокодоступного глобального веб-приложения