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.

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)