The Doppler Quarterly (FRANÇAIS) Printemps 2016 - Page 13

base de données, puis de la restaurer dans AWS sur un serveur de base de données entièrement nouveau. Pendant la période de migration et de basculement, tous les points de terminaison de l’appli- cation étaient mis à jour de manière à pointer vers les nouveaux serveurs et bases de données dans AWS. Voici les étapes de migration appli- quées pour les deux applications : 1. Création de serveurs clonés dans AWS à l’aide d’une solution de réplication de disque. Pour les serveurs Windows, nous avons utilisé un réseau isolé dans AWS pour éviter tout problème avec l’ID source, le nom et le DNS au niveau du réseau de production, et seul l’accès RDP a été autorisé sur le serveur au moyen d’un compte administrateur local temporaire créé avant le clone. 2. Diverses étapes de préparation des serveurs incluant la mise à jour du fuseau horaire et l’installation d’un logiciel de surveillance. 3. Création de clones pour les serveurs de base de données pendant la migration. 4. Déploiement d’un cluster Linux à deux nœuds avec HAProxy et logiciel keepalive pour chacune des applications. 5. Mises à jour de la confi guration de l’application : Pour l'application 1 Mise à jour de la confi guration du cluster logiciel afi n de refl éter les nouvelles adresses IP et les con- trôleurs de domaine locaux AWS. Pour les serveurs de l’application 2 Mise à jour des noms d’hôte et des confi gurations de serveur Web de sorte qu’ils soient agnostiques aux adresses IP et suppression de la confi guration du réseau agrégé personnalisé. Plusieurs séries de tests d’applications ont été réal- isées au niveau des serveurs clonés, et l’équipe d’application a notam- ment testé tous les points de termi- naison, l’interaction des bases de données, la validation du contenu de stockage ainsi que l’ensemble des scripts. Une fois les serveurs prêts dans AWS, nous avons suivi ces étapes pendant la période de migration : 1. Mise à jour des groupes de sécurité AWS afi n de permettre aux serveurs Windows de communiquer avec le réseau de production et les contrôleurs de domaine. 2. Synchronisation fi nale des données NFS avec le nouveau serveur NFS basé sur AWS. Démontage des anciens points de montage NFS et montage des nouveaux volumes NFS basés sur AWS. Cette étape a été réalisée de façon incrémentielle sur chacun des serveurs de manière à permettre la coordination avec la confi guration du pool d’équilibrage de charge et ainsi éviter tout temps d’arrêt. 3. Mise à jour des équilibreurs de charge Citrix Netscaler et HAProxy avec les anciens serveurs et les nouveaux serveurs dans AWS et mise à jour du pool depuis les anciens serveurs vers les nouveaux serveurs en testant chacun d’entre eux dans le pool d’équilibrage de charge. 4. Mise à jour des DNS externe et interne. Comme la confi guration en cours de l’équilibreur de charge Citrix Netscaler était intacte, les demandes de l’application ont pu être satisfaites alors même que les changements DNS étaient propagés. 5. Une fois le traitement des demandes de l’application par les nouveaux serveurs validé, effacement des données des anciens serveurs et retrait de ceux-ci du pool d’équilibrage de charge. 6. Arrêt des services d’application sur les anciens serveurs. 7. Mise à jour de la règle de groupe afi n de rétablir le paramètre appliqué avant la migration. 8. Après validation des tests, lancement du processus de mise hors service. Pour mettre en œuvre une migra- tion sans temps d’arrêt, il nous a fallu, au-delà de l’architecture technique et de l’approche, réaliser une analyse approfondie des appli- cations et valider leur comporte- ment à l’aide de tests. Il est égale- ment primordial d’effectuer la migration dans les environnements de développement et de prépro- duction avant de la mettre en œuvre dans l’environnement de production. Enfi n, une gestion de projets effi cace, une implication active des tiers et une communica- tion régulière contribuent forte- ment à la réussite d’une telle migration. Finalement, Avid a réussi à mettre en œuvre une migration sans temps d’arrêt dans AWS. L’équipe du cli- ent, quant à elle, a profi té de l’anal- yse, la documentation et des tests approfondis pour acquérir une par- faite connaissance de ses applica- tions. Pour bon nombre d’entreprises, cette analyse et les découvertes qu’elle implique peuvent être tout aussi profi tables que la migration elle-même. PRINTEMPS 2016 | THE DOPPLER | 11