StorMagic SvSAN erlaubt den Aufbau eines hochverfügbaren virtuellen Speichersystems mit nur zwei physischen Servern, das eine fast hundertprozentige Betriebszeit ohne einen Single-Point-of-Failure gewährleistet. Basis sind hierbei konventionelle x86-Server, die je nach Kapazitätsbedarf mit ausreichend Festplatten oder (NVMe-)SSDs bestückt sind. Davon werden zwei – oder für Hochverfügbarkeit auch während einer Wartung drei Server – mit Hypervisor als Teil eines Virtualisierungs-clusters benötigt.

Auf dieser Plattform mit darauf laufenden VMs mit der in unserem Test genauer betrachteten SvSAN-Software lässt sich dann ein hochverfügbarer gemeinsamer Speicher konfigurieren, bei dem die Daten aktiv-synchron zwischen den beteiligten Servern gespiegelt werden. Fällt einer dieser Hosts aus oder muss beispielsweise für eine Wartung offline genommen werden, arbeiten der oder die verbleibenden weiter, sodass die Datenspeicher ohne Unterbrechung erreichbar sind und für die nutzenden VMs keine Ausfallzeiten entstehen.

Wie das Konzept im Detail funktioniert, werden wir im weiteren Verlauf genauer beschreiben. Dabei konzentrieren wir uns auf die Konfiguration mit zwei Servern. Der Dreier-Betrieb hat wie erwähnt nur den Vorteil, dass einer in Wartung genommen werden kann und dann währenddessen eine Redundanz besteht, was beim Zweier-Betrieb nicht der Fall ist.

Eine optional nutzbare Witness-Instanz, auch als Quorum bezeichnet, entscheidet bei einem Problem zwischen den beteiligten Servern, welches System das aktive bleibt. Der Witness kann dazu auf einem physischen Server laufen oder ebenfalls als VM, aber stets außerhalb des zugehörigen SvSAN-Clusters.

StorMagic SvSAN unterstützt als Hypervisor wahlweise VMware vSphere, Microsoft Hyper-V sowie Linux-KVM-Distributionen. Entsprechend muss die eingesetzte Hardware für den gewünschten Hypervisor freigegeben sein. Ein Vorteil der breiten Unterstützung ist, dass der Administrator jeweils die für ihn bevorzugte Umgebung wählen kann. Er sollte sich nach der Hypervisor-Wahl bei der weiteren Planung strikt an die Herstellervorgaben halten, um am Ende einen robusten und performanten Speicher für den beabsichtigten Einsatz zu erhalten.

Für unseren Test kam eine vSphere-Umgebung mit drei ähnlichen, aber nicht absolut identischen ESXi-Servern zum Einsatz. Auf zweien wollten wir SvSAN ein- richten und den Speicher dann auch am dritten für VMs bereitstellen. Aufgrund der Verwendung von vSphere 6.7 als Hypervisor mussten wir die dazu kompatible SvSAN-Version 6.2 einsetzen. Die aktuelle Version ist 6.3 und setzt dabei mindestens vSphere 7.0 voraus. Eine Kompatibilitätsmatrix des Herstellers listet die zulässigen Kombinationen auf. Die funktionalen Unterschiede zwischen den genannten Versionen sind nur gering.

Bezüglich des eigentlichen Designs eines SvSAN-Clusters gibt es mehrere Möglichkeiten, um das Optimum aus Kapazität und Performance zu erreichen. Idealerweise setzt eine SvSAN-Installation auf mindestens zwei ESXi-Servern mit identischer Hardwareausstattung auf, die sich in einem vSphere Datacenter und einem darin angelegten Cluster-Objekt befinden. SvSAN selbst benötigt eigentlich keinen Cluster, dieser wird aber für VMware HA benötigt. Außerdem muss DRS aktiviert sein.

