Lo stesso OSD va down e torna up
In ceph health detail compaiono messaggi come osd.4 marked down after no beacon ripetuti nel tempo, e il numero di OSD coinvolti è sempre lo stesso o sempre sullo stesso nodo.
Emergenze Ceph
OSD in flapping: quasi sempre è la rete
Un OSD che entra ed esce dal cluster raramente ha un disco rotto. Nei cluster su cui veniamo chiamati la causa è quasi sempre la rete, e sostituire il disco per primo fa perdere tempo mentre il cluster resta scoperto.
Come si riconosce
Il cluster segnala OSD che cambiano stato da soli, senza che nessuno li abbia toccati.
Lo stesso OSD va
Il recovery riparte ogni volta
A ogni giro il cluster ricomincia a spostare dati. In ceph -s il recovery non arriva mai alla fine: riparte da capo prima di completarsi.
Il disco non ha errori
SMART è pulito, dmesg non riporta errori di I/O, e il disco risponde normalmente quando lo si interroga. È il segnale che il problema sta altrove.
Le tre cause che troviamo più spesso
In ordine di frequenza, su cluster in produzione che non abbiamo installato noi.
MTU diverso fra i nodi
Un nodo configurato a 9000 e gli altri a 1500, o uno switch che non passa i jumbo frame. I pacchetti piccoli passano, quelli grandi no: il cluster sembra funzionare finché il traffico non supera la soglia, poi gli heartbeat si perdono e l’OSD viene dichiarato morto.
Un link che perde pacchetti sotto carico
Un cavo, un transceiver o una porta che degrada solo quando il traffico sale. A riposo il collegamento è perfetto, e proprio il riequilibrio innescato dal flapping porta il carico al punto in cui il link cede: il problema si alimenta da solo.
Rete cluster e rete pubblica sullo stesso cavo
Quando il traffico di replica e quello dei client condividono il collegamento, basta un backup o una macchina virtuale che scrive molto per far ritardare gli heartbeat oltre la soglia. Ceph interpreta il ritardo come un OSD morto.
Cosa guardare, in questo ordine
Tre verifiche che si fanno in pochi minuti e che escludono o confermano la rete prima di toccare i dischi.
L’MTU, da nodo a nodo
Un ping con pacchetto grande e frammentazione vietata: ping -M do -s 8972 <altro-nodo>. Se passa a 1472 ma non a 8972, l’MTU non è coerente lungo il percorso. Va provato fra tutte le coppie di nodi, non solo da uno.
Gli errori sulle interfacce
ip -s link su ogni nodo: contatori di dropped o errors che crescono indicano il collegamento, non il disco. Vanno letti due volte a distanza di qualche minuto, perché quello che conta è se aumentano.
Quali OSD, su quali nodi
ceph osd tree dice se gli OSD che fanno flapping stanno tutti sullo stesso nodo o sullo stesso switch. Se sì, la causa è quasi certamente quel percorso di rete.
Come si corregge
Due delle tre cause si sistemano in pochi minuti, a cluster acceso. La terza richiede di decidere, non solo di eseguire.
MTU: allinearlo su tutti i nodi
Si corregge un nodo alla volta, senza fermare nulla: ip link set dev <interfaccia> mtu 9000 per la prova, poi la stessa riga nella configurazione di rete perché sopravviva al riavvio. Lo switch deve passare i jumbo frame su tutte le porte coinvolte, altrimenti il problema si sposta invece di sparire. Dopo ogni nodo si ripete il ping con pacchetto grande: se passa, quel percorso è a posto.
Link che perde pacchetti: sostituire il pezzo
Cavo, transceiver o porta dello switch, in quest’ordine di probabilità. Si mette il nodo in noout, si sostituisce, si toglie noout e si guardano i contatori di ip -s link per qualche ora sotto carico. Se tornano a salire, il pezzo era un altro: si prosegue con il successivo invece di tornare indietro.
Rete cluster e pubblica da separare: qui si decide
La correzione è nota (una rete dedicata per la replica, dichiarata in cluster_network) ma farla su un cluster che sta servendo dati non è un comando: è una sequenza. In che ordine toccare i nodi, se fermare il riequilibrio prima o lasciarlo correre, cosa fare se a metà strada un OSD non rientra. Sbagliare l’ordine su un cluster già scoperto costa più del problema che si stava risolvendo. Se siete a questo punto e il cluster ha già meno copie del previsto, scriveteci prima di iniziare: mezz’ora con chi l’ha già fatto costa meno di un recovery andato storto.
Cosa non fare
Sostituire il disco per primo
Se la causa è la rete, il disco nuovo farà flapping come il vecchio. Nel frattempo il cluster ha perso una copia in più e il riequilibrio aggiunge carico proprio sul collegamento che sta cedendo.
Alzare le soglie per far smettere gli allarmi
Allungare i tempi di heartbeat fa sparire il sintomo e lascia il problema. Un cluster che non dichiara morto un OSD davvero irraggiungibile smette di proteggere i dati, che è l’unica cosa per cui esiste.
Lasciare noout e dimenticarsene
Impostare noout è giusto per fermare il riequilibrio mentre si indaga, ed è il primo comando che diamo anche noi. Diventa un problema se resta impostato: il cluster smette di reagire ai guasti veri, e quello successivo non viene assorbito.
Domande frequenti
Il flapping può essere davvero il disco?
Può, ed è il caso meno frequente. Succede con dischi che rispondono con latenze molto alte senza dare errori: l’OSD non muore ma non risponde in tempo agli heartbeat. Si riconosce perché gli OSD coinvolti sono sparsi su nodi diversi invece di concentrarsi su uno, e perché le latenze sono alte anche a cluster fermo.
Quanto è urgente?
Dipende da quante copie restano. Con tre repliche e un OSD che fa flapping il dato è ancora protetto, ma ogni giro consuma banda e allunga il recovery. Con due copie, o con un secondo OSD già fuori, è un’emergenza: il margine per il guasto successivo non c’è più.
Si risolve senza fermare il cluster?
Quasi sempre sì. Correggere un MTU o spostare la rete cluster su un collegamento dedicato si fa a cluster acceso, un nodo alla volta. Fermare tutto serve raramente, e quando serve è perché il flapping ha già portato dei placement group fuori servizio.
Intervenite anche su cluster che non avete installato voi?
È il caso più frequente. Non serve che ci raccontiate com’è stato messo su né perché: quello lo guardiamo noi.
Se sta succedendo adesso
ContattaciUn OSD che fa flapping non ferma il cluster, ma lo lascia scoperto finché continua. Se non riuscite a isolare la causa, scriveteci: queste situazioni le abbiamo già viste, anche su cluster che non abbiamo installato noi.
