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

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

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

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

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

Architecture

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

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

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

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

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

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

Если целевой объект завершается ошибкой пробы работоспособности, шлюз приложений помечает целевой объект как неработоспособный и останавливает запросы маршрутизации к нему. Если все целевые объекты в серверном пуле неработоспособны, шлюз приложений возвращает ответ HTTP 502. Неизвестное состояние в отчете о работоспособности серверной части указывает, что плоскость управления не может определить работоспособности целевого объекта и не обязательно означает, что шлюз приложений остановил трафик маршрутизации. Пробы работоспособности обнаруживают сбои, но они не предоставляют другое приложение или Среда службы приложений для отработки отказа.

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

Управляемый Redis в Azure

Настройте Azure Managed Redis для обеспечения высокой доступности, чтобы он развертывал по крайней мере два узла в зонах доступности. Во время сбоя зоны Azure Managed Redis автоматически перенаправляет трафик на здоровые узлы. Отработка отказа может привести к потере от 10 до 15 секунд простоя и данных, которые не реплицировались в другую зону. Приложения должны повторить временные сбои и использовать шаблонCache-Aside , чтобы они могли вернуться к основному хранилищу данных, если кэш недоступен. Дополнительные сведения см. в статье "Надежность" в Управляемом Redis Azure.

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

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

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

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

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

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

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

Соавторы

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

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

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

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

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