Hyperkonvergenz für kleine Budgets

von Jürgen Heyer

Die neue Preis- und Lizenzpolitik für VMware-Produkte hat viele Nutzer dazu veranlasst, sich auf die Suche nach einem alternativen und kostengünstigeren Hypervisor zu begeben. Auch soll sich die Umgebung im Idealfall mit einfachen, günstigen Serverkomponenten aufbauen lassen, optional hochverfügbar und zudem flexibel skalierbar. Diese Bedingungen erfüllt SvHCI von StorMagic. Im Test haben uns die überschaubaren Hardwareanforderungen und das schnelle Failover gut gefallen.

In der März-Ausgabe 2024 hatten wir bereits ein Produkt von StorMagic im Test: SvSAN ermöglicht den Aufbau eines hochverfügbaren virtuellen Speichersystems mit nur zwei physischen Servern, das eine fast hundertprozentige Betriebszeit ohne einen einzigen Ausfallpunkt gewährleistet. Nachdem es sich hierbei um eine reine Speicherbereitstellung handelt, bedarf es für eine Virtualisierung noch eines zusätzlichen Hypervisors wie VMware vSphere oder Micro- soft Hyper-V.

Das diesmal unter die Lupe genommene SvHCI geht einen Schritt weiter und beinhaltet neben der SvSAN-Funktionalität auch einen eigenen Hypervisor sowie ein virtuelles Netzwerk, basierend auf der Open-Source-Technologie KVM/QEMU und Open vSwitch, sodass für den Aufbau einer Plattform zur Virtualisierung keine weitere Software benötigt wird.

Möglich ist auch die kombinierte Nutzung beider Funktionen, also der Betrieb von VMs auf einem oder zwei SvHCI-Hosts im Cluster sowie das Bereitstellen von hochverfügbarem Speicher via iSCSI für die Nutzung in Verbindung mit einem der eingangs genannten Hypervisoren.

Basis von SvHCI sind konventionelle x86-Server, die je nach Kapazitätsbedarf mit ausreichend Festplatten oder (NVMe)-SSDs bestückt sind. Für einen High-Availability-Betrieb bilden zwei Server einen Cluster, auf dem aktuell bis zu 50 VMs hochverfügbar laufen können oder bis zu 100 VMs ohne HA-Funktion. Möglich ist auch ein Mischbetrieb von VMs mit und ohne Hochverfügbarkeit.

Eine zusätzliche Witness-Instanz, auch als Quorum bezeichnet, entscheidet bei einem Problem zwischen den beiden Hosts, welches System das Aktive bleibt. Die Witness kann dazu als Dienst auf einem physischen Windows-System laufen, in einer VMware Appliance, unter Ubuntu, Debian, CentOS, Alma Linux, RHEL oder auf einem Raspberry Pi 4, aber stets außerhalb des zugehörigen SvHCI-Clusters.

Einstieg mit Minimal- konfiguration möglich

In unserem Test konzentrieren wir uns auf die vollumfängliche SvHCI-Funktion. Dass ein SvHCI-Cluster analog zum Produkt SvSAN auch iSCSI-Speicher für einen externen, anderen Hypervisor zur Verfügung stellen kann, betrachten wir hier nicht weiter. Die SvHCI-Lizenz deckt beide Verwendungen ab, entscheidend ist allein die insgesamt verwaltete Speicherkapazität.

In einer Minimalkonfiguration für sehr kleine Umgebungen reicht es, SvHCI nur auf einem Hardwaresystem einzurichten, dann folglich ohne HA-Funktion. Bezüglich der Kompatibilität gibt es eine HCL, die Serversysteme von Dell, HPE, Intel, Lenovo, RCF Innovations sowie Supermicro auflistet, weiterhin diverse Netzwerkkarten und Speichercontroller. Tatsächlich aber wird weitaus mehr Hardware unterstützt, was wir im Test sehr positiv bemerkten.

So verwendeten wir zwei herkömmliche Desktopsysteme mit teils unterschiedlicher Ausstattung hinsichtlich CPU und RAM-Bestückung sowie des verbauten SATA-Controllers. Nur die verwendeten Netzwerkkarten von Intel, jeweils einmal 1-GbE sowie einmal 10-GbE, waren identisch. Zusätzlich wurden auf beiden Systemen die Onboard-Netzwerkports mit Realtek-Controllern erkannt, was auch hier eine breite Unterstützung signalisiert. Mit diesen beiden Desktop-PCs wollten wir einen HA-tauglichen SvHCI-Cluster aufbauen, was fast reibungslos funktionierte.

