Guide de migration : SQL Server vers Azure SQL Managed Instance

  • Article

S’applique à :Azure SQL Managed Instance

Ce guide vous aide à migrer votre instance de SQL Server vers Azure SQL Managed Instance.

Vous pouvez migrer SQL Server s’exécutant en local ou sur :

  • SQL Server sur les machines virtuelles
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relational Database Service) pour SQL Server
  • Google Compute Engine
  • Cloud SQL pour SQL Server - GCP (Google Cloud Platform)

Pour plus d’informations sur la migration, consultez la vue d’ensemble de la migration. Pour obtenir d’autres guides de migration, consultez Migration de base de données.

Migration process flow

Prérequis

Pour migrer votre serveur SQL vers Azure SQL Managed Instance, assurez-vous d’avoir :

Prémigration

Une fois que vous avez vérifié que votre environnement source est pris en charge, commencez par la phase de prémigration. Découvrez toutes les sources de données existantes, évaluez la faisabilité de la migration et identifiez les problèmes bloquants susceptibles d’empêcher la migration de s’effectuer correctement.

Découvrez

Durant la phase de découverte, analysez le réseau pour identifier toutes les instances et fonctionnalités de SQL Server utilisées par votre organisation.

Utilisez Azure Migrate pour évaluer la pertinence de la migration des serveurs locaux, effectuer un dimensionnement en fonction des performances, et fournir des estimations de coût pour une exécution dans Azure.

Vous pouvez également utiliser Microsoft Assessment and Planning Toolkit (« MAP Toolkit ») pour évaluer votre infrastructure informatique actuelle. La boîte à outils fournit un puissant outil d’inventaire, d’évaluation et de création de rapports, qui permet de simplifier le processus de planification de la migration.

Pour plus d’informations sur les outils utilisables au cours de la phase de découverte, consultez Services et outils disponibles pour les scénarios de migration de données.

Une fois les sources de données découvertes, évaluez les instances de SQL Server locales que vous pouvez migrer vers Azure SQL Managed Instance pour identifier les obstacles ou les problèmes de compatibilité liés à la migration. Passez aux étapes suivantes pour évaluer et migrer des bases de données vers Azure SQL Managed Instance :

Steps for migration to Azure SQL Managed Instance

Évaluer

Notes

Si vous évaluez l’ensemble du patrimoine de données SQL Server à grande échelle sur VMware, utilisez Azure Migrate pour obtenir des recommandations de déploiement Azure SQL, le dimensionnement de la cible et des estimations mensuelles.

Déterminez si SQL Managed Instance est compatible avec les exigences de base de données de votre application. SQL Managed Instance est conçu pour faciliter la migration « lift-and-shift » de la plupart des applications existantes qui utilisent SQL Server. Toutefois, vous pouvez d’avoir parfois besoin de fonctionnalités ou de capacités qui ne sont pas encore prises en charge, et pour lesquelles le coût d’implémentation d’une solution de contournement est trop élevé.

L’extension de migration Azure SQL pour Azure Data Studio fournit une expérience fluide basée sur un assistant pour effectuer l’évaluation, obtenir des recommandations Azure et migrer vos bases de données SQL Server locales vers des machines virtuelles Azure. Outre mettre en évidence les éléments bloquants ou les avertissements liés à la migration, l’extension inclut également une option pour obtenir des recommandations Azure en collectant les données de performances de vos bases de données afin de recommander une instance Azure SQL Managed Instance de taille appropriée pour répondre aux besoins de performances de votre charge de travail (au meilleur prix).

Vous pouvez utiliser l’extension Azure SQL Migration pour Azure Data Studio si vous souhaitez évaluer des bases de données afin d’obtenir :

Pour évaluer votre environnement à l’aide de l’extension Azure SQL Migration, effectuez ces étapes :

  1. Ouvrez l’extension Azure SQL Migration pour Azure Data Studio.
  2. Connectez-vous à votre instance SQL Server source
  3. Cliquez sur le bouton Migrer vers Azure SQL dans l’Assistant Migration Azure SQL dans Azure Data Studio
  4. Sélectionnez les bases de données à évaluer, puis cliquez sur Suivant
  5. Sélectionnez votre cible Azure SQL, dans ce cas, Azure SQL Managed Instance
  6. Cliquez sur Afficher/Sélectionner pour examiner le rapport d’évaluation
  7. Recherchez les éventuels problèmes de blocage de la migration et de parité des fonctionnalités. Vous pouvez également exporter le rapport d’évaluation vers un fichier partagé avec d’autres équipes ou membres du personnel de votre organisation.
  8. Déterminez le niveau de compatibilité de la base de données pour réduire les efforts postmigration.

