© stokkete / 123RF.com

Ceph gilt als Klassenprimus unter den quelloffenen Objektspeichern. Wie leicht sich neue Versionen einspielen lassen, hängt davon ab, ob die vorhandene Installation bereits die Ceph-Orchestrierung nutzt. Falls nicht, steht einige Arbeit an.

Ceph gilt als typische Open-Source-Erfolgsgeschichte. Seine Anfänge liegen in einer Doktorarbeit von Sage Weil, der bei der amerikanischen Umweltschutzbehörde EPA beschäftigt war. Es gilt heute als erste Wahl, wenn man einen massiv skalierbaren Objektspeicher für vielfältige Einsatzszenarien benötigt. Zwar hat das Produkt mittlerweile mehrmals den Besitzer gewechselt, weil erst der ursprüngliche Hersteller Inktank Storage in Red Hat aufging und sich dann IBM Red Hat einverleibte. Noch immer aber steht Ceph quelloffen und kostenlos zur Verfügung [1]. An der Vielseitigkeit der Lösung hat sich ebenso wenig geändert: Nach wie vor bietet Ceph Frontends für virtuelle Blockspeicherlaufwerke (RADOS Block Device, RBD), für das Ablegen von Daten per Amazon-S3-Protokoll (RADOS Gateway, RGW) sowie ein POSIX-kompatibles Dateisystem namens CephFS.

Dieser Tage allerdings droht vielen eigentlich glücklichen Ceph-Administratoren Ungemach: Einerseits läuft 2025 der offizielle Support für Ubuntu 20.04 aus. Die Canonical-Distribution gilt als äußerst beliebte Grundlage für Ceph-Cluster, weil sie native Pakete dafür bereithält und ein einmal auf Ubuntu aufgesetzter Ceph-Cluster im Regelfall nur wenig Wartungsaufwand verursacht. Andererseits endet absehbar auch die Herstellerunterstützung für Ceph 17 alias “Quincy”. Diese Version war bereits 2022 erschienen und sollte eigentlich längst aus dem offiziellen Support gefallen sein. Weil es aber noch immer vielerorts zum Einsatz kommt, hat Red Hat die Unterstützung dafür schon mehrmals verlängert.

Darauf verlassen, dass das ewig so weitergeht, sollten Administratoren sich freilich nicht. Gerade weil Ceph 17 nahezu gleichzeitig mit Ubuntu 22.04 herauskam – einem Release, das vielen damals noch als zu frisch erschien – ist das Gespann aus Ceph 17 und Ubuntu 20.04 bis heute regelmäßig anzutreffen. In der Folge steht nun häufig der doppelte Wartungsaufwand an, um die Installation auf Ubuntu 24.04 und Ceph 19.2 zu heben.

Wie kompliziert das wird, hängt primär von einem Umstand ab: Wer 2022 bereits auf die Orchestrierung mit Ceph setzte und seinen Cluster mittels Cephadm ausrollte, hat heute deutlich weniger Arbeit als jene, die auch 2022 noch auf die Ceph-Pakete gesetzt haben. Bis heute lässt sich Ceph durchaus händisch ohne Cephadm und den Ceph-Manager ausrollen, auch wenn das keine gute Idee ist. Fehlt der Manager in einem Setup, fehlen auch dessen automatische Update-Künste. Schließlich ist der Ceph-Manager nicht weniger als ein in die Lösung integriertes Werkzeug für die Orchestrierung eines ganzen Ceph-Clusters.

Dieser Artikel beschreibt, wie ein Update von Ceph 17 ohne Orchestrierung auf eine Version mit Orchestrierung unter Ubuntu 24.04 aussehen kann. Dabei handelt es sich aus heutiger Sicht um so etwas wie das Worst-Case-Szenario, also den größtmöglich vorstellbaren Aufwand. Hier gilt aber die Devise “Keine Panik!”, denn die Ceph-Entwickler sehen einen Prozess vor, um einen Cluster auf Paketbasis zunächst kontrolliert in die eingebaute Orchestrierung zu überführen. Das Update des darunterliegenden Betriebssystems erscheint danach beinahe schon trivial, denn wenn der Ceph-Manager einmal die Kontrolle über einen Cluster übernommen hat, lassen sich mit seiner Hilfe sämtliche Dienste leicht ausrollen oder ersetzen und steuern.

