Optimiser les coûts des serveurs d'applications

Baisser les coûts de possession des serveurs d'entreprise ne relève pas des seuls choix matériels et logiciels. Pour optimiser les ratios performances-prix, on jouera, tout au long du cycle de vie, sur des paramètres méthodologiques et techniques.

Faire plus pour moins cher est une quadrature du cercle délicate à résoudre dans le monde des serveurs d'entreprise. D'autant que les aspects matériels ne sont pas les seuls en cause, souligne Xavier Devriese, directeur de projets chez l'éditeur et intégrateur de PGI, IBS France : ' Dans un projet PGI, le matériel ne représente que de 10 à 20 % des dépenses à engager sur deux ans. ' C'est donc tout au long du cycle de vie des serveurs d'applications qu'il convient de tenter d'en optimiser les coûts de possession (TCO). Les choix techniques ont leur importance, mais il conviendra de conserver un état d'esprit critique lors de la comparaison des offres propriétaires et open source concurrentes.L'intérêt de l'open source est indéniable pour développer des plates-formes de services web. Des frameworks de composants tels que Struts ou Sprint économisent nombre de jours de développement. Cependant, les plates-formes de déploiement propriétaires, tels WebLogic ou WebSphere, ont des arguments à faire valoir en termes de performances et de disponibilité. Quant à Linux, ses mérites économiques sont d'autant plus appréciables qu'il a gagné en évolutivité avec la sortie du noyau 2.6.

Pas de solution universelle

Le transporteur Fret SNCF, qui avait refondu sa plate-forme de tarification en technologies WebLogic et Ilog, n'a pas hésité à déployer ce service sur Linux. Ceci étant, il ne faut pas idéaliser ce système d'exploitation car ses concurrents ont des arguments à lui opposer. Exemple avec HP-UX dont HP a grandement amélioré le rapport prix-performances sur ses serveurs Itanium. Ils sont passés de 10 $ à moins de 3 $ par transaction en quelques années. HP se fait fort de proposer des serveurs HP-UX dont le TCO à trois ans est meilleur que celui de serveurs sous Linux Red Hat. Quant à Sun, il dispose, avec la version libre x86 de Solaris 10, d'un redoutable moyen de répondre à Linux sur le plan du TCO aussi bien que des fonctionnalités avancées.Au-delà de ces choix techniques, minimiser les coûts systèmes est contraint par les problèmes de dimensionnement des machines. Dans les mondes des PGI et de Java, les constructeurs et des éditeurs sont capables de dégrossir les niveaux de performances des serveurs cibles en s'appuyant sur des abaques sophistiqués. Mais comment prendre en compte les pointes d'activités journalières ou saisonnières ? Tout dépend du chiffre d'affaires généré lors de ces périodes. ' Un éditeur de livres scolaires qui livre entre juillet et août ou un fabricant de chocolats qui livre à Pâques ou à Noël, doit avoir des serveurs prévus pour ses pics d'activité ', illustre Xavier Devriese.Lorsque l'activité est plus régulière, on peut dimensionner les serveurs afin de répondre à une charge annuelle moyenne. Mais lors des pics d'activités, les serveurs fonctionneront en mode dégradé. Cette dégradation sera-t-elle acceptable ? C'est aux contrats de niveaux de service (SLA) d'en juger, ainsi qu'aux tests de performances. On peut tenter de répondre à ce problème de dimensionnement par des choix architecturaux. Mais en la matière, il n'existe pas de solution parfaite, universelle. Les déploiements de WebLogic, par exemple, se réclament aussi bien d'un modèle scale out (croissance externe) avec la mise en grappe de serveurs avec équilibrage de charge, que d'un modèle scale in (croissance interne) avec une consolidation sur des serveurs d'entreprise.Le scale out est adapté à l'organisation en trois niveaux des applications distribuées : présentation-traitements-accès aux données. Il permet, d'une part, de bien isoler les différents niveaux et, d'autre part, de coller à l'évolution des besoins. Les services de présentation sont assurés par des grappes de serveurs peu coûteux, tandis que les traitements sont tenus par des clusters de serveurs de gamme intermédiaire. Des n?"uds peuvent être ajoutés au fur et à mesure aux clusters, si nécessaire. D'un autre côté, ce type de plate-forme est délicat à administrer et ne répond qu'aux besoins de déploiement d'un projet donné. À l'inverse, la consolidation façon scale in, qui s'appuie sur des serveurs de moyenne ou de haut de gamme, permet de mutualiser les ressources d'un ensemble d'applications critiques.

Pas d'excès d'enthousiasme !

À condition de bien cloisonner les domaines applicatifs, le partitionnement logique prend alors toute son importance. Il est intégré aux Unix commerciaux, et disponible, avec VMware, dans les mondes Windows et Linux. L'hyperviseur ESX de VMware diminuerait d'un facteur dix à trente le nombre de serveurs x86 d'un parc, augmenterait de 50 à 60 % le taux d'utilisation des serveurs consolidés et, en fin de compte, économiserait jusqu'à 50 % sur les matériels. Il faut se garder de tout excès d'enthousiasme. La consolidation ne conduisant pas forcément à une réduction des coûts d'administration et de support, selon le Groupe Gartner, car l'environnement virtualisé est plus complexe. D'où la nécessité d'un instance management (gestion d'entité) et d'une industrialisation des procédures d'installation d'images systèmes et applicatives. La création de serveurs virtuels à la volée est une façon séduisante de coller instantanément aux montées en charge. Encore faut-il disposer d'une réserve de puissance matérielle. Sur ce plan, les systèmes Unix peuvent mettre en avant leurs capacités de calcul à la demande. Originellement développées sur les mainframes, les fonctions de CoD ou de CUoD (Capacity upgrade on demand) assurent des processeurs de réserve, activables si besoin.

Relativiser le poids des licences

Bien que la virtualisation de serveurs arrive à maturité, les modèles de tarification logicielle ont du mal à suivre. Mais il convient de relativiser le poids des licences dans des projets applicatifs importants. Selon BEA, le coût des services est alors cinq à dix fois supérieur à celui des licences. D'où l'intérêt des bonnes pratiques d'implémentation et de réglage des applications. Avec les PGI, il ne faut pas sous-estimer les méthodes et les outils d'assistance proposés par certains éditeurs, et notamment SAP. Ainsi, selon une enquête de l'université allemande de Ludwigshafen réalisée en 2004 auprès de 192 entreprises, les outils d'assistance proposés par SAP (SAP Best Practices) aident à baisser de 11 % le TCO des projets PGI.Dans le monde des bases de données et du développement EJB, le réglage fin des développements contribue souvent à limiter les ajouts de puissance matérielle. À condition que l'on instaure une bonne synergie entre les exploitants, les administrateurs des bases de données et les développeurs. Ainsi, explique Jean-Pascal Chevin, responsable des applications transverses chez le courtier CAI Cheuvreux, ' il nous arrive de faire évoluer nos serveurs pour répondre aux pics d'activité. Mais nous nous appuyons d'abord sur la supervision. Celle-ci doit indiquer les causes de surconsommation de ressources, suite à quoi nous tentons d'optimiser les applications avant d'ajouter des ressources serveurs. ' La mise en ?"uvre de serveurs J2EE commence à témoigner d'une évolution des pratiques, puisqu'il arrive que des équipes rassemblant architectes, développeurs, testeurs et exploitants se constituent autour d'un objectif commun : l'optimisation.