Emergenza
Se lo storage non risponde e le macchine virtuali sono ferme, al telefono trovate chi ci mette le mani: anche su cluster che non abbiamo installato noi.
Le situazioni in cui conviene chiamare invece di aspettare.
HEALTH_ERR che non si sbloccaDa HEALTH_WARN il cluster si riprende spesso da solo. Da HEALTH_ERR quasi mai: vuol dire che qualcosa impedisce all’I/O di procedere, non solo di essere ottimale. Più resta così, più cresce il rischio che il prossimo evento (un disco, un nodo) non trovi più margine per essere assorbito. Come si legge e da dove si parte.
peering o active+undersizedIn peering quei placement group non servono I/O finché gli OSD coinvolti non si mettono d’accordo su quale sia la copia buona: se dura più di qualche minuto, di solito c’è un OSD che risponde a intermittenza. active+undersized significa che il dato è raggiungibile ma con meno copie del previsto: un secondo guasto, a quel punto, non ha più rete di sicurezza. Quali si possono aspettare e quali no.
Il flapping quasi mai è colpa del disco. Nella maggior parte dei casi è la rete: MTU diverso fra nodi, un link che perde pacchetti sotto carico, o la rete cluster e quella pubblica sullo stesso cavo. Ogni giro di su e giù forza un riequilibrio dei dati, che a sua volta aggrava il carico che ha causato il flapping. Come si riconosce e cosa verificare.
nearfull o fullSu full Ceph blocca le scritture per non rischiare di riempire del tutto un OSD, e con lui l’intero pool. Non è un allarme da rimandare: da nearfull a full possono bastare poche ore se il riequilibrio è già in corso, e a quel punto anche liberare spazio richiede attenzione per non far peggio.
Un recovery lento non è di per sé un’emergenza, ma lo diventa se nel frattempo il cluster è scoperto: meno copie in giro, meno margine per il guasto successivo. Le cause tipiche sono un limite di banda impostato troppo basso, una rete satura, o dischi che non reggono il ritmo delle scritture normali insieme a quelle di recupero.
Senza quorum dei monitor il cluster non prende decisioni: gli OSD restano vivi ma nessuno può dirgli cosa fare, e l’I/O si ferma. Le cause tipiche sono due nodi persi su tre, orologi disallineati fra i monitor, o una partizione di rete che li isola a coppie.
Metà cluster su una versione e metà sull’altra è tollerato per definizione (gli aggiornamenti sono pensati per essere graduali) ma non indefinitamente, e alcune funzioni restano disattivate finché tutto non è allineato. La cosa da non fare è tornare indietro sui componenti già aggiornati: si prosegue, nell’ordine giusto.
Il cluster continua a servire dati anche senza quel nodo, ma ogni minuto in più è un minuto senza le sue copie. Prima di forzare una ricostruzione conviene capire perché non rientra (un disco, la rete, un boot fermo) perché ripartire dal punto sbagliato può costare più tempo di quanto ne faccia risparmiare.
Ceph regge guasti che fermerebbero qualsiasi altro storage, ma quando si degrada le decisioni vanno prese nell’ordine giusto: forzare le cose nella sequenza sbagliata può far perdere i dati che si stavano cercando di salvare. È il momento in cui l’esperienza vale più di qualsiasi manuale.
La prima domanda è una sola: il cluster sta ancora servendo I/O o no. Cambia completamente cosa si può fare senza peggiorare.
Prima si torna a servire i dati, poi si capisce perché è successo. Ogni intervento è un passo misurabile e reversibile: niente comandi che non si possono annullare finché il cluster non è stabile.
A cluster stabile si risale a cosa l’ha rotto (rete, dischi, regole CRUSH, un aggiornamento andato storto) e si sistema, così non succede di nuovo fra due mesi.
È il caso più frequente. Non serve che ci raccontiate com’è stato messo su né perché: quello lo guardiamo noi. Capita spesso di essere chiamati su cluster montati da qualcuno che nel frattempo non c’è più.