Test Storage Resource Manager per SC4

Test Storage Resource Manager per SC4 Giacinto Donvito Vincenzo Spinoso

Introduzione • È importante cercare di capire se le funzioni necessarie per SC4 e per il lavoro di esperimento sono supportate e con che livello di affidabilità • Il goal primario è quello di aiutare i tier2 ma alcuni parametri potrebbero essere utili anche al tier1 • È importante prendere in considerazione tutti gli aspetti dei software (da ordinare in funzione della priorità che si vuole dare): • Funzionalità base • Performance • Stabilità operativa • Supporto • Possibilità di sviluppi futuri • Funzionalità avanzate • La valutazione dei sistemi deve tenere in considerazione ognuno di questi aspetti

Modalità di test • Primo livello di test, da farsi in qualsiasi sito (tier2): • Sono importanti test di installazione (per valutarne la facilità) • Vanno fatti test per coprire le funzionalità di base • Alcuni test sulla stabilità operative in caso di failure simulate • Secondo livello di test, da farsi nel testbed al CNAF: • Test di performance alla scala di un futuro Tier2 • Sia con programmi contruiti ad arte per “stressare il sistema”, sia con applicazioni reali dei 4 esperimenti • Test di failure in condizioni di elevato “stress” • Test di funzionalità avanzate • Terzo livello di test, esperienze di SC3 • Problemi nell’uso quotidiano • Performance e feedback

Test di primo livello Sarebbe necessario procedere in parallelo su più sedi ai test sui vari sistemi: DPM, dCache, StoRM(??), DRM (??) • Installare il software con le indicazioni fornite (guide ufficiali più note sul WIKI) • Fornire feedback e/o ulteriori suggerimenti per rendere il più semplice possibile il lavoro dei tier2 durante SC4 • Effettuare test di fuzionalità di base per verificare l’installazione • Verrà fornito uno script con pochi test di base da runnare su una UI LCG • Effettuare i test di funzionalità richieste da SC4 • Verrà fornito uno script per rendere quando più automatica possibile la procedura • Effettuare test di performance e di stress • Verrà usato un client in C scritto ad hoc da eseguire sui WN per evideziare eventuali problemi di scala della configurazione hardware/software • Effettuare test con applicativi reali? • Secondo noi questo step andrebbe approntato solo al CNAF • Effettuare dei test di integrazione con il DBII di sito

Test di secondo livello Concentrare i test sulle performance e sull’affidabilità per failure o per “stress” operativo. Alcuni test su funzionalità avanzate che possono risultare utili in un grosso Tier2 o al Tier1 Motivi: • Scalare di un ordine di grandezza la quantità di storage gestito • Raggiungere configurazioni hardware (rete e numero di WN) difficilmente raggiungibili in un attuale Tier2 Metodi: • Usare il programma di benchmark costruito ad-hoc • Usare software e job di esperimento per simulare l’uso reale • Simulare l’accesso via SRM (per provare che il sistema può essere in grado di gestire la mole di lavoro necessaria a fornire i 20 MB/sec per ogni tier2 necessari per SC4)

Test di secondo livello (2) Configurazione Hardware necessaria: Server: • 2 o 3 disc-server con circa 6-8 terabyte • 1 admin node (no spazio disco, CPU >1GHz e RAM >1GB) • Interfacce di rete gigabit ethernet Client: • Almeno 30 client • Interfaccia 100Mbit • Nessun requirement particolare per CPU e RAM

Test di secondo livello Concentrare i test sulle performance e sull’affidabilità per failure o per “stress” operativo. Alcuni test su funzionalità avanzate che possono risultare utili in un grosso Tier2 o al Tier1 Motivi: • Scalare di un ordine di grandezza la quantità di storage gestito • Raggiungere configurazioni hardware (rete e numero di WN) difficilmente raggiungibili in un attuale Tier2 Metodi: • Usare il programma di benchmark costruito ad-hoc • Usare software e job di esperimento per simulare l’uso reale • Simulare l’accesso via SRM (per provare che il sistema può essere in grado di gestire la mole di lavoro necessaria a fornire i 20 MB/sec per ogni tier2 necessari per SC4)

