VMware vSAN wurde vor etwa 10 Jahren entwickelt. Wir schreiben das Jahr 2012. Als Datenspeicher kamen überwiegend magnetische Disks zum Einsatz und Flashmedien wurden praktisch in Gold aufgewogen. In dieser Zeit entstand die Idee hinter vSAN. Hybride Datenspeicher mit drehenden Spindeln für Massendaten und Flashmedien als Cache. Flashdevices verwendeten in dieser Zeit die gleichen Interfaces und Protokolle wie magnetische Disks. Somit konnten sie ihr volles Potenzial nur schlecht entfalten. Es gab immer den Flaschenhals des Interfaces.
Heute – gute 10 Jahre später – haben wir modernere Flashspeicher mit hoher Datendichte und leistungsfähigen Protokollen wie z.B. NVMe. Der Preis pro TB liegt bei Flash inzwischen auf Augenhöhe mit magnetischen SAS-Disks, wodurch magnetische Disks praktisch abgelöst wurden. Hinzu kommen höhere mögliche Bandbreiten im Netzwerk, höhere Core-Dichte in der CPU, sowie ganz neue Anforderungen wie z.B. ML/AI oder Container. Die Zeit ist also reif für eine neue Art der vSAN-Datenspeicherung, die das Potenzial neuer Speichertechnologien voll ausschöpfen kann.
vSAN Express Storage Architecture (ESA)
Um es vorweg zu nehmen: Die vSAN ESA Architektur ist eine optionale Datenspeicherarchitektur. Es wird weiterhin das herkömmliche Diskgruppen-Modell geben – auch unter vSAN 8.
VMware vSAN ESA ist eine flexible Single-Tier Architektur. Das heisst sie kommt ohne Diskgruppen aus und es wird nicht mehr in Cache- und Capacity-Layer unterschieden. Sie ist optimiert auf die Verwendung moderner NVMe Flashspeicher. Alle Storage-Devices eines Hosts werden in einem Storage-Pool zsammengefasst.
Es gibt keinen Upgrade-Pfad vom Diskgruppen Modell zu ESA. Die neue Architektur kann also nur in Greenfield-Bereitstellungen genutzt werden. Die vSAN Knoten müssen ausdrücklich hierfür zertifiziert sein. Es wird spezielle vSAN ReadyNodes für ESA geben.
Was kann vSAN ESA?
- Effizientere Datenspeicherung bei hoher Leistung. Die Verwendung platzsparender Speichermethoden wie Erasure-Coding RAID5/6 geht nicht mehr mit den bisherigen Leistungseinbußen einher. RAID6 mit der Performance von RAID1.
- Snapshots mit weit geringeren Auswirkungen auf die Leistung.
- Adaptives Erasure-Coding. Bei geringerer Anzahl an Knoten kann dennoch eine EC Speicherrichtline verwendet werden. vSAN 8 passt die Anzahl der minimal notwendigen Fault Domains dynamisch an die Anzahl der Knoten an.
Vorrausetzungen
Wie können Anwender das neue vSAN8 ESA einsetzen?
- Zertifizierte Hardware: Es müssen für ESA freigegebene ReadyNodes verwendet werden. Die VMware HCL wird für ESA erweitert, sodass zukünftig auch eigene Hosts zusammengestellt werden können, wenn alle Komponenten für ESA freigegeben sind. Dies werden selbstverständlich weniger sein, als bei der normalen vSAN HCL.
- VMware vSAN ESA erfordert Advanced oder Enterprise Lizenzen.
- VMs müssen auf einen Greenfield-Cluster migriert werden. Es wird keinen Upgrade-Pfad von der herkömmlichen Original Storage Architektur (OSA) auf ESA geben.
- ESA und OSA Cluster können im selben vCenter nebeneinander betrieben werden.
Unter der Haube
Das neue vSAN ESA verwendet im Wesentlichen zwei neue zusätzliche Ebenen im bestehenden vSAN-Storage-Stack.
Log-Structured File System (LFS)
vSAN ESA verwendet ein neues Log-Structured Filesystem (LFS), welches auf die Verarbeitung großer I/O optimiert ist. Die ankommenden Daten können sehr schnell und platzsparend abgelegt werden. Es erlaubt leistungsfähige Snapshots und reduziert Vervielfachung von I/O im Datenpfad.
Mit zunehmender Datenspeichergröße war bisher nicht die Verarbeitung der Daten problematisch, sondern die der Metadaten. Daten und Metadaten werden zunächst in das Durable-Log geschrieben und können sofort ein Write-ACK zurückliefern.
Log-Structured Object Manager
Der neue Log-Structured Object Manager liefert die Daten schnellstmöglich an die Storage-Devices, so dass die native Geschwindikeit des Flashdevices zum limitierenden Faktor wird und nicht der Datenpfad.
Die Kombination der beiden neuen Ebenen ermöglicht eine Single-Tier Architektur, bei der künftig nicht mehr zwischen Cache- und Capacity Device unterschieden werden muss.
Unter LFS gibt es ein sogenanntes Performance-Leg und ein Capacity-Leg. Dies sind jedoch keine unterschiedlichen Flash-Geräteklassen. Alle Devices befinden sich im gleichen Pool. Bei der Verwaltung neuer Devices gibts es einen Storage-Pool Clain und keine Diskgruppen.
Zunächst werden Daten entgegengenommen und im Durable-Log (Performance-Leg) zwischengespeichert. Von dort wandern die Nutzdaten in den Capacity-Bereich, währen die Metadaten im Metadata-Log reorganisiert und sehr effizient gespeichert werden.
Storage Policy und Component-Placement
Obwohl sich auf Filesystem-Ebene sehr viel verändert hat, so hat sich für den Admin nur wenig verändert. Objekte werden weiterhin in Componenten unterteilt und auf verschiedene Hosts verteilt. Neu sind die Komponenten des Performance-Leg, die auch auf mehrere Host verteilt werden. Die Grafik unten zeigt drei unterschiedliche Speicher-Richtlinien und die daraus resultierende Verteilung der Componenten.
Der Capacity-Leg entspricht in weiten Teilen der ursprünglichen Komponentenverteilung in der bisherigen OSA Architektur. Neu sind die Komponenten des Performance-Leg die grundsätzlich als RAID-1 Mirror abgelegt werden. Die Anzahl richtet sich nach den FTT der angewendeten Richtlinie. Performance-Leg Komponenten dürfen sich auf dem selben Host befinden wie die zugehörigen Komponenten des Capacity-Legs.
Höhere Effizienz der Datenprozessierung
Um einen der Vorteile des ESA zur herkömmlichen OSA herauszuarbeiten, sehen wir uns exemplarisch ein VM Objekt mit einer RAID-6 EC Policy an, bei dem zusätzlich Datendienste wie Kompression und Verschlüsselung angewendet werden. Alle diese Datendienste finden auf jedem beteiligtem Host auf Ebene der Diskgruppe statt.
VMware vSAN ESA verschiebt die Bearbeitung dieser Datendienste auf einen einzigen Host am Eingang der Kaskade. Kompression, Verschlüsselung und Checksummenberechnung findet am Host statt, welcher die Daten entgegengenommen hat. Dadurch werden die Daten einmalig verarbeitet und es findet keine Multiplizierung der I/O statt. Die fertig prozessierten Daten werden dann über die geforderte Menge Hosts verteilt.
Adaptives RAID-5
Ein neues, adaptives RAID-5 Erasure-Coding passt sich den Clustergrößen an. Unter normalen Umständen mit 6 oder mehr Hosts wird ein 4+1 Modell mit 125% Speicherbedarf gefahren. D.h. vier Datenkompoenten und einer Parity-Komponenete. Dies erfordert einen Host mehr als RAID-5 in bisherigen vSAN Clustern, die ein 3+1 Modell verwendeten. Bei kleineren Clustern mit 3-5 Hosts passt sich das EC RAID-5 an und fährt ein 2+1 Modell mit 150% Speicherbedarf. In allen Fällen wird versucht, einen Host als Reserve zu halten. Daher wird das 4+1 Modell erst ab 6 Hosts verwendet. Bevor ein 4+1 RAID-5 in ein 2+1 Modell – oder umgekehrt – überführt wird, wartet der Cluster 24 Stunden. Somit wird vermieden, dass Wartungsarbeiten oder Hostausfälle vorzeitig Umlagerungsprozesse auslösen.
Adaptives RAID-5 ermöglicht auch in kleineren Umgebungen die Verwendung einer EC Policy.
Storage Policy-based Compression
Compression ist unter ESA keine Clustereigenschaft mehr, sondern kann Dank des neuen Filesystems pro Objekt über eine Policy eingestellt werden. Es ist unter ESA nicht mehr notwendig, ein Rolling-Reformat des Datastores zu machen, um Kompression zu verwenden.
Kompression ist standardmäßig aktiviert. Der CPU Overhead ist nur gering.
Thema Verschlüsselung
In herkömmlichen vSAN Clustern gab es Data-at-Rest-Encyption und Data-in-Transit-Encyption. Unter ESA gibt es diese Unterscheidung nicht mehr. Ähnlich wie Kompression erfolgt die Verschlüsselung weit oben im Storage-Stack. Dadurch entfallen die bisher mehrfachen Ver- und Entschlüsselungsvorgaänge beim Schreiben auf das Storagedevice.
Intelligentes Traffic Shaping im vSAN Traffic
Resync Traffic im vSAN Netzwerk kann gedrosselt werden, um den operativen VM I/O Traffic nicht zu beeinträchtigen. Die Drosselung kann pro Host angepasst werden.
Neue Snapshot Engine
Die Snapshot Engine wurde komplett überarbeitet und auf Hochleistung optimiert. Die Konsolidierung von Snapshots konnte im Vergleich zu OSA um bis zu Faktor 100 verbessert werden. Unter ESA sind selbst Snapshots von Objekten im “Degraded” State möglich.
Die Integration in VADP Lösungen von Drittanbietern ist nahtlos möglich. Dies bedeutet auch höhere Leistung für SRM und vSphere-Replication.
Das Userinterface zeigt jetzt deutlich den Speicherverbrauch eines Snapshots an.
600 GB Cache Limit
Eine Änderung wird vor allem Nutzer der klassischen OSA Architektur erfreuen. Bisher war die maximal nutzbare Kapazität eines Cache-Devices 600 GB. Alle Bereiche darüber wurden als Wear-Out Reserve verwendet. Mit vSAN 8 ist die Grenze jetzt auf 1,6 TB pro Diskgruppe angehoben worden. Ein größerer Schreibcache bedeutet reduzierte I/O Last auf das Capacity-Tier.
Links
- VMware – Announcing vSAN 8
- VMware Blog – An Introduction to the vSAN Express Storage Architecture