Nagios 3 sur VMWare: pas très rapide en SMP!
VMWare ESX permet de virtualiser des serveurs. Il faut alors indiquer les ressources "matérielles" souhaitées. Dans notre cas, il fallait s'exprimer en "UO" où une UO correspond à 1 VCPU ("Virtual CPU") à 667 MHZ et 1Go de RAM. Les calculs nous ont amenés à demander 4UOs, soit: 4VCPU et 4Go de RAM. Puis les tests de performances ont commencés. Là, c'est simple, on fait une supervision standard de 10 serveurs de tests. Les serveurs sont correctement supervisés avec les indicateurs standards (CPU, RAM, partitions, processus, Swap, interfaces réseaux, matériels, ...) et les indicateurs spécifiques. Puis on multiplie ces serveurs en ajoutant un chiffre à la fin. À la fin on obtient 100 * 10 serveurs pour un total d'environs 10 000 indicateurs. On lance Nagios et on regarde.
Bon, le premier résultat est loin d'être positif. Donc on améliore ici ou là. De mon côté, j'avais peu d'espoir d'améliorations car j'ai l'habitude de faire une configuration de base performante, avec toutes les bonnes pratiques. Deux jours dessus, on améliore un peu les choses mais pas de quoi crier victoire. Les VCPUs sont tous à fond, la load grimpe, la latence de Nagios explose et le NTP disjoncte. Et c'est là le problème: le temps n'est plus une donnée fiable. En effet, VMWare a beaucoup de mal à synchroniser les horloges des serveurs invités. Il semblerait que ce ne soit pas un problème lié spécifiquement à VMWare mais à tous les outils de virtualisation. Je n'ai pas d'informations précises, je suis très loin d'être un expert là dessus. Comme le temps n'est plus une donnée fiable, Nagios s'emmêle les pinceaux. Comme il se base sur le temps pour effectuer tous ces tests, dès que le temps n'est plus une donnée fiable, Nagios perd les pédales. En même temps, il ne faut pas lui en vouloir, c'est son travail: ordonnancer tous les tests, les lisser dans le temps pour éviter la surcharge de la machine de supervision et de toutes les machines supervisées. L'horloge de la machine invitée perdait 30 secondes toutes les minutes. Voyant cela, Nagios essaye de plus en plus de lancer de tests, d'où une surcharge. Ce qui entraîne une perte de temps plus importante de la part de Nagios... qui doit compenser en lançant plus de tests en simultané... donc une plus grande surcharge... qui aboutit à une perte de temps plus importante... que Nagios doit compenser ... surcharge.. perte de temps... compensation ... ... ... Rien n'y a fait: obliger NTP à se synchroniser toutes les minutes, sélection de plugins Nagios plus rapides, augmentation au maximum du reaper_frequency, ... Rien! "Donnez moi une machine physique!!!". Ha non, ce n'est pas possible...
Puis une idée de génie de la personne qui s'occupe de VMWare. On va passer de 4VCPUs à un seul CPU mais plus rapide. Et... ça marche! Nagios est beaucoup plus à l'aise. La synchronisation temporelle se fait entre les serveurs NTP même si des décalages peuvent apparaître ici ou là. Cependant, ce n'est en rien comparable avec la configuration précédente. Ça marche donc! Hourra! Mais je ne sais pas pourquoi, je ne suis pas totalement convaincu par la virtualisation. Je ne lui confierais pas ma vie pour le moment... À suivre!



