Поделиться через


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

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

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

Заметки об архитектуре

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

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

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

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

Потоки трафика входящего ТРАФИКА HTTP(S)

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

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

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

  2. Шлюз приложений, развернутые в зонах доступности, получают трафик HTTP(S) из браузера, а Брандмауэр веб-приложений s Premium проверяют трафик для обнаружения веб-атак. Шлюзы приложений будут отправлять трафик в серверную часть, внутреннюю подсистему балансировки нагрузки для внешних виртуальных машин (виртуальных машин). Для этого конкретного потока внутренняя подсистема балансировки нагрузки перед веб-серверами не требуется строго, так как Шлюз приложений может выполнять эту балансировку нагрузки. Однако он включается для обеспечения согласованности с потоком для приложений, отличных от HTTP(S).

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

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

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

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

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

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

Потоки трафика, отличные от HTTP(S)

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

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

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

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

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

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

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

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

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

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

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

Компоненты

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание решения

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

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

Шлюз приложений - Хотя Диспетчер трафика обеспечивает балансировку нагрузки на основе DNS, Шлюз приложений предоставляет множество таких же возможностей, как Azure Front Door, но на региональном уровне, например:

  • Фаервол веб-приложений (WAF)
  • Конечная точка для связи по протоколу TLS
  • Маршрутизация на основе пути
  • сходство сеансов на основе файлов cookie;

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

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

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

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

Следующие рекомендации соответствуют основам Azure Well-Architected Framework (WAF). Основные принципы WAF помогают обеспечить качество облачных рабочих нагрузок. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Соображения

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

Надежность

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

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

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

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

  • Технические требования, включая географическое расстояние и задержку между регионами
  • Требования к месту расположения данных
  • Рекомендации по регулированию
  • Поддержка зоны доступности
  • Доступность служб в каждом регионе
  • Себестоимость

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

Дополнительные сведения о выборе регионов Azure см. в разделе "Выбор регионов Azure" в Cloud Adoption Framework.

Зоны доступности. Используйте несколько зон доступности для поддержки Шлюз приложений, Брандмауэр Azure, Azure Load Balancer и уровней приложений при наличии.

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

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

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

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

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

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

Глобальное представление трафика

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

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

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

Используйте номер SKU Шлюз приложений версии 2 для автоматической устойчивости.

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

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

Шлюз приложений должен доверять сертификату ЦС Брандмауэр Azure.

Брандмауэр Azure

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

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

Ниже приведены некоторые рекомендации по пробам работоспособности в Диспетчер трафика, Шлюз приложений и Load Balancer.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Брандмауэр веб-приложений - Функции WAF Шлюз приложений Azure будут обнаруживать и предотвращать атаки на уровне HTTP, например внедрение SQL (SQLi) или межсайтовые скрипты (CSS).

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

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

Распределенное отказ в обслуживании (DDoS) — используйте защиту сети DDoS Azure для повышения защиты от атак DDoS, чем базовая защита, которую предоставляет Azure.

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

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

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

Теги служб можно использовать для определения элементов управления доступом к сети в группах безопасности сети или Брандмауэр Azure.

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

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

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

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

Операционное превосходство

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

Группы ресурсов— используйте группы ресурсов для управления ресурсами Azure по времени существования, владельцу и другим характеристикам.

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

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

Эффективность производительности

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

Масштабируемые наборы виртуальных машин— используйте Масштабируемые наборы виртуальных машин для автоматизации масштабируемости виртуальных машин. Масштабируемые наборы виртуальных машин доступны во всех размерах виртуальных машин Windows и Linux. Плата взимается только за развернутые виртуальные машины и используемые базовые ресурсы инфраструктуры. Нет добавочных сборов. Преимущества Масштабируемые наборы виртуальных машин:

  • Создание нескольких виртуальных машин и управление ими легко
  • Высокий уровень доступности и устойчивость приложений
  • Автоматическое масштабирование по мере изменения спроса на ресурсы

Дополнительные сведения см. в Масштабируемые наборы виртуальных машин.

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

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