Bonjour,
 
Nous recontrons actuellement de nombreuses lenteurs sur notre infra.
 
Par exemple une opération sur une VM locale met environ 40sec alors que sur notre infra cette opération met 7min.
 
Détail de l'infra:
ESX : 4.1
Baie de disque
 
2 serveurs:
RAM : 128Go
Coeurs CPU : 12 CPU x 2,6Ghz (x5650) (d'apres l'esx)
 
On nous suggerent fortement que le problème viendrait des CPU. Nous hébergeons 78VM pour 84 vCPU.
 
D'apres Vsphere, le CPU sur chaque esx n'est que de 3Ghz sur les 12x2,6Ghz.
 
Comment pouvons nous optimiser cela? sachant que le besoin en ressource est tres modéré.
ESX a du mal à gérer autant de VM pour si peu de CPU?

 
Sur quels éléments sont basés ces dires ? Sur les stats Vsphere, est-ce vérifié ? Si oui, peux-tu essayer de voir s'il y a une (ou plusieurs) VM qui satureraient les CPU ?

Un ratio de 7:1 c'est déjà pas si mal. Regarde l'utilisation des cpu physique voir si t'es ras la moule.
Elle a combien de vCPU cette machine ?
Il faut faire gaffe au nombre de vCPU par VM parce que (aux dernières nouvelles que j'ai) il faut que l'ensemble des vCPU soient disponible pour que le CPU bosse. Donc si tu as 2 vCPU il faut que 2 cores soient libres pour que la VM puisse avoir sa part d'où une potentielle latence.

 
Merci de vous réponses, déjà je suis "novice" en esx, c'est pourquoi je vais détailler au maximum mes interventions afin de ne pas vous induire en erreur.
 
Nous passons par un prestataire, bien que nous avons accès également à vsphere.
 
Nos CPU se tournent les pouces (d'apres l'onglet performance), 3Gz par serveurs.(résultat obtenu quand je clique sur un esx> performance.
 
 
 
Sinon il s'agit de l'integralité de l'infra qui est ralenti et pas une VM.
Aucune VM me dispose de plus de 2 vCPU
 
Les tests ont été effectué sur une VM avec un vCPU. Mais de nombreux utilisateurs remarques de lenteurs.
 
 
Quel serait le test afin que je puisse voir si ce sont les CPU le factueurs limitant (plutot le nombre de vCPU par CPU physique)
 
 
edit: je viens de vérifier, chaque serveur a 2 CPU physique

90% du temps c'est des problèmes d'IO. J'investiguerai déjà là dessus.
Ensuite souvent des problème réseau (78VM sur du 1GB voir 2GB ça rame )

dans vsphere:  
si je me met sur un esx> performance (avancée):
Grahique empilé (c'est plus clair mais je ne connais si les résultats sont ok)
 
CPU:temps reel: taux d'utilisation du coeur : 25%
CPU:temps reel: taux d'utilisation : 6%
CPU:temps reel: utilisation : 12%
CPU:temps reel: utilisé : non dispo
CPU:temps reel: utilisation en Mhz : 4Ghz
 
 
 

 
 
Je peux voir ça ds vsphere?

dans vsphere:  
si je me met sur un esx> performance (avancée):  
Grahique empilé (c'est plus clair mais je ne connais si les résultats sont ok)  
 
disque temps réel: taux de lecture (Kbps): max: 3612 min: 14 moyen: 655
disque temps réel: taux de ecriture(Kbps): max: 6657 min: 1028 moyen: 2330
disque temps réel: utilisation(Kbps): max: 6937min: 1008 moyen: 2913
disque temps réel: latence la plus elevee(ms): max: 3522 min: 76 moyen: 343
 
 
 

La latence max à 3.5 secondes ouais c'est énorme tout comme la latence moyenne.
 
Pour info, un disque a une latence <10ms. Là ton sous système disque est largement sous dimmensionné.
 
Combien de disques pour tes 78VM ?

Je vais te dire ça pour les DD.
 
Afin d'etre clair avec le prestataire, pour toi il s'agit d'un pb de la baie (ou du moins une latence?)
 
 
Les CPU sont pour toi ok?
 
 

je sais pas ce que ça vaut mais vla les stats disque Vmware chez moi
 

 
disque - Latence la plus élevée sur les dernières 24h
 
Fais péter les screens

Tu n'as pas assez d'hôtes, et ton infra est complètement à la ramasse niveau I/O.
Il faudrait que tu vérifies la consommation de RAM/Processeur/bande passante mais il y a des chances pour que ce soit trop juste de ce côté-là aussi.
 
Bref tu as de sérieux problèmes de dimensionnement.

http://pubs.vmware.com/vsphere-4-e [...] _disk.html
 
Mais ouais 3ms c'est bien, 79 c'est inutuilisable

la latence est très élévée. Pour ton information, j'ai une latence en lecture de l'ordre de 2,5ms et en écriture de l'ordre de 10ms (sur un raid 10 de sas 15k) avec des latences maxi de l'ordre de 40ms.

de plus je rejoint certaines membres:  ton infra me semble un peu light pour héberger autant de VM.

12 CPU pour 84 vCPU, je trouve ça également hors normes.
Comme un prestataire a-t-il pu cautionner cela ? o.O
 
On attend ta config disque

Merci à vous déjà.
 
Je n'ai pas pu obtenir beaucoup d'information:
1 x CX4-120C SPE WITH SINGLE SPS
2 x 4G DAE FACTORY OR FIELD INSTALL
15 x2000GB 7200RPM SATA II
10 x 450GB 4GB 10K FIBRE CHANNEL DISK DRIVE
VAULT PACK FOR CX4 SERIES 450 10K 4G DRIVES QTY5
CX4-120 Optional Second SPS
 
Par contre les VM sont autant ralenti sur la fibre ou le sata
 
Par contre d'apres ce graph sur une VM la mesure "prêt" semble surchargé depuis le debut de la mise en place de la plateforme. Mais à cette époque il y avait tres peu de VM sur cette infra.  
Ou alors je n'ai pas compris cette mesure
 

Je voulais comparer avec notre environnement mais j'ai pas trouvé cette mesure chez nous !? C'est bien dans CPU ?

oui dans CPU sur une VM.
 
On vient d’augmenter le cache sur la baie.
 
Nous avons maintenant des lentence très correcte : 1 à 2ms
 
 
Le problème porte sur les CPU maintenant.
Notre consommation CPU est très peu elever, mais nous avons bcp de vcpu. Il n'y a pas de façon de contourner cette limite?

 
Je ne comprends pas trés bien comment lire cette doc.... les chiffres 1,2,3,4 ... correspond à quoi ?

 
Schématiquement (un pro de la vm, devrait bien rire en lisant ce qui va suivre, mais bon......):  
 
78 VM ==> il faut prioriser.  Les VM les plus critiques, tu dois les paramétrer afin qu'elles soient "prioritaires" c'est à dire qu'elles puissent consommer plus de "part" de cpu que les vm moins prioritaires.
 
A cela tu supprimes dans tes vm les lecteurs de disquettes
Quant aux cdrom de déclarés, tu les déclares "hors connexion".
Les VM doivent être déclarées avec un provisionnement non dynamique. Cela prend plus de place mais au moins il n'y a de fractionnement des fichiers vmdk dans le datastore.
Les datastore au format VMFS doivent être formatés avec une taille de cluster la plus grande possible à savoir 8Mo. (surtout si tu héberge des "grosses VM)
vérifier aussi la partie réseau et la répartition des vm sur les switch virtuel
...
etc....
 
 
 

A première vue je n'aurais plus que des problème de CPU.
 
 
La "puissance" disponible me convient désormais (exemple nous sommes passé de 7m à 7s sur un script d'import sql).
 
Seul la partie CPU (mesure "prêt" ) semble complètement à la ramasse, bien que nos CPU se tournent les pouces.
 
nous avons trop de vcpu mais je ne peux les supprimer.
 
Ma question se tourne maintenant sur 2 points:
 -y a t'il un risque pour ma ferme, je veux dire, elle peut "tomber"
 -comment améliorer ce point? en gros j'ai plein de VM qui ne font rien (peu de conso cpu) mais très peu de core physique.
 

1) oui une "ferme" peut tomber. Mais pas à cause d'un overload cpu.  
 
2) plein de vm qui ne font rien ? => pour celle là tu diminues la priorité CPU.    
 
PS: et n'oublies pas de te poser la question de la pertinence de certaines VM (doivent-elles etre tout le temps on line ?)

Tu rajoutes des CPU physiques et/ou des hôtes. Mais il te faudra probablement acheter les licences vSphere supplémentaires.

et il n'y a pas de solutions autre que cette solution? (machine bi proc au max)

Question bête : pourquoi ne pas mettre 1 seul vCPU sur toutes les VM non critiques ?

car j'ai 78vm

Non, ton archi physique est sous-dimensionné par rapport à ton nombre de VM, il n'y a pas de miracles possibles.
De toute façon tu n'as même pas de redondance en l'état actuel, autant solutionner ceci au passage.

 
Niet, mis à part un leger tuning qui pourra améliorer les choses, il n'y a aucune solution miraculeuse. ton infra est tout simplement sous dimensionnée.

Ah oui excuse, je suis vraiment à l'ouest...
C'est déjà le cas sur 92% de tes VMs
 
Va falloir faire marcher la carte bancaire ^^
 
Edit : pour info, la valeur prêt sur une VM (javais jamais vu cette valeur avant non plus...)
 

 

Si tu veux confirmer que les problèmes sont bien lié aux disque fais des test avec IOmeter...