vsphere 5.1 iSCSI hohe Latenz Read

[Cr4sh]

Hey Leute,

könnt ihr mir Erfahrungswerten von euren Latzenzen mit iSCSI Storage geben?
Ich habe irgendwie schlechte Latenzen beim Lesen. Schreiben ist in Ordnung.



Ich habe ein iSCSI Storage auf Basis von CentOS.
Ich habe gefühlt neuerdings relativ hohe Latenzen. Die SAN langweielt sich hat selbst hat ein Load Average von 0.12 / 0.20 / 0.70. CPU´s haben 0.0% waits und id ist bei 98,5%.

Das ISCSI Netz ist über eine HP Switch derzeit 1GBit aus Fehlersuche angebunden. Der Switch meldet keine Packet Error auf allen Ports = 0.Der 1Gbit Port ist auch nicht auf Volllast.

Die ESXI Server langweilen sich vom Prinzip her auch 50% RAM frei und CPU Nutzung wenn es hoch kommt 10%.

Fehlersuche habe ich bereits eine zweites Storage aufgebaut gleichen Symtome. Switch wurde bereits ausgetauscht. Habe drei ESXi Server mit 5.1 und alle zeigen die gleichen (schlechten Latenzen).

Weiß langsam nicht mehr weiter... VMKernel.log spuckt auch nix aus.

[weigeltchen]

Hardware Basis des iSCSI-Storage?

[Cr4sh]

Hier die Grundzüge:

- Intel Xeon E5-2609 Quad-Core 2,4Ghz
- 16GB RAM
- 16x SATA, 8x SSD mit Adaptec ASR72405
- 2x 10Gbit LAN

[pirx]

Ich weiß nie so recht was ich von iSCSI erwarten kann. Bei uns sieht das mit einer größeren iSCSI Umgebung (Lefthand) so aus. Und HP meint das ist ok so.

[Cr4sh]

Das sieht ja dann so ungefähr aus wie bei mir.

Alle sagen ja immer bis 30ms ist alles gut.Aber ich mache mir halt Gedanken das ich jetzt noch relativ wenig Last habe und schon Latenzen bis 20ms habe. Was passiert wenn ich richtig Last rauf packe?

[pirx]

Man muss sich irgendwann einfach von der Vorstellung verabschieden, dass VMs in einer virtuellen Umgebungen immer eine vergleichbare Performance bieten wie klassische physische Server. Wenn nur CPU und Memory eine Rolle spielen ist es kein großer Unterschied, sobald eine VM aber viel auf das Storage zugreift, sieht die Welt anders aus. Das kann man heute sicher alles mit SSDs/Flash Speicher kompensieren, aber in den wenigsten Umgebungen wird das aus Kostengründen gemacht. Zumindest bei uns ist praktisch immer das Storage der Flaschenhals. Das muss nicht immer kritisch sein, aber selber einfache Dinge wie das Syncen (sequentieller Zugriff) von größeren Datenmengen, dauert deutlich länger als auf einem alten physischen Server mit 3 internen Disks.

Selbst in einer Umgebung mit aktueller HP EVA + VPLEX steigen dann die Latenzen z.B. bei solchen Kopieraktionen auf > 80ms für längere Zeit. Das ist eben so.

Früher waren unkritische Systeme bei denen Performance keine große Rolle spielt bei der Virtualisierung das Ziel. Heute wird praktisch alles virtualisiert.

Das hat jetzt nicht direkt was mit deinen Latenzen zu tun, aber gerade das sollte bei der Planung berücksichtigt werden.

[bla!zilla]

Ich kann das so nicht bestätigen. Ich habe selber ein paar iSCSI Umgebungen bei Kunden und kann das Lastverhalten so nicht bestätigen.

Ich habe bei einem Kunden ein DB Cluster virtualisiert. Zentrales MS SQL Cluster für ein ERP System. Backup und Batch-Jobs liefen nach der Virtualisierung 300% schneller. So viel zum Thema "auf Phsyik mit drei Platten war alles schneller...". So schwarz/ weiß ist es dann doch nicht.

Latenzen sind ja immer so eine Sache. Gerade bei iSCSI kommen die meist aus dem Netzwerk. Und 1 GbE ist nicht 1 GbE. Da spielen viele Dinge eine Rolle (VLANs, Latenz der Switches, Port Buffer etc.). iSCSI pauschal als langsam abzustempeln finde ich falsch. Das habe ich in der Praxis anders erlebt.

[pirx]

I
Ich habe bei einem Kunden ein DB Cluster virtualisiert. Zentrales MS SQL Cluster für ein ERP System. Backup und Batch-Jobs liefen nach der Virtualisierung 300% schneller. So viel zum Thema "auf Phsyik mit drei Platten war alles schneller...". So schwarz/ weiß ist es dann doch nicht.

