L'ordine di avvio è un ritardo, non una dipendenza

L'host torna dopo un blackout e metà di ciò che dovrebbe girare non gira. La macchina del database è su, ma l'applicazione davanti ha rinunciato, oppure un contenitore non è riuscito a montare uno storage che un altro contenitore stava ancora avviando. Niente è rotto e nessuno ha registrato un errore che valga la pena leggere. I pezzi sono semplicemente saliti nell'ordine sbagliato.

È qui che la forma della vostra installazione, chi dipende da chi, smette di essere uno schema nella vostra testa e diventa qualcosa che la macchina esegue davvero. Vale la pena sapere con precisione cosa fa quel meccanismo, perché è più stretto di quanto quasi tutti immaginino.

La frase che spiega quasi tutte le sorprese

Il ritardo di avvio è un intervallo, non una condizione.

Quando date un ritardo a un ospite, Proxmox VE avvia quell'ospite, aspetta i secondi indicati e poi passa al successivo. Non controlla se dentro l'ospite l'avvio è finito. Non controlla se un servizio risponde. Aspetta e prosegue.

Quindi l'assetto che avete in mente, "l'applicazione aspetta il database", non è mai ciò che viene configurato. Ciò che viene configurato è "l'applicazione parte novanta secondi dopo che al database è stato detto di partire". In un riavvio di prova tranquillo i due casi sono indistinguibili. Dopo un vero blackout, quando i dischi sono più lenti, gira un controllo del filesystem o un ospite avvia in modalità di ripristino, non lo sono più.

Quattro regole da conoscere prima di mettere numeri

Il più piccolo parte per primo e si spegne per ultimo. L'ordine di spegnimento è l'inverso di quello di avvio; non esiste un'impostazione separata. Un ospite con ordine 1 è il primo su e l'ultimo giù, e di solito è proprio quello che si vuole per la cosa da cui dipende tutto il resto.

I numeri uguali non sono casuali. Gli ospiti con lo stesso ordine vengono inoltre ordinati per identificativo crescente. I pareggi sono quindi stabili e prevedibili, e non serve dare un numero unico a ogni ospite per ottenere un comportamento ripetibile.

Gli ospiti senza ordine partono sempre dopo quelli che ce l'hanno. È più utile di quanto sembri. Non dovete numerare tutto. Numerate le tre o quattro cose che devono davvero essere presto e lasciate stare il resto.

L'ordine vale per un host, non per il cluster. Non può esprimere "questo ospite sul nodo A deve salire prima di quello sul nodo B". Nel momento in cui la dipendenza attraversa un confine di nodo, questo meccanismo non ha nulla da dire.

La trappola che compare dopo

Gli ospiti gestiti dallo stack di alta disponibilità ignorano sia l'avvio automatico sia l'ordine di avvio. La procedura di avvio e arresto li salta del tutto, perché è il gestore di alta disponibilità a decidere quando girano.

Questa morde tardi. Un host singolo con un ordine tarato con cura funziona per un anno. Poi arriva un secondo nodo, alcuni ospiti passano sotto alta disponibilità, e il loro ordine smette silenziosamente di valere. Niente vi avverte, perché niente è sbagliato; è solo cambiata la titolarità.

Il ritardo che volete davvero spesso è un altro

Un motivo comune per ricorrere ai ritardi per ospite è una risorsa esterna: uno storage di rete che deve essere raggiungibile prima che qualcosa lo monti, o uno switch che ha bisogno di un momento. Comprare quel tempo distanziando i singoli ospiti è una via goffa, perché allunga l'intera sequenza.

Esiste un'impostazione separata per nodo esattamente per questo: un ritardo tra la fine dell'avvio dell'host e il primo ospite ad avvio automatico. Un numero solo, applicato una volta, nel punto in cui l'attesa appartiene davvero.

Il numero che nessuno imposta finché non fa male

Il timeout di spegnimento è per impostazione predefinita 180 secondi per ospite. Proxmox VE chiede all'ospite di spegnersi, aspetta, e se allo scadere l'ospite è ancora in esecuzione viene fermato in modo forzato. Un arresto collettivo di tutti gli ospiti ha un proprio limite complessivo di tre minuti prima che accada la stessa cosa.

Per una macchina che scrive su disco durante lo spegnimento, quel tetto merita di essere verificato di proposito e non scoperto durante un guasto. Il valore predefinito è generoso per la maggior parte degli ospiti e troppo corto per alcuni, e quei pochi sono esattamente quelli in cui un arresto forzato vi costa qualcosa.

Cosa si vede davvero in pratica

Sull'host usato per verificare il comportamento descritto qui c'erano nove ospiti configurati e tre impostati per partire all'avvio. Nessuno aveva un ordine di avvio.

È lo stato normale delle cose, e spesso va benissimo. Macchine che non dipendono l'una dall'altra non hanno bisogno di un ordine. Lo scopo di questo testo è più stretto: se avete mai detto ad alta voce che un ospite ha bisogno che un altro sia su per primo, quella frase oggi vive solo nella vostra memoria, e un blackout non legge la vostra memoria.

Cosa fa Atlas

Atlas non riordina niente al posto vostro e non inventa un sistema di dipendenze sopra quello che Proxmox VE ha già. Quello che fa è rendere le relazioni visibili in un'unica immagine invece che un ospite alla volta, così che la domanda "qui che cosa dipende davvero da che cosa" si possa porre mentre la macchina è tranquilla e non mentre sta tornando su.

Vedere la forma non la configura. Ma nessuno imposta un ordine sensato per una disposizione che non ha mai visto disegnata.