München, Starnberg, 9. Aug. 2016 - Container gelten als Schlüsseltechnologie, die den Übergang zu Microservices ermöglichen. Ein Fachbeitrag von Red Hat Storage...
Zum Gastbeitrag: "Persistenter Storage für Container, hyperkonvergente Infrastrukturen und Object Storage zählen zu den wichtigsten Trends, die Unternehmen beim Einsatz von Linux im Storagebereich berücksichtigen sollten. Die Container-Technologie gewinnt im Linux-Umfeld immer stärker an Bedeutung. Obwohl die Container-Idee nicht neu ist, hat sie mit dem Aufkommen neuer Technologien zunehmend an Bedeutung gewonnen. Heute befasst sich nahezu jeder größerer Softwarehersteller mit Container-Technologien.
Zu den zentralen Merkmalen von Containern zählt die Isolierung der Laufzeitumgebung und die Ressourcenkontrolle. Mittlerweile gibt es das standardisierte Open-Container-Format. Vorbild dafür sind die seit den 1950er-Jahren gebräuchlichen Industrie-Container. Sie sind standardisiert und genormt und werden zum Gütertransport per Schiff oder Lkw genutzt. Dieser Ansatz hat sich heute auch in der Anwendungsentwicklung etabliert. Die Stärke von Containern ist die Kapselung von Applikationslogik. Die nächste Entwicklungsstufe in Richtung Vereinfachung und Standardisierung zeichnet sich bereits ab. Im Laufe der Zeit werden sich Applikationen, die aus großen, komplexen Codeblöcken bestehen, in kleinere, unabhängig voneinander implementierbare Konstrukte – sogenannte Microservices – verwandeln.
1. Container gelten als Schlüsseltechnologie auf dem Weg zu Microservices
-
Die Entwickler können sich mit Containern ihre virtuelle Server-Umgebung auf Basis von einfach zu erzeugenden Microservices selbst erstellen und sie sind dabei nicht mehr auf die Kollegen vom IT-Betrieb angewiesen. Damit wird eine vereinfachte Abstimmung zwischen der Applikationsentwicklung und dem IT-Betrieb möglich. Im Ergebnis führt dies zu kürzeren Testzyklen, einer höheren Softwarequalität und einem vereinfachten Applikations-Management. Container-Technologie schafft nach und nach die Voraussetzungen für eine schnellere Bereitstellung von Applikationen.
-
Gleichzeitig mit der Verbreitung der Container-Technologie in den Unternehmen erwarten IT-Administratoren eine Funktionalität, wie sie diese aus virtualisierten Umgebungen gewohnt sind. Eine der wichtigsten Anforderungen ist persistenter Storage. Lange Zeit gab es jedoch keine überzeugende Lösung, um Applikationsdaten über den gesamten Lebenszyklus eines Containers zu speichern. Flüchtiger, lokaler Speicher reicht nicht aus. Zustandsbehaftete (stateful) Applikationen erfordern jedoch, dass Daten auch über den Lebenszyklus eines Containers hinaus verfügbar sind. Zwar erfüllen Cloud-Storage-APIs diese Anforderungen, aber nicht jeder will seine Anwendungen auf Cloud-APIs umschreiben und nicht jeder will oder darf seien Daten in der Cloud speichern.
-
Mit einer eingebauten Hardwareunabhängigkeit und Flexibilität wird Software-defined Storage den Herausforderungen besser gerecht. Software-defined Storage lässt sich in physischen Umgebungen, virtualisiert und in der Cloud einsetzen – und zwar wesentlich einfacher als traditionelles monolithisches Storage. Es unterstützt sowohl gängige Storage-APIs, wie zum Beispiel POSIX, als auch Block und Object Storage. Um persistente Daten für Applikation-Container bereitzustellen, lassen sich zwei Optionen unterscheiden: Shared Storage und Storage-Container.
Abb. 1: Zentrales Merkmal von Containern ist die Isolierung der Laufzeitumgebung und die Ressourcenkontrolle (Quelle: Red Hat).
Shared Storage für Applikations-Container
-
Mit einem verteilten Filesystem, das Speichergrößen im Petabereich unterstützt, lassen sich gemeinsam genutzte Daten oder auch Konfigurationsdaten für Stateful Container bereitstellen. In einem solchen Fall kommt es den Applikationen nicht auf einen isolierten Datenspeicher an. Sie benötigen vielmehr ein Shared Persistent Filesystem zur Speicherung und gemeinsamen Nutzung der Daten durch mehrere, auf verschiedenen Hosts verteilte Applikations-Container. Weit verbreitet sind Implementierungsmodelle, bei denen große Datenmengen von mehreren Clients beziehungsweise Tenants gemeinsam verwendet werden wie zum Beispiel zur Datenanalyse.
-
Einige Applikationen benötigen jedoch eine Datenisolierung oder nur eine geringe Speicherkapazität für individuelle Applikations-Container. In diesem Fall kann Red Hat Storage auch Block Devices über ein Cluster-Orchestrierungs-Framework wie Kubernetes bereitstellen. Zudem lässt sich die weit verbreitete S3-Storage-API für Object Storage und den Zugriff auf persistenten Speicher in Applikations-Containern einsetzen. In konventionellen Implementierungen, bei denen Applikations-Container auf eigens dafür optimierten Infrastrukturplattformen laufen, kommen zum Zugriff auf Storage Cluster oder Storage Appliances Protokolle und Schnittstelen wie NFS, iSCSI oder Fibre Channel zu Einsatz. Storage wird dabei im File- oder Block-Format bereitgestellt. Storage Appliances stehen im deutlichen Gegensatz zum dynamischen Ansatz von Containern. Mit traditionellen Storage-Lösungen geht es meist nicht so leicht, schnell einmal ein paar zusätzliche Storage-Einschübe hinzufügen, um eine neue Multi-Tier-Anwendung zu testen. Eine Software-basierte Storage Lösung hat hier erhebliche Vorteile.
2. Storage-Container und Hyperkonvergenz
-
Der Wechsel auf Microservices-getriebene Architekturen wird auch die Art der Bereitstellung von Storage ändern. Je stärker sich Microservices durchsetzen, desto wichtiger wird die zentrale Verwaltung von persistentem Storage über eine einheitliche Steuerebene (Control Plane). Dies bedeutet, dass die Storage-Plattform selbst containerisiert wird – Storage steht dann als Microservice über dedizierte Storage-Container bereit. In einem künftigen Szenario könnten dann beispielsweise in OpenShift, einer Open-Source-Container-Applikationsplattform, neben Applikations-Containern auch Storage-Container bereitstehen, die über das Orchestrierungs-Framework Kubernetes verwaltet werden.
-
Container-Images von Red Hat Storage stehen bereits jetzt als Tech-Previews zur Verfügung. Als hyperkonvergentes Konstrukt können Kubernetes-Knoten Storage- und Applikations-Container ausführen. Storage-Container könnten dann zum Beispiel als Red Hat Gluster Storage Bricks implementiert werden, aus denen zusammen genommen ein hochverfügbares GlusterFS Volume entsteht. Über dieses Volume lassen sich dann die Storage-Anforderungen einzelner Server-Knoten bedienen. Anders ausgedrückt besteht dann kein Bedarf mehr für dedizierte Storage-Hardware. Auf dem gleichen Knoten, auf dem eine Infrastrukturplattform für den Betrieb von Applikations-Containern läuft, können auch Storage-Container implementiert werden. Als Speicherkapazitäten werden die jeweils in den Applikations-Servern verbauten Festplatten beziehungsweise die SSDs genutzt und nach dem Scale-Out-Ansatz in einem Pool gesteuert. Es wird ein kompletter Storage-Layer eingespart und die Storageschicht wird – zumindest teilweise – von Kubernetes mitverwaltet.
Abhängig von der Systemkonfiguration können in diesem Szenario einige Container als reine Storage-Container, einige als Applikations-Container und ein dritte Gruppe als hyperkonvergente Storage- und Applikations-Container laufen. Über das Orchestrierungs-Framework Kubernetes lassen sich bei Bedarf zusätzliche Storage-Container starten oder nach dem Ausfall eines Knotens automatisch wieder herstellen. In Spitzenzeiten aktiviert ein Administrator weitere containerisierte Server-Instanzen und bei einem Hardwareausfall werden zuvor deaktivierte Applikations- und Storage-Container wieder gestartet.
Mit hyperkonvergenten Speicherlösungen in Form von Storage-Containern können Entwickler künftig Speicherkapazitäten deutlich granularer als heute steuern und überwachen. Auch aus DevOps-Aspekten bringt hyperkonvergenter Storage Vorteile, denn Storage- und IT-Administratoren sind dann in der Lage, Rechen- und Speicherkapazitäten zu verwalten.
Abb. 2: Hyperkonvergente Container inklusive Storage ermöglichen eine einheitliche Orchestrierung und führen zu niedrigeren Total Cost of Ownership. Quelle: Red Hat.
3. Object Storage
Das explosionsartige Wachstum bei Bildern, Videos, E-Mails, technischen Dokumenten und Sensordaten, wie sie im Internet der Dinge entstehen, stellt die IT in den Unternehmen vor erhebliche Herausforderungen. Bis zu 90 Prozent der anfallenden Datenmenge gehört in die Kategorie der wenig strukturierten Daten. Klassische Storage-Systeme können mit deren Speicherung überfordert bzw. oft zu teuer sein. Software-defined Storage bietet die deutlich effizienteren Methoden, um die kaum strukturierten Daten unabhängig von der Hardware in einer verteilten Server-Architektur als gemeinsam zugänglichen Speicherpool abzulegen.
Abb. 3: Red Hat Ceph Storage vereint Objekt- und Block-Storage auf einer Plattform. Quelle: Red Hat
-
Entstanden sind die Object-Storage-Systeme als Reaktion auf die fehlende Skalierbarkeit von File- und Block-basierten Systemen beim Umgang mit hohen Mengen von unstrukturierten Daten. Zusätzlich zu den eigentlichen Informationsinhalten enthalten objektbasierte Lösungen auch Metadaten, die zum Beispiel zur Klassifizierung der Daten verwendet werden können. Mit Hilfe der Representational-State-Transfer (REST)-Architektur wird eine Abstraktion des Datenzugriffs von der Applikation umgesetzt. Unternehmen, die vorhandene Speicherkapazitäten in OpenStack-basierende Public Clouds verlagern oder dort neue aufbauen, nutzen oft das OpenStack- Swift-API, welches vergleichbar mit dem AWS S3-API ist.
-
In Linux-basierenden On-Premise-Umgebungen ist häufig Red Hat Ceph Storage anzutreffen. Zur Speicherung werden die Daten in binären Objekten abgebildet, die sich in eine Vielzahl kleiner Segmente aufspalten lassen. Die Software speichert diese verteilt über mehrere Orte um die Redundanz sicherzustellen. Objektspeicher können damit deutlich effizienter und flexibler arbeiten als klassische Storage-Lösungen, die beispielsweise an die starre Einteilung in Blöcke gebunden sind. Object Storage ist derzeit das am stärksten wachsende Storage-Segment. Gerade im Container-Context lässt sich Object Storage sehr wirkungsvoll einsetzen."
Autor des Beitrages ist Herr Gerald Sternagl, Red Hat EMEA Business Unit Manager Storage.
Mehr Informationen und Vortrags-PDFs zu Object Storage, Hyperkonvergenz, Software Defined Storage und Flash finden Sie als registrierter Benutzer unserer Webseite auch unter folgendem Weblink: