Performane Probleme im Storage mit VPLEX / HP EVA

[pirx]

Hallo,

ich habe hier schon etwas über unsere Probleme geschrieben.

http://vmware-forum.de/viewtopic.php?p=160567#160567

Es gibt folgendes Konstrukt.

- vSphere 5.1 Cluster mit 16 Hosts und ~300 VMs (ein Cl mit 8 Hosts, der andere mit 4)
- 2 TB Datastores
- SIOC war aktiv, wurde jetzt aber deaktiviert
- DiskMaxIOSize wurde vom Default 128KB auf 32KB verkleinert -> kein Unterschied
- IBM Flex System mit x240 Nodes, 2 Chassis verteilt auf 2 RZs. Aktuell ~400m Abstand auf dem gleichen Campus, später ca. 10 Km.
- FC Anbindung an SAN Directoren
- EMC VPLEX als syn. Spiegel, 2 HP EVA HSV360 mit jeweils 150 x 900GB SAS
- fixed path policy, die Pfade wurden mit einen Skript von EMC gesetzt, so dass die Hosts auf einer Seite über die lokalen Controller gehen (Ergebnis wurde überprüft und passt)
- uniform access der Hosts auf die VPLEX distributed vVOLs
- wegen uniform access kein gesonderten DRS / Affinity Regeln, welche die VMs an eine Seite binden (aktuell stehen die beiden Cluster Seiten ja fast nebeneinander)


Wir sehen immer wieder hohe Latenzen, bzw. nicht die IOPS die wir erwarten würden. Teilweise scheint auf dem Storage kaum etwas los zu sein, trotzdem zeigen VMs deutlich schlechtere Performance als VMs in anderen Clustern.

Ein einfacher Test mit bei dem man die Probleme sieht, ist eine W2K8 Installation über das Windows Deployment Toolkit. Dabei werden Daten vom Deployment Server auf die VM kopiert. Dies dauert in allen anderen Clustern ohne VPLEX um die 2 Min. Wenn die VPLEX dazwischen hängt, geht die Zeit für diesen Vorgang auf ~10Min. hoch. Teste ich das gleiche auf LUNs die direkt von den EVAs kommen die der VPLEX als backend storage dienen, sehe ich das Verhalten nicht. Mit unterschiedlichen Iometer Tests kann ich den Unterschied aber nicht reproduzieren.

Die Tests wurden auf LUNs hinter der VPLEX, nur EVA LUNs und P9000 LUNs + VPLEX gemacht. Man sieht natürlich deutlich, dass die P9000 eine ganz andere Liga ist und die Werte der EVA mit oder ohne VPLEX deutlich darunter liegen.



Ich werde versuchen einige Daten mit vscsistats zu sammeln, wobei ich das Tool bisher nicht so gut kenne und mir die Auswertung der Daten noch nicht klar ist. Ich hoffe https://communities.vmware.com/docs/DOC-10095 bringt da etwas Licht rein.

[kastlr]

Hallo,

wie kommen denn die Daten von eurem WDT auf die VM?

Denn wenn ich mir nur die IO Meter Tests ansehe, kann ich keinen Unterschied feststellen.
Die Werte für EVA und VPLEX mit EVA im Backend sind identisch.
Daher sieht es so aus, als ob das Problem nicht wirklich durch den Storage verursacht wird.

Außerdem verwendet Ihr beim Testen immer unterschiedliche LUN's, werden denn alle LUN's auch von ESXi genutzt oder hängen da andere Systeme dran.
Und falls ja, verwenden dann alle eine vergeleichbare Multipath Policy?

Ich kann auch nichts mit dem Begriff uniform access anfangen, das müßtest du mal erläutern.
Es gibt zwei Arten einen Host an einen VPLEX Cluster mit distributed Volumes zu hängen.

1. Host erhält nur Zugrifff auf die VPLEX im selben RZ
2. Host erhält über Cross Site Zoning Zugriff auf beide VPLEX Arrays

Gruß,
Ralf

[bla!zilla]

Uniform: Zugriff auf Storage in beiden RZs.
Non-Uniform: Zugriff auf Storage nur im eigene RZ.

Das ist die Definition seitens VMware für vMSC Configs.

[pirx]

wie kommen denn die Daten von eurem WDT auf die VM?

Über das Netz von einer VM in einem anderen Cluster auf einem anderen Storage. Da sich an der Test VM im Bereich Netzwerk aber zwischen den Tests nicht ändert, schließe ich ein Problem in diese Richtung aus. Selbst wenn ich den Test mache und die VM per svMotion während der Installation auf ein nicht VPLEX DS verschiebe, tritt der Effekt auf.

