HCI-Testreihe, Teil 2
HCI mit VMware vSAN 6.7
VMware hat seine Virtual-SAN-Lösung im Lauf der Jahre kontinuierlich ausgebaut. Die Sicherheit der gespeicherten Daten gewährleisten verschiedene Redundanzverfahren, die auch den Ausfall von mehreren Hosts, ganzen Racks oder kompletten Standorten verkraften können. Ein Quickstart-Assistent vereinfacht das Setup von vSAN-Clustern.
Zum zweiten Teil der LANline HCI-Testreihe tritt VMware mit vSAN 6.7 an (Teil 1 zu WS2019 S2D siehe LANline 6/2019, ab S. 16). VMware bietet vSAN bereits seit einigen Jahren an und hat mit der HCI-Lösung einen hohen Marktanteil erreicht. Die Einsatzbereiche für vSAN sind breit gestreut. Sie reichen von geschäftskritischen Anwendungen über Virtual Desktop Infrastructure (VDI) bis zu 2-Node-Lösungen für kleinere Unternehmensstandorte.
Die vSAN-Funktionen hat VMware direkt in den ESXi-Kernel implementiert. Ein vSAN-Cluster besteht standardmäßig aus mindestens drei Hardware-Servern. VMware bietet verschiedene vSAN-Editionen an. Die Funktionen Deduplizierung, Datenkomprimierung und Erasure-Coding sind erst ab der Advanced Edition enthalten. Der Virtual Distributed Switch (DSwitch) ist bei allen Editionen dabei. Eine Verschlüsselung der gespeicherten Daten und die Stretched-Cluster-Funktion sind der Enterprise Edition vorbehalten.
vSAN unterstützt die von vSphere bekannten Mechanismen wie Hochverfügbarkeit, Verschieben von VMs im laufenden Betrieb oder Distributed Resource Scheduling (DRS) für eine automatische Lastverteilung im vSAN-Cluster. Auch vSphere Replication und der Site Recovery Manager für ein automatisiertes Desaster Recovery lassen sich mit vSAN nutzen. Eine Cloud-Anbindung ist ebenfalls möglich.
Für die lokalen Datenlaufwerke stehen bei vSAN-Clustern zwei Optionen zur Verfügung. Zum einen unterstützt die Software Hybridkonfigurationen mit HDDs und Flash-Laufwerken. Dabei verwendet das System die Flash-Drives automatisch für den Cache-Layer und die HDDs für den Capacity Tier. Zum anderen lässt sich ein vSAN mit All-Flash-Servern betreiben, bei denen die vSAN-Software einen Teil der Flash-Laufwerke für den Cache verwendet und den Rest als Kapazitätsschicht.
Hierfür bietet sich zum Beispiel eine Kombination aus NVMe-Flash-Karten für den Cache und SAS- oder SATA-SSDs für die Datenspeicherung an. 3-Tier-Konfigurationen aus Cache-Devices, einem Performance-Tier mit SSD-Drives und einem Capacity-Tier mit HDDs unterstützt vSAN nicht. Damit ein vSAN-Cluster die Daten optimal verarbeiten und speichern kann, sollten alle Storage-Nodes mit denselben Laufwerken bestückt sein.
Prinzipiell ist es möglich, in einem vSAN-Cluster auch reine Compute-Nodes ohne Datenlaufwerke aufzunehmen. Dies wird aber von VMware nicht empfohlen. Durchaus gängig ist es dagegen, einen vSAN-Datastore auch mit ESXi-Hosts zu nutzen, die nicht Mitglied des vSAN-Clusters sind. Zudem kann ein vSAN-Host auch auf normale VMFS- oder NFS-Datastores von SAN-Speichersystemen zugreifen und VMs zwischen diesen und dem vSAN-Datastore hin und her verschieben. Für kleinere Außenstellen lässt sich vSAN als 2-Node-Cluster konfigurieren. Dieser benötigt eine virtuelle Witness-Appliance, die im zentralen RZ des Unternehmens laufen kann.
Für vSAN-Cluster gibt es verschiedene Kaufoptionen. Die meisten größeren Server-Hersteller bieten so genannte vSAN Ready Nodes an, die VMware zertifiziert hat. Der Mutterkonzern von VMware, Dell EMC, hat mit VMware VxRail und VxRack SDDC zwei vSAN-Komplettlösungen aus Hard- und Software im Angebot. Zudem wird ein User-defined vSAN unterstützt, bei dem der Kunde die Hardware selbst beschafft und sich die passenden vSAN-Lizenzen dazu kauft. Wer diesen Weg wählt, sollte penibel darauf achten, dass alle Hardwarekomponenten in der vSAN-HCL (Hardware Compatibility List) von VMware enthalten sind.
Für den LANline-Test von VMware vSAN 6.7 Update 1 standen drei Dell Poweredge Server T640 der aktuellen Hardware-Generation zur Verfügung. Jedes System verfügte über eine Intel-Xeon-CPU mit zehn Cores, 64 GByte RAM sowie zwei SATA-SSDs und sechs 10k-SAS-HDDs für den vSAN-Datastore. Die Netzkommunikation erfolgte über zwei 10GbE-Karten, die mit einem 10-GBase-T-Switch von Netgear verbunden waren. VMware empfiehlt auch für Hybrid-vSANs ein 10GbE-Netz, für All-Flash-Konfigurationen ist dies Pflicht. Zunächst installierten wir auf den drei Servern den Hypervisor ESXi 6.7. Die Verwaltung der ESXi-Hosts erfolgte über eine vCenter-6.7-Appliance.
Konfiguration via Cluster-Quickstart-Assistent
Für das vSAN-Setup nutzten wir den Cluster-Quickstart-Assistenten, der den Administrator in wenigen Schritten durch die Konfiguration führt. Als erstes fügt er die ESXi-Hosts zum neuen Cluster hinzu. Wir aktivierten im Wizard DRS und vSphere HA, damit das vCenter die Last gleichmäßig auf alle ESXi-Hosts verteilt und VMs beim Ausfall eines Nodes automatisch auf einem anderen Host neu startet. Auch die Enhanced vMotion Compatibility (EVC) lässt sich im Schnellstart-Wizard aktivieren. Der EVC-Modus bietet eine bessere CPU-Kompatibilität, wenn man innerhalb eines Clusters unterschiedliche CPU-Typen mischt.
Nachdem der Assistent den vSAN-Cluster erstellt hatte, führte er uns durch die weiteren Konfigurationsschritte. Standardmäßig legt er einen DSwitch und eine Port-Gruppe an. Wir fügten dem DSwitch auf jedem ESXi-Host die zwei physischen 10GbE-Ports hinzu und konfigurierten für den vSAN-Traffic ein eigenes IP-Subnetz.
Im Abschnitt mit den erweiterten Optionen lassen sich unter anderem die Verschlüsselung sowie Deduplizierung und Komprimierung der im vSAN gespeicherten Daten aktivieren. Bei unserem Test-Cluster standen diese Datenreduktionsoptionen nicht zur Verfügung, weil sie aus Leistungsgründen nur in All-Flash-Konfigurationen zur Verfügung stehen. Um den vorhandenen Speicherplatz möglichst effizient zu nutzen, unterstützt vSAN 6.7 die TRIM/UNMAP-Kommandos des Betriebssystems. Die Space Reclamation gibt den nach dem Löschen von Dateien im Filesystem des OS frei gewordenen Speicherplatz auch im vSAN-Datastore wieder frei.
Für den Desasterschutz lässt sich ein vSAN als Stretched Cluster über zwei Standorte hinweg einrichten. Die Latenz der Standortkopplung darf fünf Millisekunden nicht übersteigen. Diese Konfiguration benötigt eine Witness-VM, die nicht auf dem vSAN-Cluster laufen darf und die man an einem dritten Standort platzieren sollte.
vSAN unterstützt sogenannte Fault Domains, die ESXi-Hosts zu Gruppen zusammenfassen. Damit lassen sich die redundanten Datenkopien auf mehrere Racks oder Blade-Chassis verteilen, sodass auch beim Ausfall eines kompletten Racks oder Chassis keine Daten verloren gehen. VMware hat diese Schutzfunktion um eine zweite Ebene erweitert, die zum Beispiel bei einem Stretched Cluster die Daten am jeweiligen Standort mit RAID-5-Erasure-Coding schützt und sie zusätzlich per RAID-1-Spiegelung am anderen Standort speichert.
Konfiguration der Datenlaufwerke
Bei der Einrichtung der Datenlaufwerke hat der Quickstart-Assistent zunächst keine Festplatten erkannt. Wie sich herausstellte, befanden sich auf den Disks noch Partitionsinformationen des vorherigen mit WS2019 S2D durchgeführten HCI-Tests. Nachdem wir über das vCenter alle Datenlaufwerke vollständig gelöscht hatten, ließen sie sich problemlos zum vSAN-Cluster hinzufügen.
Der vSAN Quickstart-Assistent stellt die Speicherkapazität standardmäßig als einen einzigen Datastore bereit. Bei einem manuellen Setup kann der Administrator auch mehrere vSAN-Datastores konfigurieren. Die Speicherkapazität eines vSAN-Clusters lässt sich durch Hinzufügen neuer Hosts sowie durch den Einbau zusätzlicher Laufwerke in die vorhandenen Hosts erweitern. Das vSAN kann die neue Kapazität automatisch zum vorhandenen Datastore hinzufügen und die Daten anschließend wieder gleichmäßig auf alle Laufwerke verteilen.
Fünf Disk Groups pro Server
Auf unserem Test-Cluster richtete der Wizard einen vSAN-Datastore ein, der die sechs SSDs als Cache-Tier und die 18 HDDs als Kapazitäts-Tier nutzte. Dazu wurden auf jedem Host zwei Disk Groups mit je einer SSD und drei HDDs erstellt. Eine vSAN Disk Group besteht immer aus einem Cache-Device und ein bis sieben Capacity-Drives. Pro Server sind bis zu fünf Disk Groups möglich. Ein vSAN-Cluster unterstützt bis zu 64 ESXi-Hosts.
Bei All-Flash-Systemen puffern die Cache-Devices nur die Schreiboperationen, weil die Capacity-Flash-Laufwerke die Lesevorgänge bereits mit einer hohen Performance ausführen. vSAN unterstützt Laufwerke mit SATA-, SAS-, PCIe- und NVMe-Schnittstelle sowie Persistent Memory (NVDIMM). In Hybrid-Konfigurationen beschleunigt der Cache auch die Lesevorgänge, für die 70 Prozent des Cache-Speichers zur Verfügung stehen.
In unserem 3-Node-Hybrid-Cluster standen etwa 10 TByte brutto für die persistente Datenspeicherung und 1,3 TByte als Cache zur Verfügung. Die nutzbare Kapazität lag bei 5 TByte, weil 3-Node-Cluster immer eine RAID-1-Redundanz mit einfacher Spiegelung verwenden. Für den Schutz vor zwei Host-Ausfällen mit RAID-1-Spiegelung sind mindestens fünf Nodes erforderlich. Ab sieben Hosts kann sogar der Verlust von bis zu drei Hosts verkraftet werden.
Der Schutz mit RAID-5-Erasure-Coding setzt mindestens vier Hosts voraus, weil die Redundanz durch drei Datenkomponenten und eine zugehörige Parity-Komponente erzeugt wird. RAID-6-Erasure-Coding, das vor dem gleichzeitigen Ausfall von zwei Hosts schützt, benötigt mindestens sechs Hosts. Erasure Coding steht bei vSAN nur in All-Flash-Konfigurationen zur Verfügung, weil die Speicherung der Daten sehr I/O-intensiv ist.
VMware empfiehlt, zum einem vSAN-Cluster generell einen zusätzlichen Host hinzuzufügen, damit bei einem länger dauernden Ausfall eines Hosts die vSAN-Software mithilfe des Reserve-Systems die ursprüngliche Datenredundanz der jeweiligen RAID-Konfiguration wiederherstellen kann. Sobald ein Host länger als 60 Minuten nicht verfügbar ist, startet ein automatisches Rebuild der verloren gegangenen Redundanzinformationen. Wenn zum Beispiel bei einem 3-Node-Cluster ein Host ausfällt und bei den verbleibenden zwei Hosts zusätzlich ein Datenlaufwerk den Dienst verweigert, besteht die Gefahr von Datenverlusten.
Die Basiskonfiguration und Erstellung des vSAN-Clusters war nach etwa 15 Minu-ten abgeschlossen. Die Verwaltung eines vSANs erfolgt am einfachsten über das VMware vCenter. Für das Management stehen zudem die Kommandozeilen-Tools vSphere Power CLI und Ruby vSphere Console (RVC) sowie das auf RVC basierende Performance-Monitoring-Tool Virtual SAN Observer zur Verfügung. Eine Automatisierung ist über die umfangreichen APIs und mehrere Software Development Kits möglich.
Storage-Policies auf VM-Ebene
vSAN steuert die Datenredundanz und die Performance-Eigenschaften der vSAN-Objekte über das VMware Storage Policy Based Management Framework (SPBM). Jede VM besteht aus mehreren vSAN-Objekten. Der Administrator legt in der Storage-Policy fest, wie viele Host-Ausfälle das System tolerieren und mit welcher RAID-Technik es die Datenredundanz herstellen soll. Die Storage-Policies lassen sich für jede VM individuell konfigurieren. Es ist sogar möglich, den virtuellen Disks derselben VM unterschiedliche Einstellungen zuzuweisen. Wenn man keine Storage-Policy konfiguriert hat, verwendet vSAN automatisch die Standard-Policy, die für jeden Datastore angelegt wird. Der Administrator kann die für eine VM festgelegten Policies auch nachträglich ändern und zum Beispiel die Fehlertoleranz im laufenden Betrieb von RAID-1-Spiegelung auf RAID-5-Erasure-Coding umstellen.
vSAN verfügt über einen Health-Service, der den Zustand des Clusters regelmäßig überprüft. Stellt die Software Probleme fest, erzeugt sie Warnmeldungen und gibt Hinweise zu Lösungsmaßnahmen. Der vSAN Performance Service überwacht die I/O-Leistung, den Durchsatz und die Latenz auf Cluster-, Host-, Disk- und VM-Ebene. Das Tool zeigt die aktuellen und historischen Werte grafisch an.
Der VMware Update Manager (VUM) aktualisiert nicht nur die ESXi-Software, sondern kann auch Firmware und Treiber der vSAN-Hosts auf den neuesten Stand bringen. Die Installation der Updates per VUM ist nun auch in Umgebungen ohne Internetanbindung möglich. Die aktuelle Beta-Version von vSAN bietet zusätzliche Funktionen. VMware hat eine neue VM-Snapshot-Technik entwickelt, mit der sich VMs in sehr kurzen Zeitabständen sichern lassen. Zudem unterstützt die Beta-Version native File-Services, um NFS- oder CIFS-Shares bereitzustellen sowie persistenten Storage für Container. Ob VMware alle Beta-Features in das nächste vSAN-Release übernimmt, bleibt abzuwarten.
VMware vSAN im Testbetrieb
Für den LANline-Test installierten wir auf dem vSAN-Cluster insgesamt sechs WS2016- und WS2019-VMs. Über das vCenter stehen für vSAN die gewohnten Funktionen inklusive VM-Setup mittels Templates zur Verfügung. Um die Redundanzfunktionen des 3-Node-Clusters zu testen, schalteten wir einen ESXi-Host hart aus, indem wir ihn von der Stromversorgung trennten. Die zwei auf diesem Host laufenden VMs wurden automatisch auf den beiden anderen Nodes neu gestartet. Abgesehen vom Neustart der zwei VMs konnten wir keine weiteren Beeinträchtigungen feststellen. Im vCenter erschienen Warnmeldungen, dass ein Host ausgefallen und deshalb die Redundanz der gespeicherten Daten nicht mehr gewährleistet ist. Durch den Ausfall des Hosts zeigte der vSAN-Datastore eine um ein Drittel niedrigere Gesamtkapazität an. Nachdem wir den dritten Node wieder hochgefahren hatten, hat das vCenter nach einiger Zeit die zwei ursprünglich auf diesem Host laufenden VMs per vMotion automatisch zurückverschoben.
Den Ausfall eines Laufwerkes simulierten wir, indem wir eine SAS-Festplatte aus einem Server entfernten.. Das vCenter zeigte an, dass eine Disk fehlt und dass vSAN in 60 Minuten automatisch mit der Resynchronisierung startet. Unter dem Menüpunkt Resyncing Objects zeigt das vCenter an, welche VMs von einem Platten- oder Host-Ausfall betroffen sind. Das Rebuild wurde erwartungsgemäß gestartet und vSAN hat für die vom Ausfall betroffenen 23 GByte Daten innerhalb von zehn Minuten die in der Storage-Policy konfigurierte RAID-1-Fehlertoleranz wiederhergestellt. Nachdem das Rebuild abgeschlossen war, haben wir die Disk wieder eingeschoben. Es hat etwa fünf Minuten gedauert, bis das Laufwerk wieder im vSAN Datastore zur Verfügung stand. Ein Rebalancing hat das System nicht durchgeführt, weil durch den Ausfall lediglich für 23 GByte VM-Daten eine neue Redundanzkopie erstellt werden musste. vSAN führt zudem eine automatische Umverteilung von Datenblöcken durch, sobald bei einem Laufwerk mehr als 80 Prozent Speicherplatz belegt sind.
Mit vSAN 6.7 ist es auch möglich, iSCSI-LUNs zu erstellen und an externe Hosts zu mappen. Wir konfigurierten über das vCenter ein neues vSAN-iSCSI-Target, erstellten eine 500-GByte-LUN und wiesen diese einem physischen WS2019-Server zu. Auf dem Windows-System konnten wir diese LUN problemlos hinzufügen und als zusätzliches Datenlaufwerk nutzen.
Fazit
Die vSAN-Lösung von VMware lässt sich relativ einfach aufsetzen und kann durch ihre nahtlose Integration in das vCenter überzeugen. Über die grafische Management-Oberfläche sind die meisten von vSphere bekannten Funktionen auch für vSAN-Cluster nutzbar.
Durch die Kombination verschiedener RAID-Level und Fehlertoleranzmechanismen lässt sich die Konfiguration flexibel und granular an die Schutzbedürfnisse der jeweiligen VMs anpassen. Die Lizenzierung von vSAN richtet sich nach der Anzahl der physischen CPU-Sockets. Preise sind auf Anfrage erhältlich.
Lesen Sie mehr zum Thema
