Fehlerbehebung bei Latenzspitzen in ESXi NFS-Datenspeichern

44

Bei NFS-Datenspeichern in ESXi treten fsync-Latenzen von etwa fünf Sekunden auf, die von bestimmten VMs ausgelöst werden. Ich vermute, dass dies durch VMs mit NCQ / TCQ verursacht werden kann, da dies bei virtuellen IDE-Laufwerken nicht der Fall ist.

Dies kann mit fsync-tester (von Ted Ts'o) und ioping reproduziert werden . Beispiel für die Verwendung eines Grml-Live-Systems mit einer 8-GB-Festplatte:

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 ...]

Das sind 5 Sekunden, keine Millisekunden. Dies führt sogar zu E / A -Latenzen auf einer anderen VM, die auf demselben Host und Datenspeicher ausgeführt wird :

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

Wenn ich die erste VM in den lokalen Speicher verschiebe, sieht das ganz normal aus:

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 ...]

Dinge, die ich ausprobiert habe, die keinen Unterschied machten:

Mehrere ESXi-Builds getestet: 381591, 348481, 260247
Getestet auf unterschiedlicher Hardware, verschiedenen Intel- und AMD-Boxen
Getestet mit verschiedenen NFS-Servern zeigen alle dasselbe Verhalten:
- OpenIndiana b147 (ZFS-Synchronisierung immer oder deaktiviert: kein Unterschied)
- OpenIndiana b148 (ZFS-Synchronisierung immer oder deaktiviert: kein Unterschied)
- Linux 2.6.32 (synchron oder asynchron: kein Unterschied)
- Es spielt keine Rolle, ob sich der NFS-Server auf demselben Computer (als virtuelle Speicher-Appliance) oder auf einem anderen Host befindet

Gastbetriebssystem getestet, zeigt Probleme:

Windows 7 64 Bit (bei Verwendung von CrystalDiskMark treten Latenzspitzen hauptsächlich während der Vorbereitungsphase auf)
Linux 2.6.32 (fsync-tester + ioping)
Linux 2.6.38 (fsync-tester + ioping)

Ich konnte dieses Problem auf Linux 2.6.18-VMs nicht reproduzieren.

Eine andere Problemumgehung besteht darin, virtuelle IDE-Festplatten (im Vergleich zu SCSI / SAS) zu verwenden. Dies schränkt jedoch die Leistung und die Anzahl der Laufwerke pro VM ein.

Update 30.06.2011:

Die Latenzspitzen scheinen häufiger aufzutreten, wenn die Anwendung vor fsync in mehrere kleine Blöcke schreibt. Zum Beispiel macht fsync-tester das (strace output):

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

Ioping tut dies während der Vorbereitung der Datei:

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

Die Einrichtungsphase von ioping hängt fast immer, während fsync-tester manchmal gut funktioniert. Kann jemand fsync-tester aktualisieren, um mehrere kleine Blöcke zu schreiben? Meine C-Fähigkeiten sind zum Kotzen;)

Update 02.07.2011:

Dieses Problem tritt bei iSCSI nicht auf. Ich habe dies mit dem OpenIndiana COMSTAR iSCSI-Server versucht. ISCSI bietet jedoch keinen einfachen Zugriff auf die VMDK-Dateien, sodass Sie sie mit Snapshots und Rsync zwischen Hosts verschieben können.

Update 06.07.2011:

Dies ist Teil einer Wireshark-Erfassung, die von einer dritten VM auf demselben vSwitch erfasst wird. Dies geschieht alles auf demselben Host, ohne dass ein physisches Netzwerk beteiligt ist.

Ich habe gegen 20 Uhr angefangen zu jopen. Es wurden keine Pakete gesendet, bis die fünf Sekunden Verzögerung vorbei waren:

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. Update 06.07.2011:

Die TCP-Fenstergröße scheint einen gewissen Einfluss zu haben. Ich konnte dieses Problem mit FreeNAS (basierend auf FreeBSD) als NFS-Server nicht reproduzieren. Die Wireshark-Erfassungen zeigten in regelmäßigen Abständen TCP-Fensteraktualisierungen auf 29127 Bytes. Ich habe sie nicht mit OpenIndiana gesehen, das standardmäßig größere Fenster verwendet.

Ich kann dieses Problem nicht mehr reproduzieren, wenn ich die folgenden Optionen in OpenIndiana festgelegt und den NFS-Server neu gestartet habe:

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

Dies beeinträchtigt jedoch die Leistung: Das Schreiben von / dev / zero in eine Datei mit dd_rescue geht von 170 MB / s auf 80 MB / s über.

Update 2011-07-07:

