Термин балансировки нагрузки относится к распределению рабочих нагрузок между несколькими вычислительными ресурсами. Балансировка нагрузки нацелена на оптимизацию использования ресурсов, увеличение пропускной способности, уменьшение времени отклика и предотвращение перегрузки одного ресурса. Кроме того, она может повысить доступность за счет совместного использования рабочей нагрузки в пределах избыточных вычислительных ресурсов.
Azure предоставляет различные службы балансировки нагрузки, которые можно использовать для распределения рабочих нагрузок между несколькими вычислительными ресурсами. К этим ресурсам относятся Шлюз приложений Azure, Azure Front Door, Azure Load Balancer и Диспетчер трафика Azure.
В этой статье описываются некоторые рекомендации по определению соответствующего решения балансировки нагрузки для потребностей рабочей нагрузки.
Классификации служб
Службы балансировки нагрузки Azure можно разделить на два измерения: глобальные и региональные и HTTP(S) и не HTTP(S).
Глобальный и региональный
- Global: эти службы балансировки нагрузки распределяют трафик между региональными внутренними серверами, облаками или гибридными локальными службами. Эти службы поддерживают управление одним уровнем управления, отвечающим за глобальное маршрутизацию трафика конечных пользователей в доступную серверную часть. Они часто реагируют на изменения надежности службы или производительности, чтобы повысить доступность и производительность. Их можно рассматривать как системы, которые распределяют нагрузку между единицами масштабирования приложений, конечными точками или единицами масштабирования, размещенными в разных регионах и географических областях.
- Регион. Эти службы балансировки нагрузки распределяют трафик в виртуальных сетях между виртуальными машинами или зональными и зональными конечными точками службы, избыточными между зонами в пределах региона. Их можно рассматривать как системы, которые выполняют балансировку нагрузки между виртуальными машинами, контейнерами или кластерами в пределах региона в виртуальной сети.
HTTP(S) и не HTTP(S)
- HTTP(S): эти службы балансировки нагрузки — это подсистемы балансировки нагрузки уровня 7 , которые принимают только трафик HTTP(S). Они предназначены для веб-приложений или других конечных точек HTTP(S). Они могут иметь такие функции, как разгрузка SSL, брандмауэр веб-приложения, балансировка нагрузки на основе пути и сходство сеансов.
- Не HTTP(S): эти службы балансировки нагрузки — это подсистемы балансировки нагрузки уровня 4 , которые могут обрабатывать трафик, отличный от HTTP(S), в основном службы TCP или UDP.
В следующей таблице перечислены службы балансировки нагрузки Azure.
| Service | Глобальный или региональный | Рекомендуемый трафик |
|---|---|---|
| Azure Front Door | Глобальный | HTTP(S) |
| Диспетчер трафика Azure | Глобальный | Без поддержки HTTP(S) |
| Шлюз приложений Azure | Региональный | HTTP(S) |
| Azure Load Balancer | Региональные или глобальные | Без поддержки HTTP(S) |
Примечание.
Диспетчер трафика Azure и Azure Load Balancer имеют возможности распределения трафика HTTP(S), но не имеют определенных функций для маршрутизации на основе сведений об единице данных протокола выше уровня 4. Они оба поддерживают трафик HTTP(S), но только на уровне функциональных возможностей уровня 4.
Службы балансировки нагрузки Azure
Ниже приведены основные службы балансировки нагрузки, доступные в Azure:
Azure Front Door — это сеть доставки приложений, которая обеспечивает глобальную балансировку нагрузки и службу ускорения сайта для веб-приложений. Он предлагает возможности уровня 7 для приложения, таких как разгрузка SSL, маршрутизация на основе пути, быстрая отработка отказа и кэширование для повышения производительности и высокой доступности приложений.
Диспетчер трафика — это подсистема балансировки нагрузки на основе DNS, которая позволяет оптимально распределять трафик между службами в глобальных регионах Azure, обеспечивая высокую доступность и скорость реагирования. Так как Диспетчер трафика является службой балансировки нагрузки на основе DNS, балансировка нагрузки выполняется только на уровне домена. По этой причине он не может выполнять отработку отказа так быстро, как Azure Front Door, из-за распространенных проблем, возникающих при кэшировании DNS и системах, не использующих DNS-TTLs.
Шлюз приложений предоставляет контроллер доставки приложений в качестве службы, предлагая различные возможности балансировки нагрузки уровня 7 и функциональные возможности брандмауэра веб-приложений. Используйте его для перехода из общедоступного сетевого пространства в веб-серверы, размещенные в частном сетевом пространстве в регионе.
Load Balancer — это высокопроизводительная служба балансировки нагрузки уровня 4 с низкой задержкой (входящие и исходящие) для всех протоколов UDP и TCP. Она разработана для обработки миллионов запросов в секунду, обеспечивая высокую доступность решения. Load Balancer является избыточным по зонам, обеспечивая высокий уровень доступности в зонах доступности. Она поддерживает как топологию регионального развертывания, так и топологию между регионами.
Примечание.
Технология кластеризации, например приложения контейнеров Azure или Служба Azure Kubernetes, содержит конструкции балансировки нагрузки, которые работают главным образом в пределах собственной привязки кластера, маршрутизация трафика в доступные экземпляры приложений на основе готовности и проб работоспособности. Эти параметры балансировки нагрузки не рассматриваются в этой статье.
Дерево принятия решений для балансировки нагрузки в Azure
При выборе решения балансировки нагрузки следует учитывать такие факторы, как следующие факторы:
- Тип трафика: это веб-приложение HTTP(S)? Это общедоступное или частное приложение?
- Глобальный и региональный: необходимо ли балансировать нагрузку виртуальных машин или контейнеров в одной виртуальной сети, а также масштабировать единицы или развертывания нагрузки в разных регионах или обоих регионах?
- Доступность: что такое соглашение об уровне обслуживания?
- Стоимость. Дополнительные сведения см. в ценах на Azure. Помимо стоимости самой службы, учитывайте расходы на управление решением, созданным на ее основе.
- Функции и ограничения. Какие возможности поддерживаются для каждой службы и какие ограничения являются ограничениями службы для каждой службы?
! [СОВЕТ] В портал Azure представлено руководство на основе анкеты, аналогичное следующей блок-схеме. В портал Azure найдите "Балансировка нагрузки - помогите мне выбрать". Ответив на вопросы, вы можете сузить параметры балансировки нагрузки.
Следующая блок-схема помогает выбрать решение для балансировки нагрузки для приложения. В блок-схеме содержится набор ключевых критериев принятия решения, которые соответствуют рекомендациям.
Используйте эту блок-схему в качестве отправной точки. К каждому приложению есть свои требования, поэтому в качестве отправной точки используйте рекомендации. Затем выполните более подробную оценку.
Если рабочая нагрузка включает несколько служб, требующих балансировки нагрузки, важно оценить каждую службу по отдельности. Во многих случаях эффективная настройка использует несколько типов решения балансировки нагрузки. Эти решения могут быть включены в различные места в архитектуре рабочей нагрузки, каждая из которых обслуживает уникальную функцию или роль.
Определения
Веб-приложение (HTTP/HTTPS ): это относится к необходимости принятия решения о маршрутизации для данных уровня 7, таких как путь URL-адреса, поддержка проверки полезных данных связи (например, текста HTTP-запроса) или обработки функций TLS.
Приложение с доступом к Интернету: приложения, которые общедоступны из Интернета. В качестве рекомендации владельцы приложений применяют политики ограниченного доступа или защищают приложение путем настройки таких предложений, как брандмауэр веб-приложения и защита от атак DDoS.
Глобальный или развернутый в нескольких регионах: если в этом подсистеме балансировки нагрузки должен быть один высокодоступный уровень управления, отвечающий за маршрутизацию трафика на общедоступные конечные точки в глобально распределенном приложении. Это может быть поддержка топологий active-active или active-пассивных в разных регионах.
Примечание.
Можно использовать региональную службу, например Шлюз приложений, для балансировки нагрузки между внутренними серверами, охватывающими несколько регионов, и управлять маршрутизацией с помощью одной плоскости управления. Эта архитектура возможна с помощью межрегионального Приватный канал, пиринга глобальной виртуальной сети или даже общедоступных IP-адресов служб в других регионах.
Этот сценарий не является основной точкой этого решения, однако.
Использование регионального ресурса в качестве маршрутизатора для глобально распределенных серверных служб представляет региональную единую точку сбоя и вызывает дополнительную задержку, так как трафик принудительно выполняется через один регион, прежде чем переходить к другому, а затем снова.
Платформа как услуга (PaaS): предоставляет управляемую среду размещения, где можно развернуть приложение без необходимости управлять виртуальными машинами или сетевыми ресурсами. В этом случае PaaS относится к службам, которые обеспечивают интегрированную балансировку нагрузки в пределах региона. Дополнительные сведения см. в разделе "Выбор службы вычислений — масштабируемость".
Служба Azure Kubernetes (AKS): позволяет развертывать контейнерные приложения и управлять ими. AKS предоставляет бессерверные Kubernetes, интегрированную интеграцию и непрерывную доставку, а также безопасность и управление корпоративным классом. Дополнительные сведения об архитектурных ресурсах AKS см. в Служба Azure Kubernetes архитектуре.
Инфраструктура как услуга (IaaS) — вариант вычислений, в котором подготавливаются необходимые виртуальные машины, а также связанные компоненты сети и хранилища. Приложения IaaS требуют внутренней балансировки нагрузки в виртуальной сети с помощью Load Balancer.
Обработка на уровне приложений: относится к специальной маршрутизации в виртуальной сети. Например, маршрутизация на основе пути в виртуальной сети между виртуальными машинами или масштабируемыми наборами виртуальных машин. Дополнительные сведения см. в статье "Когда следует развернуть Шлюз приложений за Azure Front Door?".
Ускорение производительности: относится к функциям, которые ускоряют веб-доступ. Ускорение производительности можно достичь с помощью сетей доставки содержимого (CDN) или оптимизированной точки присутствия для ускорения подключения клиента к целевой сети. Azure Front Door поддерживает как CDN, так и ускорение трафика Anycast. Преимущества обоих функций можно получить с Шлюз приложений или без Шлюз приложений в архитектуре.
Дополнительные рекомендации
Каждая служба балансировки нагрузки также имеет поддержку или сведения о реализации, которые также необходимо учитывать. Ниже приведены некоторые примеры, которые могут быть актуальными для сценария балансировки нагрузки.
- Поддержка веб-сокетов
- Поддержка HTTP/2 (как получение, так и продолжение серверных узлов)
- Поддержка липких сеансов
- Механизм мониторинга работоспособности внутреннего узла
- Взаимодействие с клиентом или задержка между неработоспособным обнаружением и удалением из логики маршрутизации.
Примеры
В следующей таблице перечислены различные статьи, основанные на службах балансировки нагрузки, используемых в качестве решения.
| Службы | Статья | Описание |
|---|---|---|
| Load Balancer | Балансировка нагрузки виртуальных машин между зонами доступности | Балансировка нагрузки виртуальных машин между зонами доступности для защиты приложений и данных от маловероятного сбоя или потери всего центра обработки данных. При избыточности зоны одна или несколько зон доступности могут завершиться ошибкой, и путь к данным сохраняется до тех пор, пока одна зона в регионе остается работоспособной. |
| Azure Front Door | Совместное использование расположения в реальном времени с помощью бессерверных служб Azure с низкой стоимостью | Используйте Azure Front Door, чтобы обеспечить более высокую доступность для приложений, чем развертывание в одном регионе. Если региональный сбой влияет на основной регион, вы можете использовать Azure Front Door для отработки отказа в дополнительный регион. |
| Диспетчер трафика | Многоуровневое веб-приложение, созданное для обеспечения высокой доступности и аварийного восстановления | Развертывание устойчивых многоуровневых приложений, созданных для обеспечения высокой доступности и аварийного восстановления. Если основной регион становится недоступным, Диспетчер трафика выполняет отработку отказа в дополнительный регион. |
| Azure Front Door и Шлюз приложений | Мультитенантная saaS в Azure | Используйте мультитенантное решение, включающее сочетание Azure Front Door и Шлюз приложений. Azure Front Door помогает сбалансировать трафик между регионами. Шлюз приложений маршрутизирует и балансирует трафик внутри приложения в различных службах, удовлетворяющих потребностям клиента. |
| Диспетчер трафика + Load Balancer | Многорегионное N-уровневое приложение | Многорегионное N-уровневое приложение, использующее Диспетчер трафика для маршрутизации входящих запросов в основной регион. Если этот регион становится недоступным, диспетчер трафика выполняет отработку отказа в дополнительный регион. |
| Диспетчер трафика + Шлюз приложений | Балансировка нагрузки с несколькими агрегатами с помощью Диспетчер трафика и Шлюз приложений | Узнайте, как обслуживать веб-рабочие нагрузки и развертывать устойчивые многоуровневые приложения в нескольких регионах Azure для обеспечения высокой доступности и надежной инфраструктуры аварийного восстановления. |