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 ich würde einen großen Cluster 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 CephX-Key-Rotationsanforderungen, die dieses Sicherheitsrelease einführt.

Ich habe die Release-Ankündigung zu Ceph 19.2.6, die Ceph-Manager-Dokumentation und die Community-Warnung abgeglichen, die speziell die PG-Anzahl auf .mgr vor dem Upgrade größerer Cluster anspricht. Die Upstream-Tracker-Diskussion ist der Grund für die zusätzliche Vorsicht, während die Ceph-Release-Ankündigung der Grund ist, das Sicherheitsupgrade 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 den Bereichen 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 bedeutsam, weil die Behebung einen neuen CephX-Schlüsseltyp namens aes256k sowie ein neues Verfahren für Key-Upgrade und -Rotation einführt.

Das verändert die Art der Wartung. Sie ersetzen nicht nur Pakete oder Container-Images. Je nach Deployment-Methode und Clients müssen Sie 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 Aufmerksamkeit vom Betreiber erfordern. Die Kernel-Client-Unterstützung für aes256k beginnt upstream in Linux-Kernel 7.0, mit Backports in manchen Distributionen. Das bedeutet: „Mein Ceph-Cluster läuft auf 19.2.6" und „jeder Client ist bereit für den neuen Key" sind zwei getrennte Prüfungen.

Wenn dieser Ceph-Cluster unter Proxmox läuft, behandeln Sie die Storage-Ebene als eigenen Änderungsplan. Der Proxmox-Bereich ist für die Hypervisor-Seite nützlich, aber die Ceph-Release-Notes sollten für die Reihenfolge der Ceph-Sicherheitsmaßnahmen 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 Manager-Modul-Pool, und der führende Punkt markiert ihn als internen, reservierten Pool-Namen.

Das ist die Art von Pool, die Admins leicht übersehen, weil er keine normalen RBD-Images oder CephFS-Nutzerdaten enthält. Das macht ihn nicht verzichtbar. 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. Das verlinkte Ceph-Tracker-Issue bleibt die richtige Stelle, um den genauen Bug-Status und die endgültige Upstream-Behebung zu verfolgen, daher würde ich keine universelle „sichere" PG-Zahl erfinden, die Ceph selbst nicht veröffentlicht hat.

Was ich tun würde, ist die Pool-Konfiguration zu dokumentieren, bevor ich den Cluster anfasse:

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

Identifizieren 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 eine bessere Reaktion, als zu raten, dass eine höhere oder niedrigere PG-Zahl schon richtig sein wird.

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

Placement Groups sind die logische Schicht, mit der Ceph Objekte auf OSD-Sets abbildet, daher wirkt sich die PG-Anzahl direkt darauf aus, wie viel Cluster-Zustand die Daemons verfolgen und bewegen müssen. Zu wenige PGs können der Verteilung schaden, während zu viele PGs den Speicher- und Peering-Overhead erhöhen.

Modernes Ceph enthält den PG-Autoscaler, um den Umfang manueller Anpassungen zu reduzieren, aber Autoscaling bedeutet nicht, dass jeder historisch gewachsene Pool in jedem großen Cluster eine ideale Konfiguration hat. Interne Pools können auch mehrere Generationen von Upgrades und Konfigurationsänderungen überdauern.

Vor einem Sicherheitsupgrade interessiert mich weniger, eine mathematisch perfekte PG-Zahl zu erreichen, sondern vor allem, Ausnahmen zu erkennen. 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, verlieren Sie die Möglichkeit zu beurteilen, ob das Upgrade das Problem verursacht hat. Deshalb ist meine erste Hürde langweilig: ceph -s sollte einen Zustand zeigen, den ich bereits verstehe.

Für eine umfassendere Erklärung, wie Storage-Design-Entscheidungen mit Virtualisierung zusammenspielen, ist der Storage-Bereich nützlicher, als zu versuchen, die Pool-Architektur innerhalb eines Notfall-Patch-Fensters 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 den Kurs ändern können, falls sich ein Node oder Client nach dem Upgrade anders verhält. Ich würde sowohl den Cluster-Zustand als auch den Zustand der Abhängigkeiten festhalten.

Meine Checkliste würde Folgendes umfassen:

• 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 vorzugsweise active+clean lauten.
• Notieren Sie ceph versions, damit Sie genau wissen, welche Daemons auf welchem Release laufen.
• Notieren Sie alle Pool-Details, mit besonderem Augenmerk 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. Sicherheitsdringlichkeit ist kein Grund, einen bereits 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 Kernel-CephFS- und RBD-Clients, nicht nur die Cluster-Daemons.
• 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.

Ich würde außerdem die Ausgaben im Wartungsticket speichern. Wenn sich nach Node drei etwas ändert, ist „ich glaube, das sah vorher schon so aus" nutzlos. Ein Text-Mitschnitt der Preflight-Prüfung ist billig zu beschaffender Beweis.

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, daher muss die Authentifizierungskompatibilität über Daemons und Clients hinweg berücksichtigt werden. Ceph bezeichnet dies als die erste Einführung eines neuen CephX-Credential-Schlüsseltyps, weshalb das Release ein spezielles Key-Upgrade-Verfahren enthält.

Bei cephadm-Deployments ist die Daemon-Key-Rotation stärker automatisiert, aber die Release-Ankündigung weist Betreiber trotzdem darauf hin, ein längeres Upgrade zu erwarten, während OSD- und MDS-Keys rotiert werden. Client-Keys bleiben ein separates Thema.

Hier können gemischte Umgebungen Sie überraschen. Ein moderner Ceph-Cluster kann ältere Kernel-Clients, Container, Hypervisoren, Backup-Systeme und Appliances bedienen. Der Cluster kann sein Daemon-Upgrade abschließen, während ein Client noch keine Unterstützung für den Credential-Pfad hat, den Sie nutzen wollen.

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

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

Proxmox macht die Auswirkungen der Wartung sichtbarer, weil Ceph während des Patchens möglicherweise laufende VM-Disks trägt, aber das ändert nichts daran, dass Sie Cephs eigenen Sicherheitsvorgaben folgen müssen. Die wichtigste zusätzliche Sorge ist, genug Storage- und Compute-Redundanz zu erhalten, während Hosts die Wartung durchlaufen.

Wenn Sie zusätzlich ein Upgrade von Proxmox VE 8 auf 9 vorbereiten, vermeiden Sie es, alle größeren Änderungen in ein einziges Fenster zu packen. Auch das EOL von Proxmox VE 8 drängt, aber ein gestaffelter Plan ist trotzdem sicherer. Ich würde zuerst den erforderlichen Ceph-Pfad abschließen und validieren, bevor ich zum großen Versionswechsel von Proxmox übergehe.

Diese Reihenfolge behandle ich in der Proxmox-VE-8-EOL-Upgrade-Anleitung, da die Fristen zwar zusammenhängen, die Failure Domains aber unterschiedlich sind.

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

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

Ich würde den ersten Produktions-Node lange genug verschieben, um .mgr zu prüfen, das aktuelle Tracker-Issue zu lesen, den Cluster-Zustand zu validieren und den neuen Key-Rotationspfad zu verstehen. Das könnten Stunden sein oder ein Wartungszyklus. Es sollte nicht zur Ausrede werden, einen exponierten Cluster monatelang ungepatcht zu lassen.

Würde ich heute einen großen Ceph-Cluster betreiben, wäre meine Reihenfolge einfach: 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 mit verifizierter Client-Kompatibilität rotieren. Sicherheitsdringlichkeit sollte den Prozess schneller machen. Sie sollte ihn nicht nachlässig machen.