Riparare un guasto OSD di Ceph: ribilanciamento dei dati, problemi di backfilling e processo di sostituzione OSD

Riparare un guasto OSD di Ceph è un’attività di routine in ambienti di object‑storage distribuiti, ma comporta rischi: un tuning errato può peggiorare le IO in produzione, una rimozione troppo frettolosa degli OSD può portare a PG non dimensionati/lost. Questo articolo spiega passo dopo passo come rilevare in sicurezza un guasto OSD, risolvere problemi di Backfill/Rebalance, adattare in modo responsabile i parametri di Recovery e sostituire un OSD sia manualmente con ceph‑volume sia orchestrato con cephadm. Il pubblico di riferimento sono amministratori, system engineer e storage operator.

Perché è importante concentrarsi su Rebalance e Backfill

OSD sta per Object Storage Daemon; rappresenta un disco e il relativo daemon che gestisce gli oggetti nelle Placement Groups (PGs). Se un OSD si guasta, Ceph cerca di ripristinare le repliche mancanti tramite Backfill e Rebalancing. Backfill (copia dei dati dalle repliche esistenti) e Rebalance (redistribuzione del posizionamento degli oggetti) generano un elevato carico di rete e disco. Senza un controllo mirato ciò può aumentare le latenze o rallentare significativamente la recovery – e quindi prolungare il tempo in cui il cluster non si trova nello stato ideale.

Prime misure: valutazione rapida

Iniziate con un controllo “first‑look” per determinare portata e urgenza. Questo aiuta a decidere se servono parameter tuning, flag temporanei o una sostituzione immediata dell’OSD.

# 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

Importante: annotate il numero di PG in degraded/recovering, il Recover‑Throughput e se i messaggi MON marcano gli OSD esistenti come out/down. Questi valori determinano l’urgenza.

Riparare un guasto OSD di Ceph: priorità e albero decisionale

Nella decisione su come procedere distinguete tre priorità: 1) preservare l’accesso ai dati per le applicazioni, 2) ripristinare la health del cluster, 3) pulizia/sostituzione sostenibile dell’OSD guasto. Uno schema mentale rapido:

• Se ci sono SMART‑Errors o guasti ripetuti di breve durata → sostituire l’OSD.
• Se la causa è raggiungibilità di rete/host → diagnostica dell’host, eventualmente noout per manutenzione pianificata.
• Se il Backfill è estremamente lento → analisi delle cause (rete, IO, parametri) e tuning temporaneo con piano di rollback.

Controlli e metriche essenziali

Il monitoring è cruciale. Metriche chiave:

• PG‑Status: active+clean, recovering, degraded — riflette lo stato diretto.
• Recover Bytes / Recover Throughput: quanti byte/sec vengono trasferiti.
• Latenze OSD (read/write): un aumento persistente indica hotspot o saturazione.
• Metriche di rete: larghezza di banda, perdita di pacchetti, MTU‑Mismatch.
• Livello host: iostat, CPU, memoria, SMART per errori del disco.

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

Log e messaggi di errore tipici

I log di OSD e MON mostrano le cause. Messaggi comuni:

• „heartbeat from osd.X timed out“ → raggiungibilità di rete/host; verificate MTU, log degli switch, IPMI.
• SMART‑fehler oder I/O‑Errors → disco fisico difettoso.
• „slow request“ → performance OSD/device, spesso causa di Backfill lento.

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

Cause tipiche di un backfill molto lento

Un backfill lento non è quasi mai solo un problema di parametri. Cause frequenti:

• Colli di rete o perdita di pacchetti (es. MTU‑mismatch, QoS, eventi Spanning Tree).
• Singoli OSD lenti (degrado hardware, limite IOPS sul controller RAID).
• Hotspot nel cluster: alcuni OSD ricevono molti più dati di altri (disequilibrio CRUSH, CRUSH‑Rules configurate in modo errato).
• Mancanza di capacità libera sugli OSD di destinazione: il rebalancing richiede spazio libero.

Troubleshooting graduale per backfill in stallo

1. Verificare la rete: test iperf3 tra gli host interessati.

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

2. Controllare e confrontare l’MTU su tutte le interfacce OSD.

ip link show eth0
ethtool -k eth0

3. Verificare lo stato e le prestazioni dei dispositivi (SMART, iostat).

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