Pour obtenir une recommandation Azure avec l’extension Azure SQL Migration, effectuez ces étapes :

  1. Ouvrez l’extension Azure SQL Migration pour Azure Data Studio.
  2. Connectez-vous à votre instance SQL Server source
  3. Cliquez sur le bouton Migrer vers Azure SQL dans l’Assistant Migration Azure SQL dans Azure Data Studio
  4. Sélectionnez les bases de données à évaluer, puis cliquez sur Suivant
  5. Sélectionnez votre cible Azure SQL, dans ce cas, Azure SQL Managed Instance
  6. Accédez aux sections des recommandations Azure, puis cliquez sur Obtenir une recommandation Azure
  7. 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.
  8. Après 10 minutes, Azure Data Studio indique qu’une recommandation est disponible pour Azure SQL Managed Instance.
  9. Accédez à la carte Azure SQL Managed Instance dans le volet de la cible Azure SQL pour lire votre recommandation de référence SKU Azure SQL Managed Instance

Pour en savoir plus, consultez Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance en ligne avec Azure Data Studio.

Pour en savoir plus, consultez Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance hors connexion avec Azure Data Studio.

Si l’évaluation révèle plusieurs obstacles qui indiquent que votre base de données n’est pas prête pour une migration vers Azure SQL Managed Instance, d’autres options existent :

Évaluations mises à l’échelle et analyse

L’extension Azure SQL Migration pour Azure Data Studio et Azure Migrate prend en charge les évaluations mises à l’échelle et la centralisation des rapports d’évaluation à des fins d’analyse.

Si vous disposez de plusieurs serveurs et bases de données qui doivent être évalués et analysés à grande échelle afin de fournir une vue plus large du parc de données, consultez les liens suivants pour en savoir plus :

Important

L’exécution d’évaluations à grande échelle sur plusieurs bases de données peut également être automatisée à l’aide de l’utilitaire en ligne de commande de DMA. Vous pouvez ensuite charger les résultats vers Azure Migrate pour approfondir l’analyse et préparer la cible.

Déployer sur une instance gérée dimensionnée de façon optimale

Vous pouvez utiliser l’extension de migration Azure SQL pour Azure Data Studio pour obtenir une recommandation sur une taille appropriée d’Azure SQL Managed Instance. L’extension collecte des données de performances auprès de votre instance SQL Server source pour fournir une recommandation Azure sur une taille appropriée qui répond aux besoins en matière de performances de votre charge de travail avec un coût minimal. Pour plus d’informations, consultez Obtenir une recommandation d’Azure sur une taille appropriée pour votre ou vos bases de données SQL Server locales

En fonction des informations de la phase de découverte et d’évaluation, créez une cible SQL Managed Instance de taille appropriée. Pour ce faire, vous pouvez utiliser le portail Azure, PowerShell ou un modèle ARM (Azure Resource Manager).

SQL Managed Instance est adapté pour des charges de travail locales qui planifient une migration vers le cloud. Un modèle d’achat est ainsi présenté. Il offre davantage de flexibilité dans le choix du niveau de ressources pour vos charges de travail. Dans l’univers de l’informatique locale, vous étiez probablement habitué à dimensionner ces charges de travail en utilisant des cœurs physiques et une bande passante des E/S. Le modèle d’achat pour une instance gérée repose sur des mémoires à tores magnétiques virtuelles, ou « vCores », avec un stockage et des E/S supplémentaires disponibles séparément. Le modèle vCore vous permet de comprendre plus facilement vos exigences de calcul dans le cloud par rapport à ce que vous utilisez localement aujourd’hui. Ce modèle d’achat vous permet de dimensionner au mieux votre environnement de destination dans le cloud. Quelques conseils généraux pouvant vous aider à choisir les caractéristiques et le niveau de service appropriés sont décrits ici :

  • En fonction de la base de référence d’utilisation du processeurs, vous pouvez provisionner une instance managée correspondant au nombre de cœurs que vous utilisez sur SQL Server, tout en tenant compte des caractéristiques du processeur qui sont susceptibles d’être mises à l’échelle, afin de satisfaire aux caractéristiques des machines virtuelles où l’instance managée est installée.
  • En fonction de l’utilisation de la mémoire de référence, choisissez le niveau de service disposant de la mémoire correspondante. La quantité de mémoire ne peut pas être choisie directement : vous devez donc sélectionner l’instance managée avec la quantité de vCores qui a la mémoire correspondante (par exemple 5,1 Go/vCore dans la série Standard (Gen5)).
  • En fonction de la latence d’E/S de référence du sous-système de fichiers, choisissez entre les niveaux de service Usage général (latence supérieure à 5 ms) et Critique pour l’entreprise (latence inférieure à 3 ms).
  • En fonction du débit de référence, pré-allouez la taille des fichiers de données ou des fichiers journaux pour atteindre les performances d’E/S attendues.