Ich habe dieses tcpdump-Capture hochgeladen (kann mit wireshark analysiert werden). In diesem Fall ist 192.168.250.2 der NFS-Server (OpenIndiana b148) und 192.168.250.10 der ESXi-Host.

Dinge, die ich während dieser Aufnahme getestet habe:

Gestartet mit "Ioping -w 5 -i 0,2". zum Zeitpunkt 30 hängen 5 Sekunden im Setup, abgeschlossen zum Zeitpunkt 40.

Gestartet mit "Ioping -w 5 -i 0,2". zum Zeitpunkt 60 hängen 5 Sekunden im Setup, abgeschlossen zum Zeitpunkt 70.

Startete "fsync-tester" zum Zeitpunkt 90 mit der folgenden Ausgabe und stoppte zum Zeitpunkt 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. Aktualisierung 07.07.2011:

Getestet eine andere NFS-Server-VM, diesmal NexentaStor 3.0.5 Community Edition: Zeigt die gleichen Probleme.

Update 2011-07-31:

Ich kann dieses Problem auch auf dem neuen ESXi-Build 4.1.0.433742 reproduzieren.

vmware-esxi nfs latency

— exo_cw
quelle

12

Ich muss sagen, dass es eine Weile her ist, dass ein brandneuer Benutzer mit einer so gut dokumentierten und durchdachten Frage an die Tafel gekommen ist - im Ernst, hats vor dir. Es ist auch wirklich interessant, ich bin noch nie auf fsync-tester gestoßen, also danke. Trotzdem bin ich mir nicht sicher, ob ich noch etwas hinzuzufügen habe. Sie haben so viele Dinge ausprobiert, die ich bereits getan hätte. Ich würde sagen, Sie sprechen mit VMWare, um ehrlich zu sein von "Long-Tail" / "kein tatsächlicher Service-Ausfall" Zeug ernst. Wie auch immer, ich wollte nur sagen, gut gemacht für das, was du bisher getan hast :)

— Chopper3

Auf der VMware-Website kann ich sie leider nicht kontaktieren: "Sie haben derzeit keine aktiven Support-Ansprüche"

— exo_cw

ah, ja, das kann natürlich ein Problem sein ...

— Chopper3

3

5-Sekunden-Timeout mit NFS kam mir bekannt vor. In Linux NFS gibt es ein Timeout von 0,7 Sekunden für RPC, das sich nach jedem Fehler verdoppelt und nach 3 Fehlern einen Major zieht (Standardeinstellungen). 7 + 1,4 + 2,8 = 4,9 Sekunden. Es gibt eine Vielzahl von RPC-Authentifizierungsproblemen, die dies verursachen können.

— Mark

2

@ Ryan: Ich habe die Capture-Datei hochgeladen. Ich habe auch die nfsstat-Ausgabe hochgeladen .

— Exo_CW

5

Dieses Problem scheint in ESXi 5 behoben zu sein. Ich habe Build 469512 erfolgreich getestet.

— exo_cw
quelle

3

Danke, nfsstat sieht gut aus. Ich habe die Aufnahme überprüft. Nichts aussagekräftiges gefunden, aber etwas interessantes gefunden. Ich habe nach tcp.time_delta> 5 gefiltert. Was ich in jeder Verzögerungsinstanz gefunden habe, war der genaue Start eines RPC-Aufrufs. Nicht alle neuen RPC-Aufrufe waren langsam, aber alle Verzögerungen traten genau zu Beginn eines RPC-Aufrufs auf. Aus der Erfassung geht außerdem hervor, dass 192.168.250.10 die gesamte Verzögerung enthält. 192.168.250.2 antwortet sofort auf alle Anfragen.

Ergebnisse:

Verzögerungen treten immer im ersten Paket eines RPC-Aufrufs auf
NFS-Befehlstypen wurden nicht mit Verzögerungsinstanzen korreliert
Fragmentierung = verzögert nur das erste Paket

Ein großer Schreibaufruf kann in 300 einzelne TCP-Pakete aufgeteilt werden, und nur das erste wird verzögert, während der Rest alle durchfliegt. Niemals tritt die Verzögerung in der Mitte auf. Ich bin nicht sicher, wie die Fenstergröße den Beginn der Verbindung so drastisch beeinflussen könnte.

Nächste Schritte: Ich würde anfangen, die NFS-Optionen wie NFSSVC_MAXBLKSIZE nach unten und nicht das TCP-Fenster zu optimieren. Außerdem ist mir aufgefallen, dass 2.6.18 funktioniert, 2.6.38 nicht. Ich weiß, dass in diesem Zeitraum Unterstützung für den VMXnet3-Treiber hinzugefügt wurde. Welche NIC-Treiber verwenden Sie auf den Hosts? TCP auslagern ja / nein? Um die 95-Sekunden-Marke herum gibt es mehr als 500 TCP-Pakete für einen einzelnen NFS-Schreibaufruf. Was auch immer für TCP zuständig ist und die große PDU zerstört, könnte blockieren.

