Traditionell wurde Software mit dem Ziel entwickelt, auf einem System installiert und betrieben zu werden – sei es nun ein Mainframe, PC oder Server. Die Software hatte Mindestvoraussetzungen an das System, auf dem sie laufen sollte. Änderten sich die, musste die Hardware angepasst werden. Mit dem Siegeszug der Cloud rückten jedoch Skalierbarkeit, Hochverfügbarkeit und Portabilität in den Vordergrund. Um auf geschäftliche Anforderungen reagieren zu können, Kosten zu senken und flexibler zu werden sollte sich Software zwischen unterschiedliche Plattformen und Infrastrukturen umziehen lassen – und zwar möglichst ohne Zeitverlust.

Die Software jeweils an die Voraussetzungen für das Deployment und den Betrieb der neuen Plattform anzupassen, kommt dafür nicht infrage. Es wäre zu aufwändig und würde zu lange dauern. Außerdem wäre schnell eine nicht mehr beherrschbare Komplexität die unabwendbare Folge.

Unternehmen setzen wegen DevOps, Microservices und Cloud-Nutzung verstärkt auf Container. Bei Storage hat die Technologie aber noch Tücken (Bild: Canva Pro)

Was ist die Container-Technologie?

Die Lösung lehnt sich an einem Konzept an, das sich in der Logistik bewährt hat: dem Container. Er lässt sich auf unterschiedlichen Plattformen (LKW, Schiff, Eisenbahn) transportieren, durch sein standardisiertes Format schnell und einfach umladen, ist als Größe berechenbar und kann dennoch flexibel beladen werden. Genau das suchte man auch für die IT. Due grundsätzlich schon länger vorhandenen Möglichkeiten rückten ab 2013 mit dem Open-Source-Projekt Docker stärker in den Vordergrund.

Angesichts der Anforderungen beim Aufbau und Betrieb von Cloud-Rechenzentren ist es selbstverständlich, dass sich Applikationen, die in einem Container organisiert sind, automatisiert bereitstellen lassen müssen – ohne viel Rücksicht auf die konkrete Umgebung nehmen zu können. Geschwindigkeit und niedriger Aufwand sind Trumpf. Unternehmen setzen wegen DevOps, Microservices und Cloud-Nutzung verstärkt auf Container. Bei Storage hat die Technologie aber noch Tücken.

Dazu wird nur die erforderliche Anwendung mit den notwendigen Abhängigkeiten in einem Container gekapselt. Der verwendete Linux-Kernel erlaubt es, Prozessor, RAM, Netzwerk und Speicher voneinander zu isolieren und Applikationen unabhängig von der jeweiligen Umgebung, etwa dem Dateisystem oder der Netzwerkverbindung, zu betreiben. Der Container lässt sich so auf jedem beliebigen System autonom ausführen. Er bringt alles mit, was er zur Erledigung seiner Aufgabe benötigt – aber eben auch nicht mehr.

Container-Engine und Container-Image

Anders gesagt führt eine Container Engine ein Container Image aus und erst daraus entsteht das, was landläufig als »Container« bezeichnet wird. Die bekanntesten und gängigsten Container Engines sind Docker, das von Red Hat initiierte CRI-O, rkt (ausgesprochen: »rocket«), die Container-Engine des Betriebssystems CoreOS sowie das von Canonical betreute LXC (Linux Container).

Die relevanten Container-Image-Formate sind Docker, das zu rkt gehörende Appc und das LXC begleitende LXD. Um Interoperabilität und Standardisierung kümmert sich die Open Container Initiative, in der inzwischen alles vertreten ist, was in der IT Rang und Namen hat. Auch dank der dort erarbeiteten Spezifikationen hat sich ein ganzes Ökosystem mit Tools und Services für Management, Orchestrierung, Monitoring, Sicherheit und Networking gebildet.

Unterschiede zwischen Container und Virtual Machines

