Eine an softwarebasierte Speicherlösungen gerichtete Kritik ist, dass es ihnen an funktionalen Verwaltungswerkzeugen mangelt. Wer sich hingegen mit den typischen SAN- oder NAS-Appliances der etablierten Hersteller schon mal beschäftigt hat, weiß: Hier gibt es üblicherweise ein Webinterface mit ein paar virtuellen Lämpchen, die per Signalfarbe den Zustand der Daten symbolisieren. Ist die Lampe grün, schlafen Sie ruhig, weil Sie wissen, dass es den eigenen Daten gut geht. Und nicht nur über den Zustand der Daten geben die Managementwerkzeuge der etablierten Hersteller Auskunft. Sie erlauben auch das gefahrlose Durchführen bestimmter Vorgänge. Wer etwa in einem SAN eine LUN einrichten möchte, den führt der grafische Assistent ohne Probleme durch diesen Vorgang.

Um das Problem für Ceph zu lösen, arbeiten dessen Entwickler seit einigen Jahren am "Ceph Dashboard". Dieses gehört mittlerweile fest zu Ceph und hat, seit es einst als Fork des Speicherverwaltungssystems openATTIC [1] an den Start ging, eine heftige Entwicklung zurückgelegt. Vielen Administratoren ist das Tool bis heute trotzdem weitgehend unbekannt. Dieser Beitrag stellt das Dashboard für Ceph vor. Wie gehen Sie vor, um es zu aktivieren? Welche Informationen lassen sich aus ihm gewinnen? Und welche Wartungsaufgaben führt das Ceph-Dashboard auf Zuruf aus?

Die gute Nachricht gleich vorweg: Das Dashboard ist sehr gut in Ceph integriert. Wer einen aktuellen Ceph-Cluster einsetzt, betreibt womöglich das Dashboard schon, ohne es zu merken. Der Grund dafür: Über die Jahre hat Ceph mehrere radikale Veränderungen durchlaufen, was seine eigene Toolchain angeht. Als der Weisheit vorläufig letzter Schluss hat sich das Management-Framework für Ceph herausgestellt. Dieses ist eine Art Orchestrierungsdienst, der speziell auf Ceph und seine Bedürfnisse zugeschnitten ist. Das neue Deployment-Werkzeug für Ceph, "cephadm" [2], fußt ebenso auf dem Management-Framework im Hintergrund wie eben auch das Ceph-Dashboard. "ceph-mgr" [3], so die etwas sperrige Kurzform des Frameworks, gehört in einem Ceph-Deployment heute zur Standardinstallation. Und die meisten Ceph-Produkte installieren das Dashboard dann auch gleich mit.

Vollständig sind Sie damit allerdings noch nicht aus dem Schneider – denn je nach lokalen Vorgaben kann es im Hinblick auf das Ceph-Dashboard notwendig sein, noch ein paar zusätzliche Befehle auszuführen. Im Folgenden geht es deshalb zunächst darum, wie Sie das Dashboard in der für Sie idealen Konfiguration an den Start bringen.

Zunächst haben Sie die Aufgabe vor der Brust, jene Hosts herauszufinden, auf denen eine Instanz von ceph-mgr läuft. Es handelt sich bei diesen um dieselben Hosts, die auch eine Instanz des Dashboards betreiben. Anders als vielleicht erwartet, kommt das Ceph-Dashboard nicht als geclusterter Dienst daher. Folglich ist es auch notwendig, das Ceph-Dashboard pro Manager-Instanz zu konfigurieren, nicht Cluster-weit. Um die Hosts zu identifizieren, die die Manager-Komponente betreiben, genügt der Befehl ceph mgr services auf jedem Host, auf dem das ceph-Kommando grundsätzlich funktioniert. Die MON-Server sind hier in aller Regel die sicherste Wette. Ein MON-Server ist im Ceph-Kontext eine Art Cluster-Wachhund. Er erzwingt für Cluster-Partitionen ein Quorum, um Split-Brain-Situationen zu verhindern, und führt Buch über alle vorhandenen MON- und OSD-Dienste. OSD (Object Storage Daemon) ist ein Ceph-eigener Dienst, der aus einem beliebigen Block-Storage-Device einen für Ceph nutzbaren Datenträger macht.

