VCF9 – vSAN: Architektur, Policies und Hochverfügbarkeit

In diesem Beitrag der VCF 9 Serie geht es um vSAN, die Storage-Schicht der VMware-Infrastruktur.

Die größere Architekturveränderung bei vSAN lag allerdings nicht in der neuen Version selbst, sondern bereits in vSAN 8 (mit vSphere 8.0 im Jahr 2022), nämlich beim Wechsel von der Original Storage Architecture (OSA) zur Express Storage Architecture (ESA).

In VCF 9.0 wurde ESA zur Standardarchitektur. In VCF 9.1 kamen mehrere Erweiterungen hinzu: Auto-RAID-6 wurde zur Standardeinstellung, es gibt eine globale Deduplikation mit Verschlüsselung und vSAN Storage Clusters lässt sich über vCenter-Grenzen hinweg erweitern. Außerdem gibt es einen Site Maintenance Mode für Stretched Cluster.

ESA – Express Storage Architecture

Die OSA (Original Storage Architecture) war die einzige Speicherarchitektur von vSAN, bis mit vSAN 8 die ESA (Express Storage Architecture) eingeführt wurde. Der Aufbau war zweistufig: Jeder ESXi-Host hatte eine oder mehrere Disk Groups und jede Disk Group bestand aus einem Cache-Tier (eine SSD) und einem Capacity-Tier (bis zu sieben Capacity-Devices). Schreibvorgänge gingen zuerst in den Cache und wurden anschließend asynchron in das Capacity-Tier destagiert.

Das Modell war damals durch die hohen Kosten für die SSD gerechtfertigt. Die Hybrid-Welt aus SSD-Cache und HDD-Capacity war in vielen Bereichen State of the Art. Der größte Nachteil war, dass bei Ausfall des Cache-Devices einer Disk Group die gesamte Disk Group offline war. Da Kompression und Deduplikation auf Disk-Group-Ebene arbeiteten, waren die Effizienzgewinne begrenzt.

ESA hat dieses zweistufige Modell aufgelöst. Anstelle von Disk Groups gibt es nun einen flachen Storage Pool, in dem alle NVMe-Geräte eines Hosts gleichberechtigt zusammenarbeiten. Das Konzept separater Cache-Laufwerke entfällt vollständig, sodass alle Geräte direkt für die Datenkapazität genutzt werden.

Die Schreibvorgänge sind log-strukturiert (Log-File-System, LFS), wodurch eine deutlich höhere Konsistenz unter Last erreicht wird. Die Kompression arbeitet pro Objekt statt pro Disk-Group, was die Effizienz spürbar verbessert. Voraussetzung für ESA ist allerdings eine reine All-Flash-Infrastruktur (basierend auf modernen NVMe-Geräten), da Hybrid-Konfigurationen mit HDDs nicht unterstützt werden.

In VCF 9.0 ist die ESA die empfohlene Standardarchitektur für neue Workload-Domains und wird auch vom VCF-Installer automatisch gesetzt. OSA wird in VCF 9 zwar weiterhin unterstützt, gilt aber als Auslaufmodell für bestehende Umgebungen. In VCF 9.1 verschiebt sich der Schwerpunkt weiter in Richtung ESA: Die Auto-RAID-6-Logik wählt RAID 6 als Default-RAID-Level für vSAN-Cluster, um optimale Kapazität bei maximaler Ausfallsicherheit zu bieten. Die neue Global Deduplication auf Cluster-Ebene ist nur in ESA verfügbar. Die Deduplikation arbeitet so, dass sie auch bei aktiver Data-at-Rest-Verschlüsselung wirksam bleibt.

Merkmal	Original Storage Architecture	Express Storage Architecture
Hardware	HDDs + SATA/SAS SSDs	Nur NVMe (Nonvolatile Memory Express)
Architektur-Struktur	Two-Tier (Dedizierter Cache + Kapazität)	Single-Tier (Einheitlicher Storage Pool)
Logische Organisation	Festplattengruppen (Disk Groups)	Keine Disk Groups mehr
Netzwerk-Empfehlung	10 Gigabit Ethernet (GbE)	ab 25 Gigabit Ethernet (GbE)
RAID 5/6 Effizienz	Höhere CPU-Last, Performance-Einbußen	RAID 5/6 erreicht RAID-1-Performance dank LFS

Policy-based Storage Management

Die vSAN-Konfiguration erfolgt grundlegend über Richtlinien. Eine Storage Policy beschreibt nicht das Storage-Objekt selbst, sondern dessen Anforderungen in Bezug auf Verfügbarkeit, Performance und Effizienz. vSAN platziert die VM-Objekte anschließend vollautomatisch so, dass diese Anforderungen erfüllt werden. Dieses bewährte Bedienmodell bleibt auch in VCF 9 unverändert.

