Migrer une infrastructure composée de plusieurs dizaines de serveurs vers des environnements cloud comme ceux proposés par AWS implique de se fixer des objectifs clairs, de recenser précisément l’infrastructure existante et de concevoir une méthodologie pour mettre en place un processus de migration efficace.
Notre client, acteur du secteur des télécommunications, a suivi courant 2018 une procédure minutieuse pour réaliser un audit de ses 72 serveurs (52 serveurs applicatifs pour 8 clusters Hadoop Cloudera) hébergés dans un datacenter interne afin de les migrer vers le Cloud AWS.
Pour l’accompagner dans ce vaste projet dont la complexité et l’ampleur restent souvent sous-estimés, nous avons réalisé un plan de migration personnalisé devant conduire notre client à un transfert de son infrastructure, de ses serveurs et de ses applications, vers le cloud Public AWS dans un délai de 4 mois.
Migrer vers le cloud AWS : analyse du projet, définition des objectifs, planification
L’analyse du projet de migration vers le cloud de notre client et de son environnement informatique, réalisée en plusieurs étapes listées ci-dessous, a permis de faire un état précis sur la composition de son infrastructure :
- Réalisation d’un référentiel et inventaire des serveurs, des systèmes d’exploitation, des bases de données et des applications.
- Audit et analyse détaillée des éléments constituant l’infrastructure technologique.
- Identification du niveau de dépendance entre les applications et l’infrastructure globale.
- Identification des risques et des problèmes potentiels liés au projet de migration.
- Redéploiement des applications au sein de la nouvelle infrastructure en se basant sur la méthodologie 5R.
Au terme de l’analyse, nous avons pu recenser précisément les clusters constituant l’infrastructure, afin de la reconstruire et migrer vers le Cloud AWS les applications et les données dans le délai imparti.
Infrastructure de notre client
Nombre de Serveurs | Serveurs d’applications | Serveurs base de données | Serveurs d’infrastructures |
72 | 52 | 8 | 12 |
- 52 serveurs d’applications : migration de clusters Hadoop Cloudera, dédiés aux traitements et à l’exploitation des données
- 8 serveurs de bases de données : reconstruction des bases de données PostgreSQL vers des bases RDS MySQL d’AWS, via Cloudera Director pour répondre aux besoins d’automatisation
- 12 serveurs d’infrastructures : dont 2 serveurs DNS, 2 serveurs NTP, 2 serveurs Zabbix/ Syslog, 2 serveurs Active Directory, 2 serveurs de fichiers et 2 serveurs Bastions permettant d’accéder à l’environnement cloud (1 windows et 1 linux).
- Systèmes d’exploitation : migration des systèmes d’exploitation CentOS vers Red Hat Enterprise Linux
Cloudera Data Platform, la solution plaît mais à quel prix ?
Dans sa démarche de migrer vers le cloud AWS une partie conséquente de son infrastructure, notre client avait préalablement formulée les attentes suivantes :
- Pouvoir répondre à des exigences d’analyse de rentabilité financière sur l’ensemble de son infrastructure.
- Réduire significativement le coût de possession (TCO) en virtualisant l’ensemble de l’infrastructure dans le cloud AWS.
- Gagner en flexibilité sur l’administration et la gestion de l’infrastructure.
- Faire monter en compétences l’ensemble des équipes sur la nouvelle infrastructure et sur les applications, pendant le processus de migration.
- Bénéficier de services cloud puissants afin de limiter l’impact de la migration vers AWS sur l’activité de l’entreprise.
- Permettre d’augmenter et diminuer facilement les ressources serveurs en fonction des besoins et des pics de demande.
- Augmenter la disponibilité des applications et créer un plan de reprise d’activité (PRA).
Redéploiement des applications au sein du cloud AWS en 5 étapes : la méthodologie 5R
Selon le type de projet, des modèles de migration alternatifs peuvent être envisagés pour migrer vers le cloud des applications et leurs données. La méthodologie 5R initialement avancée par l’institut Gartner et que nous avons adaptée au projet de notre client, permet d’y répondre selon les cas de figure (migration partielle, migration totale, en plusieurs phases échelonnées dans le temps, etc.).
Ré-hébergement de l’infrastructure vers le cloud (REHOSTING)
Au cours de cette phase, nous avons procédé au ré-hébergement de 46 serveurs d’applications. Cette réalisation en deux étapes, n’a impliqué presque aucun changement au niveau des applications elles-mêmes.
Une fois le cap franchi de la migration des serveurs d’applications, des données et du trafic dans le cloud AWS, le premier retour d’expérience positif des équipes internes chez notre client, concernait le processus d’optimisation des applications, dorénavant simplifiée. Financièrement, notre client a pu constater assez rapidement une baisse du TCO de ses applicatifs (coût de possession) de l’ordre de 15 %.
A noter que la majeure partie des projets qui consistent à repenser l’hébergement de l’infrastructure au sein d’un environnement cloud, peuvent être automatisés à l’aide d’outils tels AWS Migration Hub, AWS Server Migration Service, AWS Database Migration Service, Zerto Replication and Recovery, Veeam Cloud Connect et d’autres encore.
En plus du rehosting AWS, nous avons mis en place une réplication des serveurs et des données critiques vers le datacenter ISO 27001 de Cyrès (basé Tours) permettant un redémarrage des applicatifs en moins de 4h, sans perte de donnée, en cas d’incident majeur.
Redéploiement de services vers des plateformes plus innovantes (REPLATFORMING)
Pour permettre à la nouvelle infrastructure de gagner en puissance, nous avons redéployé une partie des bases de données vers de nouvelles plateformes.
Pour se faire, nous avons envisagé la reconstruction des services de bases de données relationnelles PostgreSQL sur de nouvelles bases de données RDS (Related Database Services) MySQL de AWS.
L’étape de migration des données vers les nouveaux clusters a permis de reconstruire dans leur intégralité les bases de données dans le nouvel environnement AWS.
Par ailleurs, concernant les applications, le processus de reconstruction vers les nouvelles plateformes aura été presque transparent avec un délai d’interruption relativement court.
En redéployant de cette façon 7 bases de données vers des plateformes (RDS) conçues et adaptées pour ce type de migration, il a été constaté par les équipes informatiques que le temps consacré à l’administration et à la gestion des nouvelles instances de bases de données avait significativement baissées. L’avantage étant également de ne pas avoir eu besoin de modifier l’architecture des applications lors de cette opération de migration.
Révision et optimisation de l’architecture Cloud (REFACTORING)
Afin d’implémenter de nouvelles fonctionnalités demandées par le client, nous avons remanié une partie de l’architecture cloud et réorganisé certains services applicatifs. Ce qui jusqu’ici n’était pas envisageable avec l’ancienne infrastructure.
Grâce aux fonctionnalités natives du cloud AWS, notre client a pu passer à une architecture beaucoup plus orientée sur des services, tout en atteignant des performances et une agilité jusque là inégalées.
Cette phase du projet de migration, même si elle ne concernait finalement qu’une partie de l’infrastructure de départ, aura contribué à améliorer le déroulement de l’activité de notre client.
Nos services managés sur la plateforme AWS Cloud
Rétention de services sur le site primaire (RETAIN)
Le cycle de migration, réalisé sur une période de 4 mois, a été pensé de manière graduelle afin de basculer progressivement l’ensemble des applications de notre client vers son nouvel environnement cloud AWS.
Au sein de ce projet visant à migrer vers le cloud l’infrastructure de notre client, seuls les services et applications essentiels à l’activité de l’entreprise ont été migré vers AWS au cours des deux premiers mois du projet (dans notre schéma : Ré-hébergement – Phase 1). Les autres applications ont vu leurs migrations étalées sur les deux derniers mois du projet (dans notre schéma : Ré-hébergement – Phase 2), de sortes à ne pas densifier le processus de migration des applications prioritaires et leur intégration dans le nouvel environnement.
Au final, seuls 4 serveurs d’infrastructure auront été maintenus sur site et sans que cela n’engendre de coûts supplémentaires. Cela inclue les applicatifs/serveurs dont la latence réseau entre l’utilisateur et le serveur a un fort impact sur les performances.
Rationalisation de l’environnement et décommissionnement (RETIRE)
En parallèle de toutes ces actions, nous avons rationalisé les applications du client en vue de les migrer vers le cloud AWS. Le plan de décommissionnement visait à limiter le nombre de serveurs d’applications au profit de services managés d’AWS, en procédant à leur mise hors service. A l’arrivée, 8 serveurs d’application et 1 serveur de base de données ont été supprimé et totalement décommissionnés à la fin de la migration.
Ce retrait de serveurs a permis de réaliser des économies sur les coûts d’hébergement et enfin, d’améliorer la rentabilité globale de la nouvelle infrastructure.
Migrer vers le cloud AWS en 5 phases : les bénéfices additionnels
Outre les bénéfices évoqués, concevoir un plan de basculement en 5 phases et migrer vers le cloud une partie conséquente de l’infrastructure, aura apporté à notre client les bénéfices additionnels suivants :
- Economies sur les frais annuels de licences, de support et de maintenance de l’infrastructure en exécutant ses systèmes sur AWS.
- Réduction des délais de mise en œuvre de nouveaux services informatiques par les équipes internes, dû aux nouvelles fonctionnalités dorénavant accessibles via le nouvel environnement AWS.
- Gain de performances global permettant, à titre d’exemple, de mettre en service une infrastructure dans un délai très court (quelques heures seulement), sécurisé et en haute disponibilité.
- Capacité de l’infrastructure à supporter de fortes charges de travail ou pics d’affluence.