EGEE is a project funded by the European Union under contract IST-2003-508833 SRM overview: d-Cache, DPM G.Donvito INFN Bari www.eu-egee.org.

Presentazione sul tema: "EGEE is a project funded by the European Union under contract IST-2003-508833 SRM overview: d-Cache, DPM G.Donvito INFN Bari www.eu-egee.org."— Transcript della presentazione:

1 EGEE is a project funded by the European Union under contract IST-2003-508833 SRM overview: d-Cache, DPM G.Donvito INFN Bari www.eu-egee.org

2 Workshop Storage, 20-21 Marzo 2006 - 2 Outline Overview of SRM dCache  Overview  Test DPM  Overview  Test Conclusion

3 Workshop Storage, 20-21 Marzo 2006 - 3 dCache overview Collaborazione fra Desy e FNAL (più altre piccole collaborazioni) Obbiettivo:  Sistema di storage distribuito per utilizzare storage server economici  Fornisce un’astrazione dello spazio disco sotto unico root file-system navigabile per i meta-data (attraverso interfaccia NFS)  Possibilità di aggiungere il supporto per il proprio sistema di Tape Library È necessario scrivere due/tre script bash o perl (put/get/remove)  Garantire la scalabilità nell’ordine delle centinaia di Tb di spazio disco e centinaia di pool node Accesso:  Fornisce accesso locale e non (anche posix like) con vari protocolli (dcap, ftp) autenticati e non Gestione dei pool:  Possibilità di gestire l’accesso ai pool secondo classi di storage (read, write, cache, on VO or user base)

4 Workshop Storage, 20-21 Marzo 2006 - 4 dCache overview (2) Supporta copie multiple dei file (per garantire alta disponibilità o bilanciamento del carico)  Supporta pool-2-pool automatic transfer Dinamic “match-making” fra i pool  con i parametri configurabili da amministratore (in base a spazio disco, carico, network, ecc) Supporta multiple “acces point” e doors E’ possibile “svuotare” un pool per uno “scheduled downtime” Possibilità di suddividere i vari servizi su macchine diverse con elevata granularità Elevate possibilità di configurazione per venire incontro a tutti gli ambiti di utilizzo Sistema di monitoring integrato via web Interfaccia grafica di amministrazione in JAVA

5 Workshop Storage, 20-21 Marzo 2006 - 5 dCache overview (3)

6 Workshop Storage, 20-21 Marzo 2006 - 6 dCache overview (4)

7 Workshop Storage, 20-21 Marzo 2006 - 7 dCache testbeds Bari: Installazione di produzione  3 pool server (gigabit eth): 6 Tb in totale (a breve verranno aggiunti altri 11 Tb aggiungendo 2 server)  1 admin node  ~ 40 Client  Rete: 2 Gbit/sec aggregati fra i client e i server (a breve porteremo la banda aggregata fra client e server a 3 Gbit/sec) CNAF: Installazione di test  4 pool server: circa 50 Tb  1 admin node  34 client (in seguito farm di produzione del CNAF)  Nella prima configurazione 2 Gbit/sec, attualmente 4 Gbit/sec di uplink Bari: Installazione di test  2 Macchine (1 admin+pool e 1 pool)  Macchine virtuali Torino: Installazione di produzione  1 nodo come admin e pool (80 Gbyte)  Usato principalmente per testare i trasferimenti fra CNAF e TO

8 Workshop Storage, 20-21 Marzo 2006 - 8 Bari: Installazione di produzione Tests + Usato principalmente come SE di esperimento (CMS) + Buona stabilità operativa + Usato in tutte le fasi di SC3 (trasferiti su WAN, usando PHEDEX, più di 7TB di dati) + Usato per i trasferimenti con PHEDEX e con FTS + Pubblicato nel BDII di sito  Corrette (e dinamiche) le informazioni su spazio disco occupato e disponibile + Saturata la banda di rete disponibile  Sia con “bench” che con il software di CMS (era necessario aggiungere un parametro di configurazione nel software di CMS) + Test dimostrano la possibilità di aprire più di 2000 descrittori di files, usando questa configurazione (probabilmente sufficienti per ~ 200 job)  Eseguiti più di 100 job contemporaneamente senza problemi

