Sieben Kriterien für die Auswahl von hyper-converged Systemen

Wer vor der Anschaffung von hyper-converged Systemen steht, muss genau festlegen, was er will. Sieben Kriterien sind hauptsächlich zu beachten.

Angesichts einer größeren Auswahl an konkurrierenden Installationsangeboten brauchen IT-Entscheidungsträger Hilfe, wenn es darum geht, geeignete hyper-converged Systeme für ihre Rechenzentrumsumgebungen angemessen zu beurteilen.

Die folgenden sieben Kriterien für die Auswahl von hyper-konvergenten Systemen berücksichtigen die wesentlichen Gesichtspunkte, die bei jeder IT-Anschaffung anfallen: Kosten, Verfügbarkeit und adäquate Zielumsetzung.

Hardware-Abhängigkeiten

Einige Lösungen für hyper-converged Server- und Speichersysteme sind vorkonfigurierte Appliances oder Hardwareplattformen, die von einem bestimmten Hypervisor-Anbieter zertifiziert sind. Diese sorgen jedoch für eine Lock-in-Situation auf der Hardware-Ebene. 

Einen Hardware-unabhängigen Ansatz zu verfolgen, ist aber der einzige Weg, um an verschiedenen Stellen der IT-Architektur und zu unterschiedlichen Zeitpunkten Verbesserungseffekte zu erzielen und dabei neue Technologien einzusetzen. Die wirklich fundamentale Fragestellung in diesem Zusammenhang lautet: „Welche Hardware braucht man, um die angestrebte Lösung praktisch umzusetzen?“

Auf der Hardware-Ebene sollte man auch ein Auge auf die Skalierungsproblematik werfen. Je eng gefasster eine Hardwarespezifikation ausgelegt ist, desto weniger wird man in der Lage sein, verschiedene Komponenten auf einem modularen Wege zu erweitern. 

Verbesserungen bei den Komponententechnologien können in unterschiedlichen Phasen erfolgen, was es mitunter schwierig macht, immer mit der Innovationsgeschwindigkeit Schritt zu halten. Außerdem wird sich ein Lock-in bei einer ganzen Reihe von Hardwareprodukten auf Dauer so auswirken, dass die Kosten für das ausgesuchte hyper-converged System womöglich ansteigen werden.

Architektur mit mehreren Knoten

Mehrere Anbieter von Hypervisoren verkaufen hyper-converged Speichermodelle, die mit drei (oder mehr) Konfigurationen für Cluster-Knoten beginnen. Für einen Knoten sind in der Regel ein physischer Server, eine Softwarelizenz, eine Cluster-Software (entweder als Teil eines Hypervisor-Pakets, eines Betriebssystems oder einer speziellen Software eines weiteren Herstellers), Flash-Speicher und ein Storage-Array oder ein JBOD nötig. 

Laut einem aktuellen Lab-Bericht fallen für einen Knoten auf der Hypervisor-Seite Kosten zwischen 8.000 und 11.000 Dollar allein für die Softwarelizenzen an, während man auf der Hardwareseite für Server und Storage zwischen 8.000 und 14.000 Dollar veranschlagen muss. 

Diese Zahlen muss man mit der Anzahl der Knoten multiplizieren, die für eine hyper-converged Infrastruktur gebraucht werden, um einen realistischen Überblick über die Gesamtausgaben zu bekommen – wobei man aus Verfügbarkeits- und Performance-Gründen von mindestens drei oder vier Knoten ausgehen muss. 

Im Gegensatz dazu erfordern einige hyper-converged Systeme von Third-Party-Anbietern lediglich zwei physische Knoten für den Anfang. Außerdem können sie auch weniger teure Hardware verwenden – zum Beispiel SATA- anstelle von SAS-Festplatten.

Management-Fähigkeiten

Führende Anbieter von Hypervisoren (und die meisten Hersteller von hyper-converged Appliances) ziehen es vor, dass ihre einheitlichen Software-Stacks für das Management aller angeschlossenen Ressourcen und deren besondere Services verwendet werden. 

Was den Storage-Bereich angeht, stellen die Hypervisor-Anbieter zum Beispiel Schnittstellen für die Verwaltung von Data Mirroring und Replikation über mehrere Knoten hinweg zur Verfügung, außerdem für Thin Provisioning von Speicherresourcen, Deduplizierung und Komprimierung sowie für andere Aufgaben, die früher von Controllern ausgeführt wurden. Im Wesentlichen fassen diese Schnittstellen die zusätzlichen Funktionen, die früher von den Speicherherstellern als besondere Unterscheidungsmerkmale angeboten wurden, in einem gemeinsamen Software-basierten Controller zusammen.

Man muss sich darüber im Klaren sein, dass diese Funktionen in ihrem Kontext genau geprüft werden sollten, damit die gewählte Infrastruktur ihre Aufgaben erfüllen kann. Zum Beispiel kann die Komprimierungsfunktion bei einem Produkt beeindruckend sein, während die angebotene WAN-Replikation nicht dem aktuellen Stand der Technologie entspricht.

