Virtualisation de serveurs : l'âge industriel  

Bonnes pratiques : les principaux obstacles à éviter

Avant de se lancer dans un projet de virtualisation, il est bien sûr  nécessaire de définir les objectifs que l'on souhaite atteindre. S'agit-il de réduire le nombre de serveurs dans l'entreprise (consolidation), de maximiser la disponibilité des applications (haute disponibilité, tolérance de pannes, Plan de reprise après désastre), de rendre plus agile et plus flexible le système d'information (provisionning plus rapide de serveur, déplacement de capacité d'un datacenter à un autre…). Ces objectifs conditionneront le choix des technologies à mettre en œuvre mais aussi les points de l'infrastructure à faire évoluer.  Ce n'est toutefois pas sur ces aspects que cet article souhaite s'appesantir, mais plutôt sur les points douloureux auxquels ont été confrontés nombre de projets de virtualisation au cours des deux dernières années, notamment la gestion des capacités, la gestion des performances, la cohabitation des équipes d'administration et le support logiciel.

Capacity Management : connaître son environnement pour bien le virtualiser…
L'une des conditions de la réussite d'un projet de virtualisation est de bien connaître les caractéristiques de son environnement avant de le virtualiser. Aucun projet ne devrait se lancer formellement sans une analyse détaillée des métriques d'utilisation des serveurs physiques en place et notamment celles touchant à la consommation CPU, à l'usage de la mémoire ainsi qu'à la gestion des entrées/sorties (I/O réseau et stockage).
Ces quatre métriques essentielles permettent de caractériser les environnements à virtualiser. On peut ainsi déterminer en connaissance de cause les bons candidats à la virtualisation et les applications qui devront continuer à tourner sur des serveurs physiques. On peut aussi construire des profils types d'environnements compatibles entre eux . Il est par exemple préférable d'éviter de consolider sur un même serveur des VM faisant un usage intensif de la mémoire et des I/O disques. De la même façon, on évitera de mixer des environnements ayant un comportement régulier avec des environnements ayant un comportement ératique. Idéalement, il est nécessaire de collecter les différentes métriques durant une période assez longue (quelques mois) afin d'avoir un aperçu des variations en fonction des périodes et des plages horaires, mais aussi d'avoir une idée de l'évolution de la charge des différents serveurs (on évitera par exemple de mettre sur un serveur virtualisé déjà bien occupé, une VM ayant un profil de consommation en forte croissance).
Ce travail peut être fait de façon plus ou moins manuelle pour un petit projet mais il devient rapidement ingérable dans le cas d'un grand projet sans l'appui d'un logiciel adéquat. Quelques éditeurs se sont fait une spécialité du capacity management et du capacity planning à des fins de virtualisation, comme Novell avec PlateSpin Recon, Systar avec Omnivision, ou Uptime Software. Notons aussi l'outil gratuit MAP (Microsoft Assessment and Planning développé par Microsoft pour Windows) et qui peut s'avérer très pratique pour un exercice de capacity planning initial.

…Et continuer à le suivre pour éviter les soucis
Imaginer pouvoir se satisfaire d'un exercice de capacity planning initial est en revanche suicidaire dans le cadre de déploiement importants impliquant plus d'une cinquantaine de machines virtuelles. Comme dans le monde physique, les machines virtuelles évoluent et peuvent voir leur profil de consommation évoluer dans le temps. Une VM qui initialement semblait ne pas poser de problème sur un serveur, peut rapidement perturber le fonctionnement de ses voisines en s'accaparant trop de ressources par rapport à ce qui était prévu. Il faudra alors envisager de la déplacer. Poru cela il faudra établir son nouveau profil, mais surtout disposer d'une analyse des capacités disponibles sur les autres serveurs afin de la déplacer sur la machine adéquate. Bref, vous l'aurez compris, en environnement virtuel, la gestion des capacités doit être un exercice récurrent (voire permanent) si l'on veut éviter les déconvenues en matière de service rendu aux utilisateurs.

Organisation : mettre en place des équipes transversales
L'un des impacts souvent inattendu des hyperviseurs est qu'ils rendent très floues les frontières traditionnelles entre les couches réseaux, calcul et stockage. DU fait de la fluidité des environnements virtualisés, il est donc préférable d'anticiper et de mettre en place des équipes pluridisciplinaires impliquant équipés réseaux, administrateurs systèmes et administrateurs stockage sous peine de voir un jour se déclencher une guerre larvée entre ces différents métiers. Dans un environnement virtuel il est en effet facile pour un administrateur système de s'accaparer certaines ressources habituellement gérées par les équipes réseau de même que l'intégration de systèmes de fichiers en clusters dans la plupart des hyperviseurs (VMware vSphere ESX, Microsoft Hyper V2, Oracle VM) a tendance à casser les schémas traditionnels d'administration du stockage, ce qui peut perturber les relations entre administrateurs systèmes et stockage.L'idéal est d'envoyer ces équipes se former ensemble et de les faire s'asseoir autour d'une table pour définir leurs règles de cohabitation en environnements virtualisés. D'autant qu'à l'avenir les frontières entre composants d'infrastructures devraient continuer à s'estomper…

Définir un modèle de coût afin de facturer les utilisateurs
Dans un modèle de production informatique traditionnel, chaque service métier se voit allouer ses propres ressources dédiées et est donc refacturé en conséquence. Mais dans un monde virtualisé, les ressources sont pour l'essentiel mutualisée et il est donc nécessaire de définir un modèle de coût afin de pouvoir refacturer de façon pertinente les utilisateurs mais aussi afin d'éviter certaines dérives. Certaines entreprises qui se lançaient dans la virtualisation ont ainsi été confrontées à une inflation galopante du nombre de leurs machines virtuelles faute d'avoir mis un coût sur ces machines. En affichant clairement et dès le départ, un prix (et accessoirement un temps minimum de provisionning de quelques heures, plutôt que de quelques minutes) on limite les risques d'abus. Afficher aussi une grille tarifaire est aussi un moyen pour un service informatique de se benchmarker face à ses concurrents extérieurs (notamment les outsourcers) mais aussi de définir des règles de recours (ou non) aux services de prestataires tiers comme les opérateurs d'infrastructures en nuage.

S'assurer du support de ses fournisseurs de logiciels
Un point souvent sous-estimé dans les projets de virtualisation touche aux aspects de support logiciel. Ce domaine reste un vrai champ de mines, aucun éditeur n'ayant adopté une politique homogène en matière de support technique sur les grands hyperviseurs du marché. Longtemps des éditeurs comme SAP ou Oracle ont refusé de supporter leurs clients faisant fonctionner leurs logiciels sur une couche de virtualisation. C'est un problème réglé chez SAP mais toujours saillant chez Oracle, qui n'assure un support total de ses solutions que sur son propre hyperviseur, OracleVM. Chez de nombreux petits éditeurs, les hyperviseurs sont aussi non grata, même si leurs solutions fonctionnent en général sans problèmes au-dessus d'une couche de virtualisation. Un autre problème persistant est celui des licences logicielles. Certains éditeurs facturent ainsi leurs outils au socket processeur, mais ne reconnaissent pas les capacités de découpage des hyperviseurs. Ainsi une machine virtuelle à laquelle on a alloué 2 CPU virtuels sur une machine à 4 CPU pourra se voir réclamer une licence pour 4 CPU chez certains éditeurs.  Pire, certains éditeurs et pas des moindres, n'admettent pas que leur logiciel puisse être déplacé d'un serveur à un autre avec une technologie de migration en live (cela a par exemple été longtemps le cas de Microsoft, qui exigeait que ses logiciels ne changent pas de serveur avant un délai minimum de 90 jours après leur dernier déplacement) . Autant dire qu'il est prudent de se renseigner sur ce que son éditeur considère comme légitime avant d'imaginer virtualiser un logiciel…