Der Plan

Gegeben seien also ein Ceph-Cluster aus drei Knoten mit Ubuntu 20.04 als Betriebssystem sowie Ceph 17.2.8 ohne aktivierte Orchestrierung. Das Szenario impliziert, dass auf jedem betroffenen Knoten ein Ceph-Monitor (MON-Server) von RADOS sowie mindestens ein Object Storage Daemon (OSD) läuft, der seine lokalen Speichermedien, zum Beispiel Festplatten, in den Ceph-Cluster exportiert [2].

Vor Beginn der Umbauarbeiten sollte der Administrator sicherstellen, dass alle Komponenten auf dem aktuellsten Versionsstand sind. Es schadet auch nicht, in Ubuntu 20.04 den HWE-Kernel (Hardware Enablement Kernel [3]) zu installieren (Abbildung 1). Das Beispiel geht ferner davon aus, dass der Ceph-Cluster sich in einem ausgeglichenen Zustand ohne laufende Recovery-Arbeiten befindet und dass die Ausgabe von »ceph health detail« ein »HEALTH_OK« ist.

Abbildung 1: Wer Ceph in die Orchestrierung übernehmen und von Version 17 auf 19 aktualisieren möchte, sollte in Ubuntu 20.04 den HWE-Kernel ausrollen – der ist nicht ganz so alt wie die originale Variante.

Der nun folgende Vorgang besteht aus mehreren Teilen: Zunächst aktiviert der Administrator die Ceph-Orchestrierung und übernimmt dafür die laufenden Dienste samt und sonders. Damit einher geht die Umstellung von lokal installierten Paketen auf Container. Sobald die abgeschlossen ist, lässt sich mittels »ceph orch« ein rollendes Upgrade der einzelnen Ceph-Komponenten von Ceph 17 auf Ceph 18 und im weiteren Verlauf auf Ceph 19 bewerkstelligen.

Sobald Ceph 19 läuft, kann schließlich das Update der einzelnen Knoten der Installation erfolgen. Dabei steht es dem Admin frei, Ubuntu entweder zu aktualisieren oder die betroffenen Systeme gleich mit Ubuntu 24.04 neu zu installieren. Wer sich für das rollende Upgrade entscheidet, sollte aber auf den Systemen eventuell noch vorhandene Ceph-Pakete im Nachgang deinstallieren.

Aller Anfang

Wie sich ein bestehender Cluster in den Ceph-Manager und Cephadm aufnehmen lässt, beschreiben die Ceph-Entwickler selbst in ihrer Dokumentation ausführlich [4]. Der ausführende Administrator sollte sich vergewissern, dass die Version der Doku, die er sich ansieht, auch tatsächlich zu seiner Ceph-Version passt – im konkreten Fall also zu Ceph “Quincy” alias Ceph 17.2.8. Spätere Versionen bieten zwar mehr Möglichkeiten; wer aber auf Ubuntu 20.04 mit Ceph 17 festhängt, ist auf die Features des Cephadm beschränkt, das Red Hat für ebendiese Versionskombination zur Verfügung stellt.

Abbildung 2: Cephadm ist in Ubuntu 20.04 mit Ceph 17 verfügbar. Obwohl nicht sonderlich neu, funktioniert das Werkzeug hinreichend gut für das Aktivieren der Orchestrierung.

Den ersten Schritt auf dem Weg zum orchestrierten Ceph-Cluster stellt folglich die Installation des Cephadm-Pakets an sich dar (Abbildung 2). Das muss auf allen drei Systemen geschehen. Parallel dazu installiert der Administrator die Community-Edition von Docker auf allen drei Systemen. Wie das im Detail funktioniert, verrät die Docker-Dokumentation [5], inklusive aller nötigen Befehle.

