Dell Precision T7400: da workstation del 2008 a NAS di casa

L'idea

La Dell Precision T7400 è una workstation professionale del 2008: un case enorme, due processori Intel Xeon E5420 da quattro core ciascuno, 16 GB di RAM di tipo server e un alimentatore da oltre mille watt. All'epoca era una macchina da studio di progettazione; oggi, per l'uso quotidiano, è superata da qualunque portatile. Però ha una cosa che molti computer moderni non hanno: tanto spazio per i dischi.

L'idea iniziale era un'altra: donare potenza di calcolo alla scienza. Esiste un progetto, BOINC, che permette a chiunque di mettere a disposizione il proprio computer per ricerche scientifiche vere (matematica, astronomia, medicina): il programma scarica piccoli pacchetti di calcoli, li elabora e rimanda indietro i risultati ai ricercatori. Il mio piano era accendere la T7400 solo quando i pannelli fotovoltaici di casa producono più energia di quella che consumiamo, così da regalare alla ricerca un'energia che altrimenti sarebbe andata sprecata. Strada facendo la macchina è diventata anche qualcosa di più utile nel quotidiano: un NAS secondario, cioè un archivio di rete dove salvare backup e file non critici, raggiungibile da tutti i computer di casa. Un modo concreto per dare lavoro sia a lei sia a una pila di vecchi dischi che altrimenti sarebbero rimasti in un cassetto.

La preparazione hardware

Prima di tutto ho aperto la macchina per una revisione. Sotto i dissipatori delle due CPU ho trovato la pasta termica originale ormai completamente pietrificata: non ne avevo mai vista una così dura. L'ho rimossa, ho pulito i processori e ho applicato pasta nuova su entrambi. Con quasi vent'anni sulle spalle, su una macchina del genere è il primo intervento da fare, prima ancora di pensare al software.

Il controllo generale ha fatto emergere anche un classico delle macchine datate: la batteria tampone della scheda madre scarica, segnalata all'avvio e responsabile di una data di sistema sbagliata. Un dettaglio che sembra innocuo, ma che più avanti avrebbe complicato l'installazione del sistema operativo.

Il mistero dei segmentation fault

Come sistema operativo ho scelto Ubuntu Server, amministrato da remoto dal mio computer fisso. L'installazione è filata liscia, ma da subito il sistema ha cominciato a comportarsi in modo strano: segmentation fault casuali, cioè programmi che si chiudevano di colpo per un accesso alla memoria non valido. Succedeva all'accesso remoto, durante l'installazione degli aggiornamenti, perfino all'avvio. In un caso il riavvio stesso non è andato a buon fine e la macchina si è fermata nella shell di emergenza del sistema di avvio: la stessa fase di boot che avevo studiato in teoria al corso di Sistemi Operativi, e che lì ho ritrovato davanti agli occhi, dal vivo.

Qui è andata la maggior parte del tempo di tutto il progetto. Le ipotesi erano tante, e tutte plausibili. La prima era la RAM: le FB-DIMM sono moduli da server con un chip dedicato che scalda molto, e dopo quasi vent'anni un banco stanco non sarebbe una sorpresa, anche se nei log non compariva nessun errore di memoria. La seconda era l'architettura biprocessore: con due CPU che condividono la stessa memoria e si passano continuamente i dati attraverso il chipset, basta un'instabilità minima in quel dialogo per far crollare un programma, e infatti i crash comparivano su core di entrambi i processori. La terza era il software: una versione di Ubuntu pensata per hardware recente, che su una piattaforma del 2008 poteva inciampare in qualche combinazione mai testata.

Ho scelto la strada più pulita: reinstallazione da zero con la versione LTS precedente, più collaudata. Anche lì qualche crash si è ripresentato, ma questa volta circoscritto a una componente precisa, e una piccola correzione alla configurazione del gestore dei pacchetti l'ha fatto sparire. Da quel momento il sistema è stabile. Il colpevole esatto non si è mai fatto scoprire: con ogni probabilità è stato un intreccio tra hardware datato, architettura a due processori e software moderno, e cambiare il terzo elemento è bastato a rimettere in equilibrio gli altri due.

In mezzo c'è stata anche la battaglia con le ventole. Il sistema non riusciva a controllarle e le teneva al massimo: un rombo da aereo, giorno e notte. Dopo diversi tentativi ho trovato il modo di far gestire le ventole in base alla temperatura reale dei processori. Risultato: in idle la macchina è tornata silenziosa, e sotto sforzo prolungato le temperature restano sotto controllo.

Dischi, volumi e la condivisione in rete

Il cuore del NAS sono i dischi: otto dischi recuperati, di marche, età e capacità diverse, da 160 GB fino a 2 TB. La domanda era come trasformarli in un unico archivio. Le strade classiche non andavano bene: un RAID vuole dischi uguali, e nelle versioni che sommano lo spazio basta che se ne rompa uno per perdere tutto; un volume unico che "incolla" i dischi uno dopo l'altro ha lo stesso difetto.

Ho scelto invece un'unione logica dei dischi con mergerfs. Ogni disco resta un disco a sé, con il suo filesystem e i suoi file interi al suo interno; mergerfs si limita a mostrarli tutti insieme come un'unica cartella da oltre 5 TB, e quando arriva un file nuovo decide lui su quale disco salvarlo, tenendo unite le cartelle e privilegiando quello con più spazio libero. I vantaggi per un archivio come questo sono concreti: se un giorno un disco si rompe, si perde solo il suo contenuto e non l'intero archivio; si possono aggiungere dischi di qualunque capacità in qualsiasi momento; e ogni disco, collegato da solo a un normale PC Windows, resta leggibile in caso di emergenza.

Questa è stata la parte più "da archivista": ogni disco è stato ripulito, formattato ed etichettato, anche fisicamente, con il suo nome e la sua capacità. Il sistema operativo è finito su un disco dedicato, trasferito da quello di partenza senza reinstallare nulla. Lungo la strada ci sono stati i classici imprevisti di chi gestisce tanti volumi: identificativi dei dischi che non corrispondevano più alla configurazione, punti di montaggio da rimettere in ordine, un avvio che si bloccava per un controllo automatico che non aveva senso su quel tipo di dischi. Li ho risolti uno alla volta, finché ogni disco non è tornato al suo posto e l'avvio non è diventato affidabile.

Infine la condivisione: con Samba l'archivio compare come una normale cartella di rete su Windows, con accesso protetto da credenziali. Per tenere d'occhio la macchina uso un'interfaccia web di amministrazione (Cockpit), che raggiungo dal browser del mio computer fisso, e btop per controllare in tempo reale carico dei processori, memoria e temperature.

Il risultato

Oggi la T7400 è un NAS da oltre 5 TB costruito interamente con hardware recuperato: una workstation che nessuno usava più e una manciata di dischi che aspettavano solo di essere buttati. Dal computer di casa ci salvo backup e archivi non critici come in una qualsiasi cartella di rete, e quando voglio controllare come sta mi basta aprire il browser.

È stato il progetto più lungo tra quelli che ho raccontato qui, e anche uno dei più istruttivi. Non per un singolo guasto da riparare, ma per la somma di piccoli problemi da capire uno per uno: una pasta termica diventata cemento, una batteria da due euro, un sistema che crollava senza un motivo evidente, dischi da mettere in fila. Alla fine il premio è una macchina di quasi vent'anni che, invece di finire in discarica, custodisce i dati di casa.