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.
Hardware
Una volta presa la decisione di utilizzare una struttura da 16 alloggiamenti, ho scelto il Ci Design SR316 come base dell'intero sistema. Può contenere fino a 16 drive hot-swap Serial ATA (SATA), un floppy drive, CD-ROM, triplo alimentatore ridondante e una moltitudine di schede madri.
Per queste ultime, ho scelto Tyan Thunder i7501 Pro con controller SCSI opzionale. Ho utilizzato schede madri Tyan in passato e sono sempre rimasto più che soddisfatto; supportano due processori Intel Xeon e i modelli che ho scelto, 3.06GHz/533MHz, avevano il miglior rapporto prezzo/prestazioni. Utilizzare due processori mi rende più tranquillo quando devo eseguire programmi in locale senza poter impattare le prestazioni del file server; spesso infatti, mi ritrovo ad utilizzare processi che richiedono un alto uso di CPU, come la conversione di immagini di CD in MP3 o l'esecuzione di checksum dei file, etc.
La scheda madre è provvista anche di tre porte Ethernet integrate, una da 10/100 Mbit e due da 10/100/1000 Mbit. Le prestazioni Ethernet Gigabit erano essenziali per questo progetto, e fortunatamente la scheda ne aveva già due integrate.
Per le memorie ho utilizzato esclusivamente prodotti Kingston, selezionando due KVR266X72RC25L/2G dall'elenco riportato nella lista dei moduli approvati da Tyan; 4GB sarebbero stati comunque abbondandi per la gestione dei buffer dei dischi. Nonostante la scheda madre supporti fino a 12GB di memoria (6 di questi moduli da 2 GB), ai tempi non era semplice trovare sistemi operativi che supportassero più di 4GB.
Uno dei componenti più importanti per un file server è il controller dei dischi; e per il mio progetto ho scelto gli AMCC 9500S-8MI di 3Ware, ognuno dei quali supporta otto drive e si connette al backplane del case tramite un cavo Multilane Interconnect (MI). Questo cavo ne sostituisce quattro SATA normali, riducendo così il numero di cavi totali da 16 a 4.
Infine, ho aggiunto cavi SCSI interni e terminatori esterni CS Electronics; costruiscono e spediscono qualsiasi tipo di cavo personalizzato in un solo giorno o due.
I 16 drive del sistema sono divisi in due gruppi indipendenti da 8 dischi l'uno, un gruppo per ogni controller. All'interno di ogni gruppo, 7 drive vengono usati in RAID 5 mentre l'ottavo viene tenuto come "hot spare", pronto a sostituire uno degli altri sette drive nel caso si guastasse.
Software
Come detto precedentemente, la scelta del sistema operativo è caduta su FreeBSD 6.x, Samba come software di server CIFS, rdiff-backup per la sincronizzazione dei RAIDzilla di backup con le unità locali e, naturalmente, una grande varietà di altri software minori. Uno dei vantaggi di RAIDzilla rispetto NAS standard, è la possibilità di eseguire un gran numero di software localmente, senza aver bisogno di costruire un OS NAS (ammesso che i sorgenti siano disponibili) e di cross-compilazione delle applicazioni.
Cosa farei di diverso oggi (due anni dopo - 2007)
Se oggi dovessi ricominciare un progetto simile da zero, il cambiamento più grosso consisterebbe nell'utilizzare un'unica scheda RAID a 16 canali, così da avere un solo disco di parità e un solo disco di spare, invece dei due per tipo che ho adesso.
Userei anche dell'hardware più moderno, come una scheda madre PCI Express e una scheda RAID, senza naturalmente dimenticare drive con capacità maggiori, 750GB o 1TB
Dato che il supporto per sistemi con più di 4GB di memoria è molto più diffuso, potrei anche fare qualche esperimento installandone il massimo consentito. Oggigiorno dovrebbe essere possibile utilizzare efficacemente 16GB, se non addirittura 32GB su schede madri di classe server.
Dettagli della costruzione
Figura 1: RAIDzilla - Vista Frontale (Cliccate sull'immagine per ingrandirla)
La Figura 1 mostra la vista frontale del server, unica cosa visibile una volta installato in un rack. Come potete notare, la maggior parte dello spazio sul lato frontale è occupato dagli alloggiamenti per i 16 dischi hot-swap mentre il floppy, il pannello di controllo e l'unità CD-ROM vengono installati in poco spazio, al di sopra dei 16 drive.
Figura 2: Lo scatolone aperto, contenente gli hard drive (Cliccate sull'immagine per ingrandirla)
La Figura 2 mostra lo scatolone appena aperto contenente 20 dischi Seagate Barracuda 7200.8 da 400GB. É importante per ottenere le migliori prestazioni RAID, che tutti i drive siano identici, persino nella revisione dei drive e dei firmware. Il modo migliore per garantirsi prodotti completamente identici tra loro è comprarli direttamente dai produttori, in lotto.
Figura 3: Le ventole di raffreddamento degli hard drive (Cliccate sull'immagine per ingrandirla)
Nella Figura 3, la vista dall'alto del sistema senza copertura; potete vedere le tre grandi ventole che muovono l'aria tra i dischi per poi mandarla all'esterno dalla parte posteriore del case.
Figura 4: La scheda madre, le CPU e l'unità di alimentazione (Cliccate sull'immagine per ingrandirla)
Nella Figura 4 è possibile vedere la parte posteriore del case, in particolare viene mostrata la scheda madre con due CPU montate, sotto le due coperture di plastica nere e, sulla destra, l'unità di alimentazione contenente tre alimentatori ridondanti.
Figura 5: L'area delle schede di espansione (Cliccate sull'immagine per ingrandirla)
La Figura 5 mostra un dettaglio degli slot di espansione. I due controller 3Ware occupano la parte centrale dell'immagine ed è possibile vedere, sulla destra, i cavi arrotolati che collegano i dischi. I cavi ondulati connessi ai controller, di colore rosso e grigio, collegano gli indicatori luminosi di stato dell'attività di ogni singolo drive.
Nella parte inferiore della Figura 5, si vedono i cavi Ultra-320 SCSI, di colore arancione e giallo, che connettono i due canalli SCSI interni verso l'esterno, per permettere il collegamento di altri dispositivi, come unità nastro DLT.
Figura 6: 4GB di memoria (Cliccate sull'immagine per ingrandirla)
Il dettaglio dei due banchi di memoria da 2Gb ciascuno è mostrato nella Figura 6. Per chiunque di voi abbia trascorso tanto tempo nel mondo dei computer quanto me, vedere il livello di densità dei componenti raggiunto è sorprendente. Il primo banco di memoria che comprai nel 1978, era un quadrato da più di 30 centimetri per lato e spesso un centimetro; aveva 8Kbytes di memoria e costava $22.000. Era considerato il massimo che la tecnologia potesse offrire.
I costi
Il crollo dei costi del RAIDzilla sono mostrati nella seguente tabella. Noterete che alcuni dei prezzi riportati sono rimasti aggiornati al 2004, si tratta più che altro di componenti ormai obsoleti e non più commercializzati, mentre il costo degli altri è sostanzialmente crollato. Notate che i costi dei cablaggi non sono inclusi, ma non rappresentavano una grande spesa.
Quantità |
Componente |
Prezzo ($) |
Note |
16 |
Drive SATA Seagate ST3400832AS |
2.348 |
prezzo attuale |
2 |
Controller RAID 3Ware/AMCC 9500S-8MI |
769 |
prezzo del 2004 |
1 |
Case Ci Design SR316 |
1.234 |
prezzo del 2004 |
1 |
Scheda Madre Tyan Thunder i7501 Pro S2721-533 |
524 |
prezzo del 2004 |
2 |
RAM KVR266X72RC25/1024 |
222 |
prezzo attuale |
1 |
Processore Xeon 3.06GHz BX80532KE3066D |
309 |
prezzo attuale |
Totale |
$ 5.442 |
|
I risultati
La lista seguente mostra i filesystem attivi. I /backups_ sono copie in mirroring dei filesystem primari, da utilizzare in caso uno degli array RAID non sia più disponibile, permettendo così di riavviare il sistema per recuperarne la piena funzionalità.
I filesystem attualmente forniti alla rete sono da 2TB e identificati come /data0 e /data1, più due da 120GB, chiamati /work0 e /work1, messi a disposizione degli utenti della rete come spazio temporaneo aggiuntivo.
Figura 7: Screenshot che dimostra la capacità del filesystem (Cliccate sull'immagine per ingrandirla)
La Figura 7 visualizza un'immagine catturata dal filesystem di uno dei server, notate la sua capacità totale: 1,93TB. É un sistema protetto da firewall, quindi risparmiatevi il fastidio di venire a visitarlo, dareste solamente fastidio a me, che poi dovrei lamentarmi col vostro ISP.
Filesystem |
1K-Blocks |
Usati |
Disponibili |
Capacità |
Montato su |
| /dev/da0s1a |
507630 |
51894 |
415126 |
11% |
/ |
| devfs |
1 |
1 |
0 |
100% |
/dev |
| /dev/da0s1d |
16244334 |
37408 |
14907380 |
0% |
/var |
| /dev/da0s1e |
16244334 |
6 |
14944782 |
0% |
/var/crash |
| /dev/da0s1f |
16244334 |
1607096 |
13337692 |
11% |
/usr |
| /dev/da0s1g |
8122126 |
62 |
7472294 |
0% |
/tmp |
| /dev/da0s1h |
8121252 |
26 |
7471526 |
0% |
/sysprog |
| /dev/da0s2h |
120462010 |
4 |
110825046 |
0% |
/work0 |
| /dev/da0s3h |
2079915614 |
859342082 |
1054180284 |
45% |
/data0 |
| /dev/da1s1a |
507630 |
249998 |
217022 |
54% |
/backup_root |
| /dev/da1s1d |
16244334 |
38762 |
14906026 |
0% |
/backup_var |
| /dev/da1s1e |
16244334 |
62 |
14944726 |
0% |
/backup_var_crash |
| /dev/da1s1f |
16244334 |
1686090 |
13258698 |
11% |
/backup_usr |
| /dev/da1s1g |
8122126 |
126 |
7472230 |
0% |
/backup_tmp |
| /dev/da1s1h |
8121252 |
86 |
7471466 |
0% |
/backup_sysprog |
| /dev/da1s2h |
120462010 |
4 |
110825046 |
0% |
/work1 |
| /dev/da1s3h |
2079915614 |
1474939512 |
438582854 |
77% |
/data1 |
|
Come base di confronto coi test di altri NAS, ho eseguito iozone su RAIDzilla, utilizzando un Dell Dimension 8400 con una CPU da 3.6GHz, 2GB di RAM e Windows XP Home. La scheda di rete è una Intel MT1000, connessa a 1000Mbps in full duplex con jumbo frames da 9K abilitati. Le Figure 8 e 9 sono state riportate dai nostri grafici delle prestazioni NAS.
Figura 8: Confronto prestazioni in scrittura - file di piccole dimensioni
Le Figure 8 e 9 mostrano come RAIDzilla si posizioni al vertice della classifica delle prestazioni in scrittura RAID 5 1000Mbps di file con dimensioni pari o inferiori a 16 MB, ma si fermi solo al secondo posto, dietro il Linksys NSS4000/140, nei test in lettura. Notate che NSS4000 ha utilizzato solo jumbo frames da 4K, a differenza dei 9K di RAIDzilla.
Figura 9: Confronto prestazioni in lettura - file di piccole dimensioni
Risultati invertiti invece, per quanto riguarda la gestione di file di grosse dimensioni, da 32MB a 1GB. Dalle Figure 10 e 11 è possibile vedere che il Linksys si comporta meglio di RAIDzilla in fase di scrittura, ma non regge il confronto durante la lettura.
Figura 10: Confronto prestazioni in scrittura - file di grandi dimensioni
Figura 11: Confronto prestazioni in lettura - file di grandi dimensioni
Ho testato anche le prestazioni raggiunte durante il trasferimento di file in FTP tra due RAIDzilla (get /dev/zero /dev/null) raggiungendo velocità superiori a 650Mbit/sec. Naturalmente, le effettive velocità di gestione dei file sono limitate da quelle del sottosistema di dischi.
Non mi sono ancora preoccupato di migliorare le prestazioni, principalmente perchè questo livello di throughput è già più che adeguato alle mie applicazioni.
Potrebbe non rappresentare la soluzione più semplice, ma progettando e costruendo personalmente il vostro NAS potrete ottenere un sistema con tutte le funzionalità che vi servono... e saprete comunque dove mettere le mani nel caso qualcosa smetta improvvisamente di funzionare.