Zum Testzeitpunkt war SvHCI in der Version 2.0 gerade neu veröffentlicht worden. Die Installationsquelle liefert StorMagic als gepacktes Datenträgerimage (ISO), gut 300 MByte groß, das wir auf eine CD brannten. Beide PC-Systeme hatten wir mit einer kleineren Festplatte (160 GByte) für das Betriebssystem und einer SSD mit 1 TByte Kapazität für die Daten beziehungsweise die auf dem Cluster laufenden VMs ausgestattet. Beim Booten von der CD erschien ein Menü mit vier Setupoptionen, von denen die beiden ersten, die manuelle sowie automatische Installation, die wichtigsten waren. Auf beiden Systemen wählten wir zuerst das automatische Setup, bei dem wirklich alle Schritte skriptgesteuert ablaufen und keinerlei weitere Angaben erforderlich sind.

Bei unserem ersten System war dieser Weg erfolgreich und wir konnten nach einem Neustart auf dem Startbildschirm die per DHCP vergebene IP-Adresse ablesen. Der Startscreen von SvHCI ist informativ und übersichtlich aufgebaut. Über ein Menü kann der Administrator alle möglichen Informationen einsehen und auch Änderungen durchführen. Trotzdem dürfte dieser nur selten benötigt werden, denn die eigentliche Administration erfolgt über die grafische SvHCI-Oberfläche in einem Browser, zu dem der Admin über die vergebene IP-Adresse gelangt.

Beim zweiten Server wählte die automatische Installation fälschlicherweise die nicht angeschlossene Onboard-Netzwerkkarte für das Management des SvHCI-Hosts aus, sodass das System schlussendlich ohne Netzanbindung dastand. Daher führten wir die Installation erneut durch, diesmal manuell. Jetzt erschienen einige Abfragen, um die Bootplatte und eben die Netzwerkkarte auszuwählen, sodass wir hier eingreifen konnten.

Wahlweise Single- oder Cluster-Betrieb

Nach der Bare-Metal-Einrichtung von SvHCI hängen die nächsten Schritte ein wenig davon ab, ob es sich um einen einzigen Host im Singlebetrieb handelt oder um zwei Hosts als Cluster. Bei einem einzelnen Host ist die weitere Konfiguration sehr einfach, denn der Administrator muss nur anhand der verfügbaren Devices (Festplatten, SSD, NVMe) einen oder mehrere Pools bilden, als Basis für die Datenträger der virtuellen Maschinen. Dabei stehen die RAID-Level JBOD sowie RAID 0, 1 und 10 zur Verfügung, um in Richtung Performance und/oder Datenredundanz zu optimieren. Gerade bei einem Singlebetrieb bieten sich hier ein RAID 1 oder 10 an, um innerhalb des Systems die Daten doppelt zu halten und nicht durch den Ausfall eines Datenträgers die VMs zu verlieren.

Auf einem Pool kann der Administrator virtuelle Laufwerke anlegen, entweder direkt für eine externe Bereitstellung (SvSAN-Funktionalität) oder in Verbindung mit der Einrichtung einer virtuellen Maschine. Der Zugriff auf ein Laufwerk erfolgt per iSCSI, daher wird ein solches für eine externe Bereitstellung als Target bezeichnet. Optional lassen sich hier Caching und Verschlüsselung aktivieren, in einem Zwei-Knoten-Cluster auch eine Spiegelung, also eine synchrone Datenreplizierung zwischen den beiden enthaltenen Hosts.

Vor dem Anlegen einer virtuellen Maschine ist zuerst das Netzwerk zu konfigurieren. Das Setup hat für den Hostzugriff eine Netzwerkkarte, angebunden mit einem virtuellen Switch und einem Managementnetz. Sofern weitere Netzwerkkarten vorhanden sind, um beispielsweise den iSCSI-Datenverkehr sowie die VM-Kommunikation zu trennen, sind weitere Interfaces und virtuelle Switches anzulegen und zuzuordnen. Für die Einrichtung einer virtuellen Maschine ist mindestens eine Portgruppe zu konfigurieren, um diese einer VM zuzuweisen. VLANs zur Trennung des Datenverkehrs werden unterstützt. Eine Bandbreite von 1 GBit/s ist bei wenigen VMs ausreichend, bei mehr oder intensiverer externer Bereitstellung von iSCSI-Targets sind 10 GBit/s zu empfehlen.

