c i n d e r

Wer jemals ein Rechenzentrum auf Basis von OpenStack hochgezogen hat, stolpert zwangsläufig über den Namen Cinder und merkt schnell, dass ohne diese Komponente eigentlich gar nichts läuft. Es geht hier nicht bloß um ein bisschen Speicherplatz für virtuelle Maschinen, sondern um das Rückgrat für persistente Daten in der Cloud. Stell dir vor, du startest eine Instanz, installierst mühsam deine Software, konfigurierst die Datenbank und nach einem Neustart oder dem Löschen der VM ist alles weg. Genau das passiert, wenn man nur auf flüchtigen Ephemeral Storage setzt. Damit deine Daten über den Lebenszyklus einer einzelnen Maschine hinaus bestehen bleiben, brauchst du diesen Block-Storage-Dienst. Ich habe in den letzten Jahren etliche Setups gesehen, bei denen die Speicherplanung erst ganz am Ende kam. Das ist ein fataler Fehler. Wer die Architektur dieser Speicherlösung nicht von Anfang an versteht, baut sich Performance-Flaschenhälse, die man später nur mit extremem Aufwand wieder loswird.

Die Architektur hinter der Cloud Speicherverwaltung

Um zu verstehen, wie das System arbeitet, muss man sich die einzelnen Dienste ansehen, die im Hintergrund die Fäden ziehen. Es ist kein monolithischer Block, sondern ein Gefüge aus verschiedenen Diensten, die über eine Nachrichtenschlange miteinander kommunizieren. Da gibt es den API-Dienst, der die Anfragen der Nutzer entgegennimmt. Wenn du also über die Kommandozeile oder das Dashboard ein neues Volume anforderst, landet das zuerst hier. Dann kommt der Scheduler ins Spiel. Dieser Teil der Software ist quasi der Logistiker. Er schaut sich an, welche Speicherknoten im Cluster gerade Kapazitäten frei haben und welche spezifischen Anforderungen du gestellt hast. Willst du schnellen SSD-Speicher oder reicht die günstige, langsame Magnetplatte? Der Scheduler trifft die Entscheidung, wo das Volume am besten aufgehoben ist.

Der eigentliche Arbeiter ist jedoch der Volume-Dienst. Dieser läuft auf den Knoten, die direkt mit der Speicherhardware verbunden sind. Er nutzt verschiedene Treiber, um mit den Storage-Systemen zu sprechen. Das ist die große Stärke dieser Architektur: Sie ist völlig agnostisch gegenüber der Hardware. Egal ob du ein schickes Enterprise-SAN von NetApp, Dell EMC oder eine Open-Source-Lösung wie Ceph nutzt, die Schnittstelle nach oben bleibt immer identisch. Ich habe oft erlebt, dass Unternehmen mit lokalem Speicher auf den Compute-Knoten anfangen und später auf ein zentrales System umsteigen. Dank der Abstraktion durch diese Software ist so ein Wechsel im laufenden Betrieb möglich, ohne dass die Anwender oben drüber viel davon mitbekommen.

Warum Block Storage kein Filesystem ist

Ein häufiges Missverständnis bei Einsteigern ist die Verwechslung von Block Storage mit einem Network Attached Storage (NAS) wie NFS oder SMB. Wenn du ein Volume über dieses System erstellst, erhält die virtuelle Maschine ein rohes Blockgerät. Das ist so, als würdest du eine frische Festplatte in einen physischen Server stecken. Das Betriebssystem in der VM muss dieses Gerät erst partitionieren und mit einem Dateisystem wie ext4 oder XFS formatieren.

Das hat enorme Vorteile bei der Geschwindigkeit. Da die Abstraktionsebene des Dateisystems auf der Host-Seite wegfällt, können Datenbanken wie PostgreSQL oder MariaDB viel effizienter direkt auf die Blöcke zugreifen. In Hochlast-Szenarien, etwa bei E-Commerce-Plattformen während eines Sales-Events, macht genau dieser Unterschied die Performance aus. Wer hier auf die falschen Treiber setzt, verliert wertvolle Millisekunden bei jedem Schreibzugriff.

Die Rolle von Treibern und Backends

Die wahre Magie passiert in der Interaktion mit der Hardware. Es gibt hunderte von Treibern für fast jeden namhaften Speicherhersteller. Diese Treiber übersetzen die generischen Befehle der Cloud-Software in die spezifische Sprache des Speichersystems. Wenn ich ein Volume "vergrößern" will, schickt die API den Befehl an den Treiber, und dieser sagt dem Storage-Array über dessen eigene Schnittstelle: "He, mach LUN 42 bitte 100 GB größer."