Für jede Instanz des Ceph-Dashboards konfigurieren Sie anschließend per

die IP-Adresse, wobei "NAME" durch den Namen der ceph-mgr-Instanz zu ersetzen ist. Die Ports für die Verbindung per HTTP(S) lassen Sie idealerweise unangetastet – es sei denn, Sie haben es mit einer komplizierten Firewall-Konfiguration zu tun. Dann setzt der Befehl

den passenden Wert, wobei "NAME" wieder zu ersetzen ist. Wichtig: Wollen Sie auf die einzelnen Ceph-Dashboards zugreifen, müssen Sie das natürlich über deren jeweilige IP-Adresse tun.

Sie melden sich mit einer Kombination aus Benutzername und Passwort am Dashboard an. Da liegt es auf der Hand, dass die Kommunikation des Browsers mit dem Dash-board unbedingt verschlüsselt sein sollte. Ab Werk richtet ceph-mgr das auch so ein – allerdings nutzt es dafür ein selbsterstelltes und selbstsigniertes SSL-Zertifikat. Wer ein SSL-Zertifikat braucht, das die hausinterne CA oder gar eine offizielle CA ausgestellt hat, muss das ceph-mgr-Zertifikat also ersetzen. Das Beispiel geht im Folgenden davon aus, dass ein Wildcard-Zertifikat für "*.example.net" in der Datei "cert.pem" vorliegt und dessen passwortloser Schlüssel in "key.pem". Wird für die SSL-CA ein Zwischenzertifikat benötigt, muss dieses ebenfalls in "cert.pem" vorliegen. Die Installation verläuft danach simpel:

Der Befehl ceph mgr module disable dashboard gefolgt von ceph mgr module enable dashboard startet im nächsten Schritt die Mgr-Komponente und mithin auch das Dashboard neu. Danach steht dieses mit offiziellem SSL-Zertifikat zur Verfügung, wenn Sie es über den richtigen Hostnamen aufrufen.

Weil das Dashboard in den vergangenen Jahren immer wieder neue Funktionen erhalten hat, kann der Einstieg etwas schwerfallen. Es schadet nicht, sich nach dem ersten Dashboard-Login mit den verschiedenen Menü-Einträgen vertraut zu machen. Eine zentrale Neuerung im Octopus-Release von Ceph war die Einführung der Navigationsleiste am linken Bildschirmrand. Diese trägt zur Übersichtlichkeit bei, weil sie die wichtigsten Menü-Einträge in Cluster aufteilt und zusammenhängend darstellt.

Unter dem Menüpunkt "Cluster" (Bild 1) verbergen sich etwa solche Einträge, die sich auf die Komponenten des Objektspeichers RADOS selbst beziehen. Das umfasst die MON- und OSD-Dienste, alle genutzten Festplatten, die von den Diensten erzeugten Logdateien und die Konfiuguration der ceph-mgr-Komponente. Darüber hinaus erhalten Sie hier auch einen Einblick in die CRUSH-Map. Zur Erinnerung: CRUSH steht im Ceph-Kontext für "Continuous Replication Under Scalable Hashing" und beschreibt den Algorithmus, den Ceph nutzt, um Daten nach bestimmten Regeln auf die vorhandenen Festplatten zu verteilen und Replikate von diesen anzulegen. Mittels der CRUSH-Map bestimmen Sie, welcher logischen Struktur der Cluster folgt, weche Festplatten also zu welchen Servern gehören, welche Server zu welchen Brandschutzzonen et cetera.

