Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance avec DMS

Vous pouvez utiliser Azure Database Migration Service (DMS) et l’extension de migration Azure SQL dans Azure Data Studio pour migrer des bases de données d’une instance SQL Server vers Azure SQL Managed Instance avec un temps d’arrêt minimal.

Pour connaître les méthodes de migration de base de données qui peuvent nécessiter une configuration manuelle, consultez Guide de migration : SQL Server vers Azure SQL Managed Instance.

Prérequis

Pour suivre ce didacticiel, vous devez effectuer les opérations suivantes :

• Télécharger et installer Azure Data Studio

• Installer l’extension de migration Azure SQL pour Azure Data Studio à partir de la place de marché Azure Data Studio

• Disposer d’un compte Azure affecté à l’un des rôles intégrés suivants :

  • Contributeur pour l’instance cible Azure SQL Managed Instance et pour le compte de stockage où vous chargez vos fichiers de sauvegarde de base de données à partir d’un partage réseau SMB (Server Message Block)
  • Rôle lecteur pour les groupes de ressources Azure qui contiennent l’instance cible Azure SQL Managed Instance ou votre compte de stockage Azure
  • Rôle propriétaire ou contributeur pour l’abonnement Azure (obligatoire si vous créez une instance Database Migration Service)

  En guise d’alternative à l’utilisation de l’un de ces rôles intégrés, vous pouvez attribuer un rôle personnalisé.

  Important

  Un compte Azure n’est requis que lorsque vous configurez les étapes de migration. Un compte Azure n’est pas nécessaire pour l’évaluation ou pour afficher les recommandations Azure dans l’Assistant Migration dans Azure Data Studio.

• Créez une instance cible d’Azure SQL Managed Instance.

• Vérifiez que les comptes de connexion utilisés pour connecter l’instance SQL Server source sont membres du rôle serveur sysadmin ou ont l’autorisation CONTROL SERVER.

• Fournissez un partage réseau SMB, un partage de fichiers de compte Stockage Azure ou un conteneur d’objets blob de compte Stockage Azure contenant vos fichiers de sauvegarde complète de base de données et de sauvegarde des journaux de transactions suivants. Database Migration Service utilise l’emplacement de sauvegarde pendant la migration de la base de données.

  • L’extension de migration Azure SQL pour Azure Data Studio n’effectue pas de sauvegardes de base de données et n’initie aucune sauvegarde de base de données en votre nom. Au lieu de cela, le service utilise des fichiers de sauvegarde de base de données existants pour la migration.
  • Si les fichiers de sauvegarde de votre base de données se trouvent dans un partage réseau PME, créez un compte de stockage Azure qui permette au service DMS de charger les fichiers de sauvegarde de la base de données et de migrer les bases de données. Veillez à créer le compte de stockage Azure dans la même région que celle où vous créez votre instance de Database Migration Service.
  • Vous pouvez écrire chaque sauvegarde dans un fichier de sauvegarde distinct ou dans plusieurs fichiers de sauvegarde. L’ajout de plusieurs sauvegardes, comme des journaux de transaction et complets à un seul support de sauvegarde n’est pas pris en charge.
  • Vous pouvez fournir des sauvegardes compressées pour réduire le risque de rencontrer des problèmes de migration de sauvegardes volumineuses.

• Assurez-vous que le compte de service exécutant l’instance source SQL Server dispose des autorisations en lecture et en écriture sur le partage réseau SMB qui contient les fichiers de sauvegarde de base de données.

• Si vous migrez une base de données protégée par Transparent Data Encryption (TDE), le certificat de l’instance source SQL Server doit être migré vers votre instance cible Azure SQL avant de migrer les données. Pour plus d’informations sur la migration des bases de données avec TDE activé, consultez Tutoriel : Migrer des bases de données avec TDE (Transparent Data Encryption) activé (préversion) vers Azure SQL dans Azure Data Studio.

  Si votre base de données contient des données sensibles protégées par la fonctionnalité Always Encrypted, le processus de migration effectue automatiquement la migration de vos clés Always Encrypted vers votre instance cible Azure SQL.

