Ceph Squid auf Tentacle: das Upgrade im laufenden Proxmox-Cluster

/01Squid und Tentacle: worum es bei diesem Upgrade geht

Das Upgrade von Ceph 19.2 „Squid" auf 20.2 „Tentacle" ist ein Wechsel der Hauptversion des Speichersystems unter einem hyperkonvergenten Proxmox-Cluster — bei laufenden VMs, ohne Neuinstallation. Es besteht aus drei Teilen: neue Paketquelle, neue Pakete auf allen Knoten, dann der geordnete Neustart aller Ceph-Dienste, damit sie die neuen Programmdateien tatsächlich laden.

Was dieser Artikel nicht ist: keine Anleitung für das Upgrade von Proxmox VE 8 auf 9. Das ist die Vorstufe, und sie ist im Beitrag zum Support-Ende von Proxmox VE 8 beschrieben, inklusive der Kurzfassung der Ceph-Befehle. Hier geht es um die Prüfungen zwischen den Befehlen, den Rückfallpunkt und das seit 28.09.2026 dokumentierte bekannte Problem. Ebenfalls nicht Thema: Ceph-Cluster, die außerhalb von Proxmox mit cephadm oder Rook betrieben werden — dort orchestriert das Werkzeug den Ablauf selbst.

Für wen der Text irrelevant ist: Wer Proxmox mit einem SAN und Shared LVM betreibt, hat kein Ceph und nichts zu tun. Wer Ceph nur als externen Speicher eines fremden Clusters anbindet, aktualisiert lediglich die Client-Pakete. Die Abwägung zwischen beiden Architekturen steht in SAN oder Ceph für Proxmox im Mittelstand.

/02Wie lange wird Ceph Squid noch gepflegt?

Die Release-Übersicht des Ceph-Projekts führt für Squid ein geschätztes Lebensende am 31.10.2026, für Tentacle den 01.06.2027 (abgerufen am 22.10.2026). Squid erschien am 26.09.2024, Tentacle am 18.11.2025. Der jüngste Squid-Stand upstream ist 19.2.7 vom 12.10.2026, bei Tentacle 20.2.4 vom 19.08.2026.

Proxmox selbst hat sich nicht auf einen festen Tag festgelegt. Im Forum schrieb ein Proxmox-Mitarbeiter am 09.01.2026, Squid bleibe „vorerst bis September 2026" unterstützt — eine Forum-Aussage mit dem Vorbehalt „for the time being", keine Lifecycle-Zusage. Belastbar ist dagegen, was in der Paketquelle steht: Am 22.10.2026 enthielt das öffentliche Proxmox-Repository für Squid zuletzt 19.2.6-pve4, für Tentacle 20.2.4-pve5. Squid 19.2.7 war dort zu diesem Zeitpunkt noch nicht paketiert.

Nüchtern: Squid bekommt noch Pakete, aber das Ende ist angekündigt. Seit Proxmox VE 9.2 vom 21.05.2026 ist Tentacle laut Roadmap der Standard für Neuinstallationen; bestehende Cluster bleiben auf Squid, bis jemand sie umstellt.

/03Voraussetzungen: was vor dem ersten Befehl stimmen muss

Die Proxmox-Anleitung „Ceph Squid to Tentacle" nennt drei harte Bedingungen: alle Knoten mindestens auf Proxmox VE 9.1 mit pve-manager ab 9.1.4, Ceph-Pakete ab 19.2.3-pve3 und ein gesunder Cluster. Der letzte Punkt steht dort wörtlich mit Ausrufezeichen. Die Ceph-Dokumentation zu Tentacle präzisiert, was „gesund" heißt: keine Placement Groups im Zustand down, recovering, incomplete, undersized oder backfilling.

# Auf JEDEM Knoten: Versionen pruefen
pveversion --verbose | grep -E '^pve-manager|^ceph:'
# erwartet (Beispiel):
# pve-manager: 9.1.4 oder hoeher
# ceph: 19.2.3-pve3 oder hoeher

# Einmal, auf beliebigem Knoten: Zustand des Clusters
ceph -s
ceph health detail
ceph pg stat
# Ziel: HEALTH_OK, alle PGs "active+clean"

Dazu kommen Voraussetzungen, die in keiner Anleitung stehen, aber im Betrieb den Unterschied machen:

