Migrer des ressources de base de données vers Azure global

Cet article contient des informations qui peuvent vous aider à migrer des ressources de base de données Azure d’Azure Allemagne vers Azure global.

Base de données SQL

Pour migrer des charges de travail Azure SQL Database plus petites, sans conserver la base de données migrée en ligne, utilisez la fonction d’exportation pour créer un fichier BACPAC. Un fichier BACPAC est un fichier compressé (compressé) qui contient des métadonnées et les données de la base de données SQL Server. Après avoir créé le fichier BACPAC, vous pouvez copier le fichier dans l’environnement cible (par exemple, à l’aide d’AzCopy) et utiliser la fonction d’importation pour reconstruire la base de données. Tenez compte des points suivants :

• Pour qu’une exportation soit cohérente de manière transactionnelle, vérifiez que l’une des conditions suivantes est vraie :
  • Aucune activité d’écriture ne se produit pendant l’exportation.
  • Vous exportez à partir d’une copie cohérente transactionnelle de votre base de données SQL.
• Pour exporter vers le stockage Blob Azure, la taille de fichier BACPAC est limitée à 200 Go. Pour un fichier BACPAC plus volumineux, exportez vers le stockage local.
• Si l’opération d’exportation à partir de SQL Database prend plus de 20 heures, l’opération peut être annulée. Consultez les articles suivants pour obtenir des conseils sur l’augmentation des performances.

Pour plus d’informations :

• Découvrez comment exporter une base de données vers un fichier BACPAC.
• Découvrez comment importer un fichier BACPAC dans une base de données.
• Consultez la documentation Azure SQL Database.

Migrer SQL Database à l’aide de la géoréplication active

Pour les bases de données trop volumineuses pour les fichiers BACPAC ou pour migrer d’un cloud vers un autre et rester en ligne avec un temps d’arrêt minimal, vous pouvez configurer la géoréplication active d’Azure Allemagne vers Azure global.

Pour plus d’informations sur les coûts de géoréplication actifs, consultez la section intitulée Géoréplication active dans la tarification d’Azure SQL Database.

La migration de bases de données avec géoréplication active nécessite un serveur logique Azure SQL dans Azure global. Vous pouvez créer le serveur à l’aide du portail, d’Azure PowerShell, d’Azure CLI, etc., mais la configuration de la géoréplication active pour migrer d’Azure Allemagne vers Azure global est prise en charge uniquement à l’aide de Transact-SQL (T-SQL).

L’instruction ALTER DATABASE vous permet de spécifier un serveur cible dans Azure global à l’aide de son nom de serveur dns complet côté cible.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]

• sourcedb représente le nom de la base de données dans un serveur Azure SQL dans Azure Allemagne.
• public-server.database.windows.net représente le nom du serveur Azure SQL existant dans Azure global, où la base de données doit être migrée. L’espace de noms « database.windows.net » est requis, remplacez le serveur public par le nom de votre serveur SQL logique dans Azure global. Le serveur dans Azure global doit avoir un nom différent du serveur principal dans Azure Allemagne.

La commande est exécutée sur la base de données master sur le serveur Azure Germany hébergeant la base de données locale à migrer.

• L’API de copie de démarrage T-SQL authentifie l’utilisateur connecté dans le serveur de cloud public en recherchant un utilisateur avec le même nom de connexion/d’utilisateur SQL dans la base de données master de ce serveur. Cette approche est indépendante du cloud ; ainsi, l’API T-SQL est utilisée pour démarrer des copies interclouds. Pour obtenir des autorisations et plus d’informations sur cette rubrique, consultez Création et utilisation de la géoréplication active et ALTER DATABASE (Transact-SQL).

• À l’exception de l’extension de commande T-SQL initiale indiquant un serveur logique Azure SQL dans Azure global, le reste du processus de géoréplication active est identique à l’exécution existante dans le cloud local. Pour obtenir des instructions détaillées pour créer une géoréplication active, consultez Création et utilisation de la géoréplication active à l’exception de la base de données secondaire créée dans le serveur logique secondaire créé dans Azure global.

