Ceph OSD‑Ausfall reparieren: Datenrebalancing, Backfilling‑Probleme und OSD‑Replace‑Prozess

Ceph OSD‑Ausfall reparieren ist eine Routineaufgabe in verteilten Object‑Storage‑Umgebungen, aber sie birgt Risiken: falsches Tuning kann Produktions‑IO verschlechtern, ein voreiliges Entfernen von OSDs kann zu unsized/lost PGs führen. Dieser Artikel erklärt Schritt für Schritt, wie Sie einen OSD‑Ausfall sicher erkennen, Backfill‑/Rebalance‑Probleme beheben, Recovery‑Parameter verantwortet anpassen und einen OSD‑Replace sowohl manuell mit ceph‑volume als auch orchestriert mit cephadm durchführen. Zielgruppe sind Administratoren, System Engineers und Storage‑Operatoren.

Warum der Fokus auf Rebalance und Backfill wichtig ist

OSD steht für Object Storage Daemon; er repräsentiert ein Laufwerk und den dazugehörigen Daemon, der Objekte in Placement Groups (PGs) verwaltet. Fällt ein OSD aus, versucht Ceph, fehlende Replikate über Backfill und Rebalancing wiederherzustellen. Backfill (Datenkopieren von vorhandenen Replikaten) und Rebalance (Neuverteilung von Objekt‑Platzierungen) erzeugen viel Netzwerk‑ und Festplatten‑IO. Ohne gezieltes Management können dadurch Latenzen steigen oder Recovery deutlich verlangsamt werden – und damit die Zeit, in der der Cluster nicht im idealen Zustand ist.

Erste Maßnahmen: schnelle Einschätzung

Beginnen Sie mit einem „First‑Look“‑Check, um Ausmaß und Dringlichkeit zu bestimmen. Das hilft zu entscheiden, ob Sie parameter­tuning, temporäre Flags oder einen sofortigen OSD‑Replace benötigen.

# Gesamtstatus, betroffene PGs, Recovery-Zeit
ceph -s
# Topologie und welcher Host betroffen ist
ceph osd tree
# Kapazitätsverteilung und freie Kapazität
ceph osd df

Wichtig ist: Notieren Sie die Anzahl degraded/recovering PGs, Recover‑Throughput und ob MON‑Meldungen vorhandene OSDs als out/down markieren. Diese Werte bestimmen die Dringlichkeit.

Ceph OSD‑Ausfall reparieren: Prioritäten und Entscheidungsbaum

Bei der Entscheidung, wie zu handeln ist, unterscheiden Sie drei Prioritäten: 1) Datenzugriff für Anwendungen erhalten, 2) Cluster‑Health wiederherstellen, 3) Nachhaltiges Bereinigen/Ersetzen des fehlerhaften OSD. Ein schnelles Diagramm im Kopf:

• Wenn SMART‑Errors oder wiederholte kurzzeitige Ausfälle vorliegen → OSD ersetzen.
• Wenn Netzwerk/Host‑Erreichbarkeit die Ursache ist → Host‑Diagnose, evtl. noout für geplante Wartung.
• Wenn Backfill extrem langsam ist → Ursachenanalyse (Netzwerk, IO, Parameter) und temporäres Tuning mit Rückrollplan.

Wesentliche Prüfungen und Metriken

Monitoring ist entscheidend. Wesentliche Metriken:

• PG‑Status: active+clean, recovering, degraded — gibt direkten Zustand wieder.
• Recover Bytes / Recover Throughput: wie viele Bytes/sek übertragen werden.
• OSD‑Latenzen (read/write): permanente Erhöhung weist auf Hotspots oder Sättigung hin.
• Netzwerkmetriken: Bandbreite, Paketverlust, MTU‑Mismatch.
• Host‑Level: iostat, CPU, mem, SMART für Disk‑Fehler.

# Live Überwachung
ceph -w
# PG-Übersicht
ceph pg dump pgs_brief
# Beispiel iostat
iostat -x 1 5

Logs und typische Fehlermeldungen

OSD‑ und MON‑Logs zeigen Ursachen. Häufige Meldungen:

• „heartbeat from osd.X timed out“ → Netzwerk/Host‑Erreichbarkeit; prüfen Sie MTU, Switch‑Logs, IPMI.
• SMART‑fehler oder I/O‑Errors → physische Disk defekt.
• „slow request“ → OSD/Device‑Performance, oft Ursache für langsames Backfill.

