VMware-Forum

Umgebung:
12 Konten (noch VS5.01, in kürze VS6)
250Windows VM´s
80TB Sore (1Pool über IBM SVC mit Tiering)

Wir haben oben beschriebene Umgebung und fragen uns, was die beste Konfiguration des Stores für uns ist. Aus Verwaltungssicht wäre es für uns das einfachste, aus dem SVC einen Laufwerk an VM-Ware zu übergeben und darin alle VMs zu speichern. Man hat uns davon abgeraten, da man damit nur eine Queue erzeugt über die dann alle IOs laufen müssen. Also haben wir alle großen Laufwerke einzeln im SVC angelegt und je an VMWare übergeben. Geht das mit VS6 eleganter? Wo schaltet man Thin provisionierung ein? Im SVC, in VM-Ware? Gibt es die Möglichkeit in Windows gelöschte Speicherbereiche im SVC über die Thin provisionierung wieder freizugeben?

MfG Balsfulland

Mit vSphere 6 kommen vVols.
Ich hab irgendwo gelesen das die SVC es können soll, ob es aber direkt zum Start von vSphere 6 funktioniert kann ich nicht sagen.

Wie gut vVols wirklich funktioniert, kann dir aktuell vermutlich nur irgendein Beta Tester beantworten.

>Gibt es die Möglichkeit in Windows gelöschte Speicherbereiche im SVC über die Thin
>provisionierung wieder freizugeben?

Afaik: Wenn du den freien Platz wieder mit 0en überschreibst und dann den ganzen Datenträger auf einen neuen Datenträger migrierst, wird es wieder frei. (vorausgesetzt der neue hat Thin Provisioning aktiv)

Was meinst Du mir "ein Laufwerk an Vmware übergeben"? Ein einzige LUN?

Also mit einer HP 3PAR hätte ich da keine Bedenken. Das war VMwares Referenzsystem für die Entwicklung von vVOLs. Die 3PAR kann es von Beginn an, sobald vSphere 6 GA ist.

Unterstützung für VVOLs für den SVC kommt erst noch. Wie haben gerade auch auf den SVC + V7000 migriert und sind in Absprache mit IBM bei 4 TB Datastores gelandet. Wie sich das von der Performance bewährt, muss sich noch zeigen. Außerdem haben wir Kompression für die VMware LUNs aktiviert... ich bin gespannt....

pirx hat geschrieben:...Außerdem haben wir Kompression für die VMware LUNs aktiviert... ich bin gespannt....

Da würde ich mich über einen Erfahrungsbericht freuen
Vor allem, was die Performance angeht. Welche Knoten habt ihr im Einsatz?

Zur LUN-Größe:
Wir haben zur Zeit fast nur 2 TB LUNs im Einsatz. Manche sind 4 oder 8 TB groß... - ist aber eher die Ausnahme.

pirx hat geschrieben:Unterstützung für VVOLs für den SVC kommt erst noch. Wie haben gerade auch auf den SVC + V7000 migriert und sind in Absprache mit IBM bei 4 TB Datastores gelandet. Wie sich das von der Performance bewährt, muss sich noch zeigen. Außerdem haben wir Kompression für die VMware LUNs aktiviert... ich bin gespannt....

Das Ergebnis würde mich auch mal interessieren. Wir haben auch SVC mit V3700 im Einsatz, aber ohne Kompression.

stahly hat geschrieben:

pirx hat geschrieben:...Außerdem haben wir Kompression für die VMware LUNs aktiviert... ich bin gespannt....

Da würde ich mich über einen Erfahrungsbericht freuen
Vor allem, was die Performance angeht. Welche Knoten habt ihr im Einsatz?

Zur LUN-Größe:
Wir haben zur Zeit fast nur 2 TB LUNs im Einsatz. Manche sind 4 oder 8 TB groß... - ist aber eher die Ausnahme.

Was die Performance angeht, habe ich noch kein wirkliches Ergebnis. Wir nutzen für den stretch cluster tiering pools mit 2x 40 TB SSDs und dahinter SATA Disks auf jeder Seite. Die Durchschnittlichen Latenzen sind ok, es gibt für meinen Geschmack aber zu viele Ausreißer nach oben.

