Ceph-19.2.6-Upgrade: PG-Anzahl prüfen, bevor Sie starten

Ceph Squid 19.2.6 ist ein Sicherheitsupdate, das sich zu installieren lohnt, aber einen großen Cluster würde ich nicht wie einen Laptop behandeln, den man erst patcht und später untersucht. Prüfen Sie vor dem Upgrade den Cluster-Zustand, die Placement-Group-Anzahl der Pools, den internen .mgr-Pool, die Client-Kompatibilität und die neuen Anforderungen an die CephX-Key-Rotation, die dieses Sicherheitsrelease mitbringt.

Ich habe die Release-Ankündigung zu Ceph 19.2.6, die Ceph-Manager-Dokumentation und die Community-Warnung abgeglichen, die ausdrücklich die PG-Anzahl auf .mgr vor dem Upgrade größerer Cluster anspricht. Die Diskussion im Upstream-Tracker ist der Grund für die zusätzliche Vorsicht, und die Ceph-Release-Ankündigung ist der Grund, das Sicherheitsupgrade trotzdem nicht auf unbestimmte Zeit zu verschieben.

Warum ist Ceph 19.2.6 ein dringendes Upgrade?

Ceph 19.2.6 ist ein dringender Squid-Hotfix, der vier CVEs in Authentifizierung, RGW und Monitor-Verhalten behebt. Das Ceph-Projekt veröffentlichte Squid 19.2.6 zusammen mit Tentacle 20.2.4 am 19. August 2026 und empfahl Betreibern dringend, zu upgraden.

Die vier gelisteten Probleme sind CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 und CVE-2026-54330. Das erste ist besonders wichtig, weil seine Behebung einen neuen CephX-Schlüsseltyp namens aes256k sowie ein neues Verfahren für Key-Upgrade und Key-Rotation einführt.

Damit ändert sich die Art der Wartung. Neben dem Austausch von Paketen oder Container-Images müssen Sie je nach Deployment-Methode und Clients möglicherweise auch prüfen, ob Daemons und Clients den neuen Schlüsseltyp verstehen, bevor Sie Zugangsdaten rotieren.

Laut Ceph automatisiert cephadm die Rotation von OSD- und MDS-Keys während des Upgrades, während manche Client-Keys weiterhin die Aufmerksamkeit des Betreibers verlangen. Die Kernel-Client-Unterstützung für aes256k beginnt upstream mit Linux-Kernel 7.0, und manche Distributionen haben sie zurückportiert. „Mein Ceph-Cluster läuft auf 19.2.6" und „jeder Client ist bereit für den neuen Key" sind deshalb zwei getrennte Prüfungen.

Wenn dieser Ceph-Cluster unter Proxmox läuft, behandeln Sie die Storage-Ebene als eigenen Änderungsplan. Der Proxmox-Bereich hilft bei der Hypervisor-Seite, doch für die Reihenfolge der Ceph-Sicherheitsmaßnahmen sollten die Ceph-Release-Notes maßgeblich bleiben.

Was ist der .mgr-Pool, und warum sollte ich ihn prüfen?

Der .mgr-Pool ist ein reservierter Ceph-Pool, den der Ceph-Manager-Dienst anlegt, damit Manager-Module ihren dauerhaften Zustand speichern können. Die Ceph-Dokumentation beschreibt ihn ausdrücklich als Pool für Manager-Module, und der führende Punkt kennzeichnet ihn als internen, reservierten Pool-Namen.

Admins übersehen so einen Pool leicht, weil er keine normalen RBD-Images oder CephFS-Nutzerdaten enthält. Verzichtbar ist er deshalb noch lange nicht, und auch Proxmox-Mitarbeiter haben davor gewarnt, interne, mit einem Punkt beginnende Ceph-Pools zu löschen oder leichtfertig zu verändern.

Die aktuelle Community-Warnung rund um Ceph 19.2.6 rät Betreibern größerer Cluster, vor dem Upgrade die Placement-Group-Anzahl auf .mgr zu prüfen. Den genauen Bug-Status und die endgültige Upstream-Behebung verfolgen Sie am besten im verlinkten Ceph-Tracker-Issue. Eine universelle „sichere" PG-Zahl, die Ceph selbst nicht veröffentlicht hat, würde ich mir deshalb nicht ausdenken.

