Базовый план миграции зоны доступности Azure

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

При создании надежных рабочих нагрузок можно выбрать по крайней мере одну из следующих конфигураций зоны доступности:

• Зональный. Зональная конфигурация предоставляет определенную локальную зону доступности.

• Избыточность между зонами. Конфигурация с избыточностью между зонами предоставляет ресурсы, которые реплицируются или распределяются по зонам автоматически.

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

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

Рекомендации по миграции в поддержку зоны доступности

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

Шаг 1. Проверьте, поддерживает ли регион Azure зоны доступности

На этом первом шаге необходимо проверить , поддерживает ли выбранный регион Azure зоны доступности, а также необходимые службы Azure для вашего приложения.

Если регион поддерживает зоны доступности, настоятельно рекомендуется настроить рабочую нагрузку для зон доступности. Если регион не поддерживает зоны доступности, вам потребуется использовать инструкции Azure Resource Mover для миграции в регион, который предлагает поддержку зоны доступности.

Шаг 2. Проверка доступности продукта и номера SKU в регионе Azure

На этом шаге вы убедитесь, что необходимые службы Azure и номера SKU доступны в зонах доступности выбранного региона Azure.

Сведения о региональной поддержке служб см. в разделе "Продукты по регионам".

Список доступных номеров SKU виртуальных машин в регионе и зоне Azure см. в разделе "Проверка доступности SKU виртуальной машины".

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

Для зональной высокой доступности Виртуальные машины Azure IaaS используйте Масштабируемые наборы виртуальных машин (VMSS) Flex для распространения виртуальных машин в нескольких зонах доступности.

Шаг 3. Рассмотрите требования к приложению

На этом последнем шаге вы определите требования к приложению, какие типы поддержки зоны доступности наиболее подходят для вашего приложения.

Ниже приведены три важных вопроса, которые помогут вам выбрать правильное развертывание зоны доступности:

Включает ли ваше приложение конфиденциальные компоненты задержки?

Зоны доступности Azure в одном регионе Azure подключены высокопроизводительной сетью с задержкой кругового пути менее 2 мс.

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

Для критически важных компонентов приложений, требующих физической близости и низкой задержки, таких как игры, инженерное моделирование и высокочастотная торговля (HFT), рекомендуется настроить зональное развертывание. Масштабируемые наборы виртуальных машин Flex предоставляет выровненные между зонами вычислительные ресурсы вместе с подключенными дисками хранилища.

Имеет ли код приложения готовность к обработке распределенной модели?

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

При зональном развертывании необходимо:

1. Определите конфиденциальные ресурсы или службы задержки в архитектуре.

2. Убедитесь, что конфиденциальные ресурсы или службы задержки поддерживают зональное развертывание.

3. Совместно найдите конфиденциальные ресурсы или службы задержки в одной зоне. Другие службы в архитектуре могут оставаться избыточными по зонам.

4. Репликация конфиденциальных зональных служб задержки в нескольких зонах доступности для обеспечения устойчивости зоны.

5. Балансировка нагрузки между несколькими зональными развертываниями с помощью стандартных или глобальных подсистем балансировки нагрузки.

Если служба Azure поддерживает зоны доступности, настоятельно рекомендуется использовать избыточность между зонами, распространяя узлы по зонам, чтобы повысить уровень обслуживания и защиту от зональных сбоев.

Для 3-уровневого приложения важно понимать уровни приложений, бизнеса и данных; а также их состояние (отслеживание состояния или без отслеживания состояния) для разработки в соответствии с рекомендациями и рекомендациями в соответствии с типом рабочей нагрузки.

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

• SAP

  • Конфигурации рабочих нагрузок SAP с использованием Зон доступности Azure
  • Группы доступности Azure и зоны доступности

• Виртуальный рабочий стол Azure

  • Рекомендации по непрерывности бизнес-процессов и аварийному восстановлению для виртуального рабочего стола Azure
  • Общая доступность зон доступности Azure в развертывании пула узлов

• Служба Azure Kubernetes

  • Создание кластера Служба Azure Kubernetes (AKS), использующего зоны доступности
  • Рекомендации по управлению операциями для Служба Azure Kubernetes
  • Перенос рабочих нагрузок Служба Azure Kubernetes (AKS) и Гибкого сервера MySQL в поддержку зоны доступности

• Oracle

  • Проектирование архитектуры Oracle в Azure

Вы хотите достичь непрерывности бизнес-процессов и аварийного восстановления в одном регионе Azure из-за соответствия требованиям, расположения данных или требований к управлению?

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

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

Прочие моменты, которые следует принять во внимание

• Сведения о тестировании приложений для обеспечения доступности и устойчивости см. в статье "Тестирование приложений для обеспечения доступности и устойчивости".

• Каждый центр обработки данных в регионе назначается физической зоне. Физические зоны сопоставляются с логическими зонами в подписке Azure. Подписки Azure автоматически назначаются этому сопоставлению во время создания подписки. Вы можете использовать выделенный REST API ARM, listLocations и задать версию API 2022-12-01 для перечисления сопоставления логических зон с физической зоной для подписки. Эта информация важна для критически важных компонентов приложений, требующих совместного расположения с ресурсами Azure, классифицированными как стратегические службы , которые могут быть недоступны во всех физических зонах.

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