http://i.imgur.com/Cp1tykl.png

Die Einsparungen durch Kompression liegen zwischen 30 und 50%.

stahly hat geschrieben:Was meinst Du mir "ein Laufwerk an Vmware übergeben"? Ein einzige LUN?

Ich meine, daß ich am liebsten in VM-Ware einen großen ungeteilten Pool hätte. Da könnte ich dann alle Virtuellen Festplatte der VMs speichern und somit den Platz einfach Managen...

MfG Balsfulland

Hallo zusammen,

um was für VM's handelt es sich denn, Server oder Client Systeme?

Prinzipiell ändert eine Virtualisierung nichts an dem IO Aufkommen, somit kannst du dir die Frage auch so stellen.
Würdest du dir eine Umgebung aufbauen, in der sich 250 physikalische Hosts Systeme eine einzelne Platte teilen?

In der Standardeinstellung verwendet ESXi 5/6.x eine Queue Depth von 64 (QLogic) bzw. 30 (Emulex).
Changing the queue depth for QLogic, Emulex, and Brocade HBAs.
Der Einsatz von vVOLs dürfte daran nichts ändern.

Das theoretische Maximum für gleichzeitig zu bearbeitende IO's einer Umgebung errechnet sich wie folgt.

Anzahl Hosts * Anzahl Pfade * HBA Queue Depth * Anzahl LUN's

Bei 4 Pfaden pro Host mit QLogic HBA's würde sich das theoretische Maximum wie folgt berechnen.
12 * 4 * 64 * 1 = 3072 gleichzeitige IO's

Pro VM stehen dann gerade einmal 3072 / 250 = 13 IO's zur Verfügung.

Jedoch greifen hier eine Vielzahl von Abhängigkeiten ein, die dieses theoretische Maximum weiter reduzieren und somit solch ein Design im Prinzip eigentlich verbieten.

1. Laut VMware HCL handelt es sich bei der SVC um ein ALUA Array, somit kann bei Verwendung nur einer LUN auch nur 50% der im Array verfügbaren Compute Power genutzt werden.
   Schließlich verwendet VMware bei Einsatz eines ALUA Arrays je LUN immer nur einen Controller, der zweite Controller wird nicht aktiv verwendet.
   Dadurch halbiert sich natürlich auch die Anzahl der verwendeten Pfade, denn die anderen 50% transportieren ja keine IO's.
   
   Damit stehen euren VM's gerade noch 6 IO's zur Verfügung.
   
2. Sollten die Antwortzeiten der einen LUN mal über einen gewissen Zeitraum über dem Schwellwert von SIOC liegen, greift VMware ein und passt die Queue Depth dynamisch an.
   Storage I/O Control
   
   Bei einem Design mit nur einer LUN stehen allen VM's in so einem Fall dann noch weniger IO's zur Verfügung, und alle VM's wären von diesem IO Throtteling betroffen.
   
3. Euer Backup Konzept hast du zwar nicht erwähnt, aber mit nur einer LUN dürften Backup Aktivitäten immer Auswirkungen auf alle VM's haben.
   Denn wenn Ihr z. B. mit Snapshot basierten Verfahren arbeitet, erhöht die regelmäßige Konsolidierung (nach Abschluß des Backups) die Last auf der LUN.
   Schließlich müssen die während des Backups aufgelaufenden Änderungen in die ursprüngliche vmdk geschrieben werden, während die VM ganz normal arbeitet und somit ebenfalls eine IO Last erzeugt.
   Darüber hinaus werden auch IO's erforderlich, welche das VMFS Filesystem betreffen, diese stehen dann ebenfalls den VM's nicht mehr zur Verfügung.
   
   Damit reduziert sich verfügbare IO Anzahl weiterhin.
   
4. Signatur Updates von Virenscannern oder das Ausrollen von Patchen für ein virtualisiertes Betriebssystem erhöht immer die normale Last, in eurem Fall mit nur einer LUN könnten alle VM's die Auswirkungen zu spüren bekommen.
   