• Une fois que la base de données secondaire existe dans Azure global (en tant que copie en ligne de la base de données Azure Allemagne), le client peut lancer un basculement de base de données d’Azure Allemagne vers Azure global pour cette base de données à l’aide de la commande ALTER DATABASE T-SQL (voir le tableau ci-dessous).

• Après le basculement, une fois que la base de données secondaire devient une base de données principale dans Azure global, vous pouvez arrêter la géoréplication active et supprimer la base de données secondaire côté Azure Allemagne à tout moment (voir le tableau ci-dessous et les étapes présentes dans le diagramme).

• Après le basculement, la base de données secondaire dans Azure en Allemagne continuera d’entraîner des coûts jusqu’à ce qu’elle soit supprimée.

• L’utilisation de la ALTER DATABASE commande est la seule façon de configurer la géoréplication active pour migrer une base de données Azure Allemagne vers Azure global.

• Aucun portail Azure, Azure Resource Manager, PowerShell ou CLI n’est disponible pour configurer la géoréplication active pour cette migration.

Pour migrer une base de données d’Azure Allemagne vers Azure global :

1. Choisissez la base de données utilisateur dans Azure Allemagne, par exemple, azuregermanydb

2. Créez un serveur logique dans Azure global (le cloud public), par exemple globalazureserver. Son nom de domaine complet (FQDN) est globalazureserver.database.windows.net.

3. Démarrez la géoréplication active d’Azure Allemagne vers Azure global en exécutant cette commande T-SQL sur le serveur dans Azure Allemagne. Notez que le nom DNS complet est utilisé pour le serveur public globalazureserver.database.windows.net. Cela indique que le serveur cible se trouve dans Azure global et non Dans Azure Allemagne.

   ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];
   

4. Lorsque la réplication est prête à déplacer la charge de travail en lecture-écriture vers le serveur Azure global, lancez un basculement planifié vers Azure global en exécutant cette commande T-SQL sur le serveur Azure global.

   ALTER DATABASE [azuregermanydb] FAILOVER;
   

5. Le lien de géoréplication actif peut être arrêté avant ou après le processus de basculement. L’exécution de la commande T-SQL suivante après le basculement planifié supprime le lien de géoréplication, la base de données étant maintenant la copie principale en lecture-écriture dans Azure global. Elle doit être exécutée sur le serveur logique de la base de données géo-primaire actuelle (c’est-à-dire sur le serveur Azure global). Cette opération termine le processus de migration.

   ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];
   

   La commande T-SQL suivante lorsqu’elle est exécutée avant le basculement planifié arrête également le processus de migration, mais dans ce cas, la base de données dans Azure Allemagne reste la copie en lecture-écriture. Cette commande T-SQL doit également être exécutée sur le serveur logique de la base de données géo-primaire actuelle, dans ce cas sur le serveur Azure Germany.

   ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];
   

Ces étapes pour migrer des bases de données Azure SQL d’Azure Allemagne vers Azure global peuvent également être suivies à l’aide de la géoréplication active.

Pour plus d’informations, les tableaux suivants indiquent les commandes T-SQL pour la gestion du basculement. Les commandes suivantes sont prises en charge pour la géoréplication active intercloud entre Azure Allemagne et Azure global :

Vues du système de surveillance actif de la géoréplication

Migrer les sauvegardes de rétention à long terme de la base de données SQL

La migration d’une base de données avec un fichier de géoréplication ou BACPAC ne copie pas sur les sauvegardes de rétention à long terme que la base de données peut avoir dans Azure Allemagne. Pour migrer des sauvegardes de rétention à long terme existantes vers la région Azure globale cible, vous pouvez utiliser la procédure de sauvegarde de rétention à long terme COPY.

Conditions préalables