• Aktuelles Backup aller VMs außerhalb von Ceph. Ein Backup auf einem Proxmox Backup Server mit eigenem Speicher ist die Bedingung, unter der man anfängt — weil ein Knotenausfall mitten im Fenster sonst zwei Probleme gleichzeitig erzeugt.
• Freie Kapazität. Ist der Pool zu mehr als etwa drei Vierteln belegt, wird jede Verschiebung von Daten heikel. Das ist ein Erfahrungswert, keine Herstellergrenze. Ceph selbst rechnet je OSD, nicht je Pool: Standardmäßig gilt ein OSD ab 85 Prozent als nearfull, ab 90 Prozent nimmt es kein Backfill mehr an, ab 95 Prozent als full. Maßgeblich ist also das vollste OSD, nicht der Durchschnitt.
• Stabiles Quorum auf beiden Ebenen. Proxmox-Cluster über Corosync und Ceph-Monitore sind zwei getrennte Quorum-Systeme. Beide müssen vollständig sein, bevor ein Monitor neu startet.

/04Bestandsaufnahme mit ceph versions und ceph osd df

Vorher wird der Ausgangszustand festgehalten; die Ausgaben gehören in die Änderungsdokumentation. Zwei Befehle reichen, ein dritter ist für ältere Cluster Pflicht.

# 1. Welche Dienste laufen mit welcher Version?
ceph versions
# Ausgabe (gekuerzt, Schema):
# {
#     "mon": { "ceph version 19.2.x (...) squid (stable)": 3 },
#     "mgr": { "ceph version 19.2.x (...) squid (stable)": 3 },
#     "osd": { "ceph version 19.2.x (...) squid (stable)": 12 },
#     "overall": { "ceph version 19.2.x (...) squid (stable)": 18 }
# }
# Deutung: Genau EINE Version je Dienst. Stehen dort zwei Squid-Staende,
# erst angleichen, dann Tentacle.

# 2. Belegung je OSD, Spalte META merken
ceph osd df tree
# Deutung: META ist der Platz fuer RocksDB-Metadaten. Diesen Wert
# je OSD notieren - er ist die Basis fuer die Pruefung in Abschnitt /08.

# 3. Nur bei Clustern, die vor Ceph Pacific (v16) angelegt wurden:
#    Sharding je OSD pruefen (OSD muss dafuer gestoppt sein, Knoten fuer Knoten)
ceph osd set noout
systemctl stop ceph-osd@
ceph-bluestore-tool show-sharding --path /var/lib/ceph/osd/ceph-
systemctl start ceph-osd@
ceph osd unset noout

Der dritte Schritt beantwortet die Frage, die das bekannte Problem aus Abschnitt /08 auslöst: Nutzt die RocksDB des OSD Sharding oder nicht? Laut Ceph-Dokumentation verwenden OSDs, die unter Pacific oder später angelegt wurden, Sharding standardmäßig; bei OSDs aus der Zeit davor ist es nach einem Upgrade abgeschaltet und bleibt es, bis jemand es umstellt. Ein über mehrere Ceph-Versionen gewachsener Cluster kann beide Sorten mischen, ohne dass die Weboberfläche es zeigt.

/05Repository, noout und Pakete: die Vorbereitung

Die Vorbereitung verändert noch nichts am laufenden Betrieb. Nach apt full-upgrade liegen die Tentacle-Programmdateien zwar auf der Platte, aber laut Proxmox-Anleitung laufen alle Dienste weiter mit den alten Squid-Binaries — bis zum Neustart. Dieser Teil geht deshalb auf allen Knoten in einem Zug.

# Auf JEDEM Knoten: Paketquelle von squid auf tentacle umstellen
sed -i 's/squid/tentacle/' /etc/apt/sources.list.d/ceph.sources
# oder im alten Einzeilen-Format:
sed -i 's/squid/tentacle/' /etc/apt/sources.list.d/ceph.list

# Kontrolle (Beispiel ohne Subskription):
cat /etc/apt/sources.list.d/ceph.sources
# Types: deb
# URIs: http://download.proxmox.com/debian/ceph-tentacle
# Suites: trixie
# Components: no-subscription
# Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

# Einmal, beliebiger Knoten: Rebalancing waehrend der Neustarts verhindern
ceph osd set noout

# Auf JEDEM Knoten: Pakete holen
apt update && apt full-upgrade

