Den Hype von hyper-converged Storage trennen

Das Herstellermarketing führt eher zu Verwirrung über hyper-converged Storage und Infrastruktur. Auf eine genaue Unterscheidung kommt es an.

Viele Anwender haben vor ein paar Jahren damit begonnen, ihre physischen Server durch den Einsatz eines Hypervisors zu konsolidieren. Einige entdeckten dann, dass ein Teil Ihrer Applikationen langsamer geworden ist oder dass das Verschieben einer virtuellen Maschine (VM) von einem physischen Server zu einem anderen langsamer von statten ging, als erwartet, so dass sie das Routing zwischen der virtuellen App und ihren Daten, die irgendwo in dem SAN des Unternehmens abgelegt waren, manuell neu anstoßen mussten. 

In beiden Fällen hat der Hypervisor-Lieferant wahrscheinlich gesagt, dass die traditionellen Speichersysteme die Ursache des Problems seien. Um das Problem ein für alle Mal zu lösen, erklären die Hersteller dann gern, dass man die alten Speicherinstallationen ja auch einfach aufgeben und auf den Zug von „hyper-converged Storage“ aufspringen könnten.

Eine berechtigte Frage hier wäre: „Wie kann es denn traditioneller, überholter Storage sein, wenn ich ihn gerade erst installiert habe?“ Die nächste Frage könnte dann gewesen sein: „Was bitte ist hyper-converged Storage?“ Eine Suche im Internet nach mehr Informationen zu diesem Begriff hat dann wahrscheinlich so viele Definitionen zu Tage gefördert, wie es Hersteller von solchen hyper-converged Produkten gibt.

Analysten gehen davon aus, dass hyper-converged Storage eigentlich eine Unterabteilung der hyper-converged Infrastruktur darstellt. Der Ausdruck hyper-converged Infrastruktur bezieht sich in der Regel auf das Verbinden von Server- mit Speicherkomponenten mittels eines gemeinsamen „Bindemittels“ in der Art von Software-defined Storage (SDS). Eine solche Konstruktion übernimmt all jene besonderen Funktionen, die gewöhnlich von Array-Controllern ausgeführt wurden, und integriert sie stattdessen in einen Software-Controller auf der Serverseite.

In Wirklichkeit gibt es keine allgemein gültige Definition von hyper-converged Infrastruktur. Es existieren mehrere Varianten nebeneinander, und jede von ihnen ist durch den Grad ihrer Abhängigkeit von einer Hypervisor-Software oder einer Storage-Hardware bestimmt.

Kategorie 1 von hyper-converged Infrastrukturprodukten

In einigen Fällen ist hyper-converged Storage als eine zentrale Speicher-Appliance auf Hardware-Basis konzipiert. Die Server-Komponente besteht einfach aus einem großen Speicher-Controller, der mit SDS läuft – in der Regel unter einem speziellen Hypervisor. Auf diese Weise werden auf der Server-Seite Direct-Attached Storage (DAS) und eventuell einige DRAM- oder Flash-basierte Memory-Speicherkomponenten kontrolliert. 

Dieses Szenario stellt ein Beispiel für eine Hardware-abhängige Installation dar, weil nur ausgewählte Hardware für Speicherzwecke benutzt wird, und gleichzeitig ist sie in der Regel ein Beispiel für eine Hypervisor-Abhängigkeit, da sie nur virtuelle Maschinen (VMs) von einem einzigen Hypervisor unterstützt. Eine Installation mit EVO:RAIL von VMware funktioniert auf diese Weise. Die Auswahl von Hardware ist ziemlich eingeschränkt, und nur Daten von VMs unter VMware können die Speicherkapazitäten nützen.

Es gibt auch Hardware-Abhängigkeit in Infrastrukturen für hyper-converged Storage, die durch den Einsatz eines SDS-Mikrokernels für den Server-Hypervisor geschaffen wird. Wenn Sie jemals versucht haben, zum Beispiel VMwares Virtual SAN (VSAN) oder auch Microsofts Hyper-V Cluster Storage Spaces zu installieren, wissen Sie, was ich meine. 

In beiden Fällen verfügt man über eine gewisse Flexibilität darin, welche Hardware man zum Server hinzufügen möchte, aber viel mehr ist es nicht. Nur bestimmte Typen von Festplatten, Flash-Komponenten und Verbindungsprotokollen werden unterstützt oder sind zertifiziert. In Sachen Hardware-Auswahl sind diese beiden Varianten um einiges flexibler als EVO:RAIL, aber es wird jeweils nur ein bestimmter Hypervisor unterstützt. Und die Speicherkapazität kann nicht zwischen den Workloads verschiedener Hypervisoren aufgeteilt werden.

Kategorie 2 von hyper-converged Infrastrukturprodukten

Eine zweite Gruppe von hyper-converged Infrastrukturprodukten kann über feste oder flexible Hardware verfügen, unterstützt aber den Daten-Workload unter verschiedenen Hypervisoren. Nehmen wir an, Sie setzen Microsoft Hyper-V und VMware vSphere ESX für verschiedene VMs ein. 