Während die meisten Anbieter von hyper-konvergenten Systemen darin übereinstimmen, dass Speicherfunktionen außerhalb des eigentlichen Arrays in einem unabhängigen Software-Stack eingerichtet werden müssen, vermeiden viele von ihnen zugleich den Ansatz, Kapazitäts-Management vom Controller des Storage-Arrays abzulösen. 

Dies stellt eine erwähnenswerte Begrenzung vieler hyper-converged Angebote dar, da Kapazitätsmanagement so zu einer abgetrennten Funktion wird, die einzeln auf jedem Speichergerät ausgeführt werden muss und oft spezialisierte Tools und Kenntnisse erfordert.

Worauf es beim Hardware-Einsatz ankommt

Es ist ebenfalls sehr wichtig, eine hyper-converged Infrastruktur-Version auszuwählen, die den Hardware-Einsatz optimiert. Während zum Beispiel die meisten verfügbaren hyper-converged Produkte dynamische RAM- und Flash-Technologie verwenden können, um Cache- und Pufferspeicher zur Verbesserung der Anwendungs-Performance einzurichten, verfahren sie letztlich nicht konsequent genug oder sind auch nicht auf alle Funktionen vorbereitet, die heute bereits am Markt zur Verfügung stehen. So ist DRAM de-facto besser als Flash-Memory für Schreib-Caching geeignet, aber aus den Marketing-Botschaften der Hersteller von hyper-converged Infrastrukturen kann man dies nicht entnehmen. 

Oft wird dagegen Flash für Einsatzzwecke empfohlen, für die es eigentlich nicht geeignet ist, oder die Hersteller schränken die Möglichkeiten der Anwender ein, weniger teure Komponenten einzusetzen. Das gilt auch für den Einsatz von Technologien, die auf dem allerneuesten Stand der Entwicklung („best-of-breed“) und bereits vom Hersteller zertifiziert sind, um die Performance der Anwendungen weiter zu beschleunigen.

Unterstützung für DRAM

Unterstützung für Beschleunigung durch DRAM- und vielleicht auch Flash-Memory ist besonders für Server notwendig, auf denen mehrere virtuelle Maschinen laufen. Memory-basiertes Caching und Buffering (Puffer) ermöglichen die Performance-Steigerung von Applikationen, selbst wenn die Ursachen von langsamen Anwendungen nichts mit I/O-bezogenem Storage zu tun haben. Idealerweise sollte auch Flash-Technologie unterstützt werden, aber das ist nicht zwingend notwendig.

Zielführende Technologie

Die Fähigkeit, Ergebnisse zu liefern, hängt ganz einfach davon ab, inwieweit sich die neue Technologie in die bestehende Umgebung und ihre Bedingungen einfügt. Dies schließt unter anderem Faktoren wie Geräuschpegel, Stromversorgung, ausgebildete IT-Mitarbeiter und die Kompatibilität mit unterschiedlichen Hypervisoren ein. Es lohnt sich, eine Liste mit den räumlichen Bedingungen, den Workload- und den Arbeitsplatzanforderungen anzulegen, sobald man alternative Produkte in Erwägung zieht.

Verfügbarkeit

Die Cluster- und Mirroring-Funktionen der hyper-converged Software, die man einsetzen möchte, muss nicht nur das Spiegeln von Daten in Caches und Puffern einschließen, sondern auch die auf Solid State Drives (SSDs) und auf magnetischen Festplatten gespeicherten Daten.

Hoch verfügbare Mirroring-Funktionen muss man ohne Unterbrechung der Anwendungsoperationen testen und bewerten können – nur so erhält man ein realistisches Abbild ihrer Tauglichkeit. Man sollte sich darüber hinaus vergewissern, ob ein Mirroring-Failover automatisch funktioniert oder manuell angestoßen werden muss. Verfügbarkeit ist keine Einbahnstraße: Nachdem der Failover passiert ist, muss auch die Möglichkeit für ein Failback vorhanden sein. Dies bringt in der Regel das Puffern von Mirrored Writes mit sich, bis die Verbindungen wieder hergestellt sind.

Fazit

Während diese sieben Kriterien vielleicht nicht erschöpfend sind, sollten sie doch zumindest dabei helfen, einen Überblick über das Feld von hyper-converged Systemoptionen zu gewinnen, um langfristig das eigene Geschäftsmodell voranzubringen. Für mein Geld ziehe ich eine hyper-converged Infrastruktur vor, die keine Beschränkungen bei Hardware und Hypervisor mit sich bringt, die DRAM und Flash von jedem beliebigen Hersteller unterstützt und die über eine Festplattenlandschaft verfügt, die sowohl für Direct-Attached Storage (DAS) als auch für Storage Area Network (SAN) offen ist – so dass ich auch den ROI-Vorteil (Return on Investment) einer SAN-Lösung realisieren kann. 

Meine endgültige Auswahl würde auch darin bestehen, die komplette Speicherkapazität zu virtualisieren, so dass ich bequem Speicher zuweisen und unterschiedliche Speicherumgebungen an verschiedenen Orten zusammen mit einer einzigen Software-Oberfläche verwalten kann.

Über den Autor:
Jon William Toigo blickt auf 30 Jahre Erfahrung im IT-Bereich zurück. Er ist CEO und Managing Principal von Toigo Partners International sowie Vorsitzender des Data Management Institute.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Juni 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Data-Center-Storage

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close