Ceph-Storage für die Private Cloud: Architektur-Guide

Storage ist der Teil einer Private Cloud, auf den sich alle verlassen und über den fast niemand nachdenken möchte, bis er ausfällt. Klassische Speicher-Arrays lösten das, indem sie Geld auf das Problem warfen: doppelte Controller, proprietäre Plattenregale und ein passender Supportvertrag. Ceph geht einen grundlegend anderen Weg. Es verwandelt einen Verbund gewöhnlicher Server und ihrer Festplatten in ein einziges, selbstheilendes, software-definiertes Speichersystem, das von einer Handvoll Knoten bis zu Tausenden skaliert, ohne dass ein kompletter Austausch nötig wird.

Wer eine Private Cloud baut oder bewertet, sollte verstehen, wie Ceph funktioniert, denn es bildet die Grundlage für Block-, Objekt- und Dateispeicher, auf die virtuelle Maschinen und Anwendungen angewiesen sind. Dieser Leitfaden führt von Grund auf durch die Architektur, erklärt die entscheidende Wahl zwischen Replikation und Erasure Coding und zeigt, wie Ceph in OpenStack-Dienste wie Cinder und Glance eingreift.

Was Ceph eigentlich ist

Ceph ist eine verteilte Speicherplattform, die aus einem einzigen zugrundeliegenden Cluster drei Schnittstellen bereitstellt: Blockspeicher (RBD, das RADOS Block Device) für die Festplatten virtueller Maschinen, Objektspeicher (ein S3-kompatibles Gateway) für unstrukturierte Daten und Backups sowie ein POSIX-Dateisystem (CephFS) für gemeinsamen Dateizugriff. Alle drei sitzen auf demselben Fundament, einem zuverlässigen, autonomen, verteilten Objektspeicher namens RADOS.

Das Entwurfsziel hinter RADOS ist leicht gesagt und schwer erreicht: kein Single Point of Failure und kein zentraler Flaschenhals. Es gibt keinen zentralen Controller, durch den jeder Lese- und Schreibvorgang laufen muss. Stattdessen berechnen die Clients selbst, wo Daten liegen, und sprechen die zuständigen Knoten direkt an. Genau diese Eigenschaft lässt Ceph nahezu linear skalieren, wenn Hardware hinzukommt.

Die Kernkomponenten

Ein Ceph-Cluster besteht aus wenigen unterschiedlichen Daemons, jeder mit einer klaren Aufgabe. Sie zu verstehen entzaubert das meiste, was in Monitoring-Dashboards auftaucht.

OSDs: wo die Daten liegen

Ein Object Storage Daemon (OSD) verwaltet ein einzelnes Speichergerät, typischerweise eine Festplatte oder SSD. Er speichert die eigentlichen Datenobjekte, kümmert sich um die Replikation zu seinen Nachbarn und beteiligt sich an der Wiederherstellung, wenn ein Gerät ausfällt. Ein Produktiv-Cluster betreibt von einem Dutzend bis zu Tausenden OSDs, und sie leisten die eigentliche Arbeit des gesamten Systems. Als Faustregel läuft ein OSD pro physischer Platte, sodass Kapazität und Durchsatz gemeinsam mit der Zahl der Platten wachsen.

Monitore: die Quelle der Wahrheit

Monitor-Daemons (MONs) pflegen die Cluster-Map, das maßgebliche Verzeichnis darüber, welche OSDs existieren, welche aktiv sind und wie Daten verteilt werden sollen. Clients fragen die Map ab, um zu wissen, wo sie lesen und schreiben. Da die Map kritisch ist, laufen Monitore als kleines, ungeradzahliges Quorum (typischerweise drei oder fünf), damit der Cluster stets eine konsistente, einvernehmliche Sicht auf seinen eigenen Zustand hat.

Manager und Metadatenserver

Manager-Daemons (MGRs) kümmern sich neben den Monitoren um Metriken, Dashboards und Orchestrierung. Wer CephFS nutzt, hat Metadatenserver (MDS), die Namensraum, Verzeichnishierarchie und Berechtigungen des Dateisystems verwalten, damit Dateioperationen schnell bleiben, ohne die Objektschicht zu belasten.

Wie Ceph Daten platziert: CRUSH

