Virtual Volumes unter vSphere 6

Schon 2013 stellte VMware seine Vision vom Software Defined Datacenter (SDDC) vor. Die Grundidee ist die Verlagerung der Konfigurationsarbeiten vom Hardware-Layer in den VMware-Software-Stack. Grundstein für diese Philosophie war VMware NSX. Damit bietet der Hersteller die Möglichkeit, virtuelle Netzwerkkomponenten auf VMware-Ebene zu definieren (virtuelle Switche, Router und Firewalls). Sie können ACLs definieren und die Zugriffe zielgerichtet steuern. Der zweite Wegbereiter zum SDDC war das VSAN, das lokalen Storage anderen Hosts bereitstellt.

Ein Storage-Job verlässt den Host

Damit ist der vSphere-Host aber immer noch für Dinge verantwortlich, die eigentlich das Storage viel besser erfüllen könnte. Mit der "vStorage APIs for Storage Integration" (VAAI) ist diese Lücke geschlossen worden: Der Host tritt bei einigen Storage-Funktionen zurück, triggert den Job und reduziert sich selbst zur reinen Anzeige des Job-Trackings. Funktionen wie beispielsweise Cloning und Storage vMotion werden dadurch extrem beschleunigt.

Mit den Virtual Volumes (VVOLs) hat VMware die Palette hier erweitert und adressiert ein weiteres Problem. Vor der Virtualisierung wurde einem System, das zentralen Storage nutzen sollte, direkt eine LUN zugeordnet. Außerhalb des Clusters gab es dort eine 1-zu-1-Beziehung, das heißt, jede LUN gehörte genau einem Server. Mit der Virtualisierung führte VM­ware den Datastore ein. Es handelt sich dabei um einen mit dem Virtual Machine File System (VMFS) formatierten Datenbereich. Das Filesystem ist clusterfähig und erlaubt den parallelen Zugriff mehrerer Hosts. Zusätzlich können mehrere virtuelle Maschinen auf diesem Datenbereich abgelegt werden.

Der erstellte Datenbereich erhält Storage-Attribute, die für den gesamten Datenbereich und damit auch für alle dort gehosteten VMs gelten. Das kann dazu führen, dass es viele unterschiedliche

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.