Изменить

Share via

Перемещение ресурсов Azure между регионами

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
VPN-шлюз Azure

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

Архитектура

Схема, показывая поток данных для перемещения ресурсов Azure по регионам.

Скачайте файл Visio для этой архитектуры.

Поток данных

  • Локальная сеть центра обработки данных: частная локальная сеть, запущенная в организации для поддержки локальных ресурсов.

  • Канал ExpressRoute: подключения ExpressRoute используют частное выделенное подключение через стороннего поставщика подключений. Частное подключение расширяет локальную сеть в Azure.

  • Локальные пограничные маршрутизаторы: маршрутизаторы, которые подключают локальную сеть к каналу, управляемому сторонним поставщиком. В зависимости от того, как вы подготовили подключение, может потребоваться предоставить общедоступные IP-адреса, используемые маршрутизаторами.

  • Маршрутизаторы Microsoft Edge: два маршрутизатора в конфигурации с высоким уровнем доступности active. Эти маршрутизаторы позволяют стороннему поставщику подключения подключать каналы непосредственно к центру обработки данных. В зависимости от того, как вы подготовили подключение, может потребоваться предоставить общедоступные IP-адреса, используемые маршрутизаторами.

  • VPN-шлюз. С помощью службы VPN-шлюза можно подключить виртуальную сеть к локальной сети.

  • Подсеть Active Directory: большинство корпоративных организаций имеют среду домен Active Directory Services (AD DS) в локальном центре обработки данных. Чтобы упростить управление ресурсами, перенесенными в Azure из локальной сети, которая зависит от AD DS, рассмотрите возможность размещения контроллеров домена AD DS в Azure в центральном центре виртуальная сеть (VNET), к которому могут получить доступ зависимые рабочие нагрузки.

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

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

    • Веб-уровень: верхний слой, включая пользовательский интерфейс. Этот слой анализирует взаимодействие пользователей и передает действия следующему уровню для обработки.
    • Уровень бизнес-приложений: обрабатывает взаимодействие с пользователем и принимает логические решения о следующих шагах. Этот уровень соединяет веб-уровень и уровень данных.
    • Уровень данных: хранит данные приложения. В этом случае база данных SQL сохраняет данные.

  • Внутренняя подсистема балансировки нагрузки: сетевой трафик из VPN-шлюза направляется в облачное приложение через конечную точку внутренней подсистемы балансировки нагрузки (ILB), расположенную в подсети уровней приложений.

  • Ресурсы платформы как услуга (PaaS): в этой среде есть несколько служб PaaS, таких как Центр Интернета вещей Azure, Azure Key Vault и служба приложение Azure.

Компоненты

В примере архитектуры используются следующие компоненты:

Подробности сценария

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

Рекомендации и архитектура в этом примере содержат рекомендации по эффективному, безопасному и простому перемещению ресурсов Azure в разных регионах.

Потенциальные варианты использования

Ниже приведены некоторые из основных причин перемещения ресурсов в другой регион:

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

Шаги по перемещению ресурсов между регионами

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

  1. проверка предварительных требований для перемещения;

    • Запланированное время простоя. Планирование перемещения региона в качестве действия обслуживания с запланированным временем простоя, чтобы свести к минимуму влияние клиента.

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

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

    • Идентификация ресурсов. Определите и классифицируйте ресурсы на основе типа ресурса, необходимого для экспорта шаблона Azure Resource Manager (ARM) или запуска реплика tion с помощью различных технологий. Для каждого из типов ресурсов, которые требуется переместить, шаги могут отличаться. См. сведения о перемещении ресурсов Azure в разных регионах , чтобы определить соответствующие шаги для каждого типа ресурсов.

  2. Перемещение сетевых компонентов.

    • Группы безопасности сети: нельзя перемещать группы безопасности сети из одного региона в другой. Однако вы можете использовать шаблон ARM для экспорта существующих правил конфигурации и безопасности группы безопасности сети. Затем можно выполнить этап ресурса в другом регионе, экспортируя группу в шаблон, изменяя параметры в соответствии с целевым регионом, а затем развертывая шаблон в новом регионе.

    • виртуальная сеть. Вы можете использовать шаблон Azure Resource Manager для завершения перемещения виртуальной сети в другой регион. Экспортируйте виртуальную сеть в шаблон, измените параметры в соответствии с целевым регионом, а затем разверните шаблон в новом регионе.

    • Пиринг между виртуальными сетями: пиринг виртуальной сети не будет повторно создан, а одноранговые узлы виртуальной сети завершаются ошибкой, если они по-прежнему присутствуют в шаблоне. Перед экспортом шаблона удалите все одноранговые узлы виртуальной сети. Их можно восстановить после перемещения виртуальной сети.

    • Общедоступные IP-адреса. Так как общедоступные IP-адреса Azure относятся к регионам, их нельзя переместить из одного региона в другой. Однако вы можете использовать шаблон ARM для экспорта существующих правил конфигурации и безопасности группы безопасности сети. Затем можно выполнить этап ресурса в другом регионе, экспортируя группу в шаблон, изменяя параметры в соответствии с целевым регионом, а затем развертывая шаблон в новом регионе.

  3. Перемещение компонентов приложения.

  4. Перемещение служб PaaS: службы PaaS имеют собственные конкретные шаги для оркестрации перемещения. Сведения о списке поддерживаемых служб см. в статье "Поддержка перемещения ресурсов Azure в разных регионах".

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

Рекомендации

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

При переходе между регионами следует учитывать следующие моменты:

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

  • Переместите типы ресурсов вместе. Объединяя перемещение аналогичных типов ресурсов (например, 50 виртуальных машин или 20 баз данных SQL), можно спланировать этап подготовки перемещения и обеспечить выполнение длительных операций вместе, что помогает сократить время простоя.

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

  • Убедитесь, что вам потребуется емкость. Возможность проверить емкость или квоту доступна в целевом регионе для поддержки текущего и потенциального роста бизнеса до фактического перемещения.

  • При выполнении перемещения не должно быть минимального влияния на текущие критически важные для бизнеса приложения или инфраструктуру в исходном регионе.

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

  • Возможность проверить миграцию до окончательной фиксации на целевую сторону имеет решающее значение, особенно если вы поддерживаете рабочие нагрузки уровня 0, уровня 1 в отрасли финансовых услуг (FSI) или по вертикали здравоохранения.

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

  • После перемещения ресурсов в целевой объект убедитесь, что окончательная конфигурация выполняется и выполняется путем внесения окончательных изменений, таких как:

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

Следующие шаги