Einmalige Einblicke

von Martin Loschwitz

Das Ceph-Dashboard hat sich zum effektiven Helfer der Ceph-Administration gemausert und bietet heute viel mehr als nur Klickibunti. Dank seiner Unterstützung verwaltet der Admin Ceph in einer Art und Weise, die auf der Kommandozeile schlicht unmöglich wäre. Somit eröffnet die webbasierte Benutzeroberfläche Wege zur umfassenden Überwachung und Administration von Ceph-Speicher-Clustern. Es visualisiert den Zustand des Clusters, OSD- sowie Poolstatus und ermöglicht das Benutzermanagement.

Storage-Admins schätzen es, wenn sie ihrem Schützling nicht nur per Kommandozeile zu Leibe rücken können, sondern auch über eine grafische Schnittstelle. Nicht ohne Grund bewerben Net-App, Dell, HP und andere Hersteller ihre Storage-Appliances auch mit deren Benutzerschnittstelle. "Alles ganz einfach" lautet die Devise, auch wenn diese Einfachheit in der Praxis mitunter an Grenzen stößt.

Sinnvolle Ergänzung für bessere Übersicht

Das Ceph-Dashboard [1] dient als GUI für den Objektspeicher RADOS und seine Frontends. Es ist längst mehr als eine grafische Ergänzung zur Kommandozeile. Vielmehr verdichtet es Zustands-, Konfigurations- und Metrikdaten, die Ceph im laufenden Betrieb ohnehin sammelt. Während Administratoren sich mit Werkzeugen wie "ceph -s", "ceph health detail", "ceph osd tree" oder "ceph df" ein Bild vom Cluster verschaffen, die gewonnenen Informationen aber erst im Kopf zu einem Gesamtbild zusammenführen müssen, bündelt das Dashboard diese Datenströme ohne Umwege in einer strukturierten Ansicht des gesamten Clusters.

Inzwischen erlaubt es zudem, verschiedene administrative Aufgaben direkt zu erledigen. Das Dashboard ersetzt die Shell also nicht, sondern ergänzt sie sinnvoll um die Stärken einer grafischen Schnittstelle. Ereignisse wie OSD-Ausfälle, Rebalancing-Vorgänge oder inkonsistente Placement Groups erscheinen nicht als isolierte Textmeldungen, sondern im Kontext des Gesamtsystems. Genau dieser Kontext ist im Alltag entscheidend, denn Ceph reagiert auf Störungen fast immer mit Automatismen – und deren Zusammenspiel erfassen Administratoren grafisch deutlich schneller als über mehrere Terminalfenster hinweg.

Praktisch erlaubt das Dashboard eine fast vollständige operative Arbeit am Cluster. Es zeigt den Gesamtzustand, listet Hosts und deren Dienste auf, stellt OSDs samt Auslastung und Gewichtung dar und visualisiert die Verteilung der Placement Groups. Pools lassen sich anlegen, ändern und analysieren, einschließlich Replikationsfaktoren, "min_size"-Parametern und CRUSH-Regeln. Auch die drei zentralen Clientfrontends von Ceph – RBD, CephFS und Ceph Object Gateway – sind integriert. Administratoren sehen RBD-Laufwerke ("Images"), Dateisysteme, Buckets und Benutzer zwar jeweils in eigenen Ansichten. Aus diesen Ansichten lässt sich der Zustand des Clusters jedoch deutlich besser ablesen als allein per CLI. Hinzu kommen Performancedaten, die Latenzen, Durchsatz und I/O-Muster sichtbar machen. Das Dashboard fungiert damit als zentrales Kontrollzentrum.

In der Praxis beschleunigt das Dashboard viele Routineaufgaben deutlich. Pools anlegen, OSDs ersetzen, Benutzer verwalten oder neue CRUSH-Regeln definieren – all das erfolgt über klar strukturierte Oberflächen. Gleichzeitig bleibt Ceph selbst vollständig deterministisch: Jede Aktion im Dashboard entspricht einem klar definierten Befehl oder einem Konfigurationsparameter im Hintergrund. Dabei ist allerdings Vorsicht geboten, wenn parallel Automatisierung eingesetzt wird, etwa über Ansible und das "ansible-cephadm"-Modul. Änderungen über das Dashboard und über automatisierte Konfigurationsverwaltung können miteinander kollidieren. In produktiven Umgebungen sollte deshalb ein klar definierter Prozess festlegen, auf welchem Weg Konfigurationsänderungen erfolgen dürfen.

