Questions fréquentes (FAQ) sur l’utilisation d’Azure Database Migration Service

Azure Database Migration Service est un service complètement managé conçu pour permettre la migration homogène de plusieurs sources de base de données vers des plateformes de données Azure avec un temps d’arrêt minimal. Le service est actuellement en disponibilité générale, les efforts de développement en cours étant axés sur les aspects suivants :

• Fiabilité et performances.
• Ajout itératif de paires source/cible.
• Investissement continu dans les migrations sans problèmes.

Le service prend actuellement en charge diverses paires source/cible ou scénarios de migration. Pour obtenir la liste complète des états de chaque scénario de migration disponible, consultez l’article État des scénarios de migration pris en charge par Azure Database Migration Service.

Lors de la migration depuis SQL Server, les sources prises en charge pour Azure Database Migration Service sont SQL Server 2008 et versions ultérieures. Si vous utilisez Azure Data Studio avec l'extension SQL Migration, les sources prises en charge sont SQL Server 2008 à SQL Server 2022.

Vous pouvez utiliser Azure Database Migration Service pour effectuer des migrations en ligne et des migrations hors connexion. Dans le cas d’une migration hors connexion, le temps d’arrêt de l’application commence quand la migration commence. Dans le cas d’une migration en ligne, le temps d’arrêt est limité à la durée du basculement à la fin de la migration. Nous vous suggérons de tester une migration hors connexion pour déterminer si le temps d’arrêt est acceptable ; dans le cas contraire, privilégiez une migration en ligne.

Azure Database Migration Service est la méthode recommandée pour la migration de bases de données à grande échelle vers Microsoft Azure. Pour plus d'informations sur la comparaison d'Azure Database Migration Service avec d'autres outils de migration de bases de données Microsoft et pour obtenir des suggestions sur l'utilisation du service dans divers scénarios, consultez Différenciation des outils et services de migration de bases de données Microsoft.

Azure Migrate facilite la migration de machines virtuelles locales vers Azure IaaS. Le service évalue la pertinence de la migration et le dimensionnement en fonction des performances, et fournit des estimations de coût pour l’exécution de vos machines locales dans Azure. Azure Migrate est particulièrement utile pour les migrations de type lift-and-shift des charges de travail basées sur des machines virtuelles locales vers des machines virtuelles IaaS Azure. Toutefois, contrairement à Azure Database Migration Service, Azure Migrate n’est pas une offre de service de migration de bases de données spécialisée pour les plateformes de bases de données relationnelles Azure PaaS telles qu’Azure SQL Database ou Azure SQL Managed Instance.

Non. Le service de migration de base de données ne stocke pas les données client.

Pour les cibles Azure SQL VM et Azure SQL MI, DMS utilise la migration physique, c'est-à-dire l'utilisation de la sauvegarde et de la restauration. La cohérence des données entre source et cible est assurée comme expliqué ci-dessous en fonction du mode de migration choisi.

• Migration hors ligne : lors de la migration hors ligne vers les cibles Azure SQL VM et Azure SQL MI, le temps d'arrêt de l'application commence au démarrage de la migration. DMS garantira que tous les fichiers de sauvegarde seront restaurés sur la cible, à condition que le ou les derniers fichiers de sauvegarde de la source soient copiés vers SMB. stockage réseau ou vers un conteneur blob (selon la configuration de la migration). Vous pouvez vérifier le nom du dernier fichier de sauvegarde à partir de la source avec le dernier fichier de sauvegarde appliqué sur la cible affiché sur la page de surveillance de la migration DMS.
• Migration en ligne : lors de la migration en ligne vers les cibles Azure SQL VM et Azure SQL MI, une fois que vous avez lancé le basculement de migration et suivi de l'arrêt de l'application, DMS veillera à ce que tous les fichiers de sauvegarde soient restaurés sur la cible à condition que le ou les derniers fichiers de sauvegarde de la source soient restaurés. est copié sur le stockage réseau SMB ou dans un conteneur blob (selon la configuration de migration). Il affiche également le nombre de fichiers de sauvegarde en attente qui n'ont pas encore été appliqués sur la cible, avant de terminer le basculement de migration. Vous pouvez vérifier le nom du dernier fichier de sauvegarde à partir de la source avec le dernier fichier de sauvegarde appliqué sur la cible affiché sur la page de surveillance de la migration DMS.

