Базовые показатели миграции зоны доступности Azure
В этой статье показано, как оценить готовность приложения к зоне доступности для перехода с поддержки зоны доступности на поддержку зоны доступности. Мы рассмотрим шаги, необходимые для определения того, как можно воспользоваться преимуществами поддержки зон доступности в соответствии с требованиями приложения и региона. Дополнительные сведения о зонах доступности и регионах, которые их поддерживают, см. в статье Что такое регионы Azure и зоны доступности.
При создании надежных рабочих нагрузок можно выбрать по крайней мере одну из следующих конфигураций зоны доступности:
Зональный. Зональная конфигурация предоставляет определенную, самостоятельно выбранную зону доступности.
Избыточность между зонами. Конфигурация, избыточная между зонами, предоставляет ресурсы, которые автоматически реплицируются или распределяются между зонами.
Помимо двух вариантов зон доступности, зональных и избыточных между зонами, Azure предлагает глобальные службы, что означает, что они доступны глобально независимо от региона. Так как эти службы всегда доступны в разных регионах, они устойчивы к региональным и зональным сбоям.
Чтобы узнать, какие службы Azure поддерживают зоны доступности, см. статью Служба зон доступности и региональная поддержка.
Примечание
Если вы не выберете конфигурацию зоны для ресурса( зональной или избыточной между зонами), ресурс и его подкомпоненты не будут устойчивы к зонам и могут выйти из строя во время зонального сбоя в этом регионе.
Рекомендации по переходу на поддержку зоны доступности
Существует несколько возможных способов создания надежного приложения Azure с зонами доступности, которые соответствуют как соглашениям об уровне обслуживания, так и целевым показателям надежности. Выполните приведенные ниже действия, чтобы выбрать правильный подход в соответствии с техническими и нормативными требованиями, возможностями службы, местом расположения данных, требованиями к соответствию и задержкой.
Шаг 1. Проверьте, поддерживает ли регион Azure зоны доступности
На этом первом шаге необходимо убедиться , что выбранный регион Azure поддерживает зоны доступности, а также необходимые службы Azure для вашего приложения.
Если ваш регион поддерживает зоны доступности, настоятельно рекомендуется настроить рабочую нагрузку для зон доступности. Если ваш регион не поддерживает зоны доступности, вам потребуется использовать руководство Azure Resource Mover для миграции в регион, который предлагает поддержку зон доступности.
Примечание
Для некоторых служб зоны доступности можно настроить только во время развертывания. Если вы хотите включить зоны доступности для существующих служб, может потребоваться повторное развертывание. Ознакомьтесь с документацией по конкретным службам в статье Общие сведения о рекомендациях по миграции зон доступности для продуктов и служб Microsoft Azure.
Шаг 2. Проверка доступности продукта и SKU в регионе Azure
На этом шаге вы проверите, доступны ли необходимые службы и номера SKU Azure в зонах доступности выбранного региона Azure.
Чтобы проверка для региональной поддержки служб, см. статью Продукты, доступные по регионам.
Список доступных номеров SKU виртуальных машин по регионам и зонам Azure см. в статье Проверка доступности номера SKU виртуальной машины.
Если ваш регион не поддерживает службы и номера SKU, необходимые приложению, вернитесь к шагу 1. Проверьте доступность продукта в регионе Azure , чтобы найти новый регион, поддерживающий службы и номера SKU, необходимые приложению. Настоятельно рекомендуется настроить рабочую нагрузку с избыточностью между зонами.
Для зонального высокого уровня доступности azure IaaS Виртуальные машины используйте Масштабируемые наборы виртуальных машин (VMSS) Flex, чтобы распределить виртуальные машины между несколькими зонами доступности.
Шаг 3. Учитывайте требования к приложению
На этом последнем шаге вы определите, какой тип поддержки зоны доступности наиболее подходит вашему приложению, в зависимости от требований приложения.
Ниже приведены три важных вопроса, которые помогут вам выбрать правильное развертывание зоны доступности.
Включает ли приложение компоненты, чувствительные к задержке?
Зоны доступности Azure в одном регионе Azure подключены к высокопроизводительной сети с задержкой кругового пути менее 2 мс.
Рекомендуемый подход к достижению высокого уровня доступности, если низкая задержка не является строгим требованием, заключается в настройке рабочей нагрузки с развертыванием, избыточным между зонами.
Для критически важных компонентов приложений, требующих физической близости и низкой задержки, таких как игры, инженерное моделирование и высокочастотная торговля (HFT), рекомендуется настроить зональное развертывание. Масштабируемые наборы виртуальных машин Flex предоставляет вычислительные ресурсы, выровненные по зонам, а также подключенные диски хранилища.
Имеет ли код приложения готовность к работе с распределенной моделью?
Для модели распределенных микрослужб и в зависимости от приложения существует возможность постоянного обмена данными между микрослужбами в разных зонах. Такой непрерывный обмен данными через API может повлиять на производительность. Чтобы повысить производительность и обеспечить надежную архитектуру, можно выбрать зональное развертывание.
При зональном развертывании необходимо:
Определение ресурсов или служб, чувствительных к задержке, в вашей архитектуре.
Убедитесь, что ресурсы или службы с учетом задержки поддерживают зональное развертывание.
Совместное размещение ресурсов или служб, чувствительных к задержке, в одной зоне. Другие службы в вашей архитектуре могут по-прежнему оставаться избыточными между зонами.
Реплицируйте зональные службы с учетом задержки в нескольких зонах доступности, чтобы обеспечить устойчивость зон.
Балансировка нагрузки между несколькими зональными развертываниями с помощью стандартных или глобальных подсистем балансировки нагрузки.
Если служба Azure поддерживает зоны доступности, настоятельно рекомендуется использовать избыточность между зонами, распределяя узлы между зонами, чтобы обеспечить более высокое время доступности и защиту от зональных сбоев.
Для трехуровневого приложения важно понимать уровни приложения, бизнеса и данных; а также их состояние (с отслеживанием или без отслеживания состояния) для архитектуры в соответствии с рекомендациями и рекомендациями в соответствии с типом рабочей нагрузки.
Сведения о специализированных рабочих нагрузках в Azure, как показано ниже, см. в соответствующем руководстве по архитектуре целевой зоны и рекомендациях.
SAP
Виртуальный рабочий стол Azure
Служба Azure Kubernetes
Oracle;
Хотите обеспечить непрерывность бизнес-процессов и аварийное восстановление в одном регионе Azure в соответствии с требованиями к соответствию, месту расположения данных или управлению?
Для обеспечения непрерывности бизнес-процессов и аварийного восстановления в одном регионе и при отсутствии региональной пары настоятельно рекомендуется настроить рабочую нагрузку с избыточностью между зонами. Подход с одним регионом также применим к определенным отраслям, которые имеют строгие требования к месту расположения данных и управлению в одном регионе Azure. Сведения о репликации, отработке отказа и восстановлении размещения виртуальных машин Azure из одной зоны доступности в другую в пределах одного региона Azure см. в статье Включение аварийного восстановления виртуальных машин Azure между зонами доступности.
Если требуется несколько регионов или ваш регион Azure не поддерживает зоны доступности, рекомендуется использовать пары регионов. Региональные пары расположены на расстоянии около 100 миль друг от друга, и дают вам защиту от сбоев регионального уровня, таких как пожар, наводнения, землетрясения и другие природные или непредвиденные бедствия. Дополнительные сведения см. в статье Репликация между регионами в Azure: непрерывность бизнес-процессов и аварийное восстановление.
Примечание
Могут быть сценарии, в которых сочетание зональных, избыточных между зонами и глобальных служб лучше всего соответствует бизнес-требованиям и техническим требованиям.
Прочие моменты, которые следует принять во внимание
Дополнительные сведения о тестировании приложений на доступность и устойчивость см. в статье Тестирование приложений на доступность и устойчивость.
Каждый центр обработки данных в регионе назначается физической зоне. Физические зоны сопоставляются с логическими зонами в подписке Azure. Подписки Azure автоматически назначаются этому сопоставлению при создании подписки. Вы можете использовать выделенный REST API ARM, listLocations и задать версию API 2022-12-01, чтобы получить список логических сопоставлений зоны с физической зоной для вашей подписки. Эти сведения важны для критически важных компонентов приложений, которым требуется совместное размещение с ресурсами Azure, которые классифицируются как стратегические службы , которые могут быть доступны не во всех физических зонах.
Плата за пропускную способность между зонами взимается при перемещении трафика между зонами. Дополнительные сведения о ценах на пропускную способность см. в разделе Цены на пропускную способность.