Una sola macchina, due filosofie: la fondazione deve essere lo storage o la virtualizzazione?

Chi ha un solo server e più compiti prima o poi arriva a questo bivio. Da una parte i sistemi costruiti attorno a un insieme di dischi, dove far girare macchine virtuali è una funzione. Dall'altra i sistemi costruiti attorno a un hypervisor, dove lo storage è un sottosistema. Funzionano entrambi. C'è chi è contento da entrambe le parti.

La domanda utile non è quale sia migliore. È: quale strato volete sotto l'altro, perché è questo a decidere cosa potrete sostituire più avanti senza ricostruire la macchina.

Cosa significa qui "fondazione"

La fondazione è lo strato che continua a funzionare mentre si lavora sull'altro. Tutta la differenza sta lì, ed è facile perderla mentre si confrontano elenchi di funzioni.

Se la fondazione è lo storage, l'insieme sopravvive ai vostri esperimenti con i servizi. Potete rompere un contenitore alle due di notte e i vostri file restano intatti, perché ciò che li tiene non è mai stato coinvolto.

Se la fondazione è l'hypervisor, le macchine sopravvivono ai vostri esperimenti con lo storage. Potete aggiungere un pool, spostare un disco, sostituire un supporto, e le macchine proseguono finché i loro dischi restano raggiungibili.

Nessuno dei due ordini protegge entrambe le cose. State scegliendo quale deve essere la cosa noiosa e stabile.

La domanda che decide davvero

Non "cosa voglio far girare", perché entrambe le risposte fanno girare tutto. Chiedetevi invece: a cosa serve questa macchina nel suo giorno peggiore?

Se la risposta onesta è "tiene cose che non posso perdere, e fa girare anche qualche servizio", la fondazione vuole essere lo storage. Il lato virtualizzazione sarà sufficiente e non profondo, ed è il compromesso giusto perché il punto è l'insieme di dischi.

Se la risposta onesta è "fa girare cose da cui dipendono delle persone, e conserva anche i loro dati", la fondazione vuole essere l'hypervisor. Lo storage arriverà come pezzi invece che come prodotto finito, e anche questo è il compromesso giusto perché il punto è la continuità dei servizi.

La maggior parte delle delusioni nasce da chi sceglie la seconda risposta aspettandosi l'esperienza di storage del primo sistema. O viceversa.

Cosa costa davvero ciascuna parte

Prima l'insieme di dischi. Il lato virtualizzazione è reale ma meno profondo. Integrazione degli snapshot con l'ospite, migrazione a caldo, pianificazione dei backup per singola macchina e passaggio dell'hardware esistono in misura diversa, e tutto questo è più facile dal lato hypervisor. Se le vostre macchine virtuali sono due scatole di servizio, non ve ne accorgerete mai. Se sono otto servizi di produzione, ve ne accorgerete.

Prima l'hypervisor. Lo storage arriva a pezzi, non come prodotto finito. Scegliete una disposizione, decidete la ridondanza, impostate verifiche e monitoraggio, e da nessuna parte compare una procedura guidata gentile che vi offra di "creare una condivisione". La flessibilità è reale, e lo è anche il tempo di montaggio.

⚠️ Entrambe le parti rendono costoso un riavvio, e questo sorprende chi credeva che la scelta dischi-prima lo evitasse. Un aggiornamento del kernel ferma la macchina in ogni caso, con tutto quello che ci sta sopra. La fondazione riguarda ciò che sopravvive alle vostre modifiche, non ciò che sopravvive a un riavvio.

L'ibrido e il guasto che aggiunge

Una disposizione molto comune: l'hypervisor come fondazione, e sopra un sistema orientato allo storage come macchina virtuale, con i dischi passati direttamente.

Funziona, è diffusa, e dà davvero entrambe le esperienze. Ma introduce una dipendenza che prima non c'era: i vostri file ora richiedono che una macchina virtuale si avvii. Se non si avvia, lo storage non è soltanto lento, è assente, e tutto ciò che monta una condivisione da lì cade nello stesso momento.

È un compromesso accettabile se sapete di farlo. Diventa una brutta sorpresa se scoprite la dipendenza durante un disservizio. Due abitudini lo rendono sicuro: tenere il disco di avvio dell'hypervisor del tutto separato dai dischi passati, e assicurarsi che almeno una via di ripristino non passi da quella macchina.

Cosa non decide

I numeri grezzi di prestazione. Su una sola macchina i due approcci poggiano sullo stesso hardware, e la differenza pratica di solito è minore di quella tra due disposizioni di storage sullo stesso sistema.

Quale si installa più facilmente. L'installazione avviene una volta. Ciò con cui convivete è il secondo anno, quando dovete cambiare qualcosa.

Quale è più popolare per il vostro uso. Una configurazione ben compresa che sapete riparare batte una migliore che non sapete riparare.

Cosa fa Atlas

Atlas non trasforma Proxmox in un apparato di storage e non finge che il passaggio di montaggio sparisca. Quello che fa è rendere leggibile il risultato montato, ed è proprio lì che il lato hypervisor è più duro.

La catena delle risorse viene disegnata da ogni macchina fino al disco fisico, così la disposizione che avete montato diventa un'immagine visibile invece di una decisione ricordata. Dal lato dischi quell'immagine è implicita perché l'insieme è il prodotto; qui va mostrata, e mostrarla è il punto.

Le operazioni di storage passano da un flusso guidato con anteprima e via di ritorno, su ZFS, LVM e Btrfs. Questo non sceglie al posto vostro, e non è pensato per farlo: rende ispezionabile a posteriori la scelta che avete fatto, ed è quella parte a decidere come andrà il secondo anno.