Ein Dashboard für Teamwork

Seinen besonderen Mehrwert zeigt das Dashboard bei der gemeinsamen Verwaltung von Ceph in Teams. In größeren Umgebungen arbeiten Storage-Administratoren, Plattformbetreiber und Netzwerkverantwortliche parallel am selben Cluster. Nicht jeder Beteiligte arbeitet täglich mit dem CLI oder möchte komplexe Shell-Ausgaben interpretieren. Das Dashboard schafft hier eine gemeinsame Sicht auf den Zustand des Systems. Warnungen sind klar hervorgehoben, Abhängigkeiten visuell nachvollziehbar und Konfigurationsparameter strukturiert abrufbar.

Das reduziert Missverständnisse und beschleunigt Abstimmungen, etwa bei Incidents oder geplanten Wartungsarbeiten. Netzwerker erkennen sofort, wenn der Durchsatz einbricht, Storage-Admins sehen auf einen Blick defekte OSDs, und Linux-Admins entdecken anhand der angezeigten Fehler, wenn im System grund- sätzlich etwas nicht stimmt. Gleichzeitig bleibt die Logik von Ceph unverändert, auch wenn Admins per Dashboard auf den Cluster blicken: Wer eine CRUSH-Regel ändert oder einen Pool neu konfiguriert, greift weiterhin direkt in die zugrunde liegenden Mechanismen ein.

Wichtig ist deshalb auch die richtige Erwartungshaltung. Das Dashboard ist kein GUI im Stil klassischer NAS- oder SAN-Appliances. Es blendet die Komplexität nicht aus, sondern macht sie nachvollziehbar. Wer Ceph betreibt, muss weiterhin verstehen, was Replikation, Failure Domains oder Backfill bedeuten. Das Dashboard hilft jedoch dabei, diese Konzepte im laufenden Betrieb schneller zu erfassen und gezielt zu steuern. Es ist damit weder Spielerei noch Marketing-Zugabe, sondern ein ernstzunehmendes Werkzeug, mit dem Administratoren die Komplexität eines großen, verteilten Speichersystems beherrschen.

Dashboardmodul gezielt aktivieren

In aktuellen Ceph-Installationen, die mit "cephadm" und dem integrierten Orchestrator arbeiten, gehört das Dashboard technisch bereits zum System. Es handelt sich um ein Modul des Ceph-Managers (MGR), das dieser als Container-Dienst bereitstellt. Standardmäßig ist das Modul jedoch nicht automatisch aktiv oder erreichbar. Sie müssen es daher zunächst einschalten und sicherstellen, dass der Dienst tatsächlich läuft. Dazu aktivieren Sie das Dashboardmodul im Ceph-Manager mit dem Befehl:

Je nach Konfiguration kann es vorkommen, dass das Dashboard danach noch nicht sofort startet. In diesem Fall ermitteln Sie zunächst mit ceph -s den aktuell aktiven Manager-Daemon. Anschließend beenden Sie diesen gezielt mit ceph mgr fail <Name>. Der Ceph-Cluster übernimmt den Manager-Dienst automatisch auf einem anderen Knoten. Für den laufenden Betrieb entsteht daraus kein Risiko: Der Ausfall eines Ceph-Manager-Daemons führt weder zu Downtime noch zu einem Neustart anderer Cluster-Dienste.

TLS-Zertifikat und Benutzer für das Dashboard einrichten

Im nächsten Schritt benötigt das Dashboard ein TLS-Zertifikat. Für Testumgebungen genügt ein selbstsigniertes Zertifikat:

Betreiben Sie hingegen eine interne SSL-CA, erstellen Sie dort zunächst ein Zertifikat für den Hostnamen, unter dem das Dashboard erreichbar sein soll. In Ceph-Versionen bis einschließlich 20 ist dafür häufig zusätzlich ein Loadbalancer erforderlich, der den Dashboardport bereitstellt und idealerweise auch die SSL-Terminierung übernimmt. Dieser leitet die Anfragen anschließend an den Dash- board-Dienst weiter.

