Балансировка нагрузки для нескольких регионов

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

Эта архитектура предназначена для глобальных, интернет-приложений, использующих протоколы HTTP(S) и не HTTP(S). Она включает глобальную балансировку нагрузки на основе DNS, две формы региональной балансировки нагрузки и пиринг глобальной виртуальной сети для создания надежной архитектуры. Зоны доступности обеспечивают устойчивость в каждом регионе, а развертывание с несколькими регионами обеспечивает возможность восстановления после регионального сбоя. Брандмауэр веб-приложений Azure и брандмауэр Azure проверяют трафик на нескольких уровнях.

Architecture

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

Потоки входящего HTTP(S)-трафика

Трафик HTTP(S) проходит через брандмауэр веб-приложения для фильтрации шлюза приложений Azure (WAF) и инспекцию Transport Layer Security (TLS) брандмауэра Брандмауэр Azure Premium, прежде чем он достигнет уровни приложений.

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

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

  1. Диспетчер трафика Azure использует маршрутизацию на основе DNS для балансировки входящего трафика между двумя регионами. Диспетчер трафика разрешает DNS-запросы приложения к общедоступным IP-адресам конечных точек шлюза приложений. Общедоступные конечные точки экземпляров шлюза приложений функционируют как задние конечные точки Traffic Manager для управления трафиком HTTP(S). Диспетчер трафика разрешает запросы DNS на основе выбранного метода маршрутизации. Браузер или другой HTTP-клиент подключается непосредственно к конечной точке. Дополнительные сведения см. в разделе "Метод маршрутизации трафика приоритета".

  2. Экземпляры шлюза приложений, развернутые в зонах доступности, получают трафик HTTP(S) из браузера, а WAF проверяет трафик для обнаружения веб-атак. Экземпляры Шлюза приложений перенаправляют трафик во внутренний балансировщик нагрузки, который распределяет его на фронтальные виртуальные машины. В этом потоке шлюз приложений работает в качестве подсистемы балансировки нагрузки, поэтому дополнительная внутренняя подсистема балансировки нагрузки перед веб-серверами не требуется. Но внутренняя подсистема балансировки нагрузки включена в структуру обеспечения согласованности с потоком для приложений, отличных от HTTP(S).

  3. Определяемые пользователем маршруты в подсети Application Gateway перенаправляют трафик между шлюзом приложений и внутренней подсистемой балансировки нагрузки через Брандмауэр Azure Premium. Брандмауэр Azure Premium имеет зональную избыточность и применяет проверку TLS к трафику для усиленной безопасности. Если брандмауэр Azure обнаруживает угрозу, он удаляет пакеты. Если брандмауэр Azure не обнаруживает угрозу, он перенаправит трафик во внутреннюю подсистему балансировки нагрузки целевого веб-уровня.

  4. Веб-уровень является первым слоем трехуровневого приложения. Он содержит пользовательский интерфейс и анализирует взаимодействие с пользователем. Подсистема балансировки нагрузки веб-уровня охватывает все три зоны доступности и распределяет трафик между тремя виртуальными машинами веб-уровня.

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

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

  7. Виртуальные машины уровня бизнеса охватывают зоны доступности и маршрутизируют трафик к слушателю группы доступности баз данных.

  8. Уровень данных хранит данные приложения, как правило, в базе данных, хранилище объектов или общей папке. Эта архитектура содержит SQL Server на виртуальных машинах Azure, распределенных по трем зонам доступности. Они используют группу доступности AlwaysOn с каждой виртуальной машиной SQL Server в отдельной подсети. Развертывание с несколькими подсетями позволяет прослушивателю группы доступности направлять трафик непосредственно на реплики и не требует балансировщика нагрузки Azure или распределенного сетевого имени (DNN).

Входящие потоки трафика, отличные от HTTP(S)