Ein sehr populäres Gespann in deutschen Rechenzentren ist die Kombination mit Ceph. Ceph bietet einen verteilten Speicher, der extrem skalierbar ist. Hier kommuniziert die Speicherkomponente über das RADOS Block Device (RBD) Protokoll. Das ist deshalb so charmant, weil man keine teure Spezialhardware kaufen muss. Man nimmt handelsübliche Server, steckt viele Festplatten rein und lässt die Software die Redundanz regeln. Das senkt die Kosten pro Gigabyte massiv, erhöht aber die Komplexität in der Wartung. Man muss sich entscheiden: Will ich die Rundum-Sorglos-Garantie eines Hardware-Herstellers oder die Flexibilität von Open Source?

Cinder in der täglichen Betriebspraxis

In der Praxis geht es meistens um Stabilität und Vorhersehbarkeit. Ich erinnere mich an ein Projekt, bei dem ein Kunde ständig über langsame Datenbank-Antwortzeiten klagte. Die Analyse ergab, dass zu viele hochperformante Volumes auf demselben physischen Storage-Backend lagen. Wir haben dann angefangen, mit Volume Types zu arbeiten. Das ist ein mächtiges Werkzeug. Du kannst damit Gold-, Silber- und Bronze-Tiers definieren. Ein Nutzer fragt dann nicht mehr nach "100 GB Speicher", sondern nach "100 GB vom Typ Gold".

Hinter diesen Typen stecken sogenannte Extra Specs. Damit steuerst du, welche Hardware genutzt wird oder welche Quality of Service (QoS) Regeln gelten. Du kannst die IOPS (Input/Output Operations Per Second) hart limitieren. Das klingt erst mal einschränkend, verhindert aber das Problem des "Noisy Neighbors". Wenn ein Nutzer plötzlich einen riesigen Import startet und die gesamte Bandbreite des Speichersystems auffrisst, bleiben die anderen Anwendungen stabil, weil sie durch ihre reservierten Quoten geschützt sind.

Backups und Snapshots richtig nutzen

Ein Cloud-Speicher ist kein Backup. Das muss man sich immer wieder klarmachen. Ein Snapshot in diesem System ist eine feine Sache für schnelle Rollbacks vor einem Software-Update. Er speichert den Zustand der Daten zu einem bestimmten Zeitpunkt. Aber Achtung: Viele Treiber implementieren Snapshots so, dass sie vom Original-Volume abhängen. Stirbt das Backend, sind oft auch die Snapshots weg.

Für echte Datensicherheit gibt es den Backup-Dienst innerhalb der Architektur. Dieser kopiert die Daten tatsächlich auf ein separates System, zum Beispiel in einen S3-Speicher oder ein anderes unabhängiges Cluster. Ich rate jedem, diese Trennung strikt durchzuziehen. Snapshots sind für die Agilität, Backups für das Überleben des Unternehmens. Wer das vermischt, spielt mit dem Feuer. Es gibt professionelle Tools wie Trilio, die genau hier ansetzen und das Management dieser Sicherungen vereinfachen.

Skalierung und Quotas

In einer Multi-Tenant-Cloud, in der sich verschiedene Abteilungen oder Kunden die Ressourcen teilen, sind Quotas lebenswichtig. Ohne Limits würde ein einzelner Nutzer in kürzester Zeit den kompletten Speicherpool füllen. Man kann Limits für die Anzahl der Volumes, die gesamte Gigabyte-Zahl und sogar für die Anzahl der Snapshots setzen.

Interessant wird es bei der Speicherüberprovisionierung. Viele Systeme erlauben es, mehr Speicher an die Nutzer zu verteilen, als physisch vorhanden ist. Das nennt man Thin Provisioning. Da die meisten Nutzer ihre 100 GB niemals voll ausnutzen, funktioniert das meistens gut. Aber wehe, wenn doch! Dann läuft das physische System voll und alle Schreibvorgänge im gesamten Cluster bleiben stehen. Ein Albtraum für jeden Admin. Deshalb ist ein engmaschiges Monitoring Pflicht. Wer hier spart, spart an der falschen Stelle. Ich nutze dafür meistens Prometheus und Grafana, um die physische Auslastung gegen die logische Zuteilung zu prüfen.

Performance Tuning für Fortgeschrittene

Wenn die Basis läuft, geht es ans Eingemachte. Die Geschwindigkeit hängt oft nicht nur von den Festplatten ab. Das Netzwerk ist häufig die eigentliche Bremse. Da Block Storage Daten über das Netz schickt (außer bei sehr speziellen lokalen Setups), braucht man eine Infrastruktur mit geringer Latenz. 10 Gbit/s sind heute das absolute Minimum, 25 oder 100 Gbit/s für den Storage-Traffic sind in modernen Setups Standard.

