NDLR: Je précise tout de même, très sérieusement pour le coup, que cela ne remet évidemment pas du tout en cause les qualité intrinsèques de NSX-T, le bien fondé de notre démarche et notre stratégie globale. Je sais pertinemment que les managers NSX-T 2.4x hébergent désormais aussi les contrôleurs et que ceux-ci sont critiques pour le bon fonctionnement du produit. Merci à Vincent et Cyrille pour notre échange à ce sujet. Enfin, à tous, rappelez-vous que ce blog est un blog personnel (voir ici) et que mon tempérament Français m’impose quelque fois un humour assez dur et décalé (mise en boite, un peu de troll etc.), surtout vis à vis de certains Anglo-saxons. So, guys, don’t take this too seriously, when you see a “Rognotudju” keyword in front of the post title, it’s clearly a “french humor” blog post ^^
Bon, alors, donc, oui, je vous ai dit à plusieurs reprises que j’étais surprenant de zénitude depuis quelques semaines, malgré nos soucis récents (je ne vais pas encore en parler, sinon, on va croire que je troll. pas mon genre ^^). C’est vrai, je prends sur moi, je fait mon taï-chi tous les matins … MAIS LA, CA COMMENCE A BIEN FAIRE ! VMware, qu’est-ce que c’est que ces specs ???
NSX-T ou la machine à pomper de la RAM, en plus de virtualiser le réseau, certes …
Déjà qu’il faut pas moins de trois managers NSX-T en vers 2.4.x, mais en plus chacun doit être, pour une production classique à taille humaine (Tiny et Small n’étant là que pour faire joli ou pour la blague, je ne sais pas), au minimum taillé à 6 vCPUs, 24 Go de RAM (!!!). Comment dire, 72 Go de RAM ? Sçérioussli ? Et je ne parle ici que des managers.
Ah, oui, j’avais oublié ça aussi : pour des raisons de “design”, on est obligé de mettre les 3 managers dans le même faultdomain ! En gros, on a 3 machines, dans le même DC … je dubite … et on compte sur HA pour tout redémarrer de l’autre coté en cas de problème. On me l’a expliqué au moins 2/3 fois, mais je n’ai toujours pas réussi à comprendre pourquoi … split brain et latence, qu’ils disent. Dont acte. Dans ce cas, pourquoi ne pas avoir tout simplement qu’une seule VM NSX Manager, je vous le demande ? Si en plus elles savent pas se sauvegarder … c’est le pompon (ok je trolle ^^)
Pour ce qui concerne les NSX Edge, ça va encore … au début : 4 vCPUs, 8 Go de RAM chacune. La où ça se complique c’est si tu as le malheur d’envisager un deuxième TIER0. Oui, sachez-le, à partir de 2 TIER0, il faut rajouter 2 NSX Edge supplémentaires, ben oui hein, on est jamais assez prudent, histoire d’être sûr que ça marche. On s’en fiche de ce que ça coute finalement, les gigas et les vCPUs… la formule est posée, là, tranquillou : 2 + (nb_tier0 x 2). Gosh…
Je veux bien comprendre que lorsqu’on on est un grand nom du cloud ou une entreprise avec beaucoup d’agent, on en est pas à quelques VMs près, mais lorsqu’on est un “petit” comme nous avec “seulement” quelques 2000 VMs et qui doit en plus compter ses sous du mois au mois, désolé, mais 72 Go rien que pour gérer un cluster NSX de 20 ESXi et 2 NSX Edge …, définitivement, non : PENSEZ AU PETITS un peu, Rognotudju ^^
VMware, j’adore vos produits et depuis longtemps, mais rappelez-vous aussi à qui vous vendez toutes vos licences et ce qu’implique vos specs. Au passage, vous savez rester raisonnable quand il le faut, regardez les specs vCenter : 8 vCPUs et 24 Go de RAM pour gérer … roulement de tambour, jusqu’à 400 Hosts et 4000 VMs.
Le pire dans cette affaire c’est qu’à coté de cela, vous nous pondez des super graphiques dans vRealize Operations pour nous aider à faire la chasse au gaspillage dans les VMs applicatives … En plus, j’ai l’air de quoi moi maintenant avec mes grands principes et mon long combat sur les vCPUs face à nos fournisseurs ? mmmmh ? (voir ici, un précédent Rognotudju)
Non, désolé, Rognotudju quoi.
… ok, je vais me faire un bain chaud d’huiles zéssentielles …
Hello Cédric,
Demain matin tu commences par un petit cours de Shiatsu pour commencer la semaine ^^. Merci de partager tes remarques, c’est vrai en effet les composants commencent à s’alourdir en terme de vCPU/RAM mais c’est aussi pour donner une bonne expérience à nos utilisateurs :) :) en effet depuis le merge de la partie «contrôle plane » le fait d’avoir « tout en un » demande un peu plus de RAM….
C’est donc pour cela que VMware recommande aussi un Cluster de Management séparé :) pour ne pas consommer de la ressource sur les workload compute.
Ça pourrait être intéressant de regarder dans vROPS le comportement de tes Edges/Managers en fonctionnement de production afin de vérifier que les spécifications données sont cohérentes… ou pas ^^.
Mika
Déjà, Mika, un Rognotudju ne mérite pas forcément de réponses constructives :D … t’aurais pu être plus incisif, ça aurait été rigolo. Je ne remet pas en cause le design, mais je persiste à penser que VMware prend ses aises avec certains de ses outils. Un peu d’optimisation ne ferait pas de mal ou une gestion plus fine des configurations et des maximums, tout simplement. Juste, s’adapter aux contraintes de tous ses clients et ne pas trop facilement se “réfugier” derrière des specs un peu maxed-out.
/Disclaimer: VMwarepayemesfactures
Je fais un gros travail sur moi-même depuis quelques temps pour ne pas nourrir les trolls, donc je vais juste donner un avis le plus neutre possible (qui je pense serait le même quelque soit mon employeur).
Premièrement, je peux comprendre la frustration. :)
Je pense que les solutions autre que VMware, ou nos concurrents, sont pareils. Il y a au moins autant (mais certainement plus) de CPU/RAM dans les boitiers physiques (controllers, routeurs, switches, etc.) que dans NSX-T. Enfin, en appliance virtuelle, c’est d’autant plus difficile car il est impossible de contrôler le type de hardware qui font tourner ces appliances: il peut y avoir de grosses différentes en terme de vitesse CPU ou mémoire par exemple.
Merci pour ton retour Romain, c’est vrai que ce “coup de gueule” en forme de petit troll a eu bien plus d’impact qu’il n’en méritait vraiment… pour le coup la créature à échappé à son maître ^^. D’un autre coté, je comprends aussi parfaitement la difficulté de sizer correctement des environnements virtualisés tels que NSX-T.
Mais justement, tant qu’à faire, au lieu de sur-dimensionner systématiquement les best-practice, je trouverais plus judicieux de faire une petite pré-étude de perf sur la cible, tout simplement. Même si on dimensionne 8 CPUs et que derrière, le taux de contention est de 25/30% , ça changera pas grand chose et cela peut même être contre productif pour un cluster vue la façon dont l’éligibilité d’une VM à du CPU est conçu sur ESXi.
4
5