Некоторые рабочие нагрузки принимают трафик по протоколам, отличным от HTTP(S), например, протокола SFTP для приема данных на основе файлов от деловых партнеров или интеграций на основе устаревшего протокола управления передачей данных (TCP). Трафик, отличный от HTTP(S), направляется непосредственно в брандмауэр Azure для преобразования адресов целевой сети (DNAT) и проверки, обходя шлюз приложений.

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

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

  1. Диспетчер трафика использует маршрутизацию на основе DNS для балансировки входящего трафика в двух регионах. Диспетчер трафика разрешает DNS-запросы приложения к общедоступным IP-адресам конечных точек Azure. Общедоступные конечные точки брандмауэра Azure работают в качестве внутренних конечных точек диспетчера трафика для трафика, отличного от HTTP(S). Диспетчер трафика разрешает запросы DNS на основе выбранного метода маршрутизации. Клиент подключается непосредственно к разрешенной конечной точке. Дополнительные сведения см. в разделе "Метод маршрутизации трафика приоритета".

  2. Брандмауэр Azure Premium с обеспечением избыточности по зонам проверяет входящий трафик для гарантии безопасности. Если брандмауэр Azure обнаруживает угрозу, он удаляет пакеты. После успешной проверки брандмауэр Azure применяет DNAT к входящим пакетам и перенаправит трафик во внутреннюю подсистему балансировки нагрузки веб-уровня.

  3. Веб-уровень является первым слоем трехуровневого приложения. Он содержит пользовательский интерфейс и анализирует взаимодействие с пользователем. Подсистема балансировки нагрузки веб-уровня охватывает все три зоны доступности и распределяет трафик на каждую из трех виртуальных машин веб-уровня.

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

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

  6. Виртуальные машины уровня бизнеса охватывают зоны доступности и маршрутизируют трафик к слушателю группы доступности баз данных.

  7. Уровень данных хранит данные приложения, как правило, в базе данных, хранилище объектов или общей папке. Эта архитектура содержит SQL Server на виртуальных машинах, распределенных между тремя зонами доступности. Они используют группу доступности AlwaysOn с каждой виртуальной машиной SQL Server в отдельной подсети. Развертывание с несколькими подсетями позволяет прослушивателю группы доступности направлять трафик непосредственно на реплики и не требует балансировщика нагрузки Azure или DNN.

Исходящие потоки трафика (все протоколы)

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

Утвержденные потоки оставляют исходный сетевой адрес брандмауэра преобразованным (SNAT) на один из его общедоступных IP-адресов, который Брандмауэр Azure выбирает случайным образом на поток. Количество подключенных общедоступных IP-адресов ограничивает бюджет использования портов SNAT и определяет идентификацию исходящего трафика, которую необходимо включить в белый список партнерам на нижнем уровне; используйте префикс общедоступного IP-адреса, чтобы выразить этот набор как непрерывный диапазон.

Components

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

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

  • Диспетчер трафика — это глобальная подсистема балансировки нагрузки на основе DNS, которая распределяет трафик между службами в глобальных регионах Azure и обеспечивает высокую доступность и скорость реагирования. В этой архитектуре диспетчер трафика обеспечивает глобальную балансировку нагрузки и разрешает DNS-запросы для направления трафика в региональные конечные точки приложения. Он отслеживает работоспособность конечных точек и перенаправляет ответы DNS из неработоспособных регионов.

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

  • Защита от атак DDoS Azure — это служба, которая помогает защитить от распределенных атак типа "отказ в обслуживании" (DDoS). В этой архитектуре защита от атак DDoS обеспечивает защиту общедоступных IP-адресов и помогает обеспечить доступность во время сценариев атаки.

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

  • Частные зоны DNS Azure — это функция Azure DNS. Частные зоны DNS Azure предоставляют разрешение имен в виртуальной сети и между виртуальными сетями. В этой архитектуре частные зоны DNS Azure предоставляют внутреннее разрешение имен для ресурсов в инфраструктуре виртуальной сети.

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

  • Масштабируемые наборы виртуальных машин Azure с гибкой оркестрацией — это служба, которую можно использовать для создания и управления группой виртуальных машин с балансировкой нагрузки, которая может автоматически масштабироваться по требованию. В этой архитектуре масштабируемые наборы виртуальных машин размещают виртуальные машины веб-и бизнес-уровня между зонами доступности в каждом регионе. Уровень данных использует автономные виртуальные машины SQL Server, как описано ниже.

  • SQL Server на виртуальных машинах — это служба, которая предоставляет полные версии SQL Server в облаке, чтобы вам не приходилось управлять локальным оборудованием. В этой архитектуре SQL Server на автономных виртуальных машинах формирует уровень данных с группами доступности AlwaysOn, распределенными между зонами доступности в конфигурации с несколькими подсетями.

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

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

