Stefano Marinelli's Blog (Articoli su linux)

Backup efficienti di container LXC in Proxmox - ZFS

Stefano Marinelli — Wed, 18 Jan 2023 08:34:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente in inglese sul blog it-notes. L'originale sarà sempre più aggiornato.

Ho già scritto relativamente ad alcune delle mie strategie di backup in Proxmox. Proxmox Backup Server è un valido strumento, ma non è sempre l'opzione migliore, soprattutto se si utilizzano container lxc.

I container LVM e Ceph RBD sono già stati trattati in un altro post, ma una delle (molte) ottime opzioni, se si usa Proxmox, è ZFS. Utilizzo ampiamente ZFS sia su FreeBSD che su Linux (e ho sempre desiderato che BTRFS potesse raggiungere lo stesso livello di affidabilità).

Quando non ho bisogno di un file system in rete (come Ceph) o voglio superare i limiti di LVM, tendo a installare le VM di Proxmox e i container lxc su ZFS. Concentriamoci ora sul backup dei container lxc.

Proxmox utilizza i dataset ZFS per lo storage dei container lxc, quindi tutti i file si trovano su /nome-pool/subvol-x-disk-y. Possiamo eseguire facilmente il backup come abbiamo fatto nel mio precedente articolo, abbiamo solo bisogno di un modo diverso per eseguire le snapshot di tutti questi dataset.

I dataset ZFS forniscono una directory .zfs, nascosta, che contiene tutte le istantanee attualmente esistenti di quel dataset specifico. "ls" non la mostrerà, ma si può fare un "cd" e sarà utilizzabile.

Naturalmente si può usare zfs send/receive in maniera nativa (o un utile software che uso quotidianamente, zfs-autobackup, sia per le istantanee locali che per la replica remota), ma vogliamo salvare i file, non il dataset zfs, in modo da poter eseguire il backup su un file system diverso. Qualsiasi file system. Quindi useremo borg backup.

Supponiamo che il nostro pool ZFS sia chiamato "proxzfs". Ecco uno script di esempio. Naturalmente, questo è il mio script, funziona per me e non sono responsabile se non funziona per voi/distrugge tutti i vostri dati/mangia il vostro server/ecc.

#!/bin/bash

/usr/sbin/zfs snapshot -r proxzfs@forborg