Vous pouvez choisir des ressources de calcul et de stockage au moment du déploiement, puis les modifier plus tard sans temps d’arrêt pour votre application par le biais du portail Azure :

Managed Instance Sizing

Pour apprendre à créer l’infrastructure de réseau virtuel et une instance gérée, voir Créer une instance gérée.

Important

Il est important de maintenir votre réseau virtuel de destination et le sous-réseau en adéquation avec la Configuration requise de réseau virtuel d’instance gérée. Toute incompatibilité risque de vous empêcher de créer des instances ou d’utiliser celles que vous avez déjà créées. Apprenez-en davantage sur la création de réseaux et la configuration de réseaux existants.

Migrer

Une fois que vous avez effectué les tâches associées à la phase de prémigration, vous êtes prêt à effectuer la migration du schéma et des données.

Migrez les données à l’aide de la méthode de migration de votre choix.

SQL Managed Instance cible des scénarios d’utilisateur qui exigent une migration de base de données en masse depuis des implémentations locales ou de machine virtuelle. Ils constituent le meilleur choix lorsque vous avez besoin d’effectuer une migration « lift-and-shift » du backend des applications qui utilisent régulièrement des fonctionnalités au niveau de l’instance et/ou entre plusieurs bases de données. Si cela correspond à votre scénario, vous pouvez déplacer toute une instance vers un environnement correspondant dans Azure sans devoir redéfinir l’architecture de vos applications.

Pour déplacer des instances SQL, vous devez planifier avec soin :

  • La migration de toutes les bases de données qui ont besoin d’être colocalisées (celles qui s’exécutent sur la même instance).
  • La migration des objets au niveau de l’instance dont votre application dépend, notamment les connexions, les informations d’identification, les travaux et opérateurs de l’Agent SQL, ainsi que les déclencheurs au niveau du serveur.

SQL Managed Instance est un service managé qui vous permet de déléguer certaines des activités courantes d’administration des bases de données à la plateforme, car elles y sont intégrées. Ainsi, certaines données au niveau de l’instance n’ont pas besoin d’être migrées, notamment les travaux de maintenance pour les sauvegardes régulières ou la configuration Always On, étant donné que la haute disponibilité est intégrée.

Cet article aborde deux des options de migration recommandées :

  • Extension de migration Azure SQL pour Azure Data Studio - Migration avec un temps d’arrêt quasi nul.
  • Native RESTORE DATABASE FROM URL - Utilise des sauvegardes natives à partir de SQL Server et nécessite un temps d’arrêt.

Ce guide décrit les deux options les plus répandues : Azure Database Migration Service (DMS) et la fonctionnalité native de sauvegarde et restauration.

Pour d’autres outils de migration, consultez Comparer les options de migration.

Migrer avec l’extension de migration Azure SQL pour Azure Data Studio (temps d’arrêt minimal)

