Richtlinienbasiertes Speicher-Management mit VMware Virtual SAN (vSAN)

Folgende Abbildung demonstriert die Interaktion zwischen "Kunde" und "Provider". In der linken Spalte kommuniziert ein Array 1, welche Fähigkeiten es besitzt und anbieten kann. Dazu gehören etwa RAID-Typ, Kapazität, Format etc.

In der mittleren Spalte zeigt eine Anwendung an, welche Anforderungen sie an das Storage-Array hat, beispielsweise IOPS oder Format. In der rechten Spalte antwortet ein Array damit, ob es die gewünschten Anforderungen erfüllt.

Eingeführt mit vSphere 5.0 im Jahre 2011 (VASA 1.0), erlaubte die Schnittstelle zunächst nur eine unidirektionale Kommunikation. Dabei sorgt der so genannte VASA-Provider dafür, dass das Storage-Array seine Fähigkeiten publizieren kann.

Erst mit VASA 1.5 (eingeführt mit vSphere 5.5) wurde es anlässlich der Vorstellung von VMware Virtual SAN notwendig, VASA auf eine bidirektionale Kommunikation zu trimmen. Damit kann auch die vCenter-Seite dem Storage mitteilen, welche Speicher­anforderungen für eine ausgewählte VM gewünscht sind, wobei VMware den VASA-Provider für VSAN selbst mitbringt.

Das mit vSphere 6 eingeführte VASA 2 unterstützte erstmals Virtual Volumes (1.0) und VASA 3 bei vSphere 6.5 dann die Array-basierte Replikation für Virtual Volumes 2.0.

Automatische Auswahl des passenden Speichers

Beiden neuen Speicher­technologien von VMware ist gemein, dass keine Notwendigkeit mehr besteht, sich Gedanken über Volume-Größen, Dateisysteme, Blockgrößen, Alignment oder ähnliche Dinge zu machen. Sämtliche virtuelle Maschinen-Objekte werden jetzt nämlich nativ im Speicher-Backend abgelegt, wobei sich das Speichersystem der Tatsache auch "bewusst" ist.

Bei VVOLs bekommt quasi jedes einzelne Objekt ihr eigenes virtuelles Volume. Das erstreckt sich auf Konfigurations­dateien (vmx), Daten (VMDK), Swap-Files, Snapshots, Config, Data, Disk- und Memory-Snapshots.

Bei Virtual SAN sind es die virtuellen Disks (VMDK), die Swap-Datei, der Home-Namespace für eine VM oder die Delta-VMDK sowie der Memory-Dump für Snapshots. Der Clou bei beiden Technologien besteht darin, dass sich jedes einzelne der beschrie­benen Objekte richtlinien­basiert ablegen lässt.

Da es bei Virtual SAN nur einen Hersteller gibt, nämlich VMware selbst, ist seine Standard-Speicher­richtlinie (im Vergleich zu den Möglichkeiten bei VVOLs) übersichtlicher, aber dennoch sehr wirkungsvoll, da es sich bei vSAN um einen echten Objektspeicher handelt.

Die wichtigsten vSAN-Policies

Er bietet die im Folgenden abgebildeten Möglichkeiten, wobei sich die einzelnen Einstellungen immer einer der Kategorien Capacity, Availability oder Performance zuordnen lassen bzw. diese beeinflussen.

Bei der mitgelieferten Standard-vSAN-Policy ist zum Beispiel der Vorgabewert für die Anzahl der zu tolerierenden Fehler (Primary level of failueres to tolerate) gleich 1. Die Regel bezieht sich auf den möglichen Ausfall eines ESXi-Hosts, einer Disk-Group oder einer Disk.

vSAN legt in diesem Fall eine zusätzliche Replik etwa des VMDK-Objektes an. Die Regel gehört in die Kategorie Availability, tangiert aber auch den Bereich Capacity, weil sie die Netto-Kapazität des Clusters beeinflusst.

Das gilt jedenfalls dann, wenn vSAN wie in der Default-Einstellung im RAID1-Modus arbeitet. Ändern lässt sich dies ggf. mit der vSAN-Policy failure tolerance method. RAID 5&6 (Erasure Encoding) lässt sich allerdings nur einstellen, wenn man über eine Advanced-Lizenz von vSAN verfügt und auch die Kapazitäts­laufwerke SSDs sind.

Ebenfalls 1 per Default ist die Voreinstellung für Number of disk stripes per object, eine Regel, die dem Bereich Performance zuzuordnen ist und darüber entscheidet, auf wie vielen Spindeln die Replik effektiv "ge-stripe-ed" wird. Ein höherer Wert führt zwar zu einer besseren Performance, verursacht aber auch eine höhere Auslastung von System-Ressourcen. Der mögliche Maximalwert ist 12, allerdings hängt dieser in der Praxis von der vorhandenen Zahl an Spindeln im Cluster ab.

Auch die Regel Flash read cache reservation (%) betrifft die Performance-Kategorie. Hier ist 0 die Voreinstellung und der Maximalwert 100 %, wobei vSAN die hier angegebene Flash-Kapazität als Read-Cache für das ausgewählte VMDK-Objekt reserviert, prozentual zur logischen Größe der VMDK-Datei. Jedoch steht die hier reservierte Kapazität dann anderen Objekten nicht mehr zur Verfügung

Das erklärt die Voreinstellung, denn ohne Objekt-spezifische Regel nutzt vSAN per Default 70 Prozent der vorhandenen Cache-SSD als Read-Cache und zu 30 Prozent als Schreib-Cache. Bei einer All-Flash-Konfiguration wird die Regel nicht unterstützt.

Der Wert bei Force provisioning steht per Vorgabe auf No. Mit Yes würde das betreffende VM-Objekt auch dann bereitgestellt, wenn die Einstellungen in Number of failures to tolerate, Number of disk stripes per object oder Flash read cache reservation verletzt würden.

Normalerweise überwacht VSAN aber kontinuierlich, dass die im Storage-Profil definierten Werte eingehalten werden. Beim Überschreiten eines Schwellwertes konfiguriert vSAN die betroffenen Datenbereiche der VM automatisch um.

So garantiert zum Beispiel IOPS limit for object die gewünschte Limitierung der IOPS für das betreffende Objekt. Die Berechnung basiert auf einer Default Base Size von 32 KB, d. h. ein 64-KB I/O repräsentiert zwei I/O-Operationen. Bei der Kalkulation werden Read und Write äquivalent behandelt, Cache-Treffer aber nicht berücksichtigt. Überschreitet eine Disk den angegebenen Grenzwert, wird sie von vSAN automatisch gedrosselt. Diese Funktion unterstützt allerdings nur die Enterprise-Version.