linux user group brescia

immagine del castello

Archivio della mailing list

**** FORSE CI SIAMO **** Re: Problema con nfsd **** FORSE CI SIAMO ****

Alfredo Quartini quarto a numerica.it
Ven 28 Feb 2003 14:41:52 UTC
ciao Bauno,

grazie per i consigli;


> 
> Ti posso dire che utilizzo (in quasi-produzione) uno stabbiotto analogo 
> al tuo, suddividibile in "slice" che vengono visti come HD fisici sui 
> diversi lun dell'ID scsi. E non ho mai avuto problemi di sorta né nel 
> riconsocimento, né nell'utilizzo. Senz'altro le condizioni di 
> funzionamento sono molto - gravose dei tuoi test, xò l'IO è piuttosto 
> pesante. Il filesystem (qualche centinaio di GB) è reiserfs, la distro 
> utilizzata è UnitedLinux. Non è xò condiviso in NFS. Io mi sono fatto 
> l'idea (e te lo dissi) che l'anello debole della catena di stabilità sia 
> il controller da 17.000 €. Sulla macchina sopra ho installato un normale 
> AHA17qualcosa (Ultra160) e funziona benissimo. Volendo prestazioni 
> migliori, a 2.000 € e rotti ti prendi una scheda con porta in fibra da 
> 2Gb che polverizza il controller SCSI dal punto di vista prestazionale e 
> ha il vantaggio di poter condividere lo scatolotto via switch. Ma forse 
> è un po' tardi x fare simili considerazioni :). Sarebbe xò molto 
> istruttivo se potessi provare con un controller scsi "normale".
> 

non posso utilizzare un controller SCSI normale. Mi sembra di capire che 
il tuo non faccia anche il RAID hardware. Quello che ho io appare come 
un'interfaccia scsi, e si collega al controller scsi (aic7899w) che e' 
dentro il computer che controlla il tutto. Il controller RAID appare 
come un device con Id1 al controller dell'host. Ripeto, a parte quando 
ho avuto il primo crash (ma per altri motivi, questa volta veramente 
hardware:-), non ho avuto problemi con il connubio filesystem / 
partizioni / luns  etc etc. I problemi saltano fuori quanto, appunto, 
esporto i filesystem via nfs e poi comincio ad usarli in modo 
impegnativo (che e' l'unico modo in posso usarli :-). Non probelmi 
usando applicazioni come ftp - rcp - tar - rsync - samba -.....

> 
> 
> LVM è senz'altro quello che ti garantisce la maggiore flessibilità. Dal 
> punto di vista della stabilità non mi ha mai dato alcun problema. Ma il 
> tuo è un banco di prova severo :)
> Altrimenti, senza farti troppe questioni, partiziona tutto con fdisk, 
> non vedo controindicazioni di sorta...:)

vedro' di provare anche LVM; ho aspettato tanto, posso aspettare ancora 
un po' :-). Adesso che (penso) di aver risolto il problema di 
affidabilita' catastrofica, posso dedicarmi al tuning della cosa.


Per la cronaca, lo scatolotto ha funzionato per 30 ore con:

14 bonnie++ in esecuzione parallela su 5 filesystem esportati via NFS; 
due dei client arrivavano al server con collegamenti Gb
5 bonnie++ in esecuzioni locale, cioe' eseguiti dallo stesso filesrv, 
uno su ogni filesyste
4 sessioni di copia reiterata seguita da cancellazione di due alberi di 
directory "profondi", via nfs
5 sessioni di "find /.... -name ... -exec ...." via nfs

... a questo punto, la larghezza di banda della rete ethernet dovrebbe 
essere piu' che saturata....

tutto eseguito in parallelo da 8 client solaris, mentre il filesrv 
faceva anche due compilazioni in continuo del kernel (questo per tenere 
occupati i processori).

sembra un po' stupido, ma sono un sostenitore della teoria della 
"mortalita' infantile...": se deve morire, deve morire subito.
Invece, il sistema non ha fatto una piega, nemmeno un singolo "nfs 
filesrv not responding, still trying...".  Ho provato sia con ext2, che 
con xfs; come divevo nella mail precedente, xfs non garantisce 
prestazioni migliori per un singolo o pochi client; la differenza si 
vede sotto stress.

grazie, Alfredo.





Maggiori informazioni sulla lista Lug