Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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. Pendant le déplacement, SQL Managed Instance reste disponible, à l’exception d’un court temps d’arrêt lorsque le basculement se produit , généralement pendant 10 secondes, même si des transactions de longue durée 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.
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égation au
Microsoft.Sql/managedInstancesfournisseur 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 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 sansmpty.
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
dnsZonePartnerparamè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 avoir les mêmes règles de sécurité nécessaires 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 SQL (celle 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. 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 managé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, 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 que les données sont amorçagees ou que les fichiers de base de données sont attachés, le système se prépare au basculement. Lorsque tout est prêt, le système effectue un basculement avec un court temps d’arrêt, ce 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.