Pour les cibles Azure SQL DB, DMS effectue une migration logique dans le cas d'Azure SQL DB, c'est-à-dire qu'il copie les données des tables de la base de données SQL source et les écrit dans les tables de la base de données Azure SQL DB cible. Comme DMS prend uniquement en charge la migration hors ligne vers Azure SQL DB, le temps d'arrêt de l'application commence au démarrage de la migration. Vous pouvez surveiller et valider le nombre de lignes lues (à partir de la table de base de données source) et copiées (écrites dans la table Azure SQL DB cible) à partir de la surveillance de la migration. page.

La liste suivante contient les ressources Azure qui peuvent être créées en arrière-plan pour effectuer une migration de données. Les services utilisés peuvent varier selon le scénario de migration.

• Azure Monitor
• Microsoft Azure
• Stockage Azure
• Azure Service Bus
• Azure Data Factory.

En interne, DMS gère un magasin de métadonnées qui comprend des informations sur les emplacements réseau, les informations d'identification, les fichiers de sauvegarde et les tâches terminées. Les informations d'identification et les champs sélectionnés, comme les clés de compte, sont cryptés. Les données, comme les noms de tables pouvant être inclus dans la télémétrie, sont hachées. Les noms d'utilisateur peuvent apparaître en texte brut dans les journaux de service, mais les mots de passe ne le seront jamais. La télémétrie est cloisonnée par région, régie par des politiques de rétention et disponible uniquement pour le personnel autorisé de Microsoft à des fins de dépannage valides. Les noms de ressources Azure, comme les noms de serveurs et de bases de données, suivent les règles des ressources Azure.

DMS (Classic) utilise les rubriques Azure Service Bus pour faciliter la communication entre les couches de calcul. Les rubriques Azure Service Bus sont uniques à chaque instance DMS et toutes les données personnelles sont chiffrées.

Azure SQL Managed Instance et SQL Server sur les machines virtuelles Azure

Le schéma et les données sont migrés à l'aide de la sauvegarde et de la restauration. Les clients ont le choix de restaurer à partir d'un partage réseau ou directement à partir d'un conteneur de stockage. Un fichier contenant des données de performances Windows peut être utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail.

Azure SQL Database

Les migrations vers Azure SQL Database s'effectuent en deux étapes. La première étape est une migration de schéma. DMS (Classic) utilise SQL Management Objects (SMO) pour la migration de schéma. La deuxième étape est la migration proprement dite des données. SqlBulkCopy est utilisé pour effectuer la migration des données. DMS ne prend pas en charge la migration de schéma. Les données sont migrées à l'aide d'Azure Data Factory. Facultativement mais fortement recommandé, un fichier contenant des données de performances Windows peut être utilisé pour fournir des suggestions sur le dimensionnement de la charge de travail.

Base de données Azure pour PostgreSQL

Dans ce scénario, l'utilisateur final extrait les métadonnées, en l'occurrence le schéma, à l'aide des utilitaires de ligne de commande pg_dump et pg_restore. Lors de la configuration de la capture des données modifiées pour PostgreSQL, DMS utilise en interne pg_dump et pg_restore pour effectuer l'amorçage initial pour CDC. Les données sont stockées dans un stockage temporaire chiffré qui n'est accessible qu'à votre instance DMS. Un fichier contenant des données de performances Windows peut être utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail.

Azure Database pour MySQL

Dans ce scénario, l'extraction et la migration du schéma sont effectuées par DMS (Classic) à l'aide de mysql-net/MySqlConnector. Dans la mesure du possible, la réplication des journaux binaires MySQL est utilisée pour répliquer à la fois les modifications de données et de schéma. Le code personnalisé est utilisé pour synchroniser les modifications là où la réplication binlog ne peut pas être utilisée.

MongoDB vers Azure Cosmos DB