• Si vos sauvegardes de base de données se trouvent dans un partage de fichiers réseau, fournissez un ordinateur sur lequel installer l’IR auto-hébergé pour accéder et migrer les sauvegardes de base de données. L’Assistant Migration vous fournit le lien de téléchargement et les clés d’authentification pour télécharger et installer votre IR auto-hébergé.

  Pour préparer la migration, assurez-vous que l’ordinateur sur lequel vous prévoyez d’installer le runtime d’intégration auto-hébergé possède les règles de pare-feu sortantes et les noms de domaine suivants activés :

  Noms de domaine	Port sortant	Description
  Cloud public : {datafactory}.{region}.datafactory.azure.net ou *.frontend.clouddatahub.net Azure Government : {datafactory}.{region}.datafactory.azure.us Microsoft Azure géré par 21Vianet : {datafactory}.{region}.datafactory.azure.cn	443	Requis par l’IR auto-hébergé pour se connecter au service de migration des données. Pour une fabrique de données nouvellement créée dans le cloud public, recherchez le nom de domaine complet (FQDN) de votre clé de runtime d’intégration auto-hébergée, au format {datafactory}.{region}.datafactory.azure.net. Pour une fabrique de données existante, si vous ne voyez pas le nom de domaine complet dans votre clé d’intégration auto-hébergée, utilisez *.frontend.clouddatahub.net à la place.
  download.microsoft.com	443	Exigé par le runtime d’intégration auto-hébergé pour télécharger les mises à jour. Si vous avez désactivé la mise à jour automatique, vous pouvez ignorer la configuration de ce domaine.
  .core.windows.net	443	Utilisé par le runtime d’intégration auto-hébergé qui se connecte au compte de stockage Azure pour charger les sauvegardes de base de données à partir de votre partage réseau.

  Conseil

  Si vos fichiers de sauvegarde de base de données sont déjà fournis dans un compte de stockage Azure, l’IR auto-hébergé n’est pas requis pendant le processus de migration.

• Lorsque vous utilisez l’IR auto-hébergé, assurez-vous que l’ordinateur sur lequel le runtime est installé peut se connecter à l’instance SQL Server et au partage de fichiers réseau source où se trouvent les fichiers de sauvegarde.

• Activez le port de sortie 445 pour autoriser l’accès au partage de fichiers réseau. Pour plus d’informations, consultez Recommandations relatives à l’utilisation d’un runtime d’intégration auto-hébergé.

• Si vous utilisez Database Migration Service pour la première fois, assurez-vous que le fournisseur de ressources Microsoft.DataMigration est inscrit dans votre abonnement. Vous pouvez suivre les étapes pour inscrire le fournisseur de ressources.

Lancer l’Assistant Migration vers Azure SQL dans Azure Data Studio

Pour ouvrir l’Assistant Migrer vers Azure SQL :

1. Dans Azure Data Studio, accédez à Connexions. Sélectionnez et connectez-vous à votre instance locale SQL Server. Vous pouvez également vous connecter à SQL Server sur une machine virtuelle Azure.

2. Cliquez avec le bouton droit sur la connexion au serveur, puis sélectionnez Gérer.

3. Dans le menu du serveur, sous Général, sélectionnez Migration Azure SQL.

4. Dans le tableau de bord de l’extension de migration Azure SQL, sélectionnez Migrer vers Azure SQL pour ouvrir l’Assistant Migration.

   

5. Sur la première page de l’Assistant, démarrez une nouvelle session ou reprenez une session précédemment enregistrée.

Exécution de l’évaluation de la base de données, collecte de données de performances et recommandation Azure

1. Sélectionnez les bases de données que vous souhaitez évaluer, puis sélectionnez Suivant.

2. Sélectionnez Azure SQL Managed Instance en tant que cible.

   

3. Sélectionnez Afficher/Sélectionner pour afficher les résultats de l’évaluation.

4. Dans les résultats de l’évaluation, sélectionnez la base de données, puis passez en revue le rapport d’évaluation pour vous assurer qu’aucun problème n’a été détecté.

   

   1. Sélectionnez Obtenir la recommandation Azure pour ouvrir le volet de recommandations.

   2. Sélectionnez Collecter les données de performance maintenant. Choisissez un dossier sur votre ordinateur local pour stocker les journaux de performances, puis sélectionnez Démarrer.

      Azure Data Studio collecte ensuite les données de performances jusqu’à ce que vous arrêtiez le processus, appuyiez sur le bouton Suivant dans l’Assistant ou fermiez Azure Data Studio.

      Après 10 minutes, Azure Data Studio indique qu’une recommandation est disponible pour Azure SQL Managed Instance. Vous pouvez aussi cliquer sur le lien Actualiser la recommandation après les 10 minutes initiales pour actualiser et affiner la recommandation à l’aide des données supplémentaires collectées. Une évaluation étendue est particulièrement utile si vos modèles d’utilisation varient au fil du temps.

   3. Dans la cible Azure SQL Managed Instance sélectionnée, cliquez sur Afficher les détails pour ouvrir le rapport de recommandation de référence SKU détaillé.

   4. Dans Passer en revue les recommandations Azure SQL Managed Instance, passez en revue la recommandation. Pour enregistrer une copie de la recommandation, cochez la case Enregistrer le rapport de recommandations.