Denn wenn ich mir nur die IO Meter Tests ansehe, kann ich keinen Unterschied feststellen. Die Werte für EVA und VPLEX mit EVA im Backend sind identisch.
Daher sieht es so aus, als ob das Problem nicht wirklich durch den Storage verursacht wird.

Das ist ja auch mein Problem. In den synthetischen Tests finde ich keinen Unterschied.

Außerdem verwendet Ihr beim Testen immer unterschiedliche LUN's, werden denn alle LUN's auch von ESXi genutzt oder hängen da andere Systeme dran.
Und falls ja, verwenden dann alle eine vergeleichbare Multipath Policy?

Da wir die LUNs hinter der VPLEX nicht so ohne weiteres raus nehmen konnten wurden andere leere LUNs direkt auf der EVA verwendet. Mit der Policy hast du recht, bei den Tests direkt auf der EVA wurde ALUA mit MRU genutzt, ich habe es jetzt auf Fixed umgestellt.

Ich kann auch nichts mit dem Begriff uniform access anfangen, das müßtest du mal erläutern.
Es gibt zwei Arten einen Host an einen VPLEX Cluster mit distributed Volumes zu hängen.

1. Host erhält nur Zugrifff auf die VPLEX im selben RZ
2. Host erhält über Cross Site Zoning Zugriff auf beide VPLEX Arrays

Dann ist es Cross Site Zoning.

http://kb.vmware.com/kb/2007545

[kastlr]

Da sieht man es wieder, Mann lernt nie aus.
Unified Access = Cross Site Zoning

Deiner Antwort entnehme ich, das Ihr beide WDT Tests mit der selben VM gemacht habt, die Ihr dann immer nur auf einen anderen Datastore verschoben habt.

Ich gehe mal davon aus, das die Auslastung der getesteten Datastores vergleichbar ist und nicht einer von einer Vielzahl von VM's und der andere exklusiv von eurer Test VM benutzt wird.

Bei Write IO's kann die VPLEX nur langsamer sein als eine einzelne EVA, denn schließlich muß die VPLEX einen Write IO über den ISL zur VPLEX ins zweite RZ schicken, diese ihn dann an ihr Backend Array senden.
Erst wenn beide BE Arrays das ACK gesendet haben und das auch von der Remote VPLEX zur lokalen VPLEX gesendet wurde, erhält der Host die Bestätigung, das der IO abgeschlossen ist.

Sofern Reads nicht aus dem Cache der lokalen VPLEX bedient werden können sieht es ähnlich aus.
Die lokale VPLEX prüft, ob eventuell eine andere VPLEX den angeforderten Track im Cache hat.
Trifft dies zu, fordert sie diese Information von dieser VPLEX an.
Erst wenn die Info in keiner VPLEX im Cache vorhanden ist wendet sie sich an ihr Backend Array.

Darum ist es auch empfohlen, das eine distributed LUN IO's bevorzugt aus einem RZ erhält.
Geht zwar auch ohne, aber wieder zu Lasten der Performance.

Wie schon mal erwähnt, VPLEX erhöht die Sicherheit und Sicherheit geht immer zu Lasten der Performance.
Nichts wird dadurch schneller das man es zweimal macht.

Was sagen denn die esxtop Daten, einmal von einem IO Meter Test und das andere Mal von deinem Deployment Test?

Gruß,
Ralf

[pirx]

esxtop hat mir bisher nicht weiter geholfen. Was mit bei meinen Tests heute aufgefallen ist....

- Installiere ich eine VM auf eine frische vDisk auf der VPLEX, dann dauert der Vorgang ~12 Min. Wiederhole ich das ganze mit den gleichen vDisks, sinkt die Zeit auf 3-4 Min.

- Installiere ich eine VM auf eine frische vDisk direkt auf der EVA, dann liegt die Zeit bei ~5Min, bei der Wiederholung bei 3-4 Min

Wenn ich also die vDisks auf der VPLEX wiederverwende, erreiche ich fast die gleiche Zeit wie direkt auf der EVA. Es scheint das dort ein Caching Effekt bei der VPLEX deutlich stärker zum tragen kommt. Ob die vDisks thin oder thick sind macht bei meinen Tests keinen Unterschied.

[kastlr]

Hallo,

was stellen die EVA's der VPLEX denn an Storage bereit, Thin oder Thick?
Welche Art gibt denn die VPLEX an die Hosts, Thin oder Thick?

Und verwendet Ihr beim Anlegen der (Thick) vmdks Eagerzeroing?