Man sollte unbedingt den Einsatz von iSCSI gegenüber anderen Protokollen prüfen. iSCSI ist weit verbreitet, kann aber bei vielen gleichzeitigen Verbindungen ordentlich CPU-Last auf den Hosts erzeugen. Hier helfen Hardware-Offloading-Karten, die den Netzwerkstack entlasten. Wer Ceph nutzt, profitiert davon, dass die Daten direkt zwischen der VM und den Storage-Nodes fließen, ohne über einen zentralen Controller zu müssen. Das eliminiert Single Points of Failure und skaliert linear mit der Anzahl der Knoten.

Multi-Attach Volumes und ihre Tücken

Ein Feature, das oft angefragt wird, ist Multi-Attach. Das bedeutet, dass man dasselbe Volume an mehrere virtuelle Maschinen gleichzeitig hängen kann. Das klingt super für Cluster-Dateisysteme. Aber Vorsicht: Das ist kein "Zauber-Speicher", der alles regelt. Wenn zwei VMs gleichzeitig versuchen, auf denselben Block in einem normalen ext4-Dateisystem zu schreiben, hast du nach Sekunden einen totalen Datenverlust.

Multi-Attach erfordert spezielle Software innerhalb der virtuellen Maschinen, wie zum Beispiel OCFS2 oder GFS2. Zudem muss das Backend dieses Feature explizit unterstützen. In der Realität ist es oft einfacher und stabiler, für geteilte Daten auf einen Objektspeicher oder einen dedizierten Shared-File-Service wie Manila zu setzen. Man muss genau abwägen, ob die zusätzliche Komplexität den Nutzen rechtfertigt. Meistens ist die Antwort: eher nein.

Migration und Upgrades

OpenStack-Komponenten wie Cinder zu aktualisieren, war früher eine Operation am offenen Herzen. Heute ist das durch die Versionierung der APIs und die bessere Abwärtskompatibilität viel entspannter geworden. Man kann die Control Plane aktualisieren, während die Volumes für die VMs weiterhin verfügbar bleiben. Der Datenpfad ist meistens von der Management-Ebene getrennt.

Trotzdem sollte man Migrationen planen. Wenn du Hardware austauschst, kannst du Volumes im laufenden Betrieb von einem Backend auf ein anderes verschieben. Die Software kopiert die Daten im Hintergrund. Sobald alles drüben ist, wird der Pfad umgeschaltet. Die Anwendung in der VM merkt davon oft nur eine kurze Latenzspitze. Das ist der Moment, in dem die Cloud-Infrastruktur ihre volle Stärke ausspielt: Wartung ohne Ausfallzeiten.

Sicherheit im Speicherumfeld

Daten sind das wertvollste Gut. Deshalb ist Verschlüsselung kein optionales Extra mehr. Man kann Volumes direkt beim Erstellen verschlüsseln lassen. Der Schlüssel wird dabei in einem sicheren Key-Manager wie Barbican abgelegt. Selbst wenn jemand physischen Zugriff auf die Festplatten im Rechenzentrum bekommt, sieht er nur Datensalat.

Wichtig ist auch die konsequente Nutzung von Policies. Wer darf Volumes löschen? Wer darf Backups einsehen? Über die policy.yaml lässt sich das extrem fein granular steuern. Standardmäßig sind die Einstellungen oft recht offen. Ich empfehle, hier nach dem Prinzip der minimalen Rechtevergabe (Least Privilege) vorzugehen. Ein Entwickler braucht vielleicht das Recht, Snapshots zu erstellen, aber sicher nicht das Recht, das gesamte Storage-Backend zu verwalten.

Ein weiterer Punkt ist das sichere Löschen von Daten. Wenn ein Nutzer ein Volume löscht, sollten die Blöcke auf der physischen Hardware überschrieben werden, damit der nächste Nutzer nicht die Reste der Firmendaten seines Vorgängers auslesen kann. Die meisten modernen Backends erledigen das automatisch, aber man sollte es im Treiber-Setup verifizieren. In Deutschland ist das aufgrund der strengen Datenschutzgrundverordnung (DSGVO) ohnehin ein kritisches Thema. Weitere Informationen zu IT-Sicherheitsstandards findest du beim Bundesamt für Sicherheit in der Informationstechnik.

Herausforderungen bei großen Setups

Wenn dein Cloud-Setup wächst, stößt du auf Probleme, die man am Anfang gar nicht auf dem Schirm hat. Eines davon ist die Datenbank-Performance der Cloud-Steuerung selbst. Jeder Status eines Volumes, jeder Snapshot und jede Verbindung wird in einer SQL-Datenbank (meist MariaDB) festgehalten. Bei zehntausenden Volumes wird diese Datenbank zum kritischen Punkt. Hier hilft nur Index-Optimierung und schnelle Hardware für die DB-Knoten.

