Partage via

Déplacer des ressources dans une nouvelle région - Azure SQL Database

  • Article

S’applique à : Azure SQL Database

Cet article présente un flux de travail générique pour déplacer votre base de données ou pool élastique vers une nouvelle région.

Remarque

  • Pour déplacer des pools élastiques et des bases de données vers une autre région Azure, vous pouvez également utiliser Azure Resource Mover (recommandé).
  • 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 base de données ou pool 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.

Vérifier les prérequis pour déplacer la base de données

  1. Créez un serveur cible pour chaque serveur source.
  2. Configurez le pare-feu avec les exceptions appropriées à l’aide de PowerShell.
  3. Configurez les serveurs avec les connexions appropriées. Si vous n’êtes pas administrateur de l’abonnement ou administrateur SQL Server, collaborez avec l’administrateur pour affecter les autorisations dont vous avez besoin. Pour plus d’informations, consultez Guide pratique pour gérer la sécurité d’Azure SQL Database après la récupération d'urgence.
  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 le serveur source) au serveur cible, puis à définir la clé comme protecteur TDE sur le serveur cible, puisqu'un serveur d'une région peut désormais être connecté à un coffre-fort de clés dans n'importe quelle autre région.
    • Pour vérifier que le serveur 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 le serveur source pour retourner la liste des clés disponibles et ajouter ces clés au serveur cible.
    • Pour plus d’informations et pour connaître les bonnes pratiques relatives à la configuration du chiffrement TDE géré par le client sur le serveur cible, consultez Azure SQL Transparent Data Encryption avec des clés gérées par le client dans Azure Key Vault.
    • Pour déplacer le coffre de clés vers la nouvelle région, consultez Déplacer un coffre de clés Azure d’une région à une autre.
  5. Si l’audit au niveau de la base de données est activé, désactivez-le et activez plutôt l’audit au niveau du serveur. Après le basculement, l’audit au niveau de la base de données nécessite le trafic inter-régions, qui n’est pas souhaitable ou possible après le déplacement.
  6. Pour les audits au niveau du serveur, vérifiez que :
    • Le conteneur de stockage, Log Analytics ou le hub d’événements avec les journaux d’audit existants est déplacé vers la région cible.
    • L’audit est configuré sur le serveur cible. Pour plus d'informations, consultez Prise en main de l’audit SQL Database.
  7. Si votre serveur a une stratégie de conservation à long terme (LTR), les sauvegardes LTR existantes restent associées au serveur actuel. Le serveur cible étant différent, vous pouvez accéder aux sauvegardes LTR plus anciennes dans la région source à l’aide du serveur source, même si le serveur est supprimé.

Remarque

La migration de bases de données 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 le serveur cible, ce qui n’est pas possible actuellement.

Préparer les ressources

  1. Créez un groupe de basculement entre le serveur de la source et le serveur de la cible.
  2. Ajoutez les bases de données que vous souhaitez déplacer au groupe de basculement. La réplication de toutes les bases de données ajoutées est lancée automatiquement. Pour plus d’informations, consultez Utilisation de groupes de basculement avec SQL Database.

Superviser le processus de préparation

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

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

Tester la synchronisation

Une fois que ReplicationState a la valeur 2, connectez-vous à chaque base de données ou sous-ensemble de bases de données à l’aide du point de terminaison secondaire <fog-name>.secondary.database.windows.net et 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 au serveur cible à l’aide du point de terminaison secondaire <fog-name>.secondary.database.windows.net.
  2. Utilisez Switch-AzSqlDatabaseFailoverGroup pour faire du serveur secondaire la base de données primaire avec synchronisation complète. Cette opération réussira ou sera restaurée.
  3. Vérifiez que la commande s’est correctement exécutée en exécutant nslook up <fog-name>.secondary.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 ne sera pas mis à jour.

Supprimer les bases de donné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-AzSqlDatabaseFailoverGroup.
  2. Supprimez chaque base de données source à l’aide de Remove-AzSqlDatabase pour chacune des bases de données sur le serveur source. Cela met automatiquement fin aux liens de géoréplication.
  3. Supprimez le serveur source à l’aide de Remove-AzSqlServer.
  4. Supprimez le coffre de clés, les conteneurs de stockage d’audit, l’Event Hub, le locataire Microsoft Entra et les autres ressources dépendantes pour qu’elles ne vous soient plus facturées.