REPOSITORY=yourpath/server/whatever:borgrepository/
TAG=mytag
borg create -v --stats --compression zstd --progress    \
   $REPOSITORY::$TAG'-{now:%Y-%m-%dT%H:%M:%S}'          \
   /proxzfs/*/.zfs/snapshot/forborg/  \
   --exclude '*subvolYouMayWantToExclude-disk-0*'

/usr/sbin/zfs destroy -vrR proxzfs@forborg

borg prune -v $REPOSITORY --stats --prefix $TAG'-' \
   --keep-daily=31 --keep-weekly=4 --keep-monthly=12

Questo piccolo script creerà un'istantanea @forborg per qualsiasi dataset che troverà sotto "proxzfs", quindi avvierà borg e gli chiederà di attraversare le snapshot forborg montate automaticamente all'interno della directory .zfs di qualsiasi dataset.

Quindi distruggerà le istantanee "forborg" ed eseguirà un prune di borg. Questo eliminerà i vecchi backup, in base alla politica impostata. Questo passaggio può essere evitato, ma io preferisco eseguirlo dopo un backup, in modo che il mio repository sia sempre coerente con la mia politica di data retention.

Come riavviare macchine Linux o FreeBSD con storage inchiodato

Stefano Marinelli — Wed, 11 Jan 2023 06:25:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente in inglese sul blog it-notes. L'originale sarà sempre più aggiornato.

A volte il filesystem si blocca. Non è possibile eseguire alcuna operazione e un "riavvio" causerà solo un tempo di attesa indefinito per l'I/O. È possibile accedere al server tramite ssh (o login tramite console), ma non è possibile eseguire alcuna operazione perché i dispositivi di archiviazione sono bloccati. Questo può accadere a causa di un problema sul file system o di uno strano bug del kernel. È più probabile che questo accada quando si ha a che fare con interfacce esterne collegate via usb.

Esiste un codice "magico" che attiva una condizione specifica del kernel e causa un riavvio.

Attenzione, questi comandi devono essere considerati come l'ultima risorsa. Non verrà eseguito il flush del disco, né verrà avviata la procedura di spegnimento, per cui si rischia di distruggere completamente il file system o qualsiasi file aperto.

Tuttavia, questa potrebbe essere l'opzione migliore che avete a disposizione e non sarà più dannosa di un hard reset o di un "tradizionale" cable pull - ma potete farlo da remoto.

Ricordate di lanciare i comandi con i privilegi di root:

Su Linux:

echo b > /proc/sysrq-trigger

In questo modo si attiverà un riavvio immediato - non verranno eseguite ulteriori operazioni sul disco.

Su FreeBSD:

sysctl debug.kdb.panic=1

Verrà generato un kernel panic che (per impostazione predefinita) causerà un riavvio.

Perché stiamo migrando (molti dei nostri) server da Linux a FreeBSD

Stefano Marinelli — Sat, 22 Jan 2022 16:25:19 GMT

An English version of this article (and following about the same topic, not available in Italian) may be found here

Sono un utente Linux (o GNU/Linux, per i puristi) dal 1996. Sono un utente FreeBSD dal 2002. Ho sempre utilizzato con successo entrambi i sistemi operativi, ognuno per specifici scopi. Ho trovato, in media, i sistemi BSD più stabili rispetto agli equivalenti Linux. Per stabilità non intendo l’uptime (troppo uptime vuol dire pochi aggiornamenti di sicurezza del kernel, il che è sbagliato). Intendo che le cose funzionino come devono, che non si “rompano” da un aggiornamento all’altro e che non si renda necessario rivedere tutto per colpa di un comando base sparito o modificato.

Sono sempre stato a favore dello sviluppo e dell’innovazione a patto che essa non renda (necessariamente, automaticamente e immotivatamente) incompatibile tutto ciò che è già in essere. E la strada che le varie distribuzioni di Linux stanno prendendo sembra proprio quella del modificare cose che funzionano solo per il gusto di farlo oppure per seguire i diktat del Kernel e di chi lo gestisce - ma non solo.

Già da un po’ di tempo ho iniziato un’operazione complessa, continua e non sempre lineare ovvero quella di migrare, ove possibile, buona parte dei server (nostri e dei nostri clienti) da Linux a FreeBSD.

Perché proprio FreeBSD?

Ci sono molti sistemi operativi alternativi a Linux e la famiglia dei *BSD è variegata e completa. FreeBSD, a mio avviso, è ad oggi il sistema “all rounder” per eccellenza, ovvero ben rifinito e adatto sia all’utilizzo su grossi server che su piccoli sistemi embedded. Gli altri BSD hanno punti di forza che, in alcuni campi, li rendono particolarmente adatti ma FreeBSD, a mio avviso, è adatto (quasi) ad ogni scopo.

Tornando dunque all’argomento principale dell’articolo, perché sto migrando molti dei server che gestisco a FreeBSD? Le ragioni sono molte, ne elencherò alcune con le relative spiegazioni.

Il sistema è coerente - kernel e userland sono creati e gestiti dallo stesso gruppo

Uno dei problemi alla base di Linux è che (ricordiamolo) è un kernel, tutto il resto viene creato da persone/aziende diverse. In più di una occasione Linus Torvalds nonché altri tra i principali sviluppatori del kernel Linux hanno rimarcato che a loro interessa lo sviluppo del kernel stesso, non come gli utenti lo utilizzeranno. Nelle scelte tecniche, dunque, non si tiene conto di quello che è il reale utilizzo dei sistemi ma che il kernel vada per la sua strada. Questo è un bene, in quanto lo sviluppo del kernel Linux non viene “frenato” dalla lotta tra le distribuzioni e soluzioni software presenti, ma allo stesso tempo è anche uno svantaggio. In FreeBSD, kernel e relativo userland (dunque tutti i componenti del sistema operativo base) vengono sviluppati dallo stesso team e c’è, dunque, una forte coesione tra le parti. In molte distribuzioni Linux c’è stato bisogno di “deprecare” ifconfig a favore di ip in quanto nuovi sviluppi avvenuti nel kernel non erano più sfruttabili da ifconfig, a meno di romperne la compatibilità con le altre (precedenti) versioni kernel oppure avere funzioni (sulla stessa interfaccia di rete) gestite da tool diversi. In FreeBSD ad ogni release del sistema operativo ci sono sia kernel che userland aggiornati per cui queste modifiche vengono coerentemente inserite e documentate, rendendo i tool compatibili con i relativi aggiornamenti lato kernel.

In parole povere, in FreeBSD non c’è bisogno di “rivoluzionare” tutto ogni pochi anni e le modifiche vengono fatte principalmente sotto forma di aggiunte in grado di arricchire (e non di rompere) ogni aggiornamento. Se una modifica dovesse cambiare il modo di interfacciarsi ai dispositivi di rete, ifconfig verrebbe modificato per trarne beneficio e restare compatibile con la “vecchia” sintassi. A lungo termine, questo tipo di approccio viene decisamente apprezzato dagli amministratori di sistema che si trovano ad avere un percorso di aggiornamenti lineare, coerente e sempre ben documentato.

Lo sviluppo di FreeBSD è (ancora) guidato da interessi tecnici, non strettamente commerciali

Linux e relative distribuzioni hanno ormai contributi da moltissime imprese, molte delle quali (ad esempio: Red Hat) spingono (giustamente) nella direzione di ciò che sia comodo per loro, loro prodotti e loro servizi. Essendo grossi contributori del progetto hanno un grosso peso per cui, di fatto, le loro soluzioni diventano spesso degli standard de-facto. Si pensi a systemd - c’era davvero bisogno di un sistema del genere? Pur apportando alcuni vantaggi, ha aggiunto una certa complessità ad un sistema altrimenti estremamente semplice e funzionale. E’ tutt’ora divisivo e molti si chiedono: “ma era davvero necessario? I vantaggi portati hanno bilanciato gli svantaggi?”. 70 file binari solo per inizializzare e loggare e un milione e mezzo di righe di codice solo per questo? Ma Red Hat ha lanciato il sasso…e molti si sono accodati. Perché a volte è bello seguire la mode, l’hype di una specifica soluzione.

Anche FreeBSD ha grosse realtà dietro, che collaborano in maniera più o meno diretta. La licenza è più permissiva, dunque non tutti coloro che lo utilizzano in maniera commerciale poi contribuiscono, ma sapere che FreeBSD è alla base delle CDN di Netflix, dei server di Whatsapp (in attesa che Meta li sostituisca, per ragioni di coerenza interna, con server Linux), delle Sony Playstation e, in parte, di MacOS, iOS, iPadOS, ecc. sicuramente fornisce rassicurazioni sul suo livello. Queste realtà, però, non hanno un peso tale da guidare lo sviluppo del team principale.

Linux ha Docker, Podman, lxc, lxd, ecc ma… FreeBSD ha le jail!

Le jail di FreeBSD sono potentissimi strumenti per inscatolare e separare i servizi. Ci sono polemiche sul fatto che Docker non giri su FreeBSD ma io credo (come molti) che FreeBSD abbia uno strumento più potente. Le jail sono più vecchie e mature - e di molto - rispetto qualunque soluzione di containerizzazione su Linux. Le jail sono efficienti e sono ben integrate in tutto il sistema operativo. Tutti i principali comandi (ps, kill, top, ecc.) sono in grado di mostrare anche le informazioni relative alle jail. Ci sono molti strumenti di gestione ma, di fatto, tutti fanno la stessa cosa: si interfacciano con FreeBSD base e creano dei file di configurazione su misura. Personalmente mi trovo molto bene con BastilleBSD ma ci sono molti strumenti decisamente validi, nonché una sufficientemente semplice gestione manuale. Quando ho bisogno di Docker lancio una macchina Linux - spesso Alpine, che ritengo essere un’ottima distribuzione minimalista, oppure Debian. Ma sto spostando molti servizi da docker ad una jail dedicata su FreeBSD. I container Docker sono un ottimo strumento di distribuzione rapida (e coerente) di software, ma non sono tutte rose e fiori. I container, ad esempio, si basano su immagini che a volte invecchiano e non vengono più aggiornate. Questo è un problema di sicurezza da non trascurare.

Linux ha ext4, xfs, btrfs… (e zfs, ma con qualche intervento manuale). FreeBSD ha UFS2 e ZFS

UFS2 è un file system ancora molto valido ed efficiente e, configurato per usare i softupdates, in grado di effettuare live snapshot del file system. Questo è ottimo per i backup. Ext4 e XFS non supportano snapshot se non attraverso strumenti esterni (come DattoBD o snapshot attraverso il volume manager). Tutto ciò funziona, certo, però non è nativo. Btrfs è ottimo nelle intenzioni ma non è ancora così stabile come dovrebbe essere dopo tutti questi anni di sviluppo. FreeBSD supporta ZFS in maniera nativa nel base system e questo porta molti vantaggi: separazione dei dataset per le jail, nonché i Boot Environment, per fare delle snapshot prima di aggiornamenti/modifiche e poter fare il boot (da bootloader) anche su un BE differente, ecc.

La procedura di boot di FreeBSD è più semplice e lineare

Linux usa da sempre ottimi strumenti come grub, lilo (oggi ormai superato), ecc. FreeBSD da sempre utilizza un sistema molto lineare e coerente di boot, con il suo bootloader e la sua partizione dedicata di boot. Che sia su mbr, gpt, ecc. le cose sono molto simili e coerenti. Non ho mai avuto problemi a far fare boot ad un sistema FreeBSD dopo uno spostamento o recupero da backup. Su Linux, invece, a volte grub mi ha dato noie, anche dopo un semplice aggiornamento di sicurezza del kernel.

Lo stack di rete di FreeBSD è (ancora) superiore a quello di Linux - e, spesso, lo sono anche le sue prestazioni

Meta, da anni, sta cercando di portare le prestazioni dello stack di rete di Linux a livello di quello di FreeBSD. Molti si chiederanno perché, allora, non spostare i servizi su FreeBSD. Grosse aziende con enormi datacenter non possono cambiare soluzione da un giorno all’altro e i loro tecnici, a qualunque livello, sono esperti Linux. Hanno investito molto su btrfs, su Linux, sulle loro peculiarità. Chiaramente, all’acquisizione di Whatsapp, hanno preferito migrare i “pochi” server di Whatsapp a Linux e spostarli nei loro datacenter. In merito alle reali prestazioni di sistema (ovvero trascurando i benchmark, utili solo fino ad un certo punto), FreeBSD brilla, specialmente in condizioni di alto carico. Dove Linux inizia a boccheggiare (es: in attesa di I/O) con il 100% di CPU, FreeBSD ha un carico di processore più basso e spazio per altre cose. Nel mondo reale (dei miei server e tipi di carico), ho a volte riscontrato dei forti rallentamenti di sistema a causa di un forte I/O, anche sei i dati da processare non dipendevano da letture/scritture. Su FreeBSD ciò non accade e se c’è qualcosa di bloccante, blocca QUELLA operazione, non il resto del sistema. Durante lo svolgimento dei backup o di altre operazioni importanti questo fattore diventa estremamente importante per garantire prestazioni adeguate (e stabili) di sistema.

Semplicità nell'analisi delle prestazioni di sistema

FreeBSD, nel base system, ha tutti gli strumenti per analizzare eventuali problemi e carichi della macchina. “vmstat” , in una riga, mi dice se la macchina sta faticando per CPU, per I/O o per Ram. “gstat -a” mi mostra quanto, disco per disco, partizione per partizione, sia attivo lo storage, anche in percentuale rispetto alle sue prestazioni. “top”, poi, ha anche il supporto per capire, processo per processo, quanto I/O venga utilizzato (opzione “m”). Su Linux, per ottenere gli stessi risultati, bisogna installare applicazioni specifiche, diverse da distribuzione a distribuzione.

Bhyve è più incompleto (ma più prestante) di KVM

Per i miei utilizzi, Bhyve è un ottimo strumento di virtualizzazione. KVM è decisamente più completo ma non avendo esigenze particolari e specifiche non coperte da Bhyve su FreeBSD, con questa combinazione ho trovato (mediamente) prestazioni migliori. Su FreeBSD manca però il KSM che, in alcuni casi, è molto utile.

Abbandonerò dunque Linux per FreeBSD? Ovviamente no, così come non l’ho fatto negli ultimi 20 anni. Entrambi hanno i loro utilizzi, il loro spazio, i loro punti di forza. Però se fino ad oggi ho avuto un 80% Linux e 20% FreeBSD, la prospettiva è quella di invertire le percentuali di utilizzo e, ove possibile, implementare direttamente soluzioni basate su FreeBSD.

Backup efficienti di container LXC in Proxmox (e non solo)

Stefano Marinelli — Thu, 10 Sep 2020 12:25:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente sul blog it-notes. L'originale sarà sempre più aggiornato.

A volte un container lxc può essere un'alternativa più valida rispetto ad ad una macchina virtuale KVM. Ha un overhead inferiore, una gestione delle risorse più semplice ed efficiente e un minore impatto sulla macchina fisica.

Continua la lettura… (ulteriori 4 minuti di lettura)

Proxmox Backup Server - Consigli per una buona implementazione

Stefano Marinelli — Mon, 31 Aug 2020 10:25:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente sul blog it-notes. L'originale sarà sempre più aggiornato.

Proxmox Backup Server (PBS) è stato rilasciato. È ancora in beta ma è già perfettamente utilizzabile. Dopo molti anni, è ora possibile eseguire backup incrementali delle VM e grazie alle dirty bitmap di qemu, i backup sono anche veloci.

Continua la lettura… (ulteriori 1 minuti di lettura)

BTRFS: effettuare automaticamente snapshot e backup remoti

Stefano Marinelli — Wed, 04 Sep 2019 10:40:19 GMT

Utilizzo con soddisfazione BTRFS (ne ho parlato nel 2014 e, più recentemente, nel blog IT-Notes). Non lo considero ottimale per tutti i tipi di carico, ma risolve molti problemi in moltissime situazioni. Una delle cose che utilizzo con più soddisfazione è la funzione di generazione dinamica di snapshot, che garantisce la possibilità di avere una copia perfetta e immediata di uno specifico volume (o subvolume). Quando è necessario un backup, ad esempio, l'utilizzo delle snapshot è fondamentale e averle a livello di file system è senza dubbio un buon ausilio.

Quando si tratta di volumi BTRFS, però, abbiamo ulteriori opzioni. Ci sono strumenti nativi che sono in grado di inviare e ricevere dati da e verso volumi BTRFS in maniera ottimizzata, sfruttando le caratteristiche intrinseche del file system stesso. Ecco dunque un metodo per fare automaticamente delle snapshot e trasferirle, in maniera ottimale, su un altro volume BTRFS (locale o remoto).

Continua la lettura… (ulteriori 2 minuti di lettura)

Docker: come limitare la crescita incontrollata dei log dei container

Stefano Marinelli — Wed, 28 Aug 2019 07:10:13 GMT

(English version, Rotating Docker log files available on IT-Notes blog)

Ho già scritto in merito al fatto che io apprezzi Docker come soluzione per il deploy di specifici servizi. Invece che "sporcare" le singole distribuzioni e dover tenere tutto aggiornato alle versioni delle stesse, si può avere un sistema pulito, replicabile, aggiornabile rapidamente.

Uno dei problemi che ho riscontrato è però questo: quando si hanno dei container che non vengono aggiornati spesso (o, meglio, ricreati spesso), il loro output continua ad accumularsi in un file di log legato al container stesso. Alla fine si rischia di trovarsi con un log enorme e nessuna cognizione di come ridurne le dimensioni.

Continua la lettura… (ulteriori 1 minuti di lettura)

Alla Ricerca del Backup Perfetto: Borg e Restic

Stefano Marinelli — Wed, 23 May 2018 07:42:37 GMT

English version here

Backup: tecniche principali

In passato ho già affrontato l'argomento backup ponendo alcune basi e dando alcune indicazioni sulle principali modalità e sul perché è fondamentale farlo, sul perché il RAID non può essere considerato una forma di backup e su alcuni software da me presi in esame e utilizzati in precedenza. Invito dunque a leggere l'articolo collegato, per una base di partenza. Questa volta, però, daro delle guide su come io realizzo i backup e su come io riesca a garantire un certo grado di sicurezza.

Backup: le basi di partenza

Proporrò l'argomento sotto forma di elenco puntato, onde coprire le principali problematiche da gestire:

Sistema Operativo e dati da salvare: ogni sistema operativo è un universo. E' ragionevole pensare che non esista una soluzione universale, anche se molti dei principali software open source sono multi-piattaforma. Il principale divario è tra i sistemi Unix-Like (GNU/Linux, BSD, MacOS, ecc.) e Windows. Lo stesso software, pur essendo disponibile per più piattaforme, potrebbe non essere il migliore per la propria o per le proprie necessità.
Tipo di dati da salvare: ogni tipo di backup richiede soluzioni diverse. Ci sono situazioni in cui si ha la necessità di copie pressoché sempre incrementali in quanto i file crescono ma non vengono modificati. In questo caso, un qualunque sistema appunto incrementale (es: Duplicity ) può essere sufficiente. Nel caso, invece, di backup sempre diversi (es: un database che cambia costantemente), un sistema come quello precedente può essere estremamente inefficiente, specialmente nel lungo periodo.
Necessità di crittografia o meno: i backup delle mie fatture, ad esempio, potrei anche evitare di crittarli...
Rapidità di esecuzione e di recupero: ci sono strumenti che sono estremamente efficienti nell'effettuare l'operazione di copia, ma che rendono estremamente lento il recupero. Una delle (poche) carenze da me riscontrate in BURP Backup, di cui ho parlato nell'articolo precedente e che utilizzo ancora con successo in certe situazioni, è che richiede il restore dei file e non consente, per lo meno direttamente, di navigare nel backup come fosse un file system locale. Stesso discorso vale, ad esempio, per il backup nativo di Proxmox: è comodissimo da impostare, completo e nativo ma il tempo di recupero può essere importante, specialmente se effettuato in postazioni remote e su connessioni lente. Recuperare un file richiederà, molto spesso, il recupero totale della macchina.
Snapshot: ultima in lista, ma questione di primaria importanza. Un backup di un file system "live" avrà un momento di inizio e un momento di fine. Nel frattempo, i dati cambieranno all'interno di esso e potrebbe generarsi incoerenza. In passato ho avuto problemi del genere: un database (mysql) di qualche GB è stato rovinato da un cliente e me ne è stato chiesto il recupero. Ho preso, con baldanza, l'ultimo backup e ho ripristinato i vari file (non un dump). Inutile dire che è stato impossibile farlo ripartire: il file molto grande era cambiato troppo tra l'inizio del backup dello stesso e la fine, per cui era incoerente. Per i maliziosi: avevo anche il dump, ovviamente, per cui ho recuperato quello. Ma la questione resta chiara: fare un backup di un file system live è pericoloso, a meno che non si stia copiando la cartella "Documenti" o "Immagini". Un database aperto, come anche semplicemente quello del browser, ha altissime probabilità di corrompersi e rendere inutile la copia di sicurezza fatta. La tecnica è fare uno snapshot dell'intero file system prima di iniziare la copia. Ci sono margini di rischio anche in questo (il backup avrà all'incirca lo stesso stato che avrebbe la macchina se venisse improvvisamente staccata la spina), ma largamente inferiori. Ad oggi, utilizzando snapshot, sono stato in grado di recuperare tutto.

Continua la lettura… (ulteriori 9 minuti di lettura)

Docker e la nuova separazione dei servizi

Stefano Marinelli — Tue, 03 Apr 2018 17:45:46 GMT

Se c'è una cosa che mi piace, nell'ambito informatico, è il trovare nuove soluzioni a vecchi problemi. O nuovi problemi a vecchie soluzioni, ma allo scopo di risolvere eventuali punti lasciati in sospeso da tempo, per mancanza di tempo o per mancanza di soluzioni a disposizione.

Una delle questioni più annose, per chi lavora nel settore (ma non solo) è sempre la vecchia scelta operativa: accentrare i servizi su un server o separarli il più possibile?

Continua la lettura… (ulteriori 2 minuti di lettura)

Un assaggio di Proxmox

Stefano Marinelli — Mon, 28 Aug 2017 12:22:14 GMT

Proxmox, la storia

Proxmox nasce nel 2008 come sistema completo di virtualizzazione (alternativo a prodotti come VMWare) "a pacchetto". Lo scopo è sempre stato, ed è ancora, quello di fornire un sistema semplice e pratico di preparazione di hardware fisico allo scopo di ospitare macchine virtuali, il tutto gestito attraverso una comoda interfaccia web.

Fino alla versione 3.0, Proxmox ha sofferto di serie problematiche di gioventù. Pur essendo, infatti, già sufficientemente maturo, c'erano alcuni problemi (bug o mancanza di feature) che non lo rendevano estremamente adatto ad ambienti di produzione importanti. Dalla 3.0 in poi, invece, si è assistito al lancio verso l'olimpo in quanto le funzionalità di base erano ormai mature e affidabili e le nuove opzioni erano tutte incentrate sul renderlo sempre più un prodotto enterprise.

Sviluppato e diretto dall'Austriaca Proxmox Server Solutions GmbH, è un progetto in rapido progresso e con interessantissime funzionalità che si aggiungono versione dopo versione.

Il sistema è interamente Open Source, prevede la possibilità di acquistare un abbonamento (a prezzi molto vantaggiosi) per accedere al repository di aggiornamento enterprise, più collaudato e sicuro di quello standard, e tutto il supporto e l'assistenza necessari al sistemista che ne possa avere necessità.

Continua la lettura... … (ulteriori 7 minuti di lettura)