9 Workshop Storage, 20-21 Marzo 2006 - 9 Bari: Installazione di produzione Tests (2) - Per raggiungere i risultati di performance e scalabilità riportati sono state necessarie diverse configurazioni fini (alcune non ben documentate) - Provato l’aggiornamento dalla versione 1.6.5 alla 1.6.6  Diversi problemi nella conversione fra il vecchio e il nuovo database dei Metadata  Aggiornamento effettuato senza aspettare la nuova versione di LCG: problemi per aggiornare il software di LCG su un dCache più nuovo di quello atteso - Problemi nel third-party-trasfer con SE non dCache  Necessario usare SRMCP per ottenere il massimo livello di performance  Problemi di performance con l’uso di FTS (versioni precedenti: non supportavano correttamente srmcp)

10 Workshop Storage, 20-21 Marzo 2006 - 10 CNAF: Installazione di test Schema dCache CORE PNFS Server Postgres DB Admin node SRM door Pool node dcap door Pool service SRM door Pool node dcap door Pool service SRM door Pool node dcap door Pool service SRM door Pool node dcap door Pool service

11 Workshop Storage, 20-21 Marzo 2006 - 11 CNAF: Installazione di test Tests + Test di lettura il locale con il protocollo “dcap”  Usati i WN dedicati (34 Macchine, banda passante massima: 3Gbit/sec)  Usato il programma “bench” (previsti test in futuro con i job di analisi di CMS) + Test di funzionalità avanzate  Replica dei files per garantire alta disponibilità e alte performance  Vacating di un pool “on-line” con successo +/- Test di trasferimento su WAN  Provati vari trasferimenti sia in scrittura (da FNAL e CERN) che in lettura (verso LNL e Bari) con link a 1 Gbit/sec  Problemi iniziali a causa di crush delle macchine, prima per problemi derivanti dalla configurazione dei socket di rete e poi per il file-system XFS  Alla fine risolti con buone prestazioni + Abilitato un bilanciamento del carico in tutte le funzioni fornite dal sistema (tranne DB e Admin-node)  Usato un DNS a round-robin con un alias

12 Workshop Storage, 20-21 Marzo 2006 - 12 Risultati dei test: Trasferimenti in lettura su WAN CNAF LNL Bari + Il carico sulle macchine al CNAF era molto basso, quindi tutto lascia pensare che si potrebbe salire di molto con la rate - il valore basso della banda passante di LNL è dovuto al comportamento dell’installazione di DPM di LNL (dettagli in seguito) + La banda di Bari era satura

13 Workshop Storage, 20-21 Marzo 2006 - 13 Risultati dei test: Trasferimenti in scrittura su WAN + Dopo diverse configurazioni siamo riusciti a raggiungere (e superare per poco tempo) i 100 files trasferiti in parallelo con 5 streams per ogni file. + In totale fra i vari test sono stati trasferiti poco meno di 20 Tb di files I due link hanno latenza molto diversa. Per ovviare all’alta latenza nel caso di FNAL è stato necessario usare un numero molto alto di files in parallelo CERN FNAL + I trasferimenti con il CERN sono riusciti a saturare la banda + Con FNAL si è riuscito ad arrivare a 936 Mbit/sec

14 Workshop Storage, 20-21 Marzo 2006 - 14 Bench e bopener Bench scrive/legge file di test in numero e dimensioni personalizzabili È possibile centralizzare la registrazione dei risultati dei test su un DB MySql I log contenenti le misure di performance possono essere rielaborati (via scripts Perl) per ottenere statistiche Mentre bench legge i files in sequenza, e ciascun file dall’inizio alla fine, bopener:  Apre tutti i files contemporaneamente  Divide ciascun file in chunks  Legge in ordine random tutti i chunks di tutti i files Bopener simula il funzionamento dei jobs di CMS in condizioni teoriche limite  “Se dCache regge le richieste di I/O di bopener, allora deve reggere quelle dei jobs di CMS” (stress test)

