Dieser Artikel ist Teil unseres Guides: So optimieren Sie hybride IT-Infrastrukturen

Auf Konvergenz und Hyperkonvergenz folgt Disaggregation

Disaggregation und Hyperkonvergenz gelten oft als Gegensatzpaare. Im Grunde handelt es sich aber eher um eine konsequente Weiterentwicklung.

Die Diskussion um konvergente Infrastruktur, bei der Compute-, Storage- und Netzwerkressourcen auf dem Server integriert werden, wird tatsächlich erst seit einigen wenigen Jahren geführt. Heute ist mit hyperkonvergenten Lösungen die nächste Evolutionsstufe erreicht, und es sieht eher nicht nach einer nachlassenden Nachfrage nach integrierten Produkten aus.

In diesem Marktbereich hat sich der Staub gerade erst gelegt, und doch sprechen wir inzwischen schon über den nächsten Trend im Data Center: Disaggregierung.

Was ist aber eigentlich genau ein disaggregierter Server und wie lässt er sich zu dem in Verbindung setzen, was wir als Konvergenz und Hyperkonvergenz kennen? Um das zu erklären, muss man ganz am Anfang beginnen.

Die Ära von Moore´s Law

Mitte der 1960er hatte Gordon Moore von Intel das vorgestellt, was später als Moore´s Law berühmt werden sollte: Alle 18 Monate, so die These, würde sich fortan die Leistung von Mikroprozessoren verdoppeln lassen, was letztlich zu enorm leistungsfähigen PCs, Workstations und auch Servern führte. In gleicher Weise wurde so aber zum Beispiel auch das Client-Server-Modell möglich.

Moore´s Law hat sich erstaunlich lange bewahrheitet, bis die Industrie schließlich an den Grenzen des physisch Machbaren angekommen war. So lassen sich Prozessoren zum Beispiel ab einem bestimmten Punkt nur noch schwer verkleinern und auch die Taktgeschwindigkeit kann nicht beliebig erhöht werden. In den letzten Jahren haben Prozessorhersteller zur Leistungssteigerung daher vor allem den Weg über Multicore-Prozessoren gesucht.

Wenn sich ein einzelner Prozessor nicht mehr schneller machen lässt, warum dann nicht einfach mit mehreren Kernen eine höhere Leistung erreichen? Multicore-Prozessoren wiederum führten zur Entwicklung so leistungsfähiger Server, dass sie über Hypervisoren die Server-Virtualisierung und damit die Server-Konsolidierung überhaupt erst möglich machten.

Aggregierung durch Konvergenz und Hyperkonvergenz

Durch Multicore-Prozessoren wurde die Rechenkraft in Servern vergleichsweise günstig. Auf diese Weise sind Multicore-Prozessoren auch eine der Voraussetzungen für Software-definierte Strukturen.

Bei Storage wurde zunächst die Kontrollschicht von der Datenschicht getrennt, wodurch unterschiedlichste Hardware als Datenschicht über eine Software-definierte Kontrollschicht verwaltet werden kann. Aber bei all der so leistungsfähigen Hardware – warum nicht auch die Datenschicht in der Software integrieren? Kurz gesagt führten Multicore-Prozessoren direkt zur Integration aller Storage-Funktionen in die Software, um diese anschließend auf Commodity-Hardware auszuführen. Diese Idee verhalf Produkten wie DataCore, EMC ScaleIO, HP StoreVirtual oder auch VMware vSAN zum Durchbruch.

Mit dem Aufkommen so hochentwickelter Virtualisierungs-Technologien sowohl für Storage als auch für Server und parallel stattfindenden Verbesserungen bei Dateisystemen, warum das Ganze nicht einfach einen Schritt weiter denken und mehrere Funktionen direkt auf einem Server oder auf Server-Clustern implementieren?

Mit diesem Konzept nahm die Entwicklun hin zu hyperkonvergenten Produkten ihren Lauf, allen voran mit Start-ups wie Nutanix oder SimpliVity, später auch mit Produkten alteingessesener Storage-Konzernen wie EMC. Auch Hadoop-Anbieter erfreuten sich an der Idee von Scale-out-Nodes, die sowohl Compute- als auch Storage-Workloads auf den gleichen Server-Nodes ausführen konnten.

Mit der schieren Masse inzwischen verfügbarer Rechenkraft wurde es immer einfacher, einem einzelnen CPU-Kern mit einer vorhersagbaren Performance eine spezifische Funktion zuzuweisen, selbst wenn auf dem gleichen Server noch viele andere Workloads ausgeführt wurden. Die Public Cloud ist das beste Beispiel für die Umsetzung dieses Konzepts.

Konvergenz oder Hyperkonvergenz kann man sich so als Phase der Aggregierung von Compute-, Storage- und Netzwerkressourcen vorstellen. Letztlich werden hier Konzepte des Mainframes aufgenommen, wenn auch sehr viel anpassbarer und skalierbarer.

Auf Hyperkonvergenz folgt Disaggregierung

Gerade als sich die Branche mit Konvergenz und Hyperkonvergenz anzufreunden scheint, dreht sich der technologische Fortschritt weiter und die Industrie beschäftigt sich zunehmend mit dem Konzept disaggregierter Server. Dabei geht es nicht darum, wieder zu einzelnen Silos für bestimmte Funktionen oder Workloads zurückzugehen, sondern vielmehr um das Erstellen großer Ressourcen-Pools über Server-Nodes hinweg, aus denen sich Workloads dann skalierbar bedienen können.