Gruß,
Ralf

[pirx]

Hallo,

was stellen die EVA's der VPLEX denn an Storage bereit, Thin oder Thick?
Welche Art gibt denn die VPLEX an die Hosts, Thin oder Thick?

Und verwendet Ihr beim Anlegen der (Thick) vmdks Eagerzeroing?

Auf dem Storage wird alles thick bereitgestellt. Die thick VMDKs habe ich lazy zeroed angelegt. Ich kann es nächste Woche mit eager testen. Wobei thin hin oder her, das den Unterschied bei den Tests noch nicht erklärt. Und auch in allen anderen Cluster wo wir thick VMDKs verwenden, wird lazy verwendet.

[kastlr]

Hallo,

das könnte den Unterschied sehr wohl erklären.

Wenn du einen Track schreiben möchtest, der bisher noch nicht in Verwendung war erzeugt VMware zwei IO's.
Einmal Zero Out und danach die Daten.
Und der zweite IO wird erst dann abgesetzt, wenn der erste beantwortet ist.

Beim erneuten Beschreiben eines Tracks fällt dieser Aufwand weg.

Und das würde auch das IO Meter Verhalten erklären.
Bevor IO Meter testet legt es eine Datei an, das ist mit der Info preparing Disk gemeint.
Der eigentliche Test findet daher dann immer in einem bereits einmal beschriebenen Bereich statt, so das der doppelte Aufwand während des eigentlichen Testlaufs entfällt.
Wahrscheinlich dauert das Erstellen der Testdatei bei den Systemen unterschiedlich lang.

Gruß
Ralf

[pirx]

Hallo,

das könnte den Unterschied sehr wohl erklären.

Wenn du einen Track schreiben möchtest, der bisher noch nicht in Verwendung war erzeugt VMware zwei IO's.
Einmal Zero Out und danach die Daten.
Und der zweite IO wird erst dann abgesetzt, wenn der erste beantwortet ist.

Beim erneuten Beschreiben eines Tracks fällt dieser Aufwand weg.

Und das würde auch das IO Meter Verhalten erklären.
Bevor IO Meter testet legt es eine Datei an, das ist mit der Info preparing Disk gemeint.
Der eigentliche Test findet daher dann immer in einem bereits einmal beschriebenen Bereich statt, so das der doppelte Aufwand während des eigentlichen Testlaufs entfällt.
Wahrscheinlich dauert das Erstellen der Testdatei bei den Systemen unterschiedlich lang.

Ich werde die Tests heute noch einmal mit vDisks im eager zero Formt durchführen. Das es bei den Formaten grundsätzlich Unterschiede gibt ist mir schon klar. Ich war aber der Meinung, dass sie sich nicht so extrem auswirken sollten. Hier geht es ja um Faktor 4-5. In den alten Clustern haben wir idR Thick mit lazy zeroed verwendet, an einigen Stellen auch schon thin. Dort gab es mit der HP Lefthand auch schon eine Storage Lösung mit sync. Spiegel, dort ist nie etwas vergleichbares aufgefallen. Auch jetzt liegen die Tests dort mit thin vDisks im gleichen Bereich wie direkt auf einer EVA ohne Netzwerk RAID1 (Installtion in 2 Min.).

Wenn es im Bereich VPLEX + EVA tatsächlich am vDisk Format liegt, dann würde ich immer noch vermuten, dass an irgendeiner Ecke etwas nicht stimmt und es nicht das zu erwartende Verhalten ist.

[kastlr]

Hallo,

du kannst aber einen synchronen Spiegel nicht mit einer Access anywhere Lösung vergleichen.

Ich kann ja verstehen, das euch die initiale Performance nicht gefällt.
Aber scheinbar tritt dieses Verhalten doch nur beim erstem Write auf einen zuvor noch nicht verwendeten Block auf, somit ist das doch nur ein relativ kurzfristiges Problem.
Und verantwortlich dafür ist noch nicht einmal der Storage, sondern VMware.

Gruß,
Ralf

[pirx]

Hallo,

du kannst aber einen synchronen Spiegel nicht mit einer Access anywhere Lösung vergleichen.

Was meinst du mit Access anywhere Lösung? Bei uns läuft die Lefthand auch als sync. Spiegel. Mit der nicht ganz optimalen MPIO Unterstützung für VMware von HP, ist die Lösung ja auch nicht ganz problemfrei. Die Probleme mit den vDisk Formaten hatten wir dort aber gar nicht.