Wenn Sie keine weitere Kapazität mehr auf den hyper-converged VSAN-Knoten hinter dem VMware-Server, aber dafür noch Platz auf den Clustered Storage Spaces hinter dem Microsoft-Hyper-V-Server haben, gibt es keine einfache Lösung, die verfügbare Speicherkapazität da einzusetzen, wo sie benötigt wird.

Microsoft stellt allerdings einen Konverter zur Verfügung, der Ihre VMware-VMDK-Datei in eine VHD-Datei umwandelt, so dass sie auf einem Speicher unter Clustered Storage Spaces abgelegt werden kann. Das führt aber zu der Konsequenz, dass VMware sie nicht länger benutzen kann. VMware bietet umgekehrt nicht einmal ein Tool an, um seinen VSAN-Speicher mit einem fremden Hypervisor zu verwenden. Interessanterweise stellt Nutanix eine Hardware-abhängige Appliance her, die Workloads sowohl von VMware als auch von Hyper-V hosten kann.

Für hyper-converged Angebote, die Hardware- und Hypervisor-unabhängig sein sollen, müssen Sie sich in der Regel bei Third-Party- oder unabhängigen Software-Herstellern umsehen, die sich auf SDS-Produkte spezialisiert haben. Während nicht alle von ihnen eine Plattform für universell zu nutzenden Speicher liefern, die zwischen verschiedenen Workloads aufgeteilt werden kann, können zum Beispiel die Lösungen von StarWind Software für getrennte Instanzen jenseits von verschiedenen Hypervisoren installiert und von einer gemeinsamen Konsole aus verwaltet werden.

Kategorie 3 von hyper-converged Infrastrukturprodukten

Eine hyper-converged Idealwelt würde eine Third-Party-SDS-Software einsetzen, die gemeinsam zu verwaltende Speichereinheiten hinter jedem Hypervisor erzeugt und virtuelle sowie nicht-virtuelle Workloads unterstützt. Dies ergibt dann eine dritte Gruppe einer hyper-converged Speicherarchitektur, die einen SDS-Software-Stack erfordert, der Speichervirtualisierung einschließt. 

Mit Speichervirtualisierung kann man virtuelle Volumes aus jeder beliebigen Ansammlung von Storage-Hardware gemeinsam nutzen und sie auch gemeinsam in verschiedenen hyper-converged Speicherinstallationen verwalten, die auf Basis unterschiedlicher Hypervisoren entstanden sind. Virtual SAN von DataCore Software besitzt diese Eigenschaft – und zwar schon längst vor dem neuesten hyper-converged Hype. Aktuelle IT-Planungen sollten den Ansatz von DataCore durchaus mit berücksichtigen.

Laut Industrieanalysten werden bis zum nächsten Jahr annähernd 75 Prozent aller Applikationen virtualisiert sein. Die anderen 25 Prozent bestehen aus transaktionsorientierten, Umsatz-produzierenden Anwendungen, die im Moment niemand virtualisieren möchte. Geht man von dieser Situation aus, wird man für die nächste Zeit weiterhin Speicherlösungen sowohl für virtualisierte als auch für nicht-virtualisierte Workloads zur Verfügung stellen müssen – also für mindestens zwei grundverschiedene Typen von Workloads.

Wenn aktuelle Datenuntersuchungen korrekt sind, werden Sie wahrscheinlich Workload-Daten von mindestens zwei Hypervisoren unterstützen müssen, da die Unternehmen dazu tendieren, ihre gegenwärtige Hypervisor-Software zu diversifizieren. 

Das bedeutet, dass Sie eventuell sogar mit mehr isolierten Inseln von virtuellen und nicht-virtuellen Workloads zu tun haben werden als bisher – abgetrennt voneinander je nach Hypervisor-Typ und entsprechender hyper-converged Infrastruktur. Das kann dann sehr schnell zu vertrackten, schwer zu lösenden Problemen führen. Anders gesagt: Verfügt man über eine hyper-converged Option, die flexible Hardware und unterschiedliche Workloads auf einer gemeinsamen Software-Basis managt, ist man auf der richtigen Seite.

Mehr oder weniger alle Anbieter von hyper-converged Speicher-Appliances und hyper-converged Infrastruktur auf Hypervisor-Basis versprechen die Beschleunigung von Anwendungen, einfache Skalierung, Hochverfügbarkeit und niedrige Kapital- und Arbeitskosten (Capex und Opex). 

Wenn Sie diese Beschreibungen der positiven Effekte von hyper-converged Infrastruktur etwas enttäuschend finden, stehen Sie durchaus nicht alleine da. Leider gehen sehr viele der aktuellen Ansätze bei hyper-converged Infrastruktur von einem Sammelsurium von allgemeinen, ungesicherten Annahmen aus, sowie zusätzlich von zahlreichen Halbwahrheiten und überzogenen Vereinfachungen, die ebenfalls zu schade sind für eine ernsthafte Auseinandersetzung.

Nützlicher sind da schon einige Kriterien, anhand derer man sich eine eigene Auswahl von Technologien für eine hyper-converged Infrastruktur zusammenstellen kann. Und mit denen man dann jene Lösung findet, die am besten den eigenen Ansprüchen gerecht wird.

Ü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

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close