What’s New in vSphere 6: Überblick Virtual Volumes (VVols) – Part 2 – Terminologie

Nachdem es im ersten Teil dieser Serie primär um die Grundkonzepte von Virtual Volumes ging, möchte in diesem Part das Augenmerk auf die Vielzahl von neuen Begrifflichkeiten legen, diesen man während der Arbeit sowie Implementierung mit VVols begegnet. Gleichzeitig werfen wir auch einen ersten Blick „hinter die Kulissen“, um technisch den Unterschied zu den klassischen Datastores genauer zu beleuchten.

Als Ausgangspunkt dient uns wie in Part 1 der Architekturüberblick, welcher uns  step-by-step durch die einzelnen beteiligten Komponenten führt:

Überblick: Architektur Virtual Volumes

• Storage Policy Based Management (SPBM)

Das Storage Policy Based Management bezeichnet ein Framework innerhalb von VMware vSphere das es ermöglicht, Storage-Ressourcen pro VM richtlinienbasiert zu zuweisen. Während früher Storage-Tiering primär pro Array stattgefunden hat, kann heutzutage ein einzelnes Storagesystem alle denkbaren Typen/Arten von Speicher parallel zur Verfügung stellen.

Denken wir als Beispiel einfach an ein NetApp FAS-Array: Ein einzelner Controller kann sowohl über Aggregate basierend auf SSDs, SAS- oder SATA-Disks verfügen und damit verschiedene Klassen (z.B. Gold, Silber, Bronze) von Speicher gleichzeitig bereitstellen.

Durch den Einsatz von SPBM kann innerhalb von vSphere nun auf Basis von manuell definierten VM Storage Policies z.B. bei der Erstellung einer VM festgelegt werden, auf welche Klasse von Speicher diese virtuelle Maschine abgelegt werden soll. Damit entfällt für den vSphere-Administrator die Notwendigkeit exakt zu wissen, hinter welchem Datastore nun welches Array, welcher Plattentyp, welche Funktionalität etc. steckt. Auf Basis der definierten VM Storage Policy ermittelt das vCenter automatisiert welche Storageressource für die jeweilige VM verwendet werden kann und überwacht über den Lebenszyklus der VM hinweg die Einhaltung dieser Richtlinie.

• Vendor Provider (VASA)

Damit das vCenter überhaupt in der Lage ist zu erkennen, über welche Eigenschaften und Features ein bestimmtes Storagesystem verfügt, bedarf es einer Kommunkationsschnittstelle zwischen beiden Komponenten. Genau diese Aufgabe übernimmt der sog. Vendor Provider (VP) auf Basis der vSphere API for Storage Awareness (VASA).

Diese Komponente wird vom jeweiligen Storagehersteller bereitgestellt und kann entweder direkt im OS des jeweiligen Arrays enthalten sein oder auch beispielsweise als zusätzliche virtuelle Appliance bereitgestellt werden. Grundsätzlich kann man den VP also als eine Art „Dolmetscher“ zwischen den APIs des Storage-Arrays und den vSphere APIs bezeichnen (=Control Path). 

Übersicht: Funktionsweise vSphere API for Storage Awareness

Genau diese Aufgabe macht den Vendor Provider zu einer extrem wichtigen und auch kritischen Komponente bei der Verwendung von vSphere Virtual Volumes, denn das vCenter ist ausschließlich durch den VP in der Lage, VVols zu erzeugen sowie diese zu verwalten.

Damit ergeben sich natürlich eine Reihe von technischen Abhängigkeiten die im Vorfeld zu beachten sind. Als Beispiel kann hier genannt werden, das der Ausfall des VPs zwar im ersten Moment keinerlei Einfluss auf bereits laufende VMs hat, jedoch sämtliche Ein- oder Ausschaltvorgänge nicht mehr ohne Weiteres möglich sind.

Auch wenn der VP „nur“ den Control-Path zwischen vCenter und Storage darstellt, ist diese Komponente beim Einsatz von VVols ein essentieller Bestandteil der vSphere Infrastruktur.

• Protocol Endpoint

Ein ebenfalls wichtiger Begriff bzw. fundamentales Konzept auf das man beim Einstieg in das Thema vVols stößt, ist der sog. Protocol Endpoint (PE). Ein Protocol Endpoint ist ein I/O-Proxy der Lese- und Schreibzugriffe der ESXi-Hosts entgegennimmt und an das entsprechende Virtual Volume weiterleitet.

Aus Sicht eines ESXi-Hosts ist ein PE eine normale LUN (FC/iSCSI) bzw. ein NFS-Export (NAS), wird jedoch nicht selbst direkt zur Speicherung von Daten verwendet. Ein PE ist nur der „Einstiegspunkt“ der zugreifenden Hosts um auf die dahinterliegenden Storageressourcen zugreifen zu können.