# OSD-Logs prüfen
journalctl -u ceph-osd@.service -n 200
# Alternativ Ceph-Logs
grep -i "heartbeat" /var/log/ceph/ceph-osd.*.log

Typische Ursachen für sehr langsames Backfill

Langsames Backfill ist meist nicht nur ein Parameter‑Problem. Häufige Ursachen:

• Netzwerkengpässe oder Packetloss (z. B. MTU‑Mismatch, QoS, Spanning Tree Events).
• Einzelne langsame OSDs (Hardware‑Degradation, IOPS‑Limit auf RAID‑Controller).
• Cluster‑Hotspots: Manche OSDs erhalten deutlich mehr Daten als andere (CRUSH‑Ungleichgewicht, falsch konfigurierte CRUSH‑Rules).
• Fehlende freie Kapazität auf Ziel‑OSDs: Rebalancing braucht freien Platz.

Schrittweises Troubleshooting bei hängenden Backfills

1. Netzwerk prüfen: iperf3 Tests zwischen betroffenen Hosts.

# Auf Host B (Server, Empfänger)
iperf3 -s
# Auf Host A (Client, Sender)
iperf3 -c  -t 30

2. MTU prüfen und vergleichen auf allen OSD‑Interfaces.

ip link show eth0
ethtool -k eth0

3. Device‑Health und Performance prüfen (SMART, iostat).

smartctl -a /dev/sdX
iostat -x 1 10

4. Hotspots erkennen: OSD‑DF und OSD‑Latency‑Metriken auswerten.

ceph osd df tree
# Falls Prometheus vorhanden, prüfen: ceph_osd_op_latency_seconds

Temporäres Tuning: verantwortet anpassen

Änderungen an Recovery‑Parametern können Recovery beschleunigen, aber auch Produktions‑IO beeinträchtigen. Speichern Sie vorher die aktuellen Werte und erhöhen Sie schrittweise mit Monitoring.

# Werte sichern
ceph config get global osd_max_backfills > /tmp/osd_max_backfills.before || true
ceph config get global osd_recovery_max_active > /tmp/osd_recovery_max_active.before || true
# Beispielhafte, konservative Erhöhung
ceph config set global osd_max_backfills 4
ceph config set global osd_recovery_max_active 8

Warum es funktioniert: osd_max_backfills steuert wie viele Backfill‑Threads pro OSD gleichzeitig laufen; osd_recovery_max_active limitiert parallele Recovery‑Operations. Erhöhung erlaubt mehr parallele Datenbewegung, benötigt aber deutlich mehr Netzwerk‑ und Disk‑Reserven. Scheitert es, wenn einzelne OSDs weiterhin langsam sind oder Netzwerkbandbreite begrenzt ist – dann erhöhtes Recovery verschlechtert nur Latenzen.

Flags sinnvoll nutzen: noout, norebalance, nobackfill

Flags können helfen, aber sie sind riskant. noout verhindert, dass MONs OSDs automatisch aus dem CRUSH nehmen, etwa bei temporärer Wartung. Verwenden Sie:

# Vor geplanter Wartung
ceph osd set noout
# Nach Abschluss
ceph osd unset noout

Warnung: noout kann echte Ausfälle verdecken. norebalance oder nobackfill sind ähnlich: sinnvoll für kurze Wartungsfenster, gefährlich, wenn ein OSD wirklich verloren ist.

OSD ersetzen: Workflow und Befehle (manuell mit ceph-volume)

Wenn ein Laufwerk defekt ist oder SMART‑Errors vorliegen, ist ein sauberer Replace meist die beste Option. Hier ein konservatives, dokumentierbares Vorgehen für manuelle Replace mit ceph-volume (LVM‑basierte OSDs):

1. OSD sauber aus dem Dienst nehmen (out) und warten, bis PGs wieder im Prozess sind.

# Markieren und prüfen
ceph osd out osd.
ceph -s    # beobachten, bis PGs recovering/clean werden

2. Stoppen Sie den OSD‑Dienst auf dem Host.

systemctl stop ceph-osd@.service
# Prüfen, dass der Prozess gestoppt ist
systemctl status ceph-osd@.service

3. Zap/entfernen Sie das alte Device (bei physischem Austausch).

# Zap löscht LVM/Partition-Header. ACHTUNG: unwiderruflich für das Device
ceph-volume lvm zap /dev/sdX --destroy

Erklärung: ceph-volume lvm zap entfernt Ceph‑Metadaten vom Device und bereitet es für Reuse vor. Scheitern kann, wenn device busy ist; prüfen Sie LVs mit lvs.

