Periferiche di Rete

RAIDzilla: NAS RAID5 fai da te con stile

Pagina 1: RAIDzilla: NAS RAID5 fai da te con stile

La Storia

Quando iniziai il progetto per rendere disponibile sulla rete locale la mia collezione di 2000 CD, utilizzai un drive NETGEAR ND520, ma alla fine risultò essere incredibilmente lento e inaffidabile. Mi ritrovai a dover prendere l’ennesima decisione se comprare o costruire un server più stabile e con maggiore spazio. La mancanza di un buon chassis OEM 1 RU (1.75") in grado di contenere quattro drive, mi spinse verso soluzioni pre-costruite e la mia scelta cadde sul Snap Server 4100. (Snap è passata attraverso diverse reincarnazioni: prima come Meridian Data, poi parte di Quantum, successivamente ritornò società privata indipendente per poi essere comprata da Adaptec. Forse Quantum non digerì il fatto che non si utilizzassero drive marchiati Quantom, preferendo dispositivi IBM).

Il 4100 è uno chassis 1 RU, provvisto di quattro drive di varie dimensioni, il modello più piccolo che ho visto conteneva hard disk da 30 GB, mentre il più potente da 120 GB. Possono essere utilizzati in una moltitudine di configurazioni RAID/JBOD; come RAID 5, la capacità utilizzabile è prossima ai 3/4 di quella totale, meno 1GB o quasi, per l’overhead.

Da allora, ho aggiornato il 4100 con dischi sempre più capienti, sino a raggiungere la versione più recente con drive da 120GB, per uno spazio totale utilizzabile di circa 350GB. Queste unità sono facili da trovare sul mercato dell’usato, in particolare nelle versioni dotate di dischi dalle dimensioni più ridotte. Il Dell 705N è una versione OEM del 4100, anch’essa aggiornabile.

Sfortunatamente Snap ha deciso di non supportare l’indirizzamento a 48 bit del 4100, col risultato che i drive più grandi di 137 GB non possono essere utilizzati in tutta la loro capacità. Nonostante le negoziazioni per rimuovere questa limitazione, Snap ha deciso di non apportare modifiche al funzionamento del dispositivo. Non possiamo biasimarli, del resto il 4100 è un prodotto che presto verrà abbandonato e implementare nuove caratteristiche solo per consentire ai clienti di aggiungervi dischi più grandi limitando le spese, può effettivamente non rientrare tra i migliori interessi dell’azienda.

La decisione presa da Snap mi obbliga a scegliere tra l’aggiungere altri 4100 alla mia già grande collezione (ora arrivata a quota 13 unità 4100) o cambiare cercando hardware più recente, in grado di supportare dischi più grandi.

Questa volta però, ho deciso di costruire personalmente i miei server, per i seguenti motivi:

  • Altre unità 4100 occuperebbero ancora più spazio e avrei bisogno di bilanciare manualmente l’utilizzo dei server.
  • Le prestazioni del Snap 4100 non sono così ottime, circa 35 MBit/sec per letture native (Unix NFS) e circa 12Mbit/sec per letture tramite Windows File Sharing.
  • Oggigiorno si trovano ottimi case OEM dalle diverse dimensioni.
  • Costruendo personalmente il sistema, sarei a conoscenza di qualsiasi limitazione hardware o software e potrei quindi porvi rimedio o gestirla come voglio.
  • Risparmierei più soldi costruendo personalmente il mio sistema piuttosto che comprandone uno nuovo.

RAIDzilla

Quando iniziai a studiare questo progetto, il drive singolo più grande disponibile sul mercato era il Western Digital WD2500, da 250GB. Western Digital chiamò questi dischi "Drivezilla", quindi definire un sistema che ne montasse 24 "RAIDzilla" può sembrare abbastanza ovvio.

Comunque, durante la fase di valutazione dei costi di ogni singolo componente del sistema, Seagate annunciò la commercializzazione di un nuovo drive da 400GB con 5 anni di garanzia. Di conseguenza, cambiai i miei piani e decisi di costruire un server con 16 drive Seagate Barracuda 7200.8 SATA da 400GB (ST3400832AS) invece dei Western Digital da 250GB.

Decisi anche di utilizzare FreeBSD come sistema operativo del server, ma necessitavo di funzionalità disponibili solo nella versione 5.x che, in quel periodo, era ancora in fase di test. Con tutti questi ritardi, il sistema completo non è stato integrato (termine elegante per non dire "messo assieme") fino a Gennaio 2005. Fortunatamente i componenti erano funzionanti e in uso da circa sei mesi quindi mi sono fatto un po’ di esperienza per capire, il giorno in cui il server sarebbe stato montato, cosa avrebbe funzionato e cosa no.