Red Hat OpenShift & Nutanix- Persistente Speicherlösungen

Container-Plattformen verändern die Art, wie mit Daten gearbeitet wird: Sofern nicht anders definiert, sind Container mit all ihren Daten volatil. Sie werden mit ihren Programmdateien und -konfigurationen in einem Kubernetes-Cluster als „Wegwerf“-Produkte angesehen. Die überwachende Container-Orchestrierung ersetzt sie im Betrieb fortwährend. Dies kann im Rahmen von Updates, Skalierungen, Entwicklungsprozessen oder der großen Stärke von Kubernetes – der Selbst-Heilung – geschehen.  

Beim Betrieb einer containerisierten Anwendung entfällt das Vorhalten von Konfigurationen oder Abhängigkeiten: Container-Images werden lauffähig gebaut, Einstellungen werden durch das Cluster in den Container geladen, um seine Idempotenz sicherzustellen. Lediglich die individuellen Nutzdaten der Applikation müssen so abgespeichert sein, dass sie in ihrem Lebenszyklus beständig bleiben und sinnvoll konsumierbar sind. Ein Administrator muss bei einem angelieferten Container-Image keinerlei Berechtigungen oder Software nachträglich konfigurieren bzw. installieren. Ihm obliegt es nur die Daten, die im direkten Einsatz erzeugt werden, sicher und konsistent abzuspeichern und auch für zukünftige Container-Versionen zur Verfügung zur stellen.  

Die Auslagerung der Datenhaltung vom datenverarbeitenden Container-Prozesses spielt die große Stärke des modularen Aufbaus von Kubernetes aus und verändert die Administration und Bereitstellung von Speicher in der IT-Landschaft.  

Die Idee hinter RedHat OpenShift & Nutanix 

Hyperkonvergente Infrastrukturen, wie beispielsweise die Lösung von Nutanix, bieten die Möglichkeit, softwaredefinierte Speicher zu provisionieren. Mithilfe von RedHat OpenShift können beliebige Anwendungen containerisiert abgebildet werden, welche gleichzeitig noch andere Anforderungen an den Speicher stellen.  So ist eine der üblichen Darreichungsformen für den Betrieb horizontal redundanter Container die Anbindung an ein NFS-System mit mehrfacher Lese- und Schreibberechtigung: Unabhängig von dem Container, der die derzeitige Anfrage bearbeitet, teilen sich alle definierten „Recheneinheiten“ des Clusters die gleiche Datenbasis. Datenbanken hingegen unterliegen in ihrer Betriebszeit einem ständigen Wandel ihrer Datenhaltung. Hier schafft der Block-Speicher wesentlich höhere Lese- und Schreibberechtigungen und geringere Latenzen als ein NFS-Laufwerk.  

In den letzten Jahren kam der S3-Speicher als Objekt-Storage-Speicheroption dazu. Diese Darreichungsform des Speichers skaliert nahezu endlos und kann Dateien verteilt speichern. Dieser Speicher empfiehlt sich gerade für Backups und Machine Learning-Prozesse.  

Dieser Speicher kann dann über die Nutanix-Plattform den Anwendungen auf der Containerplattform OpenShift dediziert bereitgestellt werden. Dabei muss auf Features der „alten Welt“ nicht verzichtet werden: Die Containerplattform ermöglicht Snapshots und die nachträgliche Justierung der Speichergrößen ebenso wie man mit Berechtigungen den vorhandenen Speicher auf Nutzende der Plattform aufteilen kann.  

Das Container-Storage-Interface (CSI) 

Das Container-Storage-Interface beschreibt eine Kubernetes-Schnittstelle, welche, den richtigen Treiber vorausgesetzt, beliebigen Speicher von einem Storage-System provisionieren kann. Ohne CSI-Integration werden dem Cluster einzelne Speicherobjekte (Persistent Volume – PV) bereitgestellt, die mit Labels und Eigenschaften einen gewissen Zustand über alle Namespaces hinweg präsentieren.  Ein Persistent Volume Claim (PVC) beschreibt ein Objekt, das das Cluster auffordert, ein Volume, definiert durch eine bestimmte Güte, an sich zu binden. Hier findet auch die logische Verknüpfung mit der Zielanwendung statt.  