Auf Wunsch VM-Spiegelung

Bei einem Cluster mit zwei Hosts ist der zweite identisch mit den gleichen Netzwerkbezeichnungen einzurichten, vor allem mit gleichnamigen Portgruppen, damit der VM-Failover funktioniert. Stehen die beiden Hosts nicht weit voneinander entfernt, ist auch eine Direktverbindung zweier Netzwerkkarten möglich, optional redundante Anbindungen sorgen zudem für mehr Ausfallsicherheit.

Waren zwei weitgehend identische Hosts bezüglich Pools und Netzwerk eingerichtet, konnten wir diese anschließend zu einem Cluster verbinden, indem wir jeweils den anderen Partner hinzufügten und zur Vermeidung einer Split-Brain-Situation ein Quorum definierten – hier als Witness bezeichnet. Wie bereits erwähnt kann es sich dabei um eine VM oder einen Dienst handeln, der außerhalb des Clusters laufen muss. Die entsprechenden Sources lassen sich bei StorMagic herunterladen. Für unseren Test installierten wir den sogenannten StorMagic Witness Service auf einer Windows-Workstation.

Ist der Cluster eingerichtet, stehen dem Administrator anschließend mehr Funktionen zur Verfügung. So kann er beim Anlegen einer VM individuell festlegen, ob diese mit oder ohne Spiegelung laufen soll. Für eine Spiegelung muss er die Option "Protected" auswählen und dann für beide Hosts im Cluster festlegen, auf welchem Pool die zugehörigen Laufwerke gleicher Größe erstellt werden sollen.

Anschließend findet eine initiale Synchronisation statt, um die Spiegelung einzurichten. Während dies je nach Laufwerksgröße einige Minuten dauern kann, fiel uns auf, dass bei späteren Ausfalltests eines Hosts oder einer Verbindung das Nachsynchronisieren sehr schnell vonstattenging. Hintergrund ist, dass sich die Software für jede abgesicherte VM merkt, welche Blöcke im Dateisystem nach einer Verbindungsunterbrechung zur Spiegelseite verändert wurden und nach dem Wiederherstellen der Kommunikation nur diese synchronisiert, nicht das gesamte Laufwerk.

Neben einem oder mehreren Laufwerken sind noch mindestens eine Netzwerk-Portgruppe zuzuweisen sowie ein virtuelles CD-ROM-Laufwerk. Letzteres wird benötigt, um die Installationsquellen anzubinden, worauf wir nachfolgend noch genauer eingehen.

Überschaubare Betriebssystem-Unterstützung

Für unsere weiteren Tests legten wir nun einige gespiegelte sowie ungespiegelte VMs an. Zu beachten ist, dass ein Overcommitment, also eine Überbuchung von CPU und RAM derzeit nicht möglich ist. Allerdings arbeiten die Entwickler daran, um dies in einer zukünftigen Version anzubieten.

Die aktuelle Betriebssystem-Unterstützung für eine SvHCI-VM ist im Moment noch recht überschaubar. Bei Windows werden nur die Serverversionen ab 2019 angeboten, keine Windows-Workstation. Außerdem stehen einige Linux-Distributionen zur Auswahl. Für den Upload einer Installationsquelle wird diese als ISO-Datei benötigt. Der Upload erfolgt wahlweise nur auf einen Host oder gespiegelt auf beide. Letzteres hat den Vorteil, dass die hochgeladenen Daten dann auf beiden Hosts zur Verfügung stehen. Die Verwaltung geschieht analog den Laufwerken für SvSAN sowie denen für die SvHCI-VMs als iSCSI-Target. Für den Zugriff wiesen wir die hochgeladene ISO-Datei dem entsprechenden CD-ROM zu, um so in der betreffenden VM darauf zuzugreifen.