Sobald sich »cephadm« und »docker ls« auf der Kommandozeile ausführen lassen und plausible Ausgaben liefern, beginnt die eigentliche Migration. Aus Sicht des Administrators empfiehlt es sich, zunächst mittels »ceph osd set noout« zu unterbinden, dass RADOS automatisch OSDs aus dem Cluster entfernt, die länger als zehn Minuten nicht online waren. Das kann zum Beispiel beim Reboot von Systemen durchaus vorkommen, würde bei einem kontrollierten Update aber vor allem zu viel unsinnigem Herumschaufeln von Daten führen.

Nach der Installation von Cephadm sollte der Administrator zudem sicherstellen, dass er die UIDs und GIDs des Nutzers und der Gruppe ceph auf den Wert 167 ändert, denn diesen Wert erwarten die in den Containern laufenden Dienste. Hat der Ceph-Nutzer eine andere User-ID, scheitert schlimmstenfalls die Migration zu Containern wegen verwehrter Zugriffe. Das Ändern der Werte bedingt das Anhalten aller Dienste auf dem Host, die den Benutzer oder die Gruppe ceph nutzen.

Der Admin stoppt also auf einem System nacheinander zumindest die MON-Dienste, alle OSD-Dienste sowie eventuell weitere laufende Dienste wie MDS-Server für CephFS. Dann ändern die Befehle »usermod -u 167 ceph« sowie »groupmod -g 167 ceph« die GID/UID. Ein Reboot im Anschluss sollte dazu führen, dass alle Ceph-Dienste automatisch wieder hochkommen und dem Cluster beitreten, dann aber jeweils mit der richtigen UID und GID. Der Cluster ist grundsätzlich bereit für das Update, sobald dieser Schritt auf allen Systemen absolviert wurde.

Los geht’s

Am Anfang der Migration jedes Hosts steht der Cephadm-Befehl »prepare-host« (Listing 1, erste Zeile). Er prüft, ob alle Voraussetzungen für die Aufnahme in den Ceph-Manager gegeben sind, und beschwert sich, falls er auf Unstimmigkeiten trifft. Obendrein empfiehlt es sich, bereits das Ziel-Image für die Konvertierung zu Containern (Zeile 2) auf allen drei Systemen vorzubereiten (Abbildung 3). Dann stößt der Administrator die Konvertierung einer bestehenden »ceph.conf«-Datei für den Ceph-Manager an (Zeile 3). Ein Dump der Konfiguration (Zeile 4) zeigt im Anschluss jene Werte, die Cephadm zuvor auf den Systemen gefunden und in die Ceph-interne Notation umgewandelt hat.

Abbildung 3: Schon vor der Übernahme der Dienste in die Ceph-Orchestrierung organisiert der Admin auf den betroffenen Systemen das Ceph-Abbild. Das spart später Zeit.

# cephadm prepare-host
# docker pull quay.io/ceph/ceph:v17.2.8
# ceph config assimilate-conf -i /etc/ceph/ceph.conf
# ceph config dump
# [...]
# cephadm --image quay.io/ceph/ceph:v17.2.8 adopt --style legacy --name mon.ceph{01,02,03}
# cephadm --image quay.io/ceph/ceph:v17.2.8 adopt --style legacy --name mgr.ceph{01,02,03}
#
 [...]
# ceph mgr module enable cephadm
# ceph orch set backend cephadm
# ceph cephadm generate-key
# ceph cephadm get-pub-key > ~/ceph.pub
# ssh-copy-id -f -i ~/ceph.pub root@ceph{01,02,03}
# ceph orch host add ceph01

Dann steht bereits die Umstellung der MON-Server auf Orchestrierung mit Ceph-Manager an. Im Beispiel heißen die drei Server einfach »ceph01«, »ceph02« und »ceph03«. Weil man beim Kommando zur Adoption auch noch das Image-Tag angeben muss – Cephadm würde anderenfalls das neueste verfügbare Image nutzen und so ein Sprung-Update auf Ceph 19.2 ausführen – lautet das gesamte Kommando so wie in der sechsten Zeile von Listing 1. Während des Vorgangs zeigt die Ausgabe von »cephadm ls«, ob die Adoption eines einzelnen Diensts funktioniert hat.

