Надежность в Azure Spring Apps

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

Поддержка зоны доступности

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?"

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

Предварительные условия

• В плане "Базовый" резервирование зон недоступно.

• Azure Spring Apps поддерживает зоны доступности в следующих регионах:

  • Восточная Австралия
  • Южная Бразилия
  • Центральная Канада
  • Центральная часть США
  • Восточная Азия
  • Восточная часть США
  • Восточная часть США 2
  • Центральная Франция
  • Центрально-Западная Германия
  • Северная Европа
  • Восточная Япония
  • Республика Корея, центральный регион
  • Северная часть ЮАР;
  • Центрально-южная часть США
  • Юго-Восточная Азия
  • южная часть Соединенного Королевства
  • Западная Европа
  • западная часть США 2
  • Запад США 3

Создание экземпляра Azure Spring Apps с включенными зонами доступности

Вы можете включить зональную избыточность в Azure Spring Apps с использованием Azure CLI или портала Azure.

az spring create \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name> \
    --location <location> \
    --zone-redundant true

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

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

Опыт расслабления

Если экземпляр приложения выходит из строя из-за размещения на узле виртуальной машины в неисправной зоне, Azure Spring Apps создает новый экземпляр приложения для неработающего приложения на другом узле виртуальной машины в другой зоне доступности. Пользователи могут столкнуться с коротким прерыванием в течение этого времени. Никаких действий пользователя не требуется, и затронутый экземпляр Azure Spring Apps будет восстановлен службой.

Цены

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

Аварийное восстановление между регионами и непрерывность бизнес-процессов

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

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

Служба Azure Spring Apps не предоставляет георезервное восстановление, но тщательное планирование может помочь защитить вас от простоя.

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

При разработке архитектуры учитывайте следующие ключевые факторы:

• Доступность по регионам. Чтобы свести к минимуму задержку сети и время передачи, выберите регион, поддерживающий избыточность зоны Azure Spring Apps, или географическую область, близкую к пользователям.
• Пары регионов Azure. Чтобы обеспечить скоординированные обновления платформы и при необходимости приоритеты усилий по восстановлению, выберите парные регионы в выбранной географической области.
• Доступность службы. Определите, должны ли ваши пары регионов работать в режиме горячий/горячий, горячий/тёплый или горячий/холодный.

Использование диспетчера трафика Azure для маршрутизации трафика

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

Если у вас есть приложения в Azure Spring Apps, работающих в нескольких регионах, Диспетчер трафика Azure может управлять потоком трафика в приложениях в каждом регионе. Определите конечную точку Azure Traffic Manager для каждого экземпляра службы, используя IP-адрес этого экземпляра. Для подключения используйте DNS-имя службы Azure Traffic Manager, указывающее на экземпляр сервиса Azure Spring Apps. Диспетчер трафика Azure распределяет трафик между определенными конечными точками. Если в центре обработки данных происходит авария, Диспетчер трафика Azure перенаправляет трафик из этого региона в парный центр, обеспечивая непрерывность службы.

Чтобы создать экземпляр Диспетчер трафика Azure для экземпляров Azure Spring Apps, выполните следующие действия.

1. Создайте экземпляры Azure Spring Apps в двух разных регионах. Например, создайте экземпляры служб в восточной части США и Западной Европы, как показано в следующей таблице. Каждый экземпляр служит основным и резервным конечным пунктом для трафика.

   Название услуги	Расположение	Приложение
   service-sample-a	Восточная часть США	шлюз / служба аутентификации / служба аккаунтов
   service-sample-b	Западная Европа	шлюз / сервис-аутентификации / сервис-аккаунтов

2. Настройте пользовательский домен для экземпляров услуг. Дополнительные сведения см. в руководстве Сопоставление существующего личного домена с Azure Spring Apps. После успешной установки оба экземпляра службы привязываются к одному и тому же пользовательскому домену, например bcdr-test.contoso.com.

3. Создайте диспетчер трафика и две конечные точки. Для получения инструкций см. в кратком руководстве: Создание профиля диспетчера трафика с помощью портала Azure, которое создаёт следующий профиль диспетчера трафика:

   • DNS-имя диспетчера трафика: http://asa-bcdr.trafficmanager.net
   • Профили конечных точек:

   Профиль	Тип	Цель	Приоритет	Настраиваемые параметры заголовка
   Профиль конечной точки А	Внешняя конечная точка	service-sample-a.azuremicroservices.io	1	host: bcdr-test.contoso.com
   Профиль конечной точки B	Внешняя конечная точка	service-sample-b.azuremicroservices.io	2	host: bcdr-test.contoso.com

4. Создайте запись CNAME в зоне DNS, как показано в следующем примере. bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net

Теперь среда настроена. Если вы использовали примеры значений в связанных статьях, вы сможете получить доступ к приложению с помощью https://bcdr-test.contoso.com.

Используйте Azure Front Door и Шлюз приложений Azure для маршрутизации трафика

Azure Front Door — это глобальная масштабируемая точка входа, использующая глобальную промежуточную подсеть Майкрософт для создания быстрых, безопасных и масштабируемых веб-приложений. Azure Front Door обеспечивает ту же многозоновую избыточность и маршрутизацию в ближайший регион, что и Диспетчер трафика Azure. Azure Front Door также предоставляет дополнительные функции, такие как завершение протокола TLS, обработка слоя приложений и Брандмауэр веб-приложений (WAF). Дополнительные сведения см. в статье "Что такое Azure Front Door?"

На следующей схеме показана архитектура экземпляра службы Azure Spring Apps, интегрированной с виртуальной сетью, с резервированием для нескольких регионов. На схеме показана правильная конфигурация обратного прокси-сервера для Application Gateway и Front Door с пользовательским доменом. Эта архитектура основана на сценарии, описанном в статье "Предоставление приложений с помощью сквозного TLS в виртуальной сети". Этот подход объединяет два экземпляра Azure Spring Apps, интегрированных с Application Gateway, со встроенной виртуальной сетью в геоизбыточный экземпляр.

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

• Краткое руководство. Развертывание первого приложения Spring Boot в Azure Spring Apps

• Надежность в Azure