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

Статья
10/26/2023

В этой статье содержатся подробные сведения о региональной устойчивости с зонами доступности и поддержкой аварийного восстановления между регионами и поддержкой непрерывности бизнес-процессов для 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 Spring Apps с помощью Azure CLI или портал Azure.

Azure CLI
Портал Azure

Чтобы создать службу в Azure Spring Apps с поддержкой избыточности между зонами с помощью Azure CLI, включите --zone-redundant параметр при создании службы, как показано в следующем примере:

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 будет восстановлен службой.

Цены

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

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

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

Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы 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 для каждого экземпляра службы с помощью IP-адреса экземпляра. Необходимо подключиться к Диспетчер трафика Azure DNS-имени, указывающего на экземпляр службы Azure Spring Apps. Диспетчер трафика Azure распределяет трафик между определенными конечными точками. Если авария попадает в центр обработки данных, Диспетчер трафика Azure направляет трафик из этого региона в свою пару, обеспечивая непрерывность службы.

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

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

Service name	Расположение	Приложение
service-sample-a	Восточная часть США	gateway / auth-service / account-service
service-sample-b	Западная Европа	gateway / auth-service / account-service

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

Создайте диспетчер трафика и две конечные точки. Инструкции см. в кратком руководстве по созданию профиля Диспетчер трафика с помощью портал 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`

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

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