Sobald ein Dienst in den Manager übernommen ist, wiederholt der Administrator das Prozedere für die verbliebenen MONs alter Installationsart. Danach gilt es, die auch in einem Cluster ohne aktive Orchestrierung laufenden Ceph-Manager-Dienste zu übernehmen. Das geschieht für alle drei Server analog zur Adoption der MONs (Listing 1, Zeile 7). Erneut lässt sich der Fortschritt mittels »cephadm ls« messen. Sind alle Systeme konvertiert, sollten hier drei aktive MON-Server und drei aktive MGR-Server in der Liste auftauchen.

Darauf folgt das Aktivieren der Orchestrierung (Listing 1, Zeile 9 und 10). Weil der Ceph-Manager im Nachgang mittels SSH zwischen den Systemen kommuniziert, muss der Administrator darauf achten, dass der interne SSH-Schlüssel des Ceph-Managers angelegt und sein öffentlicher Teil in der »authorized_hosts«-Datei aller Systeme für den Systemadministrator root hinterlegt ist (Zeile 11 und 12). Ein »ssh-copy-id« auf alle drei Systeme (Zeile 13) sorgt dafür, dass der SSH-Login ohne Passwort funktioniert.

Genau das ist die Voraussetzung dafür, dass der Ceph-Manager die Hoheit über ein System weitgehend übernehmen kann. Mittels »ceph orch« weist der Administrator den Manager dann an, eben das zu tun (Zeile 14). Achtung: Auch wenn dieser Befehl auf dem Host »ceph01« aufgerufen wird, ist er doch für alle drei Hosts des Clusters anzuwenden. Der Ceph-Manager übernimmt nämlich den Host »ceph01« auch dann nicht automatisch in die Orchestrierung, wenn der Administrator alle zentralen Befehle von ihm aus absendet. Stehen alle Systeme unter der Obhut »ceph orch«, lässt sich mittels »ceph orch ps« prüfen, ob die Kommunikation per SSH funktioniert und ob der Ceph-Manager die laufenden Dienste bereits erkennt.

Dann folgt die eigentliche Mammut-Aufgabe: Die am zahlreichsten in einem Ceph-Cluster vorzufindende Dienstart ist üblicherweise der Object Storage Daemon (OSD), von dem es pro System oft 12 bis 20 Instanzen gibt. Jede einzelne davon übernimmt der Administrator analog zu den Cephadm-Adopt-Befehlen in den Cluster. Anstelle von »mon.ceph01« oder »mgr.ceph01« muss er beim Dienstnamen dann aber den des OSDs angeben. Ein vollständiges Kommando lautet entsprechend »cephadm adopt –style legacy –name osd.1«. Wer in seinem Cluster 48 OSDs hat, führt den Befehl entsprechend 48 mal aus – einmal für jeden einzelnen OSD – oder baut sich ein Shell-Konstrukt mit einer For-Schleife auf der Kommandozeile.

Zumindest den ersten OSD eines Clusters sollte der Administrator aber einzeln in die Orchestrierung aufnehmen: Geht hier etwas schief, hat er die Gelegenheit, einzugreifen. Geht er stattdessen gleich mit der Brechstange ans Werk und nutzt von Anfang an eine Schleife, scheitern schlimmstenfalls alle OSDs der Installation, und der Cluster ist danach offline.

Durchaus bemerkenswert übrigens: Die gesamte Umstellung des Ceph-Clusters auf Orchestrierung erfolgt ohne Unterbrechung des Diensts und mit minimalen Auswirkungen auf die Clients. Hier kommt Ceph seine implizit redundante Architektur zugute, die dafür sorgt, dass Clients beim Ausfall von MONs oder OSDs automatisch nach Alternativen suchen, statt eine Fehlermeldung anzuzeigen.