Stattdessen würde ich die Pool-Konfiguration dokumentieren, bevor ich den Cluster anfasse:

ceph health detail
ceph osd lspools
ceph osd pool ls detail
ceph osd pool autoscale-status
ceph -s

Suchen Sie anschließend den .mgr-Eintrag in der Pool-Detailausgabe und notieren Sie dessen pg_num, Autoscale-Modus, Größe und Application-Metadaten. Wenn Ihr Cluster groß ist oder die .mgr-Pool-Konfiguration ungewöhnlich aussieht, vergleichen Sie sie vor dem Fortfahren direkt mit dem Upstream-Issue und den Hinweisen aus der Mailingliste. Das ist allemal besser, als darauf zu wetten, dass eine höhere oder niedrigere PG-Zahl schon passen wird.

Warum ist die Placement-Group-Anzahl bei einem Ceph-Upgrade wichtig?

Placement Groups sind die logische Schicht, über die Ceph Objekte auf OSD-Sets abbildet. Die PG-Anzahl bestimmt also direkt, wie viel Cluster-Zustand die Daemons verfolgen und bewegen müssen. Zu wenige PGs können der Verteilung schaden, zu viele erhöhen den Speicher- und Peering-Overhead.

Modernes Ceph bringt den PG-Autoscaler mit, der manuelle Anpassungen seltener nötig macht. Das heißt aber nicht, dass jeder historisch gewachsene Pool in jedem großen Cluster ideal konfiguriert ist, zumal interne Pools mehrere Generationen von Upgrades und Konfigurationsänderungen überdauern können.

Vor einem Sicherheitsupgrade suche ich vor allem nach Ausnahmen und weniger nach einer mathematisch perfekten PG-Zahl. Trägt ein winziger interner Pool überraschend viele PGs? Ist Autoscaling auf einem Pool deaktiviert, an dessen Erstellung sich niemand erinnert? Gibt es PGs, die schon vor Beginn der Wartung nicht active+clean sind?

Wenn der Cluster die Änderung in einem degradierten oder sich erholenden Zustand beginnt, können Sie hinterher nicht mehr beurteilen, ob das Upgrade das Problem verursacht hat. Meine erste Hürde ist deshalb langweilig: ceph -s sollte einen Zustand zeigen, den ich bereits verstehe.

Wer verstehen will, wie Storage-Design und Virtualisierung zusammenspielen, ist im Storage-Bereich besser aufgehoben, als wenn er versucht, die Pool-Architektur in einem Notfall-Patch-Fenster zu reparieren.

Was sollte ich vor der Installation von Ceph 19.2.6 prüfen?

Eine Preflight-Prüfung für Ceph 19.2.6 sollte belegen, dass Sie den Ausgangszustand kennen und umsteuern können, falls sich ein Node oder Client nach dem Upgrade anders verhält. Ich würde dafür sowohl den Cluster-Zustand als auch den Zustand der Abhängigkeiten festhalten.

Auf meiner Checkliste stünde Folgendes:

• Bestätigen Sie, dass alle Monitore, Manager, OSDs und MDS-Daemons, die laufen sollen, tatsächlich laufen.
• Bestätigen Sie, dass die PG-Zustände verstanden sind und vor dem Start möglichst active+clean lauten.
• Notieren Sie ceph versions, damit Sie genau wissen, welche Daemons auf welchem Release laufen.
• Notieren Sie alle Pool-Details und achten Sie dabei besonders auf .mgr und andere interne Pools.
• Prüfen Sie ceph osd pool autoscale-status auf unerwartete PG-Empfehlungen oder deaktiviertes Autoscaling.
• Prüfen Sie freie Kapazität und Recovery-Spielraum, denn auch dringende Sicherheitsfixes sind kein Grund, einen fast vollen Cluster zu upgraden.
• Lesen Sie das offizielle CephX-Key-Rotationsverfahren für Ceph 19.2.6, bevor der erste Daemon geändert wird.
• Erfassen Sie neben den Cluster-Daemons auch die Kernel-CephFS- und RBD-Clients.
• Wenn Sie RGW Multisite nutzen, befolgen Sie den Release-Hinweis zu rgw_sigv4_insecure, bevor Sie mit dem Upgrade beginnen.
• Sichern Sie kritische Konfiguration und Monitor-Daten mit der für Ihr Deployment passenden Methode.

