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