Репликация между регионами в 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 может связать данные в Canada Central с одноранговым элементом в Восточной Канаде при использовании вычислительных ресурсов 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.

Важно!

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

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

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

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