Datenlogistik

von Ariane Rüdiger

Ursprünglich war für Container kein persistenter Storage vorgesehen. Doch inzwischen fußen auch produktive Umgebungen auf Containern, weshalb eine langfristige Datenhaltung wichtig geworden ist. Neben nativer Kubernetes-Technik und Open-Source-Tools für die Storage-Verwaltung gibt es auch von namhaften kommerziellen Anbietern entsprechende Software. Wir beleuchten die wichtigsten Werkzeuge und die zugrundeliegenden Standards.

Auf cloudnative Umgebungen mit Containern unter Kubernetes-Orchestrierung laufen längst auch geschäftswichtige Applikationen. Das hat mit Weiterentwicklungen der Container-Technik im Bereich Management von Speicher und persistenten Daten zu tun. Dabei ist ein Container eigentlich nur eine Softwarebox ohne eigenes Betriebssystem. Sie enthielt in der Urversion neben der App oder dem Mikroservice auch alle benötigten Treiber, Abhängigkeiten und Daten, die die jeweilige Applikation zum Laufen brauchte. Wurde der Container gelöscht, war das alles weg. Es musste also ein Datenspeicher her, der unabhängig von der Existenz eines Containers oder seines Pods am Leben bleibt.

PVs, PVCs und Storage-Klassen

Zwei Varianten sind in dem Bereich verfügbar: Persistent Volumes (PV) und Persistent Volume Calls (PVC). Persistent Volumes sind statisch. Sie werden vom Admin vorausschauend definiert, gehören zu einem Kubernetes-Cluster und gehen mit diesem unter – überleben aber das Löschen einzelner Container. Der Administrator schreibt ihnen alle charakteristischen Eigenschaften zu: Größe, Speicherklasse, Pfade, IP-Adressen, Benutzer, Kennungen und das zu verwendende Plug-in.

Storage-Klassen haben dabei bestimmte Merkmale wie QoS, Replikation, Kompression, Sicherung oder mehr, die das Container Storage Interface (CSI), nicht jedoch Kubernetes selbst versteht. Es gibt inzwischen viele unterschiedliche Storage-Klassen für PVs in Kubernetes-Cluster: von lokalem Speicher über solchen, der mit NFS, iSCSI oder FC angebunden ist, bis zu Blockstorage von Azure, AWS oder Google. Alle PVs einer Speicherklasse sind über das gleiche API zugänglich beziehungsweise an den Pod gekoppelt.

PVCs dagegen werden vom Applikationsverantwortlichen als Storage-Klasse gemäß dem Applikationsbedarf angefordert. Je nach Anforderung entsteht ein PVC aus dem Template der entsprechenden Storage-Klasse und ist fortan an den Pod angebunden, geht also auch mit ihm unter. Mit einem Stateful Set lassen sich PVCs über mehrere Pods kopieren. Ihre Eigenschaften sind in der YAML-Deklaration eines Pods festgelegt. Letztlich wird dem PVC so viel Speicher zugewiesen, wie Nutzer für eine ganz bestimmte Anwendung veranschlagen.

Läuft ein Pod auf einem Host, lässt sich auch ein Pfad auf ein Host-Verzeichnis definieren, wo dann die Container-Daten landen – allerdings nur so lange, wie der Container tatsächlich auf dem Host läuft. Auch Datenblocks oder Objekte, die im Zusammenhang mit containerisierten Apps stehen, lassen sich lokal speichern, aber eben nur so lange, wie der Container tatsächlich auf dieser Hardware bleibt.

Container Storage Interface als Schnittstelle

Mittlerweile sehr wichtig ist das bereits erwähnte CSI [1]: eine Schnittstelle entwickelt von der Cloud Native Computing Foundation (CNCF), damit Anbieter von Speichersystemen diese an Kubernetes- und andere orchestrierte Container-Umgebungen ohne eigene Treiber anbinden können. Aktuell hat sich CSI am Markt durchgesetzt und wird von vielen Storage-Herstellern unterstützt.