1. La base de données cible, où vous transférez les sauvegardes LTR, doit exister dans Azure Global avant de commencer la copie de ces sauvegardes. Il est recommandé de migrer d’abord la base de données source à l’aide de la géoréplication active , puis de lancer la copie de sauvegarde LTR. Cela garantit que les sauvegardes de base de données sont copiées dans la base de données de destination correcte. Cette étape n’est pas nécessaire si vous copiez des sauvegardes LTR d’une base de données supprimée. Lors de la copie des sauvegardes LTR d’une base de données supprimée, un ID de base de données factice est créé dans la région cible.
2. Installer ce module PowerShell Az
3. Avant de commencer, vérifiez que les rôles RBAC Azure requis sont accordés à l’étendue de l’abonnement ou du groupe de ressources . Remarque : Pour accéder aux sauvegardes LTR appartenant à un serveur supprimé, l’autorisation doit être accordée dans l’étendue de l’abonnement de ce serveur. .

Limites

• Les groupes de basculement ne sont pas pris en charge. Cela signifie que les clients qui migrent des bases de données Azure Allemagne doivent gérer eux-mêmes les chaînes de connexion pendant le basculement.
• Aucune prise en charge du portail Azure, des API Azure Resource Manager, de PowerShell ou de l’interface CLI. Cela signifie que chaque migration Azure Allemagne devra gérer la configuration et le basculement de géoréplication actifs via T-SQL.
• Les clients ne peuvent pas créer plusieurs instances secondaires géographiques dans Azure global pour des bases de données situées en Azure Allemagne.
• La création d’un géo-secondaire doit être lancée à partir de la région Azure Allemagne.
• Les clients peuvent migrer des bases de données hors d’Azure Allemagne uniquement vers Azure global. Actuellement, aucune autre migration intercloud n’est prise en charge.
• Les utilisateurs Azure AD dans les bases de données utilisateur Azure Allemagne sont migrés, mais ne sont pas disponibles dans le nouveau locataire Azure AD où réside la base de données migrée. Pour activer ces utilisateurs, ils doivent être désactivés et recréés manuellement à l'aide des utilisateurs Azure AD actuels disponibles dans le nouveau locataire Azure AD où réside la base de données récemment migrée.

Copier des sauvegardes de rétention à long terme à l’aide de PowerShell

Une nouvelle commande PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup a été introduite, qui peut être utilisée pour copier les sauvegardes de rétention à long terme d’Azure Allemagne vers les régions globales Azure.

1. Copier la sauvegarde LTR à l’aide du nom de sauvegarde L’exemple suivant montre comment copier une sauvegarde LTR d’Azure Allemagne vers la région globale Azure à l’aide du nom de sauvegarde.

# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN 

2. Copier la sauvegarde LTR à l’aide de l’ID de ressource de sauvegarde L’exemple suivant montre comment copier la sauvegarde LTR d’Azure Allemagne vers la région globale Azure à l’aide d’un ID de ressource de sauvegarde. Cet exemple peut également être utilisé pour copier des sauvegardes d’une base de données supprimée.

$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Limites

• Les sauvegardes de restauration à un point dans le temps (PITR) ne sont effectuées que sur la base de données primaire, c'est voulu. Lors de la migration des bases de données depuis Azure Allemagne en utilisant la Réplication Géographique, les sauvegardes PITR commenceront à s'effectuer sur la nouvelle base de données principale après le basculement. Toutefois, les sauvegardes PITR existantes (sur le serveur principal précédent dans Azure Allemagne) ne seront pas migrées. Si vous avez besoin de sauvegardes PITR pour prendre en charge les scénarios de restauration dans le temps, vous devez restaurer la base de données à partir de sauvegardes PITR dans Azure Allemagne, puis migrer la base de données récupérée vers Azure global.
• Les stratégies de rétention à long terme ne sont pas migrées avec la base de données. Si vous avez une stratégie de rétention à long terme (LTR) sur votre base de données dans Azure Allemagne, vous devez copier et recréer manuellement la stratégie LTR sur la nouvelle base de données après la migration.