5. Sélectionnez Fermer pour fermer le sous-onglet de recommandations.

6. Sélectionnez Suivant pour poursuivre la migration de votre base de données dans l’Assistant.

Configurer les paramètres de migration

L’extension de migration Azure SQL pour Azure Data Studio n’exige plus de configurations spécifiques au niveau des paramètres réseau de votre compte Stockage Azure pour la migration de vos bases de données SQL Server vers Azure. Cependant, selon l’emplacement de sauvegarde de votre base de données et la configuration souhaitée des paramètres réseau du compte de stockage, quelques étapes sont nécessaires pour permettre à vos ressources d’accéder au compte Stockage Azure. Consultez le tableau suivant pour découvrir les différents scénarios de migration et les différentes configurations réseau :

1a – Configuration réseau de Stockage Blob Azure

Si votre runtime d’intégration auto-hébergé (SHIR) est installé sur une machine virtuelle Azure, consultez la section 1b – Configuration réseau de Stockage Blob Azure. Si votre runtime d'intégration auto-hébergé (SHIR) est installé sur votre réseau local, vous devez ajouter votre adresse IP cliente de la machine d’hébergement dans votre compte Stockage Azure comme suit :

Pour appliquer cette configuration spécifique, connectez-vous au portail Azure à partir de la machine SHIR, ouvrez la configuration du compte Stockage Azure, sélectionnez Réseau, puis cochez la case Ajouter l’adresse IP de votre client. Sélectionnez Enregistrer pour rendre la modification persistante. Pour les étapes restantes, consultez la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé).

1b – Configuration réseau de Stockage Blob Azure

Si votre SHIR est hébergé sur une machine virtuelle Azure, vous devez ajouter le réseau virtuel de la machine virtuelle au compte de Stockage Azure, car la machine virtuelle a une adresse IP non publique qui ne peut pas être ajoutée à la section Plage d’adresses IP.

Pour appliquer cette configuration spécifique, localisez votre compte Stockage Azure. Ensuite, dans le panneau Stockage des données, sélectionnez Réseau, puis cochez la case Ajouter un réseau virtuel existant. Un nouveau panneau s’ouvre. Sélectionnez l’abonnement, le réseau virtuel et le sous-réseau de la machine virtuelle Azure qui héberge le runtime d’intégration. Vous trouverez ces informations dans la page Vue d’ensemble de la machine virtuelle Azure. Il se peut que le sous-réseau indique Point de terminaison de service obligatoire. Si c’est le cas, sélectionnez Activer. Une fois que tout est prêt, enregistrez les mises à jour. Pour les étapes restantes nécessaires, reportez-vous à la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé).

2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé)

Si vos sauvegardes sont placées directement dans un conteneur de Stockage Azure, toutes les étapes précédentes sont inutiles, car aucun runtime d’intégration ne communique avec le compte Stockage Azure. Cependant, il nous reste encore à vérifier que l’instance cible de SQL Server peut communiquer avec le compte Stockage Azure pour restaurer les sauvegardes à partir du conteneur. Pour appliquer cette configuration spécifique, suivez les instructions de la section 1b – Configuration réseau de Stockage Blob Azure, en spécifiant le réseau virtuel de l’instance SQL cible au moment de compléter la fenêtre contextuelle « Ajouter un réseau virtuel existant ».

2b – Configuration réseau de Stockage Blob Azure (point de terminaison privé)

Si vous avez configuré un point de terminaison privé sur votre compte Stockage Azure, suivez les étapes décrites dans la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé). Cependant, vous devez sélectionner le sous-réseau du point de terminaison privé, et pas seulement le sous-réseau cible SQL Server. Vérifiez que le point de terminaison privé est hébergé dans le même réseau virtuel que l’instance cible de SQL Server. Si ce n’est pas le cas, créez un autre point de terminaison privé en suivant le processus de la section Configuration du compte Stockage Azure.

Créer une instance de Database Migration Service

Créez une instance d’Azure Database Migration Service, ou réutilisez un service existant que vous avez créé.

Si vous avez précédemment créé une instance Database Migration Service à l’aide du Portail Azure, vous ne pouvez pas réutiliser l’instance dans l’Assistant de migration dans Azure Data Studio. Vous pouvez réutiliser une instance uniquement si vous l’avez créée à l’aide d’Azure Data Studio.

Utiliser une instance existante de Database Migration Service

Pour utiliser une instance existante de Database Migration Service :

1. Dans Groupe de ressources, sélectionnez le groupe de ressources qui contient une instance existante de Database Migration Service.

2. Dans Azure Database Migration Service, sélectionnez une instance existante de Database Migration Service qui se trouve dans le groupe de ressources sélectionné.

3. Sélectionnez Suivant.