Pour effectuer une migration avec temps d’arrêt minimal en utilisant Azure Data Studio, suivez les étapes générales ci-dessous. Pour obtenir un tutoriel pas à pas détaillé, consultez Migrer SQL Server vers Azure SQL Managed Instance en ligne en utilisant Azure Data Studio :

  1. Téléchargez et installez Azure Data Studio et l’extension de migration Azure SQL.
  2. Lancez Migrer vers Azure SQL dans l’Assistant Migration Azure SQL de l’extension dans Azure Data Studio.
  3. Sélectionnez des bases de données pour évaluation, et consultez l’état de préparation ou les problèmes de la migration (le cas échéant). Collectez aussi des données de performances et obtenez une recommandation d’Azure pour une taille appropriée.
  4. Sélectionnez votre compte Azure et votre instance Azure SQL Managed Instance cible dans votre abonnement.
  5. Sélectionnez l’emplacement de vos sauvegardes de base de données. Vos sauvegardes de base de données peuvent se trouver sur un partage réseau local ou dans un conteneur Stockage Blob Azure.
  6. Créez un service Azure Database Migration Service en utilisant l’Assistant dans Azure Data Studio. Si vous avez déjà créé un service Azure Database Migration Service en utilisant Azure Data Studio, vous pouvez réutiliser le même si vous le souhaitez.
  7. Facultatif : Si vos sauvegardes se trouvent sur un partage réseau local, téléchargez et installez le runtime d’intégration auto-hébergé sur une machine qui peut se connecter au serveur SQL Server source et à l’emplacement contenant les fichiers de sauvegarde.
  8. Démarrez la migration de la base de données et surveillez la progression dans Azure Data Studio. Vous pouvez aussi surveiller la progression sous la ressource Azure Database Migration Service dans le portail Azure.
  9. Effectuez le basculement.
    1. Arrêtez toutes les transactions entrantes vers la base de données source.
    2. Apportez les changements de configuration nécessaires aux applications pour qu’elles pointent vers la base de données cible dans Azure SQL Managed Instance.
    3. Effectuez les sauvegardes de fin de journal pour la base de données source à l’emplacement de sauvegarde spécifié.
    4. Vérifiez que toutes les sauvegardes de base de données sont à l’état Restauré dans la page des détails de la supervision.
    5. Sélectionnez Terminer le basculement dans la page des détails de la supervision.

Sauvegarde et restauration

Une des fonctionnalités clés d’Azure SQL Managed Instance pour accélérer et faciliter la migration des bases de données est la restauration native des fichiers de sauvegarde de base de données (.bak) stockés sur Stockage Azure. La sauvegarde et la restauration sont des opérations asynchrones basées sur la taille de votre base de données.

Le diagramme suivant fournit une vue d’ensemble du processus :

Diagram shows SQL Server with an arrow labeled BACKUP / Upload to URL flowing to Azure Storage and a second arrow labeled RESTORE from URL flowing from Azure Storage to a SQL Managed Instance.

Remarque

Le temps nécessaire pour effectuer une sauvegarde, la charger vers le stockage Azure et exécuter une opération de restauration native sur Azure SQL Managed Instance dépend de la taille de la base de données. Prenez en compte un temps d’arrêt suffisant pour les grandes bases de données.

Le tableau suivant fournit des informations supplémentaires sur les méthodes que vous pouvez utiliser en fonction de la version de SQL Server source que vous exécutez :

Étape Moteur SQL et version Méthode de sauvegarde/restauration
Placer la sauvegarde sur Stockage Azure Avant 2012 SP1 CU2 Charger le fichier .bak directement sur Stockage Azure
2012 SP1 CU2 - 2016 Sauvegarde directe utilisant la syntaxe WITH CREDENTIAL dépréciée
2016 et versions ultérieures Sauvegarde directe utilisant WITH SAS CREDENTIAL
Restaurer à partir d’un Stockage Azure vers une instance gérée RESTORE FROM URL avec SAS CREDENTIAL

Important

  • Lorsque vous migrez une base de données protégée par Transparent Data Encryption vers une instance gérée à l’aide d’une option de restauration native, le certificat correspondant du serveur SQL Server local ou de machine virtuelle Azure doit être migré avant la restauration de la base de données. Pour des instructions détaillées, voir Migrer un certificat TDE vers une instance gérée.
  • La restauration de bases de données système n’est pas prise en charge. Pour migrer des objets au niveau de l’instance (stockés dans des bases de données master ou msdb), nous vous recommandons de les scripter et d’exécuter des scripts T-SQL sur l’instance de destination.

