Надежность в приложениях контейнеров Azure
В этой статье описывается поддержка надежности в приложениях контейнеров Azure и охватывает как региональную устойчивость с зонами доступности, так и устойчивостью между регионами при аварийном восстановлении. Более подробный обзор надежности в Azure см. в статье "Надежность Azure".
Поддержка зоны доступности
Зоны доступности — это физически отдельные группы центров обработки данных в каждом регионе Azure. При сбое одной зоны службы могут выполнять отработку отказа в одну из оставшихся зон.
Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?".
Приложения контейнеров Azure используют зоны доступности в регионах, где они доступны для обеспечения высокой доступности для приложений и данных из сбоев центра обработки данных.
Включив функцию избыточности зон контейнеров, реплики автоматически распределяются по зонам в регионе. Трафик распределяется между репликами. Если происходит сбой в зоне, трафик автоматически направляется на реплики в остальных зонах.
Примечание.
Дополнительная плата за включение избыточности зоны не взимается, но она предоставляет преимущества только при наличии 2 или более реплик, при этом идеально подходит 3 или более регионов, так как большинство регионов, поддерживающих избыточность зоны, имеют 3 зоны.
Необходимые компоненты
Приложения контейнеров Azure обеспечивают одинаковую поддержку надежности независимо от типа плана.
Приложения контейнеров Azure используют зоны доступности в регионах, где они доступны. Список регионов, поддерживающих зоны доступности, см. в статье Регионы Azure с зонами доступности.
Улучшения обслуживания
Для приложений контейнеров Azure нет дополнительных соглашений об уровне обслуживания. Дополнительные сведения об соглашениях об уровне обслуживания приложений контейнеров Azure см . в соглашении об уровне обслуживания для приложений контейнеров Azure.
Создание ресурса с включенной зоной доступности
Настройка избыточности зоны в среде "Приложения контейнеров"
Чтобы воспользоваться преимуществами зон доступности, необходимо включить избыточность зоны при создании среды приложений контейнеров. Среда должна включать виртуальную сеть с доступной подсетью. Чтобы обеспечить правильное распределение реплик, установите минимальное число реплик приложения на три.
Включение избыточности зоны с помощью портал Azure
Чтобы создать приложение-контейнер в среде с поддержкой избыточности зоны с помощью портал Azure:
- Перейдите на портал Azure.
- Найдите контейнерные приложения в верхнем поле поиска.
- Выберите "Приложения-контейнеры".
- Выберите "Создать" в поле "Среда приложений контейнеров", чтобы открыть панель "Создание среды приложений контейнеров".
- Введите имя среды.
- Выберите "Включено " для поля избыточности зоны.
Для избыточности зоны требуется виртуальная сеть с подсетью инфраструктуры. Можно выбрать существующую виртуальную сеть или создать новую. При создании новой виртуальной сети можно принять значения, указанные для вас, или настроить параметры.
- Перейдите на вкладку Сеть.
- Чтобы назначить имя настраиваемой виртуальной сети, нажмите кнопку "Создать" в поле виртуальная сеть.
- Чтобы назначить имя настраиваемой подсети инфраструктуры, выберите "Создать" в поле "Подсеть инфраструктуры".
- Для виртуального IP-адреса можно выбрать внутренний или внешний.
- Нажмите кнопку создания.
Включение избыточности зоны с помощью Azure CLI
Создайте подсеть виртуальной сети и инфраструктуры для включения в среду приложений контейнеров.
При использовании этих команд замените <PLACEHOLDERS> значениями.
Примечание.
Для среды потребления требуется выделенная подсеть с диапазоном /23 CIDR или больше. Для среды профилей рабочей нагрузки требуется выделенная подсеть с диапазоном /27 CIDR или больше. Дополнительные сведения о размерах подсети см. в обзоре сетевой архитектуры.
az network vnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--name <VNET_NAME> \
--location <LOCATION> \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--vnet-name <VNET_NAME> \
--name infrastructure \
--address-prefixes 10.0.0.0/21
Затем выполните запрос к идентификатору подсети инфраструктуры.
INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`
Наконец, создайте среду с параметром --zone-redundant . Расположение должно быть таким же расположением, которое используется при создании виртуальной сети.
az containerapp env create \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--location "<LOCATION>" \
--infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
--zone-redundant
Проверка избыточности зоны с помощью Azure CLI
Примечание.
Портал Azure не показывает, включена ли избыточность зоны.
az container app env show Используйте команду для проверки избыточности зоны для среды контейнеров.
az containerapp env show \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--subscription <SUBSCRIPTION_ID>
Команда возвращает ответ JSON. Проверьте, содержится "zoneRedundant": trueли ответ.
Методы безопасного развертывания
При настройке избыточности зоны в приложении-контейнере реплики распределяются автоматически по зонам в регионе. После распределения реплик трафик распределяется между ними. Если происходит сбой в зоне, трафик автоматически направляется к репликам в оставшейся зоне.
Вы по-прежнему должны использовать безопасные методы развертывания, такие как сине-зеленое развертывание. Приложения контейнеров Azure не предоставляют однозонное развертывание или обновление.
Если вы включили сходство сеансов, а зона исчезнет, клиенты для этой зоны перенаправляются на новые реплики, так как предыдущие реплики больше не доступны. Любое состояние, связанное с предыдущими репликами, теряется.
Миграция зоны доступности
Чтобы воспользоваться преимуществами зон доступности, включите избыточность зоны при создании среды "Приложения контейнеров". Среда должна включать виртуальную сеть с доступной подсетью. Невозможно перенести существующую среду приложений контейнеров из недоступной зоны поддержки в поддержку зоны доступности.
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплицируют данные или не реплицируются из неудающегося региона для перекрестной репликации в другой включенный регион. Для этих служб вы отвечаете за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
В маловероятном случае сбоя в полном регионе у вас есть возможность использовать одну из двух стратегий:
Восстановление вручную. Вручную разверните его в новом регионе или дождитесь восстановления региона, а затем повторно разверните все среды и приложения вручную.
Отказоустойчивое восстановление. Сначала разверните приложения-контейнеры заранее в нескольких регионах. Затем используйте Azure Front Door или Диспетчер трафика Azure для обработки входящих запросов, указывая трафик на основной регион. Затем, если произойдет сбой, вы можете перенаправить трафик из затронутого региона. Дополнительные сведения см. в статье Репликация между регионами в Azure.
Примечание.
Независимо от выбранной стратегии убедитесь, что файлы конфигурации развертывания находятся в системе управления версиями, чтобы можно было легко повторно развернуть при необходимости.
Дополнительные рекомендации
Следующие ресурсы помогут вам создать собственный план аварийного восстановления:
- Восстановление после сбоев и аварийное восстановление для приложений Azure
- Техническое руководство по обеспечению устойчивости в Azure