Navigieren Sie zum "Pools"-Eintrag im Seitenmenü links, gelangen Sie zur Einrichtung der Pools in Ceph. Sie sind eine Art logische Aufteilung – jedes binäre Objekt im Ceph-Cluster gehört zu einem Pool. Einerseits fungieren Pools also als eine Art Namensschild, andererseits implementiert Ceph über Pools einen großen Teil seiner internen Replikationslogik. Denn de facto sind es gar nicht die Objekte, die zu einem Pool gehören, sondern die sogenannten Placement Groups. Ein Pool ist also immer eine spezifische Menge von Placement Groups mit einer definierten Anzahl von Objekten. Über das Anlegen, Löschen und Konfigurieren von Pools, das über diesen Punkt im Dashboard möglich ist, bestimmen Sie folglich etliche Details des Clusters. Darunter fällt die insgesamt vorhandene Anzahl an Placement Groups, die sich auf die Performance des Speichers auswirkt, ebenso wie die Anzahl von Replikas pro Pool.

Die folgenden Menüpunkte befassen sich mit den Frontends für Ceph, die der Anwender für den Zugriff benötigt. Unter "Block" sehen Sie eine Übersicht der konfigurierten virtuellen RBD-Blockgeräte, wobei dies eher statistischen Zwecken dient. Denn RBD-Volumes richten Anwender sich im Rahmen ihrer Vorgaben üblicherweise autark ein, ohne dass Sie etwas damit zu tun haben. Ähnliche Einchränkungen gelten für die Menüpunkte "NFS" und "Filesystems", die einen Einblick in die Statistiken rund um Ganesha und CephFS liefern. Auch hier werden Sie in der Regel eher nur zuschauen und nicht anfassen.

Der Punkt "Object Gateway" erlaubt hingegen wieder etwas mehr Interaktion. Hier gelangen Sie zur Konfiguration des "Ceph Object Gateways", vielen Admins wohl noch unter seinem alten Namen "RADOS Object Gateway" oder kurz RGW bekannt. Das Object Gateway kommt je nach Deployment-Szenario mit einer eigenen Benutzerdatenbank daher, auf die Sie über den erwähnten Menüpunkt Einfluss nehmen können.

Über das Dashboard sehen Sie einerseits den aktuellen Status des Clusters und andererseits ermöglicht es eine Vielzahl grundsätzlicher Wartungsaufgaben, ohne sich dabei in die Untiefen der Kommandozeile und des dortigen Werkzeugs "ceph" zu begeben. Weil Ceph in den vergangenen Jahren immer mehr Funktionen bekommen hat, mussten auch dessen Befehle immer umfangreicher werden. Neueinsteiger werden die einzelnen Befehle, die ceph heute alle beherrscht, kaum sinnvoll einordnen oder einsetzen können. Für grundlegendste Aufgaben schafft das Dashboard hier insofern eine dringend benötigte Brücke.

Zwar wünschen sich die meisten Administratoren heute eine Flash-Only-Welt für ihren Speicher, Realität ist das in den meisten Setups bisher allerdings noch nicht. Wer großen Massenspeicher will, wird auch in Ceph-Setups weiterhin viel rotierenden Rost finden – also klassische Festplatten. Diese gehören nach Erfahrung der meisten IT-Profis zu jenen Komponenten mit den häufigsten Ausfällen. Wer einen Ceph-Cluster mit vielen Festplatten betreibt, wird sich früher oder später also damit konfrontiert sehen, dass auch regelmäßig Festplatten kaputt gehen.

Das Dashboard greift Ihnen hier gleich an mehreren Stellen direkt unter die Arme. Zwar funktioniert SMART (Self-Monitoring, Analysis and Reporting Technology) nicht zu 100 Prozent bei allen Geräten – gewisse Trends lassen sich aus der Selbstüberwachung von Platten aber doch ablesen. Die Entwickler des Ceph-Dashboards integrieren SMART-Daten aus diesem Grund in die GUI und zeigen etwaige SMART-Warnungen prominent im Dashboard an. Zur Übersicht gelangen Sie, indem Sie zunächst den jeweiligen Host auswählen, dann die jeweilige Festplatte und im Registerreiter "Device Health" danach auf "SMART" klicken (Bild 2).

