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