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

  • Статья

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

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

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

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

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

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 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 не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе 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, выполните следующие действия.

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

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

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

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

    • DNS-имя диспетчера трафика: http://asa-bcdr.trafficmanager.net
    • Профили конечных точек:
    Profile Тип Назначение Приоритет Настраиваемые параметры заголовка
    Профиль конечной точки А Внешняя конечная точка 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 с несколькими регионами. На схеме показана правильная конфигурация обратного прокси-сервера для Шлюз приложений и Front Door с личным доменом. Эта архитектура основана на сценарии, описанном в статье "Предоставление приложений с помощью сквозного TLS в виртуальной сети". Этот подход объединяет два экземпляра внедрения виртуальной сети Azure Spring Apps в геоизбыточное экземпляр.

Diagram showing the architecture of a multi-region Azure Spring Apps service instance.

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