Vor CSI galt es, Plug-ins für Volumes zu schreiben, verlinken, kompilieren und mit dem Kubernetes-Code zu verschicken – ein teures und unflexibles Verfahren. Denn jedes Mal, wenn neue Storage-Optionen ihren Weg in die Systeme fanden, musste der Kubernetes-Code selbst verändert werden. Damit ist dank CSI Schluss – die Codebasis von Kubernetes bleibt nun von Veränderungen der unterstützten Storagesysteme unberührt.

Ein CSI-konformes Plug-in besteht aus drei Komponenten: einem Controller-, einem Node- und einem Identity-Service. Der Controller-Service steuert den Storage. Dazu gehören Funktionen wie Cre-ate, Delete, List, Publish, Snapshots und so weiter. Über den Node-Service greift der Container-Node auf den Storage zu. Wichtige Funktionen sind das Volume-Staging und -Publishing, Volume-Statistik und -Eigenschaften. Der Identity-Service liefert Informationen über den angebundenen Storage.

Insgesamt umfasst ein standardkonformes CSI rund 20 Funktionen. Entsprechen diese der CSI-Spezifikation, erhalten Administratoren ein funktionierendes Plug-in für die Anbindung eines Storage an ein beliebiges Containersystem. Dort läuft der CSI-Controllerservice auf dem Controller-Node. Es lassen sich aber beliebig viele Nodes mithilfe des Node-Services anbinden. Stirbt ein Node, der ein bestimmtes Volume nutzte, wird es einfach an einen anderen Node publiziert, wo es dann verfügbar ist. Die wichtigen Container-Orchestrierungssysteme (Kubernetes, OpenShift, PKS, Mesos, Cloud Foundry) unterstützen inzwischen CSI, Kubernetes ab Version 1.13.

Kubernetes ergänzt CSI durch eigene Funktionen. Dazu gehören die Weitergabe von Storage-Class-Parametern an die CSI-Treiber. Weiter die Möglichkeit, Kenndaten ("Secrets") zu verschlüsseln, die vom Treiber automatisch entschlüsselt werden und der automatische und dynamische Start des Node-Services auf neu geschaffenen Knoten.

In einer Kubernetes-Umgebung können mehrere CSI-Driver parallel arbeiten. Das ist wichtig, wenn Applikationen im Cluster unterschiedliche Storage-Anforderungen stellen. Sie können sich dann die passende Speicherressource aussuchen, da alle gleichermaßen über CSI an den Cluster angebunden sind. Kubernetes sorgt durch Redundanzmechanismen dafür, dass immer zumindest ein Controller-Service läuft. Damit bietet Kubernetes derzeit die umfassendste Unterstützung aller Orchestrierer für CSI.

Allerdings benötigt CSI bei der Arbeit in Kubernetes-Umgebungen zusätzliche Middleware-Softwarekomponenten außerhalb des Kubernetes-Core. Sie sorgen für Passgenauigkeit zwischen der jeweils verwendeten CSI- und Kubernetes-Version. Die Middleware registriert, bindet, löst, startet und stoppt die CSI-Treiber. Auf diese Weise versorgt die externe Middleware, die allerdings vom Kubernetes-Team programmiert wurde, die jeweils bestehende Knoten mit dem nötigen Storage-Zugriff.

Die meisten CSI-Driver sind in Go geschrieben. Dafür gibt es als Unterstützung das GoCSI-Framework. Es liefert rund ein Viertel des nötigen Codes einschließlich eines vordefinierten Remote Procedure Codes (goRPC). Außerdem gibt es dort ein spezielles Testtool. Dell EMC beispielsweise verwendet dieses Framework für einige seiner Storage-Produkte.

Verwaltungswerkzeug Ceph

Die zahlreichen Open-Source-Projekte rund um Container-Storage füllen funktionale Lücken und Mängel in Kubernetes meist in Bezug auf das Management persistenter Storage und Daten. Nur mit solchen Ergänzungen ist Kubernetes für geschäftliche Anwendungen ein sicheres Umfeld. Derzeit zieren die Project-Map der Cloud Native Computing Foundation rund 30 Storage-Projekte, von denen viele bereits kommerzialisiert wurden. Hier stellen wir Ceph, Rook, Gluster und Swift ausführlicher vor. Hinzu kommen kurze Beschreibungen weiterer Projekte mit Fokus auf Container-Storage.

