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

Применимо к:Управляемый экземпляр SQL Azure

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

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

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

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

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

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

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

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

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

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

В пользовательском интерфейсе Виртуальная сеть на портале Azure виртуальные сети, которые соответствуют необходимым требованиям для управляемого экземпляра, классифицируются как Ready for Managed Instance (Готова к управляемому экземпляру). Виртуальные сети с подсетями с управляемыми экземплярами, уже развернутыми на них, отображают значок Управляемый экземпляр SQL перед именем виртуальной сети. Пустые подсети, готовые к работе с управляемым экземпляром, отображают значок подсети виртуальной сети.

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

• Зона DNS экземпляров в конечной подсети должна соответствовать зоне DNS перемещаемого экземпляра. Это ограничение применяется, если планируется перейти в непустую подсеть.

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Портал

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

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

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

PowerShell

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

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

Для указания параметров используйте следующую команду 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 prepartion 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

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

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

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

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

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

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

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

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

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

• Сведения о создании первого управляемого экземпляра см. в этом руководстве по началу работы.
• Сведения о функциях и сравнительные таблицы см. в статье Сравнение функций: База данных SQL Azure и Управляемый экземпляр SQL Azure.
• Дополнительные сведения о конфигурации виртуальной сети см. в разделе Архитектура подключения к Управляемому экземпляру SQL Azure.
• Сведения о создании управляемого экземпляра и восстановлении базы данных из файла резервной копии см. в разделе Краткое руководство. Создание управляемого экземпляра Управляемого экземпляра SQL.
• Сведения о миграции с помощью Azure Database Migration Service см. в разделе Руководство. Миграция из SQL Server в Управляемый экземпляр базы данных SQL Azure в автономном режиме с помощью DMS.