Die mit Abstand wichtigste Idee in Ceph ist, dass es keine zentrale Nachschlagetabelle führt, die jedes Objekt einem Ort zuordnet. Eine solche Tabelle würde im großen Maßstab zum Flaschenhals und zum Risiko. Stattdessen verwendet Ceph einen Algorithmus namens CRUSH (Controlled Replication Under Scalable Hashing).

CRUSH erlaubt es jedem Client oder OSD, allein aus Cluster-Map und Objektnamen exakt zu berechnen, welche Geräte ein bestimmtes Datenstück halten sollen. Daten werden in Placement Groups gebündelt, und CRUSH bildet diese Gruppen deterministisch nach selbst definierten Regeln auf OSDs ab. Weil die Platzierung berechnet und nicht nachgeschlagen wird, gibt es kein zentrales Verzeichnis, das überlastet werden könnte, und der Cluster kann sich bei Hardwareänderungen selbst neu ausbalancieren.

CRUSH kennt zudem die Topologie. Sie beschreiben Ihren physischen Aufbau, welche Platten in welchem Host, welche Hosts in welchem Rack, welche Racks in welchem Raum, und CRUSH verteilt die Repliken über diese Fehlerdomänen. Der praktische Nutzen: Sie können Ceph anweisen, nie zwei Kopien derselben Daten ins selbe Rack zu legen, sodass der Verlust eines ganzen Racks nicht den Verlust Ihrer Daten bedeutet.

Replikation vs. Erasure Coding

Dies ist die Entscheidung, die das Kosten- und Resilienzprofil eines Clusters am stärksten prägt, und es lohnt sich, sie richtig zu verstehen.

Replikation

Bei der Replikation hält Ceph mehrere vollständige Kopien jedes Objekts vor, üblicherweise drei. Fällt eine Platte aus, existieren die Daten noch an zwei anderen Stellen, und der Cluster beginnt sofort, sie anderswohin zu kopieren, um die Zahl der Repliken wiederherzustellen. Replikation ist einfach, schnell und erholt sich zügig, was sie zur natürlichen Wahl für leistungssensiblen Blockspeicher macht. Der Preis ist Kapazität: Dreifachreplikation bedeutet, dass nur ein Drittel der Rohkapazität nutzbar ist.

Erasure Coding

Erasure Coding arbeitet wie eine klügere, verteilte Variante von RAID. Statt vollständiger Kopien zerlegt Ceph jedes Objekt in Daten-Chunks plus eine Anzahl Paritäts-Chunks und verteilt sie über viele OSDs. Ein gängiges 4+2-Profil etwa verträgt den Verlust beliebiger zwei Chunks und liefert dabei rund 67 Prozent nutzbare Kapazität, weit mehr als die 33 Prozent der Dreifachreplikation.

Der Kompromiss liegt in Rechenaufwand und Latenz. Daten aus Parität zu rekonstruieren kostet CPU und bindet mehr Knoten pro Vorgang, weshalb Erasure Coding eher zu großen, durchsatzorientierten Daten wie Backups, Archiven und Objektspeicher passt als zu heißen, latenzsensiblen Volumes. Viele Cluster nutzen beides: replizierte Pools für VM-Platten, Erasure-codierte Pools für Massen- und Kaltdaten.

Selbstheilung und Resilienz in der Praxis

Ceph ist darauf ausgelegt, von Hardwareausfällen auszugehen, denn im großen Maßstab treten sie immer auf. Fällt ein OSD aus, aktualisieren die Monitore die Cluster-Map, die betroffenen Placement Groups werden als degradiert markiert, und die überlebenden OSDs beginnen, die fehlenden Daten neu zu replizieren, um die volle Redundanz wiederherzustellen, alles ohne Eingriff des Betreibers.

Im Hintergrund läuft fortlaufend ein Scrubbing, das Repliken und Prüfsummen vergleicht, um stille Datenkorruption (Bit Rot) zu erkennen, bevor sie sich ausbreitet. Das Ergebnis ist ein System, das Ausfälle nicht nur übersteht, sondern aktiv an der eigenen Integrität arbeitet. Für den Betreiber verschiebt sich der Speicheralltag von reaktivem Feuerlöschen hin zu Kapazitätsplanung und Überwachung.