Auch die Bereinigung von "Leichen" ist ein Thema. Nutzer erstellen Volumes, vergessen sie, löschen die VM, aber behalten den Speicher. Über Monate hinweg sammeln sich so Terabytes an ungenutzten Daten an, die echtes Geld kosten. Hier helfen automatisierte Skripte, die nach verwaisten Ressourcen suchen und die Besitzer benachrichtigen. Ein gut geführtes Rechenzentrum braucht eine aktive Hygiene der Ressourcen.

Monitoring und Logging

Man kann ein komplexes System nicht blind fliegen. Die Logs der verschiedenen Dienste geben Aufschluss darüber, warum ein Volume-Erstellungsvorgang vielleicht im Status "error" gelandet ist. Oft sind es Kleinigkeiten: Ein Netzwerk-Timeout, ein voller Speicherpool oder ein falsch konfigurierter Authentifizierungstoken. Ich nutze zentralisierte Logging-Systeme wie den ELK-Stack (Elasticsearch, Logstash, Kibana), um alle Events an einem Ort zu haben.

Wenn du siehst, dass der cinder-volume Dienst ständig neu startet, weißt du sofort, wo du suchen musst. Ohne zentrales Logging suchst du dich auf dutzenden Knoten dumm und dämlich. Besonders bei der Fehlersuche im Zusammenspiel mit dem Message-Broker (RabbitMQ) ist ein guter Überblick Gold wert. Wenn die Nachrichten dort hängen bleiben, reagiert die gesamte Cloud träge oder gar nicht mehr auf Speicheranfragen.

Die Zukunft der Speicherverwaltung in der Cloud

Die Entwicklung bleibt nicht stehen. Ein großes Thema ist die Integration von NVMe-over-Fabrics (NVMe-oF). Damit lässt sich die extrem niedrige Latenz von NVMe-Speichern über das Netzwerk fast verlustfrei an die VMs weitergeben. Das wird die Performance-Lücke zwischen lokalem Speicher und Netzwerkspeicher fast vollständig schließen. Viele Treiber arbeiten bereits an der Unterstützung für diese Technologie.

Auch die Verzahnung mit Kubernetes nimmt zu. Über das Container Storage Interface (CSI) können Container direkt Volumes aus der Cloud-Infrastruktur anfordern. Das macht die Verwaltung von persistenten Daten für zustandsbehaftete Anwendungen wie Datenbanken in Containern wesentlich einfacher. Die Cloud-Infrastruktur liefert dabei die bewährte Stabilität, während Kubernetes die Orchestrierung übernimmt. Eine solide Basis findest du in der offiziellen Dokumentation auf OpenStack.org, wo die neuesten API-Änderungen und Treiber-Updates dokumentiert sind.

Praktische nächste Schritte für dein Projekt

Wenn du jetzt loslegen willst, solltest du nicht einfach blind installieren. Hier ist ein Plan, wie du zu einem stabilen Setup kommst:

1. Analysiere deinen Workload genau. Brauchst du hohen Durchsatz (Bandbreite) oder niedrige Latenz (IOPS)? Das entscheidet über die Wahl deiner Hardware und Treiber.
2. Wähle dein Backend weise. Für kleine Setups reicht LVM auf den Knoten, für alles Größere solltest du dir Ceph oder eine dedizierte Storage-Appliance ansehen.
3. Definiere Volume Types von Anfang an. Auch wenn du nur eine Art von Hardware hast, erstelle logische Trennungen. Das macht spätere Migrationen viel einfacher.
4. Setze Monitoring und Quotas am ersten Tag ein. Nichts ist schlimmer, als im Nachhinein Nutzern Ressourcen wegzunehmen oder festzustellen, dass das System seit Tagen am Limit läuft.
5. Teste den Ernstfall. Lösche ein Volume und stelle es aus einem Backup (nicht nur Snapshot!) wieder her. Nur ein getestetes Backup ist ein echtes Backup.
6. Halte deine Treiber aktuell. Die Community fixxt ständig Bugs und verbessert die Performance. Ein regelmäßiger Update-Zyklus spart dir langfristig viele Nerven.

Am Ende ist die Speicherverwaltung kein Hexenwerk, aber sie verzeiht keine Schlamperei. Wer die Mechanismen versteht und die Architektur respektiert, bekommt eine extrem leistungsfähige und flexible Plattform für seine Daten. Es geht darum, die Kontrolle über die eigenen Daten zurückzugewinnen und gleichzeitig die Agilität der Cloud zu nutzen. Viel Erfolg beim Aufbau deiner Infrastruktur!