Proxmox LXCs vs VMs: Risparmio di Risorse e Maggiore Efficienza

Dalla virtualizzazione completa ai container: ottimizzare le risorse con Proxmox LXC

All'inizio della mia esperienza con Proxmox, la scelta di creare macchine virtuali complete per ogni servizio sembrava la soluzione più sicura. Ogni applicazione aveva il proprio sistema operativo, disco virtuale, allocazione di memoria e un posto ben definito sul server. Questa organizzazione appariva ordinata e, soprattutto, offriva un isolamento adeguato. Tuttavia, con il tempo, mi sono reso conto che diverse installazioni di Linux quasi identiche stavano eseguendo servizi che utilizzavano appena le risorse assegnate. Trasferire questi carichi di lavoro in container Linux, o LXC, ha reso evidente lo spreco di risorse, poiché lo stesso hardware sembrava improvvisamente più veloce, meno affollato e più facile da mantenere.

I container Linux eliminano la duplicazione delle risorse

La maggior parte dei servizi non ha bisogno di una macchina virtuale completa. Servizi come Pi-hole, Uptime Kuma, Homarr e RustDesk sono applicazioni Linux che necessitano di un ambiente stabile, archiviazione e una connessione di rete. Inizialmente, ho assegnato loro interi computer virtuali semplicemente perché era il metodo di distribuzione che conoscevo meglio. Ogni VM aveva il proprio sistema operativo, servizi di background, cache di pacchetti, log di sistema e processo di aggiornamento. Questo significava riservare una quantità significativa di hardware per Linux stesso prima che l'applicazione che mi interessava avesse fatto qualsiasi lavoro.

Gli LXC eliminano gran parte di questa duplicazione condividendo il kernel del host Proxmox, mantenendo i servizi in ambienti utente isolati. Nonostante ciò, ottengo ancora filesystem distinti, indirizzi IP, account utente, limiti di risorse e lavori di backup. Non sto più avviando un altro kernel e un intero sistema operativo per ogni dashboard o strumento di monitoraggio. Una volta visto quanto poco questi container necessitano per funzionare comodamente, le allocazioni che avevo dato alle vecchie VM sono iniziate a sembrare eccessive.

Tempi di avvio più rapidi e manutenzione semplificata

La prima differenza che ho notato non era nascosta in una grafica delle risorse: i container si avviavano molto più velocemente. Una VM doveva completare i controlli dell'hardware virtuale, l'avvio del kernel e l'avvio del sistema operativo prima che il servizio diventasse disponibile. Un LXC era di solito di nuovo attivo prima che avessi il tempo di chiedermi se dovevo aprire la console e controllarlo.

Questa velocità ha cambiato le mie abitudini di manutenzione più di quanto mi aspettassi. Con le vecchie VM, a volte rimandavo un riavvio o una modifica di configurazione perché sapevo che avrei dovuto aspettare che diversi ospiti si spegnessero e tornassero in sequenza. Non era un enorme ritardo, ma era abbastanza attrito da farmi rimandare lavori che avrei dovuto gestire. Con gli LXC, fermare un servizio, cambiare qualcosa e riavviarlo sembra un compito normale piuttosto che un evento di manutenzione minore.

Meno sistemi operativi, meno manutenzione ripetitiva

L'uso inferiore delle risorse era il beneficio più facile da notare, ma la riduzione della manutenzione è ciò che ha reso gli LXC una scelta definitiva. Ogni VM aveva i propri pacchetti del sistema operativo, repository, aggiornamenti di sicurezza e servizi di background. Anche quando diversi ospiti eseguivano la stessa distribuzione Linux, dovevo comunque aggiornare ogni installazione separatamente. Dopo aver eseguito la stessa manutenzione dei pacchetti su macchine quasi identiche alcune volte, la separazione ordinata ha iniziato a sembrare più ripetitiva che utile.

Gli LXC sono la mia scelta predefinita per la maggior parte dei servizi Linux perché si adattano meglio a questi carichi di lavoro. I container non rimuovono completamente quel lavoro: ognuno ha ancora il proprio spazio utente, pacchetti di applicazioni e configurazione. Sono semplicemente ambienti più piccoli con meno software non correlato in esecuzione al loro interno. Gli aggiornamenti terminano più rapidamente, i backup hanno meno dati da spostare e c'è generalmente meno rumore da filtrare quando sto controllando perché un servizio si comporta in modo strano.

Macchine virtuali complete offrono un isolamento più forte

C'è un motivo per cui Proxmox supporta sia LXC che macchine virtuali complete. I container condividono il kernel del host, quindi non possono eseguire un sistema operativo completamente diverso o sostituire liberamente i componenti del kernel. Windows appartiene a una VM, e alcuni carichi di lavoro Linux richiedono anche un controllo del kernel maggiore di quanto un LXC possa offrire comodamente. Questi casi non diventano meno reali solo perché i container sono più efficienti per tutto il resto.

Il confine di sicurezza è diverso. Una VM isola l'ospite dal host dietro l'hypervisor e fornisce il proprio kernel, mentre un LXC si affida a namespaces Linux, permessi e altri meccanismi di isolamento. Utilizzo container non privilegiati dove possibile perché sono il default più sicuro per i servizi che sto eseguendo. Anche allora, non li descriverei come identici alle VM dal punto di vista della sicurezza, perché non lo sono.

Le limitazioni contano meno per i servizi che eseguo effettivamente

Il caso più forte per gli LXC non è che le loro limitazioni siano irrilevanti. È che la maggior parte dei miei servizi Proxmox non le incontra mai. Il mio DNS, i tool di monitoraggio, le dashboard e gli strumenti di accesso remoto non hanno bisogno del proprio kernel. Assegnare a ciascuno una VM ha risolto problemi di isolamento che non avevo realmente, aggiungendo manutenzione che avevo sicuramente.

Non ho cercato di forzare ogni applicazione in un LXC solo per rendere l'ambiente coerente. Jellyfin e i miei servizi di gestione della libreria multimediale vengono ancora eseguiti in Docker sul NAS, vicino allo storage che utilizzano ogni giorno. Questo setup funziona già, e spostare queste applicazioni in Proxmox richiederebbe l'aggiunta di mount di rete, permessi e un'altra dipendenza tra il NAS e il cluster. Cambierei un setup sensato solo per rendere il diagramma più pulito.

Il mio hardware Proxmox ora trascorre più tempo eseguendo servizi utili

Il cambiamento più grande è che non tratto più una macchina virtuale come il punto di partenza automatico per ogni nuova distribuzione. Inizio con il servizio e scelgo il tipo di guest appropriato in base alle sue esigenze specifiche. Gli LXC sono la mia scelta predefinita per la maggior parte dei servizi Linux perché si adattano meglio a questi carichi di lavoro, non perché penso che ogni VM o distribuzione Docker sia sbagliata. Se qualcosa ha bisogno di un kernel separato, un sistema operativo diverso, un isolamento più forte o un passaggio hardware più semplice, utilizzerò una VM. Se appartiene al NAS accanto ai dati che gestisce, la lascio lì.