Alexander Best, Datacore»Container sind der nächste Schritt der Virtualisierung«, sagt Alexander Best, Director Technical Business Development bei Datacore Software. Best erklärt das mit einem kurzen Rückblick auf die Entwicklung: »Wir hatten bei Servern üblicherweise eine CPU-Auslastung von fünf bis zehn Prozent. Der Schritt zur Virtualisierung hat gebracht, dass wir heute Server-Auslastungsraten von 60 Prozent und höher erreichen. Trotzdem gibt es noch eine Lücke: Die Leistung wird immer größer und es ist sehr schwierig, die virtuellen Maschinen zu verwalten, da wir immer noch das Betriebssystem mitschleppen. Der nächste Trend ist daher, zu containerisieren, also nicht mehr die Maschine zu virtualisieren, sondern die Applikation zu abstrahieren, sie portabel zu halten und damit selbst den ganzen Overhead der virtuellen Maschine noch zu entkoppeln.«

Ein weiterer wichtiger Punkt ist, dass alle von einer Applikation auf einer Virtual Machine (VMs) benötigten Ressourcen ihrerseits für zahlreiche und große Abhängigkeiten sorgen. Ein Container umfasst dagegen nur die eigentliche Applikation und deren Abhängigkeiten. Ausgeführt wird er auf dem Host-Betriebssystem als isolierter Prozess. Zwar teilt er sich den Linux-Kernel mit anderen Docker-Containern, aber durch die strikte Isolation können mehrere Container auf dieselben Kernel-Ressourcen zugreifen. Dabei lässt sich für jeden Container definieren, wie viele Ressourcen er bekommen darf.

Das Container-Image ist eine Datei, die sich einfach von einem System auf ein anderes übertragen lässt. Statt Installation, Update und später Deinstallation wie bei einer virtuellen Maschine findet hier nur ein Kopiervorgang statt. Da sich aus einem Container Image heraus beliebig viele Container starten lassen, sind Container gut und schnell skalierbar. Schreibzugriffe verändern nicht das Container Image, sondern jeweils ein eigenes Dateisystem. Hat der Container seine Aufgabe erfüllt, wird er gelöscht. Von ihm bleibt dann nichts im System zurück.

VMs und Container bedienen unterschiedliche Abstraktionsebenen

Mit VMs lassen sich ganze Systeme isolieren, mit Containern dagegen einzelne Anwendungen. Damit agieren VMs und Container auf unterschiedlichen Abstraktionsebenen. Zwar lassen sich beide Techniken zum Verpacken und Verteilen von Software nutzen, sie sind aber keine Konkurrenten. Sie ergänzen sich vielmehr und erfüllen unterschiedliche Zwecke: Virtuelle Maschinen ermöglichen die bessere Ausnutzung der vorhandenen Infrastruktur. Container erlauben es dagegen, komplexe Software aus kleinen Blöcken zusammenzusetzen, um Architekturansätze wie Microservices und verteilte Software zu unterstützen und Services schnell einzurichten und zu skalieren.

VMs werden überwiegend einmal erstellt und anschließend lange Zeit genutzt und verwaltet. Bei ihrer Behandlung und Wartung gehen die Anwender meistens noch so vor, als ob sie mit physischen Servern arbeiten. Container dagegen sind Gebrauchsgegenstände. Sie werden je nach Bedarf genutzt und verworfen - und das möglichst automatisiert.

Welche Container-Anwendungen sollte man kennen?

Die meistgenutzte Lösung im Container-Umfeld ist die Open-Source-Software Docker. Sie ermöglicht Bereitstellung, Isolierung und Verwaltung von Anwendungen. Die Software findet sich einer dieses Jahr von Techconsult im Auftrag des IT-Dienstleisters Cronon durchgeführten Umfrage zufolge in 38 Prozent der befragten Unternehmen und wird von 46 Prozent der Software-Entwickler bevorzugt.

LXC setzt 2020 demnach rund ein Drittel der befragten Unternehmen zur containerbasierten Virtualisierung innerhalb des Linux-Kernels ein. Ein Viertel der Befragten verwendet zur Einrichtung ihrer Container-Umgebung OpenShift. Für die Verwaltung von Containern sind Docker Swarm (18 Prozent), Kubernetes (17 Prozent) am weitesten verbreitet. Außerdem wird das Automatisierungs-Tool Packer (17 Prozent) häufig genutzt