Vérifier les prérequis pour déplacer le pool

  1. Créez un serveur cible pour chaque serveur source.
  2. Configurez le pare-feu avec les exceptions appropriées à l’aide de PowerShell.
  3. Configurez les serveurs avec les connexions appropriées. Si vous n’êtes pas un administrateur de l’abonnement ou un administrateur du serveur, collaborez avec l’administrateur pour attribuer les autorisations dont vous avez besoin. Pour plus d’informations, consultez Guide pratique pour gérer la sécurité d’Azure SQL Database après la récupération d'urgence.
  4. Si vos bases de données sont chiffrées avec la clé de chiffrement transparente et que vous utilisez votre propre clé de chiffrement dans Azure Key Vault, vérifiez que le matériel de chiffrement correct est provisionné dans les régions cibles.
  5. Créez un pool élastique cible pour chaque pool élastique source, en veillant à ce que le pool soit créé dans le même niveau de service, avec le même nom et la même taille.
  6. Si un audit de niveau base de données est activé, désactivez-le et activez plutôt l’audit au niveau du serveur. Après le basculement, l’audit au niveau de la base de données nécessitera le trafic inter-régions, qui n’est pas souhaitable ou possible après le déplacement.
  7. Pour les audits au niveau du serveur, vérifiez que :
    • Le conteneur de stockage, Log Analytics ou le hub d’événements avec les journaux d’audit existants est déplacé vers la région cible.
    • La configuration de l’audit est configurée sur le serveur cible. Pour plus d’informations, consultez Audit SQL Database.
  8. Si votre serveur a une stratégie de conservation à long terme (LTR), les sauvegardes LTR existantes restent associées au serveur actuel. Le serveur cible étant différent, vous pouvez accéder aux sauvegardes LTR plus anciennes dans la région source à l’aide du serveur source, même si le serveur est supprimé.

Remarque

La migration de bases de données 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 le serveur cible, ce qui n’est pas possible actuellement.

Préparer le déplacement

  1. Créez un groupe de basculement entre chaque pool élastique sur le serveur source et son pool élastique équivalent sur le serveur cible.

  2. Ajoutez toutes les bases de données du pool au groupe de basculement. La réplication des bases de données ajoutées est lancée automatiquement. Pour plus d’informations, consultez Utilisation de groupes de basculement avec SQL Database.

    Notes

    Bien qu’il soit possible de créer un groupe de basculement qui comprend plusieurs pools élastiques, nous vous recommandons vivement de créer un groupe de basculement distinct pour chaque pool. Si vous devez déplacer un grand nombre de bases de données dans plusieurs pools élastiques, vous pouvez exécuter les étapes de préparation en parallèle, puis lancer l’étape de déplacement en parallèle. Ce processus est mieux adapté et prend moins de temps que si vous avez plusieurs pools élastiques dans le même groupe de basculement.

Superviser le processus de préparation

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

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

Tester la synchronisation

Une fois que ReplicationState a la valeur 2, connectez-vous à chaque base de données ou sous-ensemble de bases de données à l’aide du point de terminaison secondaire <fog-name>.secondary.database.windows.net et 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 au serveur cible à l’aide du point de terminaison secondaire <fog-name>.secondary.database.windows.net.
  2. Utilisez Switch-AzSqlDatabaseFailoverGroup pour faire du serveur secondaire la base de données primaire avec synchronisation complète. Cette opération réussira ou sera annulée.
  3. Vérifiez que la commande s’est correctement exécutée en exécutant nslook up <fog-name>.secondary.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 pools élastiques 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-AzSqlDatabaseFailoverGroup.
  2. Supprimez chaque pool élastique source sur le serveur source à l’aide de Remove-AzSqlElasticPool.
  3. Supprimez le serveur source à l’aide de Remove-AzSqlServer.
  4. Supprimez le coffre de clés, les conteneurs de stockage d’audit, l’Event Hub, le locataire Microsoft Entra et les autres ressources dépendantes pour qu’elles ne vous soient plus facturées.

Étapes suivantes

Gérez votre base de données après avoir migré.