4. Rilevare hotspot: analizzare OSD‑DF e le metriche di latenza degli OSD.

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

Tuning temporaneo: modifiche da gestire responsabilmente

Modifiche ai parametri di recovery possono accelerare la recovery, ma influire anche sulle IO in produzione. Salvate prima i valori correnti e aumentate gradualmente monitorando.

# 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

Perché funziona: osd_max_backfills controlla quanti thread di backfill per OSD possono girare contemporaneamente; osd_recovery_max_active limita le operazioni di recovery parallele. Aumentare permette più movimento dati parallelo, ma richiede molte più risorse di rete e disco. Se alcuni OSD restano lenti o la banda di rete è limitata, un recovery aumentato peggiora solo le latenze.

Uso mirato dei flag: noout, norebalance, nobackfill

I flag possono essere utili, ma sono rischiosi. noout impedisce che i MON rimuovano automaticamente un OSD dal CRUSH, ad esempio durante una manutenzione temporanea. Usare:

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

Avvertenza: noout può nascondere guasti reali. norebalance o nobackfill sono analoghi: utili per finestre di manutenzione brevi, pericolosi se un OSD è effettivamente perso.

Sostituzione OSD: workflow e comandi (manuale con ceph-volume)

Se un disco è guasto o si riscontrano errori SMART, una sostituzione pulita è spesso la soluzione migliore. Di seguito una procedura conservativa e documentabile per la sostituzione manuale con ceph-volume (OSD basati su LVM):

1. Rimuovere l’OSD dal servizio (out) e attendere fino a che i PG non siano nuovamente nel processo.

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

2. Arrestare il servizio OSD sull’host.

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

4. 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

Spiegazione: ceph-volume lvm zap rimuove i metadati Ceph dal device e lo prepara per il riutilizzo. L’operazione può fallire se il device è busy; verificate gli LV con 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

Dopo create l’OSD viene registrato automaticamente presso i MON e vengono applicate le regole CRUSH. Monitorare il progresso del rebalancing.

OSD ersetzen: mit cephadm (orchestriert)

Nei cluster gestiti da cephadm molti operatori preferiscono la variante orchestrata, perché cephadm gestisce il ciclo di vita (immagine del container, deploy delle unità, logging). Passaggi tipici:

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

Nota: ceph orch apply osd --all-available-devices è potente e va usato in produzione solo se si comprende la policy dell’orchestrator. Testare in staging.

Sorgfältige Validierung nach Replace

Dopo ogni sostituzione verificare:

• Lo stato di salute del cluster è HEALTH_OK o, almeno, non ci sono più PG in degraded/recovering.
• ceph osd df tree mostra una distribuzione dei dati uniforme e nessun hotspot estremo.
• Accessi di lettura a campione su pool/oggetti critici e confronto delle checksum, se presenti.

# 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

Ogni modifica ai parametri di recovery o la rimozione di OSD deve essere reversibile. Preparare script che ripristinino i valori di configurazione originali e conservare timestamp per tutte le azioni.

# 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

Errori pratici che si verificano più frequentemente:

• Modifiche ai parametri di recovery senza osservabilità: verificare sempre dashboard e alert.
• Cancellare un OSD (ceph osd rm) mentre i PG sono ancora in recovering: causa PG lost/unsized.
• Applicare alla cieca ceph orch apply osd --all-available-devices su host eterogenei: creazione di OSD indesiderate.
• Capacità libera insufficiente prima della sostituzione: assicurarsi che gli OSD di destinazione abbiano spazio sufficiente.

Pragmatische Checkliste für den OSD‑Replace

1. Raccolta: ceph -s, ceph osd tree, ceph osd df, log rilevanti.
2. Backup: esportare i valori di configurazione correnti (/tmp) e salvare screenshot del monitoring.
3. Decidere: Replace o riparazione (host vs. disco). In caso di dubbio, preferire reweight anziché rm.
4. Eseguire: impostare noout per manutenzione pianificata; OSD out; stop; zap; create con ceph-volume o cephadm.
5. Osservare: throughput di recovery, latenze e utilizzo della rete; predisporre punti di rollback.
6. Validare: HEALTH_OK, ceph osd df tree, letture a campione.
7. Documentare: tempo, valori, decisioni, azione di rollback.

