La configurazione è diventata di sola lettura: perché il posto dove vive è diverso

Provi a modificare un file e il permesso viene negato. Sei root. Sul disco c'è spazio. Eppure non riesci a scrivere.

Qui non si è rotto nulla. Il posto che stai guardando non è una cartella normale, e rifiuta la scrittura di proposito.

Il posto dove vive la configurazione non è una cartella

Proxmox tiene le configurazioni delle macchine, le definizioni degli storage, le regole del firewall e i lavori di backup in un unico posto. Sembra un filesystem, ha cartelle e file, ma dietro c'è un piccolo database, e quel database viene replicato su ogni nodo del cluster.

Il motivo è semplice: tutti i server di un cluster devono vedere la stessa definizione di macchina. Se vuoi spostare una macchina da un server a un altro, l'altro lato deve già sapere come quella macchina è definita. Se la configurazione fosse un file ordinario sul disco di un server, gli altri non ne saprebbero nulla.

Questo progetto ha tre conseguenze, e tutte e tre compaiono nella vita quotidiana.

Conseguenza uno: senza maggioranza la scrittura viene rifiutata

Se un server non vede la maggioranza del cluster, la scrittura si chiude. La lettura continua, la scrittura si ferma.

Non è un guasto, è una decisione. Se la rete si spezzasse in due e entrambe le metà potessero scrivere, della stessa macchina nascerebbero due definizioni diverse. Al ritorno della rete nessuno saprebbe dire quale sia giusta, e non ci sarebbe modo di unirle. Il sistema sceglie invece questo: il lato rimasto in minoranza smette di scrivere.

Come si conta una maggioranza in un cluster, e perché gli impianti a due server sono scomodi, è trattato in un altro articolo. Qui c'è solo da aggiungere: è esattamente così che quella regola di maggioranza si sente nella pratica, non riuscire più a scrivere all'improvviso.

Conseguenza due: la stessa struttura gira anche su un server solo

Anche senza cluster questa struttura è in funzione. Un server solo è già una maggioranza da sé, quindi normalmente non va storto nulla.

Ma se il servizio che fornisce quella struttura non è in salute, lo stesso sintomo lo vedi anche su un server solo. Quindi "non ho un cluster, a me non può succedere" non è corretto.

C'è anche una strada meno nota: il database dietro questa struttura sta sul disco locale. Quando il disco locale si riempie, le scritture falliscono e a te sembra di non poter cambiare le impostazioni. Il sintomo è dalla parte della configurazione, la causa dalla parte dello storage.

Conseguenza tre: tutto ciò che scrivi lì va a tutti

L'opzione "lo cambio solo su questa macchina" non esiste. Quello che si scrive lì raggiunge ogni nodo del cluster.

L'errore classico, fatto senza saperlo, è apportare una modifica di prova su un nodo dando per scontato che non tocchi gli altri.

Un altro punto: quel posto è stato progettato per la configurazione, non per i dati. I piccoli file di testo ci stanno; script, archivi e backup no. Non prendere l'abitudine di lasciarci dei file.

Se non riesci a scrivere, controlla in ordine

Controlla prima la maggioranza: il server vede il resto del cluster? Se non lo vede, il vero problema è nella rete e il file di configurazione è innocente.

Poi controlla il servizio: il servizio che fornisce questa struttura è in esecuzione?

Poi controlla il disco locale: se è pieno, entra in gioco la strada di sopra.

E l'ultimo, quello saltato più spesso: un nodo potrebbe aver lasciato il cluster. Un'interruzione di rete, un vicino spento, una regola di firewall mal configurata. Il sintomo sembra sempre lo stesso, la causa è ogni volta altrove.

Cosa fa Atlas

Atlas legge questa struttura direttamente come file, invece di eseguire ogni volta lo strumento di interrogazione del sistema.

Abbiamo misurato perché. Ogni chiamata a quello strumento costa tra cento e duecento millisecondi di processore e circa cento megabyte di memoria temporanea. Con il pannello aperto c'è un aggiornamento ogni dieci secondi, e ogni aggiornamento richiede otto o dieci chiamate. In altre parole, il monitoraggio produceva un'oscillazione continua proprio sul server che stava monitorando.

Leggere la stessa informazione da un file richiede microsecondi. Il divario è di migliaia di volte, e quel divario si vede sulla macchina dell'utente come stabilità.

Il secondo dettaglio è più elegante: dentro quella struttura c'è un contatore di cambiamento che avanza ogni volta che la configurazione cambia. Atlas lo osserva. Così, nel momento in cui un'impostazione viene modificata dal pannello, la cache si aggiorna da sola; chiedere di rado e non mostrare mai informazioni stantie diventano possibili insieme.

È un'altra faccia di un principio scritto altrove in questa wiki: ciò che osserva non deve essere ciò che costa. L'errore più facile per uno strumento di monitoraggio è rallentare il sistema che osserva, e così falsare proprio il numero che misura.