Weiter geht’s

Sind alle OSDs erfolgreich in die Orchestrierung aufgenommen, was sich auf den einzelnen Systemen mittels »docker ps« gut nachvollziehen lässt, stehen im Grunde bloß noch Aufräumarbeiten an. Vorhandene Instanzen des Ceph-Metadatenservers etwa müssen ebenfalls in die Orchestrierung aufgenommen werden. Dabei kommt aber nicht mehr der Adopt-Befehl von Cephadm zum Einsatz. Stattdessen rollt der Administrator parallel zu den noch immer laufenden Instanzen der Dienste ohne Container mittels »ceph orch apply mds Name« weitere Instanzen der Dienste aus.

Wer seine Metadatenserver nach einem bestimmten System verteilt hat oder eine bestimmte Anzahl davon benötigt, erweitert das Kommando noch um den Parameter »–placement«, also etwa »–placement=”3 ceph01 ceph02 ceph03″«, um drei Instanzen statt der üblichen zwei auszurollen. Das Kommando »ceph fs ls« sollte in unserem Beispiel im Anschluss sechs Metadatenserver anzeigen. Die alten Instanzen ohne Orchestrierung lassen sich dann mittels »systemctl stop ceph-mds.target« und »rm -rf /var/lib/ceph/mds/ceph-*« auf den betroffenen Systemen beseitigen.

Ähnlich geht der Administrator beim RADOS-Gateway vor. Auch dort sorgt das Kommando »ceph orch apply rgw Service-ID« für das automatische Deployment der RGW-Instanzen aus dem Ceph-Manager heraus. Wer für das RADOS-Gateway ein bestimmtes Placement wünscht oder beispielsweise SSL nutzen möchte, erstellt idealerweise eine »rgw.yml« mit allen nötigen Parametern und spielt sie im Nachgang mittels »ceph orch apply -i rgw.yml« in den Cluster ein. Details zu solch einer Service-Definition und den möglichen Parametern finden sich in der Ceph-Dokumentation [6].

Nach erfolgreichem Update sollte der Administrator auch hinsichtlich des RADOS Gateway im Nachgang noch aufräumen. Das ist mittels der Kommandos »systemctl stop ceph-rgw.target« und »rm -rf /var/lib/ceph/radosgw/ceph-*« auf den Systemen, auf denen zuvor ein RADOS Gateway lief, schnell erledigt. Wenn »ceph health detail« schließlich wieder »HEALTH_OK« anzeigt, ist die Umstellung auf die Orchestrierung erfolgreich abgeschlossen.

Update? Kinderleicht!

Warum die beschriebene Reihenfolge beim Vorgehen Sinn ergibt, zeigt sich beim nun anstehenden Update zuerst auf Ceph 18 und dann auf Ceph 19. Hat der Ceph-Manager erst einmal das Regiment übernommen, wickelt er die rollenden Updates aller betroffenen Komponenten automatisch und ohne weiteres Eingreifen des Administrators ab.

Gerade bei Updates von älteren Ceph-Versionen kann es aber doch vorkommen, dass es mal klemmt. Aus diesem Grund empfiehlt es sich, vor einem anstehenden Upgrade das Logging der einzelnen Ceph-Dienste in lokale Protokolldateien zu aktivieren. Üblicherweise loggen die Ceph-Dienste stattdessen nach STDERR, sodass die Meldungen schließlich im Systemjournal des beheimatenden Hosts landen. Geht beim Upgrade etwas schief und ist davon insbesondere der Manager selbst betroffen, also »ceph-mgr«, lassen sich Fehler mit lokalen Logs deutlich schneller lokalisieren. Die Kommandos aus den ersten zwei Zeilen von Listing 2 nehmen die nötige Einstellung vor. Danach finden sich auf jedem Host in »/var/lib/ceph-FSID/« die Log-Dateien aller Ceph-Dienste.

# ceph config set global log_to_file true
# ceph config set global mon_cluster_log_to_file true
# docker pull quay.io/ceph/ceph:v18.2.4
# ceph orch upgrade start --ceph-version 18.2.4

