vladimircaribb - Fotolia
Composable Architektur und traditionelles Storage im Vergleich
Applikationen wie DevOps, AI und Maschinenlernen überfordern die Flexibilität traditioneller Storage-Architekturen und eignen sich daher gut für Composable Infrastrukturen.
Traditionelle Storage-Architekturen wie NAS oder SAN passen gut zu vielen Workloads. Allerdings haben mehrere Faktoren diese Architekturen an ihre Grenzen gebracht: das massive Wachstum sehr vielfältiger Daten, gekoppelt mit modernen Applikationstechnologien und komplexen Workflows.
Um diese neuen Anforderungen besser zu adressieren, implementieren viele IT-Teams Composable-Storage-Architekturen. Sie abstrahieren Speicher und andere physische Ressourcen und liefern sie als Services aus.
Aber bevor Organisationen diesen Weg einschlagen, sollten sie die Vor- und Nachteile von traditionellem Storage im Vergleich zu Composable Infrastructure verstehen.
Traditionelle NAS-Systeme
Storage wird in den meisten RZs als NAS, SAN oder DAS implementiert. Jede Technologie hat ihre eigenen Vor- und Nachteile und sollte individuell evaluiert werden, wenn man traditionelle mit einer Composable Infrastruktur vergleicht. Die drei Infrastrukturen haben teilweise ähnliche Eigenschaften, die man verstehen sollte, wenn man darüber nachdenkt, auf eine Composable Infrastruktur umzusteigen.
In einer NAS-Konfiguration greifen mehrere Anwender und Applikationen auf Daten in einem gemeinsam genutzten Storage-Pool im LAN zu. NAS lässt sich einfach bereitstellen, warten und nutzen und wie SAN kommt es mit eingebauter Sicherheit, Fehlertoleranz und Managementfunktionen. Allerdings ist ein NAS generell kostengünstiger als ein SAN.
Eine technische Herausforderung bei NAS besteht darin, dass Speicheranfragen (Storage Requests) mit anderem Netzverkehr im Wettbewerb stehen, was schlimmstenfalls zur Netzüberlastung führen kann.
Die Alternative besteht darin, NAS auf einem eigenen privaten Netzwerk zu implementieren, allerdings kann das zu mehr Wartungsaufwand und höheren Kosten führen. Und sogar auf einem privaten Netzwerk kann eine zu hohe Anwenderdichte die Storage-Laufwerke überfordern. Zusätzlich skalieren gerade Einsteiger-NAS-Systeme nur begrenzt. Obwohl Hochleistungs-NAS skalierbarer sind, zeigen sich auch hier im Vergleich zum SAN Grenzen.
Traditionelle SANs
IT-Teams, die sich nach besser skalierbarem Storage umsehen, kommen häufig auf die Idee, ein SAN zu nutzen. Das ist ein ausschließlich für Speicherzwecke aufgebautes Hochleistungsnetzwerk. Es verbindet diverse Storage-Systeme und präsentiert sie als Ressourcenpool. Die Storage-Devices teilen sich das Netzwerk mit den Applikationsservern, die den Datenzugriff steuern und auf denen die Storage-Managementsoftware läuft. Ein SAN bietet hohe Verfüg- und Skalierbarkeit, Disaster Recovery und Schutz vor Ausfällen durch blitzschnelles Umschalten auf ein intaktes System (Failover).
Trotz ihres breiten Einsatzes haben auch SANs ihre Probleme. Es kann schwierig sein, sie bereitzustellen und zu warten – häufig sind dafür besondere Fertigkeiten nötig. Schon das treibt die Kosten nach oben. Zudem können SAN-Komponenten recht teuer sein. Und außerdem leisten SANs oft weniger als erwartet, teilweise wegen ihrer Komplexität. Allerdings haben sich SANs in Bezug auf ihre Leistungsfähigkeit erheblich weiterentwickelt.
Die DAS-Option
Sowohl NAS als auch SAN arbeiten über Netzwerkverbindungen. Das kann ihre Leistungen sogar unter den besten denkbaren Bedingungen beeinträchtigen. Deshalb verwenden einige Organisationen für besonders leistungshungrige Lasten Direct Attached Storage (DAS). DAS lässt sich einfacher implementieren und warten als SAN und NAS. Die Technologie umfasst zudem nur wenige Komponenten. All das macht DAS kostengünstiger als NAS und SAN. Einem DAS fehlen zwar komplexere Managementfunktionen, aber Applikationen wie Hadoop oder Kafka verwalten das Storage selbst, deshalb ist das häufig kein Problem.
Die größere Herausforderung bei DAS-Konfigurationen besteht darin, dass Storage-Ressourcen nicht zusammengefasst und gemeinsam genutzt werden können wie bei NAS und SAN. Außerdem ist die Skalierbarkeit begrenzt. Daraus resultieren ein unflexibles Speichersilo und in der Folge überprovisionierte und zu wenig ausgelastete Ressourcen. Aber diese Rigidität gibt es nicht nur bei DAS.
Die inneren Strukturen aller drei Architekturen sind fixiert und schwer veränderlich, jede steckt in ihrem eigenen Silo. Es ist nicht einfach, Konfigurationen zu ändern oder Geräte einer neuen Bestimmung zuzuweisen, damit sie sich den sich stets verändernden Anforderungen moderner Applikationen anpassen. Vielmehr brauchen Unternehmen heute Storage-Ressourcen die sich fließend an die Anforderungen anpassen und Automatisierung sowie die Koordination der Ressourcen untereinander (Orchestrierung) unterstützen. Das schafft traditioneller Speicher allein nicht.
Storage und Composable Infrastructure
Eine Composable Infrastruktur abstrahiert Storage und andere Ressourcen. Sie werden als Services bereitgestellt, die dynamisch zusammengesetzt und verändert werden können, wenn sich die Anforderungen der Applikationen ändern.
Composable heißt so viel wie zusammengesetzt oder zusammensetzbar, was die Flexibilität einer solchen Architektur beschreiben soll. Composable Infrastrukturen unterstützen Anwendungen, die auf Bare Metal, in VMs und in Containern laufen. Werkzeuge von Drittanbietern können über eine API in die Infrastruktur eingebunden werden und dann die gepoolten Ressourcen dynamisch so zuweisen, wie es die jeweiligen Anwendungen brauchen. Das ermöglicht hochgradige Automatisierung und Orchestrierung.
In einer Composable Infrastruktur bleiben die Storage-Ressourcen von den übrigen Ressourcen getrennt und können unabhängig von ihnen skaliert werden. Der Speicher wird bei Bedarf zugewiesen und wieder freigesetzt, wenn er nicht mehr nötig ist, so dass andere Applikationen ihn verwenden können.
Die Composable Software erledigt diese Aufgaben im Hintergrund. Administratoren müssen dafür die Hardware nicht umkonfigurieren. Zudem kann eine Composable Infrastruktur NAS, SAN und DAS in die Umgebung einbinden, nämlich als Teil seines Pools flexibler Storage-Kapazität.
Weil Composable Infrastruktur nicht für bestimmte Workloads vorkonfiguriert ist, kann sie unterschiedliche Applikationen unterstützen, ohne dass man zuvor deren Konfigurationsanforderungen genau kennen müsste. Das führt zu mehr Flexibilität und Auslastung als beim traditionellen Speicher. Eine Composable Architektur vereinfacht den Betrieb, beschleunigt die Bereitstellung, verringert den Verwaltungsaufwand und bietet nahezu unbegrenzte Skalierbarkeit. Storage-Ressourcen können zugewiesen werden, wenn und für so lange man sie braucht.
Herausforderungen von Composable-Infrastrukturen
So gut all das klingt, auch eine Composable Infrastruktur hat ihre Fallstricke. Es handelt sich um eine junge Technologie. Die Software für die freie Zusammenstellung der einzelnen Komponenten nach Applikationsbedarf ist noch nicht ausgereift. Es fehlen Industriestandards und sogar eine gemeinsame Definition der Bedeutung von „Composability“ unter den Herstellern. Sie definieren und implementieren Systeme mit Composable Infrastruktur nach ihren jeweils eigenen Regeln. Das kann zur unerwünscht festen Bindung an einen Hersteller (Lock-in) führen und die Integration mit schon vorhandenen Systemen erschweren.
Eine Composable Infrastruktur ist komplex und möglicherweise schwer bereitzustellen und zu managen. Oft sind spezielle Kenntnisse und Erfahrungen nötig. Viele Organisationen müssen sich für den sinnvollen Einsatz einer Composable Architektur komplett neue Denkkonzepte aneignen und die Geschäftsprozesse an die neue Methodik anpassen. In einem traditionellen Rechenzentrum werden Applikationen als diskrete Operationen entwickelt, getestet und bereitgestellt. Ressourcen werden Stück für Stück zusammengefügt.
In einem modernen Rechenzentrum ist der Applikations-Lebenszyklus ein umfassend vereinheitlichter Prozess, zu dem kontinuierliche Integration und Auslieferung sowie automatisierte Ressourcenzuweisung gehören. Das passt gut zu Composable Architekturen. Ohne ein solches Umdenken riskieren IT-Teams, ein weiteres Storage-Silo aufzubauen.
Trotzdem ist Composable Infrastructure vorteilhaft für vielfältige Workloads. Beispielsweise für KI und Maschinenlernen, die oft eine dynamische Ressourcenzuweisung brauchen, um mit der Verarbeitung der Befehle und dem diskontinuierlichen Datenzufluss fertig zu werden. DevOps-Prozesse wie kontinuierliche Integration und Auslieferung können ebenfalls von einer Composable Infrastruktur profitieren, vor allem, wenn sie zusammen mit Infrastructure as Code benutzt werden. Deshalb ist eine Composable Infrastruktur auch für IT-Teams geeignet, die den IT-Betrieb zunehmend automatisieren wollen.
Tatsächlich sollte jede Organisation eine Composable Infrastruktur in Betracht ziehen, die Applikationen mit unvorhersehbaren oder sich kontinuierlich verändernden Storage-Anforderungen betreibt. Das bedeutet nicht, dass es keinen Platz für traditionelle Storage gäbe. Organisationen, die Applikationen mit stabilen Anforderungen verwenden, deren Betrieb ohne ständige Rekonfigurationen oder Ressourcenzuweisungen auskommt, sind mit traditionellen Technologien gut bedient.
Umstieg auf eine Composable Infrastruktur
Traditionelle Storage-Systeme sind nicht für heutige, moderne Applikationen gemacht. Je dynamischer die Applikationen und je größer und vielfältiger die Datensätze, die sie verarbeiten, desto schwieriger ist passende Hardware dafür zu finden.
Eine Composable Architektur könnte die Komplexität des heutigen Storage-Management effektiver handhaben. Allerdings ist die Technologie noch recht neu. Sie muss sich erheblich weiterentwickeln, bis sie echte freie Konfigurierbarkeit (Composability) über alle üblichen Hardwareprodukte hinweg ermöglicht.
Trotzdem wenden sich immer mehr Anbieter dem Composable-Modell zu. Vielleicht lautet die wichtigste Frage, die sich IT-Teams beim Nachdenken über Composable Infrastrukturen stellen sollten, ob sie bereit sind, sich ein komplett anderes Konzept hinsichtlich der Infrastruktur und der Zuweisung von Storage-Ressourcen anzueignen.