Neu in vSAN 7 (U1): SMB in Native File Services, Support für Laufwerke bis 32TB, Hot-plug für NVMe

Dazu werden NFS 4.1-File-Server automatisch als Agenten-VMs auf ausgewählten ESXi-Hosts im eigenen vSAN-Cluster erstellt. Sie bilden zusammen ein einziges verteiltes vSAN-Dateisystem (VDFS), das aus mehreren unabhängigen Datei-Servern besteht, die als Shards bezeichnet werden.

Der Shard-Manager fasst diese zu einen einheitlichen Namespace zusammen, so dass Nutzer wahlweise via SMB oder NFS auf die Dateifreigabe zugreifen können. Dazu muss der Shard-Manager an die vorhandene vSphere-Verwaltungs­oberfläche gebunden sein, die zur Steuerung von vSAN verwendet wird.

In vSphere 7 Update 1 hat VMware zudem die vSAN-Dateidienste in das Active Directory integriert. Sie lassen sich nun über Berechtigungen auf Basis von AD-Benutzern absichern. Primärer Anwendungs­fall hierfür ist aber weniger die traditionelle Datei­freigabe, sondern die Möglichkeit, Shared Storage als persistente Kubernetes-Speicherklasse für Tanzu anzubinden.

vSAN und Kubernetes

Container-Anwendungen, die dauerhaften Speicher benötigen, können somit vom Kubernetes-Administrator oder vom Anwendungs­entwickler bereitgestellt werden, ohne dass diese den zugrunde liegenden Speicher verstehen müssen.

Dazu ordnen vSAN-Admins einfach Speicher­richtlinien an Kubernetes-Speicherklassen zu. Die Abbildung unten zeigt das Prinzip: Hierbei ersetzt das Container Storage Interface (CSI) rechts oben im Bild den vSphere Cloud-Provider. Dieser ermöglicht eine dynamische Volume-Bereitstellung über die Kubernetes-StorageClass-API.

Das CSI ist ein Out-of-Tree-Treiber, beispielsweise ein Plug-In, das auf jeder Version von Kubernetes nach 1.12 installiert werden kann. Das Feature entkoppelt vSAN so vom Kubernetes-Release-Zyklus.

Laufwerke mit höherer Kapazität

Darüber hinaus erweitert VMware im Backend die Obergrenze für Laufwerke auf 32 TB bzw. jene für logische Kapazität auf 1 PB, sofern die Deduplizierung aktiviert ist. Dadurch erzielen Disks mit großer Kapazität bessere Deduplizierungs­raten. Ebenfalls neu ist der Hot-Plug-Support für NVMe im Backend.

Besonders komfortabel ist, dass das Ersetzen des Witness-Host-Appliance in einem 2-Node-Cluster eine sofortige Resynchro­nisierung eines Stretched Cluster auslöst.

Außerdem hat VMware im Stretched Cluster das Ausbalancieren der verfügbaren Kapazität zwischen den Standorten optimiert. Ungleichgewichte haben ihre Ursache meist darin, dass jede einzelne VM im vSAN mit einem anderen RAID-Level konfiguriert werden kann.

Hinzu kommt, dass Replikations­objekte nun auch in der vSAN-Kapazitätsansicht sichtbar sind. Ebenfalls verbessert wurde das Reporting der VM-Speicherkapazität und der historischen Daten zur Speicher­auslastung. Hierdurch lässt sich leicht nachvollziehen, wie sich das Hinzufügen oder das Upgrade von Laufwerken auf den verfügbaren Speicherplatz auswirkt.

VSAN 7 Update 1

Das kürzlich erschienene Update 1 brachte eine ganze Reihe weiterer Neuerungen. Bereits erwähnt habe ich die SMB-Unterstützung in den Native File Services sowie die Zugriffs­kontrolle, die nun mit Active Directory samt Kerberos-Authenti­fizierung integriert ist.

HCI Mesh

Wenn mehrere vSAN-Cluster ungleichmäßig ausgelastet sind, dann konnten Nutzer bisher die freie Kapazität eines einzelnen Clusters nicht einem anderem zuteilen. Um dies zu ändern, hat VMware mit vSAN 7 Update 1 eine Feature namens "disaggregiertes HCI" bzw. "HCI-Mesh" eingeführt.

Damit können vSAN-Administratoren nun Remote-vSAN-Datenspeicher aus anderen vSAN-Clustern bereitstellen. Auf diese Weise könnte eine virtuelle Maschine Compute-Ressourcen über den lokalen vSAN-Cluster erhalten und ihr Speicher auf dem Remote-vSAN liegen. Dies passiert allerdings nicht über iSCSI oder NFS, sondern ist tatsächlich nativer vSAN-Traffic.

Kompression ohne Dedup

Ein häufiger Wunsch vieler vSAN-Nutzer bestand laut Aussage von VMware darin, mehr Kontrolle über die Komprimierung und Deduplizierung zu erlangen. Bisher ließen sich beide Techniken bekanntlich nur zusammen aktivieren.

Nun hat VMware die Option Compression only eingeführt, mit der Anwender nur die Komprimierung alleine nutzen können. Der Vorteil dieser Änderung zeigt sich bei Workloads, die sich für die Deduplizierung nicht gut eignen.

Ein weiterer Pluspunkt: Fiel bisher in einem vSAN-Datastore, auf dem beide Mechanismen aktiviert sind, nur ein einziges Laufwerk aus, dann ist die gesamte Disk-Gruppe davon betroffen. Die Hash-Tabelle für die Deduplizierungs- und Komprimierungs­daten ist nämlich auf mehrere Datenträger verteilt.

Shared Witness Node

Bis vSAN 7 Update 1 musste man für jeden 2-Knoten- bzw. Stretched-Cluster genau eine Witness-Appliance bereitstellen. Hat man mehrere kleine vSAN-Cluster, dann braucht also jeder seinen eigenen dedizierten Zeugen-Knoten und damit jeweils eine vollwertige virtuelle Maschine.

Mit vSAN 7 Update 1 können sich bis zu 64 Zwei-Knoten-Cluster ein Zeugen-Appliance teilen, was die Ressourcen- und Kapazitäts­anforderungen erheblich senkt. Ferner unterstützt vSAN seit Version 7.0 das Überschreiben des Standard-Gateways im VMkernel für den vSAN-Verkehr und im VMkernel für den Witness-Traffic.