Pour effectuer une migration à l’aide de la fonctionnalité de sauvegarde et restauration, suivez les étapes ci-dessous :

  1. Sauvegardez votre base de données sur le Stockage Blob Azure. Par exemple, utilisez la fonctionnalité de sauvegarde vers une URL dans SQL Server Management Studio. Utilisez Microsoft Azure Tools pour prendre en charge les bases de données antérieures à SQL Server 2012 SP1 CU2.

  2. Connectez-vous à votre instance Azure SQL Managed Instance via SQL Server Management Studio.

  3. Créez des informations d’identification à l’aide d’une signature d’accès partagé pour accéder à votre compte Stockage Blob Azure avec vos sauvegardes de base de données. Par exemple :

    CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = 'sv=2017-11-09&ss=bfqt&srt=sco&sp=rwdlacup&se=2028-09-06T02:52:55Z&st=2018-09-04T18:52:55Z&spr=https&sig=WOTiM%2FS4GVF%2FEEs9DGQR9Im0W%2BwndxW2CQ7%2B5fHd7Is%3D'

  4. Restaurez la sauvegarde à partir du conteneur Azure Storage Blob. Par exemple :

    RESTORE DATABASE [TargetDatabaseName] FROM URL =
  'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'

  5. Une fois la restauration effectuée, visualisez la base de données dans l’Explorateur d’objets de SQL Server Management Studio.

Pour en savoir plus sur cette option de migration, consultez Restaurer une base de données dans Azure SQL Managed Instance avec SSMS.

Notes

Une opération de restauration de base de données est asynchrone et peut être retentée. SQL Server Management Studio peut générer une erreur en cas d’interruption de la connexion ou d’expiration d’un délai d’attente. Azure SQL Database continue d’essayer de restaurer la base de données en arrière-plan et vous pouvez suivre l’avancement de la restauration dans les vues sys.dm_exec_requests et sys.dm_operation_status.

Synchronisation des données et basculement

Quand vous utilisez des options de migration qui répliquent/synchronisent en permanence les changements apportés aux données de la source vers la cible, les données et le schéma sources peuvent varier et dériver par rapport à la cible. Pendant la synchronisation des données, vérifiez que tous les changements apportés à la source sont capturés et appliqués à la cible au cours du processus de migration.

Une fois que vous avez vérifié que les données sont identiques sur la source et la cible, vous pouvez effectuer le basculement de l’environnement source vers l’environnement cible. Il est important de planifier le processus de basculement avec les équipes métier/applicatives de façon à garantir que l’interruption minimale lors du basculement n’affecte pas la continuité de l’activité.

Important

Pour plus d’informations sur les étapes spécifiques associées à l’exécution d’un basculement dans le cadre de migrations à l’aide du service DMS, consultez Exécution du basculement de migration.

Postmigration

Une fois que vous avez réussi la phase de migration, vous devez effectuer une série de tâches de postmigration pour vérifier que tout fonctionne de manière fluide et efficace.

La phase de postmigration est cruciale pour résoudre les problèmes de justesse et d’exhaustivité des données ainsi que pour gérer les problèmes de performances liés à la charge de travail.

Surveiller et corriger les applications

Après avoir effectué la migration vers une instance managée, vous devez suivre le comportement de l’application et les performances de votre charge de travail. Ce processus comporte les activités suivantes :

Effectuer des tests

L’approche de test pour la migration de base de données comprend les activités suivantes :

  1. Développer des tests de validation : pour tester la migration d’une base de données, vous devez utiliser des requêtes SQL. Vous devez créer les requêtes de validation à exécuter sur les bases de données source et cible. Vos requêtes de validation doivent couvrir l’étendue que vous avez définie.
  2. Configurer un environnement de test: l’environnement de test doit contenir une copie de la base de données source et de la base de données cible. Veillez à isoler l’environnement de test.
  3. Exécuter des tests de validation : exécutez les tests de validation sur la source et sur la cible, puis analysez les résultats.
  4. Exécuter des tests de performances: exécutez un test de performances sur la source et sur la cible, puis analysez et comparez les résultats.

Utiliser des fonctionnalités avancées

Vous pouvez tirer parti des fonctionnalités cloud avancées offertes par SQL Managed Instance, notamment la haute disponibilité intégrée, la détection des menaces ainsi que la supervision et le paramétrage de votre charge de travail.

Azure SQL Analytics vous permet de superviser un grand nombre d’instances managées de manière centralisée.

Certaines fonctionnalités SQL Server sont disponibles uniquement une fois que vous avez fait passer le niveau de compatibilité de la base de données au dernier niveau (150).

Étapes suivantes