Die wichtigste Eigenschaft einer vSAN-Policy ist die Ausfalltoleranz-Methode (FTT – Failures to Tolerate). Sie legt fest, wie viele Host-Ausfälle eine VM gleichzeitig überleben kann, ohne dass es zu Datenverlust kommt.

Bei FTT = 1 und RAID-1 Mirroring speichert vSAN zwei vollständige Datenkopien sowie einen Witness.

Bei FTT = 2 mit RAID-1 werden drei identische Datenkopien und zwei Witnesses benötigt. Der Speicherbedarf verdoppelt sich bei FTT=1 oder verdreifacht sich bei FTT=2.

Um diesen massiven Speicher-Overhead zu reduzieren, nutzt vSAN die Technologie des Erasure Codings. Statt Daten stumpf zu spiegeln, werden die Daten in Segmente zerlegt und mit mathematischen Prüfsummen (Paritätsbits) versehen. Fällt ein Host aus, lassen sich die fehlenden Daten aus den verbleibenden Informationen und den Prüfsummen live rekonstruieren.

RAID 5 (FTT = 1): Die Daten werden über die Hosts verteilt und mithilfe einer Parität geschützt. Der Kapazitätsbedarf verändert sich drastisch: Anstatt des zweifachen Platzes (RAID 1) wird nur noch das 1,33-fache der eigentlichen Datenmenge benötigt.

RAID 6 (bei FTT = 2): Die Daten werden mit doppelter Parität geschützt und statt des 3-fachen Platzes wird nur das 1,5-fache benötigt

Die Admins müssen diese Entscheidung nicht mehr manuell treffen. Dadurch wird das Risiko minimiert, dass produktive Cluster unbemerkt im teuren RAID-1-Modus laufen und wertvolle All-Flash-Kapazitäten verschwenden.

Stretched Cluster — Site-Hochverfügbarkeit

Während FTT für die Ausfallsicherheit innerhalb eines Clusters sorgt, ist der Stretched Cluster die vSAN-Lösung für den Fall, dass ein komplettes Rechenzentrum (eine Site) ausfallen würde.

Das Modell hat sich konzeptionell seit Jahren nicht verändert: Es gibt zwei aktive Datensites mit jeweils einem Teil der ESXi-Hosts sowie eine dritte Lokation mit einer Witness-Appliance. Die beiden Datensites halten jeweils eine vollständige, synchron gespiegelte Datenkopie. Die Witness-Appliance speichert lediglich minimale Metadaten und agiert als Quorum-Entscheider bei einer Netzwerktrennungen.

Die Standard-Storage-Policy in einem Stretched Cluster ist ein Dual-Site-Mirror. Fällt eine Site physisch komplett aus, übernimmt die verbleibende vollautomatisch den Betrieb. Die Witness sorgt dafür, dass bei einer reinen Netzwerktrennung (ohne tatsächlichen Host-Ausfall) nicht beide Sites gleichzeitig weiterlaufen und divergente Datenstände produzieren, das gefürchtete Split-Brain-Szenario.

Innerhalb jeder Site lässt sich zusätzlich eine lokale FTT-Policy anwenden, sodass auch der Ausfall einzelner Hosts innerhalb einer Site weiterhin abgefangen werden kann.

Mit VCF 9.1 führt VMware den Site Maintenance Mode (SMM) ein. Mit nur einem Klick lässt sich eine vollständige Site in den Wartungsmodus versetzen, ohne dass die Stretched-Konfigurationen dabei temporär aufgelöst werden. Für Betreiber mit zwei Rechenzentren bedeutet dies eine erhebliche operative Vereinfachung.

Eine zweite Neuerung in Version 9.1 ist die Möglichkeit, Stretched Storage über vCenter-Grenzen hinweg zu betreiben. Dadurch werden das Stretched-Modell und das disaggregierte Modell miteinander verbunden, worauf wir jetzt näher eingehen.

Disaggregated vSAN (vSAN Max)

vSAN ist klassischerweise Teil der HCI-Architektur und wie folgt aufgebaut: Jeder ESXi-Host vereint Compute (CPU/RAM) und Storage (lokale Disks) in einem Gehäuse. Dieses Modell lässt sich zwar linear skalieren, ist aber ziemlich starr. Eine in kleineren oder mittelgroßen Umgebungen mögliche Option, das Nachstecken von weiteren Disks (Scale-Up), wird hier bewusst ignoriert. Wer lediglich mehr Storage-Kapazität benötigt, muss zwangsläufig auch Compute-Leistung (und damit teure Core-Lizenzen) mitkaufen, und umgekehrt.

Mit vSAN Max bietet VMware eine dedizierte Produktedition für besonders große, disaggregierte Storage-Deployments. Das zugrundeliegende Konzept des disaggregierten vSAN existiert seit vSAN 7 U1. Es bricht die HCI-Struktur auf und trennt Compute und Storage in separate Cluster.

In diesem Fall werden dedizierte vSAN Storage Clusters (vSAN Max) bereitgestellt, also, die Hosts, die ausschließlich Storage liefern und keine Workloads tragen. Und deren Datastores per Mount für Compute-Only Clusters freigegeben werden.