15 Workshop Storage, 20-21 Marzo 2006 - 15 Bench - Scrittura – Tempo medio di apertura dei files

16 Workshop Storage, 20-21 Marzo 2006 - 16 Bench - Scrittura – Rate medio

17 Workshop Storage, 20-21 Marzo 2006 - 17 Bench - Lettura – Tempo medio di apertura dei files

18 Workshop Storage, 20-21 Marzo 2006 - 18 Bench - Lettura – Rate medio

19 Workshop Storage, 20-21 Marzo 2006 - 19 Bopener 34 istanze di bopener vengono lanciate su altrettanti WN; ciascuna istanza di bopener legge 60 files (nei test successivi il numero di files sarà aumentato progressivamente); ogni file è grande 1 GB; ogni file viene diviso in chunks di dimensione di 1 MB, e quindi in 1000 chunks/file. Le istanze di bopener sui 34 WN:  aprono, a regime, un totale di 60 × 34 = 2040 descrittori lato server;  leggono tutti i chunks di tutti i files, leggendo complessivamente 2.040.000 chunks!  chiudono, infine, tutti i file.

20 Workshop Storage, 20-21 Marzo 2006 - 20 4 test bopener Aumentando il numero di files…

21 Workshop Storage, 20-21 Marzo 2006 - 21 Bopener - Rate medio

22 Workshop Storage, 20-21 Marzo 2006 - 22 Replica manager di dCache Replica files e controlla periodicamente il numero n di repliche: MIN<=n<=MAX  Se n>MAX allora cancella una replica  Se n<MIN allora duplica il file su un altro pool Vantaggi  Distribuzione della lettura su più repliche dello stesso file diminuisce il carico sul singolo pool  Se un pool “muore”, almeno un’altra replica è SUBITO disponibile Attivando il replica manager sui 4 server abbiamo verificato che l’overhead sulle operazioni di scrittura complessivamente introdotto dal replica manager è trascurabile. Abbiamo configurato 34 WN come pool di dCache, in aggiunta ai 4 disk server; si è assegnata a ciascuno di essi una quota di 40 GB di spazio disco; Abbiamo così incrementato lo spazio disponibile di 34 WN * 40 GB/WN = 1.3 TB

23 Workshop Storage, 20-21 Marzo 2006 - 23 Bopener – Lettura da dCache con o senza replica manager

24 Workshop Storage, 20-21 Marzo 2006 - 24 dCache: Comments and future Manca una implementazione SRM2.1 L’integrazione con LCG è ancora parziale Il supporto è quasi sempre puntuale per seri problemi di produzione, molto meno per test su nuove funzionalità ecc. La configurazione di un’installazione standard è semplice ma le funzionalità più avanzate “costano” tempo di configurazione Manca ancora un buon supporto all’autenticazione VOMS Interfaccia di monitoring via WEB Interfaccia grafica di management in JAVA

25 Workshop Storage, 20-21 Marzo 2006 - 25 DPM overview Sviluppato dal CERN SRM standard di LCG/gLite Fornisce accesso posix like via RFIO autenticato e per la copia via GRIDFTP Unisce vari pool sotto un unico name space, navigabile con appositi comandi Costituito da un leggero e veloce layer software su un RDBMS (MySQL) Obbiettivo:  Facilità di installazione e management  Compatibilità con il ClassicSE Fornisce una prima implementazione dell’interfaccia SRM2.1

26 Workshop Storage, 20-21 Marzo 2006 - 26 Example: SRM put processing (1)

27 Workshop Storage, 20-21 Marzo 2006 - 27 Example: SRM put processing (2)

28 Workshop Storage, 20-21 Marzo 2006 - 28 Example: SRM put processing (3)

29 Workshop Storage, 20-21 Marzo 2006 - 29 Example: SRM put processing (4)

30 Workshop Storage, 20-21 Marzo 2006 - 30 Example: SRM put processing (5)

31 Workshop Storage, 20-21 Marzo 2006 - 31 Example: SRM put processing (6)

