Quand je regarde une rangée de serveurs, j’ai maintenant une question assez simple : combien de ces processeurs travaillent réellement? Une application par boîte est facile à comprendre, mais plusieurs machines passent une bonne partie de la journée à attendre tout en consommant de l’électricité, de la climatisation et une place dans l’armoire.

La virtualisation ajoute une couche entre le matériel et les systèmes invités. L’hyperviseur présente à chaque machine virtuelle des processeurs, de la mémoire, une carte réseau et des disques virtuels. L’application croit encore posséder son serveur; l’hôte physique répartit en réalité ses ressources entre plusieurs invités.

Application A -> Windows invité A --\
Application B -> Windows invité B ----> hyperviseur -> CPU / RAM / réseau / disques
Application C -> Linux invité C   --/

Le processeur se partage assez naturellement : l’hyperviseur planifie du temps CPU pour chaque processeur virtuel. La mémoire est moins pardonnante. Si quatre VM réclament chacune 4 Go sur un hôte qui en possède 12, les chiffres ne ferment déjà plus avant de compter l’hyperviseur. Le stockage devient souvent le vrai goulot : cinq systèmes qui démarrent ou écrivent leurs journaux en même temps peuvent saturer les mêmes disques même si leurs graphiques CPU restent tranquilles.

Consolider sans empiler les risques

Imaginons huit serveurs physiques qui utilisent en moyenne 10 % de leur processeur et 1 Go de mémoire. Deux hôtes de 16 Go semblent suffisants sur papier. Pour tolérer la perte d’un hôte, il faut toutefois que le survivant puisse absorber les services prioritaires. Si les deux fonctionnent déjà à 80 % de leur mémoire, la haute disponibilité existe surtout dans le diagramme.

Je calculerais donc la consolidation dans le pire état utile, pas seulement selon la moyenne :

capacité requise après panne
  = somme des VM à redémarrer
  + marge pour les pointes
  + ressources de l'hyperviseur

Il faut aussi connaître l’ordre. L’annuaire et le DNS doivent peut-être revenir avant l’application; la base de données avant le serveur Web. Redémarrer toutes les VM ensemble peut créer une tempête d’entrées-sorties et allonger la panne.

Une copie de disque virtuel n’est pas automatiquement une sauvegarde cohérente. Si elle est prise pendant qu’une base écrit une transaction, le fichier copié peut représenter un instant impossible. Il faut coordonner la sauvegarde avec l’application ou l’arrêter proprement, puis tester la restauration sur un autre hôte.

Les serveurs invisibles se multiplient bien

La création rapide apporte un autre problème. Un environnement « pour deux semaines » reçoit un nom, une adresse IP et des données de test, puis son propriétaire passe à autre chose. La VM continue de consommer du stockage et doit recevoir des correctifs. Comme aucune nouvelle boîte ne traîne dans la salle, personne ne la remarque.

Je donnerais à chaque VM un propriétaire, un service associé, une classe de reprise et une date de révision. Une machine sans ces quatre renseignements ne devrait pas rester branchée indéfiniment.

La virtualisation peut réduire le matériel et rendre un environnement plus mobile. Elle concentre aussi les pannes, le stockage et l’administration. Avant de consolider un service important, je veux voir sa consommation réelle pendant une pointe et assister à son redémarrage sur l’autre hôte. C’est beaucoup plus convaincant qu’un taux moyen de CPU bien bas.