Newsgroup: it.comp.os.linux.sys
Titolo: Stress test unita' SAN

Problema: fatto l'upgrade a RHEL 5, HP (care persone...) non fornisce i
driver per l'HBA integrato, anche se andando sul sito del produttore qlogic
e scaricando i driver pare tutto funzionare. Pero' un conto e' migrare la
blade di prova, un conto quelli di produzione, con i rischi che il driver
sia instabile e HP, appena vede che non te l'ha venduto essa stessa, se ne
lava le mani. Cercavo quindi un software per fare stress testing dell'I/O su
disco, qualcosa che saturasse (questo e' l'obiettivo) le strutture dati del
driver e dell'HBA per vedere come reagiscono, non tanto a misurare le
prestazioni del disco. Per quanto ho visto finora c'e' LTP e iozone, poiche'
piu' il coverage e' alto e meglio e', qualcuno ha altri suggerimenti?
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 
per quanto riguarda i drivers, ibm per rhel5 e sles 10 non li fornisce
più per le qlogic. le distro ce li hanno già integrati. questo a quanto
ne so è vero sia per quelle con chip qla23xx (2 gbit) sia per quelle con
chip qla24xx (4 gbit). quindi potresti semplicemente usare quelli. i
moduli si chiamano qla2xxx e qla23xx oppure qla2xxx e qla24xx  - dipende
 dal chip che hai. comunque per esperienza quelli presi direttamente dal
sito qlogic funzionano molto bene. di solito nelle documentazioni delle
san trovi un elenco di parametri da modificare per far funzionare meglio
la hba.
per il resto non so.

 la hba.
Qua i parametri sono semplici: mai piu' uno storage di HP, non li sanno
fare, chiedono un botto di soldi e vedono Linux con puzza. La prossima volta
o spendo la meta' con Infinistor o il doppio con NetApp. 
Grazie per i suggerimenti e la solidarieta' :)


 usati piuttosto che quelli del vendor.
il qla2xxx_conf serve solo se monti il sunsurfer, il software che può
configurare la scheda anche online. io non lo uso perchè non mi serve a
niente. vedi un po' tu.
sui readme c'è scritto a cosa servono. io uso macchine ibm e san ibm
(che usa controller engenio, come molti altri). il failover viene fatto
da un layer sopra il driver qlogic.
per il failover del driver qlogic c'è un parametro in modprobe.conf che
si chiama (se mi ricordo bene) qla2xxx_failover che trovi nel readme e
che settato a 0 disabilita il failover in modo dinamico. col kernel 2.4
dovevi compilare il driver con o senza failover. oggi lo attivi al load
del modulo senza problemi.
la differenza tra failover del driver o con un 'qualcosa' sopra è
presspoco questa:
se vuoi il failover del controller (diverso WWN) oltre che dell'HBA ti
serve qualcosa sopra il driver
se vuoi il failover del solo HBA (stesso WWN del controller) allora ti
basta il driver puro e semplice
quasi tutti usano la prima opzione, per questo il failover è
disabilitato di default nel driver

 
mah, io ho un HP EVA4000 e numerosi server bl480 con Linux RH 4 e non ho
avuto problemi, per il QLogic ho usato i driver nativi RedHat ed uso il
multipath per il failover.
Se però intendi a livello di performance, allora bisognerebbe fare
paragoni con altre soluzioni.
Piuttosto mi appresto anche io ad aggiornare i driver QLogic ma dalla
vers. 4.5 alla 4.6 della RH.

 vers. 4.5 alla 4.6 della RH.
