Wie im ersten Teil beschrieben werden Storage Policies (SPBM) an VMs bzw. Objekte angehängt. Dabei besteht so eine VM aus vSAN Perspektive eben aus verschiedenen Objekten:

• VM Home Namespace (VMX-Datei, Log-Files etc.)
• VMDK (bis zu einer Größe von 255GB, danach werden VMDK-Files in mehrere Objekte aufgeteilt)
• VM Swap
• Snapshot
• Snapshot Delta

Storage Policies können dabei an den VM Home Namespace und VMDKs angehängt werden – auch unabhängig voneinander. Snapshots werden automatisch mit der Policy versehen, die für die zugehörige VMDK gesetzt wurde.

Nachdem nun klar ist welche Objekte vSAN kennt, sollten wir uns dem Begriff “Komponente” widmen. Eine Komponente ist im vSAN Gebrauch die kleinste Eineheit. Ein Objekt setzt sich aus mehreren Komponenten zusammen. Beispielsweise wird eine VMDK mit einer Größe von 355GB in eine Komponente a 255GB und eine zweite Komponente a 100GB aufgeteilt. Wenn diese VMDK nun mit einer Fehlertoleranz von 1 gespiegelt wird, werden aus den 2 Komponenten 4 – jede Komponente wird nun synchron gespiegelt um die konfigurierte Fehlertoleranz einzuhalten.

Wenn nun – wie in der oben dargestellten Situation – die Policy eine Fehlertoleranz von 1 vorsieht werden die Komponenten auf einen weiteren Host repliziert und dort synchron gespiegelt. Zusätzlich wird eine weitere Komponente für jedes Objekt angelegt – die Witness Komponente. Diese wird auf einen dritten Host abgelegt. So sind für jedes Objekt mindestens drei Komponenten vorhanden.

Wenn nun die beiden Hosts, auf denen die Datenkomponenten liegen, nicht mehr direkt miteinander kommunizieren können (Split Brain Szenario) kommt die Witness Komponente ins Spiel. Die Witness Komponente entscheidet dann welche der beiden Datenkomponenten “überlebt” und weiterhin schreiben darf. Die verbleibende Datenkomponente wird lesend geschaltet. Intern wird mit sogenannten “Votes” gearbeitet. Bei einer Fehlertoleranz von 1 und somit den beschriebenen 3 Komponenten bekommen die beiden Datenkomponenten jeweils ein Vote mit dem Wert 3, die Witness Komponente einen Vote mit dem Wert 2. Die Datenkomponente, die im Fehlerfall mit der Witness Komponente kommunizieren kann hat somit 5 Votes. Die verbleibende Datenkomponente nur 3 Votes – und würde sich damit unterordnen.

Fehlertoleranzen

Innerhalb der Storage Policies werden die Fehlertoleranzen definiert. Per Standard wird eine Fehlertoleranz von 1 angenommen. Doch was genau bedeutet das?

Fehlertoleranz meint, wie viele Komponenten ausfallen können, bis ein Objekt nicht mehr im aktiven Zugriff ist. Technisch wird dies als “Failures To Tolerate” (FTT) beschrieben. Ein FFT=1 beschreibt also, dass bei einem Objekt eine (Daten-)Komponente ausfallen kann ohne dass das Objekt offline geht. Bei FFT=2 besteht das Objekt aus 3 Datenkomponenten und es können somit 2 Komponenten ausfallen ohne dass das Objekt offline geht.

Bei einem vSAN Stretched Cluster existieren darüber hinaus noch weitere Fehlertoleranzmöglichkeiten. Mit der Primären Fehlertoleranz (Primary Failure To Tolerate = PFTT) wird definiert, ob ein Objekt in beiden Sites abgelegt werden soll. Somit wird ein Site-Ausfall abgefangen. Die Objekte sind in beiden RZ-Sites vorhanden.

Die sekundäre Fehlertoleranz (Secondary Failures To Tolerate = SFTT) definiert dann, ob innerhalb der Sites zusätzlich noch weitere Komponenten erzeugt werden. Dabei wird ein Ausfall von einem (oder mehrerer; je nach Konfiguration) vSAN Host abgefangen.

Wenn im Beispiel der Abbildung eine PFTT=1 gewählt wird, dann wird das Objekt in beide Sites abgelegt. Es ist also ein RAID-1 über beide RZ-Sites konfiguriert. Durch die Definition von SFTT=2 werden innerhalb der Sites weitere Redundanzen geschaffen. In diesem Fall über die Fehlertoleranzmethode RAID5/6. Näheres dazu später.

Somit lässt sich auch bei einem vSAN Stretched Cluster granular festlegen welche Fehlerszenarien abgedeckt werden sollen.

Neben den FTT-Einstellungen lässt sich auch die Fehlertoleranzmethode (Failure Tolerance Methode = FTM) definieren. Per Standard ist dies ein einfacher Spiegel, der einem RAID-1 entspricht. Optional lässt sich auch als FTM das sogenannte “Erasure Coding” aktivieren. In der Umsetzung ähnelt es dann einem RAID-5 bei FTT=1 bzw. einem RAID-6 bei FTT=2. Bei Erasure Coding werden die Komponenten plus Parity Informationen auf den Hosts im vSAN Cluster verteilt. Somit ergibt sich eine bessere Ausnutzung der Storagekapazität bei leicht niedrigerer Performance. Gleichzeitig werden bei FTT=1 und FTM=Erasure Coding mindestens 4 Hosts benötigt (besser: 5 Hosts auf Grund der Möglichkeit einer planmäßigen Wartung ohne verringerte Redundanzen).

Die nebenstehende Abbildung zeigt die Anzahl der benötigten Hosts in Abhängigkeit der gewählten Fehlertoleranzen und der gewünschten Fehlertoleranzmethode.

Bei einem vSAN Stretched Cluster und einem 2-Node-Cluster werden automatisch sogenannte Fault Domains gesetzt. Eine Fault Domain entspricht dabei einer Site und wird während der Konfiguration festgelegt. Bei einem vSAN Standard Cluster lassen sich jedoch diese Fault Domains händisch anlegen. Maximal werden 32 Fault Domains unterstützt.

Mit Hilfe von Fault Domains lassen sich rackübergreifend Redundanzen abbilden. Wenn nun 12 vSAN Hosts in 4 Racks verbaut werden kann diese logische Abhängigkeit im vSAN nachgebildet werden. Wenn nun ein neues Objekt mit FTT=1 erstellt wird, dann werden die Komponenten in 3 verschiedenen Fault Domains platziert. Sollte also ein komplettes Rack ausfallen ist somit sichergestellt, dass keine Daten offline gehen.

Mit vSAN 6.7 Update 1 wird der Aufbau von Fault Domains weiter verfeinert. Innerhalb einer Fault Domain lassen sich sogenannte Nested Fault Domains erstellen. Damit ist es dann möglich ein Objekt in 2 Serverracks abzulegen (PFTT) sowie innerhalb eines Racks = einer Fault Domain zusätzlich zu spiegeln (SFTT).

Im nächsten Teil geht es dann um vSAN Data Services sowie die Witness Appliance.

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.

Hallo und ein herzliches Willkommen auf meinem Blog. In der nächsten Zeit werde ich hier Artikel rund um Virtualisierung und VMware veröffentlichen. Seid gespannt!