VMware VVols - Ganz einfach mit Nimble

Mit den Virtual Volumes (VVols) von VMware beginnt eine neue Zeit der Speicherverwaltung in vSphere Umgebungen. Ich möchte hier nicht auf die Vorteile oder die Details dieser Technologie eingehen. Darüber wurde bereits ausführlich geschrieben und berichtet. Am besten mal auf dem Blog von Cormac Hogan nachlesen: http://cormachogan.com/category/vvols/

Heute zeige ich wie einfach die Konfiguration von VVols mit Nimble funktioniert. Support für VVols gibt es ab Release 3.1 von NimbleOS. Meine Nimble VM läuft mit NimbleOS 3.2.1.
 
Als erstes muss der VASA Provider auf dem vCenter regestiert werden.
In der Nimble Obefläche auf "Administration -> VMware Integration" und ein neues vCenters anlegen bzw. das bereits vorhandene editieren.
 
Wichig ist der Haken bei "VASA Provider (VVols)". Anschließend auf "Save".
Um alle weitern Vorteile der VMware Integration zu nutzen sollte natürlich auch der Web Client registriert werden.

Als nächstes müssen wir eine Ordner auf der Nimble anlegen.
Under "Manage -> Storage Pools" den entsprechenden Pool auswählen.
Anschließend auf "New Folder" klicken.
 
Wählt man bei "Management Type" "Vmware virtual volumes (VVols)" aus, muss man die maximale Größe des Ordners angeben.
(Der Ordner ist natürlich Thin-Provisioned und braucht initial keinen Speicherplatz)
Unter "Managed By" muss das vCenter ausgewählt werden, das wir im vorherigen Schritt registriert bzw. editiert haben.
Anschließend auf Save.
(Mit diesem Schritt wird automatisch das PE (Protocol Endpoint) Device für den Pool angelegt)

Als nächstes legen wir einen neuen VVol Datastore für den ESX Cluster an.
Unter "Typ" muss jetzt natürlich "VVol" ausgewählt werden.
 
Im nächsten Schritt ist der Ordner sichtbar den wir zuvor angelegt haben.
Unten sieht man den Namen der Nimble Gruppe. In meinem Fall "PROD".


Anschließen noch die Host auswählen die Zugriff auf diesen VVol Datastore haben sollen.
Fertig!

Der VVol Datastore ist jetzt wie jeder normale Datastore sichtbar.

 

ACHTUNG: Ohne funktionierende DNS Auflösung und identische Uhrzeiten (NTP) für Storage, vCenter und ESX Hosts funktionieren VVols nicht!

Jetzt kann man sich mit den Storage Policies für die VMs beschäftigen.
Als Beispiel habe ich eine Policy mit dem Namen "Nimble-Gold-Repl" angelegt.
 
In dieser "VM Storage Policy" sind Snapshotintervalle sowie Replikationsintervalle in die Nimble Gruppe "DR" definiert.
Erstellt man jetzt eine neue virtuelle Maschine und wählt eine VM Storage Policy aus, greifen die dort eingestellten Eigenschaften automatisch.
 
Wenn man unter "Manage -> Volumes" auf den Ordner klickt, sieht man alle VMs, die in diesem VVol Datastore angelegt wurden.
  

Synchroner Spiegel mit Storage Spaces und Microsoft Server 2016

Lange ist es her, dass Zeit hatte mich um diesen Blog zu kümmern. Endlich ist mal wieder so weit. Ich sitze seit mehreren Stunden am Flughafen in Atlanta und vertreibe mir die Zeit mit dem Windows Server Technical Preview 2.

Dabei fokussiere ich mich aber ausschließlich auf das bereits bekannte Feature Storage Spaces. 
Gute Nachricht: Mit Server 2016 wird endlich auch iSCSI und FC Storage offiziell unterstützt. Außerdem gibt es neue Funktionen und Features:

Storage Spaces Direct

Storage Spaces Direct ermöglicht es HA Storage Lösungen mit lokalem Storage (Interne Platten oder JBODs die nur an einen Host angeschlossen sind) zu bauen.

Storage Replica

Storage Replica ermöglicht die synchrone Spiegelung zwischen zwei Cluster oder Server. Zusätzlich werden auch stretched Cluster unterstützt.

Beides sehr interessante Features, die mich persönlich aber nicht sehr interessieren.

Mich interessiert rein die Möglichkeit des synchronen Spiegel. Dabei möchte ich nicht die Funktion nutzen bei der ein Server/Cluster auf einen anderen Server/Cluster spiegelt. Mit meinen Tests möchte ich zeigen wie man einen Host basierenden Spiegel aufbauen kann.