Für unseren Test führten wir die beschriebenen Schritte aus, um Windows Server 2019 zu installieren. Wie auch sonst üblich bootete SvHCI nach dem Start der VM vom ISO-Image und nach dem Drücken einer Taste lief das Windows-Setup ab. Allerdings wurde das zugeteilte virtuelle Laufwerk nicht als Installationsziel angeboten. Eine Nachfrage beim Support, der uns einen Link zu einem VirtIO-Treiber schickte, brachte uns weiter. Dort konnten wir eine ISO-Datei mit entsprechenden Treibern herunterladen. Nachdem wir auch diese ISO- Datei via virtuelles CD-ROM an die VM gehängt hatten, konnten wir im Windows-Setup den Treiber von dort ergänzen und dann die Installation komplett durchführen. Seit Windows Server 2022 ist der VirtIO-Treiber fester Bestandteil von Windows und muss nicht mehr manuell ergänzt werden.

Die Remoteverbindung zu den virtuellen Maschinen erfolgt über den integrierten Open-Source-VNC-Client noVNC, der nur im Browser läuft und keiner Installationssoftware oder eines Plug-ins bedarf.

Failover in Windeseile

Während es bei einer ungespiegelten VM selbstverständlich ist, dass sich diese nur über das WebGUI des bereitstellenden Hosts konfigurieren und steuern lässt, ist dieses bei einer gespiegelten VM nicht anders. Nur eine Migration lässt sich auch vom anderen Host anstoßen, um sich die VM auf das System zu holen.

StorMagic wirbt bei SvHCI mit deutlich schnelleren Failover-Zeiten im Vergleich zu den Mitbewerbern, was wir natürlich ausprobieren wollten, und zwar in zwei unterschiedlichen Szenarien. In der ersten Situation wollten wir sehen, ob es bei einer geplanten Migration zu einem Aussetzer kommt, in der zweiten schalteten wir den bereitstellenden Host hart aus.

Bei einer geplanten Migration war die VM während der ganzen Zeit arbeitsfähig, es handelt sich um eine sogenannte Livemigration. Sie dauerte für unsere VM mit zwei CPUs und 8 GByte Arbeitsspeicher rund drei Minuten. Während der Migration erhöhten sich die Ping-Antwortzeiten von vorher einer Millisekunde auf bis zu elf Millisekunden. Drei bis vier Ping-Antworten kurz vor dem Abschluss der Migration dauerten mit bis zu 297 Millisekunden besonders lang, es kam aber zu keinem Aussetzer und die Applikationen in der VM liefen unterbrechungsfrei weiter.

Beim harten Ausschalten eines Hosts wurden die darauf laufenden VMs zwangsweise beendet und der verbleibende Host startete die gespiegelten VMs sofort nach Feststellen des Ausfalls des Partners. Hier kam es zu einer kurzen Unterbrechung, die in unserer Testumgebung allerdings nur fünf Aussetzer beim Ping verursachten. Das dürfte bei einer größeren VM wohl minimal länger dauern. Auch müssen die Applikationen neu gestartet werden, aber insgesamt hat uns dieses schnelle Anlaufen sehr gut gefallen.

Sofern Administratoren existierende VMs von einem anderen Hypervisor zu SvHCI übertragen wollen, ist das grundsätzlich möglich. Vor allem für VMware sind verschiedene Wege beschrieben, mit einer schrittweisen Vorgehensweise, die einzuhalten ist.

Wichtig sind je nach Situation spezielle Vorarbeiten, um die notwendigen Treiber (VMXNET3 und PVSCSI) vorab in die VM zu bringen. Dies geschieht zum Beispiel durch die Installation der VMware Tools. Anschließend mussten wir in der VM-Konfiguration auf die entsprechenden Treiber umstellen, erst dann ließ sich die eigentliche Übertragung starten. Eine Möglichkeit dazu ist das SvHCI-Import-Utility, aber es gibt auch andere Optionen, die in diversen Dokumenten der Knowledge Base beschrieben werden.

Mehr Komfort durch zentrale Anlaufstelle

Sofern in einem Unternehmen ein SvHCI-Cluster für den VM-Betrieb nicht ausreicht, wird die Administration über die jeweiligen WebGUIs der Hosts schnell unübersichtlich und zeitaufwändig. Das hat StorMagic erkannt und als Ausweg Edge Control geschaffen. Hierbei handelt es sich um einen SaaS-Ansatz für eine zentrale Administration mehrerer SvHCI-Cluster sowie SvSAN-Installationen.