Demande d’accès

Pour migrer une base de données d’Azure Allemagne vers Azure global à l’aide de la géoréplication, votre abonnement dans Azure Allemagne doit être activé pour configurer correctement la migration intercloud.

Pour activer votre abonnement Azure Allemagne, vous devez utiliser le lien suivant pour créer une demande de support de migration :

1. Accédez à la demande de support de migration suivante.

2. Sous l’onglet Informations de base, entrez Geo-DR migration en tant que résumé, puis sélectionnez Suivant : Solutions

   

3. Passez en revue les étapes recommandées, puis sélectionnez Suivant : Détails.

   

4. Dans la page de détails, fournissez les éléments suivants :

   1. Dans la zone Description, entrez l’ID d’abonnement Azure global vers lequel effectuer la migration. Pour migrer des bases de données vers plusieurs abonnements, ajoutez une liste des identifiants Azure globaux vers lesquels vous souhaitez migrer les bases de données.
   2. Fournissez les informations de contact : nom, nom de la société, adresse e-mail ou numéro de téléphone.
   3. Remplissez le formulaire, puis sélectionnez Suivant : Vérifier + créer.

   

5. Passez en revue la demande de support, puis sélectionnez Créer.

Vous serez contacté une fois la demande traitée.

Base de données Azure Cosmos DB

Vous pouvez utiliser l’outil de migration de données Azure Cosmos DB pour migrer des données vers Azure Cosmos DB. Azure Cosmos DB Data Migration Tool est une solution open source qui importe des données vers Azure Cosmos DB à partir de différentes sources, notamment : fichiers JSON, MongoDB, SQL Server, fichiers CSV, Stockage Table Azure, Amazon DynamoDB, HBase et conteneurs Azure Cosmos.

Azure Cosmos DB Data Migration Tool est disponible en tant qu’outil d’interface graphique ou en tant qu’outil en ligne de commande. Le code source est disponible dans l’outil de migration de données Azure Cosmos DB référentiel GitHub. Une version compilée de l’outil est disponible dans le Centre de téléchargement Microsoft.

Pour migrer des ressources Azure Cosmos DB, nous vous recommandons d’effectuer les étapes suivantes :

1. Passez en revue les exigences de temps d’activité des applications et les configurations de compte pour déterminer le meilleur plan d’action.
2. Clonez les configurations de compte d’Azure Allemagne vers la nouvelle région en exécutant l’outil de migration de données.
3. Si vous utilisez une fenêtre de maintenance, copiez les données de la source vers la destination en exécutant l’outil de migration de données.
4. Si l'utilisation d'une fenêtre de maintenance n'est pas une option, utilisez l'outil pour copier les données de la source vers la destination, puis procédez comme suit :
   1. Utilisez une approche pilotée par la configuration pour apporter des modifications en lecture/écriture dans une application.
   2. Effectuez une première synchronisation.
   3. Configurez une synchronisation incrémentielle et suivez le flux de changements.
   4. Pointez sur le nouveau compte et validez l’application.
   5. Arrêtez les écritures dans l’ancien compte, assurez-vous que le flux de modifications est à jour, puis redirigez les écritures vers le nouveau compte.
   6. Arrêtez l’outil et supprimez l’ancien compte.
5. Exécutez l’outil pour vérifier que les données sont cohérentes entre les anciens et nouveaux comptes.

Pour plus d’informations :

• Pour savoir comment utiliser l’outil de migration de données, consultez Tutoriel : Utiliser l’outil de migration de données pour migrer vos données vers Azure Cosmos DB.
• Pour en savoir plus sur Cosmos DB, consultez Bienvenue dans Azure Cosmos DB.

Cache Azure pour Redis

