Comment Engie Solutions a orchestré son « move to cloud »
Engie Solutions a lancé une migration massive de son parc applicatif vers le cloud. Son prestataire Digora s’est chargé de revoir l’architecture de supervision et d’accompagner la migration de quelque 300 bases de données sur AWS, et ce en moins d’un an.
Créée officiellement en janvier 2020, Engie Solutions est une entité d’Engie regroupant l’ensemble des activités du groupe destinées aux collectivités et aux entreprises. Issue du rapprochement de Cofely, Engie Ineo, Engie Réseaux et Axima Réfrigération, cette entité propose un large panel de services liés à la fourniture d’énergies, de préférence renouvelables : gestion des réseaux chauds et froids, production d’électricité et de chaleur sur site (photovoltaïques, chaufferies), mobilité décarbonée, éclairage public, services d’exploitation, de maintenance et d’efficacité énergétique.
La politique cloud du groupe ne date pas d’hier. Engie a engagé une stratégie « cloud first » en 2015 avant de lancer un programme d’accélération en 2018. Mais il n’y a pas un monolithe Engie : il faut voir le groupe telle une galaxie d’entités, de filiales, de services. Historiquement, il n’y a donc pas un SI centralisé, mais des « systèmes complètement hétérogènes », comme l’expliquait Claude Pierre, DSI adjoint en charge des infrastructures et de la cybersécurité, chez Engie, lors de l’événement « Le Réveil Digital d’Engie », au début de l’année 2020.
Dans un premier temps, Engie n’a pas imposé la migration en cloud à ses entités, d’autant que certaines d’entre elles n’ont pas vocation à effectuer ce mouvement. Mais de manière générale, les exigences liées à la transformation numérique, à la réorganisation des activités, à la compétitivité accrue, à la transition écologique, sans parler des éventuelles conséquences de la Covid, semblent avoir accéléré le « move to cloud ».
Projet Jupiter : organiser une migration massive vers le cloud
Pour Engie Solutions, ce passage au cloud s’est formalisé au travers du projet Jupiter, imaginé au cours de l’année 2019. Ce plan de migration a connu une nouvelle étape en juillet 2020 par l’établissement d’un plan budgétaire et du recrutement de ressources externes, selon Matthieu Royer, directeur Infrastructure et Production à la DSI d’Engie Solutions. Engie porte une stratégie multicloud en fonction des besoins métiers (le groupe a choisi le CRM de Salesforce et la suite bureautique de Microsoft), mais a également signé un contrat-cadre avec AWS pour héberger la plupart de ses applications.
Engie Solutions a décidé de remplacer ses infrastructures on premise actualisées en 2016 par les services cloud d’AWS. « D’une part, il y avait le contrat-cadre entre Engie et AWS. D’autre part, nous avions déjà déployé des plateformes sur AWS », explique Matthieu Royer. La DSI d’Engie Solutions appréciait déjà la réactivité du support du fournisseur et son catalogue de services.
Matthieu Royer, directeur de
l’infrastructure et de la production IT,
ENGIE Solutions
Il fallait aller vite. En janvier 2021, il est décidé de lancer la migration des serveurs et des bases de données en lift and shift. La refactorisation attendra.
Après un inventaire exhaustif de son patrimoine applicatif, Engie Solutions a choisi de conserver ses licences Oracle, SQL Server et MongoDB en adoptant l’approche BYOL (Bring Your Own Licence). Elle déploie également des SGBD MySQL et PostgreSQL.
Migrer 300 bases de données, 150 applications, près de 900 serveurs physiques et virtuels n’a rien d’une sinécure. D’autant qu’une telle opération nécessite de maintenir les infrastructures existantes le temps de finaliser la bascule de l’ensemble des services, serveurs, bases de données et applications vers le cloud. La migration a entraîné une hybridation des systèmes, un « double run ».
Une telle migration s’envisage difficilement sans partenaires. Pour la direction et la gouvernance du projet, la DSI a été conseillée par Magellan Consulting. En outre, certaines divisions d’Engie Solution faisaient confiance à Digora depuis 2012 pour le maintien en condition opérationnelle et la supervision, l’administration des serveurs physiques et virtuels, en commençant par ses appliances de bases de données Oracle Exadata. « Au fil des ans, le périmètre a grandi », déclare Florian Pageze, Service Delivery Manager chez Digora. « Nous nous sommes ensuite chargés du monitoring des infrastructures Hyper-V de nos clients, entre autres ».
« Digora est un partenaire de confiance depuis des années », assure Matthieu Royer. Comme nous avons des contrats de bases de données et d’exploitation de niveau 1, il était tout naturel que Digora nous aide et réadapte leurs processus à cette infrastructure cloud ».
Quand Engie Solutions a fait part de sa volonté à Digora de migrer vers le cloud, la société de consultance a proposé ses services d’accompagnement afin de sélectionner les services et les fournisseurs qui auraient pu accueillir les bases de données et les serveurs de l’entité. Digora maîtrise bien la migration des appliances Exadata vers Oracle Cloud Infrastructure (OCI). Il est moins courant que ses clients lui réclament d’effectuer une migration BYOL vers AWS. « C’est sans doute le plus gros projet de migration vers le cloud auquel nous avons participé sur AWS. Nous avons respecté le choix du client », assure Florian Pageze. Ainsi, même si l’expert juge qu’il aurait été intéressant en matière de licences de choisir OCI, Digora a accompagné le mouvement.
« La décision portée par le groupe est logique : une approche multicloud aurait été plus complexe à mener en matière de gestion de licences, de migration et de flux », considère-t-il.
Adapter la supervision des VMs et des SGBD au cloud
Aussi, il fallait mettre en place une nouvelle architecture de supervision pour les serveurs et bases de données cloud. « Il s’agissait d’assister la DSI d’Engie Solutions dans la mise en place du maintien en condition opérationnelle et du monitoring dans la nouvelle plateforme AWS », ajoute-t-il.
Le temps pressait pour Engie Solutions et c’est Digora qui avait déployé et configuré les outils de monitoring existants. « Historiquement, nos infrastructures de supervision étaient également dans le data center à côté des infrastructures Exadata et Hyper-V », rappelle le responsable chez Digora. « Il fallait étudier les flux et toutes les problématiques d’accès, car les accès ne sont pas les mêmes entre les instances sur site et celles dans AWS », ajoute-t-il. Par exemple, les responsables de l’exploitation de niveau 1 chez Digora devaient avoir les privilèges nécessaires pour redémarrer certaines instances dans le cloud.
Digora a porté ses solutions de supervision basées sur Nagios. « Nous avons installé les outils sur AWS », affirme Florian Pageze « Nous sommes passés de quatre serveurs physiques dédiés à la supervision à trois instances EC2 ».
En parallèle, l’équipe de Digora a mis à jour sa plateforme de supervision et mis au point un système d’interrogation des API d’AWS. « Cela nous a permis de segmenter les supervisions en fonction des types d’actifs que nous surveillons, que ce soit des bases de données ou des serveurs », indique le responsable. L’équipe a également automatisé la remontée de données depuis des instances Amazon EC2 et RDS vers Nagios. « Nous avons défini des labels avec le client. Dès qu’une instance EC2 est associée à l’étiquette de supervision Digora, en fonction du niveau de service associé (environnement de production ou non, 24 h/24, cinq jours sur sept), ces informations sont automatiquement provisionnées dans Nagios », explique le responsable. Cette automatisation passe par des scripts combinant du code Perl et Python.
Amazon RDS impose quelques contraintes en matière de supervision. Quand son outillage classique ne permet pas d’obtenir l’information souhaitée, Digora a recours à AWS CloudWatch.
Les spécificités des bases de données Oracle et SQL Server sur AWS
À partir du deuxième trimestre 2021, Digora a accompagné Engie Solutions dans la migration des bases de données. La migration et la mise en place de la supervision ont nécessité la tenue de deux à trois sprints par mois de trois jours chacun, soit un total de 24 sprints sur 52 semaines. Une vingtaine de personnes internes et externes à la DSI d’Engie Solutions sont intervenues sur le projet.
« L’important, c’était que tout le monde travaille de concert, les responsables des applications et des bases de données », affirme Florian Pageze.
« L’important, c’était que tout le monde travaille de concert, les responsables des applications et des bases de données ».
Florian PagezeService Delivery Manager, Digora
« Les équipes du client se sont chargées de la migration d’environ 800 machines virtuelles Hyper-V sur AWS. Nous, nous nous sommes occupés des SGBD », précise-t-il. « Avec l’architecte chez Engie Solutions, nous avons défini les architectures cibles hébergeant les bases de données ».
RDS est compatible avec la plupart des versions des SGBD Oracle. Il y a tout de même quelques exceptions. « Engie Solutions aurait aimé migrer toutes ces bases Oracle vers RDS, mais ce n’était pas forcément possible. Nous avons déployé des instances EC2 pour les instances Enterprise Edition tout en essayant de rationaliser au maximum ce type de déploiement », explique-t-il. « Dans ces cas-là, nous avons installé les middlewares Oracle, effectué les migrations, remis en place des backups », liste Florian Pageze.
Les bases de données PostgreSQL et MySQL ont également été portées sur RDS. MongoDB est utilisé pour une application. Mais les divisions d’Engie Solutions ont majoritairement déployé des bases de données Oracle et SQL Server au fil du temps.
Si l’approche BYOL doit permettre des optimisations de coûts, les licences Oracle et SQL Server impliquent plusieurs contraintes, selon Florian Pageze.
« Pour SQL Server, nous avons déployé des clusters “AlwaysOn”. Historiquement, il y avait des clusters de failovers sur site, mais en allant dans AWS, certaines problématiques nous ont imposé d’adopter SQL Server AlwaysOn », explique-t-il.
« Il est également recommandé par AWS de mettre en place les équivalents des Dataguard pour les bases Oracle afin d’assurer la redondance entre plusieurs zones de disponibilités », évoque le responsable.
En outre, il est conseillé d’utiliser des hôtes dédiés EC2 pour les SGBD sous licence Oracle et SQL Server, une particularité que les responsables du projet chez Digora ont prise en compte au cours de la migration.
« Quand cela n’a pas été fait, nous allons basculer des instances EC2 vers des hôtes dédiés. Nous devons également vérifier si nous n’avons pas attribué trop de ressources dans certains cas, s’il est possible de les mutualiser », détaille le service delivery manager.
Une première étape réussie
Les bénéfices de l’approche « lift and shift » s’accompagnent inévitablement de problématiques liées à l’existant ou à la compatibilité avec l’architecture cible. La DSI d’Engie Solutions en a parfaitement conscience, mais a préféré cette méthode de migration plus rapide qu’un remaniement des bases de données et des applications en amont.
« Nous avons vérifié les performances et les consommations en ressources des instances des bases de données dans le cloud par rapport à l’infrastructure sur site et nous avons essayé de répliquer le modèle côté AWS », déclare Florian Pageze.
C’est exactement ce qu’attendait le client, en tout cas dans un premier temps. Le service delivery manager affirme que le fait de migrer simultanément les bases de données et les applications a fortement contribué au succès de l’opération.
« Nous sommes extrêmement satisfaits, puisque l’impact sur nos collaborateurs et nos clients est quasi nul », se réjouit Matthieu Royer.
Florian Pageze observe surtout des gains d’administration, un phénomène confirmé par Matthieu Royer.
« Nous avons gagné en sérénité, en réactivité. Avec le cloud, nous n’avons plus à nous soucier des problèmes d’infrastructures ».
Matthieu RoyerDirecteur Infrastructure et Production à la DSI d’Engie Solutions
« Nous avons gagné en sérénité, en réactivité. Avec le cloud, nous n’avons plus à nous soucier des problèmes d’infrastructures, de serveurs, de disque dur, de firmware, de mises à jour et nous pouvons nous concentrer sur d’autres tâches. C’est un véritable gain de temps », assure le directeur des infrastructures et de la production.
Prochaines étapes : refactorisation et FinOps
En décembre 2021, Engie Solutions estimait être « à mi-parcours » de son projet. En revanche, selon Florian Pageze, la grande majorité des bases de données ont été migrées. En 2022, les équipes IT s’attelleront à la refactorisation/replateformisation des applications. « Nous allons sélectionner et refactoriser les applications qui le méritent, celles qui sont pérennes, où il y a financièrement un intérêt à le faire », annonce Matthieu Royer.
De son côté, Digora interviendra sur l’intégration de capacités FinOps dans Nagios et dans CloudWatch. « Avec SQL Server, vous avez des instances qui mutualisent plusieurs bases de données. Ce n’est pas toujours la même application qui utilise l’ensemble des bases de données d’une même instance », explique Florian Pageze. « Comme Engie Solutions a plusieurs filiales, ce n’est pas toujours évident de savoir qui consomme quoi et qui paie quoi. À travers le monitoring, nous sommes en train de scripter un flux permettant d’obtenir le volume consommé (en s’appuyant sur les métriques CPU, RAM et stockage) de chaque base de données en fonction des applications, ce qui permet à Engie Solutions de connaître précisément les usages de ses filiales, chose qu’il n’est pas possible de faire avec les outils par défaut d’AWS », annonce-t-il.
Digora se chargera également de mettre à jour les SGBD d’Engie Solutions.
« Il y a tout de même eu quelques mises à jour nécessaires lors de la migration. Nous avons passé des bases Oracle 11.2 dans une version LTS, Oracle 19c, mais pour certaines applications liées à d’autres versions, c’est encore à faire », remarque Florian Pageze.
Toutefois, certains services sur site ne migreront pas en cloud, car ils utilisent des fonctionnalités spécifiques aux instances Exadata. « Sur certaines applications critiques, cela sera compliqué d’avoir exactement la même chose dans AWS. Nous devons étudier les services du fournisseur pour obtenir des équivalents », affirme Florian Pageze. Enfin, certains SGBD sur site seront décommissionnés en fonction de la refactorisation des applications associées.
Matthieu Royer, directeur de