Als Verbindung zwischen der SaaS-Umgebung und den Clustern im jeweiligen Unternehmensnetzwerk fungiert ein sogenannter Edge Orchestrator quasi als lokales Gateway. Für eine möglichst hohe Sicherheit verlangt Edge Control zwingend eine Zweifaktor-Authentifizierung beispielsweise anhand des Google Authenticator oder eines vergleichbaren Tools. Gleich zu Beginn der Edge-Control-Einrichtung erscheint ein QR-Code.

StorMagic stellt einen fertigen Orchestrator als OVA-Datei für vSphere bereit. Hierbei handelt es sich um eine virtuelle Maschine mit Ubuntu und einem Docker-Container mit der Orchestrator-Applikation. Die VM benötigt vier CPUs, 8 GByte RAM und 16 GByte Plattenkapazität.

Bezogen auf den Einsatz in Verbindung mit SvSAN ist dieses Design durchaus sinnvoll, widerspricht aber unserer Ansicht nach bei SvHCI der dortigen Absicht, einen anderen, teureren Hypervisor zu ersetzen. Zumindest lässt sich Hyper-V statt vSphere verwenden, indem der Administrator darauf eine Ubuntu-VM installiert, anschließend Docker und dann einen von StorMagic bereitgestellten Docker-Container aufspielt.

In unserer Testumgebung nutzten wir die vorbereitete VM auf einem ESXi-Server. Deren Einrichtung bereitete keine Probleme, es waren nur die IP-Parameter anzugeben. Um Edge Control einzusetzen, muss der Administrator im Vorfeld bei StorMagic eine Tenancy beantragen, quasi einen Eintrag in der SaaS-Umgebung. Dann erhält er eine Subskriptions-E-Mail mit einem API-Key.

Anschließend galt es, auf dem Orchestrator mittels Putty oder einem anderen SSH-Client einige Kommandozeilenbefehle abzusetzen, um die Orchestrator-VM über den API-Key der Tenancy zuzuordnen und um alle SvHCI-Hosts durch Angabe des DNS-Namens oder der IP-Adresse sowie des Admin-Passworts zu erfassen. Für die Nutzung des Orchestrators mit SvSAN ist auch der vCenter-Server anzugeben.

Die Knowledge Base beschreibt die notwendigen Schritte ausreichend genau und wir hatten Edge Control erfreulich schnell einsatzbereit und konnten nun das WebGUI von Edge Control aufrufen.

Zentrale Ansicht, separate Verwaltung

Das zentrale Element des Orchestrator ist die Dashboard-Ansicht mit allen wichtigen Infos über sämtliche SvSAN- und SvHCI-Installationen auf einen Blick. Im Navigationsmenü am linken Fensterrand finden sich Menü-Einträge für anstehende Tasks, SvHCI-Cluster mit Systemen, die Orchestrator-Einstellungen sowie die auf SvHCI laufenden VMs. Letztere lassen sich hier steuern mit Ein/Aus, Reset, Neustart und Migration im Fall einer gespiegelten VM. Eine Steuermöglichkeit für die Hosts ist im Orchestrator nicht enthalten, nur die Sicht auf die Einstellungen. Die Hoststeuerung ist nur über das WebGUI des jeweiligen Systems möglich.

Gerade in größeren Umgebungen mit mehreren SvHCI-Clustern und eventuell auch noch einer Nutzung von SvSAN verspricht Edge Control eine deutlich bessere Übersicht. Wie bereits erwähnt erscheint uns der Ansatz, für den Edge Control Orchestrator Hyper-V oder VMware als Basis zu nutzen, weniger geschickt, da SvHCI eigentlich als deren Ersatz geschaffen wurde.

Trotz der zentralen Administration durch Edge Control ist bei größeren Installationen mit mehr Clustern zu beachten, dass trotzdem jeder Cluster eigenständig für sich läuft. Eine Migration von VMs kann nur innerhalb eines Clusters erfolgen, jedoch nicht Cluster-übergreifend. Damit sollte der Administrator im Vorfeld auf die jeweilige Clusterauslastung achten. Größere Cluster mit mehr Hosts wie bei Hyper-V oder vSphere möglich bieten diesbezüglich mehr Flexibilität und eine bessere Skalierbarkeit. Eine Erweiterung auf mehr als zwei Hosts ist bei SvHCI geplant, allerdings noch nicht innerhalb der nächsten Monate.

