Virtual SAN 6.0 bringt mehr Flexibilität für VMs
26. August 2015
Mit der Vorstellung von vSphere Version 6 hat VMware auch für sein „Virtual SAN“-Konzept (VSAN 6.0) Modifikationen und Verbesserungen vorgestellt. Im Zusammenspiel mit den Virtual Volumes will der Marktführer im Bereich der Servervirtualisierung mehr Flexibilität für die virtuellen Maschinen (VMs) bereitstellen und die Nachteile der traditionellen Kopplung mit den LUN-basierten Storage-Architekturen überwinden.
Hersteller wie Datacore haben allerdings mit Lösungen wie SANsymphony (mittlerweile in Version 10, PSP 2, verfügbar) vorgelegt. Und auch Microsoft will beim Windows Server 2016 und der zugehörigen Hypervisor-Plattform Hyper-V deutliche Verbesserungen im Bereich der Speichervirtualisierung vorstellen.
VMware selbst bezeichnet sein Virtual SAN als eine hyperkonvergente softwaredefinierte Storage-Plattform, die komplett in die Hypervisor-Ebene (vSphere) integriert sei. Die Aufgabe eines Virtual SAN (VSAN) ist das Aneinanderfügen von Festplatten auf Hosts, die alle zu einem vSphere-Cluster gehören. Damit soll eine verteilte und gemeinsam nutzbare Storage-Lösung entstehen. Daraus lassen sich dann für die Betreiber viele Vorteile ableiten. Mithilfe der Verwaltungslösung von VMware, dem vCenter, lassen sich sehr schnell Speicherkapazitäten bereitstellen – und zwar erfolgt das bereits beim Anlegen von VMs. Zudem sollen sich richtlinienbasierende Vorgehensweisen definieren lassen – sprich eine Vereinfachung in Sachen Verwaltung bis hin zur Automatisierung von bestimmten Aufgaben sollte sich damit erzielen lassen. Das soll sich dann auch in reduzierten Betriebskosten für die Speicherinfrastruktur niederschlagen.
Mittlerweile gibt es – seit der Vorstellung von vSphere 6 – auch die Version 6 von VSAN. Gegenüber den Vorgängerversionen (5.5 und 5.6) bieten sich bei VSAN 6.0 zwei weitere Konfigurationsoptionen an: In einer hybriden Konfiguration lassen sich Flash-basierter Speicher, der in einem Server zum Einsatz kommt, und traditionelle, magnetische Festplattenlaufwerke verwenden. Dabei fungieren die Flash-Laufwerke im Server als eine Art Cache-Layer und sollen somit eine bessere Schreib-Leseleistungsfähigkeit bieten. Dagegen sollen die Festplattenlaufwerke die notwendige Speicherkapazität sowie die „Beständigkeit“ der Speicherinfrastruktur garantieren. In der „All Flash Configuration“ werden dagegen nur Flash-basierte Laufwerke unterstützt – sie sind sowohl für die Kapazität, als auch für das Caching zuständig.
Bei der Auswahl der passenden Hardware für VSAN 6.0 verweist VMware intensiv auf die Beachtung des VMware Compatibility Guide (VCG). Das bezieht sich auf die Server, die Speichercontroller im Host sowie auf die Flash-Laufwerke (angebunden über Schnittstellen wie SAS oder aber auf PCIe-Karten) und die Festplatten. Generell können sich die Anwender eigene Knoten für eine VSAN-Cluster (aus den im VCG aufgeführten Komponenten) zusammenstellen, oder aber sie nehmen Systeme aus der Liste von „Virtual SAN Ready Nodes“. Das sind bereits validierte Serverkonfigurationen, die von VMware und den Partnern zertifiziert sind. Eine weitere Option ist der Einsatz von EVO:Rail-Systemen. Dabei werden Compute-, Netzwerk- und Speicherressourcen in einer hyperkonvergenten Appliance kombiniert. Derartige Systeme sind ebenfalls von VMwares Partnern erhältlich.
Eine weitere Empfehlung für den Einsatz von VSAN mit vSphere lautet, dass man möglichst die neueste Softwareversion von vSphere (sowohl ESXi als auch vCenter Server) verwendet. Eine Aktualisierung von einer Betaversion von VSAN auf einen „GA-Version“ (General Availability) wird nicht unterstützt.
Möglichst gleichartige Hosts einsetzen
Zudem verweist man bei VMware auf „Balanced Configurations“. Darunter versteht man ESXi-Hostsysteme in einem Cluster, die mit sehr ähnlichen – oder sogar identischen – Ressourcen ausgestattet sind. Damit lassen sich im Betrieb dann auch die Arbeitslasten (die durch die VMs ins Spiel kommen) bestmöglich verteilen. Es besteht zwar die Möglichkeit, dass Hosts in einem Cluster, die keine Speicherressourcen bereitstellen (also reine Compute-Nodes), auch den VSAN-Datastore nutzen können. Doch damit handelt man sich ein Mehr an Verwaltungsaufgaben ein – daher empfiehlt VMware keine nicht ausbalancierten Konfigurationen zu verwenden.
Ein nützlicher Aspekt bei VSAN ist die Erweiterbarkeit: Diese Speicherlösung lässt sich recht einfach erweitern – etwa wenn man zusätzliche oder größere Festplatten in die ESXi-Hosts einbaut. Zum anderen gibt es auch die „Scale Out“-Option: Dabei werden einfach mehr Hostsysteme dem Cluster hinzugefügt. Für die Anwender bedeutet das, dass sie mit einer vergleichsweise kleinen Umgebung loslegen und später zusätzliche Hardware hinzufügen können. Doch um hier eine optimierte Konfiguration zu erhalten, müssen auch genügend Cachespeicher-Kapazitäten zum Einsatz kommen, zudem benötigt man genügend Speicherkapazität für die betreffenden Arbeitslasten. Das bedeutet für die Hostsysteme: Sie sollten über genügend freie Steckplätze für Festplattenerweiterungen verfügen und zudem sollten sich diese Disks auch leicht installieren lassen. Dabei darf der IT-Verantwortliche aber nicht vergessen, dass das Hinzufügen von reiner Kapazität – sei es für die Hybrid- oder die „All Flash“-Konfiguration – viel einfacher ist, als das Erhöhen der Größe der Flash-Geräte für den Cache-Layer.
Denn in diesem Fall ist meistens das Ersetzen des Flash-Laufwerks, das den Cache bildet, nötig. Denn es darf immer nur ein Flash-Laufwerk pro Disk-Gruppe zum Einsatz kommen. Einfacher ist das Erweitern, wenn man gleich eine komplette Disk-Gruppe – plus zugehörigen Flash-Laufwerk für den Cache – dazu nimmt. Der empfohlene Ausweg aus der Problematik: Einfach gleich zu Beginn mehr Flash für den Cache spendieren, als anfangs nötig ist und sich schon auf das künftige Wachstum einstellen. Doch das kostet dann entsprechend mehr.
Eine weitere Einschränkung ist die minimale Anzahl der ESXi-Hosts, die man für den Einsatz von VSAN benötigt. VMware gibt hier als Minimalwert drei ESXi-Hosts vor – doch diese Minimalkonfiguration hat noch ihre Nachteile: Wenn es im VSAN zu einem Ausfall kommt, wird versucht, die Komponenten einer VM erneut aufzubauen und zwar von den anderen Ressourcen innerhalb des bestehenden Clusters. Bei einem Cluster mit 3 Knoten, bei dem ein Knoten ausfällt, besteht keine Möglichkeit, die ausgefallenen Komponenten wiederherzustellen. Dasselbe Prinzip gilt auch für einen Host, der nicht ausfällt, aber der in den Wartungsmodus gebracht wird. Eine Option für die Wartungsarbeiten auf dem einen Host lautet: Alle Daten von diesem Host wegnehmen – sie förmlich zu evakuieren. Doch das lässt sich nur dann machen, wenn es vier oder mehr Knoten im Cluster gibt und wenn in dem Cluster genügend freie Kapazität vorliegt. Daher legt einem VMware nahe, man möge doch vier oder mehr Knoten einsetzen, um mehr Optionen im Bereich der Verfügbarkeit zu haben. Und zudem sollte genügend Kapazität im Cluster für derartige Betriebsfälle vorgesehen sein. Zudem gibt es auch eine Anzahl von maximal erlaubten ESXi-Knoten in einem VSAN-Cluster: 64 dürfen es nun sein (in der früheren Version 5.5 lag die Obergrenze noch bei 32 Knoten). Wer die volle Anzahl von Knoten einsetzen möchte, muss allerdings noch spezielle Angaben bei den Systemeinstellungen auf allen Hosts im Cluster machen.
Bei der maximalen Anzahl von VMs bei VSAN 6.0 sind ebenfalls neue Werte zu verzeichnen. VSAN 6.0 unterstützt bis zu 200 VMs pro ESXi-Host (in der Version 6.0). Dabei liegt das Maximum pro Cluster bei 6400 VMs. Bei Version 5.5 von VSAN galten noch 100 VMs pro Knoten im Cluster und maximal 3200 VMs in einem VSAN-Cluster mit maximal 32 Knoten/Hosts. Das sind allerdings nur die theoretischen Werte. Denn man sollte natürlich die verfügbaren Compute-Ressourcen einbeziehen. Damit ergibt sich dann oftmals eine deutlich geringere Anzahl von VMs, die im „realen Leben“ auf den Hosts laufen können.
Bei VSAN 6.0 ist es auch zu einer deutlichen Erhöhung bei der maximalen Größe einer VDMK-Datei gekommen. Lag bei VSAN 5.5 die maximale VDMK-Größe noch bei 2 TByte, so beträgt sie bei VSAN 6.0 nun 62 TByte. Allerdings werden Objekte – wie eine VDMK-Datei – bei VSAN 6.0 immer noch in 255 GByte großen Stripes angelegt. Wenn ein Administrator ein 62 TByte großes Objekt zum Einsatz bringt, werden dazu das ungefähr 500 Komponenten angelegt.
Unterschiede zwischen Hybrid und All Flash-Konfigurationen
Die besten Performance-Werte und den identischsten Durchsatz bringt die „All Flash“-Konfiguration bei VSAN 6.0. Das gilt für alle Arten von Arbeitslasten (Anwendungen in den VMs). Beide Konfigurationsoptionen – Hybrid und All Flash – bekommen dieselbe Empfehlung: 10 Prozent der verbrauchten Kapazität sollte für den Cache Layer reserviert sein. Doch in den beiden Optionen wird der Cache unterschiedlich eingesetzt.
Bei einem Hybrid-Cluster versucht der Cache-Algorithmus, sowohl die Lese- als auch die Schreib-Performance zu maximieren. 70 Prozent des verfügbaren Cachespeichers wird für das Abspeichern der am häufigsten gelesenen Diskblöcken verwendet. Damit wird der Zugriff auf die vergleichsweise langsamen Festplatten minimiert. Die restlichen 30 Prozent des Cachespeichers sind für die Schreiboperationen vorgesehen. Mehrere Schreiboperationen werden so gruppiert, dass sie möglichst sequentiell auf die sich drehenden Festplatten geschrieben werden, so dass möglichst wenig Zeit für die Positionierung des Schreibkopfes aufgewendet werden muss und man sozusagen den Schreibdurchsatz damit optimiert.
Bei den All Flash Clustern kommen zwei Typen von Flash-Speicher zum Einsatz: Ein schneller und langlebiger Schreib-Cache und ein großer, kosteneffektiverer Flashspeicher. Dabei werden 100 Prozent für den Schreib-Cache vorgesehen, denn die Lese-Performance aus dem großen Flash-Speicher ist in der Regel ausreichend. Resultat: Viel mehr Schreiboperationen werden im Cache abgelegt und erst dann in den „Kapazitäts-Layer“ geschrieben, wenn es unbedingt nötig ist. Das führt dann zu einer längeren Lebensdauer im der Kapazitäts-Flash-Schicht.
Im direkten Vergleich zu SANsymphony-V10 zeigt sich ein gravierender Unterschied: Bei Datacore wird ein eigens definierter DRAM-Bereich als Cachespeicher verwendet, ehe auf die Festplatten oder SSDs zugegriffen wird. Das erhöht die Durchsatzwerte – solange der Cache für das Schreiben oder Lesen ausreicht – um mehrstellige Faktoren. Datacore gibt an, dass unabhängige Untersuchungen klar zeigen: Der Einsatz eines großen DRAM-Caches, der direkt an SATA-Festplatten angebunden ist, bietet bei einer Schreibintensiven Arbeitslast auf ein 20-GByte-Volume mit 36.000 IOPS eine mehr als dreifache Verbesserung als der direkte Zugriff auf SSD-Laufwerke (etwa 10.000 IOPS).
Doch bei VSAN 6.0 sind noch weitere Einschränkungen zu beachten: Bei einer All Flash-Konfiguration müssen schnelle Netzwerkkarten für den Datenverkehr zum Speicher zum Einsatz kommen: 10 GBit/s sind nötig, mit den 1 GBit/s-Karten funktioniert „All Flash“ nicht. Werden 1-GBit/s-Netzwerkkarten verwendet, müssen diese NICs dem VSAN-Verkehr vorbehalten sein. Die schnelleren NICs (mit 10 GBit/s) können dagegen für verschiedenen Netzwerkverkehr verwendet werden. Man könnte darüber zum Beispiel auch den vMotion-Verkehr fließen lassen. Die maximale Anzahl von „All Flash Knoten“ in einer derartigen Konfiguration ist 64. Zudem sollte man bei der Planung einer All Flash Konfiguration sich detaillierte Gedanken über die Lebensdauer der Flash-Speicher machen.
