linux user group brescia

Ciao,

questa mail e' solo per chi ha molta pazienza e... curiosita'.

forse, dico FORSE per scaramanzia, sono riuscito ad identificare la 
causa del mio problema relativo ai server nfs che si piantano sotto 
forte carico (forte riferito al mio caso, immagino che gli NFS server 
"seri" possano sopportare molto di piu').

La cosa era sospetta fin dall'inizio dato che, pur essendoci tonnellate 
di messaggi in rete relative a problemi di nfs sui vari vari filesystems 
(ext2, ext3, xfs etc. etc.), mi sembrava strano che non ci fossero 
riscontri diretti del mio caso. Lo stesso Gelmini mi confermava che lui 
non ha problemi con nfs/ext3, mentre invece a me durava da pochi minuti 
a qualche ora al massimo. La cosa strana in piu', e' che il kernel di 
Redhat 7.3 NON RICOMPILATO non mi dava problemi..... Cosi' come non dava 
problemi un altro compputer di test con singolo disco SCSI.

Insomma, per farla breve, facendo dei casi incrociati (ci ho messo piu' 
di un mese :-(, il motivo di tutto sembra essere un malfunzionamento del 
tagged queueing sul driver scsi (naturalmente non ci sono messaggi 
significati in questo senso) quando su Id scsi sono presenti piu' luns.
Mi spiego meglio:

l'unita' scsi esterna e' in relta' un RAID Adaptec durastor 6220, con 12 
dischi U3SCSI e doppio canale LVD di collegamento all'host controller 
(ne sto usando solo uno, di canale,  perche' non sono sicuro del load 
balancing su dual channel scsi del driver aic7xxx; winnt lo fa ;-). 
Cosi' come scritto nel manuale, si possono creare fino ad x volumi raid 
con sottoinsiemi di dischi e, per ciascun RAID, si puo' far gestire al 
controller RAID il partizionamento di ciascun volume.

Nel mio caso la struttura era la seguente:

un RAID0 su due dischi, unica partizione: questo avrebbe dovuto 
contenere copie dei software che usiamo. Non e' fondamentale la 
ridondanza dato che gli stessi software sono installati pari pari su un 
altro server. Per questo era adottato il Raid0.

10 dischi in Raid5, con 3 partizioni (partizioni gestite dal controller 
e NON create dal sistema operativo). A ciascuna partizione viene 
assegnata una LUN diversa sotto lo stesso ID, cosi' come viene assegnata 
una LUN al raid0 del punto precedente.

In totale, sotto l'ID 1 del secondo canale scsi del controller aic7xxx 
vengono viste 4 luns: 0,1,2,3,4 che, al sistema operativo appaiono come 
sdc,sdd,sde,sdf

Vi ricordate quanto ho rotto le scatole per sapere come attivare il 
"probe all luns" senza ricompilare il kernel ? Era, appunto, per poter 
veder le diverse partizioni del secondo volume raid; il primo viene 
visto sempre sotto lun0.

In un modo o nell'altro, tutte le volte che riuscivo a montare tali 
partizioni, il sistema schiantava dopo un po' di tempo (ok, ci mettevo 
del mio, ma non facevo nulla di particolarmente strano), mentre quando 
usavo un kernel standard distribuito da redhat (vedi thread su 
ricompilazione di redaht 2.4.18-24) il sistema reggeva. penso che la 
conclusione sia che reggeva perche' veniva usata solo la lun-0 !!!! 
infatti, riuscito a ricompilare detto kernel (quello che "prometteva" di 
funzionare).... beh, e' morto pure quello ! anzi, per essere precisi, la 
macchina rispondeva, ma tutti gli nfsd (16 nella fattispecie) rimangono 
nello stato DW e non c'e' piu' nulla da fare.

A questo punto, facendo un matching tra le diverse casistiche che ho 
provato  non mi e' rimasto che .... multiple luns vs. single luns .... 
infatti, il kernel standard di redhat (non so gli altri) attiva solo la 
lun0 per ogni Id, su cui , guardacaso c'e' sempre stato ext2 (sulle 
altre partizioni venivano fatti ruotare ext2, ext3, xfs...) che mi ha 
fatto seguire una strada sbagliata ....  Inoltre,  Andrea  mi ha 
confermato diverse volte che lui, cosi' come altri sul pianeta spero, 
utilizza nfs/ext3 senza problemi. Ma, forse, Andrea non ha collegato id 
scsi con luns multiple.... (Andrea, mi puoi confermare ?)

Passo successivo: distrutto i due raid, creato un solo raid5 (hardware 
naturalmente) su 11 dischi (con uno spare aggiuntivo), riconosciuto dal 
kernel come /dev/sdc e fatte le partizioni (cinque) utilizzando fdisk.


Per piu' di 24 ore sono girati i "soliti" test nfs-massacranti (quelli 
che riuscivano an inchiodare il tutto)   su tutte le partizioni 
esportate via nfs, in contemporanea a ricompilazioni /copie 
/cancellazioni locali a ciclo continuo, senza colpo ferire (a dir la 
verita' tutti gli nfsd sono ancora finiti in DW state permanentemente 
ma, terminato i test questi si sono ripresi; prima non si riprendeva 
piu' nemmeno il kernel; attivando 32 nfsd, tutto e' filato liscio).
Ok, c'e' sempre Murphy, ma non era MAI successo prima.

E qui, ho tirato un sospiro di sollievo. Spero che non mi vada di traverso.

Tutto gasato, ho ricompilato il kernel 2.4.18-18 con supporto XFS 
(distribuito da SiliconG, a cui ho aggiunto l'ultimo dirver disponibile 
di Intel e1000), ed ho fatto partire il DOPPIO (circa) del carico nfs 
che di solito usavo per inchiodare il server. Sta girando da 8 ore con 
cpu al 100% (tutte e due :-); i dischi (tutti e 12) sono continuamente 
occupati; la memoria e' costantemente allocata (tutti i 2.5Gb) e temo 
che mi stia per fondere il cavo scsi. Non so se utilizzero' XFS, ma mi 
piace vedere che , almeno, funziona (omaggio a Muphy: cosi' sembra).


A supporto di questa teoria (la considero ancora tale) ho trovato 
qualche messaggio sui newsgroup di problemi relativi al tagged queing in 
presenza di luns multiple..... a dir la verita' sono piuttosto vecchi e, 
nella documentazione del kernel, c'e' scritto che possono dare problemi 
durante il probing e NON dopo.

Conclusione:

1. che fatica, e non e' ancora finita !

2. bisogna proprio farle passare tutte.

3. ammesso che adesso funzioni, che faccio ? Qual e' il metodo migliore 
per partizionare "un disco" da 720 Gb ? 4 partizioni primarie ? Una 
partizione estesa con partizioni logiche ? Un mix tra le due ? LVM ?

4. la domanda (nell'ipotesi che funzioni per davvero) e': che faccio ? 
Uso XFS ? La differenza per un singolo client o due client non si nota, 
per certi tipi di I/O va piu' veloce ext2; la differenza si vede quando 
la macchina e' sotto carico e, stando alla documentazione, quando i 
filesystem cominciano a diventare "densi". XFS richiede piu' memoria, ma 
penso che 2.5Gb per un server che deve fare SOLO NFS/samba possano 
bastare;  richiede piu' CPU, ma ne ho due "apposta"..... Quindi ? 
Stando alla documentazione ed ai test case / white paper (di qualcosa 
dovro' pur fidarmi !), garantisce una migliore scalabilita' ed e' 
maturo/testato; penso che il fatto che sara' incluso in kernel-2.6 sia 
una sorta di garanzia. Qualcuno ha un'esperienza diretta ?

5. con tutti questi test, avro' dimezzato l'MTBF dei dischi.....


Ok, se qualcuno ha avuto la pazienza di arrivare fino qui in fondo lo 
ringrazio per l'attenzione e sarei molto curioso di ricevere un'opinione 
in merito.

Grazie, alfredo.