Включение избыточности и аварийного восстановления для Azure Spring Apps

Избыточность между зонами применяется к уровню ✔️ "Корпоративный" уровня ✔️ "Стандартный"

Аварийное восстановление, управляемое клиентом, применяется к уровню ✔️ "Корпоративный" уровня "Базовый" или "✔️ Стандартный"

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

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

Зоны доступности

Зоны доступности — это уникальные физические расположения в регионе Microsoft Azure. Каждая зона состоит из одного или нескольких центров обработки данных, обеспеченных независимыми системами электропитания, охлаждения и сетями. Чтобы обеспечить устойчивость, в каждом регионе с поддержкой зоны всегда есть несколько зон. Физическое разделение зон доступности в пределах региона защищает приложения и данные от сбоев центра обработки данных. Дополнительные сведения см. в разделе Регионы и зоны доступности.

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

Ограничения и доступность в регионах

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

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

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

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

Создание экземпляра 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 CLI или портал Azure.

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

az spring show \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name>

Цены

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

Геоизбыточное аварийное восстановление, управляемое клиентом

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

Планирование развертывания приложений

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

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

Большинство регионов Azure связаны с другим регионом в том же географическом регионе, что делает их региональной парой. Azure сериализует обновления платформ (плановое обслуживание) в парах регионов, чтобы одновременно обновлялся только один регион из пары. Если сбой затрагивает несколько регионов, по крайней мере один регион в каждой паре имеет приоритет для восстановления.

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

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

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

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

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

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

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

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

    Имя службы Расположение Приложение
    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
    • Профили конечных точек:
    Профиль Тип Назначение Приоритет Пользовательские параметры заголовка
    Профиль конечной точки А Внешняя конечная точка 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, интегрированных в шлюз приложений, в геоизбыточные экземпляры.

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

Дальнейшие действия