Альтернативы

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

Глобальная подсистема балансировки нагрузки

Текущий подход: Диспетчер трафика обеспечивает глобальную балансировку нагрузки на основе DNS, которая поддерживает протоколы HTTP(S) и не HTTP(S). Эта архитектура использует диспетчер трафика, так как он должен направлять потоки, отличные от HTTP(SFTP) и устаревших интеграции TCP, через брандмауэр Azure для проверки на уровне сети. Диспетчер трафика основан на DNS, поэтому клиенты подключаются непосредственно к конечным точкам серверной части, что требует, чтобы шлюз приложений и брандмауэр Azure имели общедоступные IP-адреса.

Альтернативный подход: Используйте Azure Front Door вместо диспетчера трафика. Azure Front Door — это глобальный балансировщик нагрузки уровня 7 для трафика HTTP(S), который обеспечивает кэширование, ускорение трафика, завершение TLS, управление сертификатами и встроенный WAF. Azure Front Door — это обратный прокси-сервер, поэтому он может подключаться к шлюзу приложений через Приватный канал Azure, что устраняет необходимость общедоступных IP-адресов в серверной инфраструктуре. Это решение, предпочтительно используемое для глобальной маршрутизации рабочих нагрузок HTTP(S).

Рассмотрите Azure Front Door, если рабочая нагрузка соответствует следующим условиям:

  • Весь входящий трафик использует протоколы HTTP(S).

  • Для глубокой проверки входящего трафика брандмауэр Azure не требуется.

  • Вы хотите иметь интегрированные возможности WAF и сети доставки содержимого на глобальной периферии.

Вычислительные платформы

Текущий подход: Уровни веб-, бизнеса и данных выполняются на масштабируемых наборах виртуальных машин с SQL Server на виртуальных машинах. Эта инфраструктура как услуга (IaaS) обеспечивает полный контроль над конфигурацией операционной системы (ОС), ПО промежуточного слоя и ядра СУБД.

Альтернативный подход: Замените определенные уровни ресурсами платформы как службы (PaaS), такими как служба приложений Azure для веб-уровня или базы данных SQL Azure для уровня данных. Общая сетевая архитектура значительно не изменяется, если вы используете интеграцию приватного канала и виртуальной сети службы приложений для интеграции этих служб PaaS в виртуальную сеть.

Рассмотрите варианты PaaS, если рабочая нагрузка соответствует следующим условиям:

  • Вам не нужен непосредственный контроль над конфигурацией ОС или промежуточного слоя.

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

  • Рабочая нагрузка базы данных совместима с набором компонентов и ограничениями базы данных SQL.

Сочетание сервиса балансировки нагрузки

Текущий подход: Эта архитектура использует диспетчер трафика для глобальной маршрутизации на основе DNS. В каждом регионе шлюз приложений выполняет обработку уровня 7 и проверку WAF, а Load Balancer управляет распределением уровня 4.