Vous avez quelques options si vous souhaitez migrer une instance Azure Cache pour Redis d’Azure Allemagne vers Azure global. L’option que vous choisissez dépend de vos besoins.

Option 1 : Accepter la perte de données, créer une instance

Cette approche est la plus pertinente lorsque les deux conditions suivantes sont vraies :

• Vous utilisez Azure Cache pour Redis comme cache de données temporaire.
• Votre application remplira automatiquement les données du cache dans la nouvelle région.

Pour migrer tout en acceptant une perte de données et créer une nouvelle instance :

1. Créez une instance Azure Cache pour Redis dans la nouvelle région cible.
2. Mettez à jour votre application pour utiliser la nouvelle instance dans la nouvelle région.
3. Supprimez l’ancienne instance azure Cache pour Redis dans la région source.

Option 2 : Copier des données de l’instance source vers l’instance cible

Un membre de l’équipe Azure Cache pour Redis a écrit un outil open source qui copie les données d’une instance Azure Cache pour Redis vers une autre sans nécessiter d’importation ou d’exportation. Consultez l’étape 4 dans les étapes suivantes pour plus d’informations sur l’outil.

Pour copier des données de l’instance source vers l’instance cible :

1. Créez une machine virtuelle dans la région source. Si votre jeu de données dans Azure Cache pour Redis est volumineux, veillez à sélectionner une taille de machine virtuelle relativement puissante pour réduire le temps de copie.
2. Créez une instance Azure Cache pour Redis dans la région cible.
3. Videz les données de l’instance cible . (Veillez à ne pas vider à partir de l’instance source . Le vidage est nécessaire, car l’outil de copie ne remplace pas les clés existantes à l’emplacement cible.)
4. Utilisez l’outil suivant pour copier automatiquement les données de l’instance Azure Cache pour Redis source vers l’instance cible du Cache Azure pour Redis : sourced’outil et téléchargement de l’outil.

Option 3 : Exporter à partir de l’instance source, importer vers l’instance de destination

Cette approche tire parti des fonctionnalités disponibles uniquement dans le niveau Premium.

Pour exporter à partir de l’instance source et importer vers l’instance de destination :

1. Créez une instance Azure Cache pour Redis de niveau Premium dans la région cible. Utilisez la même taille que l’instance Azure Cache source pour Redis.

2. Exportez des données à partir du cache source ou utilisez l’applet de commande PowerShellExport-AzRedisCache.

   Remarque

   Le compte de stockage Azure d’exportation doit se trouver dans la même région que l’instance de cache.

3. Copiez les objets blob exportés vers un compte de stockage dans la région de destination (par exemple, à l’aide d’AzCopy).

4. Importez des données dans le cache de destination ou utilisez l’applet de commande PowerShellImport-AzRedisCAche.

5. Reconfigurez votre application pour utiliser l’instance Azure Cache cible pour Redis.

Option 4 : Écrire des données dans deux instances Azure Cache pour Redis, lues à partir d’une instance

Pour cette approche, vous devez modifier votre application. L’application doit écrire des données dans plusieurs instances de cache lors de la lecture à partir de l’une des instances de cache. Cette approche est logique si les données stockées dans Le Cache Azure pour Redis répondent aux critères suivants :

• Les données sont actualisées régulièrement.
• Toutes les données sont écrites dans l’instance cible de Azure Cache pour Redis.
• Vous avez suffisamment de temps pour que toutes les données soient actualisées.

Pour plus d’informations :

• Consultez la présentation d’Azure Cache pour Redis.

PostgreSQL et MySQL

Pour plus d’informations, consultez les articles de la section « Sauvegarder et migrer des données » de PostgreSQL et MySQL.

Étapes suivantes

Découvrez les outils, techniques et recommandations pour la migration des ressources dans les catégories de service suivantes :

• Calcul
• Mise en réseau
• Stockage
• Web
• Analyse
• IoT
• Intégration
• Identité
• Sécurité
• outils de gestion
• Média