Репликация между регионами в 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 (Техас)*

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

Важно!

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

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

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

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