Déplacer une instance Azure SQL Managed Instance entre des sous-réseaux

S’applique à :Azure SQL Managed Instance

Cet article explique comment déplacer Azure SQL Managed Instance d’un sous-réseau vers un autre sous-réseau dans le même réseau virtuel ou un autre réseau virtuel. L’opération est similaire à la mise à l’échelle de vCores ou à la modification du niveau de service d’instance. Durant le déplacement, SQL Managed Instance reste disponible, à l’exception d’une brève interruption lors du basculement, qui dure généralement jusqu’à 10 secondes, même si des transactions longues sont interrompues.

Le déplacement de l’instance vers un autre sous-réseau déclenche les opérations de cluster virtuel suivantes :

Le cluster virtuel génère ou redimensionne l’infrastructure sous-jacente dans le sous-réseau de destination.
Le cluster virtuel est supprimé ou défragmenté dans le sous-réseau source.

Exigences et limitations

Vous devez déployer SQL Managed Instance à l’intérieur d’un sous-réseau dédié au sein d’un réseau virtuel Azure. La taille du sous-réseau (plage de sous-réseaux) détermine le nombre d’instances managées SQL que vous pouvez déployer dans le sous-réseau. Pour déployer une instance managée SQL ou la déplacer vers un autre sous-réseau, le sous-réseau de destination doit répondre à certaines exigences réseau.

Avant de migrer votre instance vers un autre sous-réseau, vous devez vous familiariser avec les concepts suivants :

Déterminez la taille et la plage nécessaires du sous-réseau pour Azure SQL Managed Instance.
Choisissez entre déplacer l’instance vers un nouveau sous-réseau ou utiliser un sous-réseau existant.
Utilisez les opérations de gestion pour déployer automatiquement les nouvelles instances managées, mettre à jour les propriétés d’instance ou supprimer des instances. Vous pouvez surveiller ces opérations de gestion.

Avant d’initier le déplacement du sous-réseau, vérifiez que la connectivité est autorisée entre les sous-réseaux source et destination sur les ports 5022 et 11000-11999. Cette vérification inclut la validation de l’ensemble du chemin réseau et la garantie que les routes définies par l’utilisateur, les appliances virtuelles réseau (NVA), les pare-feux ou autres dispositifs réseau ne bloquent pas le trafic sur ces ports.

Préparation du sous-réseau

Avant de déplacer votre instance managée SQL, vérifiez que le sous-réseau est marqué comme Prêt pour Managed Instance.

Dans l’interface utilisateur du réseau virtuel du portail Azure, les réseaux virtuels qui répondent aux conditions préalables d’une instance managée SQL sont classés comme Prêts pour Managed Instance. Les réseaux virtuels qui ont des sous-réseaux avec des instances managées SQL déjà déployées pour eux affichent une icône SQL Managed Instance avant le nom du réseau virtuel. Les sous-réseaux vides prêts pour une instance managée SQL affichent une icône de sous-réseau de réseau virtuel.

Les sous-réseaux marqués comme non prêts ne remplissent pas toutes les conditions requises pour le déploiement SQL Managed Instance. Pour savoir pourquoi le sous-réseau n’est pas prêt et si le sous-réseau peut répondre aux exigences réseau, utilisez l’icône d’informations à droite du nom du sous-réseau. Ces conditions requises incluent :

déléguer à Microsoft.Sql/managedInstances un fournisseur de ressources
attachement d’une table de routage
attachement d’un groupe de sécurité réseau

Si le sous-réseau fait partie d’un autre réseau virtuel, vous avez besoin des éléments suivants :

Peering bidirectionnel entre le réseau virtuel actuel et le réseau virtuel de destination.
Les sous-réseaux actuels et de destination utilisent des tables de routage et des groupes de sécurité réseau distincts.

Une fois ces exigences remplies, le sous-réseau passe de la catégorie Non prêt à la catégorie Prêt pour Managed Instance afin qu'il puisse être utilisé pour une instance SQL managée.

Les sous-réseaux déjà utilisés (les sous-réseaux utilisés pour les déploiements d’instances ne peuvent pas contenir d’autres ressources), ou les sous-réseaux qui ont une autre zone DNS (une limitation de déplacement d’instance inter-sous-réseaux), font toujours partie de la catégorie Non prête .

En fonction de la désignation et de l'état du sous-réseau, les ajustements suivants peuvent être apportés au sous-réseau de destination :