Statten Sie das Dashboard direkt mit einem Zertifikat aus, hinterlegen Sie Zertifikat und Schlüssel mit:

Anschließend legen Sie einen Administratorbenutzer an:

Danach melden Sie sich mit dem definierten Benutzernamen und dem Passwort aus der entsprechenden Datei am Dashboard an. Die Adresse des Webfront-ends ermitteln Sie mit ceph mgr services. Ceph zeigt daraufhin die URL an, unter der das Dashboard erreichbar ist.

Dashboard in abgeschotteten Umgebungen bereitstellen

In cephadm-Installationen stellt Ceph sämtliche Komponenten als Container-Images bereit. Das Dashboard ist deshalb auf ein korrekt referenziertes Ceph-Image angewiesen. Standardmäßig lädt Ceph dieses aus der Red-Hat-Registry unter "quay.io". In abgeschotteten Umgebungen – etwa in regulierten Enterprise-Infrastrukturen – ist ein direkter Internetzugriff jedoch häufig nicht erlaubt. In solchen Fällen muss eine lokale Container-Registry das passende Ceph-Image bereitstellen. In diesem Fall definieren Sie das verwendete Basis-Image global mit:

Ist dieser Wert falsch oder kann der Cluster die Registry nicht erreichen, schlägt das Deployment fehl. Gerade in produktiven Umgebungen mit restriktiven Firewallregeln entscheidet dieser Punkt darüber, ob das Dashboard binnen Minuten verfügbar ist oder ob sich die Fehlersuche unnötig verlängert. Ist die Container-Versorgung korrekt eingerichtet, startet der Manager-Dienst das Dashboard hingegen problemlos.

Übersicht zeigt den Zustand des Clusters

Nach dem ersten Login präsentiert sich das Ceph-Dashboard mit einer klar strukturierten Oberfläche. Links befindet sich die Navigationsleiste, rechts der jeweilige Arbeitsbereich. Anders als klassische Installationsassistenten zwingt das Dash-board den Administrator nicht in eine feste Abfolge von Schritten. Stattdessen zeigt es jederzeit den aktuellen Zustand des Clusters und erlaubt den direkten Zugriff auf einzelne Funktionsbereiche.

Der erste Blick sollte immer der Übersichtsseite gelten. Das zentrale Dashboard fasst den Gesundheitszustand zusammen, liefert Warnungen oder Fehler prominent an und visualisiert Kerndaten wie die Anzahl aktiver OSDs, die Gesamt- und Restkapazität sowie den Zustand der Placement Groups. Hier zeigt sich schnell, ob akuter Handlungsbedarf besteht oder ob das System stabil arbeitet. Ein Cluster im Zustand "HEALTH_WARN" erfordert eine andere Aufmerksamkeit als ein sauber laufender "HEALTH_OK"-Verbund. Besonders hilfreich ist dabei, dass Warnmeldungen direkt mit den jeweils betroffenen Detailansichten verknüpft sind.

Im nächsten Schritt empfiehlt sich ein Blick in die Host- und Cluster-Ansichten. Unter "Cluster" erscheinen MONs, MGRs und weitere Dienste in logischer Struktur. Unter "Hosts" blendet das Dashboard hingegen die physische Ebene ein: Welche Server vorhanden sind, welche Dienste auf ihnen laufen und ob einzelne Knoten Auffälligkeiten zeigen. Diese Trennung zwischen logischer und physischer Sicht ist bewusst gewählt. Während das CLI häufig zwischen diesen Ebenen wechselt oder beide vermischt, stellt das Dashboard sie nebeneinander dar und erleichtert so die Einordnung.

Zu den ersten administrativen Maßnahmen gehört außerdem die Telemetrie-Konfiguration. Unter "Administration / Manager-Module / Telemetry" legen Sie fest, ob anonymisierte Nutzungsdaten an das Ceph-Projekt übermittelt werden sollen. Ein frisch eingerichtetes Dashboard weist mit einer Warnmeldung ausdrücklich darauf hin. In produktiven Umgebungen ist diese Entscheidung jedoch nicht nur technischer, sondern oft auch regulatorischer Natur.

