CNCF-Open Source für ein virtuelles Storage-Management Storage in Container-Umgebungen – Kubernetes mit OpenEBS

Mit „OpenEBS“, einem Projekt des CNCF, ist es in „Kubernetes“ möglich, Speicher über Container zu virtualisieren. Dadurch können Storage-Bereiche auch für Stateful Applications mit Containern bereitgestellt werden.

Anbieter zum Thema

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Schwarz IT KG

OpenEBS ist eine Open-Source-Lösung, mit der Storage über Container-Umgebungen bereitgestellt werden kann. Die Open-Source-Anwendung kann Container-Attached-Storage-Funktionen (CAS) in Kubernetes bereitstellen. Dadurch wird die Verbindung von Anwendungen und Storage in Container-Umgebungen unabhängig vom physischen Datenspeicher gemacht.

OpenEBS bezeichnet ist beschrieben als „Leading Open Source Container Attached Storage“. Der Quellcode steht auch in Github zur Verfügung. Die Storage-Anwendung kann zustandsbehaftete Anwendungen (Stateful Applications) unterstützen und deren Speicher über Container bereitstellen. Die Anwendungen werden dadurch flexibler nutzbar und unabhängiger von der Hardware.

Das ist Container Attached Storage (CAS)

Container Attached Storage (CAS) soll das Problem lösen, dass Storage in Container-Umgebungen immer noch von Hardware und Speicherort abhängig ist. Da immer mehr Umgebungen agil betrieben werden und Container weit verbreitet sind, ist die Integration des Storage-Systems in die Container-Umgebung enorm wichtig, um Anwendungen durch das Abschaffen der Abhängigkeit von der Storage-Hardware flexibler zu gestalten.

Unter dem Strich bringt es einer Anwendung keinen Vorteil, wenn sie in einer Container-Umgebung betrieben wird und gleichzeitig abhängig von einer Storage-Technik ist, die außerhalb der Container-Umgebung positioniert ist. Systeme wie „NFS“, „GlusterFS“, „Azure Disks“, „Amazon EBS“ und andere Storage-Möglichkeiten sind außerhalb der eigentlichen Container-Umgebung positioniert und werden als externe Ressource in die Umgebung eingebunden.

Teilweise kommen in Container-Umgebungen auch Persistent Volumes (PV) zum Einsatz. Allerdings sind auch diese eng mit den zugrundeliegenden Modulen gekoppelt. Auch PVs sind daher eher monolithisch und nicht ideal für Container-Umgebungen, vor allem im Vergleich zu CAS. PVs können aber auch mit OpenEBS bereitgestellt werden und erhalten dadurch einen Mehrwert.

Einfacher umziehen

Zwar könnten theoretisch die Anwendung und ihr Container schnell und einfach umziehen, allerdings ist das praktisch eher schwer möglich, da der zugrundeliegende Datenspeicher, den die Anwendung ebenfalls benötigt, nicht flexibel ist und daher nicht so einfach umziehen kann. Genau dieses Problem soll CAS beheben.

CAS stellt einzelne Speicherbereiche als Microservices bereit, sodass diese in die Container-Umgebung integriert werden können. Dazu stellt Speicher mit seiner Datenebene über Pods in der Container-Umgebung bereit. Die Datenebene und die mit ihr verbundenen Pods stellen den Anwendungen Speicher zur Verfügung.

Gesteuert wird diese Funktion von der Steuerebene im CAS. Steuerebene und Datenebene sind voneinander getrennt. Dadurch wird die Portabilität von Workloads und dem dazu notwendigen Speicher ermöglicht. OpenEBS stellt ein solches CAS dar, mit dem in hyperkonvergenten Umgebungen Storage auch fehlertolerant bereitgestellt werden kann.

Optimierter Storage für Container-Umgebungen

Einfach ausgedrückt, ermöglicht OpenEBS die Bereitstellung von Storage für Container-Anwendungen. Der Storage ist dabei unabhängig von der Hardware, da er ebenfalls containerisiert wird. Dazu nutzt OpenEBS die Container-Verwaltung Kubernetes.

