Was ist eigentlich VMware vSAN? VMware vSAN ist ein essentieller Teil der VMware Software Defined Datacenter (SDDC) Strategie. vSAN ist Teil der Hyperconverged Infrastructure (HCI) Lösung, die VMware anbietet.

VMware vSAN stellt dabei den Software Defined Storage (SDS) Teil dar. Mittels dieser Lösung lassen sich – heruntergebrochen – Datenspeicher und Datenservices für VMware und nicht-VMware Lösungen bereitstellen.

Aufbau

vSAN ist dabei in den bekannten vSphere Stack integriert. Als Kernelmodul läuft es innerhalb des ESXi Hypervisors. Die Vorteile liegen dabei auf der Hand: einfache Bereitstellung, da vSAN bereits in jedem ESXi Hypervisor integriert ist. Immer mehr als ausreichend Performance, da keine weiteren (externen) Komponenten, wie Storage-Appliances, benötigt werden. Und unkompliziert zu bedienen. Das Management ist in die bekannten VMware Produkte vollständig integriert. Das Aktualisieren von vSAN ist so beispielsweise nichts weiter, als das Aktualisieren der ESXi Version.

vSAN stellt also Datenspeicher und -dienste zur Verfügung und ist dabei in den ESXi Hypervisor integriert. Der eigentliche Vorteil liegt jedoch in der Verwendung der sogenannten Storage Policies (SPBM – Storage Policy Based Management). Über diese Polices werden Verfügbarkeit, Redundanzen und weitere Datendienste gesteuert und granular auf Objektebene vergeben. Die Policies lassen sich genauso auf Gruppen von VMs anwenden, wie auf einzelne VMDKs.

Um vSAN nutzen zu können werden entsprechende Komponenten benötigt. vSAN benötigt mindestens ein Flash-Device als Cache und eine HDD oder SSD als Capacity Device. Diese Kombination bildet zusammen eine Disk Group. Disk Groups können maximal aus 1x Cache plus 1-7 Capacity Devices bestehen. Und es können je Host maximal 5 Diskgroups konfiguriert werden (was 5 Cache- und 35 Capacity Devices in Summe entspricht).

Das Maximum an Hosts innerhalb eines vSAN Clusters ist 64. In einem Stretched Cluster maximal 31 Hosts (30 Hosts plus 1 Witness). Je nach Sizing sind Kapazitätsgrößen von mehreren PB (nutzbarer Kapazität) möglich.

Die Cache Devices können dabei 2,5“/3,5“ SSDs sein, aber auch NVMe Devices (2,5“ oder PCIe) oder NVDIMMs (ab vSAN 6.7). Capacity Devices sind entweder 2,5“/3,5“ HDDs oder SSDs oder auch NVMe Devices – je nach Anforderungen an die Kapazität oder Performance. Die Disks für vSAN müssen auf der vSAN HCL stehen und über einen IO-Controller angebunden sein, der ebenso für vSAN freigegeben ist.

Neben Disks und IO-Controllern ist das Netzwerk für vSAN essentiell. Über ein eigenes vSAN Network wird die (synchrone) Replikation der Objekte bzw. Komponenten vorgenommen. Über die Storage Policy wird dabei festgelegt wie viele Kopien eines Objektes angelegt werden. Die Spiegelung und Replikation erfolgt dann innerhalb des vSAN Clusters über das vSAN Network.Im Fehlerfall werden über das vSAN Network Daten wiederhergestellt. Dabei gilt: je höher das Datenvolumen zum Wiederherstellen, desto mehr Bandbreite wird benötigt. Die Faustregel hierbei: für Hybridinstallationen (Flash als Cache- und HDDs als Capacity Devices) reichen schon 1 GbE Netzwerke aus. Für All-Flash Systeme ist 10 GbE zwingend erforderlich, um die gewünschte Latenz zur Verfügung stellen zu können.

Das vSAN Network sollte ein separates IP-Subnetz sein und idealerweise in einem eigenen VLAN isoliert werden. Konstrukte mit redundanten Anbindungen sind seit vSAN 6.7 möglich.

vSAN Designarten

Die klassiche Spielart im vSAN ist der vSAN Standard Cluster. Er besteht aus mindestens 3 Hosts. Dabei kann eine Fehlertoleranz von 1 erreicht werden – es darf 1 Host ausfallen ohne dass Daten nicht mehr im aktiven Zugriff sind. Ratsam ist eine Größe von 4 Hosts, denn so lässt sich auch Wartung an einem der Hosts durchführen, ohne dass die Redundanz unterbrochen werden muss.