Und noch an einer anderen Stelle werden die SMART-Informationen im Dashboard unmittelbar erkennbar – Ceph wertet die Daten im Hintegrund nämlich auch aus. Befindet sich eine Festplatte laut SMART-Information in bedenklichem Zustand, gibt Ceph selbst eine entsprechende Warnung aus. Und diese erscheint prominent auch auf der Startseite des Dashboards beim Abschnitt "Cluster Health". Dieselbe Ausgabe erhalten Sie übrigens auf der Kommandozeile per ceph -w oder ceph health.

In Bezug auf das Dashboard haben die Ceph-Entwickler nicht versucht, das Rad neu zu erfinden. Stattdessen setzen sie auf existierende Funktionalität. ceph-mgr rollt zusammen mit dem Ceph-Dashboard auch mehrere Docker-Container aus, namentlich einen für die Zeitreihendatenbank Prometheus und einen für Grafana.

Ceph selbst hat eine eigene Schnittstelle, die Metrikdaten im Prometheus-kompatiblen Format ausgibt. Diese zapft der vom ceph-mgr ausgerollte Prometheus-Container an – und der ebenfalls ausgerollte Grafana-Container malt auf Basis voreingestellter Werte dann Grafiken aus diesen Metrikdaten. Das Dashboard bindet die Grafiken aus Grafana schließlich per iFrame ein – fertig ist der Lack. Sie sollten jedenfalls nicht in Panik verfallen, wenn Sie auf Ihren Ceph-Hosts plötzlich laufende Docker-Instanzen vorfinden, denn das ist durchaus normal – und mehr noch: Der letzte Stand der Technik ist ja, Ceph selbst ebenfalls in Container-Form auszurollen. Folglich laufen nicht nur Prometheus und Grafana auf den Servern, sondern auch die Container für MONs, OSDs und die anderen Ceph-Dienste.

Der ursprüngliche Fokus des Dashboards lag darauf, verschiedene Details rund um den Ceph-Cluster anzuzeigen. In den vergangenen Jahren hat dieser Fokus sich allerdings verschoben – heute soll das Dashboard auch grundlegende Aufgaben im Hinblick auf die Wartung des Clusters erlauben. Mittlerweile finden sich an verschiedenen Stellen im Dashboard deshalb Hebel und Schalter, mit denen sich der Zustand des Clusters aktiv beeinflussen lässt, wie der folgende Abschnitt zeigt.

Gegeben sei also eine Situation, in der Sie einen Cluster in die Breite skalieren möchten – eine Aufgabe, die Ceph problemlos hinkriegt. Im ersten Schritt müssen Sie (zumindest im Augenblick noch) wieder auf die Kommandozeile, um den Host in die Ceph-eigene Orchestrierung zu integrieren. Auf einem System, auf dem Ceph bereits läuft, genügt dafür der Befehl ceph orch host add <Hostname>, wobei "Hostname" durch den echten Namen des Hosts zu ersetzen ist. Anschließend taucht der Host bereits im Dashboard auf sowie eine Liste der auf ihm gefundenen Storage-Geräte, aus denen ein OSD werden kann. Über den Menüpunkt "OSDs" unter "Cluster" links fügen Sie im nächsten Schritt dann die OSDs zum Cluster hinzu. Hierzu wählen Sie pro Host die Geräte aus, aus denen OSDs werden sollen (Bild 3), und bestätigen die Auswahl. Um den Rest im Hintergrund kümmert sich wieder ceph-mgr.

Anders als beim Anlegen von OSDs müssen Sie beim Erstellen eines Pools in Ceph keine Hardware hinzufügen. Der bestehende Speicher lässt sich jederzeit um einen zusätzlichen Pool erweitern und ebenso können Sie bestehende Pools zu jedem beliebigen Zeitpunkt entfernen. Das geht über das zuvor erwähnte "Pools"-Menü im linken Übersichtsmenü.

