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

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

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

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

Architecture

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

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

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

Components

• Среда службы приложений версии 3 — это изолированное, высокопроизводительное решение для размещения, поддерживающее зональную избыточность. В регионах, поддерживающих избыточность зоны, можно настроить избыточность зоны в любой момент во время жизненного цикла среды службы приложений. Каждый план службы приложений в зоне-избыточной среде службы приложений должен содержать не менее двух экземпляров, чтобы гарантировать развертывание в двух или более зонах. Вы можете объединить выделенные за счёт зон и невыделенные за счёт зон планы в одной среде для приложений. Чтобы настроить план, имеющий только один экземпляр, сначала отключите избыточность зоны для этого плана. Избыточность зоны не приводит к дополнительным расходам. Вы оплачиваете только используемые изолированные экземпляры версии 2. Дополнительные сведения см. в разделе "Цены на среду службы приложений " и "Надежность" в среде службы приложений. В этой архитектуре среда службы приложений версии 3 предоставляет изолированную, высокопроизводительную платформу размещения для веб-приложений, API и функций.

• Виртуальная сеть Azure — это сеть на основе IP-адресов уровня 3, которая охватывает все зоны доступности в одном регионе. Подсети в виртуальной сети также распространяются на зоны доступности. Дополнительные сведения см. в разделе "Требования к сети" для среды службы приложений и надежности в виртуальной сети. В этой архитектуре виртуальная сеть обеспечивает безопасную изолированную сеть для всех ресурсов.

• Шлюз приложений Azure версии 2 — это подсистема балансировки нагрузки веб-трафика на основе облака, которая поддерживает избыточность зоны. В этой архитектуре она охватывает несколько зон доступности в каждом регионе. В результате один шлюз приложений обеспечивает высокий уровень доступности, как показано в эталонной архитектуре. Эталонная архитектура использует SKU брандмауэра веб-приложений шлюза приложений, который обеспечивает повышенную защиту от распространенных угроз и уязвимостей. Эта защита основана на реализации основного набора правил (CRS) проекта Open Web Application Security (OWASP). Дополнительные сведения см. в разделе "Надежность" в шлюзе приложений версии 2. Шлюз приложений версии 2 служит зонально-избыточным балансировщиком веб-трафика.

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

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

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

• GitHub Actions — это платформа автоматизации, которая поддерживает возможности непрерывной интеграции и непрерывного развертывания (CI/CD). В этой архитектуре GitHub Actions создает приложения за пределами виртуальной сети и развертывает их в планах службы приложений, размещенных в среде службы приложений.

Среда службы приложений находится в виртуальной сети, поэтому виртуальная машина служит полем перехода в виртуальной сети для упрощения развертывания. Для повышения безопасности и подключения через протокол удаленного рабочего стола (RDP) и Secure Shell (SSH) рекомендуется использовать Бастион Azure для прыжкового сервера.

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

Соображения

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

Reliability

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

прыжковые серверы

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

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

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

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

• Зоны доступности можно настроить при создании среды службы приложений или в любой момент жизненного цикла среды.

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

• Только подмножество регионов поддерживает зоны доступности.

Дополнительные сведения см. в разделе "Надежность" в службе приложений.

Resiliency

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

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"));

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

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

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

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

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

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

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

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

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

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

• Deep Bhattacharya | Архитектор облачных решений
• Сухас Рао | Архитектор облачных решений

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

Дальнейшие шаги

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

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