Für kleinere Installationen, beispielsweise in einer DMZ oder in Außenstellen, eignet sich der 2-Node-Cluster. Dabei werden 2 Hosts entweder direkt miteinander via Crossover Verkabelung oder über eine Switchinfrastruktur miteinander verbunden. Zusätzlich wird ein dritter Server als dedizierte Entscheidungsinstanz (sogenannter Witness) benötigt. Diese Witness muss an einem dritten Standort betrieben werden. Häufig anzutreffen ist das Konstrukt für Außenstellen, wo die Witness dann im Hauptstandort zentral betrieben wird.

Die Witness kann ein physischer ESXi Host sein (der entsprechend zu lizenzieren ist) oder eine Witness Appliance. Die Witness Appliance ist eine VM, die bereits vollständig vorkonfiguriert ausgerollt werden kann und die eine entsprechend benötigte Lizenz von Haus aus mitbringt.

Auf die Rolle der Witness werde ich in einem meiner nächsten Blogposts näher eingehen.

Technisch gesehen ist der 2-Node-Cluster bereits eine Art vSAN Stretched Cluster. Dieser besteht eben nur aus genau 2 Hosts plus Witness. In einem vSAN Stretched Cluster werden mindestens 2 Hosts je Site eingesetzt und bilden so das vSAN Cluster. Maximal lassen sich 31 Hosts in einem vSAN Stretched Cluster einsetzten (Stand: vSAN 6.7).

Die beiden Sites in einem vSAN Stretched Cluster können sich in unterschiedlichen Brandabschnitten, unterschiedlichen Gebäuden oder sogar unterschiedlichen Liegenschaften befinden. Dabei muss die Verbindung der vSAN Hosts untereinander möglichst optimal sein. Eine hohe Latenz oder geringe Bandbreite wirkt sich negativ auf die Performance aus. Als Vorgabe gilt:

• Direkte Layer 2 Netzwerkverbindung der vSAN Hosts untereinander; die Verbindung der vSAN Hosts zur Witness kann Layer 3 sein
• Die maximal zulässige Latenz der vSAN Hosts von Site A zu Site B darf maximal 5ms Round Trip Time (RTT) betragen – je Weg also 2,5ms
• Als Bandbreite wird mindestens 1 GbE zwischen den Sites benötigt, empfohlen ist jedoch 10 GbE (besonders bei All-Flash Installationen)
• Die Latenz der vSAN Hosts zur Witness darf maximal 200ms RTT (2-Node-Cluster: 500ms RTT) betragen und als Bandbreite wird mindestens 2 Mbit/s empfohlen

Die Bandbreite zwischen den vSAN Hosts von einer in die andere Site lässt sich durch folgende Formel berechnen:

Bandbreite = Schreibbandbreite x Data Multiplier x Resync Multiplier

VMware empfiehlt hierbei einen Faktor von 1,4 für den Data Multiplier und 1,25 für den Resync Multiplier.

Beispiel: für einen Workload von 10.000 IOPS schreibend mit 4k Blöcken (10.000 x 4KB = 40 MB/s = 320 Mbit/s) lautet die Rechnung:

Bandbreite = 320 x 1,4 x 1,25 = 560 Mbit/s

Die lesenden Operationen werden in einem vSAN Stretched Cluster nicht über die Verbindung der beiden Sites durchgeführt. Lesende Operationen sind in einem vSAN Stretched Cluster immer innerhalb einer lokalen Site (sogenanntes Read Locality).

Die Bandbreite zur Witness wird über folgende Formel berechnet:

Bandbreite = 1138 Bytes x Anzahl Komponenten / 5 Sekunden

Die 1138 Bytes stammen dabei von der Anzahl an Operationen, die stattfinden, wenn eine Site offline geht und die verbleibende Site alle Komponenten übernimmt.

Beispiel: Bei 166 VMs, die aus je einer VMDK mit weniger als 255GB Größe bestehen, und mit einer Fehlertoleranz von 1 gespiegelt werden, benötigt vSAN 966 Komponenten (166 VMs x 3 Komponenten/VM x 2 Kopien).

Zusätzlich rechnen wir die 1138 Bytes in Bits um: 1138 Byte = etwa 1000 Bit

Bandbreite = 1000 Bit x 1000 / 5s = etwa 1,82 Mbit/s – mit 10% Reserve werden also 2 Mbit/s benötigt

Diese Berechnung gilt nicht für den 2-Node-Cluster. In einem 2-Node-Cluster fällt der Faktor von 1138 Byte nicht an. Daher wäre die Berechnung mit den gleichen Parametern für ein 2-Node-Cluster wie folgt:

Bandbreite = Anzahl Komponenten / 1000 x 2 Mbit/s

Für 166 VMs mit 1000 Komponenten gilt:

Bandbreite = 1000 / 1000 x 2 Mbit/s = 2 Mbit/s

Informationen über den Aufbau von vSAN „unter der Haube“ sowie die Vorstellung der Spiegelungsmechanismen sowie der vSAN Data Services folgen in Teil 2.