Ich kann ja verstehen, das euch die initiale Performance nicht gefällt.
Aber scheinbar tritt dieses Verhalten doch nur beim erstem Write auf einen zuvor noch nicht verwendeten Block auf, somit ist das doch nur ein relativ kurzfristiges Problem.
Und verantwortlich dafür ist noch nicht einmal der Storage, sondern VMware.

Ich habe jetzt auf der VPLEX den Test mit eager zeroed vDisks gemacht, tatsächlich ist damit die Installation schon im ersten Durchgang im gleichen Bereich wie auf den anderen Storages. Die Frage ist nun, muss/soll das so sein, oder ist das eine Auswirkung eines Fehlers/Misskonfiguration an anderer Stelle. Ich finde den Faktor 4-5 im Vergleich zu vDisks auf der Lefthand im thin Format extrem.

Edit: die Latenzen der VM auf dem Datastore liegen bei der Installation im thin oder lazy Format bei ~50ms. Auch das finde ich zu hoch.

[kastlr]

Hallo,

wenn du auf der VPLEX ein distributed Volume bereitstellst, kannst du in jedem Rechenzentrum auf das Volumes zugreifen.

Von einem synchronem Spiegel spricht man, wenn die Daten eines (primären) Volumes synchron auf ein zweites (sekundäres) Volume geschrieben werden.
Der Zugriff eines Hosts auf dieses sekundäre Volume erfordert üblicherweise weitere Maßnahmen.

Wie gesagt, beim Einsatz von thin oder lazy zerod vmdks (nicht vDisks) verfährt VMware wie hier beschrieben.
About Virtual Disk Provisioning Policies

Dieses Verhalten kann durch den Storage nicht beeinflußt werden!

Ich gehe davon aus, das die hohen Latenzen beim Anlegen der VM dadurch verursacht werden, das dort eigentlich zwei IO's ausgeführt werden.
Und die haben eine Besonderheit, denn der zweite IO wird erst dann auf die Reise geschickt, wenn der erste erfolgreich abgeschlossen worden ist.

Vermutlich habt Ihr das Problem mit den Latenzen nicht, wenn Ihr die VM in einer mit eagerzeroed thick angelegten vmdk installiert.
Damit wäre dann auch der Nachweis erbracht, das thin und lazy-zeroed die eigentlichen Verursacher eures Problems sind.

An Hand der vorliegenden Informationen kann ich nichts zu einem möglichen Fehler oder einer Misskonfiguration sagen.

Gruß,
Ralf

[pirx]

Hallo Ralf,

das ist mir alles klar. Aber mit der Lefthand haben wir bereits ein Storage das genau das bei uns auch seit 3 Jahren macht, Storage über ein RAID1 über das Netzwerk in 2 RZs bereitstellen. Und dort sehe ich mit thin oder lazy zeroed vDisks absolut keinen Unterschied zu eager zeroed vDisks.

Es ist klar, dass das Verhalten auf der VPLEX durch thin/lazy verstärkt wird. Aber ich glaube immer noch nicht, dass es die tatsächliche Ursache ist. Wenn die Kombination VPLEX/EVA beim Schreiben Problem hat, dann werden die natürlich durch sowas noch verstärkt.

Die Frage ist, was die eigentliche Ursache ist.

[kastlr]

Hallo,

laß uns doch einfach mal die Fakten aufzählen

1. 10 Minuten für das initiale Deployment einer Windows VM bei Verwendung von thin oder lazy-zeroed vmdks.
2. 3-4 Minuten für das initiale Deployment einer Windows VM bei Verwendung von eagerzeroed vmdks
3. jedes erneute Deployment in einer bereits initial Installierten VM erfolgt in 3-4 Minuten
4. IO Meter Tests mit diesen VM's zeigen keinerlei Auffälligkeiten, unabhängig vom verwendeten Datastore (VPLEX = EVA)
5. Das Verhalten selber zeigt keinerlei Veränderung, unabhängig vom verwendetem Datastore (VPLEX oder EVA)

Somit stellt sich die Frage, was genau Ihr eigentlich erwartet?

Wenn die EVA dieses Verhalten schon ohne VPLEX zeigt, wieso sollte sich das Verhalten mit der VPLEX ändern, da diese doch Ihren BackEnd Storage von der EVA erhält?

Ob eure Lefthand das nun anders macht kann ich nicht beurteilen, da ich das Array nicht kenne.
Ich würde jedoch eher vermuten, das die Lefthand einen Write IO, der nur Nullen enthält gar nicht wirklich auf die Platte packt.
Sondern dem Host bei Eintreffen des IO's im Cache gleich mitteilt, habe ich geschrieben.
Das wäre dann natürlich schneller als ein realer Write und würde auch erklären, warum Ihr kaum Unterschiede zwischen Thin, lazy und eager-zeroed vmdks seht.