Diese Funktion ist nicht neu. Die wohl bekannteste Software in diesem Bereich ist der gute alte Veritas Volume Manager (jetzt Veritas Storage Foundation). Veritas Storage Foundation ist weit mehr, als nur ein Stück Software um einen Host basierenden Spiegel aufzubauen. Es ist, wieder der Name schon sagt, ein Volume Manager.

Unter Linux gibt es schon lange die Möglichkeit eine Host basierenden Spiegel aufzubauen: Logical Volume Manager (LVM). Jedoch hat dieses Lösung einen großen Nachteil. Jedes Mal wenn ein Teil des Spiegels ausfällt, muss ein kompletter Rebuild durchgeführt werden. Bei ein paar GB ist das kein Problem, aber bei vielen TB durchaus.

Synchroner Spiegel mit Nimble und Storage Spaces

Auf einem Server habe ich Windows Server Technical Preview 2 installiert. Zusätzlich habe ich zwei Nimble Systeme (Nimble-PROD und Nimble-DR).
Jedes der Systeme präsentiert eine kleine LUN (20GB) an den Windows Server.



Unter Windows habe ich einen Storage Pool aus diesen beiden Platten (NimblePool01) erstellt. Anschließend eine Virtual Disk (Mirror01) mit Storage Layout Mirror:





Diese Virtual Disk kann jetzt wie jede andere Platte verwendet werden. 
Für unser Beispiel wird sie mit NTFS formatiert und als Laufwerk E: gemountet:



Wenn ich jetzt Last auf diesem Laufwerk erzeuge, werden alle Blöcke gleichmäßig auf beide Nimble Volumes verteilt. Ein Spiegel eben :)

Um einen Ausfall zu simulieren nehme ich das Volume von Nimble-DR offline:

NIMBLE-DR:/# vol --offline Server2016-DR --force

Der Server Manager bestätigt uns, dass eine LUN des Storage Pools ausgefallen ist:





In der Oberfläche von Nimble-A sieht man das der IO für ca. 15 Sekunden stoppt und danach normal weiter läuft:






Der erste Test ist also bestanden. Es gibt keine Unterbrechung beim Ausfall einer LUN bzw. eines Storage Systems. Die Zeit von 15 Sekunden halte ich persönlich für sehr gut. Ich kenne viele Lösungen die erst nach 30 Sekunden umschalten.

Als nächstes nehme ich das Volume Server2016-DR wieder online:

NIMBLE-DR:/# vol --online Server2016-DR

Das Lasterhaften auf Nimble-PROD ändert sich jetzt natürlich. Alle Extents die sich seit dem Ausfall geändert haben müssen jetzt von Nimble-PROD wieder auf Nimble-DR übertragen werden. Daher sehen wir auf Nimble-PROD hohe Leseraten mit niedrigen Schreibraten und ausschließlich Schreiben auf Nimble-DR.

Last auf Nimble-PROD:

 

Was ist ein Extent?

Jede Virtual Disk besteht aus vielen Extents die immer 1GB groß sind. Eine 2TB große Disk besteht also aus 2000 Extents.
Nach einem Ausfall werden alle Extents wiederhergestellt, die sich während dem Ausfall geändert haben.
D.h: Auch wenn sich nur ein Byte in einem Extent ändert, muss trotzdem 1GB wiederhergestellt werden.

Ich bin gespannt ob Microsoft die Größe dieser Extents unverändert lässt bis der Server 2016 auf den Markt kommt. Man könnte die Extents verkleinern, dadurch erhöht sich aber natürlich die Anzahl der Metadaten und Indexes die verwaltet werden müssen. Evtl. kann man die Größe der Extents irgendwann selbst auswählen.

Ich vermute, dass das Tiering von Storage Spaces ebenfalls auf den 1GB großen Extents basiert. 
Daher wird dieses Feature nach wie vor nicht effizient arbeiten. Generell wird das bei Tiering nie möglich sein. (Aber das ist ein ganz anderes Thema)

Fazit:

Während meines Tests konnte ich keine Probleme mit Storage Spaces und dem synchronen Spiegel feststellen. Das ganze scheint schon sehr stabil zu funktionieren. Nimble und Storage Spaces können wunderbar miteinander kombiniert werden. Die Vorteile von Nimble bleiben weiter bestehen.

Im Vergleich zum Storage, ist der Hypervisor/Host definitiv die bessere Schicht in einer Infrastruktur, um Blöcke synchron zu spiegeln. Die Gefahr eines Split-Brains sinkt, da Microsoft immer mit einer Quorum arbeitet.

Zweifelsohne ist die Applikation immer der beste Punkt um Daten synchron zu spiegeln. Aber so lange nicht alle Applikationen diese Funktion bieten, werden wir weiter auf Storageebene und hoffentlich bald auch auf Hypervisor/Host Ebene mit Server 2016 spiegeln.

Microsoft hätte mit dieser Funktion sicher ein gutes Argument gegen VMware im petto.
Komm schon VMware! Leg nach!