Essilor a engagé une démarche de consolidation et de virtualisation qui va aboutir, en 2009, à une division par cinq du nombre de serveurs. Une approche économiquement avantageuse, même s’il faut s’armer de patience pour convaincre la finance, les études et l’exploitation.
Quelle est votre approche de la consolidation chez Essilor ?
Marc Giraud La consolidation correspond à plusieurs opérations successives. La première consiste à effectuer des rapprochements géographiques.
Cette approche répond à l’objectif de gagner de la facilité dans l’exploitation des systèmes. Il est en effet plus facile d’avoir une salle machines à l’état de l’art pour la qualité des systèmes, la redondance des matériels, la sécurité et la robustesse (alimentation, climatisation, protection contre les intrusions…).
Seconde raison qui milite en faveur de la consolidation : elle permet de faciliter le travail de tous les différents intervenants, notamment pour la maintenance. Les équipes qui en sont responsables sont, par définition, plus performantes lorsque les infrastructures et les équipes techniques sont localisées au même endroit que lorsque les sites sont multiples.
On peut, en outre, bénéficier d’effets d’échelle pour obtenir de meilleures conditions en matière d’achats, d’environnements et de services. Il en est de même pour la gestion technique des applications, qui devient, elle aussi, plus aisée, par exemple pour les mises à jour de systèmes d’exploitation ou d’hyperviseurs.
La seconde opération consiste à consolider dans quelques grosses machines ce qu’il y a dans une multitude de petites. Nous avons ainsi démarré sur notre parc de serveurs AS/400 et, plus récemment, nous nous sommes intéressés aux architectures Windows, qui sont des architectures très préoccupantes en termes de prolifération des technologies. Et le mot « prolifération » n’est vraiment pas abusif !
Quels sont ces facteurs d’inflation ?
Marc Giraud La structure même des applications, qu’elles soient en .Net ou en Java, repose sur du multiniveaux (3-tier). De façon légitime, on a tendance à positionner chacun de ces niveaux sur des plates-formes physiques différentes.
Ce comportement est d’ailleurs encouragé par les éditeurs qui préfèrent avoir la main plus lourde que légère sur le nombre de serveurs nécessaires pour faire fonctionner leurs applications, et pour éviter que les clients ne les critiquent sur les problèmes de performances. En outre, il faut de la redondance : par exemple, dans les architectures Web, on peut « s’offrir le luxe » d’avoir plusieurs serveurs en parallèle, soit parce que l’on a besoin de puissance, soit parce que l’on veut être en confiance pour être sûr d’assurer un service proche du continu.
Un autre facteur d’inflation est l’ardente nécessité que les changements de versions de logiciels soient le moins perturbateurs possible pour nos clients internes.
Pour cela, il faut donc s’entourer d’un certain nombre de précautions. Parmi celles-ci, il importe de disposer d’un environnement d’intégration similaire à celui de production, ce qui est coûteux pour simuler le changement de version « à blanc », pour être certain que les résultats soient les mêmes sur les deux environnements.
Ensuite s’expriment des besoins d’environnements hors production, et ils sont nombreux ! Ainsi, il est courant, pour une application importante, d’avoir de huit à douze environnements distincts, qui ne sont pas pour autant intégralement la réplique de l’environnement de production, sauf l’environnement d’intégration.
Pourquoi vous faut-il autant d’environnements ?
Marc Giraud Nous devons permettre à plusieurs équipes de travailler simultanément sur ce qui est leur cœur de métier. Par exemple, en régime de croisière, les équipes de tierce maintenance applicative ont besoin d’un environnement spécifique et d’un environnement de type « bac à sable » pour le paramétrage technico-fonctionnel, afin que la maîtrise d’ouvrage teste ces nouveaux paramètres, ainsi que leurs conséquences sur le comportement du système.
De même, les équipes qui travaillent sur des évolutions de versions ont besoin d’environnements de développement. Et il faut également un environnement de benchmark, un autre pour la formation… Tout cela est par nature inflationniste. Si l’on se contente de travailler sur des architectures uniquement physiques, on obtient des taux de croissance effrayants…
En nombre de serveurs, cela peut atteindre les + 30 % par an ! Autant de machines qu’il faut installer, configurer, héberger, maintenir et refroidir… C’est colossal en termes de ressources consommées. On a donc envie de faire mieux ! Pour notre projet de virtualisation en environnement Windows, plusieurs centaines de serveurs sont concernés.
Il y a donc des enjeux économiques élevés pour le coût du projet de migration. Si seulement quelques serveurs sont en jeu, cela ne pose pas de problème, mais dès lors qu’ils sont plusieurs centaines, il importe d’opérer de façon industrialisée et organisée.
Quel bilan économique en tirez-vous ?
Marc Giraud Nos clients internes (les filiales, les unités de production, les centres de recherche…) sont facturés pour les services que nous leur délivrons : la consolidation n’est pas une opération décidée « par le haut » mais bien par ces clients internes. Il faut donc leur démontrer l’utilité d’une telle opération, avec des arguments qui ne soient pas uniquement stratégiques mais avant tout économiques.
En ce qui nous concerne, le bilan économique est plutôt flatteur. Si l’on prend l’exemple de notre système de distribution européen, même en étant modeste sur les évolutions des coûts locaux, en négligeant les coûts des mètres carrés, de l’électricité, pourtant un poste de dépenses significatif, de l’eau pour la climatisation, et du temps passé par les équipes locales, la rentabilité économique était évidente en faveur de la centralisation.
Auparavant, nous avions un centre de calcul par filiale et, pour les applications de distribution, nous avons centralisé les serveurs qui étaient en France, situé dans chacun de nos centres de prise de commande et de fabrication. Rien que la première étape, qui a consisté à déplacer les serveurs, sans en réduire le nombre, pour les regrouper sur un seul site, s’est révélée économiquement intéressante.
Comment procédez-vous pour démontrer ces avantages ?
Marc Giraud Pour arriver à réaliser un business case en matière de virtualisation, nous pouvons bien sûr mettre en avant des avantages qualitatifs. Cependant, ceux-ci ont une portée qui n’est pas toujours aussi importante que l’on ne l’imagine a priori. Car il faut aussi satisfaire la voracité du moloch financier !
Autrement dit, présenter des business cases en bonne et due forme dans lesquels sont démontrés un retour sur investissement rapide et des bénéfices élevés en rythme de croisière. Les éléments qualitatifs sont indispensables mais personne n’y croira, même si l’on peut les chiffrer : n’est-ce pas le promoteur du projet qui les met en avant ? N’en surestime-t-il pas les bénéfices ? Ne minimise-t-il pas les coûts et les difficultés ? Vis-à-vis de la direction financière, il faut du concret et affirmer que ces éléments « qualitatifs » vont se traduire aussi par des éléments financiers mesurables a posteriori qu’il faut exhiber !
Comment réagit la direction financière en face de projets de consolidation ?
Marc Giraud Même si elle n’a pas tort, la direction financière est par nature prudente, parce que les projets nécessitent des investissements a priori pour économiser plus tard. Les financiers anticipent que la facture finale sera peut être plus élevée que prévue, dans la mesure où les coûts peuvent toujours déraper, et, de fait, amoindrir les bénéfices escomptés.
D’une manière générale, la direction financière n’est pas toujours confiante vis-à-vis des perspectives de bénéfices.
Suffit-il de convaincre uniquement les financiers ?
Marc Giraud Non et pour tous les projets d’infrastructures, dans nos grandes entreprises, il y a une résistance générale au changement. Il faut lutter de tous côtés… D’abord, contre les exploitants, par essence hostiles au changement. Ils sont persuadés, par expérience, que leurs ennuis proviennent précisément des changements qu’on leur impose.
Un système stabilisé fonctionne comme une horloge, et toucher au système, c’est donc prendre le risque de le rendre instable. Or, dès lors que l’on touche aux systèmes, même si les exploitants perçoivent bien les avantages qu’ils pourraient tirer des changements, ils peuvent paraître paralysés par les inconvénients qu’ils craignent et qu’ils sont, d’ailleurs, le plus souvent incapables d’énoncer.
Avec des réactions de type « Ce n’est pas parce que ça marche ailleurs que cela va fonctionner chez nous… », ou encore : « On ne prend pas assez de précautions pour préparer le projet… », même s’ils ne savent pas toujours suggérer quelles précautions il conviendrait de prendre ! Nous devons donc dépenser beaucoup de salive, de diplomatie et de patience pour nous créer des alliés dans le monde des exploitants.
à cela s’ajoutent les résistances de la part des équipes d’études qui affirment que les bénéfices sont aléatoires, surtout si la finance émet des doutes, que cela représente une charge supplémentaire, qu’il faut qualifier les migrations avec des tests de non-régression, et qu’elle subiront tous les inconvénients en phase de post-migration. C’est vrai qu’il y a des facteurs de risques.
De fait, la finance peut coopérer mollement en faisant traîner les dossiers… Il faut beaucoup de ténacité et de punch pour dépasser les résistances internes. En matière de consolidation, nous avions deux ambitions : d’une part, réussir au moins 80 % de la virtualisation du parc de serveurs et, d’autre part, mettre au moins vingt machines virtuelles par machine physique.
Si l’on ne tient pas ces engagements, le résultat risque d’être compromis. Je conseille donc de réaliser un avant-projet, en béton « à l’épreuve des balles », indiscutable pour réaliser un business case lui aussi indiscutable. Cela prend beaucoup de temps.
Où en êtes-vous par rapport à vos objectifs ?
Marc Giraud Nous avons fait migrer un peu plus de la moitié de notre parc, avec un démarrage en juillet 2008 pour les serveurs de développement qui étaient déjà dans une architecture virtualisée mais que nous avons fait migré de Microsoft Virtual Server vers WMware. En août 2008, nous avons réalisé un pilote pour les environnements de production.
Depuis septembre, nous poursuivons la migration de plusieurs lots, selon un calendrier qui nous amènera à la fin de l’année 2008.
Dans ces environnements virtualisés, par rapport à ce qu’était notre parc, très homogène mais pas très jeune, on s’aperçoit que la puissance de calcul, même en environnement virtualisé, reste surabondante et ne constitue pas du tout un facteur limitatif. C’est la mémoire vive qui constitue un facteur limitatif.
Si nous devions refaire le projet, nous ajouterions plus de mémoire dans le serveurs, afin de charger davantage de serveurs dans la même machine. Notre objectif était d’en mettre 20, nous sommes optimistes et pensons nous approcher de 25. Et nous aurions pu aller jusqu’à 40 à 45 machines virtuelles. De fait, la « scalabilité » sera atteinte non pas en augmentant le nombre de serveurs mais en augmentant simplement la taille de la mémoire vive, c’est d’ailleurs moins coûteux en investissement et en exploitation.
Autre bonne nouvelle par rapport à notre objectif, prudent, de faire migrer 80 % de serveurs avec succès, nous prévoyons d’atteindre ou de dépasser plutôt les 90-95 %. Autrement dit, nous allons consolider davantage de serveurs que prévu, sans consommer plus de technologies pour autant, ce qui améliorera d’autant le retour sur notre investissement.
Nous avons toutefois écarté de la consolidation les rares applications très consommatrices de puissance CPU, pour le calcul intensif (quelques serveurs) ainsi que les applications très consommatrices en entrées-sorties, qui sont, elles, plus nombreuses. Pour celles-ci, nous allons optimiser le paramétrage de sorte que ces applications sollicitent moins les infrastructures de stockage.
Il ne faut toutefois pas se contenter d’opérations ponctuelles de consolidation. Il importe de s’intéresser également à l’architecture des nouvelles applications ou à la réorganisation des applications existantes. Concernant ces dernières, nous menons actuellement des études pour celles qui utilisent une redondance matérielle.
Notre approche est basée sur l’utilisation de VMware, pour les environnements de production et hors production, notamment pour les environnements d’intégration. Certes, nous disposerons d’une plus faible puissance de calcul, mais lorsque nous aurons besoin de réaliser des benchmarks de charges, nous aurons recours non plus à une architecture de benchmark du serveur d’intégration dédié à l’application, mais à une architecture de benchmark unique pour toute l’entreprise.
D’où, là aussi, des économies substantielles. Et ce qui vaut pour les environnements d’intégration vaut également pour les autres environnements. En outre, WMware apporte nativement ce qui se rapproche de la très haute disponibilité, sans investissements matériels et logiciels supplémentaires.
C’est d’autant plus intéressant pour nous dans la mesure où les architectures à base de redondance logicielle sont coûteuses à entretenir et pas toujours aussi fiables que ne l’affirment les éditeurs.
Avec la concentration des serveurs, nous sommes obligés de consolider également les sauvegardes, ce qui accroît la qualité des systèmes dans la mesure où les incidents en production diminuent par rapport à une approche basée sur des sauvegardes locales sur chacun des serveurs.
Notamment parce que l’approche stockage centralisé est plus industrielle, donc plus robuste avec ses propres systèmes de redondances. On obtient ainsi des gains économiques significatifs liés à la disponibilité matérielle à la fois sur les serveurs, le stockage et les sauvegardes.
Quelles sont les prochaines étapes ?
Marc Giraud Pour notre plan 2009, nous avons un besoin identifié de 243 machines supplémentaires mais, en réalité, nous utiliserons seulement 48 machines physiques additionnelles, soit environ une pour cinq. Et à partir de 2009, nous allons étudier, en complément, la virtualisation en dehors de la salle machines principale.
Les environnements sont différents : il ne s’agit pas de centaines de serveurs en un seul lieu, mais de quelques-uns dans des environnement plus lointains. Dans nos filiales et unités industrielles (usines, laboratoires de finition…), il reste encore des serveurs pour les applications locales : nous allons poursuivre la simplification des infrastructures physiques dans nos différents sites.
Nous avons souvent un serveur par application, et les applications ont toujours tendance à proliférer. Nous sommes donc confrontés à des enjeux importants pour garantir la disponibilité, stopper la prolifération du nombre de serveurs, la résilience d’applications et du stockage.
Didier Lambert, DSI Essilor : « vers un modèle excentralisé »
Pour Didier Lambert, intervenu lors d’une conférence d’IDC France sur la gestion des infrastructures, la tendance à la consolidation est inéluctable, pour réduire la complexité des architectures.
« Essilor est une entreprise mondiale qui fabrique une majorité d’objets sur mesure, ce qui réclame une informatique particulière pour gérer 350 établissements, 250 laboratoires de proximité, 16 usines sur tous les continents et 32 000 collaborateurs. Avec 300 000 références stockées, nous sommes un grossiste vendant à la pièce.
Les systèmes d’information constituent le trait d’union entre ces éléments, avec une exigence de communications rapides entre les sites de production et les clients. Nous devons gérer quatre grands domaines : les infrastructures, les ERP, les applications génériques et les applications métiers. Concernant les infrastructures, avec des exigences « de-juste-à-temps », on ne peut se permettre ni d’essuyer les plâtres, ni de les laisser vieillir.
Il faut utiliser les standards du marché. C’est le domaine par excellence de l’infogérance, avec une exigence particulière pour la qualité de service et la maîtrise des coûts. Si le réseau tombe pendant une semaine, l’entreprise ferme… Dans le domaine des ERP, il n’y a pas d’avantages concurrentiels pour l’entreprise, et les règles du jeu portent sur la discipline et la qualité.
Pour les applications métiers, c’est traditionnellement, et de plus en plus, le domaine de l’expertise propre à l’entreprise, on ne peut donc pas sous-traiter. Cela réclame une forte synergie entre la DSI et les métiers et les règles du jeu portent sur l’innovation et l’investissement. Autant les produits sont relativement faciles à copier, autant l’expertise sur les processus et les clients est difficile à copier.
Pour les applications génériques, il y a la pression des usages grand public avec comme règles du jeu l’innovation et l’interopérabilité, ce dernier point étant crucial, sinon c’est un cauchemar pour gérer les infrastructures techniques.
On observe une convergence caractérisée par plusieurs tendances : une mutualisation des compétences, une optimisation des infrastructures, la virtualisation des environnements et une banalisation des fonctions non « core business ». Par exemple, le nombre de nos serveurs va être divisé par vingt.
On s’oriente, en réalité, vers un modèle excentralisé avec de puissants centres de calcul, des logiciels communs à plusieurs millions d’utilisateurs, l’utilisation de clients légers et le cloud computing. Cela se traduit par un réexamen des architectures (fonctionnelles et techniques) et un redimensionnement des serveurs, des réseaux, et postes de travail. Sinon, on ne parvient pas à gérer la complexité des infrastructures. »