Fazit

Riparare un guasto OSD di Ceph significa: lavorare in modo strutturato, usare il monitoring, modificare i parametri in modo conservativo e documentato e testare i workflow di Replace. Separate i problemi a livello di host da quelli a livello di disco, preferite il reweighting rispetto alla rimozione immediata e utilizzate strumenti orchestrati come cephadm solo dopo test in staging. Con controlli chiari, strategie di fallback e script di rollback automatizzati ridurrete il rischio di incoerenze nei dati e garantirete tempi di recovery più brevi.

Weiterführende Hinweise für den Betrieb

Assicuratevi che i vostri Runbooks vengano esercitati regolarmente. Test in staging aumentano la sicurezza nelle operazioni live. Stabilite inoltre quali ruoli del team siano informati e attivino in quale ordine (Operator, NetAdmin, Storage‑Engineer) – questo accelera le escalation e riduce gli errori durante interventi critici.

Ceph OSD‑Ausfall reparieren: Architektur‑ und Betriebsaspekte

Nel contesto della riparazione di un guasto OSD di Ceph, la risoluzione immediata dell’errore è solo un aspetto — le decisioni architetturali e l’operatività corrente determinano in misura decisiva quanto rapidamente e in sicurezza avviene il recovery. Determinanti sono la strategia di placement (CRUSH), il tipo di pool (replicazione vs. erasure coding), la topologia di rete e la riserva di capacità.

CRUSH‑Map e topologia: assicuratevi che le regole CRUSH rappresentino i confini fisici (Server, Chassis, Rack, AZ). Senza un placement rack‑aware aumentate, in caso di failure di un rack, il rischio che molte repliche PG siano interessate contemporaneamente, concentrando i carichi di backfill.

Design dei pool: i pool replicati si comportano durante il backfill in modo diverso rispetto ai pool erasure‑coded. I pool EC richiedono spesso temporaneamente più I/O e banda di rete per la ricostruzione e sono meno tolleranti a più OSD che cadono contemporaneamente. Pianificate per i pool EC riserve di headroom maggiori e tempi di recovery più lunghi nei vostri SLOs.

Headroom di capacità: non gestite mai Ceph in maniera permanente con un utilizzo molto elevato. Si raccomanda una capacità libera (a seconda del workload) di almeno 10–20 %, affinché il rebalancing e le repliche temporanee trovino spazio. Se gli OSD di destinazione hanno poco spazio libero, il backfill si blocca e i tempi di errore aumentano.

Architettura di rete: separate il traffico Public e Cluster fisicamente o tramite QoS. La saturazione dell’interconnect del cluster è una delle cause più frequenti di backfill lenti. Definite metriche di monitoring per perdita di pacchetti, errori MTU e throughput per OSD e generate allarmi prima che inizi il rebalancing.

Indicazioni di integrazione per l’operazione: collegate i metadati OSD alla vostra CMDB (Host, Slot, numero di serie) e ai vostri strumenti di orchestrazione. Workflow automatizzati per la sostituzione hardware (BMC‑Reboot, Ticketing, Asset‑Update) riducono gli errori negli interventi manuali. Le azioni dell’orchestrator (cephadm) dovrebbero essere registrate nelle change‑pipeline e testate in staging.

Monitoring e automazione: definite soglie di alert chiare (p. es. numero di PG degradati, Recover‑Throughput inferiore al previsto, aumento della latenza OSD). Automatizzate i controlli preflight prima di una sostituzione e uno script di rollback che ripristini tutti i valori di configurazione salvati in precedenza. Eseguite regolarmente la procedura in un ambiente replica — questo riduce gli errori umani in caso di intervento live.

Controllo rapido prima dell’intervento: verificare la topologia CRUSH, considerare il tipo di pool, verificare la capacità libera, controllare lo stato di salute della rete, confermare l’OSD→Hardware‑Mapping nella CMDB. Questi aspetti architetturali e operativi riducono sostanzialmente i tempi di recovery e diminuiscono il rischio di inconsistenze dei dati.

Per questo ambito sono inoltre importanti Ceph Backfill e Ceph Rebalancing. Il contributo inquadra questi aspetti in modo comprensibile e mostra a cosa prestare attenzione nella pratica quotidiana.