Emergenze Ceph
I nomi degli stati si somigliano e significano cose molto diverse. peering spesso si risolve da solo, incomplete quasi mai: la prima cosa da capire è in quale dei due casi siete, perché aspettare è giusto in uno e costoso nell’altro.
Si leggono con ceph pg stat e ceph pg dump_stuck.
peering: si stanno mettendo d’accordoGli OSD coinvolti stanno decidendo quale copia è quella buona. In quei secondi non servono I/O, ed è normale: succede a ogni riavvio di un OSD. Diventa un sintomo se dura più di qualche minuto, e allora quasi sempre c’è un OSD che risponde a intermittenza invece di essere chiaramente vivo o morto.
active+undersized: funziona, ma scopertoIl dato è raggiungibile e le macchine virtuali non se ne accorgono, ma le copie sono meno del previsto. Non è un’emergenza nell’istante in cui accade: lo diventa perché il guasto successivo non ha più rete di sicurezza. Il cluster sta già ricostruendo da solo, se ha dove.
degraded: mancano copie, si sta recuperandoSimile a undersized ma dice qualcosa in più: Ceph conosce le copie mancanti e le sta ricreando. La domanda da farsi è se il recovery sta procedendo o è fermo: un degraded che non cala da ore nasconde un altro problema.
incomplete o down: qui noCeph dice che non ha abbastanza informazioni per servire quei dati: le copie che servirebbero stanno su OSD che non ci sono. Questi PG non si sbloccano aspettando, e sono gli unici in cui una mossa sbagliata fa perdere dati davvero.
Tre comandi che dicono se si può aspettare o se bisogna intervenire.
ceph pg dump_stuck elenca solo quelli fermi, con da quanto tempo lo sono. Un elenco che si accorcia da solo è un cluster che sta lavorando; uno fermo allo stesso numero da mezz’ora no.
ceph pg <id> query sul PG fermo dice quali OSD sta aspettando. È la domanda che conta: se quegli OSD sono spenti ma recuperabili, la risposta è accenderli, non dichiararli persi.
In ceph -s, i numeri di recovering e misplaced letti due volte a distanza di qualche minuto. Se scendono il cluster si sta sistemando da solo, e la cosa giusta è non toccare niente.
Tre situazioni su quattro si risolvono senza comandi irreversibili.
Quasi sempre è lo stesso problema del flapping: un OSD che va e viene impedisce ai PG di chiudere il peering. Si identifica da ceph pg <id> query e si guarda perché risponde a intermittenza, di solito sulla rete. Fermarlo del tutto (ceph osd down) è spesso meglio che lasciarlo oscillare: il cluster smette di aspettarlo e ricostruisce.
Se il recovery procede, la cosa giusta è non fare niente e verificare che ci sia spazio dove ricostruire: un cluster vicino al pieno non ha dove mettere le copie mancanti e resta degradato per sempre. Se il recovery è lento, si alzano i limiti di banda con osd_max_backfills, un passo alla volta, guardando che l’I/O dei client regga.
È la soluzione più semplice e la più trascurata. Un OSD che non parte per un filesystem da controllare o un servizio fermo contiene ancora le copie che servono: recuperarlo chiude i PG senza perdere niente. Vale la pena insistere su questo prima di qualsiasi altra mossa.
incomplete: qui si decide, non si esegueEsistono strumenti per sbloccarli, da ceph-objectstore-tool per esportare e reimportare un PG da un OSD che non parte, fino a dichiarare perse le copie mancanti. Funzionano, e alcuni non si annullano. Quale usare dipende da cosa c’è ancora su quei dischi, e questo si stabilisce prima, non dopo. Se siete arrivati a questo punto, scriveteci prima di eseguire qualcosa: l’ordine conta più del comando.
Ogni riavvio rimette in peering altri PG e toglie copie proprio mentre ne mancano. Se un OSD risponde male va fermato, non riavviato in cerchio.
osd lost perché i PG non si muovonoDice a Ceph di smettere di aspettare le copie di quell’OSD e di accettare quello che resta. Sblocca davvero, e se l’OSD era recuperabile i dati che aveva solo lui non tornano. È l’ultima mossa.
Un pg_num troppo basso è un problema vero, ma alzarlo adesso innesca uno spostamento di dati su un cluster che sta già faticando a tenere le copie che ha. Si fa dopo, a cluster pulito.
Pochi minuti sono normali, soprattutto dopo il riavvio di un OSD o di un nodo. Oltre i dieci minuti sullo stesso PG non è più attesa: c’è qualcosa che impedisce agli OSD di accordarsi, e nella maggior parte dei casi è un OSD che risponde a intermittenza o una rete che perde pacchetti fra due nodi.
Potete, ed è spesso la cosa giusta: il cluster sta ricostruendo da solo. Quello da verificare è che il recovery stia davvero procedendo e che ci sia spazio dove ricostruire. Un cluster che resta undersized per giorni non sta aspettando: è bloccato, e non se ne accorge nessuno finché non si rompe il pezzo successivo.
Non necessariamente, e questa è la ragione per cui conviene fermarsi prima di agire. incomplete dice che Ceph non trova le copie che si aspetta, non che quelle copie non esistono più: molto spesso stanno su un OSD che non parte e che si può ancora leggere. Le mosse che sbloccano velocemente sono anche quelle che rendono definitiva la perdita.
È il caso più frequente. Non serve che ci raccontiate com’è stato messo su né perché: quello lo guardiamo noi.
Fra tutti i sintomi, questo è quello in cui la fretta costa di più: i comandi che sbloccano i PG in fretta sono gli stessi che rendono definitiva una perdita evitabile. Se non è chiaro cosa c’è ancora sugli OSD mancanti, scriveteci prima di eseguire qualcosa.
Sintomi collegati: OSD in flapping,HEALTH_ERRTutti i sintomi di emergenza