Der Kubernetes-Cluster sucht auf Grundlage des PVCs in seinem vorhandenen, ungebundenen Speicher das Objekt heraus, welches am ehesten seine Anforderungen erfüllt. Es kann daher passieren, dass ein wesentlich größerer Speicherblock für die Anwendung provisioniert wird, weil es das einzige Speicherobjekt ist, welches zur PVC-Anforderung passt. Wenn kein passender Speicher vorhanden ist, bricht das Deployment der Anwendung ab. Ohne CS ergeben sich neben dem verschwendeten Speicherplatz weitere Probleme der Skalierung: Sollen permanent weitere Speicherobjekte in dem Cluster erscheinen, müsste hier ein Administrator tätig werden. Die automatische Storage-Provisionierung mittels PVC ermöglicht die Automatisierung und passgenaue Provisionierung dieses Prozesses: Die Anfrage nach Storage mittels PVC löst die unmittelbare Bereitstellung des Speicherobjektes genau im Rahmen der Güte aus. 

Installation des CSI-Treibers 

Der Nutanix-CSI-Treiber ist direkt im Operator-Hub von OpenShift integriert und benötigt lediglich die Zugangsdaten zur Prism-API in Form eines Secrets. Nachdem die administrativen Zugangsdaten dort im empfohlenen Namespace „ntnx-system“ abgelegt wurden, genügt ein Klick auf das Installationsfeld, um die persistente Speicheranbindung von OpenShift in Nutanix zu aktivieren.

Abbildung 1: Der Nutanix-CSI-Treiber im Operator-Hub
Abbildung 1: Der Nutanix-CSI-Treiber im Operator-Hub

Die unterschiedlichen Speicherklassen

Nach der Installation des Nutanix-CSI-Treibers besteht die Möglichkeit, diverse Storage-Klassen zu erstellen. Dieses Kubernetes-Objekt kann als Speicherprofil verstanden werden.  

Es beschreibt neben dem zu verwendenden Treiber für die Provisionierung auch Parameter. Zu nennen wäre hierbei beispielsweise das bei der Installation vergebene Passwort oder die Verhaltensweise des Speichers bei Verlust der Verknüpfung zur Anwendung. 

Die Nutanix-Dokumentation bietet einen guten Anhaltspunkt, um sich verschiedene Speicherprofile für unterschiedliche Anwendungsszenarien zu erstellen.  

Für die Verprobung unterschiedlicher Speicherklassen werden nachfolgend diese Kategorien erstellt: 

Speicherklassen-Name  Beschreibung 
ntnx-dev-block  Einfacher Block-Speicher 
ntnx-dev-block-lvm  Blockspeicher mit LVM-Unterstützung  
ntnx-dev-nfs-dynamic 
NFS-Speicher, der zur Laufzeit von der Nutanix-Umgebung zur Verfügung gestellt wird 
ntnx-dev-nfs-static 
NFS-Speicher, der auf eine bereits existierende Freigabe in der Nutanix-Umgebung zugreifen kann  

Tabelle1: Storageclass-Arten für die Verprobung des CSI-Treibers

Die LinuxVolumeManagment (LVM)-Unterstützung erhöht beim Erstellen der Storage-Klasse “ntnx-dev-block-lvm” die Performance durch den Zusammenschluss mehrerer Disks. In dem aktuellen Versuchsaufbau werden 8 Disks verwendet, wobei der CSI-Treiber den Speicherplatz automatisch zwischen den Platten aufteilt. 

Nachdem die erstellten Kubernetes-Manifeste in Form von YAML-Dateien erstellt und dem Cluster die Anweisung gegeben wurde, die Ressourcen zu generieren, sind die Storage-Klassen im OpenShift-Cluster angelegt:  

Arbeiten mit dem Speicher 

Im Video werden folgende Dinge gezeigt: 

  • Die CSI-Treiber-Installation mit dem Hinterlegen des Secrets sowie der Installation des Red Hat OpenShift zertifizierten Nutanix-Operators  
  • Das Anlegen der Storage- sowie Snapshot-Klassen für die Differenzierung der Speichergüte 
  • Das Anlegen verschiedener PVCs: Hier ist zu sehen, wie die Volumes automatisch provisioniert und gebunden werden  
  • Die Verbindung der Volumes zu dem darunter liegenden Nutanix-System  
  • Die Anbindung an Demo-Applikationen  
  • Nachträgliche Skalierung von Speicherplatz 
  • Das Erstellen und Wiederherstellen eines Snapshots  

Fazit 

Die automatisierte Bereitstellung ist in der containerisierten Welt nicht nur auf die Laufzeitumgebung der Container beschränkt. Vielmehr bietet OpenShift auf der Nutanix-Plattform eine allumfassende Lösung, um containerisierte Anwendungen mit beliebigem Speicher zu versorgen. Durch die Möglichkeit, permanenten Speicher nachträglich zu skalieren und Snapshots zu erstellen, kann man dynamisch auf Anforderungen bestehender und neuer Anwendungen reagieren.