Die quelloffene Storage-Plattform Ceph [2] wurde bereits 2004 in den Grundzügen entwickelt. Heute kommt sie gern mit der Container-Storage-Software Rook zum Einsatz. Aktuell tragen vor allem Red Hat, Suse und SanDisk zur Entwicklung bei. Ceph wird auf einem verteilten Computer-Cluster implementiert und eignet sich für Objekte, Block- und File-Storage. Das System arbeitet verteilt mit automatischer Replikation, Selbstheilung, Selbstverwaltung und hat keinen Single Point of Failure. Für eine Ceph-Umgebung reicht Commodity-Hardware. Basis des Objektstores ist RADOS (Reliable Autonomic Distrubuted Object Store).

Der Clustermonitor ceph-mon überwacht die Funktion und Konfiguration der Cluster-Knoten. Er speichert Informationen über die Platzierung der Daten und den Allgemeinzustand des Clusters. ceph-osd verwaltet direkt angebundenen Disk-Storage (BlueStore), dessen Einträge in einem Journal mitgeschrieben werden. ceph-mds bewahrt die Metadaten aller in einem Ceph-System gespeicherten Datenobjekte auf. Manager (ceph-mgr) überwachen und warten den Cluster und bilden die Schnittstelle beispielsweise zu externen Loadbalancern oder anderen Tools. HTTP-Gateways (ceph-gwy) stellen eine S3-/Swift-Schnittstelle zum Objektstorage bereit.

Wegen der Verflechtung mit der weiteren Geschichte von Ceph sei hier auch GlusterFS erwähnt, eine Entwicklung der 2005 gegründeten Gluster Inc. Geplant war eine Open-Source-Plattform für Scale-out-Cloud-Storage für Private und Public Cloud. 2011 hat Red Hat Gluster gekauft, das mittlerweile zu IBM gehört. Red Hat vermarktete Gluster FS zunächst als "Red Hat Storage Server", kaufte dann Ceph, verband beide Technologien und vermarktet die Lösung jetzt als "Red Hat Gluster Storage".

Storage-Orchestrierung mit Rook

Rook [3] ist ein cloudnative-Storage-Orchestrator für Kubernetes. Er basiert auf einem Ceph-Cluster (Luminous oder höher, Kubernetes 1.6 oder höher) und betreibt ein verteiltes Dateisystem direkt auf dem Storage-Cluster. Rook stellt Schnittstellen für Scheduling, Lebenszyklus- und Ressourcenmanagement, Sicherheit, Monitoring und das Nutzungserlebnis in der Cloud zur Verfügung. Die Software setzt auf der Knotenstruktur von Ceph auf und hat zusätzliche Komponenten, die Installation und Betrieb von Ceph-Pods überwachen und steuern. So wird auf jedem Knoten ein Rook-Agent installiert. Er stellt einen Teil des Storage-Treibers für Kubernetes bereit. Der Rook-Operator, maßgeblich von CoreOS entwickelt, überwacht und steuert die einzelnen Agenten und andere Teile des Ceph-Clusters innerhalb einer Kubernetes-Umgebung.

Rook bietet unter anderem folgende Funktionen: Storage-Management auch in hyperskalierenden oder hyperkonvergenten Storage-Clustern, effektive Datenverteilung und -replikation, Bereitstellung von File-, Block- oder Objektstorage bei diversen Providern. Zudem lässt sich Rook verwenden, um Workloads auf Commodity-Hardware zu optimieren.

Swift: Objektstorage in OpenStack

Ein weiteres wichtiges Projekt ist Swift [4]. Mit Swift wird in OpenStack über Ringstrukturen Objektstorage realisiert. Die Ringe dienen dem Mapping zwischen den Namen von im Cluster gespeicherten Einheiten und ihren physischen Entsprechungen auf den Disks. Innerhalb des Rings gibt es Zonen, Devices, Partitionen und Replikas. Jede Partition wird im Cluster mindestens dreimal repliziert. Die Standorte der Kopien sind im Ring-Mapping gespeichert.