32 Workshop Storage, 20-21 Marzo 2006 - 32 Client SRM2 del cvs di DPM Client di Test SRM v2 presenti nei CVS di DPM, scaricabili e compilabili  Client poco documentati (sono usati ufficialmente solo per i test) “test2” è un semplice script Bash per il test di DPM (SRM2)  Scarica i cvs di DPM e compila i client SRM2  Possiede uno script di “environment” (CONFIG) facilmente configurabile  Avvia test più complessi del singolo test di funzionalità, per analizzare situazioni estreme (saturazione spazio libero) implicit pinning alberi di directory (rimozione di directory vuote)

33 Workshop Storage, 20-21 Marzo 2006 - 33 test2 put  =PrepareToPut (filesize=200MB) +globus-url-copy +PutDone get  =PrepareToGet (filesize=200MB) +globus-url-copy +ReleaseFiles/RemoveFiles rmonput, rmonget putoversize putoverspace  While (Free space exists) PrepareToPut;  Rollback! dirs  Ls, Mkdir, Rmdir, Rm, Mv

34 Workshop Storage, 20-21 Marzo 2006 - 34 Classi di funzionalità SRM 2 Data Transfer Functions Directory functions Space Management Functions Permission Functions

35 Workshop Storage, 20-21 Marzo 2006 - 35 Implicit pinning PrepareToGet e PrepareToPut non mantengono il pinning sui files?  il server restituisce correttamente sia il TURL (via RFIO oppure GridFTP), sia il token della richiesta  tuttavia durante globus-url-copy è possibile rimuovere il file usando srmRm (srm2_testRm)  PrepareToGet deve mantenere un pinning (implicito) del file almeno fino all’invocazione di ReleaseFiles da parte del client ReleaseFiles/RemoveFiles/PutDone/ExtendFileLifeTime funzionano? “PrepareToPut does not implement an hard limit on filesize. This has been discussed in SRM Collaboration meetings and probably all developpers also implement a soft limit.” JPB

36 Workshop Storage, 20-21 Marzo 2006 - 36 AbortRequest AbortRequest esce con “successo” (exit=0), ma lo spazio non viene disallocato Attendendo lo scadere del lifetime, lo spazio non viene disallocato Se dopo AbortRequest si riavvia il daemon dpm sul server, allora lo spazio preallocato viene liberato! “fixed in DPM version > 1.5.4” JPB

37 Workshop Storage, 20-21 Marzo 2006 - 37 Suspend/Resume SuspendRequest/ResumeRequest non sono previste in DPM Sono richieste (anche se con bassa priorità) per SC4 “We have no plan to implement Suspend/Resume. This is also true for Castor and dCache” JPB

38 Workshop Storage, 20-21 Marzo 2006 - 38 Ls Di una directory, “Ls” restituisce path, size, type, owner, permissions, date, ma non restituisce il listing! Mkdir, Rmdir, Rm, Mv funzionano correttamente

39 Workshop Storage, 20-21 Marzo 2006 - 39 ReserveSpace Funzionalità era attesa per fine Febbraio Non ha senso testare ReleaseSpace/UpdateSpace “global space reservation will come during the spring. At the workshop in Mumbai, the priority assigned to this item was relatively low.” JPB

40 Workshop Storage, 20-21 Marzo 2006 - 40 Permission Functions srmSetPermission srmReassignToUser srmCheckPermission “srmCheckPermission works in DPM version >= 1.5.4” JPB

41 Workshop Storage, 20-21 Marzo 2006 - 41 DPM testbeds Installazione a LNL  1 admin node  1 pool node: 4 Tb Installazione a Catania  1 admin node  1 pool node che usa GPFS come file-system

42 Workshop Storage, 20-21 Marzo 2006 - 42 Test bench: risultati (1 file da 2GB) Transfer Rate totale in MB/s

43 Workshop Storage, 20-21 Marzo 2006 - 43 Trasferimento dati CNAF-LNL con Phedex Grafico percentuale-CPU e traffico-rete del disk-server DPM Grafico traffico rete GARR