Auf beiden ESXi-Servern wird zuerst eine SvSAN-VM eingerichtet, im Weiteren als VSA (Virtual Server Appliance) bezeichnet. Diese lässt sich je nach Bedarf Speicherkapazität des jeweiligen ESX-Hosts zuweisen. Der Speicher kann wahlweise als Raw Device Mapping (RDM) oder als normale virtuelle Festplatte (VMDK) bereitgestellt werden, wobei RDM die bessere Performance verspricht, weil hier eine zusätzliche Dateisystemebene wegfällt und der Speicher direkt an die VSA durchgereicht wird. Über RAID-Controller in den Hosts lässt sich die Last auf viele Spindeln verteilen, sofern überhaupt noch Festplatten zum Einsatz kommen. In diesem Fall kann der Admin aber durch zusätzliche SSDs ein Lese- und Schreib-Caching einrichten. Der Hersteller empfiehlt hier ein SSD/HDD-Verhältnis von 1-zu-10. Auch ein zusätzliches Caching im Arbeitsspeicher der VSA ist an dieser Stelle verfügbar.

In unserer Testumgebung war zum Einstieg auf dem vCenter-Server das StorMagic-vCenter-Plug-in zu installieren, das die vCenter-GUI erweitert und aus der heraus die VSA-Einrichtung erfolgt. Ab der Version 6.3 ist das Plug-in durch eine eigene kleine VM ersetzt, sodass dann vCenter- und SvSAN-Management getrennt sind. Das hat den Vorteil, dass nicht bei jedem vCenter-Update das Plug-in erneut zu installieren ist, sondern sich die VM unverändert weiter nutzen lässt. Updates des Hypervisors und der SvSAN-Software sind dadurch entkoppelt.

Neben der Bereitstellung der passenden Speicherkapazität auf den Datenträgern spielt die Netzwerkkonfiguration eine wichtige Rolle. Selbst wenn als Minimal-anforderung eine einzelne 1-GBit/s-Netzwerkverbindung angegeben ist, sind für eine produktive Umgebung mindestens drei Verbindungen zwischen den Hosts mit den VSAs zu empfehlen. Die erste ist das Managementnetzwerk. Hier reicht eine GBit-Anbindung durchaus aus und diese kann auch für andere Zwecke verwendet werden wie den vCenter-Zugriff. Das StorMagic-Plug-in beziehungsweise die Management-VM nutzt dieses Netzwerk für das Ausrollen der VSAs sowie für die Kommunikation zur Witness-VM. Idealerweise ist das Managementnetzwerk allerdings auch doppelt ausgelegt.

Zwei weitere Netzwerkverbindungen zwischen den beiden Hosts mit den VSAs sollten am besten als Direktverbindung ohne zwischengeschalteten Switch realisiert und möglichst performant sein, also eine Bandbreite von mindestens 10 GBit/s besitzen. Hierüber laufen die synchrone Datenspiegelung sowie der iSCSI-Verkehr. Die Nutzung von iSCSI als Protokoll für den Datentransfer in Verbindung mit Multipathing über die redundanten Pfade ermöglicht bei Ausfall eines Systems einen unterbrechungsfreien Failover. Bei entsprechend mehrpfadigem Netzwerkdesign lässt sich mit vergleichsweise einfachen Mitteln ein hochverfügbarer Datenspeicher ohne SPoF (Single-Point-of-Failure) einrichten.

Auf den Hosts ist der Datenspeicher demnach als iSCSI-Datastore sichtbar und kann genauso wie ein lokaler Datastore bei der Einrichtung von VMs Verwendung finden. Des Weiteren ist der Datenspeicher nicht nur auf den beiden Hosts mit den VSAs nutzbar, sondern er kann auch an weitere Hosts im vCenter angebunden werden. Voraussetzung dafür ist allerdings, dass auch diese Hosts am besten mit 10 GBit/s oder mehr verbunden sind, um den Datastore performant erreichen zu können. Die gesamte Konfiguration erfolgt je nach SvSAN-Version über das StorMagic-Plug-in oder über die Management-VM.