Für das anstehende Update auf Ceph 18 empfiehlt es sich zunächst, einmal mehr das nötige Ceph-Containerabbild auf allen betroffenen Systemen zu hinterlegen (Listing 2, Zeile 3) und dann das Update clusterweit anzustoßen (Zeile 4). Das Prozedere folgt erneut einer bestimmten Reihenfolge: Zunächst aktualisiert Ceph-Manager sich selbst, dann die laufenden MONs, dann alle OSDs und schließlich die RGW-Instanzen sowie die Metadatenserver für CephFS. Mittels »ceph orch upgrade status« lässt sich der Status des Updates prüfen.

Kommt hier nach dem Update des Ceph-Managers eine Fehlermeldung zurück, liegt das vermutlich daran, dass in der Konfigurationsdatenbank von Ceph ein Wert hinterlegt ist, der in der neueren Version nicht mehr funktioniert. Weil Ceph intern auch JSON-Arrays als Konfigurationsparameter abspeichert, genügt es, wenn sich die Definition eines solchen Arrays geändert hat und der Ceph-Manager deshalb das Array nicht mehr korrekt auswerten kann. In einem solchen Fall hinterlässt der Manager aber beim Startversuch eine ausführliche Fehlermeldung in Form eines Python-Stacktraces in seinem eigenen Log (Abbildung 4).

Abbildung 4: Es kommt vor, dass die Ceph-Konfigurationsdatenbank alte Einträge enthält, die mit einem neueren Ceph nicht mehr funktionieren. Die gilt es dann händisch zu entfernen, bevor der Manager wieder seinen Dienst antritt.

Die Meldung enthält auch den konkreten Konfigurationsschlüssel, an dessen Inhalt der Ceph-Manager sich stört. Ist der lokalisiert, lässt er sich mittels »ceph config-key rm Wertename« unschädlich machen. Im Nachgang sollte der Manager wieder regulär starten, und das Update schreitet voran. Dabei geht der Manager übrigens stets auf Basis des einzelnen Diensts vor. Er aktualisiert also weder alle MONs gleichzeitig noch alle OSDs. Hier achten die Ceph-Entwickler also auf Redundanz und darauf, dass keine Downtime anfällt.

Und nochmal!

Nach dem Abschluss des Updates auf Ceph 18 wiederholt der Administrator das Prozedere am besten noch ein letztes Mal, um auf Ceph 19.2 und damit die aktuellste verfügbare Ceph-Version zu kommen. Dazu holt er mittels »docker pull quay.io/ceph/ceph:v19« zunächst das aktuellste Abbild von Ceph 19.2 auf alle drei Systeme und stößt dann mittels »ceph orch upgrade start –ceph-version 19« den Update-Prozess an.

Dann heißt es warten. Unter Umständen kann es sinnvoll sein, während des Update-Vorgangs in einem Terminal den Befehl »ceph -w« mitlaufen zu lassen. So erhält man einen Überblick über die absolvierten Arbeitsschritte. Wer dem Cluster im Vorfeld zudem mittels »ceph osd set noout« das automatische Deaktivieren von OSDs vorgegeben hat, sollte das nach dem Upgrade noch mittels »ceph osd unset noout« rückgängig machen.

Weitere Überlegungen

Unter normalen Umständen lässt sich selbst eine größere Ceph-Installation ohne Downtime problemlos innerhalb eines Tags erst auf die in Ceph integrierte Orchestrierung umstellen und dann auf Version 19 aktualisieren. Auftretende Fehler sind in der Regel schnell zu beheben, sodass selbst kleinere Verzögerungen keine größeren Probleme nach sich ziehen.

Sobald Ceph auf Version 19 angekommen ist, geht das anschließende Update von Ubuntu 20.04 auf 24.04 (wie im Beispiel) leicht von der Hand. Hier ist sowohl ein Update mittels »do-release-upgrade« möglich als auch die Reinstallation der Systeme. Letzteres ist der sauberste Weg, weil er auch eventuell noch vorhandene Altlasten von Ceph beseitigt. Er bedingt jedoch einige zusätzliche Schritte, zumindest dann, wenn man sich als Admin die Arbeit etwas erleichtern will.

