Dépannage des pics de latence sur les datastores ESXi NFS

44

Je rencontre des latences fsync d'environ cinq secondes sur les datastores NFS dans ESXi, déclenchées par certaines machines virtuelles. Je soupçonne que cela pourrait être causé par des ordinateurs virtuels utilisant NCQ / TCQ, car cela ne se produit pas avec les lecteurs IDE virtuels.

Ceci peut être reproduit en utilisant fsync-tester (par Ted Ts'o) et ioping . Par exemple, en utilisant un système live Grml avec un disque de 8 Go:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

C'est 5 secondes, pas millisecondes. Cela crée même des latences d'E / S sur une machine virtuelle différente s'exécutant sur le même hôte et le même magasin de données :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Lorsque je déplace la première machine virtuelle vers un stockage local, cela semble parfaitement normal:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

Les choses que j'ai essayées ne font aucune différence:

  • Testé plusieurs éditions ESXi: 381591, 348481, 260247
  • Testé sur différents matériels, différents boîtiers Intel et AMD
  • Testé avec différents serveurs NFS, tous présentent le même comportement:
    • OpenIndiana b147 (synchronisation ZFS toujours ou désactivée: aucune différence)
    • OpenIndiana b148 (synchronisation ZFS toujours ou désactivée: aucune différence)
    • Linux 2.6.32 (sync ou async: pas de différence)
    • Cela ne fait aucune différence si le serveur NFS est sur le même ordinateur (en tant que dispositif de stockage virtuel) ou sur un hôte différent

OS invité testé, présentant des problèmes:

  • Windows 7 64 bits (avec CrystalDiskMark, les pointes de latence se produisent principalement pendant la phase de préparation)
  • Linux 2.6.32 (testeur fsync + lecture)
  • Linux 2.6.38 (testeur fsync + lecture)

Je ne pouvais pas reproduire ce problème sur les machines virtuelles Linux 2.6.18.

Une autre solution consiste à utiliser des disques IDE virtuels (vs SCSI / SAS), mais cela limite les performances et le nombre de lecteurs par machine virtuelle.

Mise à jour du 30/06/2011:

Les pointes de latence semblent se produire plus souvent si l'application écrit dans plusieurs petits blocs avant fsync. Par exemple, fsync-tester fait ceci (strace output):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping fait ceci pendant la préparation du fichier:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

La phase d’installation de ioping est presque toujours suspendue, alors que fsync-tester fonctionne parfois très bien. Est-ce que quelqu'un est capable de mettre à jour fsync-tester pour écrire plusieurs petits blocs? Mes compétences C sucer;)

Mise à jour 2011-07-02:

Ce problème ne se produit pas avec iSCSI. J'ai essayé cela avec le serveur OpenIndiana COMSTAR iSCSI. Mais iSCSI ne vous donne pas un accès facile aux fichiers VMDK, vous pouvez donc les déplacer entre les hôtes avec des instantanés et rsync.

Mise à jour 2011-07-06:

Cela fait partie d'une capture wirehark, capturée par une troisième machine virtuelle sur le même vSwitch. Tout cela se passe sur le même hôte, aucun réseau physique impliqué.

J'ai commencé à lire vers 20 heures. Aucun paquet n'a été envoyé avant la fin du délai de cinq secondes:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2ème mise à jour 2011-07-06:

Il semble y avoir une certaine influence de la taille des fenêtres TCP. Je ne pouvais pas reproduire ce problème en utilisant FreeNAS (basé sur FreeBSD) en tant que serveur NFS. Les captures wirehark ont ​​montré des mises à jour de la fenêtre TCP à 29127 octets à intervalles réguliers. Je ne les ai pas vus avec OpenIndiana, qui utilise par défaut des fenêtres plus grandes.

Je ne peux plus reproduire ce problème si je définis les options suivantes dans OpenIndiana et si je redémarre le serveur NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Mais cela tue les performances: l’écriture de / dev / zero dans un fichier avec dd_rescue passe de 170 Mo / s à 80 Mo / s.

Mise à jour 2011-07-07:

J'ai téléchargé cette capture tcpdump (peut être analysée avec Wireshark). Dans ce cas, 192.168.250.2 est le serveur NFS (OpenIndiana b148) et 192.168.250.10 est l'hôte ESXi.

Choses que j'ai testées lors de cette capture:

A commencé "ioping -w 5 -i 0.2." à l’heure 30, l’installation dure 5 secondes et se termine à l’heure 40.

A commencé "ioping -w 5 -i 0.2." à l’heure 60, l’installation dure 5 secondes et se termine à l’heure 70.

Démarrage de "fsync-tester" à l’heure 90, avec la sortie suivante, arrêté à l’heure 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2ème mise à jour 2011-07-07:

Tester une autre machine virtuelle de serveur NFS, cette fois-ci dans l’édition de la communauté NexentaStor 3.0.5: présente les mêmes problèmes.

Mise à jour du 31/07/2011:

Je peux également reproduire ce problème sur la nouvelle version d'ESXi 4.1.0.433742.

vmware-esxi  nfs  latency 
— exo_cw
source
12
Je dois dire que cela fait longtemps qu’un nouvel utilisateur n’est pas venu au conseil avec une question aussi bien documentée et mûrement réfléchie - sérieusement, bravo à vous. C'est vraiment intéressant aussi, je n'ai pas encore rencontré fsync-tester avant, alors merci. Cela dit, je ne suis pas sûr d’avoir quoi que ce soit à ajouter, vous avez déjà essayé tellement de choses que j’aurais déjà - je dirais même de parler à VMWare pour être honnête, ils sont très doués pour prendre ce genre de choses. de «longue queue» / «pas une interruption de service réelle» des choses sérieusement. Quoi qu'il en soit, je voulais juste dire bravo à ce que vous avez fait jusqu'à présent :)
— Chopper3
Malheureusement, le site Web de VMware ne me permet pas de les contacter: "Vous ne disposez actuellement d'aucun droit de support actif"
— exo_cw Le
ah oui, ça peut être un problème bien sûr ...
— Chopper3
3
Un délai de 5 secondes avec NFS semblait familier. Dans Linux NFS, le délai d'attente de RPC est de 0,7 seconde. Il est multiplié par deux après chaque échec et déclenché une majeure après 3 échecs (paramètres par défaut). .7 + 1,4 + 2,8 = 4,9 secondes. Cela peut être dû à une grande variété de problèmes d’authentification RPC.
— Marc
2
@ Ryan: J'ai téléchargé le fichier de capture. J'ai également téléchargé la sortie nfsstat .
— exo_cw

Réponses:

5

Ce problème semble être résolu dans ESXi 5. J'ai testé la version 469512 avec succès.

— exo_cw
source
3

Merci, nfsstat a l'air bien. J'ai revu la capture. Je n'ai rien trouvé de concluant, mais j'ai trouvé quelque chose d'intéressant. J'ai filtré sur tcp.time_delta> 5. Ce que j'ai trouvé dans chaque instance de délai était le début exact d'un appel RPC. Tous les nouveaux appels RPC n'étaient pas lents, mais tous les ralentissements se sont produits exactement au début d'un appel RPC. En outre, il ressort de la capture que 192.168.250.10 contient tout le retard. 192.168.250.2 répond immédiatement à toutes les demandes.

Résultats:

  • Les retards se produisent toujours dans le premier paquet d'un appel RPC
  • Les types de commande NFS n'étaient pas corrélés pour retarder les instances
  • Fragmentation = retarde seulement le premier paquet

Un appel d'écriture volumineux peut se décomposer en 300 paquets TCP individuels, et seul le premier est retardé, mais tous les autres survolent. Jamais le retard ne se produit au milieu. Je ne suis pas sûr que la taille de la fenêtre puisse affecter le début de la connexion de manière aussi radicale.

Prochaines étapes: je commencerais par peaufiner les options NFS telles que NFSSVC_MAXBLKSIZE plutôt que la fenêtre TCP. En outre, j'ai remarqué que 2.6.18 fonctionne alors que 2.6.38 ne fonctionne pas. Je sais que le pilote VMXnet3 a été pris en charge au cours de cette période. Quels pilotes de carte réseau utilisez-vous sur les hôtes? Déchargement TCP oui / non? Environ 95 secondes, il y a plus de 500 paquets TCP pour un seul appel d'écriture NFS. Ce qui est en charge de TCP et de la rupture de la grande PDU pourrait être ce qui bloque.