Альтернативный подход: Для протокола, задержки и безопасности рабочей нагрузки может потребоваться другое сочетание служб балансировки нагрузки. Например, рабочие нагрузки, которые не нуждаются в WAF, могут использовать Load Balancer только для регионального распределения. Рабочие нагрузки, требующие маршрутизации на основе путей без брандмауэра, могут использовать шлюз приложений без брандмауэра Azure перед ним.

Сведения о том, какие службы соответствуют вашему сценарию, см. в разделе "Параметры балансировки нагрузки" в Azure.

Топология сети

Текущий подход: Эта архитектура использует структуру неструктурированных виртуальных сетей со всеми компонентами в одной виртуальной сети для каждого региона.

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

Подробности сценария

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

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

  • Региональная балансировка нагрузки и WAF: Шлюз приложений предоставляет возможности уровня 7 в каждом регионе, включая WAF, прерывание TLS, маршрутизацию на основе пути и привязку сеансов на основе файлов cookie.

  • Безопасность сети и глубокая проверка пакетов: Эта архитектура помещает шлюз приложений перед брандмауэром Azure для двойного проверки веб-содержимого. Альтернативные топологии описаны в брандмауэре Azure и шлюзе приложений для виртуальных сетей. Эта топология сохраняет исходный IP-адрес клиента в заголовке HTTP X-Forwarded-For , обеспечивает сквозное шифрование и запрещает клиентам обходить WAF.

    Брандмауэр Azure Premium проверяет три типа потоков:

    • Входящие потоки HTTP(S) из шлюза приложений, защищенные проверкой TLS.

    • Входящие потоки, не HTTP(S) из открытого Интернета, проверяются с полным набором функций премиального уровня. Шлюз приложений также поддерживает прокси-сервер уровня 4 (TCP/TLS), который объединяет входящий трафик HTTP и не HTTP на одну точку входа. Эта возможность доступна в предварительной версии, и WAF не применяется к трафику уровня 4, поэтому эта архитектура использует отдельный путь для потоков, отличных от HTTP(S).

    • Исходящий трафик из виртуальных машин для предотвращения утечки данных и доступа к запрещённым ресурсам.

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

  • Подключение между регионами: Пиринг глобальной виртуальной сети обеспечивает низкую задержку, репликацию данных с высокой пропускной способностью между регионами по магистрали Майкрософт. В топологии «звезда–штифт» пиринги существуют между концентраторами и периферийными сетями в каждом регионе и между концентраторами в разных регионах.

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

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

Reliability

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

  • Мультирегиональное развертывание: Развертывание минимум в двух регионах Azure для восстановления. Конфигурация многорегионирования "активный — пассивный" или "активный — активный" помогает рабочей нагрузке восстановиться после регионального сбоя. Диспетчер трафика отслеживает работоспособность конечных точек и перенаправляет ответы DNS из неработоспособных регионов, но необходимо убедиться, что дополнительный регион готов обслуживать трафик, включая репликацию данных и готовность приложений.

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

    • Реплики группы доступности SQL Server Always On в дополнительном регионе используют асинхронную фиксацию изменений с ручным переключением. Так как режим фиксации является асинхронным, вторичный регион может не получать некоторых зафиксированных транзакций во время регионального сбоя, поэтому планируйте возможную потерю данных. Определите вашу целевую точку восстановления (RPO) и проверьте, остается ли задержка репликации в пределах этой цели при объемах записи вашей рабочей нагрузки. Переключение на резервный регион — это ручная операция, требующая оператора или руководства по действиям (runbook) для повышения асинхронной реплики.

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

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

Глобальная маршрутизация

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

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

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

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

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

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

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

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

Брандмауэр Azure

Для этого требуется, чтобы брандмауэр Azure Premium предоставлял проверку TLS. Брандмауэр Azure перехватывает сеансы TLS между шлюзом приложений и виртуальными машинами веб-уровня, создает собственные сертификаты и проверяет исходящие потоки трафика из виртуальных сетей в общедоступный Интернет. Дополнительные сведения см. в разделе "Сеть нулевого доверия" для веб-приложений, использующих брандмауэр Azure и шлюз приложений Azure.