Benutzer- und Rollenmodell festlegen

Ebenfalls frühzeitig zu prüfen sind Benutzer und Rollen. Das initial gesetzte Admin-Passwort, sofern Sie es einst als Parameter für "cephadm bootstrap" definiert haben, sollten Sie nicht dauerhaft verwenden. Unter "Administration / Users" lassen sich zusätzliche Accounts anlegen, Rollen vergeben und das Administratorpasswort ändern. Gerade in Teams empfiehlt sich eine klare Trennung zwischen Lese- und Schreibrechten sowie eine saubere Abgrenzung der Berechtigungen einzelner Benutzer.

Abschließend lohnt sich ein Blick in die Konfigurationsansicht. Das Dashboard listet dort zentrale Cluster-Parameter auf und erlaubt gezielte Anpassungen. Auch wenn zunächst keine Änderungen geplant sind, vermittelt diese Übersicht ein Gefühl für die vorhandenen Stellschrauben. Wer das Dashboard nicht nur als Monitoringwerkzeug, sondern als operatives Instrument nutzt, sollte sich früh mit dieser Struktur vertraut machen – denn im Störfall bleibt selten Zeit für eine erste Orientierung.

Pools strukturieren die Datenspeicherung

Pools bilden in Ceph die logischen Container für Daten. Jede Anwendung – ob RBD, CephFS oder Object Gateway – schreibt letztlich in einen oder mehrere Pools. Entsprechend sorgfältig sollte deren Anlage erfolgen. Das Dashboard nimmt dem Administrator diese Entscheidung nicht ab, erleichtert jedoch den Zugriff auf die relevanten Parameter. Zum Anlegen eines neuen Pools navigieren Sie im Menü zu "Cluster / Pools" und klicken auf "Erstellen". Es öffnet sich eine Maske, in der zunächst der Name des Pools festzulegen ist. Der Name sollte sprechend gewählt sein, etwa "rbd-prod" oder "cephfs-data", um spätere Verwechslungen zu vermeiden.

Anschließend wählen Sie den Pooltyp. In den meisten klassischen Installationen handelt es sich um einen replizierten Pool ("replicated"). Alternativ existieren Erasure-Coded-Pools. Diese eignen sich vor allem für sehr große Datenmengen mit höherem Kapazitätsbedarf, besitzen jedoch eine andere Performancecharakteristik und reagieren insbesondere bei Recovery- oder Backfill-Prozessen meist träger.

Bei einem replizierten Pool sind zwei Parameter zentral: "size" und "min_size". Der Wert "size" definiert, wie viele vollständige Kopien eines Objekts im Cluster existieren. Ein Wert von "3" bedeutet beispielsweise drei Replikate auf unterschiedlichen OSDs gemäß der definierten CRUSH-Regel. Der Parameter "min_size" legt fest, wie viele dieser Kopien verfügbar sein müssen, damit Schreibzugriffe weiterhin erlaubt sind. Ist "size" auf "3" und "min_size" auf "2" gesetzt – wie es der Standard vorsieht – akzeptiert Ceph Schreibzugriffe auch dann, wenn eine Kopie temporär fehlt. Sinkt die Anzahl verfügbarer Kopien unter "min_size", blockiert Ceph sämtliche Schreibzugriffe, um Datenverlust zu vermeiden. Dieses Verhältnis ist sicherheitskritisch und Änderungen sollten Sie daher sorgfältig abwägen.

Physische Datenverteilung festlegen

Ein weiterer entscheidender Punkt ist die Auswahl der CRUSH-Regel für einen neuen Pool. Im Drop-down-Menü "CRUSH rule" wählen Sie die passende Regel aus und definieren damit indirekt auch die "Failure Domain" – typischerweise "host", "rack" oder eine benutzerdefinierte Ebene. Die Regel bestimmt, wie Ceph Replikate physisch im Cluster verteilt. Replikation auf Hostebene schützt vor dem Ausfall einzelner Server, nicht jedoch vor dem Verlust eines gesamten Racks. Die gewählte Regel muss daher zur tatsächlichen Infrastruktur des RADOS-Clusters passen. Ein logisch korrekt gesetzter "size"-Wert verliert seinen Nutzen, wenn alle Replikate im selben physischen Ausfallbereich landen.