4. Installieren Sie das neue Laufwerk und erstellen Sie das OSD.

# Beispiel: neues OSD auf /dev/sdY anlegen
ceph-volume lvm create --data /dev/sdY

Nach create wird das OSD automatisch bei MONs registriert und CRUSH‑Regeln angewendet. Beobachten Sie den Rebalancing‑Fortschritt.

OSD ersetzen: mit cephadm (orchestriert)

In cephadm‑verwalteten Clustern bevorzugen viele Betreiber die orchestrierte Variante, weil cephadm das Lifecycle‑Management übernimmt (Container‑Image, Unit‑Deploy, Logging). Typische Schritte:

1. Vorbereiten: Neues Device am Host verfügbar machen.
2. Mit cephadm das OSD auf dem host hinzufügen oder gezielt ersetzen.

# Alle verfügbaren Devices erkennen (nur lesen)
ceph orch device ls
# Alle verfügbaren Devices als OSDs nutzen (vorsichtig; meist in Staging testen)
ceph orch apply osd --all-available-devices
# Alternativ: gezielt ein Device zu einem Host hinzufügen (prüfen in Ihrer Ceph-Version)
# ceph orch daemon add osd :  <-- je nach Version und Politik

Hinweis: ceph orch apply osd --all-available-devices ist mächtig und darf in Produktion nur verwendet werden, wenn Sie die Orchestrator‑Policy verstehen. Testen Sie im Staging.

Sorgfältige Validierung nach Replace

Nach jedem Replace validieren Sie:

• Cluster‑Health ist HEALTH_OK oder zumindest keine degraded/recovering PGs mehr.
• ceph osd df tree zeigt gleichmäßig verteilte Daten und keine extremen Hotspots.
• Stichprobenhafte Lesezugriffe auf kritische Pools/Objekte und Vergleich von Checksummen falls vorhanden.

# Wichtige Prüfungen
ceph -s
ceph health detail
ceph osd df tree
# Beispiel: stichprobenartiger Objekt-Check
rados -p  ls | head
rados -p  get 

Rollback‑Plan und Dokumentation

Jede Änderung an Recovery‑Parametern oder das Entfernen von OSDs muss rückholbar sein. Legen Sie Skripte an, die ursprüngliche Configwerte wiederherstellen und halten Sie Zeitstempel zu allen Aktionen bereit.

# Rücksetzskript-Beispiel
prev1=$(cat /tmp/osd_max_backfills.before || echo "2")
prev2=$(cat /tmp/osd_recovery_max_active.before || echo "2")
ceph config set global osd_max_backfills "$prev1"
ceph config set global osd_recovery_max_active "$prev2"
ceph osd unset noout || true

Typische Stolperfallen und wie Sie sie vermeiden

Praktische Fehler, die häufiger auftreten:

• Änderungen an Recovery‑Parametern ohne Observability: immer Dashboards und Alerts prüfen.
• OSD löschen (ceph osd rm) während PGs noch recovering sind: verursacht lost/unsized PGs.
• Blindes Anwenden von ceph orch apply osd --all-available-devices in heterogenen Hosts: ungewollte OSD‑Erstellungen.
• Zu geringe freie Kapazität vor Replace: stellen Sie sicher, dass Ziel‑OSDs ausreichend Platz haben.

Pragmatische Checkliste für den OSD‑Replace

1. Erfassen: ceph -s, ceph osd tree, ceph osd df, relevante Logs.
2. Sichern: aktuelle Config‑Werte exportieren (/tmp) und Monitoring‑Screenshots speichern.
3. Entscheiden: Replace oder Reparatur (Host vs. Laufwerk). Wenn unsicher, lieber Reweight statt rm.
4. Durchführen: noout setzen für geplante Wartung; OSD out; stop; zap; create mit ceph-volume oder cephadm.
5. Observieren: Recovery‑Durchsatz, Latenzen und Netzwerkauslastung; Rücksetzpunkte bereit halten.
6. Validieren: HEALTH_OK, ceph osd df tree, Stichproben‑Reads.
7. Dokumentieren: Zeit, Werte, Entscheidungen, Rückrollaktion.

Fazit

