Репликация между регионами в Azure: непрерывность бизнес-процессов и аварийное восстановление

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

Репликация между регионами

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

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

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

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

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

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

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

Преимущества репликации между регионами

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

  • Последовательность восстановления регионов. Если происходит сбой на уровне географического региона, восстановление одного региона является приоритетным из всех включенных регионов. Приложения, развернутые в включенных наборах регионов, гарантированно будут иметь один из регионов, приоритетных для восстановления. Если приложение развертывается в разных регионах, в которых не включена межрегиональная репликация, восстановление может быть отложено.
  • Последовательное обновление. Запланированные обновления системы Azure для включенных регионов в хронологическом порядке, чтобы свести к минимуму время простоя, влияние ошибок и логических сбоев в редких случаях неисправного обновления.
  • Физическая изоляция. Azure стремится обеспечить минимальное расстояние в 300 миль (483 километра) между центрами обработки данных в разрешенных регионах, хотя это возможно не во всех географических регионах. Разделение центров обработки данных снижает вероятность того, что стихийное бедствие, гражданские беспорядки, перебои в подаче электроэнергии или физические перебои в сети могут повлиять на несколько регионов. Изоляция зависит от ограничений в географическом регионе, таких как размер географического региона, доступность инфраструктуры электропитания или сети, а также нормативные требования.
  • Место расположения данных. Регионы находятся в том же географическом регионе, что и их включенный набор (за исключением южной Бразилии и Сингапура) для удовлетворения требований к месту расположения данных для целей налоговой и правоохранительной юрисдикции.

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

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

Вы не ограничиваетесь использованием служб в региональных парах. Хотя служба Azure может полагаться на определенную региональную пару, вы можете разместить другие службы в любом регионе, который соответствует потребностям вашего бизнеса. Например, решение хранилища Azure GRS может связывать данные в Центральной Канаде с одноранговым элементом в Восточной Канаде, используя вычислительные ресурсы Azure, расположенные в восточной части США.

Связывание репликации между регионами Azure для всех географических регионов

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

Пары регионов Azure

Географический регион Региональная пара A Региональная пара B
Азиатско-Тихоокеанский регион Восточная Азия (Гонконг) Юго-Восточная Азия (Сингапур)
Австралия Восточная Австралия Юго-Восточная часть Австралии
Австралия Центральная Австралия Центральная Австралия 2*
Бразилия Южная Бразилия Центрально-южная часть США
Бразилия Юго-Восточная Бразилия* Южная Бразилия
Canada Центральная Канада Восточная Канада
Китай Северный Китай Восточный Китай
Китай Северный Китай 2 Восточный Китай 2
Китай Северный Китай 3 Восточный Китай 3*
Европа Северная Европа (Ирландия) Западная Европа (Нидерланды)
Франция Центральная Франция Южная Франция*
Германия Центрально-Западная Германия Северная Германия*
Индия Центральная Индия Южная Индия
Индия Западная Индия Южная Индия
Япония Восточная Япония Западная Япония
Корея Республика Корея, центральный регион Южная Корея*
Северная Америка Восточная часть США западная часть США
Северная Америка восточная часть США 2 Центральная часть США
Северная Америка Центрально-северная часть США Центрально-южная часть США
Северная Америка Западная часть США 2 центрально-западная часть США
Северная Америка Западная часть США — 3 Восточная часть США
Норвегия Восточная Норвегия; Западная Норвегия*
ЮАР Северная часть ЮАР; Западная часть ЮАР*
Швеция Центральная Швеция Южная Швеция*
Швейцария Северная Швейцария Западная Швейцария*
Соединенное Королевство западная часть Соединенного Королевства южная часть Соединенного Королевства
ОАЭ Северная часть ОАЭ; Центральная часть ОАЭ*
Министерства обороны США восточный регион US DoD* центральный регион US DoD*
US (США) US Gov (Аризона)* US Gov (Техас)*
US (США) US Gov (Айова)* US Gov (Вирджиния)*
US (США) US Gov (Вирджиния)* US Gov (Техас)*

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

Важно!

  • Западная Индия спарена только в одном направлении. Дополнительный регион для региона "Западная Индия" — "Южная Индия", а дополнительный регион для региона "Южная Индия — "Центральная Индия".
  • Южная Бразилия является уникальным регионом, так как она образует пару за пределами своей географической территории. Дополнительный регион для Южной Бразилии — центрально-южная часть США. Дополнительный регион "Центрально-южная часть США" не является регионом "Южная Бразилия".

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

Azure продолжает глобально расширяться, и Катар является первым регионом без региональной пары и обеспечивает высокий уровень доступности за счет использования зон доступности и локально избыточного или избыточного между зонами хранилища (LRS/ZRS). Регионы без пары не будут иметь геоизбыточное хранилище (GRS). Такие регионы следуют рекомендациям по месту расположения данных , что позволяет сохранять данные в одном регионе. Клиенты несут ответственность за устойчивость данных в зависимости от их целевой точки восстановления или целевого времени восстановления (RTO/RPO) и могут перемещать, копировать или получать доступ к своим данным из любого расположения по всему миру. В редких случаях, когда весь регион Azure становится недоступным, клиентам потребуется спланировать аварийное восстановление между регионами в зависимости от рекомендаций служб Azure, которые поддерживают высокий уровень доступности и устойчивость Azure — непрерывность бизнес-процессов и аварийное восстановление.

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