Die Ausgaben würde ich außerdem im Wartungsticket speichern. Wenn sich nach Node drei etwas ändert, hilft „ich glaube, das sah vorher schon so aus" niemandem, während ein Text-Mitschnitt der Preflight-Prüfung ein billiger Beweis ist.

Was ist besonders an der CephX-Key-Rotation in 19.2.6?

Ceph 19.2.6 führt aes256k als neuen CephX-Schlüsseltyp ein, deshalb müssen Sie die Authentifizierungskompatibilität über Daemons und Clients hinweg im Blick behalten. Ceph bezeichnet dies als die erste Einführung eines neuen CephX-Credential-Schlüsseltyps, und darum enthält das Release ein eigenes Key-Upgrade-Verfahren.

Bei cephadm-Deployments ist die Daemon-Key-Rotation stärker automatisiert. Die Release-Ankündigung weist Betreiber trotzdem darauf hin, dass das Upgrade länger dauert, während OSD- und MDS-Keys rotiert werden. Client-Keys sind ein eigenes Thema.

Gemischte Umgebungen können Sie an dieser Stelle überraschen. Ein moderner Ceph-Cluster bedient womöglich ältere Kernel-Clients, Container, Hypervisoren, Backup-Systeme und Appliances, und der Cluster kann sein Daemon-Upgrade abschließen, während ein Client den Credential-Pfad, den Sie nutzen wollen, noch gar nicht unterstützt.

Im Runbook würde ich daher „Daemon-Software upgraden" von „alle Zugangsdaten sofort rotieren" trennen. Folgen Sie dem offiziellen Verfahren, validieren Sie repräsentative Clients und setzen Sie die Rotation erst fort, wenn feststeht, dass der Client-Bestand bereit ist.

Ändert Proxmox die Upgrade-Entscheidung für Ceph 19.2.6?

Mit Proxmox fallen die Auswirkungen der Wartung stärker auf, weil Ceph während des Patchens womöglich laufende VM-Disks trägt. An Cephs eigenen Sicherheitsvorgaben ändert das nichts. Die wichtigste zusätzliche Sorge ist, genug Storage- und Compute-Redundanz zu behalten, während die Hosts nacheinander gewartet werden.

Wenn Sie zusätzlich ein Upgrade von Proxmox VE 8 auf 9 vorbereiten, packen Sie nicht alle größeren Änderungen in ein einziges Fenster. Das EOL von Proxmox VE 8 drängt zwar auch, ein gestaffelter Plan ist aber trotzdem sicherer. Ich würde zuerst den nötigen Ceph-Pfad abschließen und validieren und erst danach den großen Versionswechsel von Proxmox angehen.

Diese Reihenfolge beschreibe ich in der Proxmox-VE-8-EOL-Upgrade-Anleitung, denn die Fristen hängen zusammen, die Failure Domains sind aber verschieden.

Sollte ich Ceph 19.2.6 wegen der .mgr-Warnung verschieben?

Auf unbestimmte Zeit würde ich Ceph 19.2.6 nicht verschieben. Vier Sicherheitsfixes und eine ausdrückliche Upstream-Empfehlung zum Upgrade wiegen schwerer als die Bequemlichkeit, auf einem älteren Squid-Patch-Level zu bleiben.

Den ersten Produktions-Node würde ich so lange zurückstellen, bis ich .mgr geprüft, das aktuelle Tracker-Issue gelesen, den Cluster-Zustand validiert und den neuen Key-Rotationspfad verstanden habe. Das können Stunden sein oder ein Wartungszyklus, aber es darf keine Ausrede werden, einen exponierten Cluster monatelang ungepatcht zu lassen.

Würde ich heute einen großen Ceph-Cluster betreiben, sähe meine Reihenfolge so aus: den aktuellen Zustand festhalten, jede ungewöhnliche .mgr-PG-Konfiguration untersuchen, das Upgrade zuerst in der risikoärmsten verfügbaren Umgebung testen, den Produktions-Cluster in kontrollierten Wellen patchen und Zugangsdaten erst nach verifizierter Client-Kompatibilität rotieren. Die Dringlichkeit der Sicherheitsfixes darf den Prozess beschleunigen, ohne dass dabei eine dieser Prüfungen wegfällt.