Nachdem bei unserem Test wie schon erwähnt die Version 6.2 zum Einsatz kam, mussten wir zuerst das StorMagic-Plug-in auf unserer vCenter-Appliance installieren. Dazu aktivierten wir in der Appliance SSH, kopierten dann das Installationspaket per WinSCP und führten es aus. Dies klappte problemlos und wir konnten anschließend in der vCenter-GUI auf das Plug-in zugreifen. Die Einstiegsseite ist sehr übersichtlich und auf vier Aufgaben beschränkt: Verteilung einer VSA auf einem Host, Verteilung mehrerer VSAs auf mehreren Hosts, Einrichten einer Witness-VM und schließlich Erstellen eines verteilten (gespiegelten) Datastores. In jedem Fall startet ein komfortabler Assistent, der alle Parameter und Optionen abfragt und die Einrichtung durchführt.

Nachdem unsere ESXi-Hosts mit SSDs bestückt waren, installierten wir auf zweien eine VSA und verzichteten dabei auf die zusätzlichen Caching-Optionen per SSD oder die Zuweisung von Arbeitsspeicher. Für die Größe der Daten-LUN für den Speicherpool gaben wir auf beiden Systemen 300 GByte an. Der Assistent ermöglicht das Anlegen eines ersten verteilten Datastores auf der Daten-LUN, weitere lassen sich dann wie schon beschrieben über den Menüpunkt auf der Einstiegsseite des Plug-ins anlegen. Auf unserem dritten ESXi-Host richteten wir noch die Witness-VM ein.

Nachdem die Hosts in unserer Testumgebung jeweils mit einer 1-GBit/s- sowie einer 10-GBit/s-Netzwerkkarte ausgestattet waren, entsprach dies nicht vollständig der beschriebenen Empfehlung für den redundanten Betrieb. Auch war die 10-GBit/s-Verbindung nicht direkt verkabelt, sondern über einen Switch. Das alles wurde dennoch vom Installationsskript problemlos akzeptiert und die beiden VSAs fehlerfrei eingerichtet. Diese sowie der eingerichtete Speicher waren dann im Plug-in für das weitere Management sichtbar und wir konnten eine Warnung sehen, dass die Anzahl der parallelen Pfade geringer war als empfohlen.

Zusätzlich zum ersten, initial angelegten Datastore mit 80 GByte nutzten wir anschließend das Skript auf der Einstiegsseite des Plug-ins, um einen weiteren Speicherbereich mit 75 GByte anzulegen. Hier konnten wir gut erkennen, dass nach dem Anlegen eine Synchronisation stattfindet, um die Spiegelung zwischen den beiden VSAs einzurichten. Diese erfolgt stets auf der Datastore-Ebene und nicht auf Basis der darunter liegenden Datenpools.

Das Skript fragt unter anderem die Hosts ab, auf denen der Datastore per iSCSI präsentiert werden soll. So ist es sehr komfortabel möglich, einen Datastore nicht nur auf den beiden Hosts mit den VSAs, sondern auch oder nur auf anderen Hosts zu präsentieren. Je nach Konzept besteht damit die Option, dedizierte Hosts nur für die Verwendung als SvSAN-Speicher zu definieren, auf denen außer der VSA keine sonstigen VMs laufen, um dann den gesamten gespiegelten Speicher anderen Hosts für den VM-Betrieb zur Verfügung zu stellen.

Beim Anlegen eines Datastore existiert die Möglichkeit zur Verschlüsselung, wozu allerdings jede VSA einen zugewiesenen Key-Management-Server benötigt. Hierzu bietet StorMagic ein eigenes Produkt an, den SvKMS Key Management Server. Hier empfiehlt es sich, im Vorfeld den Bedarf genau zu analysieren und ein passendes Konzept zu entwerfen.

Insgesamt hat uns bei der gesamten Einrichtungsphase die sehr gute Unterstützung durch die komfortablen Assistenten positiv überrascht, nachdem wir zu Anfang des Tests eher etwas skeptisch waren, ob wir das Konstrukt überhaupt zum Laufen bekommen, da unsere Hosts und deren Vernetzung nicht ganz der Empfehlung entsprachen.