Die Software bindet sich dazu als Service ein, um sich selbst als Container den Anwendungen in der Umgebung zur Verfügung zu stellen. OpenEBS stellt also nicht nur eine für Container optimierte Storage-Umgebung zur Verfügung, sondern wird selbst als Microservice in die Umgebung integriert.

Der Vorteil besteht zusätzlich darin, dass OpenEBS den Stateful Applications (zustandsbehaftete Anwendungen) Storage ähnlich wie Cloud-Storage zur Verfügung stellt, ohne sich von einem Cloud-Anbieter abhängig machen zu müssen. Der Storage kann zusammen mit den verbundenen Anwendungen betrieben werden und daher auch problemlos zwischen Hosts oder Cloud-Anbietern umziehen. OpenEBS kann in lokalen Clustern eingesetzt werden, aber auch in öffentlichen oder hybriden Cloud-Infrastrukturen.

OpenEBS mit Prometheus

Die Steuerebene in OpenEBS verwaltet den Lebenszyklus des Datenspeichers, auf dem die Daten abgelegt werden, die durch die Datenebene von den Container-Anwendungen kommen. Hier lassen sich SANs, Blockspeicher oder andere Umgebungen einbinden. Mit OpenEBS können Snapshots erstellt werden, und das Klonen ist möglich. Außerdem sind Speicherrichtlinien und das Exportieren von Daten in externe Systeme möglich. OpenEBS unterstützt in diesem Bereich auch Prometheus.

Bei Prometheus handelt es sich ebenfalls um ein Projekt der Cloud Native Computing Foundation (CNCF). Prometheus speichert die Daten zur Überwachung in seiner Zeitreihendatenbank. Daher ist das System ideal, wenn es darum geht, Metriken von Systemen in großer Anzahl zu überwachen. Prometheus und OpenEBS arbeiten eng zusammen.

Der Node Device Manager (NDM) ist eine Komponente der OpenEBS-Kontrollebene. Die einzelnen Knoten im Kubernetes-Cluster führen jeweils einen NDM-Daemon aus. Dieser erkennt den physischen Speicher, den die Datenebene den Containern zur Verfügung stellt. NDM ist in der OpenEBS-Umgebung der Vermittler zwischen Steuerebene und den physischen Datenträgern, die an die Knoten und den Kubernetes-Cluster angeschlossen sind. Die Container kommunizieren wiederum mit der Datenebene, welche die Storage-Pods bereitstellt.

Storage-Engines in OpenEBS

Die OpenEBS-Datenebene unterstützt die Speicher-Engines „cStor“, „Jiva“ und “Local PV“. Empfohlen wird der Einsatz von cStor. Diese Engine ist für Datenbanken ideal, die in Container-Umgebungen hochverfügbar betrieben werden sollen, und bietet die meisten Funktionen. Mit cStor können Snapshots, Cloning, Thin Provisioning und Replikation genutzt werden. Die Engine nutzt drei Replikate, um die Hochverfügbarkeit in der Umgebung zu gewährleisten.

Jiva ist einfach in der Umsetzung und unterstützt lediglich Standardaktionen in Blockspeicherumgebungen. Die Engine wird eher für kleine Umgebungen genutzt.

Local Persistent Volume (Local PV) nutzt einen lokalen Datenspeicher und ist die einfachste Engine in OpenEBS. Diese Engine kommt vor allem dann zum Einsatz, wenn kein Blockspeicher oder SAN zur Verfügung stehen, sondern in Kubernetes die Clusterknoten lokalen Datenspeicher nutzen sollen.

Fazit

Unternehmen, die Container-Umgebungen betreiben und sicherstellen wollen, dass ihre Anwendungen unabhängig von der Storage-Hardware werden, sollten sich die Möglichkeiten von OpenEBS anschauen und den Nutzen, den die Open-Source bietet, in ihre Umgebung integrieren. Mit dem CAS-System kann die Abhängigkeit von Container-Anwendungen zu ihrem Datenspeicher deutlich reduziert bis abgeschafft werden.

* Der Autor, Thomas Joos, ist Berater und Autor zahlreicher Fachbücher und -artikel. Auf DataCenter-Insider schreibt er seinen eigenen Blog mit Tipps und Tricks für Administratoren*innen „Toms Admin-Blog“.

(ID:47436026)