— Ryan
source
J'ai essayé de définir nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots et nfs: nfs3_bsize jusqu'à 8192: aucune différence, mêmes problèmes. Les invités Linux n'utilisent que leurs disques SCSI / SAS, pas de NFS - ESXi est le client NFS, donc pas de problème de pilote de réseau sur l'invité Linux. Du côté du serveur NFS, j'ai essayé à la fois les serveurs virtuels e1000 et vmxnet3: cela ne fait aucune différence. Autant que je sache, ESXi utilise uniquement le déchargement TCP pour iSCSI.
— exo_cw
Le plus grand ? Pourquoi l’ajustement de la fenêtre TCP ferait-il une différence? Mon instinct me dit que cela a quelque chose à voir avec la fragmentation de ces grandes PDU sur TCP. Quelque chose dans la pile de réseaux qui s'étouffe. Je ne peux tout simplement pas penser à quelque chose qui conviendrait au comportement que nous observons. Si la taille de la fenêtre posait problème, nous devrions constater une latence contraignante pour la bande passante au milieu d’un transfert important, mais pas au début, mais c’est toujours le premier paquet de l’appel RPC ... difficile.
— Ryan
2

J'ai le même problème avec les machines virtuelles ESXi4.1U1 et CentOS. Les hôtes sont des Dell R610, le stockage est un cluster EMC2 Isilon.

Avez-vous utilisé VLANS par hasard? J'ai constaté que l'utilisation d'un réseau local virtuel sur le port VMkernel pour le stockage provoquait le blocage de 4000 à 5000 ms pour tout le trafic de stockage sur le VMHost. Cependant, si je déplace le port VMkernel du VLAN pour qu'il reçoive les paquets non étiquetés, je ne vois pas le problème.

La configuration simple ci-dessous causera le problème sur mon réseau:

1) Installez ESXi 4.1U1 sur un serveur ou une station de travail (les deux ont présenté le problème lorsque j'ai essayé)

2) Ajoutez un port VMkernel sur un VLAN.

3) Ajouter un magasin de données NFS (le mien est sur le même réseau local virtuel, c’est-à-dire que l’Isilon reçoit les paquets étiquetés)

4) Installez 2 machines virtuelles CentOS 5.5, une avec ioping.

5) Démarrer les VM en mode mono-utilisateur (c'est-à-dire pas de réseau, services minimum)

6) Exécuter ioping sur une machine pour écrire sur son disque virtuel

7) Exécutez dd ou quelque chose sur l’autre machine pour écrire 100 Mo de données dans / tmp ou similaire

Le plus souvent, je constate le gel des deux ordinateurs virtuels pendant 4 à 5 secondes.

Soyez vraiment intéressé de voir si quelqu'un d'autre a vu la même chose.

— Entaille
source
Bienvenue sur Server Fault! C'est une vieille question. Si les réponses ne vous aident pas directement, vous devez poser une nouvelle question en cliquant sur le bouton Poser la question .
— user9517 prend en charge GoFundMonica
Oui, bien sûr, j'utilise des VLAN marqués. Comme je les utilise partout, je ne les ai même pas considérées comme une source potentielle de ce problème. Je vais essayer de reproduire cela sur un port non étiqueté.
— exo_cw
Je peux reproduire ce problème également sur un port non étiqueté, aucun VLAN impliqué sur cet hôte.
— exo_cw
J'essayais encore et voyais le problème sur le port non étiqueté aussi, c'est un peu moins fréquent, c'est peut-être pour ça que je l'ai raté. Désolé pour le bum-steer. Je ne vois pas le problème sur Win7 64 bits en utilisant iometer, plus il semble que je puisse naviguer sur le lecteur c: tandis que les autres vms de Linux sont bloqués. Je vais essayer avec crystaldiskmark
— Nick
En fait, je serais intéressé de voir vos résultats avec iometer sur win7 x64. Il mesure la latence, mais le chiffre global le plus élevé que j'ai obtenu était de 300 ms à l'aide du test de lecture 4k, et non de 4000 + ms
— Nick
2