Pero' se stai su una 4.x puoi usare i driver di HP, io lo faccio per tutti
gli altri server (questo della 5.1 e' il test) e mi sono trovato bene, alla
fine l'unica specificita' che hai e' lanciare il compile_all_kernels ogni
volta che aggiorni il kernel.
La mia sensazione riguardo alle prestazioni e' che il driver "HP" e quello
Red Hat si equivalgano, io riesco comunque a saturare i 2 Gbps della fibra
(usando dd e con blocchi grandi, ovviamente).


 disabilitato di default nel driver
Io ho un MSA1000 con il firmware 7.00, quindi ho un attivo/attivo, per cui
il failover dovrebbe essere gestito a livello di device-mapper-multipath
(secondo Red Hat, con la 5.1 si puo' gestire anche l'attivo/passivo
dell'MSA1000 con il firmware 4.48. Ho preferito non testare e fare l'upgrade)
Infatti, configurando il multipath, ora la scansione dei device si comporta
come deve, cioe' trova i volumi logici e li mappa sotto /dev/mapper, mentre
prima trovava sia /dev/sda che /dev/sdb (la cosa non causava corruzioni sui
metadati perche' essendo un UUID duplicato ne veniva usato uno solo). Non ho
ancora fatto le prove consistenti nello staccare fisicamente la fibra e
vedere come il sistema reagisca, ma ho fatto delle prove con iozone e ho
visto delle cose brutte.
In particolare ho fatto questo test:
/opt/iozone/bin/iozone -i0 -i8 -K -O -s1G -t16 -T
ovvero creazione di 16 processi, ognuno con un file di 1 G, workload misto e
accessi random.
In /var/log/messages ho trovato:
Jan 20 15:40:20 ermes kernel: qla2xxx 0000:04:03.1: scsi(1:0:1): Abort
command issued -- 1 ef0c3e 2002.
iozone ha terminato poi il benchmark, solo che mi viene da pensare che
iozone potrebbe non fare una verifica forte di correttezza dei dati scritti
o letti perche' il suo compito e' un altro, e io non vorrei che un giorno ci
metto dei dati veri e quell'abort mi spacca il database o chi per esso.
Qualcuno sa cosa significhi quel messaggio di errore e quanto sia grave?


 visto delle cose brutte.
Ho fatto anche queste prove, sono sicuro che siete tutti ansiosi di sapere
come e' andata a finire :D
Il primo test e' stato quello di staccare e riattaccare una fibra o un'altra
mentre era in corso un dd if=/dev/zero etc, e anche se apparivano molti
errori sul device che era stato staccato (/dev/sd{a,b}) non c'erano errori
su /dev/mpath*, e dd terminava correttamente.
Tuttavia, ho pensato che dd non fosse un test affidabile, cosi' ho scritto
un programma in C che parte da un numero casuale, lo scrive su file, ci
aggiunge uno, lo scrive, e va avanti cosi' finche' non muore perche' ho
superato i 2 GiB di dimensione e non ho passato i giusti flag :)
Mentre questo scriveva, ho staccato e riattaccato ora una fibra ora l'altra.
Poi, ho lanciato un altro programma che leggeva questo file, e verificava
che la sequenza scritta fosse x, x+1, x+2 ecc, altrimenti segnalando errore,
e non ha dato errori. Ho quindi ripetuto la prova e ancora tutto e' andato
liscio, quindi sono ora tentativamente fiducioso che il multipath funzioni.
Mi devo comunque ancora spiegare come mai un programma che scriva un long
int alla volta impieghi pochi secondi per scrivere 2 GiB di dati, mentre un
successivo dd con blocchi da 1 MiB ci metta ben piu' tempo. Sembra un
problema di qualche buffer da qualche parte.


 
La scrittura su file passa attraverso la cache del filesystem e su 
macchine con abbastanza memoria impiega svariati secondi prima che 
arrivi al disco.  dd usato direttamente sul device bypassa la cache e 
perciò risulta più lento.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 perciň risulta piů lento.
Non vedo cosa spieghi quello che tu dici. Primo, la SAN ha 256 MB di cache
di scrittura protetti da batteria, quindi anche se scrivo a botte di 1 MB
non arrivo a scrivere direttamente. Secondo, il dd che ha dato prestazioni
deludenti e' stato sul FILE test.img, non sul device. Terzo, il
rallentamento che osservo non e' costante, ma dipende dalla durata del test,
ovvero la scrittura del primo GiB richiede molto meno tempo della scrittura
del 30esimo GiB. Inoltre il carico cresce subito rapidamente, cosa questa
che vedo con molti Linux 2.6, ad esempio ora ho che un NFS in scrittura va a
sbattere a 5 di loadavg (con un unico processo scrittore).
Quindi immagino che ci siano questioni legate al come la SAN organizzi e
riorganizzi le operazioni di I/O (eventualmente confliggendo con l'elevator
del kernel, la butto li'), e/o di come gestisca la cache in scrittura, non e' 
strano che una SAN sia ottimizzata per piccole e frequenti operazioni di I/O 
che per poche e grandi, non e' un NAS. 
Sarebbe bello aver tempo di studiare tutte queste cose per capire quale e'
il problema :(
