VMware vSphere unterstützt neben lokalen Storage im ESXi-Server selbst (SAS, SATA etc.) nicht nur klassische blockbasierte Enterprise-Backend-Technologien wie FC, FCoE oder iSCSI auf Basis des eigenen Cluster-fähigen Dateisystems VMFS, sondern auch dateibasierten Storage in Form von NFS-Netzwerkfreigaben.
Virtual SAN
Ferner arbeitet VMware mit VMware vSphere Virtual SAN seit der Version 5.1 an einer eigenen Software-definierten-Storage-Technologien, die auf in den lokalen ESXI-Servern verbauten Festplatten- (welche sich ohne Virtual-SAN-Clustering bekanntlich nicht sinnvoll als Shared-Storage nutzen lassen) und SSDs-Arrays basiert, welche Virtual SAN dann zu einem logischen, virtuellen Speicherpool zusammenfasst , der sämtlichen von einem VSAN-Cluster partizipierenden Hosts zur Verfügung steht. Mit VMware Sphere Virtual SAN 6.2 geht VMwares Hoffnungsträger für ein gewichtiges Mitspracherecht im zukunftsträchtigen Markt für Software-Defined-Storage bereits in die 4. Produktgeneration und hat inzwischen einen akzeptablen Reifegrad erreicht.
Storage-APIs
Beim SAN-Support ist zudem zu erwähnen, dass VMwares Einfluss auf die Hardwaresteller groß genug ist, dass diese von VMware entwickelte Storage-APIs, wie das seit 2010 verfügbare VMware vSphere Storage APIs - Array Integration (VAAI) oder das jüngere VMware vSphere API for Storage Awareness (VASA) in der Regel bereitwillig adaptieren.
Storage-Schnittstelle VAAI
VAAI ist ein mit vSphere 4.1 eingeführtes Paket von Storage-Programmierschnittstellen. Die API erlaubt es, Prozesse, die zuvor vom vSphere-Host initiiert und durchgeführt wurden, in den Storage zu verlagern, darunter vMotion, Cloning, Provisining. Insbesondere Technologien wie Provisioning oder das Erstellen von Snapshots sind ja ohnehin Technologien, die initial aus dem Storage-Umfeld stammen. Durch das Auslagen spezifischer Storage-Prozesse an SAN/Festplatten-Arrays, die VAAI unterstützen, erzielt vSphere eine sehr hohe Performance, sodass der ESXi derartige Prozesse nicht nur schneller durchführt, sondern auch den CPU-, RAM- und Storage-Bandbreitenbedarf reduziert. Konkret lassen sich mit VAAI-Support Blockkopien und Block Zeroing in das Array auslagen. Ferner erlaubt VAAI die Wiedergewinnung von ungenutztem Speicherplatz und ermöglicht Out-of-Space-Warnungen für Thin-provisionierte Arrays.
VAAI unterstützt darüber hinaus nicht nur blockbasierter Storage, sondern auch NAS-Systeme (NFS). Die VAAI-API ist VMware-seitig ab der Enterprise Edition in vSphere enthalten. Unterstützten anfangs (bis 2012) nur Enterprise-SAN-Systeme VAAI, bieten heute auch viele Hersteller von Home- und SOHO-NAS-Systemen VAAI-Support. Während der VAAI-Support bei Enterprise-Systemen in der Regel out-of-the-box gewährleistet ist, muss VAAI bei NAS/SAN-Geräten der Home- und SOHO-Klasse manchmal erst nachgerüstet, oft auch explizit aktiviert werden, wie in der folgenden Abbildung für eine Synology RackStation RS814+ zu sehen.
vSphere-seitig zeigt sich ein vom Backend unterstützter VAAI-Support darin, dass der betreffende Datastore im Tab "Settings" bei "Storage Capabilities" im Bereich "Hardware Acceleration" den Eintrag "Supported on all Hosts" zeigt. Optional kann man auch in der "Hosts and Clusters"-Ansicht bei markiertem Host im Tab "Manage" zu "Storage" wechseln, auf "Storage Devices" klicken und in der Tabelle der Storage-Geräte mit rechts auf die Spaltenköpfe klicken, um die Spalte "Hardware Acceleration" einzublenden.
Ohne VAAI müsste der EXI-Host Provisioning- oder Cloning-Vorgänge selber erledigen, also quasi wie ein xcopy jeden einzelnen Block einlesen und wieder rausschreiben. Mit VAAI nimmt der vSphere-Host nur noch die Statusmeldungen entgegen und stellt die Informationen dar. Übrigens funktioniert Storage vMotion via VAAI nur dann, wenn die Blockgröße der Quell- und Ziel-LUN identisch ist.
Die APi VASA
Eine weitere Storage-Schnittstelle stellt VMware seit einiger Zeit mit "VMware vStorage APIs for Array Awareness" (VASA) zur Verfügung. Die VASA-API erlaubt vSphere sowohl das Überprüfen von Storage-Konfigurationen, als auch das Festlegen von Storage-Eigenschaften für Arrays, die diese Funktionalität unterstützen. VASA wird von vSphere Virtual Volumes (VVOL), Virtual SAN und der vSphere API for IO Filtering (VAIO) als zentrale, einheitliche Steuerungsebene für vSphere-Storage genutzt. Mehr zum VVOL-Support im entsprechenden Abschnitt.
Das API-Framework VAIO
VMware vSphere API for IO Filtering (VAIO) erlaubt Entwicklern von Drittanbietersoftware das Hinzufügen von Datenservices zu ESXi und vSphere.
Die Storage-Schnittstelle iSCSI
Exemplarisch für die Unterstützung professioneller SAN-Umgebungen sei im Folgenden das Einrichten eines Datastores auf Basis von iSCSI demonstriert, wobei vorgesetzt sein soll, dass die betreffenden iSCSI-Targets, bzw. LUNs auf Backend-Seite existieren. Eine für den ESXI-Server sichtbare LUN kann von diesem dann exakt so behandelt werden wie eine lokale Festplatte, allerdings mit dem entscheidenden Unterschied, dass die LUN physisch im SAN-Array liegt und daher für alle ESXI-Hosts sichtbar ist.
Richtet der Administrator dann einen neuen VMFS-Datastore auf Basis von iSCSI-LUNs ein, kann er diesen nachher jederzeit flexibel durch Hinzufügen weiterer LUNs vergrößern. Natürlich lässt sich eine einzelne LUN auch partitionieren. Aufgrund der signifikanten Kostenvorteile einer SAN-Anbindung via iSCSI gegenüber Fibre Channel - bei iSCSI wird als Speichernetzwerk das vorhandene IP-Netzwerk genutzt, sodass der Aufbau eines separaten Speichernetzwerks samt Verkabelung, Switches und Hostadaptern entfällt - setzen gerade kleine Unternehmen primär auf iSCSI.
Für eine vernünftige Performance sollten dann allerdings 10 GBit/s-NICs und Switche zur Verfügung stehen und die ESXi-Hosts mit separaten physischen Netzwerkkarten für den iSCSI-Traffic ausgestattet sein, sonst hat man an iSCSI keine Freude. Auch der Storage-Prozessor im Backend sollte entsprechend Dampf haben, sprich das Backend mit ausreichend CPU-Kernen und RAM ausgesattet sein. Insofern bringt es meist wenig, iSCSI auf einem Home-NAS mit Atom-Prozessor und 1x1GBis/s Netzwerkadapter zu konfigurieren.
Software Initiator - der Storge-Adapter für iSCSI
Was den Storage-Adapter für iSCSI betrifft kommt seit einigen Jahren nur noch der mit ESXI gelieferte Software-Initiator zum Einsatz, da aktuelle CPUs den entsprechenden Overhead locker verkraften und sich die Anschaffung eines in Hardware gegossenen iSCSI-Adapters nicht rechnet.
NFS-Dateisystem
Das Vorgehen zum Einrichten eines neuen NFS-Datastore ist deutlich einfacher. Auch NFS-Datastores kommen in vSphere als Shared-Storage für vMotion- und/oder Cluster-Operationen in Frage. NFS ist zwar ein Netzwerkdateisystem, von Haus aus (in Version 3) aber nicht per se Cluster-fähig. Während VMFS entsprechende Lock-Mechanismen mitbringt, löst VMware dies bei NFS3 mit versteckten Lock-Dateien. NFS 4.1 hingegen, das vSphere seit Version 6.0 unterstützt, bringt wiederrum eigene Lock-Verfahren mit, die zu den VMware-eigenen in NFS 3 inkompatibel sind. Daher sollten NFS 3.0 und NFS 4.1 in vSphere-Umgebungen nicht gemischt werden. NFS 3.0 ist sehr ausgreift, stabil und performancetechnisch weit besser als sein Ruf, sofern das Fundament mitspielt etwa in Form einer durchgängigen 10GBis/S-Verkabelung.
Für NFS 4.1 spricht eigentlich nur der Kerberos-Support und damit eine generelle Möglichkeit der Authentifizierung bei der Nutzung von NFS-Freigaben, z. B. gegen ein Active Directory. Bei NFS 3 lassen sich Zugriffsrechte nur auf Client- bzw. Client-Netzwerk beschränken. Allerdings machen bis heute nur wenige vSphere-Nutzer von NFS 4.1 Gebrauch, zumal dann auch die Gegenseite mitspielen muss. Übrigens kommt als NFS-Server mitnichten nur ein NAS oder Linux-Server in Frage. Auch Windows Server sprich auf Wunsch sei geraumer Zeit auch NFS (Server und Client), wenn der Admin die entsprechend Rolle hinzufügt.
Zum Anlegen eines neuen NFS-Datastore kommt der gleiche Datastore-Assistent zum Einsatz, nur dass der vSphere-Admin jetzt im ersten Schritt bei Typ "NFS" wählt. Schließlich gibt man im Folgeschritt "Name and configuration" bei "NFS Share Details" den Namen der NFS-Freigabe (Ordner) und den des NFS-Servers an, wählt im Folgeschritt den oder die Ziel-ESXi-Hosts aus und klickt auf "Finish". Ein Formatieren oder Partitionieren entfällt im Vergleich zu einem blockbasierten VMFS-Volumes.
VVOLs machen Storage VM-aware
Seit vSphere 6.0 steht im "New-Datastore"-Assisitenten mit" VVOL" noch eine dritte Option zur Verfügung. Ein VVOL-Datastore erfordert allerdings zwingend VVOL-Support auf Backendseite, d. h. das entsprechende Storage-Gerät muss einen sogenannten VASA-Provider mitliefern. Konzeptionell gehen VVOLs in eine ähnliche Richtung wie die erwähnte VAAI-Schnittstelle, verlagern also Storage-relevante Operationen in das Storage-Gerät, allerdings reicht der VVOL-Ansatz deutlich weiter, als die VAAI-Schnittstelle. VVOLs erlauben es den in den eigentlichen VMDK-Dateien gespeicherten Betriebssystem-Installationen direkt mit den Speichersystemen zu kommunizieren, auf denen sie physisch liegen. Das Storage-Arrays kann dann z. B. Clones oder Snapshots von VM selbst erzeugen. Die Idee dahinter ist erstmal administrativer Art. Ohne VVOLs muss sich der vSphere-Admin dazu prinzipiell immer mit dem Storage-Admin abstimmen, um die spezifischen Eigenschaften der verschiedenen Speichersysteme für Dinge wie Snapshots, Clones oder Replikation abzubilden. Der Storage-Admin könnten dann z. B. einen Disk-Pool anlegen, diesem eine RAID-Gruppe zuordnen, dort logische Laufwerke erzeugen und diese letztendlich einem ESX-Server zuordnen, von dem dann das gewünschte Betriebssystem in eine VMDK-Datei installiert wird. Mit VVOL-Support lassen sich diese Vorgänge direkt aus dem vCenter-heraus steuern, ohne dass der vSphere-Admin mit den Storage-Administrator zusammen arbeiten muss.
Storage Container
Damit das funktioniert, müssen drei neue Technologien "Storage Container", der "Storage Provider" (VASA) und die so genannte "Protocol Endpoints" zusammenarbeiten. Storage-Container sind Speicher-Pools in einem Array. Bei VVOLs muss lediglich der Pool aus mehreren physikalischen Platten im Storage-System angegeben werden. Dateisysteme oder Ähnliches benötigen Storage-Container nicht. Der vSphere Admin kann dann darin mit dem beschriebenen Datastore-Assistenten im Web Client so viele VVOLs anlegen, wie Speicherplatz vorhanden ist. Der Storage-Provider stellt eine Out-of-Band-Kommunikation zwischen vCenter und den genutzten Speicherarrays her. vSphere erkennt aus dieser Kommunikation die spezifischen Eigenschaften des Arrays, die dann den jeweiligen Pool als Eigenschaften zugeordnet sind. Diese Kommunikation ist bidirektional. VCenter kann daher auch Befehle über das jeweilige API an das Speichersystem senden. Das vCenter definiert also etwaige Anforderungen wie Verfügbarkeit oder Leistung an ein VVOL und reicht sie an das Array weiter, das dann selbständig den entsprechenden Speicherplatz "zusammenbaut". Der Storage-Provider wird stets vom Storage-Hersteller geliefert und nutzt die von VMware zur Verfügung gestellte API.
Foto: VMware
Der so genannten "Protocol-Endpoint" wiederrum kommuniziert mit den VVOLs bzw. VMDKs an Stelle des ESXi-Servers, der selbst keine direkte Sicht auf die VVOLs hat. Hierbei handelt es sich wahlweise um eine LUN, wenn Blockspeicher verwendet wird, oder einen Mountpoint, bei Verwendung von NAS-Systemen Sobald eine VM liest oder schreibt, kümmert sich der Protocol-Endpoint darum, den I/Os zum korrekten VVOL zu leiten. Der Haupt-Nutzen von VVOLs besteht in der Vereinfachung der Speicherverwaltung, da separate Konfigurationsvorgänge am Storage-System entfallen. Der Einsatz von VVOLs lohnt sich also immer dann, wenn sich sehr große VMware-Installationen auf viele unterschiedliche Speichersysteme verteilen und die Abstimmung mit den jeweiligen Administratoren viel Zeit frisst.
Fazit
Seit Jahren beherrscht vSphere nur alle relevanten Enterprise-Storage-Technologien der Speicherhersteller, sondern setzt zunehmend auch eigene Trends. Damit schafft sich VMware neben den Vorsprung in der eigentlichen Compute-Virtualisierung (die weitgehend ausgeizt ist) weitere Alleinstellungsmerkmale. (hal)