Entwickler treiben die Storage-Evolution voran
In vielen innovativen IT-Umgebungen stoßen monolithische Speicher schnell an ihre Grenzen oder sind gar nicht einzusetzen. Hier bewegt sich der Markt in eine andere Richtung.
Alles entwickelt sich weiter: Menschen und Kulturen, Einstellungen und das Denken. Die Menschheit ist einfach nicht dazu bestimmt, stillzustehen. Und die Unternehmens-IT ist ein perfektes Beispiel dafür.
Der Wunsch nach höherer Leistung in der IT führte schließlich zur Abkehr von Bare-Metal (also der reinen Hardware) und hin zu virtuellen Maschinen (VM), die es Unternehmen ermöglichen, Ressourcen für mehrere Anwendungen mit gegenseitigen Abhängigkeiten besser zu nutzen. Da jedoch viele moderne Cloud-native Anwendungen und Mikroservices Agilität und eine detailliertere Ressourcenzuweisung erfordern, können VMs unhandlich und träge werden und den Wunsch des Entwicklers nach mehr Geschwindigkeit und Effizienz untergraben.
Mit dem Aufkommen der Containertechnologie wurden bereits einige der Probleme von virtuellen Maschinen beseitigt. Angesichts der Kurzlebigkeit von Containern und der Konzentration auf Stateless-Anwendungen wurde jedoch ein wichtiges Feature vernachlässigt: der Storage.
Fehlender Speicher im Container
Container wurden ursprünglich als Stateless-Tools erstellt, die nicht zum Speichern konzipiert waren. Seit der Einführung von Containern haben jedoch viele Entwickler festgestellt, dass der Wunsch nach kleinen, leichten und portablen Lösungen, die nahezu überall laufen können, persistenten Storage erfordert.
Viele Anwendungen müssen ihren Status, die Daten und Konfigurationen permanent sichern. Was würde beispielsweise passieren, wenn ein Service wie Lyft ausgeführt wird, aber während der Fahrt die Cloud-native Anwendung in einem Container verloren geht und dieser woanders neu gestartet werden müsste. Ohne dauerhaftes Speichern würden die Fahrdaten des Kunden verloren gehen, was schlecht für den Kunden ist, aber noch schlechter für den Fahrer. Jeder agile Entwickler und jeder Anwender einer NoSQL-Datenbank versteht auf Anhieb, dass persistenter Speicher für Stateful-Applikationen ein absolutes Muss ist.
Monolithen und Microservices passen nicht zusammen
Leider wurden traditionelle monolithische Storage-Arrays nicht im Hinblick auf heutige Anwendungen entwickelt. Sie sind schwer zu skalieren und die lokale Speicherkapazität ist begrenzt. Herkömmliche Storage-Systeme sind außerdem auch teuer in der Wartung und Weiterentwicklung. Einige sind je nach Alter möglicherweise nicht mehr zu warten, überhaupt nicht mehr aufrüstbar und verursachen hohe Betriebskosten.
Container dagegen ermöglichen eine hochelastische und dauerhafte Speicherung, was letztendlich zu einer neuen Stufe der Evolution geführt hat: Entwickler haben damit begonnen, den Storage bereitzustellen, den ihre Anwendungen tatsächlich benötigen und stellen dadurch sicher, dass diese Applikationen diesen Storage in ihren Containern mounten und nutzen können. Software-defined Storage (SDS) ermöglicht es Anwendungen und Speicher-Management-Komponenten, nebeneinander im Container zu funktionieren. Dadurch wird eine dauerhafte Speicherung im Container gewährleistet, so dass auch bei einem Verlust des Containers oder der Anwendung die Daten erhalten bleiben.
Zentrale Kontrolle
Die Bereitstellung von persistentem Speicher innerhalb von Containern ist bereits ein erheblicher Fortschritt, aber bei Weitem auch nicht die einzige Innovation, die durch eine Paketierung von Storage und Applikationen am selben Ort entsteht.
„Nun gewinnen die Anwendungsentwickler die Kontrolle über das Storage-Management, das bislang in den Händen von Storage-Administratoren lag.“
Irshad Raihan, Red Hat Storage
Denn nun gewinnen die Anwendungsentwickler die Kontrolle über das Storage-Management, das bislang in den Händen von Storage-Administratoren lag. Sie brauchen sich nicht mehr um Probleme wie inkonsistentem persistenten Speicher zwischen Entwicklungs-, Test- und Produktionsumgebungen zu kümmern. Stattdessen bieten Speicher und Applikationen, die innerhalb desselben Containers ausgeführt werden, nun eine einzige Steuerungsebene, über die Entwickler beide verwalten können. Diese ermöglicht ihnen eine weitaus detaillierte Kontrolle, um die Containerleistung zu maximieren und eine hohe Verfügbarkeit zu erreichen.
Wenn Entwickler mehr Speicherkapazität benötigten, mussten sie diese in der Regel beim Storage-Administrator beantragen. Das Problem: meist ließ sich keine gesicherte Prognose abgeben, der Bedarf wurde einfach geschätzt – mit einem ordentlichen Sicherheitspuffer. Im schlimmsten Fall wurde der beantragte Speicherplatz aufgrund mangelnder Ressourcen abgelehnt. Oder er wurde genehmigt, belegte aber unnötig viel Storage-Kapazität. In beiden Fällen ist das Verfahren mangels Flexibilität und Skalierbarkeit wenig effizient, da es Unternehmensressourcen verschwendet.
Mit Open SDS bekommen Entwickler ein Instrument an die Hand, mit dem sich Storage-Kapazitäten den Anforderungen der Anwendung anpassen lassen. Mithilfe eines Orchestrierungs-Frameworks wie Kubernetes können Entwickler den Storage nach oben oder unten skalieren, ohne ein Ticket an den Storage-Administrator senden und auf dessen Erledigung warten zu müssen. Was normalerweise Stunden dauern würde, kann nun in wenigen Sekunden erledigt werden. Auf diese Weise werden Kapazitäten optimal genutzt und ein Over-Provisioning vermieden – und zwar mit einem einzigen Orchestrierung-Framework für die Verwaltung von Anwendungen, Storage und Infrastruktur, unabhängig davon, ob es sich um eine Bare-Metal-Umgebung, VMs oder eine Public- oder Private-Cloud-Infrastruktur handelt.
Die nächste Entwicklungsstufe
Für viele Entwickler war das Thema Storage bislang ein notwendiges Übel, ein wichtiger Baustein zwar, aber vor allem ein potenzielles Hemmnis für die eigene Arbeit.
Mit dem Aufkommen von Containern und Software-defined Storage hat sich das gewandelt. Die Storage-Technologie in den Applikationsentwicklungsprozess zu integrieren, hat die Tür geöffnet zu neuen Projekten und Tools – von großen Projekten, die viel Planung, Überprüfungszyklen und Kapitalaufwand erforderten, hin zu kleinen, agilen Anwendungen und Diensten.
Der Entwicklungsprozess steht dennoch erst am Anfang. Das bedeutet aber auch, dass Entwickler die Möglichkeit haben, Dinge völlig neu zu gestalten. Gleichzeitig haben Unternehmen die Wahl, wenn es um ihre Storage-Prozesse geht: Setzen sie weiterhin auf traditionelle Speichermethoden, die sie kennen und seit vielen Jahren verwenden? Oder setzen sie auf einen modernen SDS, mit dem sie ihren Return on Investment in VMs und Containern maximieren können – und gehen damit den nächsten Schritt in der Storage-Evolution.
Über den Autor:
Irshad Raihan ist Director of Product Marketing bei Red Hat Storage.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
