Балансировка нагрузки в нескольких регионах с помощью Диспетчера трафика и Шлюза приложений

Шлюз приложений
Бастион
Load Balancer
Диспетчер трафика

Эта эталонная архитектура служит веб-рабочим нагрузкам с устойчивыми многоуровневыми приложениями и развертывается в нескольких регионах Azure для обеспечения высокой доступности и надежного аварийного восстановления.

Диспетчер трафика Microsoft Azure распределяет трафик между регионами и на основе Шлюз приложений Azure существует региональная подсистема балансировки нагрузки. Благодаря этому сочетанию вы получите преимущества гибкой маршрутизации диспетчера трафика и множество возможностей Шлюз приложений, в том числе:

  • Брандмауэр веб-приложений (WAF).
  • Завершение протокола TLS.
  • Маршрутизация на основе пути.
  • Сходство сеансов на основе файлов cookie.

В этом сценарии приложение состоит из трех уровней:

  • Веб-уровень: Это верхний слой и имеет пользовательский интерфейс. Он анализирует взаимодействие с пользователем и передает действия на бизнес-уровень для обработки.
  • Бизнес-уровень: Обрабатывает взаимодействие с пользователем и определяет дальнейшие действия. Он подключает веб-уровни и уровни данных.
  • Уровень данных: Хранит данные приложения, как правило, в базе данных, хранилище объектов или файлы.

Схема балансировки нагрузки в нескольких регионах с помощью Шлюз приложений и диспетчера трафика.

Скачайте файл Visio этой архитектуры.

Примечание

Azure предоставляет набор полностью управляемых решений балансировки нагрузки. Если вы ищете завершение протокола TLS (разгрузка SSL) или запрос HTTP/HTTPS, обработку на уровне приложений, проверьте, что такое Шлюз приложений Azure?. Если вы ищете региональную балансировку нагрузки, просмотрите Azure Load Balancer. В комплексных сценариях может быть целесообразно объединить эти решения.

Сравнение параметров балансировки нагрузки Azure см. в обзоре параметров балансировки нагрузки в Azure.

Архитектура

Диспетчер трафика работает на уровне DNS для направления трафика приложения в соответствии с выбранным способом маршрутизации. Например, вы можете направить запросы, отправляемые в ближайшие конечные точки, чтобы повысить скорость реагирования. Шлюз приложений балансировку нагрузки http(S) и запросов WebSocket по мере их маршрутизации на серверы серверного пула. Серверная часть может быть общедоступными или частными конечными точками, виртуальными машинами, Масштабируемые наборы виртуальных машин Azure, службами приложений или кластерами AKS. Трафик можно маршрутизировать на основе атрибутов HTTP-запроса, таких как имя узла и путь URI.

