Поделиться через


Перенос облачной рабочей нагрузки в другой регион

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

Diagram showing the relocation process and highlights the Migrate step in the Move phase. In the relocation process, there are two phases and five steps. The first phase is the Initiate phase, and it has one step called Initiate. The second phase is the Move phase, and it has four steps that you repeat for each workload. The steps are Evaluate, Select, Migrate, and Cutover.

Подготовить

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

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

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

При необходимости создайте новые подписки. Создайте только новые подписки, если необходимо реструктурировать службы и ресурсы. Попробуйте сохранить рабочую нагрузку в существующей подписке, если это возможно, так как создание новой подписки повышает сложность. Подписки служат границами для бюджетов, политик и управления доступом на основе ролей (RBACs). Для любой новой подписки необходимо проверить бюджеты, политики и RBAC. Если вы не перемещаете все ресурсы в подписке, вам нужно область политики идентификации и безопасности для сопоставления меньшей группировки ресурсов. Чтобы создать новую подписку, необходимо создать, область и реализовать необходимые политики Azure и роли RBAC в целевой подписке. Цель заключается в поддержании системы управления и безопасности.

При необходимости настройте новое доменное имя. При изменении личного домена рабочей нагрузки необходимо настроить новое доменное имя. Создайте новое имя узла, назначьте его приложению или службе, а затем проверьте разрешение имен. Вы также можете запланировать снижение и настройку времени жизни (TTL) и установить его на этапе переключение для автоматического истечения срока действия. Дополнительные сведения см. в разделе "Добавление личного домена" и "Сопоставление DNS-имени" с планом Служба приложений.

При необходимости создайте сертификаты SSL/TLS. Для любого нового доменного имени необходимо создать сертификаты SSL/TLS (X.509). Эти сертификаты обеспечивают шифрование открытого закрытого ключа и безопасное сетевое взаимодействие (HTTPS). Используйте Azure Key Vault для создания или импорта сертификатов X.509. Дополнительные сведения см. в разделе "Сертификаты Azure Key Vault" и методы создания сертификатов

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

Создайте новую рабочую область Log Analytics. Для каждого региона должна быть отдельная рабочая область Log Analytics. Создайте рабочую область в целевом регионе. Так как не удается переместить рабочую область Log Analytics в другой регион, необходимо создать новую рабочую область Log Analytics в целевом регионе. Существует два варианта сохранения данных в исходной рабочей области. Текущую рабочую область можно сохранить до тех пор, пока данные не потребуются, рассматривая данные как доступные только для чтения. Вы также можете экспортировать данные рабочей области в учетную запись хранения в новом целевом регионе Azure.

Перенос служб

Вы можете начать перенос служб в рабочей нагрузке. Для выполнения выполните доступные рекомендации по выбранной вами автоматизации перемещения. Azure Resource Mover и Azure Site Recovery содержат пошаговые руководства по перемещению службы. Дополнительные сведения см. в разделе:

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

Перенос данных

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

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

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

  3. Разрешение конфликтов синхронизации. Убедитесь, что данные в исходном и целевом расположении синхронизированы и разрешают все конфликты данных. Вы хотите, чтобы пользователи пытались получить доступ к данным, доступным. Например, Azure Cosmos DB может сериализовать параллельные операции записи, чтобы обеспечить согласованность данных.

Обновление строк подключения

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

Управляемые удостоверения

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

С другой стороны, назначаемое пользователем управляемое удостоверение имеет независимый жизненный цикл, и вы можете сопоставить управляемое удостоверение, назначаемое пользователем, с новым ресурсом в целевом регионе. Дополнительные сведения см. в обзоре управляемого удостоверения.

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

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