View Full Version : CLUSTER... consigli
Qui all'universita' di fisica di TN dobbiamo implementare un piccolo cluster, e siccome il budget non e' ovviamente milionario, stiamo cercando di contenere i costi (niente mirinet :( )
Per prima cosa abbiamo pensato di prendere macchine che da qui a 4 -5 anni, quando il cluster sara' obsoleto possano venir riconvertite in desktop decenti, quindi non abbiamo intenzione di prendere dei rack...
In teoria il cluster dovrebbe essere composto da 16 (o se arrivano altri fondi 24) macchine fatte piu' o meno cosi':
athlon 64 dual core 4400+
scheda madre nforce 4 (che ha una scheda di rete integrata)
scheda di rete intel pro 1000
disco da 120 - 160 Gb sata o pata (che viene usato solo per i file temporanei)
4Gb di Ram
Piu' un front-end (serve per compilare i programmi, tenere le home in nfs, gestire le code)
opteron biprocessore
3 dischi da 140Gb scsi in raid 5
1 o 2 Gb di ram
2 dischi in raid 1 pata o sata
I programmi che girano sul cluster usano mpi e il tutto viene gestito da pbs.
In teoria volevamo usare le schede di rete integrate dell'nforce 4 per le home in nfs (prima dobbiamo testare le schede visto che i driver non sembrano proprio il massimo) e le intel per la comunicazioni con mpi (di queste schede siamo sicuri che i driver funzionino in maniera adeguata)...
Qualcuno di voi ha esperienza con altri cluster? avete consigli su hardware/software? qualcuno ha testato decentemente i driver delle schede di rete dell'nforce4?
Il cluster dovra' essere operativo per circa ottobre - novembre, e ovviamente oltre all'implementazione dovro' scrivere anche un po di documentazione, che potrebbe tradursi in un howto decente (quindi vedete di darmi una mano!)
Ciao, ti linko la pagina del nostro progetto:
http://filibusta.crema.unimi.it/openmosix/
purtroppo non è aggiornatissimo ma se mi mandi una mail ti posso dare dei consigli.
Personalmente ho curato la scelta di tutto l'HW presente nel cluster.
La mia mail è:
the.fez@libero.it
ti uppo perche interessa anche a me la conf che andrai ad ottenere.
altra cosa, quale è l'ultimo kernel supportato da openmosix?
ciao
Dovrebbe essere il 2.6.11, comunque controlla sul sito www.openmosix.org
Per quel che riguarda il "mio" cluster.
E' nato circa 4 anni fa, purtroppo con un budegt limitato,
alle 4 macchine mono athlon 1000 del cluster iniziale ho aggiunto un totale di 7 dual athlon su piastra tyan tiger 2466, schede video geforce 5200 agp (mai utilizzate se non per configurare le macchine), 1 giga di ram, scheda di rete Intel Gigabit, e due dischi da 120/160.
Grandi soddisfazioni, tranne qualche instabilità nell'ultimo lotto di due macchine gemelle con athlon MP 2800+, probabilmente generano troppo calore, e nonostante il climatizzatore sia costantemente sui 20° a volte si bloccano.
L'ultima macchina però è la più spettacolare:
Dual Opteron 1,8GHz su scheda tyan tiger K8W (S2875), 1 giga ram, disco da 250 e la solita Intel Gigabit.
Da sola questa macchina fa girare le nostre simulazioni con Amber 7 il 15% più lentamente di 2 dual Athlon 2600+, speriamo di aggiungerne una gemella al più presto.
Purtroppo non ho ancora provato la stabilità dell'nForce su dual Opteron, inoltre nel catalogo tyan non c'è una scheda "economica" con questo chipset.
Se avessimo i soldi andremmo su soluzioni più costose, ma per ora ci si accontenta...
FEz
ti uppo perche interessa anche a me la conf che andrai ad ottenere.
altra cosa, quale è l'ultimo kernel supportato da openmosix?
ciao
beh noi non andremo ad usare openmosix, visto che i programmi che ci gireranno saranno scritti usando mpi...
comunque per ora siamo in fase di test:
- prove di boot via rete e mount della root su nfs
- primi benchmark con nfs (con schede 100Mb)
adesso dobbiamo fare:
- benchmark nfs su schede gigabit (le intel 1000)
- benchmark nfs sulle schede nforce4
- configurare mpi
- prove di stabilita' del driver dell'nforce4 con mpi (mpi satura la banda delle gigabit come ridere, e mette decisamente sotto stress driver e hardware)
- mettere in piedi un sistema di gestione code "decente"
- creare report (magari con una pagina web) dell'uso del cluster (come viene usato, quanto occupano mediamente in RAM i processi del tale utente, quanto durano ecc. in modo tale che abbiamo una direzione da prendere per un futuro upgrade)
per ora e' una settimana che ci lavoriamo "seriamente" quando ci saranno prograssi postero in questo thread...
come va in quel di Povo?
per curiosita' cos'e' l'MPI?
ciao ciao
fez, per pura curiosità, che tipo di applicativi fai girare nel tuo cluster?
cmq l'incompatibiltà dei due mp può anche derivare dalla serie dei processori e via dicendo, prova a dargli un 0,25 in piu di vcore magari li stabilizzi.
ho anche io come workstation una dual mp.
ciao
come va in quel di Povo?
Bene... sei anche tu da queste parti?
per curiosita' cos'e' l'MPI?
ciao ciao
http://www.lam-mpi.org/
Ciao!
Bene... sei anche tu da queste parti?
http://www.lam-mpi.org/
Ciao!
faccio di TLC.
Per ora siamo riusciti a mettere in piedi (su due macchine di prova... che non sono athlon64 ma pentium4):
boot via rete (e root montata in nfs)
lam-mpi
torque
maui
il tutto e' stato relativamente semplice da installare e configurare (del resto con 2 macchine...) non abbiamo fatto nessun tweaking delle code visto che l'unica cosa che ci interessava era vedere se tutto il sistema faceva almeno finta di funzionare...
Primi problemi:
mandando un nuovo lavoro alla coda (con qsub) il tutto funziona, ma se per qualche motivo bisogna interrompere il job (usando qdel) si ha che tkill (che serve per far terminare il job) si becca il 99% del processore fino all'infinito... dopo un po di strace siamo arrivati a capire che tkill impazzisce perche' non riesce ad unlinkare un file in /tmp (il file e' una socket e lo trova sembre in uso)
unlink(".nfs0056bd1200000127") = -1 EBUSY (Device or resource busy)
montando tmpfs in /tmp il problema si e' risolto, quindi il tutto e' stato causato da nfs...
e finalmente ecco qualche domanda:
cosa cavolo e' quella socket .nfsXXXXXX ?
se faccio un lsof +D /tmp mi trova in uso solamente la directory (aperta da tkill) che contiene il file .nfsXXXX ma non il file stesso...
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
tkill 9366 ciccio cwd DIR 0,13 88 4752371 /tmp/lam-ciccio@cambiami-pbs-57.server
tkill 9366 ciccio 4r DIR 0,13 88 4752371 /tmp/lam-ciccio@cambiami-pbs-57.server
e allora perche' non riesce ad unlinkarlo?
per giunta appena uccido tkill con un kill -9 il file .nfsXXX magicamente sparisce!
Ciao!
e' da un paio di settimane che ho in mano qualche mostricciatolo di prova...
Per adesso ci siamo imbattuti in un milione di problemi: dal non vedere tutti e 4 i Gb di ram installata, al malfunzionamento di alcune periferiche (sempre dovuto ai 4gb di ram), a vari problemi di boot (alcune schede di rete integrate non bootano se non c'e' un mouse ps2 attaccato!!!! altre non bootano se c'e'!)
Una nota positiva sembra venire dalle schede di rete nvidia che con i driver proprietari sembrano andare alla perfezione (e le schede dell'nvidia sono attacate al pci-express e quindi non "rubano" la poca banda disponibile al pci 32bit)...
Siccome i problemi incontrati sono stati molti (e presumo ce ne saranno ancora) io posterei qui un simil-diario di quello che succede, delle soluzioni adottate per far andare il tutto, della documentazione che consultiamo in rete ecc. cosi magari se qualcuno deve sbatterci la testa sa da dove partire... e magari qualcun'altro ci puo' suggerire qualcosa al prossimo problema!
cosa ne dite?
Vedo solo adesso questa interesantissima discussione.
Scrivi, scrivi, a me, da vecchio utente (in disuso) di openmosix, interessa parecchio.
Magari rimetto mano anche io ad un cluster.
Ciao
Federico
mitico!
scrivi tutto si!!!
anzi te ne prego... ahaha dovrei anche io mettere su un cluster in università
(nostro cliente in azienda) e allora sarei molto interessato alle tue soluzioni adottate.
al polo usano mathlab sotto windows, ma se riuscissi a farlo andare in cluster sotto linux sarebbe magnifico.
tnx ciao
qualche anno fa c'era MultiMatlab... ma non era della MathWorks. Noi abbiamo avuto un sacco di rogne per parallelizzare matlab ed alla fine abbiamo rinunciato. Adesso però non sono più aggiornato sulla cosa. Qualcuno mi può dire qualcosa di più aggiornato?
Grazie
vi dico subito (come c'e' scritto nel primo post) che il nostro clusterino servira' unicamente per far girare conti con mpi, quindi non avra' niente a che fare con openmosix (niente patch a livello kernel) quindi gireranno solamente programmi scritti appositamente da noi (non di sicuro da me!), quindi alla fin dei conti la configurazione dei singoli nodi, a livello software, non tenendo conto dei programmi per gestire le code e' "banale" (occhio alle virgolette!)...
La vera sfida per ora e' che non ho ancora trovato documentazione di macchine x86_64, che non siano opteron, che siano state clusterizzate, infatti le vere rogne incontrate sono date dai problemi hardware dovuti piu' che altro ai 4Gb di ram installati... comunque da domani/sabato postero' il riassunto delle precedenti 2 - 3 settimane con i problemi incontrati e risolti e i problemi ancora non proprio risolti (diciamo che qualche rogna piu' che risolverla l'abbiamo aggirata in maniera subdola, e magari c'e' un metodo piu' elegante)...
Ciao
Racconta...racconta...
Ciao
Federico
[Prima puntata!]
Eccomi qui! in ritardo come sempre... ma in questi giorni il clusterino mi ha fatto penare!
Allora veniamo un po ai fatti!:
Sul frontend abbiamo installato una gentoo tutta compilata per i 64bit, abbiamo configurato un server dhcp e uno tftp per far bootare le altre macchine via rete, usando come immagine un'altra gentoo (a parte qualche pacchetto le 2 installazioni erano praticamente uguali)..
Abbiamo usato 2 dischi pata messi in raid 1 software... ma subito un disco ci ha dato problemi, come la rete. L'interfaccia di rete (all'inizio abbiamo usato la marvell yukon integrata) riusciva aprendersi l'ip via dhcp, ma poi riusciva a malapena a pingare (fare un ssh era impossibile!). Allora dopo alcune ricerche abbiamo dovuto disabilitare H/W Dram Over 4G Remapping e S/H Dram Over 4G Remapping da bios. In questa maniera in compenso la ram vista dal sistema era solamente di 3Gb (1Gb buttato nel cesso!). Alla fine dopo ricerche prove varie (una settimana di lavoro) abbiamo abilitato S/H Dram Over 4G Remapping da bios e abbiamo forzato l'iommu (abbiamo usato questi parametri per bootare il kernel: iommu=force,noagp,memaper=2,fullflush noapic noacpi noirqdebug) in questa maniera siamo riusciti a far andare scheda di rete/dischi/e abbiamo pure i 4Gb!.
Ma tutto questo perche' (la spiegazione sottostante e' spannometrica, e magari pure sbagliata, ma e' quello che abbiamo capito da vari post nella mailing list del kernel/forum vari ecc.)?
il problema e' che pur avendo una macchina a 64bit (e quindi capace senza trucchi vari ad indirizzare piu' di 4Gb) i pci sono ancora a 32 bit (a 64 bit si trovano solo su schede madri per opteron) e quindi certi indirizzi verrebbero "sovrapposti"..
[/prima puntata!]
se avete commenti o domande.. omeglio se avete suggerimenti! sono qui!
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.