Отслеживайте даты окончания срока действия сертификатов промежуточного центра сертификации ( ЦС), которые брандмауэр Azure использует для проверки TLS. Истекший сертификат прерывает рукопожатие TLS, не позволяя трафику достичь серверов бэкенда, даже если все компоненты инфраструктуры остаются работоспособными. Дополнительные сведения см. в разделе "Цепочка доверия сертификатов TLS".

Рекомендации по пробе работоспособности

Рассмотрим следующие рекомендации по пробам работоспособности в диспетчере трафика, шлюзе приложений и Load Balancer.

Traffic Manager

  • Состояние конечной точки: Создайте конечную точку, которая сообщает об общем состоянии приложения. Диспетчер трафика использует пробу HTTP(S) для мониторинга доступности каждого региона. Проба проверяет ответ HTTP 200 (ОК) для указанного URL-пути. Используйте конечную точку, созданную для пробы работоспособности, так как другие конечные точки могут привести к тому, что проверка сообщит о нормальном состоянии, даже если критически важные части приложения выйдут из строя. Дополнительные сведения см. в шаблон мониторинга конечных точек работоспособности.

  • Задержка отработки отказа: Диспетчер трафика имеет задержку отработки отказа. Следующие факторы определяют длительность задержки:

    • Интервалы проверки: Как часто проба проверяет работоспособность конечной точки.

    • Допустимое количество сбоев: Сколько сбоев пробы допускается до того, как она помечает неработоспособную конечную точку.

    • Время ожидания пробы: Как долго диспетчер трафика рассматривает конечную точку как неработоспособную.

    • Время жизни (TTL): DNS-серверы должны обновить кэшированные DNS-записи, связанные с IP-адресом. Время, которое требуется, зависит от TTL DNS. Значение по умолчанию — 300 секунд (5 минут), но это значение можно задать при создании профиля диспетчера трафика. Для получения дополнительной информации см. мониторинг Диспетчера трафика.

Шлюз приложений и балансировщик нагрузки

Ознакомьтесь с политиками проб работоспособности шлюза приложений и Load Balancer, чтобы убедиться, что вы понимаете работоспособность виртуальных машин:

  • Шлюз приложений всегда использует пробу HTTP.

  • Load Balancer может оценивать HTTP или TCP. Используйте проверку HTTP, если виртуальная машина запускает HTTP-сервер. Используйте TCP для всех других вариантов.

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

Безопасность

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

