Esperienze di storage

Workshop sulle Problematiche di Calcolo e Reti nell’INFN

24-28 Maggio 2004Sant’Elmo Beach Hotel, Castiadas (CA)

Esperienze di storageTest di funzionalità e performance del

Chaparral Riva effettuati presso la Sezione di Trieste

Alessandro Tirel - Workshop Calcolo 2004 2

PremessaLa necessità di testare una soluzione di storage basata su tecnologia Fibre Channel si è presentata nel momento in cui abbiamo deciso di migrare il servizio di mailing basato sul TruCluster Digital e utilizzare RedHat Linux Enterprise come s.o. su cui basare il futuro servizio. Il motivo principale della scelta è stato quello dell’affidabilità della tecnologia FC rispetto a quella SCSI. Tuttavia la ricerca di un prodotto che facesse al caso nostro non si è rivelata semplice principalmente per l’estrema difficoltà di avere in prova questo tipo di apparati. Al termine di una lunga trattativa con Terasystem siamo riusciti ad ottenere per un periodo limitato il Riva, prodotto dalla Chaparral, che rappresentava un interessante soluzione ai nostri bisogni.


Descrizione prodottoIl Riva prodotto dalla Chaparral, recentementeacquistata dalla Dot Hill, presenta queste caratteristiche:

Doppio controller ridondato (attivo-attivo) hot-swappable 1 GB di cache ECC DDR Batteria tampone, alimentori ridondati hot-swappable, 4 porte host 2 Gb/s, 4 porte

drive 2 Gb/s 2 loop interni a doppio accesso per i dischi, 240 dischi nella configurazione massima,

670 MB/s di trasferimento dati RAID 0,1,3,4,5,10,50 e JBOD, max 128 LUN, 32 array e 16 partizioni per array Capacità di estendere gli array dinamicamente Connessione ethernet su ciascun controller per il monitoraggio e la gestione tramite

interfaccia web con in alternativa la possibilità di utilizzo della porta seriale. Hot spare globale o dedicato


Test – Hardware & SoftwarePer effettuare i test sono stati utilizzati dei server Supermicro dalle seguenti caratteristiche:

Doppia CPU Xeon 3.06 Ghz 2 GB RAM 1 disco da 36 GB Ultra320 15K rpm Scheda FC Emulex 9002L 2 Gb/s

Il Riva conteneva 8 dischi FC da 146 GB 10K rpm, per i test è stato creato un array di 4 dischi.

Sui server è stato installato RHEL 3.0 + Cluster Suite


Test - BenchmarkPer valutare le prestazioni dello storage è stato scelto il programma di benchmark IOzone che testa varie modalità di trasferimento dati caratteristiche di diversi utilizzi.Il programma permette di generare un output compatibile con Microsoft Excel e quindi permette un piú agevole trattamento dei dati per l’analisi dei risultati.Il programma è stato ricompilato sul server ed il comando utilizzato per i test è il seguente:

/opt/iozone/bin/iozone -Rab /root/testdrive.xls -g 4G


RisultatiSono stati utilizzati due tipi di file system journaled per i test: ext3 e jfs che viene indicato dai produttori di IOzone come il piú performante nella maggioranza dei test. Vediamo alcuni grafici generati dal programma di benchmark.


Ext3 – Scrittura sequenzialeWriter Report

0

50000

100000

150000

200000

250000

300000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


Writer Report

0

100000

200000

300000

400000

500000

600000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

JFS – Scrittura sequenziale


Ext3 – Lettura sequenzialeReader Report

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

2000000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


JFS – Lettura sequenzialeReader Report

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

2000000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


Ext3 – Lettura ad accesso casuale

Random Read Report

0

500000

1000000

1500000

2000000

2500000

3000000

3500000

4000000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


JFS – Lettura ad accesso casuale

Random Read Report

0

500000

1000000

1500000

2000000

2500000

3000000

3500000