Nach der Bestätigung legt das Dashboard den Pool sofort an. In der Detailansicht lassen sich die gesetzten Parameter prüfen und bei Bedarf anpassen. Änderungen an "size" oder an CRUSH-Regeln wirken sich unmittelbar auf die Datenverteilung aus und können Rebalancing-Prozesse auslösen. Das Dashboard zeigt diese Vorgänge transparent an, sodass Administratoren nachvollziehen können, welche internen Prozesse gerade laufen. Genau hier liegt der praktische Vorteil des GUI: Sie verbindet Konfiguration mit unmittelbarer Sichtbarkeit der Folgen.

OSDs kontrolliert außer Betrieb nehmen

Object Storage Daemons (OSD) bilden das Rückgrat eines Ceph-Clusters. Sie repräsentieren die Dienste, die physische Blockgeräte verwalten und Daten tatsächlich speichern. Fällt ein Laufwerk aus oder soll Hardware ersetzt werden, ist ein sauberer Ablauf entscheidend. Das Dashboard unterstützt diesen Prozess, ohne die internen Mechanismen von Ceph zu verbergen.

Um einen OSD außer Betrieb zu nehmen, navigieren Sie zunächst zu "Cluster / OSDs". In der Übersicht erscheinen alle Daemons mit Status, Gewichtung, Auslastung und Hostzuordnung. Einen OSD, der dauerhaft entfernt werden soll, setzen Sie zunächst auf "Out". Dazu wählen Sie den betreffenden OSD aus und klicken auf "Bearbeiten / Mit Befehl 'Out' markieren". Dieser Schritt signalisiert dem Cluster, dass dieser OSD künftig nicht mehr für neue Daten genutzt werden soll. Ceph startet daraufhin ein Rebalancing und verteilt vorhandene Daten gemäß CRUSH-Regel auf verbleibende OSDs. Ist das physische Laufwerk bereits ausgefallen, setzt der Cluster den entsprechenden OSD nach etwa zehn Minuten automatisch auf "Out".

Erst wenn die Datenmigration abgeschlossen ist – was sich im Dashboard über den Zustand der Placement Groups nachvollziehen lässt –, sollten Sie den OSD endgültig eliminieren. Über "Entfernen" löschen Sie den Daemon aus dem Cluster-Kontext. Das Dashboard führt durch die notwendigen Bestätigungsschritte, da dieser Vorgang nicht reversibel ist. Wichtig ist dabei, nicht vorschnell zu handeln: Ein verfrühtes Entfernen löst unnötiges Rebalancing aus und erzeugt zusätzliche Last im Cluster. Der Vorgang im Dashboard sorgt dafür, dass Ceph den OSD aus der OSD-Map, aus der CRUSH-Map, aus dem Authentifizierungssystem CephX und auch aus der Dienstübersicht im Ceph-Manager entfernt. Auf der Kommandozeile sind dafür mehrere separate Befehle notwendig.

Nach dem Austausch eines defekten Laufwerks stellt sich die Frage, wie Sie einen neuen OSD hinzufügen. In cephadmInstallationen erkennt der Orchestrator neue, ungenutzte Blockgeräte häufig automatisch. Unter "Cluster / Hosts / Physische Laufwerke" erscheint das neue Gerät mit entsprechender Statusanzeige. Von dort aus wählen Sie das Laufwerk aus und provisionieren es per Klick als OSD. Ceph initialisiert das Gerät, legt die notwendigen Strukturen an und startet den zugehörigen Daemon. Je nach Konfiguration kann es auch vorkommen, dass RADOS ein neues Laufwerk automatisch als OSD konfiguriert.

Fehlersuche bei nicht erkannten Laufwerken