44 Workshop Storage, 20-21 Marzo 2006 - 44 Virtual Ids and VOMS integration DNs are mapped to virtual UIDs: the virtual uid is created on the fly the first time the system receives a request for this DN (no pool account) VOMS roles are mapped to virtual GIDs A given user may have one DN and several roles, so a given user may be mapped to one UID and several GIDs Currently only the primary role is used in LFC/DPM Support for normal proxies and VOMS proxies Administrative tools available to update the DB mapping table:  To create VO groups in advance  To keep same uid when DN changes  To get same uid for a DN and a Kerberos principal

45 Workshop Storage, 20-21 Marzo 2006 - 45 Access Control Lists LFC and DPM support Posix ACLs based on Virtual Ids  Access Control Lists on files and directories  Default Access Control Lists on directories: they are inherited by the sub- directories and files under the directory Example  dpns-mkdir /dpm/cern.ch/home/dteam/jpb  dpns-setacl -m d:u::7,d:g::7,d:o:5 /dpm/cern.ch/home/dteam/jpb  dpns-getacl /dpm/cern.ch/home/dteam/jpb # file: /dpm/cern.ch/home/dteam/jpb # owner: /C=CH/O=CERN/OU=GRID/CN=Jean-Philippe Baud 7183 # group: dteam user::rwx group::r-x #effective:r-x other::r-x default:user::rwx default:group::rwx default:other::r-x

46 Workshop Storage, 20-21 Marzo 2006 - 46 DPM: Comments and future L’implementazione di SRM2.1 non è ancora ne completa ne a “production level” Mancano ancora molte funzionalità avanzate (utili per siti grandi o amministratori esperti) Stabilità operativa da provare Performance su WAN da indagare Scalabilità nell’ordine delle centinaia di Tb e di pool da dimostrare La filosofia che guida lo sviluppo privilegia piuttosto la velocità che la stabilità operativa

47 Workshop Storage, 20-21 Marzo 2006 - 47 SC4 / pilot WLCG Service Workshop (1/2)

48 Workshop Storage, 20-21 Marzo 2006 - 48 SC4 / pilot WLCG Service Workshop (2/2)

49 Workshop Storage, 20-21 Marzo 2006 - 49 Conclusioni Feedback dai siti è prezioso!  è necessario pianificare le attività di test (vedi SC4 WLCG Service Workshop) L’uso di SRMv2.1 è stato “spostato” in futuro  Anche a causa del ritardo nell’implementazione da parte dei software di SRM I test fatti con dCache coprono le esigenze di eventuali Tier2 (sia per SC4 che per l’attività a regime), per il tier1 (come scala e come performance) non sono ancora sufficienti Sarebbe utile capire l’interesse dei vari Tier2 su questi sistemi per cercare di capire su cosa concentrare i test  Sia come sistemi, sia come funzionalità Sarebbe utile fare degli stress test (simili a quelli fatti al CNAF per dCache) su DPM (che siano lunghi e complessi) per mettere alla prova l’affidabilità del sistema oltre che le performance. Sono necessari test di interoperabilità fra i vari SRM (sono mandatori anche per quello che viene riportato in “SC4 WLCG”) Interazione più stretta con gli sviluppatori dei vari sistemi. Dare dei suggerimenti sul sistema da adottare non è facile e molto dipende dal man-power disponibile e dalle esigenze che si devono soddisfare

50 Workshop Storage, 20-21 Marzo 2006 - 50 Ringraziamenti & Riferimenti Ringraziamenti:  Vincenzo Spinoso, Vincenzo Vagnoni,  Daniele Bonacorsi  Simone Badoer, Emidio Giorgio  Giuseppe Lo Re, Pierpaolo Ricci, Vladimir Saputenko  Jean Philippe Baud, Patrick Fuhrman Riferimenti:  Wiki Gruppo Storage: http://grid.ct.infn.it/swiki/  LCG Baseline Services Group Report http://lcg.web.cern.ch/LCG/peb/bs/BSReport-v1.0.pdf  Storage Resource Management Working Group: http://sdm.lbl.gov/srm-wg/  Tests on Storage Managers http://pccms3.cmsfarm1.ba.infn.it/~storage/TestSuite.html  SC4 / pilot WLCG Service Workshop http://agenda.cern.ch/fullAgenda.php?ida=a056461