VMware Virtual SAN (vSAN): Server-Laufwerke als Shared Storage nutzen

Allerdings richtete sich das VSA explizit an kleinere Firmen, weil es nur den Speicher von maximal 3 Servern zusammenfassen kann. Wie der Name nahelegt, handelt es sich beim VSA um ein Virtual Appliance, das als virtuelle Maschine auf allen beteiligten ESXi-Hosts laufen muss.

Virtual SAN soll künftig das VSA ersetzen und aufgrund seiner höheren Leistungsfähigkeit auch neue Einsatzgebiete erschließen. Es unterstützt in seiner ersten Ausführung die Einrichtung von Storage-Clustern mit mindestens 3 und bis zu 8 Knoten.

Das Management erfolgt ausschließlich über den vSphere Web Client, wobei auch das vCenter Server Appliance für diese Aufgabe geeignet ist. Bei der Installation eines vSAN-Clusters kann vSphere auf Wunsch alle leeren Disks automatisch ermitteln und in den Pool aufnehmen.

Implementierung im ESXi-Kernel

Im Gegensatz zum Virtual Storage Appliance läuft vSAN nicht in virtuellen Maschinen, sondern wurde in Form von Kernel-Modulen direkt im Hypervisor implementiert. Deshalb setzt es auch die Version 5.5 von ESXi voraus. Ein weiterer Unterschied besteht in der Anforderung, dass jeder Host neben Disk-Laufwerken auch über mindestens ein SSD verfügen muss.

Diese schnellen Medien erhöhen nicht die Speicherkapazität des Gesamtsystems, sondern dienen der Performance-Verbesserung. Sie fungieren als Cache für Lese-Zugriffe und als Puffer für Schreiboperationen, so dass jeder Speichervorgang erst auf einer SSD erfolgt, bevor die Daten schließlich auf Plattenlaufwerken landen.

Leistungsfähiges Netzwerk notwendig

Ein verteiltes Storage-System wie vSAN stellt erwartungsgemäß auch hohe Anforderungen an das Netzwerk, so dass VMware die Verwendung von 10 GBit NICs empfiehlt, die auf Host-Ebene zudem über Teaming gebündelt werden können.

Die Kommunikation innerhalb des Clusters umfasst nicht nur den permanenten Abgleich von Metadaten zwischen den Knoten, sondern je nach geforderter Redundanz bewegt ein vSAN auch große Mengen an Nutzdaten zwischen den Hosts. Hinzu kommt, dass auch Server in ein vSAN-Cluster aufgenommen werden dürfen, die über keinen Massenspeicher verfügen. Sie bedienen sich dann aus dem Storage-Pool der anderen Hosts.

Policies definieren die Anforderungen von VMs

Das VMware vSAN beschränkt sich keineswegs darauf, nur Speicherkapazität zu einem gemeinsam nutzbaren Pool zusammenfassen. Dem Konzept des Software Defined Datacenter zufolge soll die Intelligenz im Virtualisierungs- und Management-Layer liegen, der auf Basis von Standard-Hardware komplexe und flexible Dienste bereitstellt sowie Aufgaben automatisiert.

Ein Virtual SAN bietet daher die Möglichkeit, Anforderungen an den Speicher in Form von Policies zu definieren. Hier lassen sich Werte für Ausfallsicherheit und Performance festlegen. Kriterien sind beispielsweise die Zahl der tolerierbaren Ausfälle von Disks bzw. Hosts, die Zahl der Laufwerke, über die die Daten verteilt werden (Striping), die Größe des reservierten SSD-Caches oder die Menge an Speicherplatz, die beim Thin Provisioning von VMDKs fest zugeteilt werden soll.

Je höher die Anforderungen an die Availability sind, desto mehr Repliken der Daten hält das vSAN vor und umso höher ist der Speicherverbrauch. Es trachtet dabei immer danach, die Last zwischen den Knoten des Clusters automatisch gleichmäßig zu verteilen.

Flexible Nutzung der Storage-Ressourcen

Die Zuordnung von Policies zu VMs erlaubt eine große Flexibilität bei der Nutzung des Speicher-Pools, weil sich für jede einzelne virtuelle Maschine festlegen lässt, welche Service Levels sie in Bezug auf Verfügbarkeit und Performance erhalten soll. Im Ergebnis lassen sich auf ein und demselben Datastore je nach Applikation unterschiedliche Anforderungen erfüllen.

Bei der Bereitstellung von VMs prüft das Storage-Subsystem von vSphere, welche der vorhandenen Storage-Systeme die geforderten Kriterien erfüllt und platziert sie dann entsprechend. Steht nur ein vSAN zur Verfügung und kann es den Richtlinien für die VM nicht genügen, dann wird diese mangels Alternative trotzdem dort angelegt, aber als abweichend von den Anforderungen markiert (Not compliant).

Separate Lizenzen erforderlich

Virtual SAN ist mit den meisten Storage-bezogenen Features von vSphere kompatibel, darunter mit vMotion, HA oder Distributed Resource Scheduler (DRS). Allerdings unterstützt die Version 1.0 nur VMDKs mit dem alten Limit von 2 TB, die mit vSphere 5.5 eingeführten, bis zu 62 TB großen virtuellen Disks lassen sich auf ihm nicht nutzen.

vSAN ist zwar ein integriertes Feature von vSphere, muss aber separat erworben werden. Die Lizenzierung erfolgt pro CPU-Sockel, so dass dem Speichervolumen oder der Zahl der Laufwerke pro Host kaum Grenzen gesetzt sind. Jeder Server kann nämlich bis zu 5 Disk Groups beherbergen, von denen jede bis zu 7 HDDs und 1 SSD enthalten darf.

Keine Positionierung gegen EMC

Trotz der hohen Flexibilität und Ausfallsicherheit propagiert VMware seine neue Speichertechnik offiziell nicht als Alternative zu SANs, sondern als Tier-2-Storage. Als Tochter des Hardware-Herstellers EMC ist VMware hier in der Zwickmühle. Auf der VMworld präsentierte die Firma jedoch eine Demo, bei der ein vSAN ein All-Flash-Array bei der Nutzung durch virtuelle Desktops in puncto Performance übertraf.