Der Cluster-Manager Swarm ist seit Docker-Version 1.12.0 als Swarm-Mode nativer Teil der Docker-Engine. Das von Red Hat entwickelte Openshift ist eine Kubernetes-Plattform für die Ausführung von Containern im großen Maßstab ohne Ausfallzeiten. Es legt den Schwerpunkt auf Sicherheit und erleichtert die Orchestrierung von Containern in großem Maßstab, unter anderem durch Lastverteilung, automatische Skalierung von Apps und Ressourcen für die Erstellung von Container-Images.

Packer hilft dabei, identische machine images zu erstellen, die trotz einer Grundkonfiguration auf verschiedenen Plattformen laufen. Diese Machine-Images beinhalten ein vorkonfiguriertes Betriebssystem und installierte Software. Ziel ist es, neue running Machines möglichst schnell zu erstellen. Außerdem lässt sich Packer verwenden, um zum Beispiel Docker Images zu erstellen und wurde in der Umfrage wahrscheinlich auch deshalb relativ oft genannt.

Ebenfalls noch eine gewisse Bedeutung hat Apache Mesos. Dieser Open-Source-Cluster-Manager versorgt Applikationen mit APIs für Verwaltung und Scheduling. Mesos erlaubt es, sowohl containerisierte als auch nicht-containerisierte Workloads in einer verteilten Umgebung auszuführen. Dabei hilft das Container-Orchestration-Framework Marathon, das auf Mesos läuft.

Vorteile der Container-Technologie

Der schon erwähnten Studie von Techconsult zufolge sehen deutsche IT-Verantwortliche und Software-Entwickler als Vorteile der Container-Technologie vor allem die standortunabhängige Verfügbarkeit von Business-Anwendungen sowie die schnelle Bereitstellung neuer Applikationen beziehungsweise Funktionen. Jeweils deutlich über 80 Prozent der Befragten nannte diese Punkte als Gründe für den Einsatz der Container-Technologie.

Software-Entwickler wissen zudem die Portabilität zu schätzen. Bei IT-Entscheidern ist es dagegen eher die Ressourcen-Effizienz. Diese Aspekte waren aus der jeweiligen Gruppe für 88 bzw. 80 Prozent der Befragten die Motivation, sich mit Containern zu beschäftigen. In einer anderen Umfrage nannten IT-Fachleute dem Analysten-Haus ESG gegenüber die verbesserte Anwendungsleistung (50%), verbesserte Softwarequalität (45%) und eine bessere Anwendungs-Portabilität (45%) als die drei größten Vorteile der Container-Technologie.

Man sieht also, dass es auch auf die Perspektive ankommt, welche Vorteile man Containern zuschreibt. Ein wichtiger Grund, warum die grundsätzlich schon länger verfügbare Technologie jetzt so populär wird, ist die zunehmende Akzeptanz von Cloud- und Multi-Cloud-Szenarien. Hier ist plattformübergreifende Portabilität besonders gefragt und dafür sind Container prädestiniert. Außerdem lassen sie sich – da sie aufs Nötigste beschränkt sind – schnell hochfahren oder wieder beenden. Dabei gehen sie sparsam mit physischen Ressourcen um. Schließlich punkten sie dadurch, dass sie sich in unterschiedlichen Umgebungen gleich verhalten. Alle diese Punkte tragen dazu bei, dass Container viele Anforderungen von DevOps erfüllen. Und weil immer mehr Firmen auf DevOps setzen, nimmt auch die Container-Nutzung zu.

Nachteile der Container-Technologie aus Storage-Sicht

»Ein Problem mit Containern ist, dass sie nie dafür gedacht waren, persistente Applikationen bereitzustellen«, gibt Datacore-Manager Best zu bedenken. »Container sind aus einer Entwicklungsebene gekommen, um sogenannte Microservices bereitzustellen, für translational Services, wo kleine Dinge etwas übersetzen, in Datenbanken einstreuen und aus Datenbanken auslesen und zu einem Anwender transportieren.«

Die schon genannten Vorteile und der Nutzen einer Container-Anwendung sind allerdings so groß, dass man sie möglichst überall nutzen möchte. »Man muss es jetzt schaffen diesen Containern, die an sich sehr vergesslich sind, beizubringen, Daten auch persistent zu halten«, fasst Best anschaulich zusammen. Datacore ermögliche zum Beispiel persistente Storage-Architekturen für Container-Anwendungen, arbeite dabei allerdings im Hintergrund: »Ein Container-Administrator kann die aus seinem gewohnten Umfeld heraus mit administrieren, ohne sich mit der Datacore-Lösung wirklich auseinandersetzen zu müssen«, versichert Best.