4000000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


Ext3 – Scrittura ad accesso casuale

Random Write Report

0

200000

400000

600000

800000

1000000

1200000

1400000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


JFS – Scrittura ad accesso casuale

Random Write Report

0

500000

1000000

1500000

2000000

2500000

File size

KB

/se

c

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384


Prove per clusterPer poter effettuare le prove di affidabilità relative alla configurazione in cluster dei due server si è reso necessario attendere la fornitura da parte della Terasystem di uno switch FC. Il motivo è dato dal fatto che i due controller del Riva non sono in comunicazione diretta tra loro, ossia le LUN servite dal controller A non sono visibili agli host connessi al controller B se non nel momento di un fault del controller A. Questo è un problema poichè nella configurazione del cluster occorre definire una partizione raw detta di quorum accessibile dai nodi che ne fanno parte i quali la utilizzano per monitorare lo stato del sistema.


SAN - ProblemiUna volta collegati i due server ed il Riva allo switch si sono presentati dei problemi dovuti al modo con cui Linux mappa le LUN con i device sdx. In modo particolare se la LUN 0 non presente Linux non effettua lo scan delle successive. Un analogo problema si presenta se le LUN non sono consecutive.Per ovviare a questo tipo di problemi è bene definire quelli che si chaimano persistent bindings, cioè associazioni tra il WWNN/PN ed i device fisici /dev/sdx. Questa operazione nel caso che schede Emulex risulta essere un po` complicata infatti bisogna editare il file di configurazione del driver e quindi ricompilarlo e creare il nuovo modulo da caricare nel kernel.


ClusterLAN

Heartbeat

Switch FC

Ctrl B/1Ctrl A/0

Quorum LUN 0

Data LUN 1


Test del ClusterSono stati effettuati alcuni test di funzionalità per testare l’effettiva capacità del sistema di rispondere ad eventi di failure dei vari dispositivi. Innanzitutto è stato definito un servizio NFS con associata una partizione ‘esportata’ dal Riva come LUN 1, poi una volta attivato il servizio si è provveduto a staccare la connessione in fibra del server su cui il servizio era attivo ed esso è migrato correttamente sull’altro server. Un altra prova effettuata è stata quella copiare un file da un client via NFS sul server ed a quel punto migrare il servizio sul secondario; la copia malgrado lo spostamento del servizio è stata completata con successo. Stessa cosa è successa facendo lo shutdown del controller A del Riva.


Espandibilità dinamica dell’arrayUn requisito fondamentale che abbiamo individuato nella scelta del prodotto era quello di poter aggiungere a posteriori dei dischi ad un array già in produzione. Questa possibilità effettivamente esiste nel caso del Riva anche se i tempi per l’ampliamento sono piuttosto lunghi. Tuttavia non viene compromessa la funzionalità del sistema e quindi il problema riveste un aspetto marginale. La procedura per rendere ampliare il filesystem è piuttosto semplice si ricrea con fdisk la partizione con la nuova dimensione poi si utilizzano i comandi e2fsck e resize2fs.


Esempio[root@postman2 root]# e2fsck -f /dev/sdd1e2fsck 1.32 (09-Nov-2002)Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structure Pass 3: Checking directory connectivityPass 4: Checking reference countsPass 5: Checking group summary information/dev/sdd1: 1390982/35487744 files (0.2% non-contiguous), 7430908/70961105 blocks[root@postman2 root]# resize2fs /dev/sdd1resize2fs 1.32 (09-Nov-2002)The filesystem on /dev/sdd1 is now 89271189 blocks long


ConclusioniIl prodotto si è rivelato affidabile e di buone prestazioni, sicuramente migliorabili con opportuni tuning del sistema. Ottima l’interfaccia di management via web e le funzionalità di base.


RingraziamentiDott.ssa Laura Bastianel – Terasystem S.p.A

Esperienze di storage

Documents

Transcript of Esperienze di storage