Dépannage des pics de latence sur ESXI NFS Datastores
Je suis en train de vivre des latences FSYNC des environs cinq secondes sur les données de données NFS dans ESXI, déclenchée par certains VMS. Je soupçonne que cela pourrait être causé par des VMS à l'aide de NCQ/TCQ, car cela ne se produit pas avec Virtual IDE.
Cela peut être reproduit en utilisant FSYNC-TESTER (par Ted Ts'o) et ioping . Par exemple, à l'aide d'un système GRML en direct 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 des millisecondes. Ceci crée même des latences io-latences sur un autre VM exécuté 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 le premier VM au stockage local, il 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 ...]
Choses que j'ai essayées qui n'a fait aucune différence:
- Testé plusieurs constructions ESXI: 381591, 348481, 260247
- Testé sur différents matériels, différents boîtes Intel et Amd
- Testé avec différents serveurs NFS, tous montrent le même comportement:
- OpenIndiana B147 (synchronisation ZFS toujours ou désactivée: Aucune différence)
- OpenIndiana B148 (Sync ZFS toujours ou désactivé: Aucune différence)
- Linux 2.6.32 (synchronisation ou async: aucune différence)
- Il ne fait aucune différence si le serveur NFS est sur la même machine (en tant qu'appareil de stockage virtuel) ou sur un hôte différent.
OS invités testés, montrant des problèmes:
- Windows 7 64 bits (en utilisant CrystalDiskmark, les pics de latence se produisent principalement pendant la préparation de la phase)
- Linux 2.6.32 (FSYNC-TESTER + IOPING)
- Linux 2.6.38 (FSYNC-TESTER + IOPING)
Je ne pouvais pas reproduire ce problème sur Linux 2.6.18 VMS.
Une autre solution consiste à utiliser virtual IDE (VS SCSI/SAS), mais qui limite les performances et le nombre de lecteurs par vm.
Mise à jour 2011-06-30 :
Les crampons de latence semblent se produire plus souvent si l'application écrit dans plusieurs petits blocs avant FSYNC. Par exemple, FSYNC-TESTER fait ceci (Sortie Strace):
pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3) = 0
l'ioping le fait en préparant le 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 l'ioping est presque toujours suspendue, tandis que FSYNC-testeur fonctionne parfois 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 accès facile aux fichiers VMDK afin que vous puissiez les déplacer entre des hôtes avec des instantanés et RSYNC.
Mise à jour 2011-07-06:
Cela fait partie d'une capture de fil de fil, capturé par un troisième VM sur le même vswitch. Tout cela se produit sur le même hôte, aucun réseau physique impliqué.
J'ai commencé à utiliser le temps 20. Il n'y avait pas de paquets envoyés tant que le délai de cinq secondes était terminé:
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
2e Mise à jour 2011-07-06 :
Il semble y avoir une certaine influence de TCP Tailles de la fenêtre. Je n'ai pas pu reproduire ce problème à l'aide de Freeenas (basé sur FreeBSD) en tant que serveur NFS. Les captures de Wireshark ont montré TCP La fenêtre met à jour 29127 octets à intervalles réguliers. Je ne les ai pas vus avec Openindiana, qui utilise des formes de fenêtre plus grandes par défaut.
Je ne peux plus reproduire ce problème si je définissais les options suivantes à Openindiana et redémarrez 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/zéro à un fichier avec dd_rescue passe de 170 Mo/s à 80 Mo/s.
Mise à jour 2011-07-07:
J'ai téléchargé ceci Capture TCPDump (peut être analysé avec Wireshark). Dans ce cas, 192.168.250.2 est le serveur NFS (OpenIndiana B148) et 192.168.250.10.10.10 est l'hôte ESXI.
Choses que j'ai testées pendant cette capture:
A commencé "ioping -w 5 -i 0.2." Au temps 30, 5 secondes accrochées dans la configuration terminée à l'heure 40.
A commencé "ioping -w 5 -i 0.2." Au temps 60, 5 secondes accrochées dans la configuration terminée à l'heure 70.
Démarré "FSYNC-TESTER" à l'heure 90, avec la sortie suivante, arrêtée à 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:
Testé un autre serveur NFS serveur VM, cette fois Nexentastor 3.0.5 Edition communautaire: montre les mêmes problèmes.
Mise à jour 2011-07-31 :
Je peux également reproduire ce problème sur la nouvelle version ESXI 4.1.0.433742.
Ce problème semble être fixé dans ESXI 5. J'ai testé la construction 469512 avec succès.
Merci, nfsttat a l'air bien. J'ai examiné la capture. Je n'ai rien trouvé de concluance, mais a trouvé quelque chose d'intéressant. J'ai filtré sur tcp.time_delta> 5. Qu'est-ce que j'ai trouvé dans chaque Délai d'instance était le début exact d'un appel RPC. Tous les nouveaux appels RPC n'ont pas été lents, mais tous les ralentissements ont eu lieu au début exact d'un appel RPC. De plus, à partir de la capture, il apparaît que le 192.168.250.10 contient tout le délai. 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 commandes NFS n'ont pas été corrélés pour retarder les instances
- Fragmentation = retarde uniquement le premier paquet
Un grand appel d'écriture peut rompre dans 300 individu TCP paquets, et seul le premier est retardé, mais le reste tous voler. Jamais le retard ne se produit au milieu. Je ne suis pas sûr. Comment la taille de la fenêtre pourrait affecter le début de la connexion si radicalement.
Étapes suivantes: Je commencerais à modifier les options NFS comme nfssvc_maxblksize vers le bas plutôt que le TCP fenêtre. En outre, j'ai remarqué que 2.6.18 fonctionne tandis que 2.6.38 ne le fait pas. Je sais que le soutien a été ajouté pour le pilote VMXNET3 au cours de cette période. Qu'est-ce que NIC Les pilotes utilisez-vous sur les hôtes? TCP Déchargement Oui/Non? Autour de la marque 95SECOND Il y a Plus de 500 TCP paquets pour un seul appel d'écriture NFS. Tout ce qui est en charge de TCP et briser le grand PDU pourrait être ce qui bloque.
Nous avions exactement le même problème il y a deux semaines. ESX41 U1 et NetApp FAS3170 + DataStores NFS. RHEL5 VMS est suspendu pendant 2 ou 4 secondes et nous avons vu des pointes très élevées de la console de performance du centre virtuel.
Je demande au réseau réseau de vérifier la configuration et le problème était sur le commutateur Cisco. Nous avons deux liaisons Ethernet configurés sur EtherChannel sur le côté NetApp et non sur le côté Cisco. Il crée une éthechannel statique sur le Cisco et cela fonctionne maintenant bien. Pour identifier ce type de problème, arrêtez tout le port, sauf un entre le déposant et le commutateur. Laissez un seul port vivant et voyez comment ça va.
La deuxième chose que nous faisons, c'était pour supprimer le contrôle de flux sur le SWITTCJ et le déposant, car nous le soupçonnons d'envoyer une trame de pause.
J'ai ce qui ressemble au même problème utilisant ESXI4.1U1 et Centos VM's. Les hôtes sont Dell R610S, le stockage est un groupe EMC2 ISILON.
Étiez-vous par hasard en utilisant des vlans? J'ai trouvé à l'aide d'un VLAN sur le port VMKernel pour le stockage a provoqué le stockage de 4000-5000 ms 'pour tous les trafic de stockage sur le VMhost. Toutefois, si je déplace le port VMKernel sur le VLAN Donc, il reçoit des paquets non étiquetés, je ne vois pas le problème.
La configuration simple ci-dessous provoquera le problème sur mon réseau:
1) Installez ESXI 4.1U1 sur un serveur ou un poste de travail (les deux présentaient le problème quand j'ai essayé)
2) Ajouter un port Vmkernel sur un VLAN.
3) Ajouter un magasin de données NFS (la mine est sur le même VLAN, c'est-à-dire Isilon reçoit des paquets étiquetés)
4) Installez 2 Centos 5.5 VM's, un avec ioping.
5) Boot VM est en mode utilisateur unique (c'est-à-dire aucun réseau, services minimum)
6) exécutez ioping sur une machine afin qu'il écrive sur son disque virtuel
7) Exécutez DD ou somesuch sur l'autre machine pour écrire 100 Mo de données/TMP ou similaire
Plus souvent que non, je vois les deux gel de VM pendant 4-5 secondes.
Soyez vraiment intéressé à voir si quelqu'un d'autre a vu semblable.
Comment votre DNS a-t-il l'air? Est ton /etc/resolv.conf correct? 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 à ton /etc/resolv.conf puis exécutez vos tests FSYNC à nouveau.
Saisir aux pailles ici, mais quels Nics utilisez-vous dans ces serveurs? Les Sysadmins de pile ont eu des problèmes de mise en réseau étrange avec Broadcom Nics qui se sont éloignés lorsqu'ils sont passés à Intel Nics: http://blog.serverfault.com/post/broadcom-die-mutha/
Voici une autre hypothèse ... est votre IPv6 activé sur EXS Host? Si oui, essayez-la de l'éteindre? De mon expérience si tout votre réseau n'est pas correctement configuré pour IPv6 (I.E. RADV, DHCP6, DNS, DNS inverse) Il peut s'agir d'un problème pour certains services. Assurez-vous également qu'il est désactivé sur le serveur NFS.