1 Le macchine di questo pool fanno parte di una lan privata (la 125 illustrata a pag.2), di cui t2cmcondor è il gateway. Sono presenti 3 macchine su rete pubblica e certificate per il loro utilizzo nel contesto grid. Lo switch e tutte le macchine coinvolte sono stati portati a 9000MTU per supportare i jumbo frames. Sullo storage sono state create 3 unità da 9.8T l'una più 1 da 8.8T e 4 unità da 200G destinata all'area software di Atlas. Un disco (1T) è stato usato come global hot-spare. Le unità per i dati di produzione sono state mappate da gpfs su tutte le macchine di testa come network shared disk (da c2 a c5) e accorpate in un filesystem (/dev/storage_1). Per l'area software abbiamo 4 nsd (c1,c6,c7,c8), su cui risiede il filesystem /dev/software. A pag.3 uno schema riassuntivo. L'attuale configurazione consente di avere un filesystem per un totale di 36T (in pag.4), su cui è stato attivato il sistema quote tunato sulle VO grid. Tre delle 4 macchine manager (le ts) fanno parte del quorum di gpfs, i worker nodes WN sono invece client. In questo contesto, la macchina t2cmcondor viene usata per il frontend di Storm e come client di gpfs, per via del fatto che storm richiede una directory condivisa per l'autenticazione delle request. La stessa macchina svolge anche le funzioni di central manager del batch system Condor. Al backend Storm e al gridftp è stata dedicata la macchina se-b1-1 Attualmente sono presenti sul filesystem delle directory specifiche per la gestione dei fileset di storm: /gpfs/storage_1/atlas (per la VO atlas, con tutti i suoi spacetokens) /gpfs/storage_1/dteam (per la VO dteam di sviluppo) /gpfs/storage_1/egee (per la VO egee, testing) /gpfs/storage_1/proxies (per l'autenticazione di storm) A pag.2 è visibile la configurazione per le storage area E' stata creata anche una directory per l'area software usata dai worker nodes /gpfs/storage_1/exp_software (linkata come /opt/exp_software)‏ Pool GPFS-Storm Milano

2 ts-b1-1ts-b1-2ts-b1-3ts-b1-4 Wn-b1-1Wn-b1-35 T2cmcondor (gateway)‏ ce-b1-1 se-b / /24 Rete

3 gpfs sde sdd ts-b1-1ts-b1-2ts-b1-3ts-b1-4 c Wn-b1-1 (condor exe)‏ gpfs Wn-b1-35 (condor exe)‏ Xyratex Ctrl 1Ctrl 2 gpfs T2cmcondor (central manager)‏ UI Storm FE Ce-b1-1 (condor scheduler)‏ c2 c3 c4 c5 /dev/storage_1 sdc sdb gpfs se-b1-1 Storm BE gridftp gpfs Fiber channel /dev/software c6 c7 c8 sdh sdg sdf sda

4 Sullo storage sono stati eseguiti alcuni test volti a determinare le performance di gpfs e della rete. Esiste una debole asimmetria sulla distribuzione dei nsd del filesystem storage_1, dovuta alla presenza del disco spare. Una lun è stata ridotta e gpfs si adegua sempre al disco più lento e comunque in modo tale da riempire sui singoli nsd la medesima percentuale di spazio. Le operazioni di scrittura quindi saranno complessivamente più lente. Il massimo ottenibile è ~800MB/s La velocità di rete massima, monitorata con dstat e netperf per le 4 macchine è di ~412MB/s Il limite è dettato dalle interfacce di rete delle macchine, che non raggiungono i teorici 125MB/s Dai test sono risultati i seguenti valori per /dev/storage_1, usando dd e dstat: - lettura di files in contemporanea dalle 4 macchine di testa ~780MB/s - lettura da 16 client ~380MB/s - scrittura da quattro server di testa ~330MB/s - scrittura da 16 client ~320MB/s Caratterizzazione Sul filesystem /dev/software, usando dd e dstat: - lettura di files in contemporanea dalle 4 macchine di testa ~450MB/s - lettura da 16 client ~400MB/s - scrittura da quattro server di testa ~250MB/s - scrittura da 16 client ~180MB/s le performance su questo fs sono ridotte a causa del block-size assegnato a /dev/software di 64K, notevolmente più piccolo della stripe sul raid6 (2.3MB). Il controller perde tempo nel caching dei dati. D'altro canto software ospita più di 3M di files anche di piccole dimensioni, un blocksize maggiore comporta perdita di spazio. - compilazione software Arana da worker-node: lettura ~617KB/s scrittura ~70KB/s Per migliorare le prestazioni durante l'esercizio delle funzioni grid, può essere una buona strategia spostare i workernodes su un cluster distinto, in modo da poter ridimensionare il parametro pagepool. Si tratta della memoria dedicata alla cache di gpfs, ma i WN hanno bisogno di tutta la memoria possibile a disposizione per operare in modo ottimale.

5 Test eseguiti 4x local on storage_1 16x network on software 16x network on storage_1 4x local on software

6 mmdf /dev/storage_1: mmdf /dev/software:

7 Per Storm sono stati eseguiti i seguenti test col client standard: Test di raggiungibilità: /opt/srmv2storm/bin/clientSRM ping -e httpg://t2cmcondor:8444 Copia del file (PreparetoPut + copy + PutDone): /opt/srmv2storm/bin/clientSRM ptp -e httpg://t2cmcondor:8444 -s srm://t2cmcondor.mi.infn.it:8444/srm/managerv2?SFN=/dteam/validation/testFile.txt -p lcg-cp file:///home/pistolese/storm_test.txt gsiftp://se-b1- 1.mi.infn.it:2811/gpfs/storage_1/dteam/validation/testFile.txt oppure: globus-url-copy file:/home/pistolese/testFile.txt gsiftp://se-b1- 1.mi.infn.it:2811/gpfs/storage_1/dteam/validation/testFile.txt Chiusura transazione: /opt/srmv2storm/bin/clientSRM pd -e httpg://t2cmcondor:8444 -t "773605e2-67cf-4594-b5b8-cc7d54dcaa17" -s srm://t2cmcondor.mi.infn.it:8444/srm/managerv2?SFN=/dteam/validation/testFile.txt Rimozione file: /opt/srmv2storm/bin/clientSRM rm -e httpg://t2cmcondor:8444 -s srm://t2cmcondor.mi.infn.it: 8444/managerv2?SFN=/dteam/validation/testFile.txt Retrieve del file: prenotazione remoto - /opt/srmv2storm/bin/clientSRM ptg -e httpg://t2cmcondor:8444 -s srm://t2cmcondor.mi.infn.it:8444/srm/managerv2?SFN=/dteam/validation/testFile.txt -p copia file -lcg-cp gsiftp://se-b1-1.mi.infn.it:2811/gpfs/storage_1/dteam/validation/testFile.txt file://home/pistolese/test prenotazione locale -/opt/srmv2storm/bin/clientSRM ptg -e httpg://t2cmcondor:8444 -s srm://t2cmcondor.mi.infn.it:8444/srm/managerv2?SFN=/dteam/validation/testFile.txt -p -T -P file copia file - lcg-cp file:///gpfs/storage_1/dteam/validation/testFile.txt file:///root/test Inoltre su una delle UI è stata installata la suite Cern S2, per eseguire dei test più estesi. Sono stati scelti per il pool quelli indicati nella tabella che segue. Oltre alle funzioni base sono stati compiuti 2 test di carico, PutMany (scrittura concorrente) e GetParallel (accesso concorrente in lettura)‏ Sessione di test funzionale

8