Analyser les critères de décision pour la sélection d’outils et le modèle de migration
Maintenant que nous avons exploré les options relatives aux méthodologies de migration et les options relatives aux outils, nous pouvons explorer les critères de décision à prendre en compte pour exécuter nos migrations vers Serveur flexible Azure Database pour PostgreSQL. Les trois principaux critères qui nous aident à faire nos choix sont le temps d’arrêt, l’emplacement des bases de données sources et la facilité de 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, afin de s’assurer que les contrôles des modifications appropriés et la gouvernance associée sont terminés pour l’activité. Cette planification permet d’entretenir un dialogue avec les principales parties prenantes, afin de connaître la durée pendant laquelle le système peut être hors connexion. Dans ce cas, il est conseillé de savoir combien de temps sont nécessaires à chacune des différentes options. Ainsi, vous pouvez établir des estimations des durées de temps d’arrêt minimales et maximales.
L’établissement du temps d’arrêt minimal nécessaire pour effectuer un basculement d’application est essentiel. Dans les faits, ce temps d’arrêt correspond au délai dont vous disposez pour mettre le système hors connexion, même pour une activité de migration en ligne (ou avec temps d’arrêt minimal). C’est la complexité de l’application qui va dicter cette échelle de temps. Pour une application relativement simple, ce processus nécessitera peut-être uniquement l’arrêt d’un service, la mise à jour d’un fichier de configuration, puis la réactivation du service. Dans des environnements plus complexes, ce processus peut prendre beaucoup plus de temps si plusieurs serveurs et couches d’application sont concernés.
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, suivi de la validation et de la vérification, est votre temps d’arrêt. Ce temps d’arrêt est donc celui qui s’écoule entre le moment où vous désactivez l’application/charge de travail et le moment où vous la réactivez.
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 vers la destination une fois l’application désactivée. Vous devez ajouter à ce temps d’arrêt la validation et les activités de vérification avant de reconfigurer et d’activer l’application/charge de travail.
Une fois que nous avons ces informations, nous pouvons examiner les éléments techniques de la migration afin de nous aider à établir les options viables.
Emplacement des bases de données sources
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 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 quant au type de migration viable.
Si nous avons un grand volume de données à migrer et une bande passante proportionnellement faible, une simple sauvegarde/restauration ne sera probablement pas viable. En revanche, si nous avons un grand volume de données et une bande passante élevée, il y aura moins de problèmes.
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 prendra trop de temps.
L’un des autres facteurs importants à prendre en compte lors de la migration à partir d’autres fournisseurs de cloud est le fait de savoir s’ils facturent les sorties de données. Si c’est le cas, la possibilité de réduire l’empreinte physique des données transférées pourra être un atout. Dans des situations comme celle-ci, la technologie de compression peut être importante pour les sauvegardes 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 Serveur flexible Azure Database pour PostgreSQL. Ces bases de données sources peuvent se trouver dans des machines virtuelles Azure, des conteneurs, ou éventuellement Serveur unique Azure Database pour PostgreSQL. Si c’est le cas, il existe un ensemble différent de considérations à explorer, mais également plusieurs opportunités de tirer profit d’optimisations au sein des services Azure pour ces scénarios.
Possibilités de personnalisation
Le dernier critère à prendre en compte est la quantité de personnalisation nécessaire ou souhaitée. Il pourra s’agir par exemple du besoin de modifier la structure de la base de données source pour prendre en charge la réplication des données, ou encore de la facilité avec laquelle il est possible d’automatiser par le biais de scripts.
Un bon exemple serait l’automatisation de 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 afin de déterminer la meilleure option pour un scénario donné. Lors du choix de la méthodologie et de l’ensemble de technologies à utiliser, il est important de collaborer non seulement avec les parties prenantes de l’entreprise, mais également avec les parties prenantes techniques. Cette collaboration permet d’éviter toute situation où les dirigeants de l’entreprise favorisent une migration avec temps d’arrêt minimal, que l’équipe technique n’est pas en mesure d’implémenter en raison de contraintes de personnel, de ressources ou technologiques.
L’essentiel consiste ici à savoir gérer les attentes de chacun et à avoir un dialogue ouvert et honnête. Il est également important de s’assurer que les dirigeants de l’entreprise assument la responsabilité des tâches de validation qui se trouvent en dehors du mandat des équipes techniques implémentant la migration de base de données. Cette validation peut impliquer des vérifications de cohérence et de validité des données, ainsi que des tests d’expérience utilisateur.