Man denke dabei an eines der vermeintlich größten Probleme hyperkonvergenter Appliances: Die fehlende Möglichkeit, Compute-Ressourcen unabhängig von der Storage-Kapazität zu skalieren. Zugegebenermaßen gibt es inzwischen vermehrt Produkte, die sich stark in Richtung Compute oder Kapazität konfigurieren lassen, aber was, wenn es einem Unternehmen um Arbeitsspeicher oder nur Flash-Speicher für Caching geht?

Mit hyperkonvergenten Lösungen in Appliance-Form gibt es keine Möglichkeit, nur eine bestimmte Komponente zu skalieren. Stattdessen muss eine komplette Appliance mit Ressourcen gekauft werden, die man eigentlich gar nicht benötigt. Dieses Problem verspricht die Disaggregierung zu lösen.

Auch mit disaggregierten Servern bleibt die Infrastruktur skalierbar (Scale-out) und aus einzelnen Serverknoten aufgebaut, die jeweils benötigte Funktionalität wird aber je nach Bedarf hinzugefügt und aus den Ressourcen-Pools der unterschiedlichen Nodes zusammengesetzt. Alle Speicher-, Flash-, HDD- und Compute-Ressourcen werden also zu einem Pool zusammengefasst und gleichzeitig allen Applikationen zur Verfügung gestellt, die sich dann wiederum die jeweils nötige Kapazität reservieren.

Netzwerkfunktionen werden bisher lediglich virtualisiert bereitgestellt. Springpath zum Beispiel unterscheidet sich von den meisten Anbietern hyperkonvergenter Produkte durch die virtualisierten Netzwerkressourcen. Der nächste Schritt wäre die Disaggregierung virtueller Netzwerke, um nur die jeweils benötigte Kapazität aus einem gemeinsamen Ressourcen-Pool bereitzustellen. Sicherheitsfunktionen auf Netzwerkebene wie Firewalls oder VPNs sind dagegen in Form der Network Functions Virtualization (NFV) gewissermaßen schon disaggregiert und können in Unternehmen je nach Bedarf bereitgestellt werden.

Auf den ersten Blick scheinen sich Hyperkonvergez und Disaggregation damit diametral gegenüber zu stehen, tatsächlich sind disaggregierte Server aber eher eine Weiterentwicklung hyperkonvergenter Produkte. Disaggregation ermöglicht die Erstellung noch leistungsfähigerer Webscale-Clouds, bei denen massive Ressourcen-Pools je nach Bedarf und Zielsetzung bereitgestellt und zusammengesetzt werden können. Mit disaggregierten Server lässt sich so auch die Auslastung weiter steigern, was Einsparungen bei Rechenzentrumsfläche, Energieversorgung und Kühlung ermöglichen könnte.

Anbieter disaggregierter Lösungen

Im noch recht jungen Markt für disaggregierte Infrastruktur sind drei Anbieter besonders hervorzuheben. Erstens PernixData mit dem Fokus auf disaggregierte Flash-Kapazität über Nodes hinweg. Damit wird das direkte Verhältnis von PCIe SSDs und Server aufgehoben, in dem sie untergebracht sind. Stattdessen wird der Flash-Speicher als gepoolte Ressource bereitgestellt. PernixData bietet das gleiche Konzept inzwischen auch für Memory-Kapazität und zählt unzweifelhaft zu den Pionieren disaggregierter Produkte. Inzwischen wurde PernixData von Nutanix aufgekauft.

Der zweite Anbieter ist Datrium mit einer Art serverunterstütztem Storage-Produkt. Datrium liefert zwar lediglich Storage-Funktionen und zählt damit nicht zum Hyperconverged-Markt, aber was Datrium anbietet ist sicherlich einzigartig. Dabei werden alle Storage-Funktionen (wie IOPS, Thin Provisioning, Data Protection, Cloning oder auch Snapshots) aus dem proprietären Storage-Array herausgelöst und aufgeteilt auf gewöhnlichen Anwendungsservern ausgeführt. Durch das Ausnutzen der schieren Rechenkraft der Applikations-Server skalieren die auf dem Array ausgeführten Storage-Funktionen mit jedem neuen Anwendungsserver.

Das funktioniert mit traditionellen Storage-Arrays im Grunde genau andersherum, die Datrium-Lösung ist also deutlich kosteneffizienter und einfacher zu verwalten. Wer lieber im herkömmlichen Compute-Netzwerk-Storage-Paradigma bleibt, dem bietet Datrium schon heute ein Storage-Array für die Anforderungen von morgen.

DriveScale als dritter nennenswerter Hersteller konzentriert sich bislang voll und ganz auf Hadoop. Anstatt tausend Nodes mit Compute-Ressourcen und DAS-Storage kaufen zu müssen, ermöglicht es DriveScale, Compute- und Storage-Kapazitäten getrennt zu kaufen und den Anwendungen die Ressourcen bedarfsgerecht bereitzustellen. Damit will DriveScale das Problem lösen, bei Scale-up-Szenarien Compute- und Storage-Kapazitäten nicht getrennt skalieren zu können. Zukünftig dürfte DriveScale auch den Schritt gehen, Arbeitsspeicher zu disaggregieren.

Der technische Fortschritt ist nicht aufzuhalten, und gerade als sich die Branche mit Konzepten von Konvergenz und Hyperkonvergenz zurechtfindet, muss man mit der Disaggregation schon wieder einen neuen Fachbegriff im Auge behalten. Zukünftigen dürften disaggregierte Produkte nämlich enorm an Bedeutung gewinnen.

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

Artikel wurde zuletzt im August 2016 aktualisiert

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close