Hyperkonvergente Systeme – alles nur heiße Luft?

Hyperkonvergente Systeme stellen Compute- und Storage-Ressourcen in Form von x86-Appliances bereit. Diese können sich durch unterschiedliche Performanceklassen voneinander abheben. Der Hypervisor ist immer ein Teil der Lösung, wobei einige Hersteller auch multiple Hypervisor unterstützen. Die Verwaltung des Hypervisors, der Compute-Ressourcen und des Storage-Stacks sind in einem Management zusammengefasst. Als Formfaktor haben sich Rack- und Micro-Server durchgesetzt. Die Betrachtungen auf der Virtualisierungsebene sind immer auf virtuelle Maschinen zentriert, z.B. in dem Punkt Verfügbarkeit. Ein Skale-Out wird über das Hinzufügen neuer Appliances gewährleistet. Im Hinblick auf das Netzwerk endet die Betrachtung am Port der Netzwerkkarte jedes einzelnen Knotenpunktes. Dieser sollte aber mit mindestens 2 x 10 GB/s ausgestattet sein. Ein Bare-metal Betrieb ist nicht möglich.

Hyperkonvergente Systeme werden in zwei Typen unterschieden:

• Kernel-integrierte
• Controller-VM-basierte

Kernel-integrierte Systeme werden aktuell ausschließlich von Hypervisor Herstellern angeboten. Hierbei werden die Funktionen tief im Kernel verankert. Vorteil ist der geringere Overhead an den Compute-Ressourcen zur Bereitstellung der Storage-Funktionalität. Je nach Anbieter und Lösungsszenario ist pro Appliance somit ein Overhead von 10–25 % CPU-Performance und 8–64 GB RAM anzusetzen.

Controller-VM-basierte Systeme werden, wie der Name vermuten lässt, als VM im Hypervisor bereitgestellt (1 VM je Appliance). Der Zugriff auf SSDs und HDDs erfolgt direkt aus der VM via PCIe Pass-through Mechanismen. Vorteil dieser Lösung ist der größere Funktionsumfang. Jedoch sind die Performanceanforderungen hier auch höher. Je nach Anbieter und Lösungsszenario ist pro Appliance somit ein Overhead von 15–25 % CPU-Performance und 24–96 GB RAM anzusetzen. Im Fall von Simplivity kommt ferner ein herstellerspezifischer ASIC zum Einsatz.

Schaut man sich eine Appliance genauer an, werden SSDs vornehmlich als Cache genutzt. Die Datenhaltung erfolgt auf den HDDs, welche als JBOD angesteuert werden. Eine redundante Datenhaltung wird sichergestellt, in dem die Disk der virtuellen Maschine auf mehreren Appliances jeweils auf einzelnen Disks abgelegt wird – einem sogenannten Redundant Array of Independent Nodes (kurz RAIN). Da die Netto-Speicherkapazität sich dann, aufgrund des Mehrfachspiegels, auf bis zu 25 % reduziert, kommen zunehmend Fehlerkorrekturverfahren im Clusterverbund zum Einsatz. Somit erhöht sich die Netto-Speicherkapazität auf bis zu 67 %. Dies setzt aber eine höhere Anzahl an Cluster-Knoten voraus. Für besonders performancehungrige Anwendungen stehen auch hyperkonvergente Systeme mit einer All-Flash-Konfiguration zur Auswahl. Diese sind aktuell aber noch sehr preisintensiv.

Zum Aufbau eines Clusters werden immer mehrere Appliances benötigt. Die Anzahl hängt vom Anbieter ab. Als Einstiegsgröße werden 2–4 Appliances angeboten. Wobei eine Lösung mit zwei Appliances immer einen Zeugen für den reibungslosen Betrieb benötigt. Auch die maximale Größe eines Clusters ist unterschiedlich und hängt vom Hypervisor und dem Use Case ab. Im Fall von vSphere sind dies 8 bis 64 Knoten.

Dem Kunden werden meist Einsparungen im operativen Betrieb durch die höhere Integration versprochen. Unter anderem durch frei werdende Personalressourcen und Support aus einer Hand. Auch APIs für eine Automatisierung von Arbeitsschritten werden mitgeliefert. Die Skalierung erfolgt einfach und linear. Ferner ist eine Integration ins Backup- und Recovery-Konzept, je nach Hersteller, möglich.

Erfahren Sie in einer der nächsten Ausgaben, auf welche Punkte Sie bei der Auswahl achten sollten und für wen hyperkonvergente Systeme geeignet sind bzw. kontaktieren Sie uns gern direkt.

Weiterführende Informationen:

Storage Lösungen Cloud Backup Lösungen

Bildquelle/Copyright: © Sergey Nivens – fotolia / © SHD – Christian Müller