DMS extrait et insère les données d'un MongoDB dans Cosmos DB. Il offre également la possibilité d'extraire les données d'un dump BSON ou JSON.

Pour les dumps BSON, DMS utilise les données au format bsondump dans le même dossier au sein d'un conteneur blob. DMS recherche uniquement les fichiers de métadonnées utilisant le format collection.metadata.json.

Pour les dumps JSON, DMS lira les fichiers dans les dossiers du conteneur blob nommés d'après les bases de données contenant. Dans chaque dossier de base de données, DMS utilise uniquement les fichiers de données placés dans le sous-dossier data. DMS examine uniquement les fichiers placés dans le sous-dossier metadata et nommés en utilisant le format collection.json des métadonnées.

Oracle vers Azure SQL Base de données

Dans ce scénario, le rapport AWR ou un fichier perfmon Windows est utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail. L'utilisateur effectuant la migration utilise le Kit d'outils de conversion du schéma de la base de données pour effectuer une migration de schéma afin de préparer la base de données cible.

Oracle vers Azure Database pour PostgreSQL

Tout comme Oracle vers Azure SQL Database, dans ce scénario, le rapport AWR ou un fichier perfmon Windows est utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail. La bibliothèque ora2pg est utilisée pour extraire le schéma et migrer les données manuellement par l'utilisateur effectuant la migration.

DMS (Classic) s'appuie sur la configuration réseau du client. Si la source de migration utilise des points de terminaison privés, nous utilisons des points de terminaison privés, qui constituent la configuration préférée. Nous utilisons des points de terminaison publics s'ils constituent la seule option.

DMS utilise largement ADF en coulisses pour la planification et la coordination des déplacement des données. De plus, le runtime d'intégration auto-hébergé n'est pas différent de celui que vous utilisez probablement déjà pour vos propres pipelines ADF. Pour plus d'informations sur les problèmes de pare-feu et de serveur proxy, consultez Créer et configurer un runtime d'intégration auto-hébergé.

Toutes les données clients sont cryptées au repos. Certaines métadonnées, notamment les noms de serveurs logiques et les noms de bases de données, ainsi que l'état et la progression de la migration, apparaissent dans les journaux de service qui ne sont pas chiffrés.

Toutes les données en transit sont protégées par défaut avec le cryptage TLS 1.2. Les anciens clients nécessitant des versions antérieures de TLS doivent avoir les versions requises activées sur la page du portail DMS (classique). Pour DMS, la machine sur laquelle le runtime d'intégration auto-hébergé est installé peut être configurée pour autoriser les paramètres TLS requis pour s'adapter aux clients existants. Pour plus d'informations sur la configuration TLS pour SQL Server, consultez KB3135244-Support TLS 1.2 pour Microsoft SQL Server.

Dans la mesure du possible, des points de terminaison privés sont utilisés. Si les points de terminaison privés ne sont pas une option, les points de terminaison publics sont utilisés pour la communication entre les couches de service. Quel que soit le type de point de terminaison, toutes les ressources sont dédiées/portées à l'instance particulière de DMS et sécurisées avec des informations d'identification uniques.

Nous ne prenons pas en charge les clés gérées par le client pour le chiffrement des données au sein de notre plan de données ou de notre plan de contrôle. Cependant, toutes les données clients sont chiffrées au repos à l'aide de clés gérées par le service. Certaines métadonnées, notamment les noms de serveurs logiques et les noms de bases de données, ainsi que l'état et la progression de la migration, apparaissent dans les journaux de service sous forme non chiffrée.

Toutes les données en transit sont chiffrées par défaut avec le chiffrement TLS 1.2. La page du portail DMS (Classic) permet d'utiliser des versions plus anciennes de TLS pour les clients existants. Pour DMS, la machine sur laquelle le runtime d'intégration auto-hébergé est installé peut être configurée pour permettre la gestion des paramètres TLS afin de s'adapter aux clients existants. Pour plus d'informations sur la configuration TLS pour SQL Server, consultez KB3135244-Support TLS 1.2 pour Microsoft SQL Server.