Wie Ceph eine OpenStack-Private-Cloud antreibt

Ceph und OpenStack sind ein natürliches Gespann, und Ceph ist das De-facto-Storage-Backend für ernsthafte OpenStack-Deployments. Die Integration berührt mehrere Dienste. Cinder, der Blockspeicherdienst, stellt RBD-Volumes für VM-Platten bereit, sodass eine VM mit Speicher erzeugt, per Snapshot gesichert und vergrößert werden kann, der über den gesamten Cluster verteilt liegt statt auf einem einzelnen Host. Glance, der Image-Dienst, legt VM-Images in Ceph ab, und weil Glance und Cinder dasselbe Backend teilen, wird das Erzeugen eines Volumes aus einem Image zu einem nahezu sofortigen Copy-on-Write-Klon statt zu einer langsamen Datenübertragung.

Nova, der Compute-Dienst, kann Instanzen direkt von Ceph-gestützten Volumes booten, womit eine VM nicht mehr an die lokale Platte eines einzelnen Hypervisors gebunden ist. Fällt dieser Host aus, lässt sich die Instanz anderswo neu starten, weil ihr Speicher von vornherein nicht lokal war. Das ist die Grundlage für Live-Migration und Hochverfügbarkeit in einer Private Cloud.

Einen Cluster dimensionieren und planen

Einige Planungsprinzipien ersparen später viel Ärger. Beginnen Sie mit mindestens drei Knoten, damit Replikation und Monitor-Quorum einen Platz haben; kleinere Cluster vertragen einen Ausfall nicht sauber. Planen Sie Kapazitätsreserven ein, denn ein Cluster, der sich über rund 80 Prozent füllt, verliert den freien Platz, den er nach einem Ausfall zur Neu-Replikation braucht. Stimmen Sie das Netz auf Ihre Platten ab, denn Wiederherstellungs- und Replikationsverkehr läuft übers Netz, ein schnelles, dediziertes Storage-Netz (oft 25GbE oder mehr) hält Rebuilds rasch und die Client-I/O flüssig. Und behalten Sie Fehlerdomänen von Beginn an im Blick, indem Sie Knoten über Racks und Stromkreise verteilen, damit CRUSH Daten sicher platzieren kann.

Warum das für souveräne Infrastruktur zählt

Der Reiz von Ceph ist nicht nur technischer Natur. Weil es auf Standardhardware läuft und vollständig quelloffen ist, beseitigt es die Abhängigkeit von einem einzelnen Speicheranbieter und der damit verbundenen Lizenzierung, was für Organisationen, die echte Kontrolle über ihre eigene Infrastruktur anstreben, enorm wiegt.

Genau deshalb steht Ceph im Zentrum der clouditiv-Plattform. Wir nutzen es als einheitliche Speicherschicht unter unseren OpenStack-Private-Clouds und hinterlegen Cinder-Volumes und Glance-Images mit replizierten und Erasure-codierten Pools, die auf den jeweiligen Workload abgestimmt sind, alles in deutschen Rechenzentren und im Einklang mit den Compliance-Anforderungen europäischer Organisationen. Für Teams, die von klassischer Virtualisierung wegwollen, zeigt unser Leitfaden zur Migration von VMware zu OpenStack, wie eine Ceph-gestützte Cloud die proprietären Speicher-Arrays der Vergangenheit ablöst, und das Gesamtbild finden Sie auf unserer On-Premise-Cloud-Plattform.

Das Wesentliche

Ceph ersetzt das monolithische Speicher-Array durch etwas Flexibleres und Beständigeres: einen Verbund von Standardservern, der Ihre Daten automatisch organisiert, schützt und heilt. Sein CRUSH-Algorithmus beseitigt den zentralen Flaschenhals, seine Optionen aus Replikation und Erasure Coding lassen Sie die Balance aus Kosten und Resilienz pro Workload einstellen, und seine enge Integration mit OpenStack macht es zum Rückgrat einer modernen Private Cloud. Es zu verstehen ist der Unterschied zwischen Speicher als Blackbox und Speicher, der bewusst für die Beständigkeit entworfen wurde, die Ihre Anwendungen verdienen.