Ho montato un cluster ma le macchine non si spostano: quel che manca è lo spazio disco

Hai montato il cluster, i nodi si vedono, nell’interfaccia stanno tutti uno accanto all’altro. Poi provi a spostare una macchina su un altro nodo e non funziona.

Quel che manca non è il cluster, è lo spazio disco.

Ciò che si sposta non è la macchina, è la memoria

Spostare una macchina virtuale in funzione significa copiare lo stato della sua memoria sull’altro nodo. Passa dalla rete ed è veloce.

Ma serve anche il disco della macchina, e il disco è molte volte più grande della memoria. Se il disco sta solo sull’unità del primo nodo, il secondo nodo non ci arriva. La migrazione o non parte mai, oppure deve copiare anche il disco, e allora non si parla più di secondi ma di minuti o addirittura ore.

La risposta sta quindi in una frase: il disco deve essere visibile da entrambi i nodi.

Due modi per ottenerlo

Spazio disco condiviso. Il disco si trova in un posto comune a cui entrambi i nodi si collegano: un archivio di rete, un server di archiviazione o uno strato di archiviazione distribuito. Al momento della migrazione il disco non viene copiato affatto, perché è già lì. È la via più rapida e pulita.

Replica. Il disco resta locale ma viene copiato sull’altro nodo a intervalli regolari. Al momento della migrazione viene inviato solo ciò che è cambiato dall’ultima copia, per questo è veloce. Il prezzo è questo: poiché la copia avviene a intervalli, puoi perdere gli ultimi minuti. In una migrazione pianificata non è un problema, in un guasto improvviso può esserlo.

La domanda che decide quale ti conviene è questa: se un nodo muore all’improvviso, quanti minuti di perdita accetti? Se la risposta è "zero", ti serve spazio disco condiviso. Se la risposta è "qualche minuto va bene", la replica basta ed è molto più economica.

I contenitori non si spostano come le macchine virtuali

È qui che chi monta il primo cluster si sorprende più spesso. Una macchina virtuale si può spostare mentre gira. Un contenitore no: si spegne, si sposta e si riavvia.

Per i tuoi contenitori non esiste quindi una migrazione senza interruzione, nemmeno con un cluster. Non è una mancanza ma la natura del contenitore: una macchina virtuale porta con sé il proprio nucleo, un contenitore usa quello del server, e quel nucleo non può viaggiare.

Conseguenza pratica: tienine conto quando decidi quale lavoro sta in un contenitore e quale in una macchina virtuale. Se un lavoro che non tollera interruzioni sta in un contenitore, quel lavoro si fermerà nelle notti di manutenzione.

Stabilisci l’ordine in anticipo

La notte in cui aggiorni un nodo, le risposte a queste domande devono essere già pronte: quante macchine ci sono su questo nodo, quante si possono spostare, quante devono essere spente e su quale nodo vanno quelle spostabili.

Calcolarlo quella stessa notte è una cattiva idea. Scrivilo una volta e tienilo da parte.

Che cosa fa Atlas

Prima che un nodo venga aggiornato, Atlas elenca le macchine in funzione su di esso e ti propone un ordine di spostamento: quale macchina su quale nodo. La proposta le distribuisce a turno sui nodi disponibili.

La distinzione dei contenitori è fatta qui in modo esplicito. Per le macchine virtuali il metodo proposto è lo spostamento in funzione; per i contenitori la catena spegni, sposta, avvia. Il prodotto non lo presenta come un’opzione, constata che un contenitore non si può spostare altrimenti.

Vengono segnate anche le macchine lasciate alla gestione ad alta disponibilità, perché spostarle a mano e lasciarle alla decisione del gestore sono due cose diverse.

E la proposta resta una proposta: il comando di spostamento non parte da solo, il pulsante lo premi tu.

Un limite onesto: oggi Atlas considera spostabile ogni macchina virtuale in funzione e non verifica se il suo disco sia davvero visibile dall’altro nodo. Il prodotto quindi non risponde alla domanda sullo spazio disco al posto tuo, devi rispondere tu una volta. Leggi la proposta sapendolo.