Neben der Beschreibung der Einrichtung stellt StorMagic einen Evaluierungs-Guide bereit, der diverse Testszenarien beschreibt, um das Verhalten der Lösung besser kennenzulernen. Die Anleitung ist in zwei Rubriken unterteilt. Die erste trägt die Bezeichnung "lights on" und beschreibt einfache Ausfälle, bei denen eine Test-VM auf dem SvSAN-Datastore aufgrund der Systemredundanz kontinuierlich weiterläuft. Die zweite Rubrik "lights off" beschreibt doppelte Ausfälle wie einen Stromausfall beider Hosts, sodass die VM außer Betrieb geht. Ein weiteres Kapitel dreht sich um die Verschlüsselung, die extra zu lizenzieren ist.

Die einzelnen Szenarien sind im Evaluierungs-Guide in einer tabellarischen Übersicht beschrieben, mitsamt den erforderlichen Arbeitsschritten sowie den zu erwartenden Resultaten. Im Test haben wir uns vor allem auf die erste Rubrik konzentriert und konnten gut beobachten, dass unsere verwendete Test-VM in allen Fällen ohne Unterbrechung weiterlief. Bei diesen Durchläufen ließ sich auch das integrierte Monitoring recht gut nachvollziehen, wobei hier je nach Umgebung verschiedene Optionen zur Verfügung stehen. So unterstützt SvSAN eine Benachrichtigung per E-Mail oder SNMP. Weiterhin können in einer Hyper-V-Umgebung Meldungen per SNMP an Microsofts Operation Manager geschickt werden oder in einer VMware-Umgebung an den vCenter-Server.

Bezüglich eines direkten Zugriffs erweist sich eine VSA als erfreulich kommunikativ, was bei Problemen eine Analyse sehr erleichtert. So besitzt jede VSA eine textbasierte Konsole, über die sich die wichtigsten Einstellungen (Status, Netzwerk, Routing, Passwort Setzen, Upgrade) einsehen und anpassen lassen. Per Browser und Eingabe der IP-Adresse der VSA gelangt der Administrator nach Anmeldung auf eine Web-GUI mit mehreren Registerblättern, um auch hier alle möglichen Einstellungen kontrollieren sowie anpassen zu können. Hier sieht er die zugehörigen Speicherpools, die iSCSI-Informationen sowie weitere zum Cluster gehörige VSAs und beteiligte Witness-Hosts.

Beim Durchschauen aller dieser Möglichkeiten konnten wir uns überzeugen, dass SvSAN erfreulich transparent aufgebaut ist und der Administrator nicht vor einer Black Box sitzt, die ihn bei Problemen verzweifeln lässt.

Mit StorMagic SvSAN kann ein Administrator wahlweise unter VMware, Hyper-V und KVM mit Hilfe von Standardhardware einen ausfallsicheren und hochverfügbaren Storage konfigurieren, ohne dafür in teure SAN-Komponenten und dedizierte Speichersysteme investieren zu müssen. So entsteht ein synchron gespiegelter, per iSCSI bereitgestellter Speicher, der beim Ausfall einzelner Komponenten unterbrechungsfrei verfügbar ist. Im Test konnte SvSAN durch diverse komfortable Assistenten überzeugen, die den Aufbau eines Clusters inklusive Witness-Instanz sehr vereinfachten. Beim Durchspielen diverser Ausfallszenarien war der Speicher durchgängig erreichbar, erst bei Doppelfehlern kam es wie erwartet zu Ausfällen.

Sehr gut geeignet ist SvSAN für Umgebungen, in denen eine hohe System- und Datenverfügbarkeit gefordert ist. Je nach Netzwerklatenz lassen sich die Informationen über Brandabschnitte oder gar Standorte hinweg spiegeln und verteilen. Die Lizenzierung erfolgt pro Knoten und entsprechend der benötigten Nettokapazität. Die Lizenzkosten sind zwar nicht unbedingt ein Schnäppchen, aber immer noch weitaus günstiger als der Einstieg in die physische SAN-Welt. StorMagic wirbt zudem damit, dass es nach wie vor Kauflizenzen gibt und nicht nur ein mittlerweile von vielen Herstellern bevorzugtes Mietmodell, sodass sich nach dem initialen Kauf die Folgekosten für den Support in Grenzen halten. Interessierte Administratoren können eine 15-Tage-Testlizenz mit 2 TByte Kapazität anfordern.