Ceph OSD‑Ausfall reparieren heißt: strukturiert arbeiten, Monitoring nutzen, konservativ und dokumentiert Parameter ändern und Replace‑Workflows testen. Trennen Sie Host‑von Laufwerksproblemen, bevorzugen Sie reweighting gegenüber sofortigem Entfernen, und nutzen Sie orchestrierte Tools wie cephadm nur nach Staging‑Tests. Mit klaren Prüfungen, Rückfallstrategien und automatisierten Rollback‑Skripten reduzieren Sie das Risiko von Dateninkonsistenzen und sorgen für kürzere Recovery‑Zeiten.

Weiterführende Hinweise für den Betrieb

Stellen Sie sicher, dass Ihre Runbooks regelmäßig geübt werden. Testläufe in Staging erhöhen die Sicherheit bei Live‑Einsätzen. Legen Sie außerdem fest, welche Team‑Rollen in welcher Reihenfolge informiert und aktiv werden (Operator, NetAdmin, Storage‑Engineer) – das beschleunigt Eskalationen und reduziert Fehler während kritischer Eingriffe.

Ceph OSD‑Ausfall reparieren: Architektur‑ und Betriebsaspekte

Beim Thema Ceph OSD‑Ausfall reparieren ist die unmittelbare Fehlerbehebung nur eine Seite — die Architekturentscheidungen und der laufende Betrieb bestimmen maßgeblich, wie schnell und sicher Recovery funktioniert. Entscheidend sind Placement‑Strategie (CRUSH), der Pool‑Typ (Replikation vs. Erasure Coding), Netz‑Topologie und Kapazitätsreserve.

CRUSH‑Map und Topologie: Sorgen Sie dafür, dass CRUSH Regeln physische Grenzen abbilden (Server, Chassis, Rack, AZ). Ohne rack‑aware Placement erhöhen Sie beim Ausfall eines Racks das Risiko, dass viele PG‑Replikate gleichzeitig betroffen sind, wodurch Backfill‑Lasten konzentriert werden.

Pool‑Design: Replizierte Pools verhalten sich beim Backfill anders als erasure‑coded Pools. EC‑Pools benötigen oft temporär mehr IO und Netzwerkbandbreite für Rekonstruktion und sind weniger tolerant gegenüber mehreren gleichzeitigen OSD‑Ausfällen. Planen Sie für EC‑Pools größere Headroom‑Reserven und längere Recovery‑Zeiten in Ihren SLOs.

Kapazitäts‑Headroom: Betreiben Sie Ceph nie dauerhaft mit sehr hoher Auslastung. Empfohlen ist eine freie Kapazität (je nach Workload) von mindestens 10–20 %, damit Rebalancing und temporäre Replicate Platz finden. Wenn Ziel‑OSDs kaum freien Platz haben, stagniert Backfill und die Fehlerzeit steigt.

Netzwerkarchitektur: Trennen Sie Public‑ und Cluster‑Traffic physisch oder via QoS. Cluster‑Interconnect‑Sättigung ist eine der häufigsten Ursachen für langsame Backfills. Planen Sie Monitoring‑Metriken für Paketverlust, MTU‑Fehler und per‑OSD‑Durchsatz und schlagen Sie Alarm, bevor Rebalancing beginnt.

Integrationshinweise für den Betrieb: Verknüpfen Sie OSD‑Metadaten mit Ihrer CMDB (Host, Slot, Seriennummer) und Ihren Orchestrierungs‑Tools. Automatisierte Workflows für Hardwaretausch (BMC‑Reboot, Ticketing, Asset‑Update) reduzieren Fehler bei manuellen Eingriffen. Orchestrator‑Aktionen (cephadm) sollten in Change‑Pipelines erfasst und in Staging getestet werden.

Monitoring und Automatisierung: Definieren Sie klare Alert‑Schwellen (z. B. Anzahl degraded PGs, Recover‑Throughput unter Erwartung, OSD‑Latency‑Anstieg). Automatisieren Sie Preflight‑Checks vor einem Replace und ein Rollback‑Script, das alle vorher gespeicherten Config‑Werte wiederherstellt. Üben Sie den Ablauf regelmäßig in einer Replika‑Umgebung — das reduziert menschliche Fehler im Live‑Fall.

Kurzcheck vor Eingriff: CRUSH‑Topologie prüfen, Pool‑Typ beachten, freie Kapazität verifizieren, Netzwerk‑Health checken, OSD→Hardware‑Mapping in CMDB bestätigen. Diese Architektur‑ und Betriebsaspekte verkürzen Recovery‑Zeiten und verringern das Risiko von Dateninkonsistenzen deutlich.

Für dieses Thema sind auch Ceph Backfill und Ceph Rebalancing wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.