— Ryan
quelle

Ich habe versucht, nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots und nfs: nfs3_bsize auf 8192 zu setzen: Kein Unterschied, gleiche Probleme. Die Linux-Gäste verwenden nur ihre SCSI / SAS-Festplatten, kein NFS - das ESXi ist der NFS-Client, daher gibt es keine Netzwerktreiberprobleme auf dem Linux-Gast. Auf der NFS-Serverseite habe ich sowohl virtual e1000 als auch vmxnet3 ausprobiert: Hat keinen Unterschied gemacht. Soweit ich weiß, verwendet ESXi nur TCP-Offloading für iSCSI.

— exo_cw

Der Größte ? Ich habe, warum das Anpassen des TCP-Fensters einen Unterschied machen würde ... Mein Bauch sagt mir, dass es etwas mit der Fragmentierung dieser großen PDUs über TCP zu tun hat. Etwas im Netzwerkstapel, das daran erstickt. Ich kann mir einfach nichts vorstellen, das zu dem Verhalten passt, das wir sehen. Wenn die Fenstergröße ein Problem war, sollte die Latenz die Bandbreite in der Mitte einer großen Übertragung einschränken, nicht am Anfang, aber es ist immer das erste Paket des RPC-Aufrufs ... harte Frage.

— Ryan

2

Ich habe das gleiche Problem mit ESXi4.1U1 und CentOS VMs. Die Hosts sind Dell R610s, der Speicher ist ein EMC2-Isilon-Cluster.

Haben Sie zufällig VLANS verwendet? Die Verwendung eines VLAN auf dem VMkernel-Port für die Speicherung führte dazu, dass 4000-5000 ms für den gesamten Speicherverkehr auf dem VMHost hängen blieben. Wenn ich jedoch den VMkernel-Port aus dem VLAN verschiebe, sodass er Pakete ohne Tags empfängt, wird das Problem nicht angezeigt.

Die folgende einfache Einrichtung verursacht das Problem in meinem Netzwerk:

1) Installieren Sie ESXi 4.1U1 auf einem Server oder einer Workstation (beide zeigten das Problem, als ich es versuchte)

2) Fügen Sie einen VMkernel-Port in einem VLAN hinzu.

3) Fügen Sie einen NFS-Datenspeicher hinzu (meiner befindet sich im selben VLAN, dh der Isilon empfängt markierte Pakete).

4) Installieren Sie zwei CentOS 5.5-VMs, eine mit Ioping.

5) Starten Sie VMs im Einzelbenutzermodus (dh kein Netzwerk, minimale Dienste)

6) Führen Sie ioping auf einer Maschine aus, damit auf die virtuelle Festplatte geschrieben wird

7) Führen Sie dd oder etwas Ähnliches auf dem anderen Computer aus, um 100 MB Daten in / tmp oder ähnliches zu schreiben

In den meisten Fällen frieren beide VMs 4-5 Sekunden lang ein.

Seien Sie wirklich interessiert zu sehen, ob jemand Ähnliches gesehen hat.

— Nick
quelle

Willkommen bei Server Fault! Das ist eine alte Frage. Wenn es die Antworten Sie nicht direkt helfen , dann sollten Sie eine neue Frage stellen NEUE durch Klicken Frage stellen Taste.

— user9517 unterstützt GoFundMonica

Ja, natürlich verwende ich getaggte VLANs. Da ich sie überall verwende, habe ich sie nicht einmal als mögliche Ursache für dieses Problem angesehen. Ich werde versuchen, dies auf einem nicht getaggten Port zu reproduzieren.

— exo_cw

Ich kann dieses Problem auch auf einem nicht getaggten Port reproduzieren, auf diesem Host sind überhaupt keine VLANs beteiligt.

— exo_cw

Ich habe es nur noch einmal versucht und das Problem auch auf dem nicht gekennzeichneten Port gesehen. Es ist etwas seltener. Vielleicht habe ich es deshalb verpasst. Entschuldigung für den Penner. Ich kann das Problem unter Win7 64-Bit mit dem iometer nicht sehen, und es scheint, dass ich das c: -Laufwerk durchsuchen kann, während die anderen Linux-VMs hängen bleiben. Ich werde es mit crystaldiskmark versuchen

— Nick

