Ceph-Warnungen verstehen, bevor der Cluster geändert wird

Mit der Health-Kennung beginnen

HEALTH_WARN ist ein Einstiegspunkt, keine Diagnose. Ceph liefert konkrete Kennungen, weil ein ausgefallener Monitor, ein fast voller OSD und ein langsames Speichergerät unterschiedliche Untersuchungen erfordern. Diese Trennung ist wichtig, weil Storage-Warnungen schnell zu breiten Anwendungssymptomen werden können, wenn sie zu allgemein behandelt werden.

Diese lesenden Prüfungen in einer administrativen Umgebung mit Zugriff auf den vorgesehenen Ceph-Cluster ausführen:

ceph -s
ceph health detail
ceph osd tree
ceph df

Health-Code, betroffenen Daemon oder Pool und aktuelle Auswirkungen auf Clients festhalten. Die Anleitung setzt keinen bestimmten Ceph-Operator oder Toolbox-Pod voraus.

Fehlerbereiche unterscheiden

Signal	Erste Frage
MON_DOWN	Ist ein Monitor ausgefallen und besteht weiterhin eine Mehrheit?
OSD_DOWN	Ist der Daemon, Host oder Netzwerkpfad nicht verfügbar?
OSD_NEARFULL	Welches Gerät oder welcher Pool nähert sich der Kapazitätsgrenze?
OSD_BACKFILLFULL	Blockiert fehlender Platz Recovery oder Rebalancing?
OSD_FULL	Sind Schreibzugriffe wegen einer erreichten Füllgrenze blockiert?
MON_CLOCK_SKEW	Synchronisieren die Monitor-Hosts ihre Uhren korrekt?

Zuerst nach einer gemeinsamen Ursache suchen. Ein Host- oder Netzwerkproblem kann mehrere Daemons gleichzeitig betreffen.

Speicherzustand mit dem Workload verbinden

In Kubernetes können Speicherprobleme als Mount-Fehler, nicht verfügbare Volumes oder steigende Anwendungslatenz sichtbar werden. Das Ceph-Signal mit dem betroffenen Workload verbinden, ohne jedes Anwendungssymptom automatisch dem Speicher zuzuschreiben.

Den Zeitpunkt der Warnung mit Workload-Events und Observability-Daten vergleichen. Genügend Kontext bewahren, um Kapazitätsdruck, Geräteausfall und fehlende Netzwerkerreichbarkeit auseinanderzuhalten.

Ursachenbezogen wiederherstellen

Einen Daemon wiederherstellen, Zeitsynchronisierung korrigieren, Kapazität erweitern und einen Grenzwert ändern sind verschiedene Maßnahmen. Das Verfahren muss zur tatsächlichen Health-Kennung und zur eingesetzten Ceph-Version passen.

Eine Warnung stummzuschalten verändert ihre Sichtbarkeit, nicht ihre Ursache. Auch ein höherer Füllgrenzwert ersetzt keine Analyse des Platzmangels. Nach der Wiederherstellung sowohl den Health-Status als auch den betroffenen Client-Workload prüfen. Das hilfreiche Ergebnis ist eine Storage-Erklärung, die zu dem passt, was Clients tatsächlich erlebt haben.

Quelle

Ceph-Referenz der Health Checks, geprüft am 13. September 2026. latest beschreibt den Entwicklungsstand; für konkrete Recovery-Verfahren die Dokumentation der eingesetzten Version auswählen.