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

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

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

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

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

В Azure доступны следующие основные службы балансировки нагрузки и службы с возможностями балансировки нагрузки:

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

  Это важно

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

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

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

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

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

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

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

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

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

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

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

Поддержка HTTP(S) и ее отсутствие

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

• Не HTTP(S): К этим службам балансировки нагрузки относятся службы TCP и UDP уровня 4 или службы балансировки нагрузки на основе DNS.

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

Выбор решения для балансировки нагрузки для вашего сценария

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

• Тип трафика: Определите, является ли это веб-приложение HTTP(S) и является ли оно общедоступным или частным приложением.

• Глобальный или региональный: Уточните, нужно ли балансировать нагрузку виртуальных машин или контейнеров внутри одной виртуальной сети, балансировать нагрузку единиц масштабирования или развертываний в нескольких регионах, или и то, и другое.

• Наличие: Просмотрите соглашение об уровне обслуживания (SLA).

• Стоимость: Учесть стоимость самой услуги, а также операционные затраты на управление решением, на основе этой услуги. Дополнительные сведения см. в ценах на Azure.

• Функции и ограничения: Определите возможности, поддерживаемые каждой службой, и применимые ограничения службы.

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

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

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

Определения

• Веб-приложение (HTTP/HTTPS) ссылается на приложение, которое требует по крайней мере одной из следующих возможностей:

  • Принимает решение о маршрутизации данных уровня 7, например URL-путь
  • Поддерживает проверку нагрузки данных связи, таких как тело HTTP-запроса
  • Обеспечивает функциональность TLS

• Приложение, не использующее HTTP(S), относится к приложению, которому требуется поддержка протоколов четвёртого уровня (TCP или UDP) или протокола транспортного уровня TLS. Azure Load Balancer и Шлюз приложений Azure предоставляют возможности для обработки такого трафика. Однако их функции и поведение отличаются, как описано в этой статье сравнения.

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

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

  Замечание

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

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

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

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

• AKS позволяет развертывать контейнерные приложения и управлять ими. AKS предоставляет бессерверный Kubernetes, интегрированный процесс непрерывной интеграции и доставки (CI/CD), а также защиту и управление корпоративного уровня. Эти рабочие нагрузки AKS называются серверными службами AKS. Дополнительные сведения см. в разделе "Архитектура AKS".

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

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

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

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

• Сквозная подсистема балансировки нагрузки — это подсистема балансировки нагрузки , в которой клиент напрямую устанавливает соединение с серверным сервером, выбранным алгоритмом распределения подсистемы балансировки нагрузки.

• Завершение подсистемы балансировки нагрузки — это место, когда клиент устанавливает соединение с подсистемой балансировки нагрузки (прокси-сервером), а отдельное подключение инициируется с подсистемы балансировки нагрузки на внутренний сервер.

Другие вопросы

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

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

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

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

Примеры

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

Дальнейшие шаги

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