Auf welchem Storage läuft die Applikation jetzt? Und auf welchem lief sie davor? Klar kann man auch eine performantes Storage für virtuelle Umgebungen zur Verfügung stellen, aber es ist aus meine Sicht deutlich schwieriger als bei klassischer Physik. Wir haben hier eine bunte Mischung aus EVAs, VPLEX + EVAs , Lefthand, XPs. Egal welches Storage darunter ist, die Latenzen sind durchweg höher wenn Last existiert.

An der Performance des simplen Sync/Copy Jobs habe ich mir letzte Woche die Zähne aus gebissen. Auf einer alten Physik lief der Job mit ~100 MB/s über das Netz, in unterschiedlichen VMs auf unterschiedlichen Storage Systemen schwankte der Durchsatz zwischen 15 - 50 MB/s. Das Netz ist nicht der Flaschenhals, ipfer zeigt das der volle GbE Durchsatz erreicht wird.

Aber ich schweife ab...

[kastlr]

Hallo zusammen,

Gegenfrage, was für IO Aktivitäten finden denn zu diesem Zeitpunkt statt?

Latenzen hängen nämlich extrem davon ab, was dem Storage gerade vor die Füße geschmissen wird.

Bei Kopieraktionen sind große Latenzen kein Problem, schließlich willst du hohen Durchsatz, ob ein IO dabei 5 oder 30 ms dauert ist sekundär.
Kopieraktionen verwenden üblicherweise größe IO Sizes, und es dauert halt länger, 512KB oder 1MB zu lesen/schreiben als z.B. 4KB.

Ganz anders sieht es näturlich bei Latenz kritischen Applikationen wie z. B IP Telefonie aus.
Hier ist wiederum der Durchsatz eher sekundär.

Virtualisierung hat an den Anforderungen bezüglich Storage kaum was geändert.
Ob ein System virtuell/physikalisch betrieben wird ist den Applikationen im Allgemeinen egal, und somit auch den Nutzern.

Das eigentliche Problem liegt meistens auf der Seite der Planung & Administration, weil wenige große LUNs ja viel einfacher zu verwalten sind als eine größerer Anzahl LUN's mit unterschiedlichem IO Profil.
So krieg ich jedesmal Plaque, wenn ein Consultant/Kunde 100 Server virtualisiert und deren Last dann auf 20 LUN's packt.
Das ist dann wieder ein Fall von PEBKAC!

Wenn du also "nur" die VMware Performance Charts hast, aber keiner der Kollegen ein Problem meldet, dann hast du vielleicht auch gar keins.

Gruß,
Ralf

[pirx]

Hallo zusammen,
Gegenfrage, was für IO Aktivitäten finden denn zu diesem Zeitpunkt statt?

Das war im Tagesbetrieb, also bunt gemischt.

Wenn du also "nur" die VMware Performance Charts hast, aber keiner der Kollegen ein Problem meldet, dann hast du vielleicht auch gar keins.

Der Kollege kam aber mit dem Hinweis, dass der Job seit er auf der VM läuft, langsamer ist. Latenz hin oder her, der Durchsatz lag bei 50% der Physik und die Laufzeit hat sich verdoppelt.

Edit: was die Größe der LUNs angeht magst du Recht haben. Bei uns sind es inzwischen auch 2 TB. Aber da VMs inzwischen in den DS locker 500 GB+ belegen, kommt man mit kleineren DS kaum noch weiter. Bei eine sDRS Cluster kann es gleich vergessen, da dort die DS ähnliche Größen haben sollten.

[kastlr]

Gut, dann hast du also ein Problem.

Wie viele VM's werden denn auf diesem Datastore betrieben?
Und auf wie viele ESX Server verteilen sich die VM's?
Wie viele IO/s verarbeitet der Datastore denn?

Latenzen können auch aus dem Kernel heraus kommen, wenn z. B. die Queue Depth zu klein gewählt wurde.

Du kannst ja mal mit esxtop überprüfen, was genau passiert und wie sich die Last verteilt.

Gruß,
Ralf

[stahly]

...
So krieg ich jedesmal Plaque, wenn ein Consultant/Kunde 100 Server virtualisiert und deren Last dann auf 20 LUN's packt.
...

Das sind doch nur 5 Server pro LUN?!? Da habe ich schon deutlich Schlimmeres gesehen

[pirx]

Ich habe das Thema hier ja ganz frech entführt, deswegen werden ich die kommenden Tage einen ein eigenes Thema dazu eröffnen.

[kastlr]

Noch ein Punkt zu dem Thema.

In der "alten Welt" hatte ein System seine Platten exklusiv, heute teilen sich alle Systeme einen Storage.
Früher hattest du 100 Server mit je 3 SCSI Platten a 7.200 RPM hattest, heute einen zentralen Storage mit 30 NL SAS Platten.