Bei Ausfällen übernimmt der Ring das Umschalten auf intakte Ressourcen. Daten lassen sich innerhalb einer Zone des Rings isolieren, Replikas werden in unterschiedlichen Zonen (Rechenzentrum, Schränke, Server oder sogar Switches) gehalten. Partitionen werden über alle Devices in einem Ring verteilt. Der Ring managt sich nicht selbst, sondern wird von außen verwaltet.

Der Replikationsmechanismus überprüft durch Lesen der Hash-Files der Partitionen kontinuierlich, ob die gewünschten drei Kopien vorhanden sind. Zonen (Racks, Server, ein oder mehrere Laufwerke) sollen Fehler isolieren. Partitionen dagegen sind Sammlungen gespeicherter Daten, zum Beispiel Konten- oder Containerdatenbanken. Die Partitionen bilden den Kern des Replikationssystems.

Auf jeden Ring wird über Proxies und deren API zugegriffen. Proxies sind auch für die Koordination von Antworten und Zeitstempeln sowie die Handhabung von Ausfällen zuständig. Sie haben eine

Share-Nothing-Architektur und können nach Bedarf skaliert werden. Mindestens zwei sollten aus Redundanzgründen vorhanden sein. Container werden als individuelle, über den gesamten Cluster verteilte SQLite-Datenbank dargestellt. Dasselbe gilt für Konten. Dabei enthält eine Konten-Datenbank alle Container, die zu dem Konto gehören. Eine Container-Datenbank speichert alle Objekte im Container.

Weitere Open-Source-Projekte

Interessant ist das Projekt SODA (Soda Open Data Autonomy) [5] der Soda-Stiftung. Geplant ist ein einheitlicher API-Layer, über den Applikationen auf Daten unabhängig von dem darunterliegenden Storage oder logischen Strukturen zugreifen können. Die jeweiligen Plattformen brauchen dafür allerdings ein SODA-Plug-in.

SODA besteht aus einem Infrastrukturmanager für die gesamte Storage-Infrastruktur. Die SODA-API fungiert als zentrale externe Schnittstelle, die sich nahtlos mit heterogenen Storage-Backends verbindet und damit die üblichen heterogenen Daten- und Storage-Management-APIs vereinheitlicht. Ein Controller übernimmt das gesamte Metadaten- und Statusmanagement. Die Treiber der unterschiedlichen Storage-Backends sind an ein sogenanntes SODA-Dock angeschlossen. Zudem gibt es noch eine Komponente für das Multicloud-Management.

Ein kurzer Blick auf einige weitere Container-relevante Open-Source-Projekte der CNCF:

- Linstor ist ein Kubernetes-integriertes Block-Storage-Management für große Linux-Cluster und realisiert persistenten Block-Storage für OpenStack, OpenNebula und OpenShift.

- Longhorn eignet sich für den Aufbau von verteiltem Block-Storage in Kubernetes-Umgebungen.

- OpenEBS realisiert offenen Container-Attached-Storage in Kubernetes-Umgebungen. Damit können Stateful-Applikationen leichter auf dynamische lokale oder replizierte PVs zugreifen. Zu den Anwendern gehören Arista, Orange, Comcast und die CNCF.

- Stash sichert Stateful-Applikationen in Kubernetes-Umgebungen. Basis des Projekts ist die offene Backupanwendung Restic. Stash nutzt eine deklarative Schnittstelle und Custom Resource Definition (CRD), um das Backupverhalten zu steuern.

- Velero sichert ebenfalls Kubernetes-Ressourcen, eignet sich aber auch für Migrationen und Disaster Recovery persistenter Volumes zwischen Kubernetes-Cluster-Ressourcen.