Mit gültiger Proxmox-Subskription zeigt die URI auf enterprise.proxmox.com/debian/ceph-tentacle mit der Komponente enterprise. Das Flag noout ist laut Anleitung optional, aber empfohlen: Es verhindert, dass Ceph einen kurz neu startenden OSD als ausgefallen bewertet und mit dem Umverteilen seiner Daten beginnt. Dieses Umverteilen erzeugt Last und verzögert die Neustarts.

Ein Detail, das gern übersehen wird: apt full-upgrade zieht auch alle anderen anstehenden Proxmox-Pakete mit, je nach Stand inklusive eines neuen Kernels. Wer Ceph-Upgrade und Kernelwechsel nicht im selben Fenster haben will, bringt die Knoten vorher auf den aktuellen Squid-Stand und startet sie neu — die Logik dahinter steht im Beitrag zur Update-Reihenfolge im Proxmox-Cluster.

/06Neustart-Reihenfolge: Monitore, Manager, OSDs, MDS

Die Reihenfolge ist durch Ceph vorgegeben und in der Proxmox-Anleitung wie in der Ceph-Dokumentation identisch: erst alle Monitore, dann die Manager, dann die OSDs, dann die Metadatenserver für CephFS. Jeder Dienst wird einzeln oder knotenweise neu gestartet, danach wird geprüft. Alle Befehle, die mit ceph beginnen, laufen einmal auf einem beliebigen Knoten; systemctl läuft auf dem jeweiligen Knoten.

Zwei Hinweise aus der Proxmox-Anleitung, die sich in der Praxis bestätigen. Erstens: Liefert min_mon_release nach dem letzten Monitor nicht „20 (tentacle)", ist mindestens ein Monitor nicht neu gestartet oder nicht im Quorum. Dann wird nicht weitergemacht. Zweitens: In seltenen Fällen reagieren die Manager nach dem ersten Monitor-Neustart nicht mehr. Die Anleitung empfiehlt, dann zuerst alle Monitore fertig neu zu starten und erst danach die Manager.

Bei den OSDs entscheidet Geduld. Zwischen zwei Knoten wird gewartet, bis ceph status keine PGs mehr im Zustand peering oder degraded zeigt. Belastbare Zeiten liefert nur der eigene Cluster. Wer den Ablauf skriptet, baut die Prüfung ein, statt mit festen Wartezeiten zu arbeiten:

# Auf dem Knoten, dessen OSDs gerade neu gestartet wurden:
systemctl restart ceph-osd.target
sleep 30   # dem Monitor Zeit geben, die Neustarts zu registrieren
# warten, bis keine PG mehr in einem unsauberen Zustand ist
until ! ceph pg stat | grep -qE 'degraded|undersized|peering|activating|recover|backfill|down|stale|unknown'; do
  sleep 15
done
ceph versions | grep -A3 '"osd"'

CephFS: die Metadatenserver

Nur wer CephFS nutzt, etwa für ISO-Ablagen oder gemeinsame Verzeichnisse, hat Metadatenserver. Der Ablauf laut Anleitung je Dateisystem: allow_standby_replay notieren und abschalten, bei mehreren aktiven MDS max_mds notieren und auf 1 setzen, warten bis nur noch Rang 0 aktiv ist, alle Standby-MDS mit systemctl stop ceph-mds.target anhalten, den letzten aktiven MDS neu starten, die Standbys wieder starten und die notierten Werte zurücksetzen.

ceph fs ls
ceph fs get <fs_name> | grep -E 'allow_standby_replay|max_mds'
ceph fs set <fs_name> allow_standby_replay false
ceph fs set <fs_name> max_mds 1
# ... Standbys stoppen, letzten MDS neu starten, Standbys starten ...
ceph fs set <fs_name> max_mds <alter_wert>
ceph fs set <fs_name> allow_standby_replay <alter_wert>

Laufen im Cluster Object-Gateways (RGW), was unter Proxmox selten ist, folgen sie laut Ceph-Dokumentation als letzter Dienst: systemctl restart ceph-radosgw.target auf jedem Gateway-Knoten.

Ehrlich: Während der letzte aktive MDS neu startet, warten Zugriffe auf dieses Dateisystem. VM-Platten auf RBD sind davon nicht betroffen, wohl aber Container oder Anwendungen, die CephFS direkt einbinden. Das gehört in die Ankündigung des Wartungsfensters.

/07require-osd-release: der Punkt ohne Rückweg