Prêt pour Managed Instance (contient une instance managée SQL existante)

Aucun ajustement n’est effectué. Ces sous-réseaux contiennent déjà des instances managées SQL, et toute modification apportée au sous-réseau peut affecter les instances existantes.
Prêt pour Instance Gérée (vide)

Le flux de travail valide toutes les règles requises dans le groupe de sécurité réseau et la table de routage, et ajoute toutes les règles nécessaires mais manquantes. Les règles personnalisées que vous ajoutez à la configuration du sous-réseau source ne sont pas copiées dans le sous-réseau de destination. Vous devez répliquer manuellement toute personnalisation de la configuration du sous-réseau source sur le sous-réseau de destination. Une façon d’effectuer cette réplication consiste à utiliser la même table de routage et le même groupe de sécurité réseau pour le sous-réseau source et de destination.

Limitations concernant le sous-réseau de destination

Tenez compte des limitations suivantes lorsque vous choisissez un sous-réseau de destination pour une instance existante :

Vous pouvez déplacer SQL Managed Instance vers un sous-réseau qui est :
- Dans le même réseau virtuel que celui actuellement utilisé, ou
- Dans un réseau VNet appairé, si vous passez à un sous-réseau dans un autre réseau VNet.
La zone DNS des instances du sous-réseau de destination doit correspondre à la zone DNS de l’instance déplacée. Cette limitation s’applique si vous envisagez de passer à un sous-réseau non vide.

Vous pouvez spécialement préparer le sous-réseau de destination pour conserver la zone DNS de l’instance managée SQL que vous déplacez. Préparez le sous-réseau en créant une instance managée SQL dans un sous-réseau vide et en fournissant le dnsZonePartner paramètre dans la demande de création. Ce paramètre en tant que valeur accepte l’ID de SQL Managed Instance. Dans ce cas, vous pouvez utiliser l’instance qui sera déplacée ultérieurement vers le nouveau sous-réseau.

Outre cette approche, il n’existe aucun autre moyen de dicter la zone DNS de SQL Managed Instance, car elle est générée de façon aléatoire. Actuellement, il n’existe aucun moyen de mettre à jour la zone DNS d’une instance managée SQL existante.

Si vous souhaitez migrer une instance managée SQL avec un groupe de basculement, les prérequis suivants s’appliquent :

Le sous-réseau cible doit permettre le même trafic de réplication requis pour le groupe de basculement que le sous-réseau source :

Ouvrez les ports entrants et sortants 5022 ainsi que la plage 11000-11999 dans le groupe de sécurité réseau (NSG) pour les connexions provenant de l’autre sous-réseau de l’instance gérée SQL (celui qui héberge le réplica du groupe de basculement), afin d’autoriser le trafic de réplication entre les deux instances. Assurez-vous que le chemin réseau complet permet également ce trafic. Une route définie par l’utilisateur, un appliance virtuel réseau, un pare-feu ou un autre dispositif intermédiaire peut toujours bloquer les ports même lorsque les règles NSG sont correctes.
Le sous-réseau cible ne peut pas avoir une plage d’adresses se chevauchant avec celle du sous-réseau dans lequel se trouve la réplique d’instance secondaire du groupe de basculement.

Par exemple, si MI1 se trouve sur le sous-réseau S1, l’instance secondaire dans le groupe de basculement est MI2 sur le sous-réseau S2. Vous souhaitez déplacer MI1 vers le sous-réseau S3. Le sous-réseau S3 ne peut pas avoir une plage d’adresses qui chevauche celle du sous-réseau S2.

Pour en savoir plus sur la configuration du réseau pour les groupes de basculement, consultez Activer la géoréplication entre les instances gérées SQL..

Étapes de l’opération

Le déplacement d’une instance d’un sous-réseau vers un autre implique de nombreuses étapes. Selon la configuration de votre instance managée SQL, l’opération de déplacement peut prendre entre 30 minutes et 6 heures.

Le tableau suivant détaille les étapes de l’opération qui se produisent pendant l’opération de déplacement d’instance :

