Rognotudju !
Haaa ! 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 joli joli, mais là, il fallait que ça sorte. Alors quoi ? Quel est donc le souci avec les CPUs ? 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 fait jour. 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 oeuvre de l’application cible sont relativement raisonnables quant il s’agit de mémoire vive et de capacités disques. En effet, de ce coté là, on reste dans des limites acceptables, qui sont principalement liées aux OS invités et aux différents middleware concourant à faire fonctionner l’ensemble.
Par contre, 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 vas-y que je te demande un petit 16 vCPU pour une bécane qui va travailler pour 10 users et faire du transactionnel Oracle. Et vas-y que je ne me pose aucune question : “ça marche sur une machine physique à 32 coeurs, on va demander 32 vCPUs pour la VM équivalente”. Ben voyons, et vous ne voulez pas que je vous nettoie le pare-brise aussi ? Petit rappel utile à tous ces gens : même si on parle de plus en plus de “commodity hardware” pour nos hyperviseurs, malgré tout, ces machines COÛTENT CHER et nos budgets sont loin d’être illimités.
Soyons deux secondes sérieux… qui n’a pas déjà constaté dans sa production VMware un taux alarmant de “reclaimable vCPUs” correspondant au moins à la moitié des vCPU provisionnés ? Qui ne s’est jamais désolé devant des VMs de 8 vCPUs dont les diagrammes d’utilisation sont désespérément plats, au moins autant que l’électro-encéphalogramme de la personne qui a exigé cette puissance avec un arguments imparables bien sûr : PARCE QUE SINON JE N’ASSURE PAS LE SUPPORT. Pire, qui n’a pas déjà constaté avec effroi que les hyperviseurs luttaient à placer les milliards de VM de 16 CPUs alors que les VMs elles-mêmes se doraient la pilule en attendant les requêtes utilisateurs (Hooo, le beau CPU Ready à 40% …) ?
Bref, ARRETEZ AVEC LES vCPUS ! Une VM, par définition, c’est souple, c’est extrêmement flexible, ça se reboote en dix secondes, voire, quand l’application n’est pas trop mal faite et que l’OS invité n’est pas ante-diluvien, ça s’étend à chaud ! Soyez sereins, raisonnables et surtout réalistes. Ecoutez les responsables et/ou experts de la virtualisation : s’ils vous disent que cette machine peut largement tourner avec 2 vCPUs 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 mémoire n’est en général pas la solution à des problèmes de performance. Mais ces mêmes personnes on tendance, encore aujourd’hui, à céder face aux méchants responsables du support “qui ne veulent pas de problème” et imposent de manière totalement arbitraire des dimensionnements qui datent du début des années 2000, où les productions bien dures et physiques étaient encore reines.
Pour autant, messieurs les administrateurs, n’abandonnez pas la lutte, gardez votre joli tromblon et sortez-le ouvertement lorsqu’une nouvelle “monster VM” se pointe à l’horizon. Fournissez des courbes, des preuves tangibles, des arguments de poids (vRealize Operation est idéal pour cela) et tenez tête à vos “opposants”… à force de batailles, on la 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… on en est pas venu à noyer notre chagrin dans l’alcool, mais on aurait pu, tellement cela nous affecte au quotidien :)
Yop,
On sent que tu en as gros sur le cœur !
Il est certains que c’est une discussion délicate, mais cela vient à mes yeux de pre-réquis hérités de pays où les procès vont bon train… “Vous m’aviez dit que 2vCPU était une configuration correcte par rapport à mon infrastructure, l’application a freezé c’est inadmissible.”
J’ai dû de nombreuses fois annoncer les requirements de vApps où les discussions ont été un peu délicate, mais doit-on passer outre des pré-requis constructeur (et se mettre en situation potentiellement désagréable avec le support dudit constructeur ?)
C’est toujours la limite de l’exercice, effectivement… quel risque on prend “formellement” avec le support éditeur si on va contre ses préconisations ? D’un autre coté, cela ne coûte rien à mon sens de tout le temps négocier “avant”. Si on obtient rien, on se fait une raison, mais au moins, on challenge un peu le fournisseur. C’est comme pour les constructeurs/éditeurs qui refuse encore la virtualisation… il faut absolument exiger de leur par un argumentaire construit et un courrier de leur direction à la direction du SI, ça a le mérite de les faire vraiment réfléchir un minimum.
Ton post est criant de vérité, dans ma boite c’est une lutte de tous les jours avec nos intégrateurs applicatifs et les éditeurs pour d’abord leur expliquer comment fonctionne la virtualisation et ensuite leur démontrer que les sizings sont délirants.
Désormais on les challenge (quelles sont vos précos conseillées ? minimales ?) on commence petit en recette et on monte au fur et à mesure des besoins quand c’est possible. S’ils disent niet pour le support, on met leurs précos, et dès que l’on peut on réduit sous contrôle de vROPS et du reponsable d’application, quitte à remettre la conf d’origine si on ouvre un incident! ;)
Et oué … on sort le tromblon quoi :D
Très bon article, c’est un problème que l’on rencontre souvent.
À partir du moment ou on connait le fonctionnement d’un hyperviseur c’est tout de suite plus … compliqué.
Et oui : comme vous le dites Mathieu, quand on ne connait pas on applique simplement les prérequis éditeurs. Sinon, je propose d’appliquer aussi mais en émettant des reserves.
J’ai déjà du confronter les pré requis éditeur avec des rapports et batches esxtop. On voyait clairement que l’application utilisait bien moins de HEC (hardware execution contexts – je préfère cela à vCPU car plus précis) que configuré. L’augmentation du CPU ready et du Co-stop a permis de prouver que la plateforme se porterait mieux en diminuant le nombre de “vCPU”.
J’espere que la prise en compte des hyperviseurs sera plus rigoureuse au niveau des pré-requis applicatifs, car c’est courant maintenant!
Hello Eric !
Au passage, on se rend compte que souvent, ce sont les fournisseurs qui viennent d’adopter le mode de production virtualisé très récemment qui proposent souvent des précos délirantes. Ca confirme donc que c’est très lié à l’inertie des préco “physiques” précédentes.
Le classic. Quoi dire de plus. Bravo. Quelqu’un a dit ouvertement, sans sauce, droite dans les yeux. Eh oui, c’est comme ça.
Esperons que les integrateurs consultent les blogs de virtualization -:)
++
Vladan
Cédric, t’as oublié de parlé de ceux qui font (en + des preco en vCPUs stupides) des demandes de réservations en GHz totalement absurde !
Effectivement, j’ai zappé… quelle misère ! … “Dans la VM je ne vois que 2,4 GHz mais j’ai demandé 2,6 GHz pourtant, c’est normal que l’appli rame du coup”
Merci, merci d’avoir parlé en notre nom.
Faisont de ce poste une charte à lire avant demande de ressources.
Car troubleshoot des soucis de ready et de co-stop, c’est pas ce qui a de plus FUN et freinant les projets d’innovations.
Bonjour Cédric
En effet de nombreux clients de la prod me font part de ce genre de soucis avec les éditeurs / intégrateurs et les métiers.
Reste 2 alternatives pour (essayer de) stopper ces comportements :
– tu leur mets bien leur 64 vCPUs mais tu consolides à mort, genre 6:1
– ta direction mets en place une gouvernance ou la règle est : je te mets les vCPU que j’estime nécessaire et si ça marche pas je t’en mettrai plus
Certains ont réussi à mettre en place la 2nde solution et d’autres, qui ne me l’ont pas avoué, ont dû choisir la 1ère ! ;-)
La promesse de l’ITaaS, du catalogue de services et de la refacturation sont bien la !
Bon post
Salut Emmanuel !
Ma direction ne prendra pas le risque d’un problème dans la chaine de support, même si la question se pose souvent. Je la comprend en partie d’ailleurs. La consolidation, oui, bien sûr, mais ça ne résoudra pas le problème de perte d’efficacité de l’hyperviseur … pas forcément une solution miracle pour le moment ;)
Salut Cédric,
Merci pour ce coup de gueule, c’est également mon quotidien ! après qui a dit qu’on ne pouvait pas un peu jouer dans son coin avec l’overcommitment, si vous voyez ce que je veux dire :), je plaisante, mais dans certain cas, c’est utile.
Bonne continuation
Hello,
Le pire dans tout ça, c’est que c’est complètement absurde… On peut très bien mettre 8 vCPUs sur des processeurs d’il y a dix ans et constater au final qu’on n’est pas plus performants qu’avec 2 vCPUs sur des processeurs actuels…
On est dans un monde “0 emmerde 0 risque” donc on nous demande de charger, sans réfléchir.
Comme disait Coluche, si on peut avoir le 45 au prix du 41, pourquoi acheter le 41 ?
Bon courage à tous.
YESSEU, je viens de gagner une bataille !
DE 32 vCPUs initiaux réclamés (c’est pas Devil Inside, mais Debile Inside .. souvenirs souvenirs :D) je viens de signer pour 8 … Z’êtes fiers de moi ou pas ??
Bon déjà, 8 ça commence à être beaucoup mais ça reste gèrable ;)