Erst wenn ceph versions für alle OSDs eine 20.2-Version zeigt, folgt der Befehl, der das Upgrade abschließt:

ceph osd require-osd-release tentacle
# danach verschwindet die Warnung:
# "all OSDs are running tentacle or later but require_osd_release < tentacle"

ceph osd unset noout
ceph -s     # Ziel: HEALTH_OK

Laut Ceph-Dokumentation schließt dieser Schritt OSDs älterer Versionen aus und schaltet die Funktionen frei, die nur Tentacle kennt. Das ist der eigentliche Rückfallpunkt des ganzen Vorgangs: Bis hierher laufen OSDs zwar schon mit Tentacle, der Cluster akzeptiert aber noch Squid-OSDs. Danach nicht mehr. Einen dokumentierten Weg zurück auf Squid nennt weder die Proxmox-Anleitung noch die Tentacle-Upgrade-Beschreibung von Ceph — ein „Downgrade" ist im Ernstfall eine Wiederherstellung, kein Befehl.

Für die Planung heißt das: Zwischen dem letzten OSD-Neustart und require-osd-release darf Zeit liegen. Eine Wartezeit schreiben weder Ceph noch Proxmox vor; beide führen den Befehl schlicht als Abschlussschritt. Was folgt, ist unsere Praxis, keine Herstellervorgabe: Wir lassen einen Cluster in dieser Phase gern einige Tage im Normalbetrieb laufen, beobachten Latenzen und die META-Spalte und setzen den Abschluss erst danach. Wichtig ist nur, dass der Zwischenzustand dokumentiert ist und nicht in Vergessenheit gerät — ein Cluster, der monatelang gelb meldet, gewöhnt alle an eine gelbe Statusanzeige. In einem Runbook steht deshalb ein Datum für diesen Schritt, nicht „später".

/08Bekanntes Problem: wachsender META-Verbrauch alter OSDs

Seit der Überarbeitung vom 28.09.2026 führt die Proxmox-Anleitung einen Abschnitt „Known Issues". Er betrifft OSDs, die unter Ceph Octopus (v15, erschienen Anfang 2020) oder früher angelegt wurden: Nach dem Upgrade auf Tentacle bis Version 20.2.4 kann deren META-Verbrauch steigen. Zu sehen ist das in ceph osd df in der Spalte META. In der Proxmox-Oberfläche zeigt es sich indirekt: Der angezeigte Gesamtspeicher sinkt, weil Ceph den verfügbaren Platz am vollsten OSD ausrichtet.

Die Ursache laut Anleitung: Die RocksDB dieser OSDs nutzt kein Sharding, das Ceph erst ab Pacific (v16) standardmäßig einrichtet. Im Ceph-Tracker ist der Fehler als Bug #76256 geführt („META space usage explodes on osds without sharding after upgrade to tentacle"). Der Tentacle-Backport ist dort als erledigt markiert, allerdings mit einem Entwicklungsstand nach 20.2.4; eine Tentacle-Version mit dem Fix war am 22.10.2026 upstream noch nicht erschienen. Proxmox liefert seit Paket 20.2.4-pve5 vom 01.10.2026 laut Changelog einen zurückportierten Fix für ein BlueFS-Speicherleck beim Schließen von Dateien. Das passt inhaltlich zum Tentacle-Backport, der Changelog nennt die Tracker-Nummer aber nicht. Deshalb gilt: nach dem Upgrade messen, nicht auf eine Versionsnummer vertrauen.

Die Anleitung nennt drei Wege, die sich nach Aufwand staffeln:

Den vollständigen Sharding-Parameter nennt die Ceph-Dokumentation zu BlueStore; er wird nicht von Hand variiert. Unsere Reihenfolge in betreuten Clustern: Wer in Abschnitt /04 OSDs ohne Sharding gefunden hat, stellt sie vor dem Tentacle-Upgrade um oder legt sie neu an — dann tritt das Problem gar nicht erst auf. Wer es erst hinterher bemerkt, verdichtet zunächst, um Luft zu bekommen, und plant die dauerhafte Lösung in ruhige Fenster.

Hilfreich ist eine Alarmierung auf genau diese Größe. Die Spalte META wächst sonst unbemerkt, bis eine nearfull-Warnung auftaucht. Wie sich Ceph-Werte in Prometheus und Grafana einbinden lassen, beschreibt der Beitrag zum Proxmox-Monitoring mit Prometheus, Grafana und PDM.