Aktuell kann ich aktuell keinen Storage Fehler erkennen, meiner Meinung nach ist das works as designed

Gruß,
Ralf

[irix]

..
Ich würde jedoch eher vermuten, das die Lefthand einen Write IO, der nur Nullen enthält gar nicht wirklich auf die Platte packt.

Die Frage welche der VAAI Primitives von VPLEX supportet werden, ob sie aktiv sind und ob "WRITE SAME" das ist was LazyZero ist. Da ich mir die Namen nicht merken kann merke ich mir nur immer das ein Storage garnicht alle supporten muss um das Label "VAAI Support" zubekommen. Ich meine das VPLEX WRITE SAME und ATS supportet.

Gruss
Joerg

[pirx]

1. 10 Minuten für das initiale Deployment einer Windows VM bei Verwendung von thin oder lazy-zeroed vmdks.
2. 3-4 Minuten für das initiale Deployment einer Windows VM bei Verwendung von eagerzeroed vmdks
3. jedes erneute Deployment in einer bereits initial Installierten VM erfolgt in 3-4 Minuten
4. IO Meter Tests mit diesen VM's zeigen keinerlei Auffälligkeiten, unabhängig vom verwendeten Datastore (VPLEX = EVA)
5. Das Verhalten selber zeigt keinerlei Veränderung, unabhängig vom verwendetem Datastore (VPLEX oder EVA)

zu 5.: bei dem Test letzte Woche, habe ich nur beim Test über die VPLEX eine deutliche Änderung im Verhalten von der ersten zur zweiten Installation gesehen. Auf einem EVA Datastore lief die Installation unabhängig davon vergleichbar schnell ab.

- Installiere ich eine VM auf eine frische vDisk auf der VPLEX, dann dauert der Vorgang ~12 Min. Wiederhole ich das ganze mit den gleichen vDisks, sinkt die Zeit auf 3-4 Min.
- Installiere ich eine VM auf eine frische vDisk direkt auf der EVA, dann liegt die Zeit bei ~5Min, bei der Wiederholung bei 3-4 Min

Ich werde das aber auch noch mal testen, aktuell ist aber etwas mehr Last auf dem Storage, daher dauert das noch etwas.

Ich hatte dich so verstanden, dass du meinst das Verhalten kommt durch den sync. Spiegel über die VPLEX. Im speziellen bei thin/lazy vDisks.

Das gleiche Verhalten sehe ich aber auch bei nicht gespiegelten (lokalen) VPLEX Volumes, ich habe es gerade getestet. Auch dort benötigt die initiale Installation > 10 Min. D.h. den sync. Spiegel kann man als Ursache ausschließen.

Bleibt aber immer noch die VPLEX selber oder die EVAs. Oder das Zusammenspiel von beiden.

[pirx]

..
Ich würde jedoch eher vermuten, das die Lefthand einen Write IO, der nur Nullen enthält gar nicht wirklich auf die Platte packt.

Die Frage welche der VAAI Primitives von VPLEX supportet werden, ob sie aktiv sind und ob "WRITE SAME" das ist was LazyZero ist. Da ich mir die Namen nicht merken kann merke ich mir nur immer das ein Storage garnicht alle supporten muss um das Label "VAAI Support" zubekommen. Ich meine das VPLEX WRITE SAME und ATS supportet.

Die VPLEX beherrscht ATS und Zero.

VAAI Plugin Name:
ATS Status: supported
Clone Status: unsupported
Zero Status: supported
Delete Status: unsupported

[pirx]

Ich habe die eager/thin Tests noch einmal auf unterschiedlichen Clustern/Storages wiederholt.

- HP Lefthand: kein Unterschied
- HP XP P9000: kein Unterschied
- HP EVA: dort sehe ich einen Unterschied, dabei spielt die VPLEX keine wesentliche Rolle

-> Ergo: die EVA ist in dieser Konstellation der Engpass, dabei spielt der sync. Spiegel keine wesentliche Rolle mehr.

Etwas blöd ist, dass der Iometer Test auf den ersten Blick keinen Unterschied gezeigt hat. Gibt es eine Option das Erzeugen der Testdatei vor dem Test zu unterbinden?

[kastlr]

Hallo,

du könntest folgendes in deiner Windows VM versuchen.

cmd als Administrator starten
fsutil file createnew <LW>:\iobw.tst <Size in Bytes>

Damit legst du die von IOMeter benötigte Testdatei als Sparse File an.

Gruß,
Ralf