The Doppler Quarterly (FRANÇAIS) Printemps 2016 | Page 12

Les plateformes et systèmes d’exploitation
étant différents pour chaque application,
nous devions adopter deux approches
de migration différentes.
héritées des applications et, plus
important encore, la diffi culté de
confi gurer les différents com-
posants de manière à reproduire à
l’identique les systèmes de produc-
tion
existants
représentaient
autant de défi s auxquels nous
étions confrontés.
L’idée de cloner les serveurs selon
une approche « lift-and-shift »
nous a alors parue plus judicieuse
qu’une installation entièrement
nouvelle. Les plateformes et sys-
tèmes d’exploitation étant dif-
férents pour chaque application,
nous devions adopter une approche
différente pour chaque migration.
Nous avons effectué une analyse
approfondie du portefeuille de
façon à identifi er tous les points de
terminaison et toutes les dépen-
dances pour chacune des applica-
tions. La présentation suivante
décrit les défi s uniques et la façon
dont nous les avons relevés.
Défi s de l’application|1
• Confi ance du domaine et mots
de passe de l’ordinateur
Dans un environnement Active
Directory, les serveurs Windows
utilisent différents mécanismes
pour l’authentifi cation mutuelle, et
notamment un ID source unique
10 | THE DOPPLER | PRINTEMPS 2016
par serveur et un mécanisme de
mise à jour des mots de passe de
l’ordinateur. Les mots de passe
sont régulièrement mis à jour et
le contrôleur de domaine autorise
ou refuse l’accès. Comme nous
avions besoin d’un peu de temps
pour préparer les serveurs dans
AWS, nous avons utilisé une
règle de groupe pour désactiver
temporairement le mécanisme de
mise à jour des mots de passe et
éviter tout problème de confi ance
au niveau du domaine.
Lors de nos tests, nous avons
également constaté que les
ELB AWS ne convenaient pas à
cette application en raison d’une
incompatibilité avec les CNAME,
des exigences du nom principal
de service et de la redirection
des URL. Nous avons donc utilisé
un équilibreur de charge Linux
avec HAProxy et keepalive pour le
clustering.
Défi s de l’application|2
• Applications existantes et sites
Web
• Absence de documentation
correspondant à la
confi guration
• Adresses IP codées en dur
• Absence de documentation et
de connaissances concernant
différents scripts
Tout le contenu disponible via
l’application était hébergé sur une
appliance de stockage Netapp
au moyen du protocole NFS. Le
contenu, qui s’élevait à plusieurs
To, devait impérativement être
ancré, synchronisé et disponible
dans AWS pour la migration.
Nous avons utilisé une appliance
virtuelle NAS comme serveur
NFS dans AWS et utilisé rsync
pour ancrer et synchroniser de
façon continue le contenu. Le
contenu étant principalement en
écriture unique et en lecture, la
synchronisation initiale a demandé
beaucoup plus de temps que les
synchronisations incrémentielles
régulièrement exécutées pendant
la période de migration.
L’application s’appuyait également
sur les redirections d’URL au
niveau de l’équilibreur de charge.
Par conséquent, il n’était pas
possible d’utiliser les ELB AWS.
Comme pour l’application 1, nous
avons utilisé un équilibreur de
charge Linux avec HAProxy et
keepalive pour le clustering.
Approche de la migration
La migration lift-and-shift impli-
quait de répliquer les serveurs dans
AWS à l’aide d’une solution de répli-
cation de disque, de sauvegarder la