Перемещение управляемого экземпляра Azure SQL в другую подсеть

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

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

При перемещении экземпляра в другую подсеть запускаются следующие операции виртуального кластера:

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

Требования и ограничения

Управляемый экземпляр SQL необходимо развернуть в выделенной подсети в виртуальной сети Azure. Количество управляемых экземпляров SQL, которые можно развернуть в подсети, зависит от размера подсети (диапазона подсети). Чтобы развернуть управляемый экземпляр SQL или переместить его в другую подсеть, целевая подсеть должна иметь определенные требования к сети.

Перед перемещением экземпляра в другую подсеть ознакомьтесь со следующими понятиями:

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

Готовность подсети

Перед перемещением управляемого экземпляра SQL убедитесь, что подсеть помечается как готовая для управляемого экземпляра.

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

Подсети, помеченные как не готовые, не соответствуют всем требованиям для развертывания Управляемый экземпляр SQL. Используйте значок сведений справа от имени подсети, чтобы узнать, почему подсеть не готова, и если подсеть может соответствовать требованиям к сети. К этим требованиям относятся:

делегирование поставщику Microsoft.Sql/managedInstances ресурсов
подключение таблицы маршрутов;
подключение группы безопасности сети.

В случае, если подсеть является частью другой виртуальной сети, дополнительные требования:

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

После удовлетворения всех требований подсеть переходит из категории "Не готоводля управляемого экземпляра " и может использоваться для управляемого экземпляра SQL.

Подсети, которые уже используются (подсети, используемые для развертываний экземпляров, не могут содержать другие ресурсы), или подсети, имеющие другую зону DNS (ограничение перемещения экземпляра между подсетями), всегда являются частью категории "Не готово ".

Снимок экрана: параметры Управляемый экземпляр SQL Azure подсети.

В зависимости от состояния и обозначения подсети можно внести следующие изменения в целевую подсеть:

Ready for Managed Instance (содержит существующий управляемый экземпляр SQL) — изменения вносить нельзя. Эти подсети уже содержат управляемые экземпляры SQL, а любые изменения в подсети могут повлиять на существующие экземпляры.
Ready for Managed Instance (пустая) — рабочий процесс проверяет все необходимые правила в группе безопасности сети и таблице маршрутов и добавляет все необходимые, но отсутствующие правила. ¹

Примечание.

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

Ограничения на целевую подсеть

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

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

Примечание.

¹ Помимо этого подхода нет другого способа диктовать зону DNS управляемого экземпляра SQL, так как она создается случайным образом. Там также, по состоянию на данный момент, не существует способа обновить зону DNS существующего Управляемый экземпляр SQL.

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

Целевая подсеть должна иметь те же правила безопасности, необходимые для репликации группы отработки отказа, что и исходная подсеть:
- Откройте как входящие, так и исходящие порты 5022 и диапазон 11000~11999 в группе безопасности сети (NSG) для подключений из другой подсети управляемого экземпляра SQL (которая содержит реплика группы отработки отказа), чтобы разрешить трафик репликации между двумя экземплярами.
Целевая подсеть не может иметь перекрывающийся диапазон адресов с подсетью, содержащей реплику вторичного экземпляра группы отработки отказа.
- Например, если MI1 находится в подсети S1, вторичный экземпляр в группе отработки отказа — MI2 в подсети S2. Мы хотим переместить MI1 в подсеть S3. Подсеть S3 не может иметь перекрывающийся диапазон адресов с подсетью S2.

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

Шаги операции

Перемещение экземпляра из одной подсети в другую включает множество шагов и в зависимости от того, как настроен управляемый экземпляр SQL, может занять от 30 минут до 6 часов.

В таблице ниже описаны шаги, необходимые для перемещения экземпляра.

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

Подробное описание шагов операции можно найти в обзоре операций управления управляемым экземпляром SQL Azure.

Перемещение экземпляра

Перемещение экземпляра между подсетями является частью операции обновления экземпляра. Существующие команды обновления экземпляров, Azure PowerShell и Azure CLI дополняются свойством идентификатора подсети.

