Phases et considérations sur la migration

• 8 minutes

Une migration réussie équilibre les considérations sur plusieurs phases.

Phases de migration

Les migrations se produisent en plusieurs phases. Tout d’abord, planifiez l’étendue de la migration : découverte et évaluation des ressources de base de données, exigences métier telles que les temps d’arrêt et plan de secours en cas d’échec de la migration. Ensuite, préparez la migration en approvisionnant les ressources appropriées et en configurant la connectivité entre les environnements source et cible. Une fois l’approche de migration définie et les ressources prêtes, vous souhaitez généralement effectuer un test dans un environnement intermédiaire pour identifier les problèmes avant la migration de production. Enfin, effectuez la migration finale et validez sa progression continue et sa réussite.

Ce module se concentre sur les phases de préparation (2) et de migration finale (4, 5).

Considérations relatives à la migration

Vous devez évaluer les exigences relatives au temps d’arrêt de l’application, à la compatibilité des versions, à la mise en réseau et à la sécurité, aux performances, au coût et à la continuité de l’activité.

Temps d’arrêt de l’application

L’un des premiers aspects que vous devez prendre en compte est le temps d’arrêt que votre scénario d’entreprise peut prendre en charge. La réponse limite fortement vos options de migration disponibles.

Le meilleur temps d’arrêt est celui que les utilisateurs ne remarquent pas. Dans la pratique, les migrations sont des procédures complexes et les décisions relatives aux considérations de ce module dictent le temps d’arrêt requis. Les compromis incluent la disponibilité par rapport au coût et au risque de la migration. En raison de la complexité liée à la réduction du temps d’arrêt en minutes ou même en secondes, il est important de tester les hypothèses et de déterminer le temps d’arrêt acceptable pour la migration.

Migrations hors connexion

Avec une migration hors connexion, vous devez arrêter l’application pour déplacer la base de données. Cela garantit qu’il n’y aura aucune modification des données pendant la migration. Toutefois, cette approche nécessite de mettre fin à la base de données pour finaliser l’exportation des données. Au minimum, le temps d’arrêt sera aussi long que nécessaire pour transférer les données. Une migration hors connexion implique :

1. La déconnexion de toutes les applications de la base de données source.
2. L’exportation du contenu de la base de données source.
3. L’importation des données sources dans la base de données cible.
4. La reconnexion des applications à la base de données cible une fois l’importation terminée.

Certaines applications ont planifié des fenêtres de maintenance pendant des périodes de faible trafic. Il s’agit d’excellents moments pour effectuer des migrations hors connexion.

Une migration hors connexion incrémentielle réduit le temps d’arrêt en déplaçant la majeure partie des données avant de mettre l’application hors connexion. Tout d’abord, migrez une sauvegarde complète de la base de données. Ensuite, migrez les modifications apportées à la base de données depuis la migration précédente. Lorsque le temps nécessaire à la migration de ces nouvelles modifications correspond à votre temps d’arrêt acceptable, placez l’application hors connexion pour figer les données et finaliser la migration. Il est possible que vous constatiez qu’un incrément de migration unique est suffisant pour réduire les temps d’arrêt par ordre de grandeur ou plus, en particulier pour les bases de données ayant plusieurs années d’historique. Pour les bases de données volumineuses et chargées, il est possible que vous deviez migrer plusieurs incréments pour atteindre un temps d’arrêt acceptable.

Migrations en ligne

Avec une migration en ligne, vous pouvez réduire considérablement ou même éliminer le besoin de temps d’arrêt en répliquant les modifications du serveur source vers le serveur cible pendant la migration, puis en effectuant un transfert vers le serveur cible lorsque la réplication est entièrement synchronisée.

Parfois, les temps d’arrêt sont indésirables ou même inacceptables. Dans ce cas, il est impossible de « figer » l’état de la base de données en désactivant l’application. Au lieu de cela, la base de données source est répliquée dans la base de données cible pendant les opérations normales. Lorsque la cible est entièrement rattrapée par la source, l’application est transférée vers la base de données cible.

Une migration en ligne nécessite que vous :

1. Commenciez à répliquer la base de données source vers la base de données cible.
2. Lorsque la base de données cible est rattrapée, figez la base de données source en suspendant l’application ou en forçant les écritures à échouer en activant le mode Lecture seule.
3. Lorsque la base de données cible est intégralement mise à jour d’après les modifications, désactivez la réplication dans la cible.
4. Redirigez tous les clients vers la base de données cible et reprenez les opérations.
5. Arrêtez la base de données source héritée.

Comparer les migrations en ligne et hors ligne

Bien que les migrations hors connexion nécessitent un temps d’arrêt, la technique de migration incrémentielle antérieurement évoquée réduit considérablement les temps d’arrêt. Plusieurs incréments peuvent raccourcir la migration finale d’une journée de données ou moins. Les services automatisés comme Azure DMS réduisent les temps d’arrêt en effectuant une série de migrations toujours plus petites. Les migrations hors connexion incrémentielles peuvent également être effectuées manuellement si les paramètres réseau empêchent l’automatisation.

Les migrations en ligne coordonnent une opération délicate entre les équipes de base de données et d’applications. Les applications clientes doivent être outillées pour réagir correctement aux échecs d’écriture afin d’éviter la perte de données pendant la migration. Les clients doivent également prendre en charge la connexion à un nouveau serveur de base de données sans interrompre l’expérience utilisateur. Si cet outil d’application n’existe pas déjà, il peut être assez coûteux de le générer.

Compatibilité des versions

La plupart des opérations d’application sont compatibles avec les mises à niveau MySQL. Toutefois, dans certains cas, les composants d’application ou l’utilisation de la base de données peuvent uniquement fonctionner avec certaines versions de MySQL.

Vérifiez que tous les composants d’application sont compatibles avec la version de la base de données cible. Envisagez de séparer les mises à niveau de version des migrations qui déplacent ou reconfigurent une base de données. Par exemple, si vous migrez de MySQL 5.7 local vers un serveur flexible Azure Database pour MySQL exécutant MySQL 8.0, envisagez de migrer d’un serveur local vers un serveur flexible Azure Database pour MySQL exécutant MySQL 5.7, puis de mettre à niveau de 5.7 à 8.0 sur place.

Le réseau et la sécurité

Les migrations de base de données nécessitent le transfert de données de la base de données source vers la cible. La façon dont cela se produit et la rapidité dépendent en grande partie de la connexion entre les deux réseaux. Si vous ne pouvez pas établir une connexion dynamique de la source à la cible, vous devez transférer les fichiers de données physiques d’une autre façon, par exemple via une station de travail ou un serveur intermédiaire. Dans ce cas, assurez-vous d’avoir suffisamment d’espace disque pour stocker les instantanés sur chaque système au cours du processus.

Il est également essentiel de prendre en compte les exigences de sécurité pendant la migration. Vous aurez besoin de l’authentification et des autorisations appropriées pour les bases de données sources et cibles. Vous pouvez également créer des comptes de service pour effectuer certaines ou toutes les étapes de migration, puis supprimer leur accès à la fin.

Que la base de données source soit locale ou située sur un autre fournisseur de cloud, les paramètres réseau n’autorisent généralement pas les connexions externes. Vous devez configurer le réseau pour autoriser les connexions avec Azure.

Si la base de données source est locale et que le volume de données est grand, le déplacement de téraoctets de données sur une connexion Internet standard peut être peu pratique. Dans ce scénario, envisagez de configurer une connexion Azure ExpressRoute entre votre réseau et Azure.

Même si vous utilisez un ExpressRoute, la connexion sur laquelle il est activé servira probablement également d’autres trafics, et les deux peuvent interférer entre eux. Selon la contention, l’impact sur les performances des applications existantes et du processus de migration peut être significatif.

Performances

Les migrations de base de données constituent une excellente occasion d’augmenter la capacité en redimensionnant l’infrastructure. L’utilisation de votre base de données peut tirer parti de ressources du processeur, de RAM ou d’E/S accrues.

Avant d’approvisionner votre serveur cible, tenez compte de l’utilisation actuelle de votre base de données. Supervisez les métriques de performances telles que l’utilisation du processeur, ainsi que la croissance prévue et les contrats SLA pour décider si vous devez allouer une plus grande taille de calcul. À l’inverse, vous constaterez peut-être que votre capacité est surutilisée et que les réductions de taille économisent les coûts.

Cost

Lorsque vous migrez vers Azure, vous pouvez tirer parti de la tarification transparente. À l’aide de votre référence SKU sélectionnée et d’autres paramètres tels que la redondance et la haute disponibilité, la calculatrice de prix Azure vous permet d’estimer vos coûts post-migration pendant la planification. Vous pouvez également utiliser la calculatrice pour établir les compromis, tels que la disponibilité et le coût.

Continuité des activités

Les migrations de base de données sont un bon moment pour passer en revue les métriques et objectifs de continuité d’activité. Il peut être approprié de modifier les stratégies de rétention de sauvegarde ou de passer à des sauvegardes géoredondantes ou à une haute disponibilité. Tenez compte de votre durée de bon fonctionnement historique par rapport au temps de récupération du contrat SLA et après panne. Les migrations fournissent également des exemples réels de mise en place d’une nouvelle base de données à partir de fichiers de données physiques, qui peuvent informer les plans de récupération d’urgence.