Je suis en train de relire un certain nombre d’articles que j’ai écrits il y a longtemps, mais qui restent toujours valables aujourd’hui à mon sens. Donc, histoire de rafraîchir la mémoire de certains (et la nostalgie éventuelle qui va avec…), je vous propose un article « Back to the Future » qui reprend la rédaction originale, en la passant à la moulinette de mon Marvin perso, et qui ajoute éventuellement certaines précisions au post original.
On commence par l’un de ceux qui m’ont valu pas mal de commentaires à l’époque (positifs !!!) :
ARRETEZ AVEC LES VCPUS !!
Ha ! Ce bon vieux CAPS, une manière imagée et très visuelle de se lâcher un peu, d’essayer d’imposer ses vues à ses lecteurs. Je sais, ce n’est pas très joli, mais là, il fallait que ça sorte. Alors, quel est donc le problème avec les CPU ?
Pour être plus précis, il s’agit de dénoncer les pratiques ubuesques de certains fournisseurs vis-à-vis des dossiers de préconisations que l’on reçoit régulièrement lorsqu’un projet démarre et qu’une nouvelle infrastructure virtualisée se profile. Avant toute chose, il faut rendre à César ce qui est à César : en général, les équipes techniques chargées d’accompagner la mise en œuvre de l’application cible sont relativement raisonnables quant à la mémoire vive et aux capacités disque. En effet, de ce côté-là, on reste dans des limites acceptables, principalement liées aux OS invités et aux différents middleware concourant à faire fonctionner l’ensemble.
En revanche, il y a un vrai déni d’expertise quand on commence à parler de vCPU. La tendance actuelle étant clairement à la surenchère en la matière… et sans se poser la moindre question : « On me demande 16 vCPU pour une machine qui va servir 10 utilisateurs et faire du transactionnel Oracle. » Ben voyons, et vous ne voulez pas que je vous nettoie le pare-brise, avec ça ?
Petit rappel utile à tous ces gens : même si l’on parle de plus en plus de « commodity hardware » pour nos hyperviseurs, ces machines coûtent cher, et nos budgets sont loin d’être illimités.
Soyons sérieux l’espace de deux secondes… Qui n’a pas déjà constaté dans sa production VMware un taux alarmant de « reclaimable vCPU » correspondant au moins à la moitié des vCPU provisionnés ? Qui ne s’est jamais désolé devant des VM de 8 vCPU dont les diagrammes d’utilisation sont désespérément plats, au moins autant que l’électroencéphalogramme de la personne qui a exigé cette puissance avec un argument imparable, bien sûr : « Parce que sinon, je ne veux pas assurer le support. »
Pire, qui n’a pas déjà constaté avec effroi que les hyperviseurs luttaient pour placer des milliers de VM de 16 CPU, alors que les VM elles-mêmes se doraient la pilule en attendant les requêtes utilisateurs ? (Hooo, le beau CPU Ready à 40 %…)
Bref, arrêtez avec les vCPU ! Une VM, par définition, c’est souple, c’est extrêmement flexible : ça se redémarre en dix secondes, voire – quand l’application n’est pas trop mal faite et que l’OS invité n’est pas antédiluvien – ça s’étend à chaud ! Soyez sereins, raisonnables et surtout réalistes. Écoutez les responsables et/ou experts de la virtualisation : s’ils vous disent que cette machine peut largement tourner avec 2 vCPU seulement, ce n’est pas parce qu’ils sont radins (enfin… pas que ^^), c’est tout simplement parce qu’ils ont raison dans 95 % des cas.
Alors, oui, c’est vrai : en général, la plupart des techniciens et ingénieurs savent désormais pertinemment que la débauche de CPU et de mémoire n’est pas la solution aux problèmes de performance. Mais ces mêmes personnes ont ncore tendance, aujourd’hui, à céder face aux responsables du support « qui ne veulent pas de problème » et imposent, de manière totalement arbitraire, des dimensionnements dignes du début des années 2000, où les productions physiques et bien dures étaient encore la norme.
Pour autant, messieurs les administrateurs, n’abandonnez pas la lutte ! Gardez votre joli tromblon et sortez-le ouvertement lorsqu’une nouvelle « monster VM » se profile à l’horizon. Fournissez des courbes, des preuves tangibles, des arguments de poids (vRealize Operations est idéal pour cela) et tenez tête à vos « opposants »… À force de batailles, on gagnera cette guerre et on pourra enfin capitaliser au maximum sur nos investissements en compute !
Je profite d’ailleurs de ce coup de gueule pour faire un petit « check » amical à Pierre-Yves d’Econocom, avec qui j’ai particulièrement discuté de ce problème de fond récemment… Nous ne sommes pas venus à noyer notre chagrin dans l’alcool, mais on aurait pu, tellement cela nous affecte au quotidien 🙂