Nous n'exposons pas la possibilité de chiffrer les données sur notre plan de contrôle ou de données avec les clés gérées par le client. Toutes les données client sont supprimées au moment où l'instance DMS est supprimée, à l'exception des journaux de service. Les journaux de service DMS ne sont conservés que pendant 30 jours.

TDE

DMS prend en charge la migration des clés gérées par le client (CMK) vers Azure SQL pour Transparent Database Encryption (TDE). Pour obtenir des instructions étape par étape pour migrer vos clés TDE, consultez Tutoriel : Migrer des bases de données compatibles TDE (préversion) vers Azure SQL dans Azure Data Studio.

Cryptage cellulaire

Le chiffrement au niveau des cellules est géré au niveau du schéma. Les outils de migration de schéma migrent tous les objets de schéma, y compris les fonctions et procédures stockées nécessaires à la mise en œuvre du chiffrement au niveau des cellules.

Always Encrypted

DMS ne prend actuellement pas en charge la migration d’Always Encrypted via des scénarios dans lesquels des lignes de données individuelles sont migrées entre la source et la cible. Les colonnes chiffrées via Always Encrypted sont migrées comme prévu dans les scénarios qui utilisent la sauvegarde/restauration, comme le déplacement vers une machine virtuelle Azure SQL ou une instance Azure SQL Managed à partir d'une instance SQL Server existante.

Nous n’implémentons aucun contrôle d’accès basé sur l’emplacement au-delà de ce qui est déjà disponible dans Azure. Toutes les données associées à une instance DMS résident dans la même région que la ressource DMS.

Nos services sont utilisés dans divers environnements avec différents contrôles internes et processus commerciaux. DMS déplace les données depuis et vers n'importe quel endroit auquel le compte qu'il utilise a accès. Il est de la responsabilité de l'utilisateur de comprendre les autorisations et les contrôles internes de l'environnement dans lequel il travaille. Il est particulièrement important de garantir que le compte que DMS utilise pour se connecter à la source a accès à toutes les données destinées à être migrées depuis la source.

L’injection VNET est l’action d’ajouter une ressource Azure qui réside dans le locataire Microsoft à un sous-réseau dans un réseau virtuel sous le locataire client. Cette approche a été adoptée avec DMS pour nous permettre de gérer le calcul au nom du client, tout en conservant l'accès aux ressources du client. Étant donné que le réseau est sous abonnement client, Microsoft ne peut pas gérer la machine virtuelle au-delà de l'émission de commandes Démarrer, Arrêter, Supprimer ou Déployer. Toutes les autres actions de gestion nécessitant un accès à la VM nécessitent une requête d’assistance et une approbation initiées par le client.

Il existe plusieurs prérequis pour garantir qu’Azure Database Migration Service s’exécute correctement lors de la migration de bases de données. Certaines des conditions préalables s’appliquent à tous les scénarios (paires source-cible) pris en charge par le service, tandis que d’autres sont propres à un scénario spécifique.

Les conditions préalables associées à Azure Database Migration Service communes à tous les scénarios de migration pris en charge incluent le besoin de :

• Créez un Réseau virtuel Microsoft Azure pour Azure Database Migration Service à l’aide du modèle de déploiement Azure Resource Manager, qui fournit une connectivité site à site à vos serveurs sources locaux via ExpressRoute ou un VPN.
• Vérifiez que vos règles de groupe de sécurité réseau du réseau virtuel ne bloquent pas le port 443 pour ServiceTags de ServiceBus, Stockage et Azure Monitor. Pour plus d’informations sur le filtrage du trafic de groupe de sécurité réseau de réseau virtuel, consultez l’article Filtrer le trafic avec les groupes de sécurité réseau.
• Lorsque vous utilisez une appliance de pare-feu devant vos bases de données sources, vous devrez peut-être ajouter des règles de pare-feu pour permettre à Azure Database Migration Service d’accéder aux bases de données sources pour la migration.

Pour obtenir la liste de tous les prérequis permettant des scénarios de migration spécifiques à l’aide d’Azure Database Migration Service, consultez les tutoriels associés dans la documentation d’Azure Database Migration Service.