Eigentlich würde es mich interessieren, deine Ergebnisse mit iometer auf win7 x64 zu sehen. Es misst die Latenz, aber die höchste Gesamtzahl, die ich erhielt, war 300 ms mit dem 4k-Lesetest, nicht 4000 + ms

— Nick

2

Wir hatten vor zwei Wochen genau das gleiche Problem. ESX41 U1- und Netapp FAS3170 + NFS-Datenspeicher. RHEL5-VMs bleiben 2 oder 4 Sekunden hängen und die Virtual Center-Leistungskonsole zeigt sehr hohe Spitzenwerte.

Ich bitte den Netzwerktyp, die Konfiguration zu überprüfen, und das Problem lag beim Cisco-Switch. Wir haben zwei Ethernet-Links, die auf Etherchannel auf der NetApp-Seite und nicht auf der Cisco-Seite konfiguriert wurden. Er erstellt einen statischen Ethechannel auf dem Cisco und jetzt funktioniert es einwandfrei. Um diese Art von Problem zu identifizieren, schalten Sie alle Ports außer einem zwischen dem Filer und dem Switch aus. Lassen Sie nur einen Port am Leben und sehen Sie, wie die Dinge laufen.

Das zweite, was wir tun, war, die Flusskontrolle auf dem Switch und dem Filer zu entfernen, weil wir den Verdacht haben, dass ein Pausenrahmen gesendet wird.

— Laurent
quelle

1

Wie sieht dein DNS aus? Ist dein /etc/resolv.confrecht Das Standardzeitlimit beträgt 5 Sekunden.

Von 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>).

Versuchen Sie, timeout:3an /etc/resolv.confIhre anzuhängen, und führen Sie dann die fsync-Tests erneut aus.

— Joseph Kern
quelle

Ich habe versucht, dies auf dem NFS-Server (in diesem Fall OpenIndiana) und auf dem ESXi-Host hinzuzufügen. Das macht leider keinen Unterschied. Ich kann die Server- und Gast-IP gut auflösen.

— exo_cw

Anscheinend haben Sie den gesamten Datenverkehr herausgefiltert, der nicht mit dem NFS-Stream zusammenhängt. Möglicherweise müssen wir noch mehr sehen!

— Tony Roth

@tony roth: Eigentlich ist das der ganze Verkehr zu dieser Zeit. Ich habe das auf einem separaten vSwitch getestet, auf dem sich nur der Host und der NFS-Server befinden.

— exo_cw

Können Sie DNS mit wireshark ausgeben?

— Joseph Kern

@Joseph Kern: Ich habe gerade die Erfassungsdateien noch einmal analysiert: Während meiner Erfassungen gab es überhaupt keinen DNS-Verkehr. Der NFS-Datenspeicher wird auf dem ESXi-Host nach IP zugeordnet. DNS funktioniert einwandfrei auf dem ESXi und dem NFS-Server. Ich habe die Forward- und Reverse-Suche aller beteiligten IPs getestet. Im Moment habe ich keinen Grund zu der Annahme, dass DNS die Ursache dafür ist.

— Exo_CW

1

Hier nach Strohhalmen greifen, aber welche NICs verwenden Sie in diesen Servern? Die Stack Overflow-Systemadministratoren hatten seltsame Netzwerkprobleme mit Broadcom-NICs, die beim Wechsel zu Intel-NICs behoben wurden: http://blog.serverfault.com/post/broadcom-die-mutha/

— flink
quelle

Die letzten Tests wurden nur mit einem vSwitch durchgeführt, ohne dass ein physisches Netzwerk beteiligt war (e1000 und vmxnet3: machten keinen Unterschied). Aber ich habe dies auch auf Intel 82574L, Intel 82576 und Intel 82567LF-3 getestet, die alle das Problem zeigen. Ich habe noch keine Hardware gefunden, die ich nicht reproduzieren kann.

— exo_cw

1

Hier ist eine andere Vermutung ... Ist Ihr IPv6 auf dem EXS-Host aktiviert? Wenn ja, dann versuchen Sie es auszuschalten? Nach meiner Erfahrung kann es bei einigen Diensten zu Problemen kommen, wenn Ihr gesamtes Netzwerk nicht richtig für IPv6 konfiguriert ist (z. B. RADV, DHCP6, DNS, Reverse DNS). Stellen Sie außerdem sicher, dass es auf dem NFS-Server deaktiviert ist.

— dtoubelis
quelle

IPv6 wurde bereits auf dem ESXi-Host deaktiviert. Ich habe IPv6 auf dem NFS-Server deaktiviert (ifconfig -a6 ist jetzt leer), aber es macht keinen Unterschied: Es zeigt die gleichen Probleme.

— exo_cw