Durch den PE verschwindet gleichzeitig die bisher bekannte 1:1 Zuordnung zwischen LUN/NFS-Export und einem Datastore-Objekt im vCenter.

Grundkonzept Protocol Endpoint (PE)

Der Grund hierfür liegt im Grundprinzip von Virtual Volumes: Virtuelle Maschinen werden nicht mehr auf dedizierten Datastores sondern nativ und ohne Filesystem als Objekte auf einem Storage-Array abgelegt.

Jede VM besteht also selbst aus einzelnen VVol-Objekten. 

Somit greifen ESXi-Hosts über den Protocol Endpoint also bei jedem I/O  einer virtuelle Maschine nicht auf einen Datastore, sondern direkt auf das jeweilige (zur VM gehörende) Virtual Volume zu (=Data Path). Oder umgekehrt betrachtet: Jedes VVol wird an einen Protocol Endpoint gebunden und dadurch einem oder mehreren ESXi-Hosts zugänglich gemacht.

• Storage Container/VVol Datastore

Ein Storage Container bzw. ein VVol-Datastore ist eine logische Abstraktionsschicht die im Hintergrund die eigentlichen Ressourcen des Storage-Arrays gruppiert und vSphere als bekanntes Datastore-Objekt zur Verfügung stellt.

Um das Ganze etwas greifbarer zu machen, möchte ich kurz ein Beispiel in Kombination mit NetApp Clustered Data ONTAP anführen:

Ein VVol-Datstore besteht hier z.B. aus einem einzigen oder auch evtl. allen FlexVols einer einzelnen SVM. Durch diesen Aufbau können also innerhalb eines einzelnen VVOL Datastores, FlexVols mit unterschiedlichen Eigenschaften zusammengefasst und in vSphere als Datastoreobjekt verwendet werden. Auf welchem FlexVol später welche virtuelle Maschine (bzw. das jeweilige VVol-Objekt) abgelegt wird, wird ausschließlich über den Einsatz der VM Storage Policies definiert.

• Virtual Volumes (VVols)

Kommen wir zum Abschluss dieses Parts noch zur Komponente um die sich am Ende alles dreht ;-): Virtual Volumes.

Virtual Volumes sind im Endeffekt die Storageobjekte, die unsere virtuellen Maschinen repräsentieren. Jedes dieser Objekte enthält also einen Teil der Komponenten die einen virtuelle Maschine ausmachen. Insgesamt existieren fünf Typen/Arten von vVOL-Objekten: Config, Data, Swap, Memory und Other.

Die folgende gibt einen ersten Überblick über die VVol-Objekte und (abhängig vom Storagezugriff) in welcher Form diese implementiert sind:

Überblick: Arten von VVol-Objekten

Aus Sicht des vSphere Administrators ist dieser Aufbau jedoch komplett transparent, der Datastore-Browser zeigt alle Dateien die zu einer VM gehören gesammelt in der gewohnten Ansicht:

vSphere Web Client: Ansicht einer VM auf Basis von VVols

Jedes der oben genannten VVol-Objekte verfügt über bestimmte Eigenschaften und Besonderheiten die sich jedoch komplett „unter der Haube“ abspielen und im ersten Moment als VMware-Admin eigentlich nicht sichtbar sind. Das Ganze Konzept von VVols erscheint dem einen oder anderen sicher etwas suspekt und mir ist klar, dass allein die Begrifflichkeiten erstmal etwas für Verwirrung sorgen.

Um jedoch wirklich die Vorteile und die Raffinesse von VVols aufzuzeigen, möchte ich im nächsten Part deutlich konkreter werden und aufzeigen, wie die Implementierung von VVOLs mit NetApp Clustered Data ONTAP 8.3.1 funktioniert und an welchen Stellen genau aus technischer Sicht ein Benefit ensteht.

Spätestens dann hoffe ich die evtl. in diesem Part entstanden Fragezeichen auflösen zu können ;-).

Bis dahin stehe ich natürlich jederzeit gerne für Fragen oder Feedback zur Verfügung!

Stefan Bast

Stefan Bast ist seit Januar 2012 für Proact Deutschland tätig. Sein Schwerpunkt liegt auf den Technologien von VMware und NetApp. Außerdem richtet sich sein Fokus auf die ergänzenden Datacenter- und Cloud-Security Lösungen von Trend Micro, wie z.B. Deep Security oder ServerProtect. Neben den Tätigkeiten im Consulting ist er auch als Trainer im VMware Umfeld aktiv.