Lazy-Zeroed vs. Eager-Zeroed

[wannabee]

Guten Morgen zusammen,

aktuelle werden bei uns (vSphere 5.5 Umgebung) alle VMs (Server) mit "Thick-Provision Lazy-Zeroed" Festplatten betrieben.
Würde mir "Eager-Zeroed" einen großen Performance-Vorteil beim Betrieb der VMs bieten?

Wie macht ihr es in euren Umgebungen? Eager oder Lazy und warum?

Danke euch.

[irix]

Bei "Eager" ist halt der vorallokierte Bereich auch schon genullt und somit hat man dort einmalig einen kleinen Performancevorteil. Aber den hat man nur beim ersten Write.

"Eager" wird zwingend vorrausgesetztz bei FT VMs.

Wenn du kein Storage hast welches VAAI und dort die Primitive Zeroing supportet wuerde ich Eager nicht machen wollen ausser du bekommst dein Geld dafuer auf Fortschrittsbalks zugucken.

Wir machen Thin vDISKs. Haben aber ein Monitoring und vSphere StorageCluster im Einsatz. Ist dies nicht gegeben dann Lazy.

Gruss
Joerg

[wannabee]

Leider steht mir kein VAAI (vsphere Stanard Lizenz) nicht zur Verfügung. Danke dir

[irix]

Leider steht mir kein VAAI (vsphere Stanard Lizenz) nicht zur Verfügung. Danke dir

Was aber kein techn. Hinderungsgrund waere.

Wie lange dauert es denn wenn du eine 100GB Eager vDisk erstellst? Werden andere VMs beeintraechtigt in der Zeit weil Hypervisor/Storage nun belastet ist?

Wir haben hier doch gerade einen parallel Thread laufen wo es um die konvertierung bzw. verhalten bei Vergroesserung einer vDisk geht. Das solltest du auch mal mitlesen.

Gruss
Joerg

[kastlr]

Hallo Jörg,

warum sollte VAAI so sehr von Bedeutung sein, außer das einmal das Array (mit VAAI) und einmal der Host (ohne VAAI) für das Löschen der Bereiche zuständig ist?

Das einzige was sich durch VAAI wirklich ändert ist die IO Last, die der Host erzeugt.
Damit wird aber primär nur der Host und das SAN entlastet, in den meisten Fallen aber nicht das Array.

Bei einer svMotion Operation (VAAI extended copy) von 500 GB muß das Array in jedem Fall 1 TB an Daten verarbeiten, je 500 GB Read (Source) und 500 GB Writes (Target).
Bei VAAI zero block löschen manche Arrays die Bereiche auch nicht wirklich, sie setzen nur spezielle interne Flags.
Das entlastet zwar den Host und das SAN, aber wie oft werden denn solche Operationen im Regelbetrieb durchgeführt?

Space reclaimation erfordert in den meisten Fallen immer noch eine Aktivität des Administrators.

VAAI ist eigentlich eine ziemliche Mogelpackung, wenn es denn ATS nicht gäbe.

Gruß,
Ralf

[roeschu]

..
VAAI ist eigentlich eine ziemliche Mogelpackung, wenn es denn ATS nicht gäbe.

Bezüglich Space Reclaim im SAN Umfeld weiss ich nicht bezüglich Mogelpackung; aber im NFS Umfeld mit Netapp ist VAAI schon ziemlich was schönes.

Unter Netapp CDOT 8.3 greift VAAI mittlerweile nicht nur beim Klonen sondern auch beim Restore. D.h früher mit Netapp VSC restores von 20 - 60 Minuten je nach Grösse, heute unabhängig von der Grösse 2-3 Minuten VM Restorezeit.

[bla!zilla]

Und warum geht es schneller? Weil der Filer es macht. VAAI verlagert nur die Last vom Host auf das Speichersystem. VAAI ist schön, keine Frage. Aber die Last löst sich ja nicht in Luft auf.

[wannabee]

Der Zugriff von den Hosts auf das SAN läuft über iSCSI 10G

Ich frage mich nur: Ist es Wert beim Erstellen eines neuen Servers etwas länger zu warten, dann aber später etwas mehr Performance zu haben.

Und die zweite Frage: Wenn ein Mitarbeiter (auch Admin) meint dass die Systeme "gefühlt" ab und an etwas träge wären, kann es wirklich an "Lazy" oder "Eager" Zeroed liegen?

Grüße

[kastlr]

Die Auswirkungen auf die Performance sind marginal und können wahrscheinlich nur unter Testbedingungen festgestellt werden.

Nach meinem Kenntnisstand haben ausschließlich folgende Aktivitäten Auswirkungen auf die Performance beim Einsatz von non eager-zeroed vmdks.

• Erstmaliges Beschreiben eines Tracks
• Wachsen der vmdk (Allokieren von freier Kapazität im VMFS Filesystem, Aktualisierung Meta Daten usw.)

Somit sollten z. B. DB Logs sinnvollerweise auf eager-zeroed Thick vmdks liegen.

Gruß,
Ralf

[roeschu]

Und warum geht es schneller? Weil der Filer es macht. VAAI verlagert nur die Last vom Host auf das Speichersystem. VAAI ist schön, keine Frage. Aber die Last löst sich ja nicht in Luft auf.

Klar löst sich die Last nicht in Luft auf; wird aber massivst reduziert; durch den Einsatz neuer Features.

Ist ja lasttechnisch durchaus ein Unterschied ob z.b ein Netapp Filer via Flex Cloning eine 1Tb Disk restored, allein mit Operationen auf dem Storage; oder ob die zu restorende 1Tb VM vom Storage übers Netz zum ESX CPU und wieder zurückkopiert wird...

Die Last reduziert sich einerseits durch VAAI (bei diesem Beispiel) massiv (FlexCloning auf dem Netapp kostet lasttechnisch nicht allzuviel..) andereseits reduzieren sich die an der Operationen beteiligten und somit belasteten Komponenten von 3 auf 1 (Netz/ESX CPU/Storage vs Storage).

Im vorliegenden Beispiel könnte man durchaus sagen das die Last sich (fast) aufgelöst hat ....60Minuten restorezeit gegenüber 2 Minutenrestorezeit inklusive einer Minderbelastung der beteiligten Komponenten bei der entsprechenden Operation könnte man fast als "Lastauflösung" bezeichnen Selbst der Filer welche am Schluss beim VAAI die Operation/Last ausführt hat weniger Last als wenn er 1Tb zur ESX CPU hin und her schaufeln muss.

[PeterDA]

Hi,
bezüglich der Ausgangsfrage Lazy-Zeroed oder Eager-Zeroed kann ich mich noch an eine Aussage von Ulli vor ein par Jahren erinnern, dass man mit Eager-Zeroed eine höhere Wahrscheinlichkeit hat im Crash Daten aus einer VMDK wiederherzustellen.

Gruß Peter

[continuum]

Die Aussage stimmt auch weiterhin:

im Recoveryfall sind die Chancen bei eagerzeroed thick Provisionierung am besten.

Bei den anderen Thick-formaten wird die Recovery erschwert durch Reste von früheren Datenständen die zwar vom Gast aus gesehen leer sein sollten aber nicht wirklich genullt wurden.