Vous devrez peut-être ajouter des règles de pare-feu autorisant Azure Database Migration Service à accéder à votre base de données source pour la migration. L’adresse IP du service est dynamique, mais si vous utilisez ExpressRoute, cette adresse est attribuée en privé par votre réseau d’entreprise. Le moyen le plus simple d’identifier l’adresse IP appropriée est de regarder dans le même groupe de ressources que votre ressource Azure Database Migration Service provisionnée et y rechercher l’interface réseau associée. Habituellement, le nom de la ressource d'interface réseau commence par le préfixe NIC et est suivi d'une séquence de caractères et de chiffres uniques, par exemple, `NIC-jj6tnztnmarpsskr82rbndyp``. En sélectionnant cette ressource d’interface réseau, vous pouvez voir l’adresse IP qui doit être incluse dans la liste d’autorisation sur la page de présentation des ressources du portail Azure.

Par ailleurs, vous devez peut-être inclure la source du port que SQL Server écoute sur la liste d’autorisation. Par défaut, il s’agit du port 1433, mais le SQL Server source peut être configuré pour écouter d’autres ports également. Dans ce cas, vous devez aussi inclure ces ports sur la liste d’autorisation. Vous pouvez déterminer le port écouté par SQL Server à l’aide de la requête de vue de gestion dynamique :

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Vous pouvez également déterminer le port écouté par SQL Server en interrogeant le journal des erreurs SQL Server :

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Même si plusieurs didacticiels Microsoft peuvent vous présenter le processus de configuration d’un réseau virtuel, la documentation officielle est disponible dans l’article Réseau virtuel Azure.

Lors d’une migration de base de données classique et simple, vous effectuez les opérations suivantes :

1. Créer des bases de données cibles.
2. Évaluer vos bases de données sources.
   • Pour les migrations homogènes, évaluez vos bases de données existantes avec DMA.
   • Pour les migrations hétérogènes (à partir de sources concurrentes), évaluez vos bases de données existantes avec SSMA. Vous utilisez également SSMA pour convertir des objets de base de données et migrer le schéma vers votre plateforme cible.
3. Créer une instance d’Azure Database Migration Service.
4. Créer un projet de migration spécifiant la ou les bases de données sources, la ou les bases de données cibles, et les tables à migrer.
5. Démarrer le chargement complet.
6. Choisir la validation ultérieure.
7. Effectuer un basculement manuel de votre environnement de production vers la nouvelle base de données cloud.

Si vous avez des difficultés à vous connecter à votre système de base de données source quand vous travaillez sur la migration, créez une machine virtuelle dans le même sous-réseau de réseau virtuel que celui avec lequel vous avez configuré votre instance DMS. Dans la machine virtuelle, vous devez être en mesure d’effectuer un test de connexion, par exemple en utilisant un fichier UDL pour tester une connexion à SQL Server ou en téléchargeant Robo 3T pour tester les connexions MongoDB. Si le test de connexion réussit, vous ne devriez pas avoir de problème de connexion à votre base de données source. Si le test de connexion échoue, contactez votre administrateur réseau.

Si l’utilisateur arrête explicitement Azure Database Migration Service (DMS) ou si le service est inactif pendant 24 heures, le service est dans un état arrêté ou automatiquement mis en pause. Dans chaque cas, le service est indisponible et dans un état arrêté. Pour reprendre les migrations actives, redémarrez le service.

Vous pouvez effectuer quelques opérations pour accélérer la migration de votre base de données à l’aide du service :

• Utilisez le niveau tarifaire Usage général avec plusieurs processeurs lorsque vous créez votre instance de service pour permettre au service de tirer parti de multiples processeurs virtuels pour la parallélisation et le transfert plus rapide des données.
• Faites évoluer temporairement votre instance cible Azure SQL Database vers la référence SKU de niveau Premium pendant l’opération de migration des données afin de minimiser la limitation d’Azure SQL Database qui peut affecter les activités de transfert de données lors de l’utilisation de références SKU de niveau inférieur.

Étapes suivantes

• Qu'est-ce que l’Azure Database Migration Service.