What’s New in vSphere 6: Überblick VMware Virtual Volumes – Part 1 – Basiskonzept

This entry is part [part not set] of 2 in the series What's New in vSphere 6: Überblick Virtual Volumes (VVols)

Mein Kollege Benjamin Ulsamer hat in bereits veröffentlichten Blogposts über die Neuerungen in vSphere 6 bzw. vSphere 6 Update 1 berichtet. In dieser Blogserie möchte ich das Augenmerk speziell auf ein Feature richten, das neben den  „Klassikern“ wie z.B. Cross-vCenter-vMotion oder Multi-CPU Fault Tolerance in vSphere 6 etwas in den „Hintergrund“ geraten ist. Die Rede ist von Virtual Volumes oder kurz: VVols.

Wer oder was verbirgt sich überhaupt hinter dem Begriff „VVols“ und an welcher Stelle kann mir dieses Feature in der Praxis helfen?

 

01. „Klassische“ Storageverwaltung

Sehen wir uns hierfür zunächst den momentanen „Status-Quo“ der Verwaltung von Storageressourcen in VMware vSphere an:

Jedem ESXi-Host wird pro Array eine Anzahl „x“ an LUNs oder NFS-Exports als Datastore bereitgestellt und innerhalb dieses Datastores werden dann entsprechend virtuelle Maschinen abgelegt. Jeder Datastore ist für sich also eine eigene Verwaltungseinheit, die über bestimmte Eigenschaften verfügt und separat gemonitored, gesichert und konfiguriert werden muss. Je nachdem auf welchem Plattentyp (SAS/SATA/SSD) ein Datastore im Storage angelegt wird, werden dadurch automatisch gleichzeitig z.B. die Performanceeigenschaften oder die Backup-Schedule der jeweils abgelegten VMs festgelegt.

Da innerhalb des vSphere Clients nicht ohne weiteres erkennbar ist, welcher Disktyp hinter einem Datastore steckt, bleibt meist nur der Weg über den Datastorenamen eine „manuelle“ Kennzeichnung vorzunehmen. Ob und wie ein Datenspeicher im Hintergrund gesichert wird, ist ebenfalls nicht im vSphere Client ersichtlich. Gleichzeitig ist (je nach Aufteilung der Verantwortlichkeiten innerhalb der Firma) auch das Bereitstellen von neuem Speicher recht zeitaufwendig, da von der Anforderung bis zur eigentlichen Bereitstellung Stunden oder vielleicht sogar Tage vergehen können.

02. Storageverwaltung mittels vSphere Virtual Volumes

In VMware vSphere 6 besteht nun die Möglichkeit neben den „klassischen“ Datastores, sogenannte vSphere Virtual Volumes einzusetzen:

 

Wie im Screenshot zu sehen, ändert sich durch den Einsatz von Virtual Volumes der Fokus: Die Arrays bzw. der zur Verfügung gestellte Speicher rückt in den Hintergrund, die VMs und deren virtuelle Disks (VMDKs) rücken ins Zentrum der Betrachtung.

Die Grundidee hinter VVols lautet: Der vSphere-Administrator definiert innerhalb des vCenters ausschließlich auf Basis von Policys welche Eigenschaften eine Storageressource erfüllen muss, auf die VMs platziert werden sollen. Der VMware vCenter (in Kombination einer zusätzlichen Softwarekomponente, dem sog. VASA-Provider) sorgt völlig transparent für die Platzierung der VMs und deren Komponenten auf „einem passenden Speicher“ und überwacht die Einhaltung der angewandten Richtlinie.

Wird eine VM gewollt oder ungewollt z.B. durch Storage vMotion auf einen anderen Speicher verschoben, der gegen die definierte Policy verstößt, erfolgt eine Alarmierung im vCenter oder (je nach Implementierung des Storageherstellers) sogar eine automatische Korrektur des Verstoßes.

03. Architektur & Funktionsweise von vSphere Virtual Volumes

Folgendes Bild zeigt die technische Grundarchitektur hinter VVols:

Durch Virtual Volumes kann der vCenter über entsprechende Software-Schnittstellen ermitteln, welche Fähigkeiten und Eigenschaften ein Array und der darüber zur Verfügung gestellte Speicher besitzen. Diese Integration geht sogar so weit, dass auch Eigenschaften wie der unterliegende Disktyp, Deduplizierungfunktion, HA-Fähigkeit, Snapshoting, Replikation etc. des Arrays ausgelesen und mit als Kriterium innerhalb einer Policy verwendet werden können. Ist für eine definierte Policy kein passender Speicher vorhanden bzw. eingebunden, ist es (je nach Implementierung) sogar möglich, über das vCenter automatisiert neuen Speicher auf einem passenden Array mit den geforderten Eigenschaften zu erzeugen und ins vCenter einzubinden.

„Hinter den Kulissen“ (aus Sicht des Storagesystems) ist auch die Art und Weise wie virtuelle Maschinen bzw. deren Dateien abgelegt und intern verwaltet werden, nicht wie bei klassischen Datastores. Das Storagesystem wird durch den Einsatz von VVols „VM-aware“; ist sich also der Tatsache bewusst, dass es sich bei den jeweiligen Objekten um Komponenten von virtuellen Maschinen handelt, was völlig neue Möglichkeiten (beispielsweise bei der Erzeugung von VMware-Snapshots) ermöglicht.

Technisch betrachtet greifen bei Virtual Volumes  viele Schnittstellen und Komponenten ineinander. Abgesehen von VMware vSphere 6 gibt es auch Storage-seitig bestimmte Voraussetzungen und Designregeln, die sich von Hersteller zu Hersteller unterscheiden. Wie beispielsweise die konkrete Implementierung in Kombination mit NetApp Clustered Data ONTAP funktioniert, möchte ich in einem späteren Step-by-Step Blogpost zeigen.

04. Weiterführende Informationen

Wer sich vorab schon einmal etwas tiefer mit dem Thema VVols beschäftige möchte, empfehle ich folgende Whitepaper, sowie kostenlose Hands-On-Lab von VMware:

Ich hoffe, ich konnte mit diesem Blogpost schon etwas Interesse oder die Neugier auf Virtual Volumes wecken :-). Im zweiten Part möchte ich auf die verschiedenen Komponenten im Zusammenhang mit VVols eingehen und erklären, was sich konkret hinter Begriffen wie z.B. dem VASA Vendor Provider, einem Protocol Endpoint, einen VVol-Datastore etc. verbirgt.

Bis dahin freuen wir uns natürlich immer über Fragen und Feedback!

Series Navigation

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.

 
Kommentare

Noch keine Kommentare vorhanden.

Hinterlassen Sie einen Kommentar