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!
