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

Geography Региональная пара 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.

📎📎📎📎📎📎📎📎📎📎