Компоненты

  • Виртуальные машины Azure. Виртуальные машины — это масштабируемые вычислительные ресурсы, которые предоставляются по запросу и обеспечивают гибкость виртуализации, но устраняют потребность в обслуживании физического оборудования. Операционной системой может быть Windows или Linux. Виртуальные машины — это масштабируемый ресурс, предоставляемый по запросу.
  • Масштабируемые наборы виртуальных машин Azure — это автоматизированное масштабирование виртуальной машины с балансировкой нагрузки, которое упрощает управление приложениями и повышает доступность.
  • Диспетчер трафика — это подсистема балансировки нагрузки трафика на основе DNS, которая оптимально распределяет трафик между службами в глобальных регионах Azure, обеспечивая высокую доступность и скорость реагирования. Дополнительные сведения см. в разделе Конфигурация диспетчера трафика.
  • Шлюз приложений — это подсистема балансировки нагрузки уровня 7. В этой архитектуре избыточный между зонами Шлюз приложений направляет HTTP-запросы в веб-интерфейс. Шлюз приложений также предоставляет Брандмауэр веб-приложений (WAF), которая защищает приложение от распространенных эксплойтов и уязвимостей. Номер SKU версии 2 Шлюз приложений поддерживает избыточность между зонами. Одно развертывание Шлюз приложений может запускать несколько экземпляров шлюза.
  • Azure Load Balancer — это подсистема балансировки нагрузки четвертого уровня. Существует два номера SKU: "Стандартный" и "Базовый". В этой архитектуре избыточный между зонами Load Balancer (цен. категория направляет сетевой трафик с веб-уровня на бизнес-уровень. Так как избыточные между зонами Load Balancer не закреплены в определенной зоне, приложение будет продолжать распространять сетевой трафик в случае сбоя зоны.
  • Защита от атак DDoS Azure предоставляет расширенные функции для защиты от распределенных атак типа "отказ в обслуживании" (DDoS), функций, которые выходят за рамки базовой защиты, которую предоставляет Azure.
  • Azure DNS — это служба размещения для доменов DNS. Она осуществляет разрешение имен на базе инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure. Azure DNS также поддерживает частные зоны DNS. Частные зоны Azure DNS обеспечивают разрешение имен в виртуальной сети, а также между виртуальными сетями. Записи, содержащиеся в частной зоне DNS, невозможно разрешить из Интернета. Разрешение DNS для частной зоны DNS работает только из виртуальных сетей, связанных с ней.
  • Виртуальная сеть Azure — это защищенная частная сеть в облаке. Она позволяет виртуальным машинам подключаться друг к другу, к Интернету и к локальным сетям.
  • Бастион Azure обеспечивает безопасный и простой доступ к виртуальным машинам в виртуальной сети по протоколу удаленного рабочего стола (RDP) и Secure Shell (SSH). Это обеспечивает доступ при ограничении общедоступных IP-адресов виртуальных машин в виртуальной сети. Бастион Azure предоставляет экономически эффективную альтернативу подготовленной виртуальной машине для предоставления доступа ко всем виртуальным машинам в одной виртуальной сети.

Рекомендации

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

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

Вопросы доступности

Зоны доступности Azure

Azure Зоны доступности обеспечить высокий уровень доступности в пределах региона. Региональная сеть соединяет по крайней мере три физически отдельных стратегически размещенных центра обработки данных в каждом регионе.

Различные регионы

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

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

Технические сведения см. в разделе "Регионы" и Зоны доступности в Azure.

Пары регионов

Каждый регион Azure связан с другим регионом в одном географическом регионе (например, США, Европе или Азии). Такой подход позволяет выполнять репликацию ресурсов, таких как хранилище виртуальных машин, в разных регионах. Идея заключается в том, чтобы один регион был доступен, даже если другой становится недоступным из-за стихийных бедствий, гражданских беспорядков, потери электроэнергии, отключения сети и т. д.

Существуют и другие преимущества регионального связывания, в том числе:

  • В случае более масштабного сбоя в работе Azure в каждой паре определяется приоритетный регион, чтобы ускорить восстановление приложений.
  • Запланированные обновления Azure распространяются среди парных регионов последовательно, чтобы свести к минимуму время простоя и риск сбоев в работе приложений.
  • Данные будут по-прежнему находиться в одной географической области со своей парой (за исключением южной Бразилии). Это связано с требованиями к налогообложению и юрисдикции применения законодательства.

Убедитесь, что оба региона поддерживают все службы Azure, необходимые приложению (см. службы по регионам). Дополнительные сведения о парах регионов см. в статье Непрерывность бизнес-процессов и аварийное восстановление в службах BizTalk: в парах регионов Azure.

Конфигурация диспетчера трафика

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

При настройке диспетчера трафика необходимо учитывать следующее:

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

    Сведения о конфигурации см. в разделе "Настройка метода маршрутизации трафика производительности".

    Сведения о различных методах маршрутизации см. в разделе "Методы маршрутизации диспетчера трафика".

  • Проба работоспособности: Диспетчер трафика использует пробу HTTP (или HTTPS) для мониторинга доступности каждого региона. При этом проверяется код ответа HTTP 200 в заданном пути URL-адреса. Рекомендуется создать конечную точку, которая сообщает о работоспособности приложения, и использовать ее для проверки работоспособности. В противном случае проба может сообщить о работоспособной конечной точке при сбое критически важных частей приложения. Дополнительные сведения см. в разделе "Мониторинг конечных точек работоспособности".

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

    • При проверке работоспособности определяется, что с основным регионом невозможно связаться.
    • DNS-серверы должны обновить кэшированные записи DNS для IP-адресов, которые зависят от срока существования DNS. Срок существования по умолчанию — 300 секунд (5 минут), однако это значение можно настроить при создании профиля диспетчера трафика.

    Дополнительные сведения см. в разделе "Мониторинг диспетчера трафика".

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

Шлюз приложений

  • Шлюз приложений номер SKU версии 1 поддерживает сценарии высокой доступности при развертывании двух или более экземпляров. Azure распределяет эти экземпляры по доменам сбоя и обновления, чтобы избежать одновременного сбоя всех экземпляров. Номер SKU версии 1 поддерживает масштабируемость путем добавления нескольких экземпляров одного шлюза для распределения нагрузки.
  • Шлюз приложений номер SKU версии 2 автоматически гарантирует, что новые экземпляры распределяются между доменами сбоя и доменами обновления. При выборе избыточности между зонами новейшие экземпляры также распределяются по зонам доступности, чтобы обеспечить устойчивость к сбоям зоны.

Пробы работоспособности

Шлюз приложений и Load Balancer используют пробы работоспособности для мониторинга доступности экземпляров виртуальных машин.

  • Шлюз приложений всегда использует пробу HTTP.
  • Load Balancer может протестировать ПРОТОКОЛ HTTP или TCP. Как правило, если виртуальная машина запускает HTTP-сервер, используйте пробу HTTP. В противном случае используйте TCP.

Если проба не может достичь экземпляра в течение периода ожидания, Шлюз приложений или Load Balancer перестает отправлять трафик на виртуальную машину. Проверка продолжает проверяться и возвращает виртуальную машину во внутренний пул, если виртуальная машина снова станет доступной. Пробы HTTP отправляют HTTP-запрос GET по указанному пути и прослушивают ответ HTTP 200. Это может быть корневой путь ("/"), или конечная точка мониторинга работоспособности, реализующая пользовательскую логику для проверки работоспособности приложения. Конечная точка должна разрешать анонимные HTTP-запросы.

Дополнительные сведения о пробах работоспособности см. в следующем разделе:

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

Вопросы управляемости

  • Группы ресурсов: Используйте группы ресурсов для управления ресурсами Azure по времени существования, владельцу и другим характеристикам.
  • Пиринг между виртуальными сетями: Используйте пиринг между виртуальными сетями для простого подключения двух или более виртуальных сетей в Azure. После создания пиринговой связи две виртуальные сети выглядят как одна сеть в плане подключения. Точно так же трафик между виртуальными машинами в одноранговых виртуальных сетях использует магистральную инфраструктуру Майкрософт. Убедитесь, что адресное пространство виртуальных сетей не перекрывается. В этом сценарии виртуальные сети пиринговые через пиринг глобальной виртуальной сети позволяют выполнять репликацию данных из основного региона в дополнительный регион.
  • Виртуальная сеть и подсети: Виртуальная машина Azure и определенные ресурсы Azure (например, Шлюз приложений и Load Balancer) развертываются в виртуальной сети, которая может быть сегментирована в подсети. Создайте отдельные подсети для каждого уровня.

Замечания по безопасности

группы сетевой безопасности;

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

  1. Запретите весь входящий трафик от виртуальной сети. (Используйте тег VIRTUAL_NETWORK в правиле.)
  2. Разрешите входящий трафик из подсети уровня бизнеса.
  3. Разрешите входящий трафик из самой подсети уровня базы данных. Это правило обеспечивает взаимодействие между виртуальными машинами баз данных, которое необходимо для репликации и отработки отказа базы данных.

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

Теги служб можно использовать для определения элементов управления доступом к сети в группах безопасности сети или Брандмауэр Azure. Дополнительные сведения о требованиях Шлюз приложений NSG см. в разделе Шлюз приложений конфигурации инфраструктуры.

Цены

Используйте калькулятор цен Azure для оценки затрат. Ниже приведены некоторые другие аспекты.

Масштабируемые наборы виртуальных машин

Масштабируемые наборы виртуальных машин доступны во всех размерах виртуальных машин Windows. Плата взимается только за развернутые виртуальные машины Azure и все дополнительные базовые ресурсы инфраструктуры, такие как хранилище и сеть. Для службы Масштабируемые наборы виртуальных машин не взимается добавочная плата.

Сведения о ценах на одну виртуальную машину см. в разделе "Цены на Windows Виртуальные машины".

Load Balancer (цен. категория "Стандартный")

Цены на Load Balancer (цен. категория ежечасно основаны на количестве настроенных правил балансировки нагрузки для исходящего трафика. За правила преобразования сетевых адресов (NAT) плата не взимается. Плата за номер SKU "Стандартный" не взимается, Load Balancer если правила не настроены. Кроме того, взимается плата за объем данных, которые Load Balancer обрабатывает.

Дополнительные сведения см. в разделе о ценах на балансировку нагрузки.

номер SKU Шлюз приложений версии 2

Шлюз приложений должна быть подготовлена с помощью SKU версии 2 и может охватывать несколько Зоны доступности. С номером SKU версии 2 модель ценообразования определяется потреблением и имеет два компонента: почасовая фиксированная цена и затраты на основе потребления.

Дополнительные сведения см. в Шлюз приложений ценах.

Диспетчер трафика

Выставление счетов диспетчера трафика основано на количестве полученных ЗАПРОСОВ DNS со скидкой для служб, получающих более 1 млрд ежемесячных запросов. Кроме того, взимается плата за каждую отслеживаемую конечную точку. Сведения о ценах см. в разделе о ценах диспетчера трафика.

Пиринг между виртуальными сетями

Развертывание с высоким уровнем доступности, использующее несколько регионов Azure, использует пиринг между виртуальными сетями. Плата за пиринг между виртуальными сетями в одном регионе не совпадает с расходами на пиринг глобальной виртуальной сети.

Дополнительные сведения см. в разделе виртуальная сеть цены.

Дальнейшие действия

Дополнительные эталонные архитектуры, использующие те же технологии, см. в следующих статье: