Analyser les critères de décision pour la sélection d’outils et le modèle de migration

Effectué

Maintenant que nous avons exploré les options pour les méthodologies de migration et les options d’outils, nous pouvons explorer les critères de décision à prendre en compte pour exécuter nos migrations vers un serveur flexible Azure Database pour PostgreSQL. Les trois principaux critères qui nous aident à faire nos choix sont temps d’arrêt, emplacement de base de données sourceet Personnalisation.

Temps d'arrêt

Le temps d’arrêt est une facette essentielle des activités de migration et la durée acceptable pour les parties prenantes nous aide à décider si nous devons effectuer une activité de migration hors connexion ou en ligne.

Normalement, les activités de migration sont planifiées bien à l’avance pour s’assurer que les contrôles de modification appropriés et la gouvernance associée sont terminés pour l’activité. Cette planification permet à une boîte de dialogue avec les parties prenantes clés de comprendre la durée pendant laquelle le système peut être hors connexion. Dans cette situation, il est conseillé de connaître la durée nécessaire pour les différentes options afin d'établir des durées minimales et maximales estimées de temps d'arrêt.

L’établissement du temps d’arrêt minimal nécessaire pour effectuer un basculement d’application est clé. En fin de compte, cette fois-ci représente la durée pendant laquelle vous devez mettre le système hors ligne, même pour une activité de migration en ligne (ou avec un temps d'arrêt réduit). La complexité de l’application va dicter cette échelle de temps. Pour une application relativement simple, ce processus peut être un cas d’arrêt d’un service, de mise à jour d’un fichier de configuration, puis de le réactiver. Dans des environnements plus complexes, ce processus peut prendre beaucoup plus de temps s'il y a plusieurs serveurs et couches d'application en jeu.

Comprendre la durée nécessaire pour les activités de migration en ligne ou hors connexion est l’élément important suivant lié au temps d’arrêt. S’il s’agit d’une migration hors connexion, le temps nécessaire pour extraire, transférer et charger les données de la source vers la destination suivie de la validation et de la vérification est votre temps d’arrêt. Ce temps d’arrêt est ensuite sandwich entre le temps nécessaire pour désactiver l’application/la charge de travail et le temps nécessaire pour réactiver l’application/la charge de travail.

S’il s’agit d’une migration en ligne (temps d’arrêt minimal), le temps d’arrêt est la durée nécessaire pour synchroniser les dernières modifications de la source à la destination une fois l’application désactivée. Ajoutez-y un temps d’arrêt, la validation et les activités de vérification avant de reconfigurer et d’activer l’application/la charge de travail.

Une fois que nous avons ces informations, nous pouvons examiner les éléments techniques de la migration pour vous aider à établir les options viables.

Emplacement de la base de données source

L’emplacement source des bases de données à migrer joue un rôle en raison des contraintes susceptibles d’être en place pour une configuration donnée.

Sources locales ou non Azure

Pour une base de données locale ou non Azure, la contrainte de clé est généralement la connectivité réseau entre la source et la cible. Les trois points à prendre en compte ici sont la bande passante, la latence et le volume de données. Une fois que nous comprenons ces points, nous pouvons prendre une décision éclairée sur le type de migration viable.

Si nous avons un grand volume de données à migrer et une quantité proportionnellement faible de bande passante, un vidage et une restauration simples ne seront probablement pas viables. Alors que si nous avons un grand volume de données et une grande quantité de bande passante, il s’agit moins d’un problème.

De même, s’il s’agit d’une migration en ligne où la synchronisation des données aura lieu, la latence est l’un des facteurs clés. Si la latence est élevée, il peut y avoir des répercussions négatives sur les performances du système, car le processus de synchronisation prend trop de temps.

L’un des facteurs importants à prendre en compte lors de la migration à partir d’autres fournisseurs de cloud est de savoir s’ils facturent des sorties de données. Si c’est le cas, il est possible de réduire l’empreinte physique des données transférées. Dans des situations comme celle-ci, la technologie de compression peut jouer un rôle important pour les dumps ou les flux de données utilisés pour la synchronisation.

Autres services Basés sur Azure

Il existe des situations où vous souhaitez migrer d’autres services Basés sur Azure vers un serveur flexible Azure Database pour PostgreSQL. Ces bases de données sources peuvent se trouver dans des machines virtuelles Azure, des conteneurs ou éventuellement un serveur unique Azure Database pour PostgreSQL. Si c’est le cas, il existe un ensemble différent de considérations à explorer, mais en même temps, plusieurs opportunités d’optimisations au sein des services Azure pour ces scénarios.

Capacité de personnalisation

La dernière zone de considération est la quantité de personnalisation nécessaire ou souhaitée. Cette considération peut prendre la forme de la nécessité de modifier la structure de base de données source pour prendre en charge la réplication des données, sinon, cela peut signifier la facilité d’automatisation par le biais de scripts.

Un bon exemple serait d'automatiser la migration hors connexion d'une base de données via pg_dump et pg_restore, tout en incluant la compression et la décompression des fichiers de sauvegarde.

Prise de décision

Maintenant que nous avons suivi le processus de collecte de toutes ces informations, nous pouvons collaborer avec les parties prenantes pour déterminer la meilleure option pour un scénario donné. Lorsque vous prenez la décision sur la méthodologie et la technologie définies pour l’utiliser, il est important non seulement de travailler avec les parties prenantes de l’entreprise, mais aussi les parties prenantes techniques. Cette collaboration permet d’éviter une situation où l’entreprise favorise une migration de temps d’arrêt minimal, que l’équipe technique n’est pas en mesure de fournir en raison de contraintes de personnel, de ressources ou de technologies.

La chose clé ici est de gérer les attentes et d’avoir un dialogue ouvert et honnête. Il est également important de s’assurer que l’entreprise prend possession des tâches de validation qui se trouvent en dehors du mandat des équipes techniques qui fournissent la migration de base de données. Cette validation peut impliquer des vérifications de cohérence et de validation des données et des tests d’expérience utilisateur.