Je serai plus mesuré sur VMWare. Vous parlez de
ulkesh | mardi, mai 6 2008 | 21:05Je serai plus mesuré sur VMWare. Vous parlez de la partie CPUs qui coince. Il faudrait avoir les informations suivantes :
- la version de l'ESX (3.0.x, 3.5.x ?)
- le ratio VCPUs/CPUs
- l'architecture matériel (x86 hyperthreading, amd64 opteron ....), le type (UMA, NUMA), ...
- hébergement de la VM (vmfs sur SAN (quelle type de SAN ? Quelle type de zoning ? ...), NFS, ISCSI, disques locaux ?)
- la charge des autres VMs
- le driver SCSI de la VM Nagios (LSI Logic, BusLogic ?)
- VMtools installé sur la VM Nagios ?
...
Vous nous donnez pas le contexte matériel/logiciel. Il y'a de nombreuses choses à bien vérifier avant de mettre de la virtualisation.
Bonjour, Le client étant un intégrateur très
Cédric Temple | jeudi, mai 8 2008 | 09:00Bonjour,
Le client étant un intégrateur très fortement connu et disposant de très bonnes connaissances en VMWare, je ne pense pas qu'une erreur de configuration ou d'architecture.
Je précise dans mon billet que je ne suis pas un expert VMWare et que le problème est surtout lié à l'horloge. Ce qui fait que Nagios disjoncte. Notamment certains tests sont effectués plusieurs fois alors qu'ils ne devraient pas l'être car Nagios voit la fuite de temps et relance tous les tests.
Je ne vois pas en quoi la solution de 1 VCPU
Ulkesh | vendredi, mai 9 2008 | 10:32Je ne vois pas en quoi la solution de 1 VCPU améliore l'horloge système directement. Le passage à 1 VCPU a permis de "résoudre" le problème. Mais cela a surtout permis à l'ESX de mieux scheduler la VM. (et ainsi améliorer la gestion du temps) Il me semble que le problème devait être la.
Plus une VM a de VCPU, plus il est dur pour l'ESX de la scheduler. (surtout si on a du hyperthreading) Dans votre cas, il aurait peut être été judicieux d'appliquer un "shares".
Hello, Je suis en ce moment même entrain de mettre
raouldiouk | vendredi, mai 9 2008 | 21:54Hello,
Je suis en ce moment même entrain de mettre en place un nagios+centreon sur un serveur ESX et je m'arrache les cheveux ! J'ai moi même des gros problèmes de performances: la machine ESX tourne sur une machine avec 2 xeon et la machine est tout le temps au maxi ( avec 500 services). J'ai remarqué aussi des retards du scheduler malgré mon tunage de la conf ( nbr checks en parallèles, ..etc). J'aimerais bien savoir si la solution que vous avez apporté améliore significativement les choses.
En tout cas merci d'avoir trouver cette solutin, il fallait y penser !!
Nous avons deux machines nagios, l'une etait sur
PoP | samedi, mai 10 2008 | 09:46Nous avons deux machines nagios, l'une etait sur 2vCPU / SAN / 4CPU réel / Esx 3.0, la passer a 1vCPU n'a pas changé sa consommation CPU ni sa charge (optimisation de la configuration nécessaire?)
Par contre la seconde 4vCPU 2GoRam sur un Esx 3.0 avec un Raid 5 en local / 4Cpu réel si nous passons la machine a 1vCPU la consommation CPU passe de 4/5Ghz a 2Ghz+/- avec une charge qui a baissé de 3.6 a 2.6
raouldiouk, je ne pense pas que cette solution
Ulkesh | samedi, mai 10 2008 | 11:54raouldiouk, je ne pense pas que cette solution soit applicable directement.
Comme j'ai essayé de le dire, cela dépend de beaucoup de paramètres. La virtualisation n'est pas quelque chose de trivial. Le marketing dit souvent "affranchissez du hardware avec VMWare (ou autres)". Cela n'est absolument pas vrai pour de la production.
@Ulkesh: Comme je l'ai dit, je ne suis pas un
Cédric Temple | dimanche, mai 11 2008 | 11:17@Ulkesh:
Comme je l'ai dit, je ne suis pas un expert de VMWare ni de la virtualisation. Cependant le passage à 1VCPU "plus puissant" a bien résolu le problème. Il est clair que c'est le scheduler qui posait problème. La virtualisation est vraiment une affaire de spécialiste dans des infrastructures complexes et/ou chargées.
@raouldiouk et @Pop:
Comme je l'ai dit, je ne suis pas un expert de VMWare! En cas de problème avec Nagios je peux vous aider mais je suis dans l'incapacité de vous aider sur VMWare... Essayer de mettre en place ce que j'ai indiqué mais si cela ne marche pas, il faudra peut être faire appel à une société spécialisée dans l'expertise/le tuning de VMWare.
Bonjour, Ce problème est très classique mais n'en
Damien | samedi, juillet 26 2008 | 12:07Bonjour,
Ce problème est très classique mais n'en est pas pour autant moins déroutant. En fait, une VM à plusieurs VCPU n'est pas plus rapide qu'une VM à 1 VCPU pour deux raisons principales:
- Il faut savoir que chaque VCPU est vu par l'ESX comme un process (au sens UNIX). Une VM disposant de plusieurs VCPU est donc vue comme autant de process ... avec une contrainte supplémentaire: ils doivent s'executer en même en temps. En effet, l'OS guest peut à n'importe quel moment faire executer des taches à n'importe le(s)quel(s) des CPU qu'il connait. Moralité, la VM est très dure à scheduler (4process à scheduler en même temps c'est un poil plus compliqué qu'un seul n'importe quand!) et elle prend des ressources aux autres (même si elle n'utilise pas ses CPU, ils sont quand même indisponibles pour les autre!)
- D'autre part, hors paravirtualisation VMI avec linux>2.6.22, il faut savoir que les appels système privilégiés sont émulé par ESX et non executés directement matériellement pas le CPU physique. Hors un linux SMP (ou un windows d'ailleurs) a des taches de synchro inter CPU à executer, qu'un noyau UNI (VM à 1VCPU) n'a pas a réaliser... Donc il a plus de travail, travail qui plus est emulé!
Moralité, toute VM doit avoir 1VCPU et basta!
@ Damien, Ton commentaire va peut être me
jma | jeudi, octobre 22 2009 | 22:11@ Damien,
Ton commentaire va peut être me permettre de résoudre mon problème; présentation du cas:
Une ESXI 4.0 sur Serveur DELL R200 4GB XEON 3.16 GHZ bi coeur (il n'est pas dans la HCL)
Installation de 2 machines virtuelles avec 2 vcpu chacunes:
1 - la distrib de Cédric FAN 1.1 puis update en centos 5.4 + Asterisk 1.4 compilé (centre d'appels 20 téléopératrices)
avec 1 GB
2 - une Windows 2000 server + 4 bases oracle sur 10.1.0
avec 3 GB
Performances: je pensais que le serveur Oracle allais "bouffer" les ressources mais au contraire il tourne au poil et consomme presque rien en CPU, PAR CONTRE mon serveur ASTERISK consomme 3 GHZ de cpu en permance au repos !
En regardant de plus près dans les process, j'ai remarqué qu' en stoppant le SYSLOG-NG je tombe à une conso normale au repos: 300 MHZ
Je me demande si en passant en 1 seul VCPU tout ne va pas rentrer dans l'ordre.
Je vous tiens au courant quand le serveur sera en prod.
@Cédric
Bravo pour ta distrib FAN