Nous avons eu exactement le même problème il y a deux semaines. ESX41 U1 et Netapp FAS3170 + Banques de données NFS. Les machines virtuelles RHEL5 s’arrêtent pendant 2 ou 4 secondes et nous avons constaté des pics très élevés à partir de la console de performance Virtual Center.

Je demande au responsable du réseau de vérifier la configuration et le problème se situe au niveau du commutateur Cisco. Nous avons deux liaisons Ethernet configurées sur Etherchannel du côté de Netapp et non du côté de Cisco. Il crée un Ethechannel statique sur le cisco et maintenant tout fonctionne bien. Pour identifier ce type de problème, fermez tous les ports sauf un entre le gestionnaire de fichiers et le commutateur. Laissez un seul port en vie et voyez comment les choses se passent.

La deuxième chose que nous avons faite était de supprimer le contrôle de flux sur le commutateur et le fichier car nous soupçonnons qu’il envoie une trame en pause.

— Laurent
source
1

A quoi ressemble votre DNS? Est votre /etc/resolv.confcorrect? Le délai d'attente par défaut est de 5 secondes.

De man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Essayez d’ajouter timeout:3à /etc/resolv.confvotre fichier, puis exécutez à nouveau vos tests fsync.

— Joseph Kern
source
J'ai essayé d'ajouter ceci sur le serveur NFS (OpenIndiana dans ce cas) et sur l'hôte ESXi. Malheureusement, cela ne fait aucune différence. Je peux très bien résoudre l'adresse IP du serveur et de l'invité.
— exo_cw
on dirait que vous avez filtré tout le trafic non lié au flux nfs, nous pourrions en avoir besoin de voir plus!
— tony roth
@tony roth: En fait, c'est tout le trafic à ce moment-là. J'ai testé cela sur un vSwitch distinct avec uniquement l'hôte et le serveur NFS.
— exo_cw
Pouvez-vous vider DNS avec Wireshark?
— Joseph Kern
@ Joseph Kern: Je viens d'analyser à nouveau les fichiers de capture: il n'y a pas eu de trafic DNS du tout lors de mes captures. Le magasin de données NFS est mappé par IP sur l'hôte ESXi. Le DNS fonctionne bien sur ESXi et le serveur NFS. J'ai testé la recherche directe et inversée de toutes les adresses IP concernées. À l'heure actuelle, je n'ai aucune raison de croire que le DNS en est la cause.
— exo_cw
1

Vous ne savez pas quoi, mais quelles cartes réseau utilisez-vous sur ces serveurs? Les administrateurs système de Stack Overflow ont eu d’excellents problèmes de réseau avec les cartes réseau Broadcom, qui ont disparu lorsqu’ils sont passés aux cartes réseau Intel: http://blog.serverfault.com/post/broadcom-die-mutha/

— zippy
source
Les derniers tests ont été effectués sur un vSwitch uniquement, sans réseau physique impliqué (e1000 et vmxnet3: aucune différence). Mais j'ai aussi testé cela sur Intel 82574L, Intel 82576 et Intel 82567LF-3, ce qui montre tous le problème. Je n'ai pas encore trouvé de matériel où je ne puisse pas le reproduire.
— exo_cw
1

Voici une autre hypothèse ... Votre IPv6 est-il activé sur un hôte EXS? Si oui, alors essayez de l'éteindre? D'après mon expérience, si tout votre réseau n'est pas correctement configuré pour IPv6 (c'est-à-dire RADV, DHCP6, DNS, DNS inversé), cela peut poser problème pour certains services. Assurez-vous également qu'il est désactivé sur le serveur NFS.

— dtoubelis
source
IPv6 était déjà désactivé sur l'hôte ESXi. J'ai désactivé IPv6 sur le serveur NFS (ifconfig -a6 est vide à présent), mais cela ne change rien: il présente les mêmes problèmes.
— exo_cw
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.