Partager via

Déplacer des ressources vers une nouvelle région – Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Cet article vous présente un flux de travail générique pour déplacer Azure SQL Managed Instance vers une nouvelle région.

Remarque

Cet article s’applique aux migrations dans le cloud public Azure ou dans le même cloud souverain.

Vue d’ensemble

Il existe différents scénarios dans lesquels vous pourriez souhaiter déplacer votre instance gérée existantes d’une région à une autre. Par exemple, vous étendez vos activités à une nouvelle région et souhaitez les optimiser pour la nouvelle base de clients. Ou vous avez besoin de déplacer les opérations vers une autre région pour des raisons de conformité. Ou encore, Azure a publié une nouvelle région qui offre une meilleure proximité et améliore l’expérience client.

Le flux de travail général pour déplacer des ressources vers une autre région se compose des étapes suivantes :

  1. Vérifiez les prérequis pour le déplacement
  2. Préparez le déplacement des ressources dans l’étendue.
  3. Analysez le processus de préparation.
  4. Testez le processus de déplacement.
  5. Initiez le déplacement.
  6. Supprimez les ressources de la région source.

Vérification des conditions préalables requises

  1. Pour chaque instance managée source, créez une instance de la même taille dans la région cible.
  2. Configurez le réseau pour une instance managée. Pour plus d’informations, consultez Configuration réseau.
  3. Configurez la base de données master cible avec les connexions appropriées. Si vous n’êtes pas l’administrateur de l’abonnement ou de SQL Managed Instance, collaborez avec l’administrateur pour attribuer les autorisations dont vous avez besoin.
  4. Si vos bases de données sont chiffrées avec TDE (Transparent Data Encryption) et que vous utilisez votre propre clé de chiffrement (BYOK ou clé gérée par le client) dans Azure Key Vault, vérifiez que le matériel de chiffrement correct est provisionné dans les régions cibles.
    • La méthode la plus simple consiste à ajouter la clé de chiffrement du coffre de clés existant (utilisée comme protecteur TDE sur l’instance source) à l’instance cible, puis à définir la clé comme protecteur TDE sur l'instance cible, puisqu'une instance dans une région peut désormais se connecter à un coffre-fort de clés dans n'importe quelle autre région.
    • Pour vérifier que l’instance cible a accès aux anciennes clés de chiffrement (nécessaires pour la restauration des sauvegardes de base de données), une bonne pratique consiste à exécuter l’applet de commande Get-AzSqlServerKeyVaultKey sur l’instance source ou Get-AzSqlInstanceKeyVaultKey sur l’instance managée source pour retourner la liste des clés disponibles et ajouter ces clés à l’instance cible.
    • Pour plus d’informations et pour connaître les bonnes pratiques relatives à la configuration du chiffrement TDE géré par le client sur l’instance cible, consultez Azure SQL Transparent Data Encryption avec des clés gérées par le client dans Azure Key Vault.
  5. Si l’audit est activé pour l’instance gérée (Managed Instance), vérifiez que :
    • Le conteneur de stockage ou le hub d’événements avec les journaux existants est déplacé vers la région cible.
    • L’audit est configuré sur l’instance cible. Pour plus d’informations, consultez Audit avec une instance SQL Managed Instance.
  6. Si votre instance a une stratégie de conservation à long terme (LTR), les sauvegardes LTR existantes resteront associées à l’instance actuelle. L’instance cible étant différente, vous pourrez accéder aux sauvegardes LTR plus anciennes dans la région source à l’aide de l’instance source, même si l’instance est supprimée.

Remarque

La migration d’instances avec des sauvegardes LTR existantes entre les régions souveraines et publiques n’est pas prise en charge, car cela nécessite le déplacement de sauvegardes LTR vers l’instance cible, ce qui n’est pas possible actuellement.

Préparer les ressources

Créez un groupe de basculement entre chaque instance gérée source et l’instance gérée cible correspondante de SQL Managed Instance.

La réplication de toutes les bases de données sur chaque instance est lancée automatiquement. Pour plus d’informations, consultez Groupes de basculement.

Superviser le processus de préparation

Vous pouvez appeler régulièrement Get-AzSqlDatabaseInstanceFailoverGroup pour superviser la réplication de vos bases de données de la source vers l’instance cible. L’objet de sortie de Get-AzSqlDatabaseInstanceFailoverGroup comprend une propriété pour Get-AzSqlDatabaseInstanceFailoverGroup :

  • ReplicationState = CATCH_UP indique que la base de données est synchronisée et peut être basculée en toute sécurité.
  • ReplicationState = SEEDING indique que la base de données n’a pas encore essaimé et qu’une tentative de basculement échouera.

Tester la synchronisation

Une fois que ReplicationState a la valeur CATCH_UP, connectez-vous à la base de données géosecondaire à l’aide du point de terminaison secondaire <fog-name>.secondary.<zone_id>.database.windows.net, puis exécutez une requête sur les bases de données pour vérifier la connectivité, la configuration de sécurité et la réplication des données.

Lancer le déplacement

  1. Connectez-vous à l’instance gérée cible à l’aide du point de terminaison secondaire <fog-name>.secondary.<zone_id>.database.windows.net.
  2. Utilisez Switch-AzSqlDatabaseInstanceFailoverGroup pour faire de l’instance managée (Managed Instance) secondaire la base de données primaire avec synchronisation complète. Cette opération réussit ou restaure.
  3. Vérifiez que la commande s’est correctement exécutée en exécutant nslook up <fog-name>.secondary.<zone_id>.database.windows.net pour vérifier que l’entrée CNAME DNS pointe vers l’adresse IP de la région cible. Si la commande Switch échoue, le CNAME n’est pas mis à jour.

Supprimer les instances managées sources

Une fois le déplacement terminé, supprimez les ressources dans la région source pour éviter les frais inutiles.

  1. Supprimez le groupe de basculement à l’aide de Remove-AzSqlDatabaseInstanceFailoverGroup. Cela supprime la configuration du groupe de basculement et rompt les liens de géoréplication entre les deux instances.
  2. Supprimez l’instance managée source à l’aide de Remove-AzSqlInstance.
  3. Supprimez toutes les ressources supplémentaires du groupe de ressources, comme le réseau virtuel et le groupe de sécurité.

Contenu connexe