Эта архитектура предполагает отсутствие неявного доверия между компонентами. Несколько слоев проверяют и авторизуют трафик. WAF шлюза приложений фильтрует угрозы уровня HTTP. Брандмауэр Azure Premium проверяет все потоки трафика на глубоком уровне пакетов. Группы безопасности сети (NSG) обеспечивают сегментацию наименьших привилегий между уровнями. Данные защищены шифрованием TLS в процессе передачи на каждом сетевом узле. Ни один слой не блокирует каждую угрозу.

  • WAF: Функция WAF шлюза приложений обнаруживает и предотвращает атаки на уровне HTTP, например внедрение SQL (SQLi) или межсайтовые скрипты (XSS).

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

  • Сквозное шифрование: Трафик всегда шифруется при обходе сети Azure. Шлюз приложений и брандмауэр Azure шифруют трафик перед отправкой в соответствующую серверную систему.

  • Цепочка доверия сертификатов TLS: Брандмауэр Azure Premium работает как прокси-сервер пересылки и динамически создает сертификаты, подписанные частным ЦС во время проверки TLS. Настройте шлюз приложений, чтобы доверять корневому сертификату ЦС, который использует брандмауэр Azure, чтобы обмен TLS между ними был успешным.

    Для рабочих развертываний используйте инфраструктуру открытых ключей предприятия (PKI) для создания промежуточного сертификата ЦС. Дополнительные сведения см. в статье "Развертывание и настройка корпоративных сертификатов ЦС" для брандмауэра Azure исведений о цепочке сертификатов для этой архитектуры.

  • Ddos: Используйте защиту сети DDoS Azure для повышения защиты от атак DDoS , чем базовая защита, которую предоставляет Azure.

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

    1. Разрешить входящий трафик из подсети бизнес-уровня.

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

    3. Запретите весь входящий трафик из виртуальной сети, используя тег VirtualNetwork в правиле для замещения разрешающей инструкции в правилах NSG по умолчанию.

    Создайте правило 3 с более низким приоритетом (более высоким числом), чем первые правила.

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

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

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

  • ВМ: Виртуальные машины являются основным драйвером затрат, так как каждый уровень в обоих регионах работает непрерывно. Используйте зарезервированные экземпляры виртуальных машин Azure или планы экономии Azure для вычислений. Зарезервированные экземпляры хорошо подходят для минимальной постоянной емкости, а планы экономии затрат обеспечивают гибкость в случае изменения размеров виртуальных машин с течением времени.

  • Брандмауэр Azure Premium: Брандмауэр Azure Premium имеет фиксированную почасовую плату за единицу развертывания и переменные сборы за обработку данных за гигабайт (ГБ), а также выполняется в обоих регионах. Если для рабочей нагрузки не требуется система обнаружения и предотвращения вторжений (IDPS) или проверка TLS, определите, соответствует ли стандарт брандмауэра Azure требованиям безопасности по более низкой цене.

  • Защита сети DDoS и скидка WAF:Защита сети DDoS имеет фиксированную ежемесячную стоимость, которая охватывает до 100 общедоступных IP-адресов в подписках в клиенте.

    Когда вы включаете защиту сети DDoS, Azure выставляет счета за экземпляры WAF шлюза приложений Azure по более низкому стандартному тарифу вместо по тарифу WAF. Для архитектур с множеством экземпляров шлюза приложений, скидка на WAF может компенсировать значительную часть затрат на план защиты от DDoS.

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

Сведения о ценах для конкретной службы см. в следующих ресурсах:

Операционная эффективность

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

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

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

  • Мониторинга: Разверните рабочую область Log Analytics в каждом регионе, чтобы мониторинг оставался функциональным даже во время регионального сбоя.

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

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

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

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

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

    Гибкая оркестрация поддерживает автоматический патчинг гостевой ОС для критических и защитных обновлений, но не поддерживает автоматическое обновление образа ОС. Используйте Диспетчер обновлений Azure или конвейер развертывания для обработки обновлений образа ОС.

    Это текущее рабочее бремя является основным компромиссом для контроля и гибкости, которую предоставляет IaaS. Если ваша команда не нуждается в этом уровне управления, рассмотрите альтернативные варианты PaaS.

Эффективность работы

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки проектного решения на эффективность производительности .

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

  • Задержка двойной проверки: Поток HTTP(S) в данной архитектуре передает трафик как через WAF шлюза приложений, так и функцию проверки TLS в Брандмауэр Azure Premium. Эта многоуровневая защита добавляет задержку к каждому запросу. Проверьте производительность приложения под реалистичной нагрузкой, чтобы убедиться, что дополнительное время проверки соответствует вашим требованиям к времени отклика.

  • Пропускная способность брандмауэра Azure: IDS/IPS в режиме оповещения и блокировки значительно снижает максимальную пропускную способность брандмауэра Azure по сравнению с другими режимами. Если для вашей рабочей нагрузки требуется IDPS в режиме отказа и высокая пропускная способность, планируйте емкость соответственно и отслеживайте метрики пропускной способности брандмауэра. Дополнительные сведения см. в разделе производительность Брандмауэр Azure.

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

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