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

S’applique à : Azure SQL Managed Instance

Cet article vous enseigne comment déplacer Azure SQL Managed Instance d’un sous-réseau à un autre (au sein ou non du même VNet), de la même façon que vous mettez à l’échelle des vCores ou modifiez le niveau de service de l’instance. SQL Managed Instance est disponible pendant le déplacement, sauf pendant un temps d’arrêt réduit dû à un basculement à la fin de la mise à jour, généralement d’une durée maximale de 10 secondes, même si les 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 va développer 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

SQL Managed Instance doit être déployé dans un sous-réseau dédié au sein d’un réseau virtuel Azure. Le nombre d’instances managées pouvant être déployées dans le sous-réseau dépend de la taille du sous-réseau (plage de sous-réseau). Pour déployer une instance managée ou la déplacer vers un autre sous-réseau, le sous-réseau de destination doit présenter une certaine configuration requise pour le 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. Il est possible de superviser ces opérations de gestion.

Préparation du sous-réseau

Avant de déplacer votre instance managée, 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 remplissent les prérequis pour une instance managée sont classés comme étant prêts pour Managed Instance. Les réseaux virtuels qui ont des sous-réseaux avec des instances managées 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 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. Utilisez l’icône d’informations à droite du nom du sous-réseau pour savoir pourquoi le sous-réseau n’est pas prêt et si le sous-réseau peut répondre à la configuration réseau requise. Ces conditions requises incluent :

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

Dans le cas où le sous-réseau fait partie d’un autre réseau virtuel, une exigence supplémentaire concerne le

• 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 que toutes les conditions requises sont satisfaites, le sous-réseau passe de la catégorie Non prêt à la catégorie Prêt pour Managed Instance et peut être utilisé pour une instance managée.

Le sous-réseau déjà utilisé (les sous-réseaux utilisés pour les déploiements d’instances ne peuvent pas contenir d’autres ressources) ou le sous-réseau a une autre zone DNS (limitation du déplacement d’instance entre sous-réseaux) font toujours partie de la catégorie Non prêt.

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 SQL Managed Instance existante) : aucun ajustement n’est effectué. Ces sous-réseaux contiennent déjà des instances managées et toute modification apportée au sous-réseau peut avoir un impact sur les instances existantes.
• Prêt pour Managed Instance (vide) : le workflow 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. ¹

Notes

¹ Les règles personnalisées ajoutées à la configuration du sous-réseau source ne sont pas copiées sur le sous-réseau de destination. Toute personnalisation de la configuration du sous-réseau source doit être répliquée manuellement sur le sous-réseau de destination. Une façon d’y parvenir consiste à utiliser la même table de routage et le même groupe de sécurité réseau pour les sous-réseaux 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 :

• Le service SQL Managed Instance peut être déplacé vers le sous-réseau qui est :

  • Dans le même réseau virtuel que celui actuellement utilisé,
  • Dans un réseau virtuel appairé, si vous passez à un sous-réseau dans un autre réseau virtuel.

• 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 préparer le sous-réseau de destination pour conserver la zone DNS de l’instance SQL Managed Instance qui est déplacée. La préparation peut être effectuée en créant une instance SQL Managed Instance dans un sous-réseau vide et en fournissant le paramètre dnsZonePartner dans la demande de création. Ce paramètre en tant que valeur accepte l’ID d’instance SQL Managed Instance et, dans ce cas, vous pouvez utiliser l’instance qui sera déplacée ultérieurement vers le nouveau sous-réseau¹.

Notes

¹ En dehors de cette approche, il n’existe aucun autre moyen de dicter la zone DNS de l’instance SQL Managed Instance, car elle est générée de manière aléatoire. Il n’existe pas non plus actuellement de moyen de mettre à jour la zone DNS d’une instance SQL Managed Instance existante.

• Si vous souhaitez migrer une SQL Managed Instance avec un groupe de basculement, les prérequis suivants s’appliquent :
  • Le sous-réseau cible doit avoir besoin des mêmes règles de sécurité pour la réplication de groupe de basculement que le sous-réseau source : ouvrez les ports entrants et sortants 5022 et la plage 11000 à 11999 dans le groupe de sécurité réseau (NSG) pour les connexions à partir de l’autre sous-réseau d’instance managée (qui contient le réplica de groupe de basculement) pour autoriser le trafic de réplication entre les deux instances.
  • Le sous-réseau cible ne peut pas avoir une plage d’adresses qui présente un chevauchement avec le sous-réseau contenant le réplica 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. Nous voulons 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 managées.

Étapes de l’opération

Le déplacement d’une instance d’un sous-réseau vers un autre implique un certain nombre d’étapes et, selon la configuration de votre SQL Managed Instance, peut prendre de 30 minutes à 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 / création de 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 des fichiers de base de données / attachement de fichiers de base de données	Selon le niveau de service, la base de données est amorcée ou les fichiers de base de données sont attachés.
Préparation du basculement et basculement	Une fois les données amorcées ou les fichiers de base de données réattachés, le système se prépare au basculement. Lorsque tout est prêt, le système effectue un basculement avec un temps d’arrêt réduit, 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.

Une explication détaillée des étapes de l’opération est disponible dans la vue d’ensemble des opérations de gestion 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. Les commandes d’API de mise à jour d’instance, Azure PowerShell et Azure CLI existantes ont été 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 Informations de référence sur l’API de gestion pour Azure SQL Managed Instance.

Portail

L’option permettant de choisir le sous-réseau d’instance se trouve dans le volet Réseau du portail Azure. L’opération de déplacement d’instance démarre lorsque vous sélectionnez un sous-réseau et enregistrez vos modifications.

La première étape de l'opération de déplacement consiste à préparer le sous-réseau de destination au déploiement, ce qui peut prendre plusieurs minutes. Une fois que le sous-réseau est prêt, l’opération de gestion du déplacement d’instance démarre et devient visible dans le portail Azure.

Supervisez les opérations de déplacement d’instance à partir du volet Vue d'ensemble du portail Azure. Sélectionnez la notification pour ouvrir un volet supplémentaire contenant des informations sur l'étape en cours, le nombre total d'étapes et un bouton permettant d'annuler l'opération.

PowerShell

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. Si vous souhaitez utiliser un sous-réseau existant, indiquez le nom de ce sous-réseau dans la commande PowerShell.

Les exemples de commandes PowerShell de cette section préparent le sous-réseau de destination pour le déploiement de l’instance et déplacent l’instance managée.

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 prepartion script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Notes

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

Azure CLI

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

Étapes suivantes

• Pour savoir comment créer votre première instance managée, consultez le Guide de démarrage rapide.
• Pour accéder à la liste des fonctionnalités et à leur comparaison, consultez Fonctionnalités SQL courantes.
• Pour plus d’informations sur la configuration du réseau virtuel, consultez Configuration de réseau virtuel SQL Managed Instance.
• Pour obtenir un guide de démarrage rapide qui crée une instance managée et restaure une base de données à partir d’un fichier de sauvegarde, consultez Créer une instance managée.
• Pour accéder à un tutoriel expliquant comment utiliser Azure Database Migration Service pour la migration, consultez Migration SQL Managed Instance à l’aide d’Azure Database Migration Service.