- Min.io realisiert einen S3-Objektspeicher für Kubernetes-Umgebungen, ohne direkt mit Kubernetes zu interagieren. Die Lösung kommt mit nur einer Softwareschicht aus. Zu den Funktionen gehören Erasure Coding, Verschlüsselung, unveränderliche Speicherung, Identitätsmanagement, kontinuierliche Sicherung, globale Datenzusammenführung und eine universelle Cloudschnittstelle. Min.io läuft auf Bare Metal und allen Private Clouds, kann aber NAS-Storage anbinden.

Kommerzialisierte Open-Projekte

Daneben gibt es natürlich auch kommerzielle Angebote. Sehr erfolgreich ist Portworx [6], kürzlich von Pure Storage einverleibt. Die Software stattet beliebige Kubernetes-Umgebungen mit professionellen Funktionen für die Datensicherung aus: So sichert Portworx Volumes aus Container-Umgebungen in die Cloud und stellt applikationskonsistente Snap-shots her. Pure hat zugesichert, dass das Portworx-Geschäft zumindest vorläufig weiterlaufen soll wie bisher.

Kasten [7], spezialisiert auf Kubernetes-Backup, wurde kürzlich vom Backupanbieter Veeam aufgekauft und vervollständigt damit Veeams Portfolio sicherbarer Infrastrukturumgebungen durch Containerlandschaften. Weitere Beispiele für kommerzialisierte CNCF-Projekte:

- Trilio ist eine Lösung für den Schutz von Kubernetes-, OpenStack- und Red-Hat-Virtualisierungsumgebungen. Der Hersteller kann Point-in-Time-Snaps der entsprechenden Umgebungen ziehen.

- Ionir portiert mit seiner DataTeleport-Technologie Daten und persistente Volumes ohne händische Interventionen zwischen unterschiedlichen Cloudplattformen angeblich in weniger als 40 Sekunden. Weitere Funktionen sind globale Deduplizierung, Kompression und Datenwiederherstellung. Verschiedene Infrastruktur-Pools lassen sich mit Ionir zu einer einheitlichen, übergreifend gemanagten Datenumgebung zusammenfügen. Voraussetzung ist allerdings, dass die Daten auf K8-Umgebungen liegen.

- Robin CNS von Robin.io ermöglicht es, mittels seiner hyperkonvergenten Kubernetes-Plattform Anwendungen wie Big Data, Datenbanken oder AI/ML sehr schnell mit nur wenigen Klicks auf Cloudplattformen bereitzustellen. Das umständliche Aufsetzen der gesamten Containerumgebung für die jeweilige Applikation entfällt vollständig. Kunden loggen sich auf die Robin-Plattform ein, klicken die gewünschte Anwendung an und definieren mittels einer interaktiven Konfigurationsschnittstelle ihre Parameter. Den Rest erledigt die Robin-Umgebung selbst. Mitgeliefert werden Funktionen wie Klonen von Daten, Metadaten und Konfiguration, Replikation, Migration oder Snapshots. Robin CNS ist CSI-konform und kann deshalb mit nativen Kubernetes-Tools direkt kommunizieren.

VMware: Abschied von der reinen VM-Welt

Abschließend nun noch einige Beispiele dafür, wie große Infrastrukturanbieter Container-Storage implementieren und managen. VMware verwaltet mit vSAN und vSphere sowohl Container als auch VMs und entsprechende Stateful Services. VMware Cloud Foundation [8] ist inzwischen mit einer CSI-Schnittstelle ausgerüstet. Dabei legt VMware über vSAN, vVols und VMFs/NFS eine Policy-Schicht, dann folgen getrennte File- und Block-Schnittstellen. Die nächste Schicht im Stapel ist die zentrale Cloud-Native-Storage-Controlplane. Kubernetes und die dort definierten persistenten Volumes können über die CSI-Schnittstelle auf die Controlplane zugreifen.

Für Stateful Services sowohl auf Container- als auch VM-Basis ist die vSAN Data Persistence Platform maßgeblich. Sie bietet Applikationspartnern eine Andockstelle. Zu ihnen gehören Cloudian, DataStax, Dell und MinIO. Mit den VMware Cloud Foundation Services können Anwender auch über Kubernetes- und RESTful-APIs auf Container-Infrastruktur in der Cloud und virtuelle Maschinen zugreifen. Eine Einbindung in vSphere ist geplant. Stateful-Services von Partnern können jetzt über von den Partnern gebaute Dashboards in vCenter verwaltet werden.

