Was ist richtlinienbasiertes Speicher-Management in VMware vSphere?

In einer gewachsenen Virtualisierungs­umgebung existieren natur­gemäß diverse virtuelle Server, die ihrerseits ganz unter­schiedliche Anforderungen an das Storage stellen. Dies ist neben Sicherheit und Verfüg­barkeit auch ein wesentlicher Grund dafür, auf ein und demselben virtuellen Server nicht mehrere Applikationen parallel auszuführen. Rein technisch wäre dies möglich, indem man die VM entsprechend dimensioniert.

Wenn man sich schon zu parallel laufenden Services in einer VM entschließt, dann sollten es solche mit einer ähnlichen Workload-Charakteristik sein, wie beispielsweise mehrere Worker-Instanzen auf einem Web Server.

Hinsichtlich dieser Charakteristik könnte man mehrere Typen von Anwendungen unterscheiden:

• Ausgewogen: Darunter fielen etwa Cache-Farmen, Back-End-Systeme für SAP, Microsoft SharePoint.
• CPU-intensiv: beispiels­weise Cluster-Computing, verteilte Analysen, wissenschaftliche und technische Anwendungen, Ad-Serving, Stapel­verarbeitung, Video-Codierung
• RAM-intensive: Dazu zählen etwa In-Memory-Datenbanken, SAP HANA, Datenverarbeitungs-Engines wie Apache Spark oder speicher­intensive Workloads wie NoSQL-Datenbanken (Cassandra, MongoDB und Redis), Transaktions­datenbanken oder Data Warehouses.

Daher ist es meist besser, für jeden Anwendungs­dienst einen eigenen virtuellen Server bereitzustellen, ein Ansatz der auch bei Containern und noch mehr bei Microservices zum Einsatz kommt.

Isolierung auf VM-Ebene reicht nicht

Doch selbst wenn man Workloads mit unterschiedlichen Charakteristiken voneinander isoliert, indem man sie in separaten VMs ausführt, beeinflussen sich diese Systeme immer noch. Das gilt vor allem dann, wenn ihre VMDKs gemeinsam auf einem Shared Datastore liegen, der am Backend auf der gleichen LUN basiert (Tiering).

Bei klassischen SAN-Architekturen definiert nämlich die LUN die Eigenschaft des Datastores. Daher versteht es sich von selbst, dass verschiedenartige Workloads nicht auf die gleiche LUN gehören.

Ein anderes Thema sind Service Level Agreements. Angenommen, Sie möchten einem Kunden für das Speichern seiner VM einen gewissen Durchsatz (IOPS) oder eine gewisse Verfügbarkeit garantieren. Dann müssen Sie eine Lösung erarbeiten, die dafür sorgt, dass die betreffende VM immer auf einem Datastore liegt, dessen zugrunde liegende LUN die geforderten Eigenschaften auch erfüllt.

So etwas lässt sich nur bis zu einem gewissen Grad manuell gewährleisten. Denn was ist zum Beispiel, wenn Storage-DRS die betreffenden VMs für einen Kapazitäts- oder Last-Ausgleich (I/O) in einen Datastore im Cluster verschiebt, der vSphere Admin die VM für Wartungs­aufgaben auf einen anderen Datastore migriert oder der Storage-Admin aus einem ähnlichen Grund die LUN verschiebt bzw. deren Eigenschaften im Storage-Array ändert? Hier kommen Speicherrichtlinien ins Spiel.

Was bringen Speicherrichtlinien?

Mit Speicherricht­linien können Sie grob gesagt dafür sorgen, dass eine VMDK stets auf einem Datastore zu liegen kommt, der mit den Speicher­richtlinien einer VM kompatibel ist. Richtig komfortabel funktioniert das allerdings nur, wenn der Speicher VMwares vStorage APIs for Storage Awareness (VASA) unterstützt.

Hierbei handelt es sich um einen Satz von Programmier­schnitt­stellen (APIs), der es vCenter ermöglicht, die Fähigkeiten des Speicher-Arrays zu erkennen. Eingeführt mit vSphere 5.0 im Jahre 2011 (VASA 1.0), erlaubte das API zunächst nur eine unidirek­tionale Kommuni­kation. Dabei sorgt der so genannte VASA-Provider dafür, dass das Storage-Array seine Fähigkeiten publizieren kann.

Erst mit VASA 1.5 in vSphere 5.5 und der Vorstellung von Virtual SAN war es notwendig und möglich geworden, VASA auf eine bidirektionale Kommuni­kation zu trimmen. Dadurch kann auch die vCenter-Seite dem Storage mitteilen, welche Speicher­anforderungen für eine bestimmte VM gewünscht sind, wobei VMware vSAN den VASA-Provider selbst mitbringt und installiert.