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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После выполнения этих требований подсеть переходит из категории Not ready в категорию Готово для управляемого экземпляра и может использоваться для управляемого экземпляра SQL.

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

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

Готово для управляемого экземпляра (содержит существующий управляемый экземпляр SQL)

Никакие корректировки не выполняются. Эти подсети уже содержат управляемые экземпляры SQL, а любые изменения в подсети могут повлиять на существующие экземпляры.
Готово для управляемого экземпляра (пустой)

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

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

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

Управляемый экземпляр 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 для Управляемого экземпляра SQL Azure.

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

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

Вы можете отслеживать операции перемещения экземпляров на панели обзора портала 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((Invoke-WebRequest ($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-12-12