Vergleichskriterien für Einsatz von hyperkonvergenten Infrastrukturen
19. Oktober 2015Hyperkonvergente Lösungen versprechen vielen Unternehmen eine weitgehende Flexibilisierung der IT-Infrastruktur und damit einhergehend auch geringere Betriebs- und Investitionskosten. Doch bei der Auswahl der passenden Lösung sind verschiedene Bewertungskriterien zu beachten – es gilt vor allem, neuartige und allzu enge Herstellerbindungen zu vermeiden. Speziell die Hypervisor-unabhängigen und in Bezug auf die Storage-Systemauswahl offenen Lösungen versprechen hier deutliche Vorteile.
Nach dem durchschlagenden Erfolg der Servervirtualisierung haben konvergente Systeme Einzug in den Rechenzentren gehalten. Beispiele dafür sind die Flexpod-Systeme von Netapp und Cisco beziehungsweise die VCE-VBlocks von EMC und Cisco. Dabei lautet das Prinzip: Vorgefertigte und auf das reibungslose Zusammenspiel bereits zertifizierte Funktionsblöcke – Serverknoten, gemeinsamer Speicher (meist ein SAN) sowie Netzwerkverbindung – werden komplett als Rack angeliefert und können dadurch beim Anwenderunternehmen schneller in Betrieb genommen werden. Noch einen Schritt weiter gehen die „hyperkonvergenten Systeme“. Bei ihnen stellen die Serverknoten auch gleich den gemeinsam benutzten Storage mit zur Verfügung – ein externes SAN wird damit in vielen Fällen überflüssig.
Beispiel dafür sind die Ansätze von Nutanix oder VMwares EVO:Rail-Konzept. Dazu muss aber eine Loslösung des Speicherbereichs stattfinden – dazu hat VMware sein Virtual SAN (mittlerweile in der Version 6.1) vorgestellt. Es gibt aber auch einen Ansatz wie Datacores Virtual SAN, das eine entsprechend flexible Virtualisierung des Speichers bietet – über eine Vielzahl von Hypervisoren hinweg und unter Einbeziehung nahezu aller Storage-Optionen.
Wenn ein Anwenderunternehmen vor der Aufgabe steht, entweder als Ersatz für seine bestehende IT-Infrastruktur, oder als eine Erweiterung der IT-Landschaft eine derartige Lösung anzugehen, gilt es zwei wichtige Vorgaben zu erfüllen: Einerseits ist eine Kombination aus Infrastrukturkomponenten und -diensten auszuwählen, die den Anforderungen der jeweiligen Arbeitslasten möglichst optimal entspricht. Andererseits muss eine Entscheidung für das gewünschte hyperkonvergente Modell getroffen werden, das sich bei ändernden Speicherbedürfnissen anpassen und skalierten lässt – und das alles, ohne das zur Verfügung stehende IT-Budget aus den Augen zu verlieren.
Generell erweist sich die Vereinigung von Server-und Speichertechnologie mithilfe eines Software-basierten Speicher-Controllers, der sich im Software-Stack des Servers befindet, als das passendste Konzept der Hyperkonvergenz. Diese Konzeption wird auch als „SDS, also als Software-Defined Storage bezeichnet. Eine passende Softwareschicht dient als Speicher-Controller und ersetzt die entsprechende Funktionalitäten – typischerweise in den Speicher-Arrays. In die Hyperkonvergenz-Infrastrukturen kommen verteilte Recheneinheiten zum Einsatz, um ein hyperkonvergentes Modells zu realisieren. Zu den Vorteilen dieses Ansatzes zählen:
• eine vereinfachte Skalierbarkeit (wie sie etwa durch das Hinzufügen weiterer Server-Knoten erreicht wird),
• eine Verbesserung der Verfügbarkeit (durch die Funktionalität der Datenreplikation ist ein sauberer Failover-Vorgang möglich) und
• eine Senkung der Infrastrukturkosten. Das ergibt sich in erster Linie bei einem Austausch der schwer zu verwaltenden Storage Area Networks (SANs) und von monolithischen Speichersystemen durch Storage-Komponenten, die direkt an die Server angeschlossen werden.
Wenn es nun an die Auswahl der passenden hyperkonvergenten Storage-Konzeption geht, sind einige Parameter wichtig. Zum einen ist zu berücksichtigen, ob die Lösung mit nur einer einzigen Hypervisor-Plattform zusammenspielt – wie das zum Beispiel bei VMwares Virtual SAN gegeben ist. Zum anderen ist es in den meisten Fällen von Vorteil, wenn sich virtualisierte und physische Umgebung gemeinsam im Storage-Bereich zusammenfassen lassen, wobei sogar noch verschiedene Hypervisor-Plattformen – wie zum Beispiel vSphere, Hyper-V und KVM – zum Einsatz kommen sollen. Das ist vor allem bei Zusammenschlüssen von Unternehmen keine allzu seltene Aufgabenstellung – und falls das bei einem Unternehmen heute noch nicht ausschlaggebend ist, so kann es doch künftig an Bedeutung gewinnen. Auch die Kombination von virtualisierten Anwendungen mit Kern-Applikationen (wie viele ERP-Systeme oder spezielle Datenbanken), die aufgrund der Performance-Vorgaben nicht virtualisiert betrieben werden (können), ist heutzutage keine Seltenheit in bestehenden IT-Umgebungen.
Generell verspricht bei der Selektion einer Konvergenzlösung im Storage-Bereich die Technologie mit der größtmöglichen Kostensenkung, der höchsten Verfügbarkeit, den besten Performance-Merkmalen und der optimalen Eignung für die angedachte Aufgabe die beste Lösung. Doch bei allen technischen Aspekten gilt es die Frage nach den Kosten einer hochkonvergenten Lösung für den Speicherbereich ins Kalkül zu ziehen – denn was hilft die beste Lösung, wenn man sie sich nicht leisten kann.
Wer sich die Ausgaben im IT-Umfeld ansieht, der erkennt, dass die größten Aufwendungen für den Betrieb der bestehenden Systeme – meist sogar als Altlasten bezeichnet – aufgewendet werden müssen. Deswegen hat in den meisten Fällen auch die Reduzierung der Kosten oberste Priorität in den IT-Abteilungen. Dies gilt insbesondere für Niederlassungen oder externe Büros, aber auch für kleinere bis mittlere Unternehmen, die nicht über die IT-Budgets großer IT- oder Cloud-Dienstleister verfügen.
Betriebswirtschaftlich gesehen entstehen Kosten aus Investitionen für die Systeme (inklusive eventueller Finanzierungsaufwendungen), den Betriebsausgaben und Arbeitsaufwand – also den Personalkosten (seien sie von externen Mitarbeitern oder von fest angestellten ITlern). Effizientes Haushalten kann nur erreicht werden, wenn es der IT-Abteilung gelingt, möglichst immer nur die zur Speicherung der Daten erforderliche Hardware anzuschaffen. Dabei darf man aber nicht vergessen, Kapazitätsreserven einzuplanen, um Anforderungsspitzen abfedern zu können.
Hier sollte ein Unternehmen aber einen Aspekt nicht aus den Augen lassen: Der Grad der Verfügbarkeit der IT-Ressourcen spielt eine wesentliche Rolle – so muss man bei hohen Anforderungen im Bereich von 99,999 Prozent Verfügbarkeit wesentlich mehr einplanen, als bei den vergleichsweise gemäßigten 99 Prozent. Daher sollte bei einem Vergleich der Kosten hier immer von derselben Ausgangssituation – oder demselben Anforderungslevel – ausgegangen werden, und nicht Äpfel mit Birnen verglichen werden.
Müssen die verschiedenen Speicherkomponenten – und dabei darf man vor allem bei einer Erweiterung die bestehende Infrastruktur nicht aus den Augen verlieren – zusammenhängend und einheitlich verwaltet werden, führt dies zu einem geringeren Personalbedarf für die Infrastruktur sowie zu niedrigeren Betriebskosten.
Im Spezialfall einer hyperkonvergenten Infrastruktur für den Storage-Bereich in Erwägung, sollten folgende Kostentreiber berücksichtigt werden:
Der Faktor Hardware-Abhängigkeit: Wenn eine hyperkonvergente Server- bzw. Speicherlösung aus vorgefertigten Einzelgeräten oder kompletten Hardware-Plattformen (von vorgegebenen Herstellern) besteht, die vom jeweiligen Hypervisor-Anbieter „zertifiziert“ sind, ergibt sich eine starke Hardware-Bindung. Das wird sich dann um eine ähnliche Lösung handeln, wie sie von den traditionellen „Speicherstrukturen aus einer Hand“ ähnelt. Doch aus dieser festen Abhängigkeit wollen viele Unternehmen eigentlich entkommen.
In den meisten Fällen wird nur ein möglichst Hardware-unabhängiger Ansatz die Option bieten, einzelne Teile eines „Knotens“ zu unterschiedlichen Zeiten zu skalieren, und zwar abhängig vom Bedarf oder der Verfügbarkeit von neuer Technologie. Wichtiger erscheint daher vor allem die Frage, welche Hardware für eine „immer passende“ und funktionsfähige Lösung zum Einsatz kommen soll.
Das Attribut „immer passend“ zielt vor allem auf die Skalierbarkeit ab. Hier gilt eine wichtige Feststellung: Je enger gefasst eine Hardware-Spezifikation ausgelegt ist, desto geringer ist die Möglichkeit, einzelne Komponenten modular zu skalieren. Angesichts der üblichen „disruptiven“ Entwicklung, die sich sowohl bei Computer-Komponenten und als auch bei Speichertechnologien abspielt, können dabei Probleme entstehen.
Denn auch die jeweiligen Zeiträume, in der die Technik bestimmter Komponentenbereiche verbessert wird, unterscheiden sich mitunter massiv. Hieraus ergibt sich häufig die Notwendigkeit, einzelne oder mehrere Komponenten auszutauschen, um mit aktuellen Neuerungen Schritt zu halten. Je größer die Hardware-Abhängigkeit einer Geräteeinheit, desto geringer die Möglichkeiten, technische Innovationen nutzen zu können. Zudem wird in den meisten Fällen die Bindung an eine eng gefasste Hardware-Liste die Kosten der Lösung nach oben treiben.
Verfügbarkeit durch eine Multinode-Architektur: Einige Anbieter von Server-Hypervisoren setzen auf hyperkonvergente Speichermodelle, die bereits in der Grundausstattung mindestens drei (oder sogar mehr) Cluster-Knoten benötigen. Ein Knoten benötigt einen physischen Server, eine Lizenz für die Speichersoftware, Cluster-Software (entweder als Teil eines Hypervisor-Software-Pakets, des Betriebssystems oder einer spezialisierten Drittanbieter-Software), Flash-Speichergeräte sowie eine Speichereinheit oder ein JBOD-System. Dabei kann es leicht dazu kommen, dass sich die Kosten pro Knoten für die hyperkonvergente Software eines Hypervisor-Anbieters auf 8.000 bis 11.000 Dollar für die Software-Lizenzen und auf 8.000 bis 14.000 Dollar für die Server- und Speicher-Hardware belaufen.
Diese Zahlen sind dann mit der Anzahl der Knoten zu multiplizieren, die für den Aufbau einer hyperkonvergenten Infrastruktur erforderlich sind. Sind das im Mindestfall bereits drei Knoten, so werden aus Gründen der Verfügbarkeit und der Leistung sogar vier Knoten empfohlen. Im Gegensatz dazu erfordern die hyperkonvergenten Server-Speicher-Systeme einiger eigenständiger Hersteller in der Grundausstattung lediglich zwei physische Knoten und ermöglichen zudem die Nutzung weniger kostenintensiver Hardware (wie etwa den Einsatz von günstigen SATA- anstelle von teureren SAS-Festplatten).
Verwaltbarkeit der Lösung: Einige Anbietern von Server-Hypervisoren favorisieren bei der Verwaltung der Systeme ein Modell, bei dem für das Management aller angeschlossenen Ressourcen nur der vom Anbieter verkaufte Software-Stack sowie die spezialisierten Dienste des Anbieters zum Einsatz kommen sollen. Für den Betrieb der Speichersysteme stellen sie passende Schnittstellen für Verwaltungsfunktionen zur Verfügung.
Diese dienen zur Datenspiegelung und -replikation auf unterschiedlichen Speicherknoten und für das Ausführen von weiteren Storage-Funktionalitäten. Dazu gehören auch das „Thin Provisioning“ von Speicherressourcen, die Deduplikation sowie Kompression, aber auch die Durchführung weiterer Funktionen, wie sie üblicherweise auf den Controllern eines Storage-Arrays bereit stehen. Diese Features haben die einzelnen Hersteller von Storage Arrays benutzt, um sich von der Konkurrenz abzusetzen. All diese Funktionalitäten werden bei den hyperkonvergenten Storage-Architekturen in einem Controller bereitgestellt, zumeist Software-basiert und auf x86-Hardware ausgeführt, so dass sie für eine weit skalierende Infrastruktur zum Einsatz gebracht werden können.
Doch hier sollten die Anwender genau hinsehen, denn nicht alle Dienste einer Lösung sind das Optimum: Sollte zum Beispiel der netzwerkweite Replikations-Service eine extreme Performance liefern, muss nicht unbedingt die Kompression die beste sein, die es aktuell gibt. Bessere Ansätze liefert eine Lösung, bei der sämtliche Storage-relevanten Dienste in einem kompletten Software-Stack liegen, der sich nicht auf den Speichersystemen selbst befindet und der zudem die Freiheit bietet, die besten Techniken zu kombinieren.
Ein spezieller Punkt bei den hyperkonvergenten Storage-Lösungen betrifft das Kapazitätsmanagement. Das verorten einige „Hyperkonvergenz-Hersteller“ immer noch auf den Speichersystemen. Doch das kann vielfach zu erheblichen Einschränkungen führen, denn in einem derartigen Fall wird das Kapazitätsmanagement zu einer separaten Aufgabe für die Storage-Administratoren. Sie ist im schlimmsten Fall dann auch auf jedem einzelnen Speichergerät durchzuführen und benötigt oftmals sogar spezielle Tools und somit auch spezifische Fachkenntnisse.
Wird dagegen Speicherkapazität „virtualisiert“ oder gar in einem virtualisierten Ressourcen-Pool zusammengefasst, kann dessen Management auch zentralisiert und somit in einer verteilten Infrastruktur einfacher bereitgestellt werden – so wie man das auch von den anderen Storage-relevanten Funktionen her kennt.
Wenn hinter verschiedenen Hypervisoren jeweils isolierter – also nicht konsolidierter – Speicher zum Einsatz kommt, hat dies Auswirkungen auf die Kosten, die für das Storage-Management anfallen – sprich es werden höhere Kosten verursacht. Dieses Manko mag noch nicht offensichtlich sein, wenn ein Unternehmen eine hyperkonvergente Lösung lediglich für einen bestimmten Standort vorsieht. Aber er wird umso deutlicher auswirken, wenn die komplette Architektur weiter vorangetrieben wird.
Effiziente Hardware-Ausnutzung: Ein Hauptfaktor für die Kostensenkung lautet: Ein Unternehmen sollte sich für eine hyperkonvergente Infrastruktur entscheiden, bei der die Hardware optimal genutzt wird. Damit lassen sich vor allem die hyperkonvergenten Produkte einsetzen, die DRAM- und Flash-Speicher nutzen, um Caches und Puffer zur Verbesserung der Performance einer Anwendung zu bilden.
Doch nicht alle verfügbaren Produkte setzen Caches und Puffer wirklich effektiv ein. Zudem bieten sie nicht die Option, auf die Vielfalt der erhältlichen Drittprodukte zurückzugreifen. Dazu ein Beispiel: Ein Zwischenspeicher auf Basis der DRAM-Technologie eignet sich besser für Schreib-Caches als ein Flash-Speicher. Speziell beim Einsatz von Flash-Speicher ist Sorgfalt angesagt – er wird oftmals für Zwecke empfohlen, für die er nicht sonderlich gut geeignet ist.
Das Mischen von den besten und günstigsten Komponenten ist ein weiterer Punkt, den IT-Verantwortliche in Erwägung ziehen sollten. Einige Hersteller von Hyperkonvergenz-Lösungen schränken die Möglichkeit ein, dass die Anwender entweder günstigere Komponenten einsetzen oder aber Zusatzprodukte verwenden, die die Performance der Anwendung beschleunigen helfen. Denn das hätte zur Folge, dass die vom Hyperkonvergenz-Anbieter „empfohlenen“ und zertifizierten Produkte ausgetauscht werden – Stichwort „Vendor Lock-In“.
Erschwert wird die Situation, wenn eine Hyperkonverenz-Lösung voraussetzt, dass sämtlicher „alter“ Speicher – also die meist sehr teuren Storage-Arrays – komplett abgelöst werden müssen. Das lässt sich in der Finanzabteilung eines Unternehmens nur selten durchsetzen, denn die meisten Storage-Arrays wurde mit der Vorgabe angeschafft, dass sich nach fünf, manchmal auch erst nach sieben Jahren ein „Return on Invest“ (ROI) ergeben soll. Leichter lässt sich für die IT-Verantwortlichen argumentieren, dass im Zuge der Umstellung auf eine Hyperkonvergenz-Lösung die alten Storage-Systeme noch mit im Verbund betrieben werden können.