Wer sich mit skalierbarer Software beschäftigt, kennt das Problem: Ein Fehler auf einem Host hängt blödestenfalls mit einem Fehler auf einem anderen Host in unmittelbarer Art und Weise zusammen. Um dem roten Faden der Fehlermeldungen zu folgen, durchkämmen Sie die verschiedenen Logdateien auf den unterschiedlichen Systemen Stück für Stück, indem Sie sich von einer Datei zur nächsten hangeln. Das ist mühsam und aufwendig. In großen Umgebungen ist es deshalb heute normal, Logdateien stattdessen zentral zu sammeln, zu indizieren und so durchsuchbar zu machen.

Das Ceph-Dashboard implementiert immerhin einen kleinen Teilbereich dieser Funktionalität. Unter dem Menüpunkt "Cluster Logs" finden Sie die Logmeldungen der diversen Daemons, die am Cluster beteiligt sind, ebenso wie Statusmeldungen von Ceph selbst. Hier können Sie die Suche nach einer Fehlermeldung also effizient betreiben, ohne gleich auf allen Servern Ihres Setups herumzuturnen.

Es ist auch möglich, aus dem Dashboard heraus unmittelbar Alarme zu generieren – etwa für den Admin in Bereitschaft, in dessen Verantwortlichkeit der Zustand eines Ceph-Clusters fällt. Wie schon erwähnt, fußt der größte Teil der Monitoringfunktionalität des Dashboards auf in Containern verpackten Instanzen von Prometheus und Grafana im Hintergrund. Dass Ceph ab Werk eine Schnittstelle hat, um Metrikdaten im Prometheus-Format zur Verfügung zu stellen, kommt da natürlich ausgesprochen gelegen. Was das Dashboard bisher allerdings nicht ausliefert, ist die Prometheus-Komponente, die Alarme generieren und versenden kann – den sogenannten Alertmanager [4]. Mit etwas Handarbeit rüsten Sie diesen allerdings schnell nach.

Weil die Prometheus-Entwickler auch den Alertmanager in Container-Form anbieten, geht das sogar auf denselben Servern, die bereits die Prometheus- und Grafana-Container aus der ceph-mgr-Komponente heraus betreiben. Eine Anleitung liefern die Prometheus-Entwickler unter [5]. Vorgefertigte Alarme für Ceph-Cluster finden Sie zudem unter [6]. Der Rest ist dann quasi nur noch das Zusammensetzen des Puzzles: In die Konfiguration des Alertmanagers schreiben Sie die Alarmierungsziele einerseits. In der Alarmkonfiguration des Alertmanagers hinterlegen Sie andererseits die Alarme, die den Alertmanager zum Handeln veranlassen. Schließlich aktivieren Sie das Erstellen von Alarmen aus dem Dashboard heraus, indem Sie diesem sagen, unter welcher URL es den Alertmanager erreicht:

Der Rest ist dann bloßes Schema F. Direkt aus dem Ceph-Dashboard heraus bekommt der Alertmanager Alarme von Prometheus, die er über die konfigurierten Kanäle weiterleitet. Freilich hat ein solches Konstrukt den Nachteil, dass es eine Insellösung ist – denn es deckt nur Ceph ab. Dafür bekommen Sie hier aber ein fein granuliertes, mächtiges Monitoring- und Alarmierungswerkzeug für Ceph an die Hand, das einen genauen Blick rechtfertigt.

Aus dem einstigen openATTIC-Modul ist eine umfassende Monitoring-Umgebung für Ceph entstanden, die die Entwickler kontinuierlich weiterentwickeln. Wer das Dashboard nur als Klickibunti-Anhängsel verspottet, tut ihm jedenfalls Unrecht: Gerade die Möglichkeit, sich schnell einen optischen Überblick über den Zustand des Clusters zu verschaffen, hilft in Notsituationen viel.

Übrigens: Das Dashboard kann – je nach Produkt, mit dem es ausgerollt wird – seine optische Erscheinung durchaus verändern. Die Entwickler haben auch darauf geachtet, dass sich das Ceph-Dashboard mit einem Theme visuell an die Vorgaben eines Herstellers anpassen lässt. Auf SUSE präsentiert es sich entsprechend grün, während es in der Standardversion eher die klassischen Ceph-Farben nutzt. Die Funktionalität bleibt indes stets dieselbe.