Изменить

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

Высокодоступное корпоративное развертывание с помощью Среда службы приложений

Microsoft Entra ID
Шлюз приложений Azure
Брандмауэр Azure
Виртуальная сеть Azure
Служба приложений Azure

Примечание.

Среда службы приложений версии 3 является основным компонентом этой архитектуры. Версии 1 и 2 были прекращены 31 августа 2024 года.

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

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

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

Логотип GitHub Эталонная реализация этой архитектуры доступна на сайте GitHub.

Архитектура

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

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

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

Рабочий процесс

В этом разделе описывается характер доступности служб, используемых в этой архитектуре:

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

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

  • Шлюз приложений версии 2 является избыточной по зонам. Как и виртуальная сеть, она охватывает несколько зон доступности в каждом регионе. Поэтому для высокодоступной системы достаточно одного шлюза приложений, как показано в эталонной архитектуре. Эталонная архитектура использует SKU WAF Шлюз приложений, которая обеспечивает повышенную защиту от распространенных угроз и уязвимостей на основе реализации основного набора правил (CRS) проекта Open Web Application Security Project (OWASP). Дополнительные сведения см. в разделе Масштабирование Шлюз приложений версии 2 и WAF версии 2.

  • Брандмауэр Azure поддерживает встроенную поддержку высокой доступности. Он может пересекать несколько зон без дополнительной настройки.

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

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

  • GitHub Actions предоставляет возможности непрерывной интеграции и непрерывного развертывания (CI/CD) в этой архитектуре. Так как Среда службы приложений находится в виртуальной сети, виртуальная машина используется в качестве прыжка в виртуальной сети для развертывания приложений в планах Служба приложений. Действие создает приложения за пределами виртуальной сети. Для повышения безопасности и простого подключения RDP/SSH рекомендуется использовать Бастион Azure для прыжков.

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

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

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

Availability

Среда службы приложений

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

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

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

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

Устойчивость

Приложения, выполняемые в Среда службы приложений, формируют внутренний пул для Шлюз приложений. Когда запрос к приложению поступает из общедоступного Интернета, шлюз перенаправит запрос приложению, работающему в Среда службы приложений. Эта эталонная архитектура реализует проверки работоспособности в главном веб-интерфейсе votingApp. Эта проба работоспособности проверяет работоспособности веб-API и кэша Redis. Код, реализующий эту пробу, можно увидеть в Startup.cs:

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

В следующем коде показано, как скрипт commands_ha.azcli настраивает серверные пулы и пробу работоспособности для шлюза приложений:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
  {
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "probePath": "/health"
  }
]

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

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

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

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

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

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

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

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

Рекомендации по развертыванию

Эта эталонная реализация использует тот же конвейер CI/CD уровня рабочей среды, что и стандартное развертывание, с одной виртуальной машиной прыжка. Однако вы можете решить использовать один прыжок для каждой из трех зон. В этой архитектуре используется только один прыжок, так как поле перехода не влияет на доступность приложения. Прыжки используются только для развертывания и тестирования.

Развертывание этого сценария

Сведения о развертывании эталонной реализации для этой архитектуры см. в GitHub readme. Используйте сценарий для развертывания с высоким уровнем доступности.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Эту архитектуру можно изменить, горизонтально масштабируя приложения в одном регионе или в нескольких регионах на основе ожидаемой пиковой нагрузки. Репликация приложений в нескольких регионах может помочь снизить риски более широких географических сбоев центра обработки данных, таких как землетрясения или другие стихийные бедствия. Дополнительные сведения о горизонтальном масштабировании см. в разделе "Гео распределенное масштабирование" с помощью Среда службы приложений. Для глобального и высокодоступного решения маршрутизации рекомендуется использовать Azure Front Door.