5. to be continued

Alles in allem kann ich von diesem Design nur abraten, ich würde das sogar als grob fahrlässig betrachten.

Der Aufwand um z. B. 20 Datastores zu verwalten ist überschaubar und steht in keinem Verhältnis zu den Problemen, die ihr euch mit einer einzigen LUN für alle VM's ins Haus holen würdet.

Gruß,
Ralf

Vielen Dank für die sehr ausführliche und genau mein Problem treffende Antwort.
Wir betreiben fast ausschließlich Server auf der Farm. Die enthalten alle Windows relevanten Systeme wie AD, DNS, DHCP, Exchange, Fileserver, SQL Datenbanken...

Ich hatte gehofft, das VM-Ware in der Lage ist pro LUN mehrere Queues zu betreiben. Im Idealfall pro virtuellem Laufwerk eine. Wenn das nicht der Fall ist, bleiben wir bei unserem Konzept. Kleine VMs kommen in einen Storage-Cluster mit 4TB LUNs und große werden im SVC einzeln angelegt.

Wie steht ihr zu Thinprovisionierung? Sollte man das in VM-Ware oder besser im SVC einschalten?

Balsfulland

Hallo,

VMware ist nicht nur in der Lage, für jede einzelne vmdk eine Queue bereit zu stellen, sondern setzt dies in der Standardeinstellung bereits ein.

Doch das wird euch alles nichts nützen, wenn der SCSI Layer nicht mehr Slots bereitstellt.
Natürlich könntet ihr die Anzahl der Queue Slots erhöhen und damit zeitgleich mehr IO's zum Array senden, aber die würden immer noch nur bei einem SVC Controller auflaufen.

In Verbindung mit IBM SVC verwendet VMware zwar die Multipath Policy RoundRobin, aber selbst da erfolgt ein Pfadwechsel bei Nutzung der Standardeinstellung erst nach 1000 IO's.
Soll heißen, von euren 4 Pfaden wird pro Host eigentlich immer nur einer aktiv verwendet, ein Wechsel auf den zweiten verfügbaren Pfad zum selben Controller der SVC erfolgt nach 1000 abgestzten IO's.

Man könnte natürlich auch die VMware NMP RR umkonfigurieren, so das ein Pfadwechsel nach jedem IO erfolgt, ob IBM das jedoch supported oder empfiehlt entzieht sich meiner Kenntnis.

Auch bietet VMware für ESXi 5.x (zu 6.0 kann ich aktuell noch nichts sagen) keinerlei Tool zur Behebung von Problemen mit VMFS Datastores an.
Es gibt zwar das VOMA Tool, doch damit kannst du ein Problem nicht beheben.
Darüber hinaus kann es auch nur dann eingesetzt werden, wenn zuvor alle VM's auf dem zu testenden VMFS Datastore heruntergefahren sind.

Zum Thema Thin Provision:
Thin (VMware) on Thin (Array) funktioniert einwandfrei, erhöht jedoch den administrativen Aufwand etwas und kann auch Auswirkungen auf die Performance haben.

Beim ersten Punkt müssen die VMware UND die Storage Admins dafür Sorge tragen, das immer ausreichend freie Disk Kapazität verfügbar ist bzw. nicht mehr verwendete Kapazität wieder nutzbar gemacht wird.
Wenn ich die VMware HCL jedoch richtig interpretiere, unterstützt die SVC gar kein VAAI UNMAP, somit dürfte dieses Thema nicht ganz so trivial umzusetzen sein.
Vielleicht solltet Ihr das mal mit IBM diskutieren.

Auswirkungen auf die Performance hat der Umstand, das VMware beim ersten Schreiben auf einen zuvor noch nicht verwendeten Sektor diesen zuerst mit Nullen überschreibt.
Erst im Anschluß daran wird der eigentliche Write durchgeführt.
Somit hat das Array anstelle eines IO's zwei sequentielle IO's zu verarbeiten.

Getreu dem Motto, nichts wird schneller wenn man es zweimal macht.

Ich denke, Ihr solltet euer Konzept noch einmal überprüfen.

Gruß,
Ralf