В портал Azure используйте поле подсети на панели "Сеть" для перемещения экземпляра в целевую подсеть. При использовании Azure PowerShell или Azure CLI укажите идентификатор другой подсети в команде обновления, чтобы переместить экземпляр из существующей подсети в целевую.

Полный справочник по командам управления экземплярами см. в справочнике по API управления для Управляемого экземпляра Azure SQL.

Параметр выбора подсети экземпляра находится на панели "Сеть" портал Azure. Операция перемещения экземпляра начнется, когда вы выбираете подсеть и сохраните изменения.

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

Выбор подсети в области Управляемый экземпляр SQL сети

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

Используйте команду Azure PowerShell Set-AzSqlInstance для перемещения экземпляра после создания подсети в той же виртуальной сети, в которой находится целевая подсеть. Если вы хотите использовать существующую подсеть, укажите ее имя в команде PowerShell.

Примеры команд PowerShell в этом разделе подготавливают целевую подсеть для развертывания экземпляра и перемещают управляемый экземпляр SQL.

Для указания параметров используйте следующую команду PowerShell:

### PART 1 - DEFINE PARAMETERS

#Generating basic parameters
$currentSubscriptionID = 'subscription-id'
$sqlMIResourceGroupName = 'resource-group-name-of-sql-mi'
$sqlMIName = 'sql-mi-name'
$sqlMIResourceVnetName = 'vnet-name-of-sql-mi'
$destinationSubnetName = 'name-of-the-destination-subnet-for-sql-mi'

Пропустите эту команду, если в вашей подсети уже развернуты экземпляры. Если вы используете новую подсеть, используйте следующую команду Azure PowerShell для подготовки подсети:

### PART 2 - PREPARE DESTINATION SUBNET

#Loading the url of script used for preparing the subnet for SQL MI deployment
$scriptUrlBase = 'https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/manage/azure-sql-db-managed-instance/delegate-subnet'

#Generating destination subnet parameters
$parameters = @{
    subscriptionId = $currentSubscriptionID
    resourceGroupName = $sqlMIResourceGroupName
    virtualNetworkName = $sqlMIResourceVnetName
    subnetName = $destinationSubnetName
}

#Initiating subnet preparation script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Примечание.

Дополнительные сведения о сценарии для подготовки подсети см. в статье Настройка существующей виртуальной сети для управляемого экземпляра Azure SQL Azure.

Следующая команда Azure PowerShell перемещает экземпляр в исходную подсеть:

### PART 3 - MOVE INSTANCE TO THE NEW SUBNET

Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName"

Следующая Azure PowerShell перемещает экземпляр, а также позволяет отслеживать ход выполнения:

### PART 3 EXTENDED - MOVE INSTANCE AND MONITOR PROGRESS

# Extend the Set-AzSqlInstance command with -AsJob -Force parameters to be able to monitor the progress or proceed with script execution as moving the instance to another subnet is long running operation
Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName" -AsJob -Force

$operationProgress = Get-AzSqlInstanceOperation -ManagedInstanceName $sqlMIName -ResourceGroupName $sqlMIResourceGroupName
#checking the operation step status
Write-Host "Checking the ongoing step" -ForegroundColor Yellow
$operationProgress.OperationSteps.StepsList

Для перемещения экземпляра в другую подсеть используйте команду Azure CLI az sql mi update.

Укажите назначение, предоставив идентификатор подсети в свойстве --subnet или имя виртуальной сети в свойстве --vnet-name, а имя подсети — в свойстве --subnet.

В следующем примере управляемый экземпляр SQL перемещается в другую подсеть, указав идентификатор подсети:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --subnet /subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetworkName/subnets/destinationSubnetName

В следующем примере управляемый экземпляр SQL перемещается в другую подсеть, указав имя виртуальной сети и имя подсети:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --vnet-name myVirtualNetworkName --subnet destinationSubnetName

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

az sql mi op list -g myResourceGroup --mi mySqlManagedInstance

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-08-26

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

Перемещение управляемого экземпляра Azure SQL в другую подсеть

Требования и ограничения

Готовность подсети

Ограничения на целевую подсеть

Шаги операции

Перемещение экземпляра

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

Обратная связь

Дополнительные ресурсы