Grundsätzlich wäre es mittels »ceph orch« freilich auch möglich, zunächst alle laufenden Dienste vom bestehenden Cluster-Knoten zu entfernen, ihn dann neu zu installieren und die Dienste im Nachgang erneut zu aktivieren. Dabei geht aber der Inhalt aller OSDs auf dem Knoten verloren, was später zu umfassenden Recovery-Arbeiten und einer tiefgreifenden internen Reorganisation der gesamten RADOS-Daten führt. Stattdessen ist es sinnvoller, dem Cluster wieder mittels »ceph osd set noout« das automatische Entfernen von OSDs aus der Replikation zu untersagen und einige Dateienzu sichern, die zu Ceph gehören. Dann startet man einfach die Neuinstallation des Knotens.

Vor der Neuinstallation hilft das Skript aus Listing 3, alle nötigen Dateien zu sichern. Den resultierenden Tarball kopiert der Admin vor der neuerlichen Installation des Betriebssystems an einen sicheren Ort. Danach spielt er ihn zurück, entpackt ihn mittels »tar xvf« und wechselt in das dabei entstandene Verzeichnis. Von dort spielt er die Dateien mittels »find | cpio -padmuv /« zurück.

cd /root
(getent group ceph; getent passwd ceph) > /root/ceph-user.txt
(pvs; lvs -o lv_tags) > /root/lvm-config.txt
pushd /
tar -cWv -f /root/ceph-$(hostname -s).backup.tar \
  ./etc/ceph/*.keyring \
  ./etc/logrotate.d/ceph-* \
  ./etc/systemd/system/ceph-* \
  ./etc/systemd/system/ceph.target \
  ./etc/systemd/system/ceph.target.wants/ceph-* \
  ./etc/systemd/system/multi-user.target.wants/ceph-*.target \
  ./etc/systemd/system/multi-user.target.wants/ceph.target \
  ./root/ceph-user.txt \
  ./root/lvm-config.txt \
  ./var/lib/ceph/????????-* \
  ./var/log/ceph
popd

Ein abschließender Reboot sorgt dafür, dass die Dienste automatisch starten. Zuvor sollte der Administrator aber auch noch sicherstellen, dass Benutzer und Gruppe ceph existieren und die UID und GID 167 haben. Nach dem Reboot ist zudem sicherzustellen, dass der öffentliche SSH-Schlüssel von Cephadm auf dem frisch installierten Host hinterlegt ist: Dann übernimmt der Ceph-Manager das System nahtlos wieder in seine Obhut.

Zum Schluss ist noch eine Anmerkung wichtig: Damit Cephadm und Ceph auf Ubuntu 24.04 funktionieren, gilt es, Apparmor entweder ganz abzuschalten oder zumindest die Profile für MongoDB Compass, Nvidia und Plasmashell zu deaktivieren: Ceph 19.2.0 hat einen Bug, der über Apparmor-Regeln im Parser stolpert, wenn sie Leer- oder Sonderzeichen im Namen haben (Abbildung 5)

Abbildung 5: Ceph 19.2.0 kommt mit einigen Apparmor-Profilen unter Ubuntu 24.04 nicht klar. Daher gilt es, die Profile für MongoDB Compass, die Plasmashell und das Nvidia-Kernel-Modul zu deaktivieren.

Fazit

Gewusst wie – das gilt auch und gerade beim Ceph-Update: Selbst Admins älterer Setups brauchen vor dem nahenden Ende des Supports für Ceph 17 und Ubuntu 20.04 keine Panik zu haben. Das Ceph 17 beiliegende Cephadm erledigt problemlos die Umstellung auf die in Ceph integrierte Orchestrierung, und die kümmert sich im Anschluss um das Update. (jcb/jlu)