Перемещение ресурсов в новый регион — Управляемый экземпляр SQL Azure

  • Статья

Область применения: Управляемый экземпляр SQL Azure

В этой статье описывается универсальный рабочий процесс перемещения Управляемый экземпляр SQL Azure в новый регион.

Примечание.

Эта статья относится к миграции в общедоступном облаке Azure или в том же независимом облаке.

Обзор

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

Общий рабочий процесс для перемещения ресурсов в другой регион состоит из следующих шагов:

  1. проверка предварительных требований для перемещения;
  2. подготовка к перемещению ресурсов в области;
  3. мониторинг процесса подготовки;
  4. тестирование процесса перемещения;
  5. запуск процесса перемещения;
  6. удаление ресурсов из исходного региона.

проверка предварительных требований;

  1. Для каждого управляемого исходного экземпляра создайте экземпляр одного размера в целевом регионе.
  2. Настройте сеть для управляемого экземпляра. Дополнительную информацию см. в статье Конфигурация сети.
  3. Настройте целевую master базу данных с правильными именами входа. Если вы не администратор подписки и не администратор управляемого экземпляра SQL, свяжитесь с администратором, чтобы получить необходимые разрешения.
  4. Если базы данных зашифрованы с помощью прозрачного шифрования данных (TDE) и в Azure Key Vault используется собственный ключ шифрования (BYOK или ключ, управляемый клиентом), убедитесь в том, что в целевых регионах подготовлен правильный материал шифрования.
    • Самый простой способ сделать это — добавить ключ шифрования из существующего хранилища ключей (который используется в качестве средства защиты TDE в исходном экземпляре) в целевой экземпляр, а затем задать ключ в качестве предохранителя TDE в целевом экземпляре, так как экземпляр в одном регионе теперь может подключиться к хранилищу ключей в любом другом регионе.
    • Рекомендуется убедиться, что целевой экземпляр имеет доступ к старым ключам шифрования (требуется для восстановления резервных копий базы данных), выполните командлет Get-AzSqlServerKeyVaultKey на исходном экземпляре или командлет Get-AzSqlInstanceKeyVaultKey на исходном управляемом экземпляре, чтобы вернуть список доступных ключей и добавить эти ключи в целевой экземпляр.
    • Дополнительные сведения и рекомендации по настройке управляемого клиентом TDE в целевом экземпляре см. в статье Azure SQL прозрачное шифрование данных с помощью ключей, управляемых клиентом, в Azure Key Vault.
  5. Если аудит включен для управляемого экземпляра, убедитесь, что:
  6. Если для экземпляра настроена политика долгосрочного хранения (LTR), существующие резервные копии LTR будут по-прежнему связаны с текущим экземпляром. Поскольку целевой сервер отличается, вы сможете получить доступ к более ранним резервным копиям LTR в исходном регионе с помощью исходного экземпляра, даже если этот экземпляр удален.

Примечание.

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

Подготовка ресурсов

Создайте группу отработки отказа между каждым исходным управляемым экземпляром и соответствующим целевым управляемым экземпляром SQL.

Репликация всех баз данных на каждом экземпляре инициируется автоматически. Дополнительные сведения см. в разделе "Группы отработки отказа".

Мониторинг процесса подготовки

Вы можете периодически вызывать Get-AzSqlDatabaseInstanceFailoverGroup для отслеживания репликации баз данных из источника в целевой экземпляр. Выходной объект Get-AzSqlDatabaseInstanceFailoverGroup включает свойство для ReplicationState:

  • ReplicationState = CATCH_UP указывает, что база данных синхронизирована и может быть безопасно выполнена отработка отказа.
  • ReplicationState = SEEDING указывает, что база данных еще не заполняется, и попытка отработки отказа завершится ошибкой.

Тестирование синхронизации

После завершения репликации CATCH_UPподключитесь к гео-вторичной конечной точке с помощью вторичной конечной точки <fog-name>.secondary.<zone_id>.database.windows.net и выполните любой запрос к базам данных, чтобы обеспечить подключение, правильную конфигурацию безопасности и репликацию данных.

Начало перемещения

  1. Подключитесь к целевому управляемому экземпляру с помощью вторичной конечной точки <fog-name>.secondary.<zone_id>.database.windows.net.
  2. Используйте Switch-AzSqlDatabaseInstanceFailoverGroup , чтобы переключить вторичный управляемый экземпляр в качестве основного с полной синхронизацией. Эта операция завершается успешно или откатывается.
  3. Убедитесь, что команда выполнена успешно, с помощью nslook up <fog-name>.secondary.<zone_id>.database.windows.net. Так можно проверить, ссылается ли запись DNS CNAME на IP-адрес целевого региона. Если команда switch завершается ошибкой, CNAME не обновляется.

Удаление исходных управляемых экземпляров

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

  1. Удалите группу отработки отказа с помощью Remove-AzSqlDatabaseInstanceFailoverGroup. Это удаляет конфигурацию группы отработки отказа и завершает связи георепликации между двумя экземплярами.
  2. Удалите исходный управляемый экземпляр с помощью команды Remove-AzSqlInstance.
  3. Удалите все дополнительные ресурсы в группе ресурсов, например виртуальную сеть и группу безопасности.

Связанный контент