Schließlich wird beim Sizing einer solchen Umgebung fast ausschließlich die erforderliche Kapazität verwendet, da kaum ein Kunde etwas über sein IO Profil sagen kann.

Und selbst wenn dem so ist, machen die VMware Admins immer wieder ganz profane Fehler.

Wenn z. B. die Anforderung kommt eine DB zu virtualisieren werden zwar wie vom DB Admin gewünscht 4-5 vmdk's erzeugt, aber die liegen brav auf einem Datastore (einer LUN).

Die Logfile Platte mit fast zu 100% Write IO's, die DB Platte darf Random lesen.
Für die LUN unten kommt nur noch Random an, und durch den hohen Write Anteil gibt es kaum noch Read Cache Hits.
Und dann ist die LUN noch aus einer RAID5 Gruppe gebildet worden, deren freie Kapazität dann noch für weitere Datastores und deren VM's verwendet wird.

Kurz und gut, man sollte seinen Storage immer so planen, das die Disks 100% Random IO ohne Verwendung eines Caches bedienen können.
Kommt dann noch Replizierung hinzu, sollte 30-50% Aufschlag eingeplant werden, schließlich wird nicht schneller, wenn man es zweimal macht.

Und das der Storage so gut wie immer das Problem ist ergibt sich fast schon von selbst.
Moderne Rechner arbeiten im ns Bereich, Disk Aktivitäten werden im ms Bereich.abgewickelt.

So, genug ausgek....

Gruß,
Ralf

@Stahly,
ich auch...., trotzdem war es immer der Sche%& Storage.

[Cr4sh]

Hallo,

ja, ich würde mich freuen wenn wir zu dem eigentlichen Thema zurückkommen
Aus den Post konnte ich zwei Fragen herauslesen:

1. Was für IOPS in diesen Momente sind?
Anwort: bei mir sind es immer 100-300 IOPS also relativ gering

2. Anbindung Netzwerk des ISCSI
Das SCSI ist ein einzelner HP Swtich in seiner StandartKonfiguration und völlig alleinstehend.

3. ESXTOP
Im ESXTOP langeweielt sich alles.Nach was soll ich genau schauen?

[kastlr]

Hallo,

laß dir mal die IO Stats von esxtop anzeigen, die CPU Daten sind ja nicht von Interesse.

esxtop starten, danach u drücken und den Intervall mit s auf 2 setzen.

Interessant ist ACTV und die Werte D/K/GAVG/cmd

Gruß,
Ralf

[Cr4sh]

Ziemlich ruhig würde ich sagen:

[kastlr]

Ich auch.....

Na dann gib Ihm doch mal was zu kauen...

[Cr4sh]

Das Problem ist, wenn die Latenzen jetzt schon so sind. Was passiert wenn richtig Last raufkommt? Springen die Latenzen denn in die Höhe?

Gibts irgendwo einen Guide wie etwa "iSCSI Feintuning/Optimierung unter Vsphere" ?

[kastlr]

Das ist bisher doch nur eine Vermutung.
Ohne Tests oder Last wirst du das nie herausfinden.

[Cr4sh]

Ich habe nun einfach mal aus Spaß eine Messung mit IOMETER unter eine VM Maschine durchgeführt. Und habe daür extra als Vorlage zum vergleichen diese von hier genommen:

https://communities.vmware.com/thread/73745

und bei Max Throughput-100%Read habe ich gerade mal 44-50MB/s das find ich schon etwas schwach?

[kastlr]

Hallo,

und hast du dabei mal mit esxtop oder vscsiStats auf dem ESX Server nachgesehen, was er da so macht?

Gruß,
Ralf

[Cr4sh]

Also laut esytop ist langeweile angesagt:



Hier sieht man auch schön die "nur" 50mb/s read



Und was genau soll ich vei vscsi schauen? bin mit dem tool nicht ganz so bewandert.

[kastlr]

Hallo,

also wenn du 1650 IO/sec je 32 KB gegen eine LUN als "Grundrauschen" betrachtest, dann möchte ich nicht wissen, was du als "Vollast" bezeichnen wirst.
Die durchschnittliche Bearbeitungszeit je IO liegt unter 1ms, wie viel schneller soll denn das noch werden?

Reden wir hier wirklich über ein reales Problem oder eher darüber, das Ihr andere Werte erwartet habt?


Gruß,
Ralf

[Cr4sh]

Mich stellt sich die Frage wieso lande ich bei 50mb/s ?

Der theoretische Wert von iSCSI 1Gbit liegt doch bei 250MB/s, das dieser nicht erreicht wird ist klar. Aber nur 50MB/s kommt doch relativ wenig oder? Wenn ich diesen Testwert mit anderen vergleiche, die diese gleiche Einstellung genommen haben?

Und die Screenshots waren ja Volllast mit IOMETER 100% READ.