Nom de l’étape	Description de l’étape
Validation des demandes	Valide les paramètres envoyés. En cas de détection d’erreurs de configuration, l’opération échoue avec une erreur.
Redimensionnement ou création d’un cluster virtuel	Selon l’état du sous-réseau de destination, le cluster virtuel est créé ou redimensionné.
Démarrage d’une nouvelle instance	Le processus SQL démarre sur le cluster virtuel déployé dans le sous-réseau de destination.
Amorçage de fichiers de base de données ou attachement de fichiers de base de données	Selon le niveau de service, soit la base de données est initialisée, soit les fichiers de la base de données sont rattachés.
Préparation du basculement et basculement	Après l’amorçage des données ou la réassociation des fichiers de base de données, le système se prépare au basculement. Lorsque tout est prêt, le système effectue un basculement avec un bref temps d’arrêt, qui est généralement inférieur à 10 secondes.
Nettoyage de l’ancienne instance SQL	Supprime l’ancien processus SQL du cluster virtuel source.
Suppression de cluster virtuel	S’il s’agit de la dernière instance au sein du sous-réseau source, l’étape finale supprime le cluster virtuel de façon synchrone. Dans le cas contraire, le cluster virtuel est défragmenté de façon asynchrone.

Pour obtenir une explication détaillée des étapes de l’opération, consultez Durée des opérations de gestion dans Azure SQL Managed Instance.

Déplacer l’instance

Un déplacement d’instance entre sous-réseaux fait partie de l’opération de mise à jour d’instance. L’API de mise à jour d’instance existante, Azure PowerShell et les commandes Azure CLI sont améliorées avec une propriété d’ID de sous-réseau.

Dans le portail Azure, utilisez le champ de sous-réseau du volet Réseau pour déplacer l’instance vers le sous-réseau de destination. Lorsque vous utilisez Azure PowerShell ou Azure CLI, fournissez un ID de sous-réseau différent dans la commande de mise à jour pour déplacer l’instance d’un sous-réseau existant vers le sous-réseau de destination.

Pour obtenir une référence complète des commandes de gestion d’instance, consultez la référence de l’API managée pour Azure SQL Managed Instance.

Vous pouvez choisir le sous-réseau d’instance dans le volet Mise en réseau du portail Azure. Une fois que vous avez sélectionné un sous-réseau et enregistré vos modifications, l’opération de déplacement d’instance démarre.

L’opération de déplacement prépare d’abord le sous-réseau de destination pour le déploiement, ce qui peut prendre plusieurs minutes. Une fois le sous-réseau prêt, l’opération de gestion du déplacement d’instance démarre et apparaît dans le portail Azure.

Vous pouvez surveiller les opérations de déplacement d’instance à partir du volet Vue d’ensemble du portail Azure. Sélectionnez la notification pour ouvrir un autre volet qui contient des informations sur l’étape actuelle, le total des étapes et un bouton pour annuler l’opération.

Utilisez la commande Azure PowerShell Set-AzSqlInstance pour déplacer une instance après avoir créé votre sous-réseau dans le même réseau virtuel que votre sous-réseau de destination. Pour utiliser un sous-réseau existant, indiquez ce nom de sous-réseau dans la commande PowerShell.

L’exemple de commandes PowerShell de cette section prépare le sous-réseau de destination pour le déploiement d’instances et déplace l’instance managée SQL.

Utilisez la commande PowerShell suivante pour spécifier vos paramètres :

### 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'

Ignorez cette commande si des instances sont déjà déployées sur votre sous-réseau. Si vous utilisez un nouveau sous-réseau, utilisez la commande Azure PowerShell suivante pour le préparer :

### 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

Remarque

Pour en savoir plus sur le script qui prépare le sous-réseau, consultez Configurer un réseau virtuel existant pour Azure SQL Managed Instance.

La commande Azure PowerShell suivante déplace l’instance vers le sous-réseau source :

### 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"

La commande Azure PowerShell suivante déplace l’instance et fournit également un moyen de superviser la progression :

### 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

Utilisez la commande Azure CLI az sql mi update pour déplacer votre instance vers un autre sous-réseau.

Indiquez la destination en spécifiant l’ID de sous-réseau en tant que propriété --subnet ou le nom du réseau virtuel en tant que propriété --vnet-name et le nom du sous-réseau en tant que propriété --subnet.

L’exemple suivant déplace l’instance managée SQL vers un autre sous-réseau en spécifiant l’ID de sous-réseau :

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

L’exemple suivant déplace l’instance managée SQL vers un autre sous-réseau en spécifiant le nom du réseau virtuel et le nom du sous-réseau :

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

Utilisez la commande suivante pour superviser la progression de l’opération de gestion :

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

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-08-20