Die Dokumentation zu SvSAN sowie SvHCI ist erfreulich umfangreich, wobei SvSAN die Nase eindeutig vorn hat, da es schon länger auf dem Markt ist. Insgesamt vermissten wir eine durchgehende Struktur. Neben dem eigentlichen Handbuch gibt es zu sehr vielen Themen einzelne Artikel und Beschreibungen in der Knowledge Base, wobei es nicht immer ganz leicht ist, bei einem Problem zuverlässig den richtigen Hinweis zu finden.

Fazit

Im Test überzeugte SvHCI durch die einfache Inbetriebnahme, wobei sich das Produkt als sehr tolerant gegenüber unterschiedlicher Hardware erwies. SvHCI besteht aus einem oder zwei Hosts in einem Cluster mit integriertem Hypervisor, das aktuelle Limit sind 50 gespiegelte oder 100 ungespiegelte VMs auf einem Zwei-Knoten-Cluster. Fiel im Test ein Host plötzlich aus, wurden gespiegelte VMs in wenigen Sekunden am verbleibenden Cluster gestartet. Zu beachten ist, dass ein SvHCI Cluster immer nur aus maximal zwei Knoten bestehen kann, für größere Umgebungen dementsprechend also mehrere Cluster vorzuhalten sind. Auch ist während einer geplanten Wartung keine Hochverfügbarkeit gegeben.

Das Zusatztool Edge Control ermöglicht neuerdings einen Cluster-übergreifenden Überblick inklusive einiger Funktionen zur Administration. Verschiebungen von VMs zwischen den Clustern sind im Moment noch nicht einfach realisierbar, was eine vorausschauende Planung erfordert. Die aktuelle Betriebssystem-Unterstützung ist überschaubar. Neben einigen Linux-Distributionen werden im Microsoft-Umfeld die Serverversionen ab 2019 offiziell unterstützt, jedoch keine Desktopbetriebssysteme. Wer die genannten Einschränkungen berücksichtigt, für den ist SvHCI sicher einen genaueren Blick wert, auf der Suche nach einer günstigen, hochverfügbaren Hypervisor-Plattform mit zuverlässigem Support.

Produkt	Software zum Aufbau einer hyperkonvergenten Infrastruktur (HCI).
Hersteller	StorMagic https://stormagic.com/de/
Preis	Die Lizenzierung erfolgt nach der Nettokapazität und pro Knoten ausschließlich als Mietmodell. Ein Single-Node ohne Hochverfügbarkeit kostet jährlich 881 Euro. Eine Lizenz mit HA und 2 TByte Kapazität schlägt mit jährlich 1844 Euro zu Buche, für unbegrenzte Kapazität werden jährlich 6399 Euro fällig. Für längere Vertragslaufzeiten von drei oder fünf Jahren gibt es deutliche Rabatte.
Systemanforderungen	Hardware: Zwei x86-Server aus der Hardware-Kompatibilitätsliste; mindestens zwei CPU-Kerne, die Hardwarevirtualisierung (Intel VT-x oder AMD RVI) unterstützen; Arbeitsspeicher mindestens 2 GByte; ein Laufwerk mit mindestens 32 GByte als Bootmedium; 1-GBit/s-Ethernet, 10 GBit/s sind empfohlen. Unterstützte Gastbetriebssysteme: Windows Server 2019, 2022, 2025 64-Bit (x86); Red Hat Enterprise Linux (RHEL) 8.x 64-Bit (x86); SUSE Linux Enterprise Server 15 (SLES15) SP5 64-Bit (x86); Canonical Ubuntu Server 20.04, 22.04, 24.04 LTS 64-Bit (x86); Debian OS Linux Server 12.x 64-Bit (x86); Rocky Linux 8.x 64-bit
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Hardwarekompatibilität	9
Übersichtlichkeit des GUI	8
Betriebssystem-Unterstützung	5
Hochverfügbarkeit	9
Skalierbarkeit	6

StorMagic SvHCI 2.0