Was ist richtlinienbasiertes Speicher-Management in VMware vSphere?

    Policy Based Storage-ManagementVMwares hyper­konvergente Storage-Lösung Virtual SAN (vSAN), aber auch die Storage-Technologie Virtual Volumes (VVOLs) setzen richtlinien­basiertes Speicher-Management (Policy Based Storage Management, PBSM) um. Das System platziert VMs dann auto­matisch auf Data­stores, die den defi­nierten Policies genügen.

    Um zu verstehen, was PBSM bringt und welche Rolle dabei die vStorage APIs for Storage Awareness (VASA) spielen, ist es nützlich, sich zu vergegen­wärtigen, wie man ein richtlinien­basiertes Storage-Management auf Basis traditioneller Storage-Konzepte realisiert. Dabei stellt sich zuerst die Frage, wozu man eigentlich Speicher­richtlinien braucht.

    Eine Frage der Workloads

    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 der 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.

    Die Storage-Policies sind an VMs angeheftet und sorgen dafür, dass die VMDKs immer auf einem passenden Speicher zu liegen kommen

    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.

    Keine Kommentare