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

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.