/09Wo es hakt: CephX-Schlüssel, Autoscaler und Wartungsfenster

Neue Sicherheitsmeldungen nach dem Upgrade

Tentacle 20.2.4 behebt laut Ceph-Releasenotes unter anderem CVE-2025-30156, eine Authentifizierungsumgehung in CephX durch fehlerhafte Verwendung von AES-CBC. Behoben ist sie ab Squid 19.2.6 und Tentacle 20.2.4. Laut Ceph-Sicherheitshinweis bringt das Update sechs neue Warnungen oder Fehler im Cluster-Zustand mit, darunter AUTH_INSECURE_KEYS_CREATABLE, und verlangt die Umstellung der Schlüssel auf den Typ aes256k. Wer von einer Squid-Version vor 19.2.6 kommt, sieht diese Meldungen zum ersten Mal mitten im Tentacle-Upgrade — und hält sie leicht für eine Folge des Upgrades. Ceph nennt die Meldungen ausdrücklich normal und empfiehlt, das Rotationsverfahren schon vor dem Upgrade zu lesen.

Unsere Empfehlung: Die Schlüsselumstellung nach dem Abschluss des Upgrades als eigenen Schritt planen, nach dem Abschnitt „Upgrading and Rotating CephX Keys" der Ceph-Dokumentation, und nicht zwischen Monitor- und OSD-Neustarts einschieben. Proxmox hat in den Paketen 20.2.4-pve3 und -pve4 laut Changelog zusätzliche Hilfen für die Schlüsselrotation eingebaut, etwa eine Anzeige, welche Sitzung mit welchem Schlüssel angemeldet ist.

PG-Autoscaler anhalten

Die Ceph-Dokumentation zu Tentacle schlägt vor, den Autoscaler für die Placement Groups während des Upgrades für alle Pools anzuhalten und erst nach bestätigtem Erfolg wieder freizugeben. So beginnt Ceph nicht mitten im Ablauf, PGs zu teilen oder zusammenzulegen:

ceph osd pool set noautoscale     # vor dem ersten Neustart
ceph osd pool unset noautoscale   # nach erfolgreichem Abschluss

Wartungsfenster und Hochverfügbarkeit

Das Ceph-Upgrade selbst verlangt keinen Neustart der Knoten und keine Migration von VMs. Die HA-Verwaltung von Proxmox bleibt aktiv. Trotzdem gilt: Während OSDs eines Knotens neu starten, läuft der Cluster mit reduzierter Redundanz. Fällt in genau diesem Moment ein zweiter Knoten aus, sind bei Pools mit drei Kopien weniger Kopien erreichbar als die Mindestzahl min_size verlangt — Zugriffe auf die betroffenen Placement Groups stehen dann, bis ein Knoten zurück ist. Deshalb finden Ceph-Upgrades nicht parallel zu Hardwaretausch oder Netzarbeiten statt.

/10Jetzt upgraden oder warten? Die Entscheidungstabelle

Ob das Upgrade in den nächsten Wochen oder erst im Frühjahr fällig ist, hängt an vier Fragen: Proxmox-Version, Alter der OSDs, Gesundheit des Clusters, Nutzung von CephFS. Die folgende Tabelle ist die Entscheidungslogik, nach der wir betreute Cluster einordnen.

Wann sich das Upgrade nicht lohnt: Ein Cluster, dessen Hardware ohnehin in den nächsten Monaten ersetzt wird, bekommt Tentacle sinnvollerweise mit der Neuinstallation — seit Proxmox VE 9.2 ist es dort ohnehin Standard. Den Altbestand noch umzustellen, ist dann Aufwand ohne Ertrag — sofern Squid bis zur Ablösung gesichert und überwacht bleibt. Den Hintergrund zu Ceph als Speicherarchitektur liefert der Beitrag Ceph Storage ohne Lizenzkosten.

Für alle anderen gilt: Squid hat ein angekündigtes Ende, Tentacle ist seit Proxmox VE 9.2 im Mai 2026 als stabile Option verfügbar, und der Ablauf ist dokumentiert. Warten verschiebt das Upgrade nur in eine Zeit ohne Squid-Sicherheitskorrekturen. Für On-Premise-Cluster ohne eigenes Ceph-Know-how ist das der Moment, über Managed Services nachzudenken, bevor der Druck kommt.

/11Häufige Fragen