Créer une instance de Database Migration Service

Pour créer une instance de Database Migration Service :

1. Dans Groupe de ressources, créez un groupe de ressources pour contenir une nouvelle instance de Database Migration Service.

2. Sous Azure Database Migration Service, sélectionnez Créer.

3. Dans Créer Azure Database Migration Service, entrez un nom pour votre instance de Database Migration Service, puis sélectionnez Créer.

Une fois la création de l’instance de DMS réussie, vous recevez les détails nécessaires pour configurer le runtime d’intégration.

1. Sélectionnez le lien Télécharger et installer le runtime d’intégration pour ouvrir le lien de téléchargement dans un navigateur web. Téléchargez le runtime d’intégration, puis installez-le sur un ordinateur qui remplit les conditions préalables pour se connecter à l’instance SQL Server source.

   Une fois l’installation effectuée, le Gestionnaire de configuration de Microsoft Integration Runtime s’ouvre automatiquement pour débuter le processus d’inscription.

2. Dans le tableau Clé d’authentification, copiez l’une des clés d’authentification fournies dans l’Assistant et collez-la dans Azure Data Studio. Si la clé d’authentification est valide, une icône de contrôle verte apparaît dans le Gestionnaire de configuration Integration Runtime. Une coche verte indique que vous pouvez vous Inscrire.

   Après avoir enregistré le runtime d’intégration auto-hébergé, fermez Microsoft Integration Runtime Configuration Manager.

   Notes

   Pour plus d’informations sur l’utilisation du runtime d’intégration auto-hébergé, consultez Créer et configurer un runtime d’intégration auto-hébergé.

3. Dans Créer Azure Database Migration Service dans Azure Data Studio, sélectionnez Tester la connexion pour valider que l’instance de Database Migration Service nouvellement créée est connectée au runtime d’intégration auto-hébergé nouvellement enregistré.

   

4. Revenez à l’Assistant Migration dans Azure Data Studio.

Démarrer la migration de base de données

Passez en revue la configuration que vous avez créée, puis sélectionnez Démarrer la migration pour démarrer la migration de base de données.

Surveiller la migration de base de données

Limites

La migration vers Azure SQL Managed Instance à l’aide de l’extension Azure SQL pour Azure Data Studio présente les limitations suivantes :

• Si vous migrez une base de données unique, les sauvegardes de base de données doivent être placées dans une structure de fichiers plats à l’intérieur d’un dossier de base de données (contenant un dossier racine du conteneur), et les dossiers ne peuvent pas être imbriqués, car cela n’est pas pris en charge.
• Si vous migrez plusieurs bases de données à l’aide du même conteneur de Stockage Blob Azure, vous devez placer les fichiers de sauvegarde de différentes bases dans des dossiers distincts dans le conteneur.
• Le remplacement des bases de données existantes à l’aide de DMS dans votre Azure SQL Managed Instance cible n’est pas pris en charge.
• DMS ne prend pas en charge la configuration de la haute disponibilité et récupération d’urgence sur votre cible pour qu’elle corresponde à la topologie source.
• Les objets serveur suivants ne sont pas pris en charge :
  • travaux de l'Agent SQL Server
  • Informations d'identification
  • Packages SSIS
  • Audit de serveur
• Vous ne pouvez pas utiliser un runtime d’intégration auto-hébergé existant créé à partir d’Azure Data Factory pour les migrations de base de données avec DMS. Au départ, le runtime d’intégration auto-hébergé doit être créé à l’aide de l’extension de migration Azure SQL dans Azure Data Studio, et il peut être réutilisé pour des migrations de base de données supplémentaires.
• Un travail LRS unique (créé par DMS) peut s’exécuter pendant un maximum de 30 jours. Lorsque cette période arrive à expiration, la tâche est automatiquement annulée et votre base de données cible est automatiquement supprimée.
• Si vous avez reçu l’erreur suivante : Memory-optimized filegroup must be empty in order to be restored on General Purpose tier of SQL Database Managed Instance, ce problème est dû à la conception. L’OLTP en mémoire n’est pas prise en charge au niveau du service Usage général d’Azure SQL Managed Instance. Pour poursuivre la migration, une méthode consiste à effectuer une mise à niveau vers le niveau critique pour l’entreprise qui prend en charge l’OLTP en mémoire. Une autre méthode consiste à veiller à ce que la base de données source ne l’utilise pas quand l’Instance gérée Azure SQL est en usage général.

Contenu connexe

• Démarrage rapide : restaurer une base de données dans Azure SQL Managed Instance avec SSMS
• Qu’est-ce qu’Azure SQL Managed Instance ?
• Problèmes connus, limitations et résolution des problèmes
• Connecter votre application à Azure SQL Managed Instance