Zum Inhalt springen
labkompass

Assistent · Storage Cluster

Cluster-Troubleshooting-Assistent

Wähle Technologie und Symptom oder füge eine Statuszeile ein: Der Assistent zeigt, was du in welcher Reihenfolge prüfst, welcher lesende Befehl das zeigt und wie du das Ergebnis liest. Ursachen sind als Hypothesen formuliert. Ausgeführt oder geändert wird nichts.

Der Text wird nur in deinem Browser mit bekannten Kennungen abgeglichen und weder gespeichert noch übertragen. Entferne trotzdem Hostnamen und Adressen, bevor du Ausgaben irgendwo teilst.

Was beobachtest du?

Ceph meldet HEALTH_WARN oder HEALTH_ERR

ceph -s oder das Dashboard zeigt HEALTH_WARN bzw. HEALTH_ERR — und du weißt noch nicht, warum.

Prüfe in dieser Reihenfolge

  1. 01Welche Health-Checks sind aktiv?

    ceph health detail

    Listet jeden aktiven Health-Check mit seiner Kennung (z. B. OSD_DOWN, PG_DEGRADED) und den betroffenen Daemons oder Placement Groups.

    • Jede Kennung ist ein eigener Fall — arbeite sie einzeln ab, die schwerwiegendste (HEALTH_ERR) zuerst.
    • OSDMAP_FLAGS mit noout → jemand hat eine Wartung begonnen und das Flag nicht zurückgenommen.
    • RECENT_CRASH → ein Daemon ist abgestürzt; die Ursache steht im Crash-Bericht.

  2. 02Gesamtzustand und letzte Ereignisse

    ceph -s

    Zeigt Monitor-Quorum, OSD-Zahlen (up/in), PG-Zustände und laufende Recovery auf einen Blick.

    • Alle OSDs up und in, alle PGs active+clean → die Warnung betrifft etwas anderes als die Datenverfügbarkeit.
    • Laufende recovery/backfill → der Cluster repariert sich gerade; warten und beobachten.

  3. 03Abgestürzte Daemons

    ceph crash ls-new

    Zeigt Abstürze, die noch nicht quittiert wurden. Details liefert ceph crash info mit der Crash-ID.

    • Wiederholte Abstürze desselben OSD → Datenträger oder Host prüfen, bevor du den Absturz quittierst.

  4. 04Cluster-Log

    ceph log last 50

    Die letzten 50 Zeilen des Cluster-Logs mit Zeitstempel — hilfreich, um die Reihenfolge der Ereignisse zu sehen.

    • Der erste Fehler in der Zeitfolge ist oft die Ursache, die späteren sind Folgen.

Mögliche Ursachen

Hypothesen, keine Diagnose — welche zutrifft, zeigen erst die Prüfungen oben.

  • Ein Daemon (OSD, MON, MGR) ist ausgefallen oder abgestürzt.
  • Ein Wartungs-Flag wie noout ist noch gesetzt.
  • Füllstand, Uhrzeit oder langsame Operationen überschreiten eine Schwelle.
  • Nach einem Update aktive neue Warnungen, etwa zu CephX-Schlüsseln (Tentacle 20.2.4).

Häufige Fragen

Sind die Befehle gefahrlos?

Die Diagnosebefehle lesen nur: Status, Logs, Füllstände, Zähler. Ändernde Schritte — ein OSD entfernen, ein Flag zurücknehmen, ein DRBD-Split-Brain auflösen — stehen bewusst nicht im Assistenten, sondern im Troubleshooting-Guide mit Erklärung, Risiko und Rückweg.

Was passiert mit der eingefügten Fehlermeldung?

Nichts außerhalb deines Browsers. Der Text wird lokal mit bekannten Kennungen wie OSD_DOWN oder StandAlone abgeglichen. Er wird weder gespeichert noch übertragen; in der Adresszeile steht höchstens die Kennung des gewählten Falls.

Mein Problem steht nicht in der Liste — was nun?

Beginne mit ceph health detail bzw. drbdadm status oder dem Zustand der Longhorn-Volumes. Die dort genannten Kennungen führen fast immer zu einem der Fälle oder zur passenden Seite der offiziellen Doku.

Passende Tools

Replikation und Quorum Simulator →

2 Nodes, 2 Nodes + Witness, 3 oder 5 Nodes: Ausfälle und Netztrennungen durchspielen und getrennt sehen, ob Quorum, Datenkopien und Schreibzugriff erhalten bleiben — für Ceph, DRBD und Proxmox.

Cluster-Hardware-Planer →

RAM, CPU, Netzwerk, SSD-Klasse und Controller für Ceph, Proxmox + Ceph, LINSTOR oder Longhorn gegen die offizielle Doku prüfen — Bedarf, Engpass und Checkliste, jede Regel mit Quelle.

smartctl Command Builder →

Festplatten-Gesundheit prüfen: Health-Check, SMART-Attribute und Selbsttests — mit Erklärung, wie Tests ablaufen.