Container Attached Storage: Storage in Containern

Einstieg in Container Attached Storage

Container Attached Storage (CAS) ermöglicht eine Architektur, in der Speicher in den Containern bereitgestellt wird. Der jeweilige Speicher ist mit der Anwendung verbunden und steht ebenfalls als Microservice zur Verfügung. Es gibt keinerlei Abhängigkeiten vom Kernel-Modul. Diese Vorgehensweise macht die Verwaltung von Storage in Microservices-Umgebungen sehr flexibel, da Orchestrierungslösungen wie Kubernetes Speicher-Volumes (Persistent Volumes, PV) genauso verwalten können, wie andere Container.

CAS ist auch ideal für Workloads in Microservices, die nur eine Zeitlang benötigt werden, zum Beispiel für Analysezwecke. Häufig sind die Daten danach nicht mehr notwendig und das System löscht diese. Neben systemunkritischen Anwendungen lassen sich mit Systemen wie OpenEBS auch hochverfügbare und wichtige Anwendungen betreiben.

Die Abhängigkeit der Microservices von der Speicherstruktur kann durch CAS aufgelöst werden. Damit CAS auch in diesen Anwendungen sinnvoll einsetzbar ist, sollte die Lösung mehrere Bedingungen erfüllen:

• CAS sollte den Pass-Through-Modus unterstützen (LocalPV).
• CAS sollte auch Multi-Node-HA mit LocalPV-Geschwindigkeit unterstützen.
• Die CAS-Software sollte Cloud-nativ sein und verschiedene Daten-Engines unterstützen, um möglichst flexibel zu sein.
• Um eine Abhängigkeit von Herstellern zu vermeiden, ist es sinnvoll auf Open Source zu setzen.

Ein weiterer Vorteil beim Einsatz von CAS ist der vermeidbare Lock-in bei Storage-Lösungen. Greifen Microservices direkt auf das Storage zu, sind sie von der Architektur, teilweise dem Hersteller, und auch von der Konfiguration der Clusterknoten abhängig.

Beim Einsatz von CAS kommunizieren die einzelnen Microservices nur mit dem CAS-Controller. Welche Speichertechnologie dem zu Grunde liegt spielt für den Microservice keine Rolle. Das heißt, der tatsächliche Speicher in der Umgebung kann jederzeit angepasst, skaliert und verändert werden, ohne dass die Microservices davon beeinträchtigt werden.

Wenn Container Attached Storage so aufgebaut ist, dass es nicht auf Kernel-Modifikationen angewiesen ist, kann es den Workloads über Clouds hinweg folgen. Es ist also problemlos möglich, Microservices über diesen Weg beliebig zu verschieben. Wichtig ist nur, dass die Umgebung mit Kubernetes verwaltet wird.

Microservices-Umgebungen und monolithischer Speicher

Bei herkömmlichen Speichersystemen besteht in einer Microservices-Umgebung der Nachteil, dass der Speicher noch eng mit dem Kernel des Host-Betriebssystems verbunden ist. Das bedeutet, dass die Microservices-Umgebung in dieser Hinsicht unflexibel ist, da der Speicher monolithisch ist.

Durch die Einbindung des Storage in Container, kann auch die Storage-Struktur als Microservice genutzt werden. Wenn eine Anwendung als Microservice betrieben wird, der von ihr verwendete Speicher aber monolithisch ist, verliert die Anwendung ihren Vorteil, da ein Betrieb ohne Storage in den meisten Fällen nicht möglich ist.

Entwickler haben beim Einsatz von CAS den Vorteil, dass sie sich keine Gedanken darüber machen müssen, auf welchem Speichersystem das Storage zur Verfügung gestellt ist, der in der Container-Anwendung genutzt wird. Der Speicher wird durch OpenEBS im Pod bereitgestellt, und kann durch die Anwendungen genutzt werden. CAS unterscheidet nicht zwischen Cloud-Speicher, lokalen Festplatten, SAN, NAS oder anderen Systemen. Im CAS ist der Storage definiert und steht über Zuweisung den Containern zur Verfügung. Es spielt keine Rolle, wo sich der Speicher befindet. Die CAS-Container sind die Basis, die Microservices-Entwickler nutzen.

OpenEBS bindet Storage in Kubernetes ein

CAS will die Abhängig der Container von Storage auflösen, in dem auch das Storage selbst in einen Container verlagert wird. Natürlich kann nicht jeder Speicher auch als Microservice eingesetzt werden. Ein bekanntes Beispiel ist die Open Source OpenEBS der Cloud Native Computing Foundation (CNCF).

Die Lösung ermöglicht die Integration von Storage in Kubernetes. Im Fokus der Lösung stehen Persistent Volumes (PV). Dabei handelt es sich um einen Teil des Speichers in einem Kubernetes-Cluster, der zum Beispiel über Speicherklassen definiert ist. PV ist eine Ressource im Cluster, die sich zwischen den Knoten verschieben lässt, genauso wie die Container. Dazu wird OpenEBS im Userspace betrieben.

Der generelle Lebenszyklus von PV ist aber nicht abhängig von Pods in Kubernetes. Mit OpenEBS ist es möglich die PVs mit Pods zu verknüpfen und dadurch auch mit den Containern in den Pods. Auch in Cloud Storage ist es möglich, OpenEBS zu integrieren und dadurch auch automatisches Provisioning von Storage zu ermöglichen. OpenEBS unterstützt auch den Einsatz mehrerer Clouds (Multi-Cloud). Die Installation kann mit einer Zeile durchgeführt werden:

helm install stable/openebs --name openebs --namespace openebs

OpenEBS-Alternativen: PortWorx und StorageOS

Neben OpenEBS gibt es im CAS-Bereich auch noch Lösungen von PortWorx und StorageOS. Auch bei StorageOS greifen die Microservices in den Containern nicht direkt auf den Speicher des Clusters zu, sondern nutzen den StorageOS-Pool, der als Zwischenschicht dient. StorageOS fasst dazu den kompletten Speicher im Cluster zu einem Pool zusammen. Hier setzt die Lösung auch auf Thin Provisioning. Das bedeutet, dass Container nur den tatsächlichen Speicherplatz zugewiesen bekommen, den sie auch brauchen. Das vermeidet Speicherverschwendung.

Die Container kommunizieren mit dem ihnen zugewiesenen Speicher im Pool. Dazu erstellt StorageOS Volumes in einem Pool und stellt diese den Containern bereit. Der Container selbst weiß nicht auf welchem Storage im Cluster die Daten gespeichert werden. Auch PortWorx funktioniert nach diesem Prinzip.

Fazit

In agilen Microservices-Umgebungen sind Container-Attached-Storage-Lösungen (CAS) in Zukunft kaum mehr wegzudenken. Die Abhängigkeit von Microservices und deren Container wird durch diese Lösungen deutlich reduziert. Die Container werden unabhängiger und wesentlich flexibler.