Erkennt RADOS ein leeres Blockgerät nicht automatisch, sind zunächst grundlegende Prüfungen erforderlich. Wird das Gerät vom Betriebssystem korrekt erkannt, etwa über "lsblk"? Befinden sich noch alte Partitionstabellen oder LVM-Metadaten auf dem Datenträger? In solchen Fällen müssen Sie das Laufwerk zunächst bereinigen, beispielsweise über einen "zap"-Vorgang mit dem cephadm-Werkzeug auf CLI-Ebene. Erst wenn das Blockgerät vollständig leer ist, akzeptiert Ceph es als neuen OSD. Bei fabrikneuen Laufwerken spielt dieser Punkt in der Praxis allerdings selten eine Rolle.

Nach erfolgreicher Provisionierung zeigt das Dashboard den neuen Daemon sofort in der OSD-Liste an. Ebenso wird sichtbar, wenn Backfill- oder Recovery-Prozesse starten. Administratoren sehen dadurch nicht nur, dass ein neues OSD existiert, sondern auch, wie sich dessen Integration auf die Datenverteilung im Cluster auswirkt. Gerade in größeren Umgebungen erleichtert diese visuelle Rückmeldung die Einschätzung erheblich.

CephX-Nutzer für den Zugriff auf Clusterressourcen anlegen

CephX bildet die Authentifizierungs- und Autorisierungsschicht des Clusters. Jeder Client – ob RBD, CephFS oder Ceph Object Gateway – greift mit einem eigenen Schlüssel auf Ressourcen zu. Dasselbe gilt für Clientanwendungen wie OpenStack oder Kubernetes. Eine saubere Verwaltung dieser Schlüssel ist daher sicherheitskritisch.

Zum Anlegen eines neuen CephX-Benutzers navigieren Sie im Dashboard zu "Administration / Users". Dort erscheint eine Liste bestehender Accounts inklusive ihrer "Capabilities" (Caps) für MON, OSD und MDS. Über "Create" starten Sie den Assistenten für einen neuen Benutzer. Wichtig: Hier geht es um Benutzer für den Zugriff auf RADOS, nicht um Accounts für den Zugriff auf das Dashboard. Zunächst definieren Sie den Benutzernamen im Schema "client.<name>". Anschließend legen Sie die Berechtigungen fest. Die Capabilities bestimmen exakt, welche Operationen ein Client ausführen darf. Ein typisches Beispiel ist:

- mon: allow r: Leserechte auf Monitorebene

- osd: allow rw pool=testpool: Lese- und Schreibrechte auf einen bestimmten Pool

CephFS-Clients benötigen zusätzlich Zugriff auf die Metadaten-Server. Die feingranulare Rechtevergabe unterstützt Administratoren dabei, Compliancevorgaben umzusetzen. Statt pauschaler Vollrechte sollte konsequent das Prinzip der minimalen Berechtigung gelten. Das Dash- board stellt dafür strukturierte Eingabefelder bereit, sodass Sie die Capabilities nicht manuell zusammensetzen müssen.

Nach dem Speichern erzeugt Ceph automatisch den zugehörigen Schlüssel. Das Dashboard zeigt diesen sofort an und bietet ihn zum Download an. Dieser Moment ist sicherheitsrelevant: Den Schlüssel sollten Sie unmittelbar an den vorgesehenen Empfänger übergeben und nicht ungeschützt ablegen.

Fazit

Das Ceph-Dashboard ist kein dekoratives Add-on und auch kein Versuch, die Kommandozeile zu verdrängen. Es ist ein operatives Werkzeug, das die Komplexität eines verteilten Speichersystems sichtbar und strukturierbar macht. Gerade im laufenden Betrieb zeigt sich sein Nutzen: Zustände erscheinen nicht nur als Meldungen, sondern im Kontext des Gesamtsystems. Konfigurationsänderungen lassen sich unmittelbar mit ihren Auswirkungen verknüpfen. OSD-Ausfälle, Pool-Anpassungen oder Änderungen von CRUSH-Regeln werden sichtbar, ohne mehrere CLI-Ausgaben gedanklich korrelieren zu müssen.

Wer Ceph produktiv betreibt, sollte das Dashboard nicht als optionales Komfortmerkmal betrachten. Es ist ein Werkzeug für bessere Übersicht, strukturierte Zusammenarbeit im Team und schnellere Reaktionen im Störfall. Das GUI ersetzt kein Verständnis der Architektur – es hilft jedoch entscheidend dabei, dieses Verständnis im operativen Alltag effizient anzuwenden.