Planifier une migration de données
Un projet de modernisation des plateformes de données comporte cinq phases qui sont généralement effectuées dans l’ordre.
Dans notre scénario de distributeur mondial, le conseil d’administration a approuvé le projet de modernisation et vous commencez à organiser le personnel et d’autres ressources. Pour configurer et affecter des tâches de manière optimale, vous devez comprendre les phases du projet en profondeur.
Dans cette unité, vous allez explorer chacune des cinq phases plus en détail.
Lancer et découvrir
Les projets de modernisation de la plateforme de données sont généralement lancés pour répondre à des exigences commerciales ou légales. Il est donc essentiel de tenir compte de ces besoins et d’obtenir le soutien des cadres senior. La première étape consiste à effectuer un exercice de découverte sur la base des considérations suivantes :
Évaluer l’environnement actuel
De nombreuses infrastructures informatiques évoluent généralement sur de nombreuses années, voire des décennies. Dans ce délai, l’entreprise et le personnel peuvent changer considérablement au point qu’il n’y ait plus d’experts dans les systèmes détenus par une organisation. Dans de rares occasions, les organisations peuvent même oublier l’existence de certains systèmes.
Rechercher les dépendances entre les applications et les bases de données existantes
Vous devez prendre le temps de comprendre comment vos applications interagissent avec les bases de données qui existent sur votre réseau. En outre, vous devez comprendre toutes les dépendances pouvant exister entre les bases de données afin de pouvoir rassembler celles-ci en regroupements logiques. Vous pouvez ainsi vous appuyer sur les regroupements logiques de bases de données pour migrer celles-ci vers Azure en une seule unité.
Lister les types de charges de travail de vos systèmes
La liste des types de charges de travail sur les serveurs de base de données identifiés fournit des insights sur leur utilisation. Les charges de travail peuvent être catégorisées comme analytiques (OLAP) ou transactionnelles (OLTP), selon qu’elles sont intensives en lecture ou en écriture. Ceci permet de décider de la technologie de plateforme de données vers laquelle migrer. Une catégorisation supplémentaire peut inclure les charges de travail par lots ou d’aide à la décision.
Évaluation
Au cours de la phase d’évaluation, les informations recueillies pendant la phase de découverte sont utilisées pour effectuer une évaluation complète des charges de travail identifiées afin d’établir les éléments suivants :
- Tous les bloqueurs de migration potentiels
- Tous les changements cassants nécessitant des correctifs après la migration
- Fonctionnalités Azure que les charges de travail peuvent utiliser
Vous établissez ceci en effectuant une évaluation des charges de travail actuelles et une évaluation des critères des charges de travail :
Évaluation des charges de travail actuelles
Les serveurs de base de données et les applications identifiés sont catégorisés et vérifiés pour établir les éléments suivants : volume de données et taux de croissance attendus, utilisation moyenne des ressources et criticité pour l’entreprise. Cette phase offre également l’occasion d’envisager de combiner ou de désactiver des bases de données locales afin de réduire le nombre de bases de données à migrer et de réduire le coût total de possession.
Évaluation des critères des charges de travail
Dans l’évaluation des critères des charges de travail, vous utilisez les résultats de l’évaluation des charges de travail actuelles afin de définir les critères de post-migration pour l’exécution des charges de travail identifiées.
Supposons que vous avez identifié un serveur de base de données transactionnel fortement utilisé pendant les heures de pointe, mais avec une faible utilisation pendant les heures creuses. Dans l’évaluation des critères des charges de travail, vous définissez des critères de post-migration, comme migrer vers une base de données Azure SQL Database avec mise à l’échelle automatique pour gérer les pics de charge.
Planification
L’étape de planification d’un projet de modernisation de plateforme de données implique la détermination de la plateforme cible, de l’approche de migration et des plans d’atténuation pour les interruptions planifiées ou non planifiées.
Au cours de la phase de planification du processus de modernisation des plateformes de données, sept termes décrivent la façon dont vous pouvez gérer la transition des applications et des données d’un environnement local existant vers un nouvel environnement cloud (public ou privé) :
| # | Phase | Action | Description |
|---|---|---|---|
| 1. | Rester | Ne rien faire | Modernisation continue tout en envisageant des options à long terme pour les services locaux restants. |
| 2. | Réhébergement | Migrer vers IaaS | Cette approche élimine la nécessité de gérer le centre de données et engendre un retour sur investissement (ROI) plus élevé grâce à un coût total de possession (TCO) plus bas. |
| 3. | Refactorisation | Migration vers IaaS ou PaaS avec des modifications d’application minimales | Cette approche élimine la nécessité de gérer le centre de données et engendre un retour sur investissement (ROI) plus élevé grâce à un coût total de possession (TCO) plus bas. Elle permet également d’avoir une charge de gestion plus faible grâce au regroupement de bases de données. |
| 4. | Réarchitecture | Réécriture des aspects principaux de l’application pour utiliser des technologies cloud | Elle permet l’utilisation de composants modernes, réduit le déploiement de code et facilite le déploiement DevOps de l’infrastructure et des services. |
| 5. | Recréation | Reconstruction de l’application pour utiliser des technologies PaaS ou serverless | La reconstruction des plateformes de données et des applications avec des technologies plus récentes permet d’utiliser la haute disponibilité intégrée d’Azure, d’augmenter la portabilité et la scalabilité des applications, et de réduire les écarts de compétences potentiels entre la technologie utilisée et le personnel qui prend en charge/développe l’application. |
| 6. | Replace | Remplacer l’application par une application plus récente ou une solution SaaS | Envisagez l’approche de remplacement quand une application a des dépendances sur des appareils physiques attachés au serveur ou quand elle s’intègre étroitement à l’infrastructure locale. |
| 7. | Mettre hors service | Mettre hors service des applications qui ne sont plus nécessaires | L’approche de retrait doit être envisagée quand des applications et bases de données héritées ne sont plus utilisées car aucune exigence métier ou légale impose de les conserver. |
Le graphique ci-dessous montre la quantité d’effort qu’impose chaque terme par rapport à la valeur que retire l’entreprise de la migration.
Options de la plateforme cible
En règle générale, deux possibilités s’offrent à vous au moment de choisir la plateforme cible.
IaaS (Infrastructure as a Service) : dans cette approche, vous migrez vos données vers une machine virtuelle sur laquelle SQL Server est installé.
PaaS (Platform as a Service) : dans cette approche, vous migrez vos données vers un service de plateforme de données qui convient à votre charge de travail. Pour les charges de travail transactionnelles, cela impliquerait Azure SQL Database ou Azure SQL Managed Instance. Pour les charges de travail de type traitement analytique en ligne (OLAP), cela impliquerait Azure SQL Data Warehouse.
Choix de la plateforme cible par fonctionnalité
Azure SQL Database : à utiliser si la surface d’exposition de l’application est limitée à la base de données. SQL Database offre une solution nécessitant peu de maintenance qui peut être une option intéressante pour certaines charges de travail.
Pools élastiques Azure SQL Database : les pools élastiques vous permettent d’allouer des ressources de stockage et de calcul à un groupe de bases de données, au lieu de devoir gérer les ressources individuellement pour chaque base de données. En outre, les pools élastiques sont plus faciles à mettre à l’échelle que les bases de données uniques, car la mise à l’échelle des bases de données individuelles n’y est plus nécessaire en raison des modifications apportées au pool élastique.
Azure SQL Database serverless : ceci est efficace pour réduire les coûts dans les environnements de développement et de test. La fonctionnalité de délai de mise en pause automatique vous permet de définir la période inactive avant que la base de données ne soit mise en pause automatiquement. Vous pouvez choisir entre 1 heure et 7 jours, ou le désactiver. Quand vous accédez à nouveau à la base de données, elle reprend et entraîne seulement des frais de stockage pendant la pause.
Azure SQL Managed Instance : convient si la surface d’exposition de l’application est limitée à l’instance et nécessite des fonctionnalités non disponibles dans Azure SQL Database, comme :
- SQL Agent
- MSDTC
- DQS
- MDS
- Messagerie de base de données
- PolyBase
- Prise en charge des serveurs liés
- Prise en charge des nouveaux services cloud Azure tels que la détection des menaces
SQL Server sur une machine virtuelle Azure : à utiliser si la surface de l’application est limitée à l’instance et nécessite des fonctionnalités non disponibles dans Azure SQL Managed Instance, comme SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) et SQL Server Integration Services (SSIS).
Azure Synapse Analytics : à utiliser si vous avez des applications qui exécutent des requêtes complexes sur de grandes quantités de données et qui peuvent tirer parti du traitement massivement parallèle (MPP) pour réduire les temps de traitement des requêtes.
Pour voir la liste des fonctionnalités prises en charge sur chaque offre PaaS pour SQL, consultez Comparaison des fonctionnalités : Azure SQL Database et Azure SQL Managed Instance.
Choix de la plateforme cible par coût
Azure SQL Database : la nature PaaS d’Azure SQL Database réduit considérablement les coûts d’administration et de gestion par rapport à la topologie IaaS SQL Server sur Azure plus classique, car la majeure partie du travail requis est effectuée automatiquement pour vous en arrière-plan par Microsoft. À grande échelle, cela peut représenter des économies considérables en temps et en travail.
Pools élastiques Azure SQL Database : les pools élastiques Azure SQL Database peuvent engendrer des économies significatives s’ils sont utilisés pour plusieurs bases de données dont les demandes d’utilisation sont variables et imprévisibles. Les ressources de calcul sont partagées, ce qui évite le surprovisionnement et réduit les coûts de maintenance et d’administration du serveur.
Azure SQL Managed Instance : SQL Managed Instance est disponible pour les clients qui veulent bénéficier d’une offre de service entièrement managée, où ils peuvent effectuer facilement une opération « lift-and-shift » de leur environnement avec des modifications de configuration minimes. L’environnement offre un minimum de 8 cœurs et jusqu’à 8 To de stockage et se trouve sur un réseau virtuel isolé. Cette offre est idéale pour les clients qui veulent accéder rapidement au cloud et éviter le surcroît de travail lié à la maintenance des machines virtuelles.
SQL Server sur une machine virtuelle Azure : par rapport aux offres PaaS, SQL Server s’exécutant sur des machines virtuelles Azure a des coûts de calcul, de stockage et de gestion plus élevés, mais donne un meilleur contrôle sur SQL Server et sur l’infrastructure.
Azure Synapse Analytics : Azure Synapse Analytics peut réduire vos coûts en tirant parti de l’architecture MPP pour traiter les requêtes complexes en quelques minutes plutôt qu’en quelques heures.
Migrations hors connexion et en ligne
Au cours de la phase de planification se pose le choix d’une migration en ligne ou hors connexion. Avec les migrations hors connexion, les temps d’arrêt de l’application commencent en même temps que la migration. Pour limiter le temps d’arrêt au temps nécessaire pour basculer vers le nouvel environnement une fois la migration terminée, utilisez une migration en ligne. Nous vous recommandons 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. En outre, les options en ligne et hors connexion peuvent ne pas être disponibles, selon la plateforme Azure sélectionnée.
Transformer et optimiser
Votre évaluation et votre planification auront identifié les aspects de vos applications et de votre base de données nécessitant un travail de post-migration pour transformer ou optimiser une fonctionnalité afin de garantir la réussite de la migration. La transformation implique généralement un travail qui vous oblige à corriger ou à changer un aspect d’une base de données.
L’optimisation consiste généralement à apporter une modification à la base de données migrée pour tirer parti d’une fonctionnalité ou à optimiser son utilisation dans Azure.
Par exemple, une transformation peut impliquer la modification d’une procédure stockée ou d’une requête SQL qui contient une syntaxe non prise en charge dans la base de données cible. Ceci nécessite d’ajuster la syntaxe pour garantir la compatibilité avec la nouvelle plateforme de base de données, garantissant ainsi que la procédure stockée ou la requête s’exécute sans problème dans l’environnement cible.
Transformer
Pour garantir la réussite de l’expérience post-migration, une ou plusieurs des modifications suivantes peuvent être apportées à une base de données.
Installer les mises à niveau de version de pré-migration
Corriger les erreurs identifiées par les outils d’évaluation de la migration
Implémenter les modifications de schéma de base de données
Migrer les services de base de données intégrés existants vers Azure
Gérer les charges de travail SSIS dans le cloud
Optimize
Il se peut que vous souhaitiez suivre une ou plusieurs des recommandations d’optimisation suivantes au cours de la migration pour vous assurer que votre organisation profite au mieux de son investissement dans Azure.
Déterminer les nouvelles fonctionnalités qui peuvent être disponibles sur la plateforme cible
Restructurer les charges de travail en ensembles plus rentables ou plus performants
Choisissez le niveau de service et le niveau de performances le plus élevé pendant la migration, puis effectuez un scale-down une fois la migration terminée
S’assurer que les charges de travail sont correctement dimensionnées
Réduire la distance entre votre fichier BACPAC et le centre de données de destination
Désactivez les statistiques automatiques pendant la migration.
Tables et index de partition
Supprimer les vues indexées et les recréer une fois la migration terminée
Migrer, valider et corriger
Cette phase implique la migration proprement dite et, surtout, les étapes de validation et les étapes de correction nécessaires pour confirmer la réussite de la migration. Les phases précédentes de planification, d’évaluation et de transformation vous auront permis de vous assurer que tout est prêt à être migré et que tout fonctionnera correctement une fois effectué le déplacement vers Azure. Il ne vous reste plus qu’à préparer les outils de migration nécessaires, à effectuer la migration et à effectuer les validations fonctionnelles et de performances après la migration pour garantir la cohérence avec la base de données source.
Considérations relatives à la migration, à la validation et la correction
Vous pouvez utiliser un large éventail d’outils pour effectuer la migration vers la plateforme cible sélectionnée. Ces outils seront abordés dans d’autres modules. En attendant, il est important de tenir compte des éléments suivants lors de la réalisation de la migration :
- Comprendre vos besoins en charge de travail comme point de départ
- Sélectionner les charges de travail non critiques ou les bases de données de faible priorité pour la migration initialement
- Exécuter un test de migration
- Déterminer si des problèmes affectent la base de données
- Tester le plan pour limiter les risques liés aux temps d’arrêt et aux problèmes de compatibilité
- Évaluer les outils de migration du point de vue de l’interruption pour contribuer à réduire les risques de temps d’arrêt de la base de données
- Itérer continuellement sur votre processus de migration
- Tenir compte des fenêtres de maintenance qui sont disponibles pour l’application et la base de données ciblées pour la migration
- Mettre les anciennes bases de données et applications hors connexion
- Tester les applications tierces
- Créer des plans de reprise d’activité et de maintenance