Test di terzo livello In Italia pochi siti hanno fatto esperienza con i sistemi di SRM in produzione. Questa esperienza è fondamentale e va raccolta. Casi Noti: • Bari: SC3 CMS • Usato dCache come sistema di produzione (File trasferiti, job girati) • LNL: SC3 CMS • Usato DPM in produzione (molti problemi incontrati) • Torino: SC3 ALICE • Usato dCache (NO NEWS) • Milano: SC3 Atlas • Usato DPM (NO NEWS) • …

Alcuni dettagli DPM Esperienza precedente: • Promette di essere un buon compromesso fra facilità di uso e funzionalità • Pensato espressamente per i Tier2 • Stabilità operativa non sempre a “production level” • Buon supporto • Ancora problemi nell’uso in produzione • Previsti ottimi sviluppi • Elevata velocità ed “efficienza” sull’accesso locale • Scalabilità da verificare • Attualmente poche funzionalità avanzate • Piani chiari per il supporto a SC4

Alcuni dettagli (2) dCache Esperienza precedente: • Non semplice da gestire • Supporto non sempre puntuale • Piani non chiari per il supporto a SC4 • Ottima scalabilità • Bassa efficienza per accesso locale • Stabilità operativa ben provata • Funzionalità avanzate utili per i siti più grandi • …

Alcuni dettagli (3) DPM TO DO: • Testing della release 1.4.1 • Funzionalità di base • Stabilità • Funzionalità di SRMv2.1 per SC4 • Quelle più importanti sono dichiarate implementate • Accesso locale • con Bench • con job reali • Scalabilità • Potrà gestire 100 Tb ?? • Interoperabilità con altri SRM e altri servizi di GRID/SC4 • FTS • …

Alcuni dettagli (4) dCache TO DO: • Testing della release 1.6.6 • Funzionalità di base • Fix di alcuni problemi evidenziati in SC3 • Funzionalità di SRMv2.1 per SC4 ?? • Non è ufficialmente supportato SRMv2.1 • Non ci è stata comunicata la possibilità di testare versioni di sviluppo (anche se sembrano esistere) • Accesso locale (con Bench e con job reali) • Sembra che anche a FNAL l’efficienza di CPU non vada oltre il 50% • Scalabilità • Potrebbe essere una scelta per il tier1?? • Interoperabilità con altri SRM e altri servizi di GRID/SC4 • FTS • …

Alcuni dettagli (5) StoRM TO DO: • Testing della prima release • Funzionalità di base • Quali sono già implementate? • Quanto sono stabili? • Funzionalità di SRMv2.1 per SC4 ?? • Dovrebbe supportare SRMv2.1 quindi non ci dovrebbero essere problemi • Accesso locale (con Bench e con job reali) • Dovrebbero essere il linea con quelle di GPFS • Scalabilità • Potrebbe essere una scelta per il tier1? • Interoperabilità con altri SRM e altri servizi di GRID/SC4 • FTS • …

Alcuni dettagli (6) DRM Overview: • Interfaccia SRM verso un file-system standard • Fully compliance con SRMv2.1 • Può essere una scelta per i siti con piccole esigenze di storage (per sostituire i classicSE) • Molto utile per testare gli altri SRM • Non sono necessari test specifici e intensivi

Test Pianificati • http://pccms3.cmsfarm1.ba.infn.it/~storage/TestSuite.html

Advanced Test dCache • Replica temporanea dei file in base al costo di accesso • Uso dei WN per bilanciare il carico • vacating formatting and reusing a pool • Use a very large file-limit (for dcap local access) • use a very large login limit (in the gridftp/dcap-door) • "Hybrid" dCache replicaManger

Conclusioni • Molto lavoro da fare in poco tempo • Scadenza stretta anche per gli stessi sviluppatori del software • Fondamentale il supporto del tier1 • Importante la partecipazione di altri Tier2 • E’ necessaria una partecipazione degli esperimenti per avere il software che poi verrà usato in SC4 e uno schema del modello di computing che verrà usato

Test Storage Resource Manager per SC4