Sascha Uhl, Cloudian »Container wurden für die Cloud entwickelt«, sagt Sascha Uhl, Sales Director Central & Eastern Europe bei Cloudian. »Da sie jedoch aus sich heraus zustandslos und relativ kurzlebig sind, verhalten sie sich regelrecht kontradiktorisch zu einigen der Regeln, die mit dem traditionellen Speicherzugriff verbunden sind, was eine Reihe neuer Herausforderungen mit sich bringt.«

Storage für Container fit machen

Vielfach fehlen in gewachsenen, komplexen Storage-Architekturen einfach die API-Funktionen, um die modernen Automatisierungs-Tools, die zur Container-Verwaltung genutzt werden, zu unterstützen. Eine Möglichkeit Abhilfe zu schaffen ist es, eine Middleware-Schicht zwischen Container-Anwendungen und den traditionellen SAN/NAS-Speicher einzuziehen.

»Dieser Ansatz führt jedoch in der Regel zu höheren Kosten und Komplexität«, warnt Cloudian-Manager Uhl. »Gleichzeitig beschränkt er sich auf die traditionelle Storage-Funktionalität, anstatt die Leistungsfähigkeit der in der Cloud geborenen Techniken zur Speicherverwaltung zu nutzen.« Deutlich einfacher sei es, wenn die Speicherumgebung im eigenen Rechenzentrum der in der Cloud entspricht und dieselben Zugriffsfunktionen bieten kann, wie zum Beispiel eine Kubernetes-Bereitstellung in einer Public-Cloud.

Um von der mit Containern möglichen Portabilität der Anwendungen in vollem Umfang zu profitieren, müssen die persistenten Daten, die zur Ausführung dieser Anwendung erforderlich sind, an jedem Standort verfügbar sein. »S3 bietet einen einheitlichen globalen Namespace, der es container-basierten Anwendungen ermöglicht, einfach eine Verbindung zu den Daten herzustellen«, empfiehlt Uhl. Dessen Produkt HyperStore sei eine Möglichkeit, um Zugriff auf die nächstgelegene Kopie dieser Daten zu ermöglichen und so mögliche Probleme mit der Netzwerklatenz, die durch Remote-Verbindungen entstehen können, zu reduzieren.

Veritas hat bereits 2017 mit HyperScale for Containers ein extra auf die Storage-Anforderungen von Containern zugeschnittenes Angebot vorgestellt. Inzwischen gibt es das als Einzelprodukt bei dem Anbieter nicht mehr, die Funktionen wurden in die Produktpalette integriert. Seit Anfang 2019 sind die zum Beispiel für Docker zertifiziert. Damit ermöglicht zum Beispiel Veritas Infoscale die Verwaltung von Docker-Containern sowie die Umsetzung von Hochverfügbarkeit, Disaster-Recovery und die Skalierung der Storage-Kapazitäten. Auch NetBackup erlaubt es, seit Anfang 2020 mit einem selbst als Container eingerichteten Client Anwendungsdaten von Containern zu schützen.

Allerdings hat man die Probleme auch bei der Cloud Native Computing Foundation erkannt und arbeitetet daran, Lösungsmöglichkeiten in Kubernetes zu integrieren, etwa mit Kubernetes Volumes. Anwendern rät Chad Serino, CEO von AlphaBravo, in einem Blog-Beitrag bei der CNCF: »Es geht nicht darum, die objektiv bessere Methode zu finden, denn es stehen so viele zur Auswahl. Es kommt auf persönliche Vorlieben und ein paar Versuche an, mit denen man sich annähert. Letztlich benötigen Sie ein System, das genau Ihren Anforderungen entspricht.« Seiner Ansicht nach sollte man bei der Auswahl auf Open-Source-Design, Scale-out Persistent-Storage, In-Kernel-Data-Replication, schnelle Antwortzeiten und niedrige CPU-Anforderungen achten. Wie genau man die Schwerpunkte setzt, bleibt einem selber überlassen.