Red Hat und NetApp

Ein kurzer Blick auf Red Hat: OpenShift Container Storage [9] ist rein softwaredefiniert und für die Red Hat OpenShift Container Platform optimiert. Unterstützt werden Files, Blocks und Objekte. Die Plattform ist ein Teil der Red Hat Data Services. Ziel ist ein konsistentes Nutzungserlebnis unabhängig von der Infrastruktur. Persistenter und hochverfügbarer Container-Storage lässt sich bei Bedarf dynamisch bereitstellen und wieder freigeben.

Geeignet ist die Software für Datenbanken, Data Warehouses, zur Automatisierung von Datenpipelines sowie für hochaktive Daten in Continuous-Deployment-Entwicklungsmodellen. Weitere Anwendungsfelder sind AI, ML und Analytics, die besonders von Datenservices auf Kubernetes-/Mikroservice-Basis profitieren.

Red Hat reklamiert als Vorteile von Red Hat Container Storage als Basis für Datenservices eine beschleunigte Anwendungsentwicklung und die deterministische Leistung von Datenbanken. Dazu kommen die vereinfachte Storage-Handhabung für analytische Anwendungen sowie Schutz und Resilienz für persistente Volumes und Namensräume.

Schließlich sei noch NetApp erwähnt. Das Unternehmen will Anwendern PaaS-Umgebungen mit komplettem Management für Datenaufgaben innerhalb von Provider-Infrastrukturclouds bereitstellen. Kürzlich hat der Hersteller zwei neue Dienste präsentiert, die Ocean [10] – gedacht für Stateless-Apps im Kubernetes-Umfeld – ergänzen:

1. Astra für den Schutz von Kubernetes-Applikationen einschließlich Migration und Wiederherstellung. Dafür muss keine Software heruntergeladen, installiert, verwaltet oder aktualisiert werden. Funktionen sind Snapshots für die lokale Datensicherung und Wiederherstellung auf demselben Kubernetes-Cluster, anwendungsbezogene Disaster Recovery auch in einer anderen Region und auf einem anderen Cluster und aktives Klonen von Applikationen mitsamt ihrer Daten zu Migrationszwecken in einen anderen Kubernetes-Cluster unabhängig von seinem Standort.

2. Für eher analytische Umgebungen ist Wave gedacht. Wave implementiert eine gemanagte Spark-Umgebung auf AWS, demnächst auch Azure, Google und weiteren Cloudplattformen. Dabei findet die Spark-Version Verwendung, die der Kunde nutzen möchte, und zwar samt wichtiger Tools zum Datenstreaming in Spark und zum Query-Management von Spark-Daten. Netapp hat weitere Ankündigungen im Bereich Management persistenter Daten in Kubernetes gemacht.

Fazit

So unvollkommen Kubernetes anfänglich mit dem Bedarf nach persistenter Datenhaltung und entsprechenden Enterprise-Funktionen umging, so vielfältig ist inzwischen die Landschaft möglicher Lösungen für solche Aufgaben. Mit der sehr wahrscheinlichen weiteren Ausbreitung von Containern als zukünftiger Standardinfrastruktur für Cloudumgebungen wird sich diese Vielfalt aller Voraussicht nach wahrscheinlich weiter vergrößern. Deshalb scheint es realistisch zu erwarten, dass kaum eine aktuelle oder zukünftige Storage-Management-Herausforderung auf Dauer ohne eine effiziente Software bleiben wird.

Storage-Management für Kubernetes

Datenlogistik

PVs, PVCs und Storage-Klassen

PVs, PVCs und Storage-Klassen

Container Storage Interface als Schnittstelle

Verwaltungswerkzeug Ceph

Storage-Orchestrierung mit Rook

Swift: Objektstorage in OpenStack

Weitere Open-Source-Projekte

Kommerzialisierte Open-Projekte

VMware: Abschied von der reinen VM-Welt

Red Hat und NetApp

Fazit