Ein Compute-Only Cluster besteht aus ESXi-Hosts ohne lokales vSAN. Die VMs laufen hier ganz normal, ihre virtuellen Festplatten (VMDKs) liegen jedoch auf dem entfernten vSAN-Max-Datastore.

Mount über vCenter-Grenzen hinweg: Ein zentraler vSAN-Storage-Cluster lässt sich nun flexibel in Compute-Cluster einbinden, die von einer anderen vCenter-Instanz verwaltet werden. Dies ist sowohl über verschiedene Workload-Domains als auch über vollständig separate VCF-Deployments möglich. Somit lässt sich der Speicher als globale Ressource im Unternehmen verteilen.

Shared vSAN Storage (Mix-Modell) ermöglicht es, dass ein Compute Cluster gleichzeitig sowohl OSA- als auch ESA-Storage Cluster mountet. Dies ist in Migrationsszenarien relevant, in denen ältere OSA-Bestände neben neuen ESA-Clustern weiterbetrieben werden sollen.

End-to-End-Encryption (Data-in-Transit): Die Sicherheit bei disaggregierten Strukturen ist wichtig. Da die Daten nun über das physische Netzwerk zwischen dem Compute- und dem Storage-Cluster transportiert werden müssen, wird in VCF 9.1 die End-to-End-Verschlüsselung auf den disaggregierten Datenpfad zwischen Compute- und Storage-Cluster erweitert. In Kombination mit der Data-at-Rest Verschlüsselung kann der gesamte Speicherpfad lückenlos geschützt werden.

Natives Object Storage in vSAN

In VCF 9.1 wurde die lang ersehnte Funktionalität in vSAN implementiert (aktuell als „Technology Preview“): vSAN erhält einen nativen, in den Hypervisor integrierten, S3-kompatiblen Object Store. Somit liefert ein einziger vSAN-Cluster alle drei Speicherklassen aus derselben Plattform: Block, File und Object.

Aus architektonischer Sicht basiert die S3-Storage sowohl auf bereits bekannten Komponenten wie vSAN File Services als auch auf einem speziell entwickelten Zero-Copy-Protokoll. Dieses minimiert das I/O-Queuing über die Stack-Schichten und optimiert somit die Ressourcennutzung. Da die S3-Storage Komponente nativ in vSAN integriert ist, sind die Funktionen wie z.B. Global Deduplication und vSAN Encryption Services ebenfalls integriert.

Cyber Resilience

Das Thema Security und Ransomware-Schutz werden immer wichtiger und die Data-in-Transit Verschlüsselung ist nicht die einzige Funktion, die in der VCF 9 eingeführt wurde. Erwähnenswert sind auch diese Funktionen:

Immutable vSAN Snapshots. Lokale Snapshots können mit unveränderlichen Eigenschaften versehen werden. Selbst wenn ein Angreifer administrative Rechte erlangen würde, können diese Sicherheits-Snapshots innerhalb des definierten Aufbewahrungszeitraums weder modifiziert noch böswillig gelöscht werden.

Tag-basierte Protection Groups / vSAN Protection Groups. Die Absicherung von Workloads kann vollständig automatisiert erfolgen. Über die Protection Groups lässt sich die Zugehörigkeit von VMs mithilfe von vSphere-Tags steuern. Sobald eine VM ein bestimmtes Sicherheits-Tag erhält, greift die zugewiesene Absicherungsrichtlinie sofort, ohne dass ein manueller Eingriff seitens der Admins erforderlich ist.

Multiple Retention Schedules. Es besteht die Möglichkeit, flexible, mehrstufige Aufbewahrungsrichtlinien innerhalb derselben Schutzgruppe zu konfigurieren. Beispielsweise können tägliche, wöchentliche und monatliche Pläne erstellt werden.

Dedizierte Cyber Recovery vSAN Cluster und Clean Rooms. Im Ernstfall bietet VCF 9 in Kombination mit VMware Live Cyber Recovery die Möglichkeit, dedizierte Cyber-Recovery-Cluster direkt über den bewährten vCenter-Quickstart-Workflow bereitzustellen.

Diese Cluster fungieren als isolierte, forensische Testumgebungen, sogenannte „Clean Rooms”, in denen kompromittierte VMs sicher hochgefahren, untersucht und bereinigt werden können, ohne das produktive Netzwerk zu gefährden.

Und es geht weiter…

Wie man sieht, hat sich vSAN in mehreren Bereichen massiv weiterentwickelt. Ein wichtiger Punkt, nämlich die Storage Policies für Kubernetes-Workloads, wurde in diesem Beitrag bewusst ausgeklammert. Das Thema wird aber im nächsten Beitrag dieser Serie detailliert behandelt. Weiter geht es um VKS (vSphere Kubernetes Services) (kommt bald). Bleiben Sie dran!