Luca dell’Agnello 28 Agosto 2007 Storage Luca dell’Agnello 28 Agosto 2007

Reparto storage Gestione sistemi disco, tape Storage Area Network CASTOR, GPFS/StoRM Installazione, validazione, configurazione ed amministrazione Sistemi di storage e disk-server Gestione interfacce grid (e.g. SRM) Installazione, configurazione, gestione db Cataloghi (LFC), FTS, CASTOR, VOMS Conditions e configuration database (Atlas e LHCb) Gestione servizi FTS, LFC (sinergia con SA1)

Personale Giuseppe Lo Re (100%) – temporaneo (art. 23) SCAD. Nov. 07 CASTOR, SRM, FTS, NAGIOS Barbara Martelli (100%) – temporaneo (art. 23) SCAD. Nov. 07 DB, LFC Vladimir Sapunenko (100%) – temporaneo (art. 23) SCAD. Feb 08 GPFS, SAN, StoRM Dejan Vitlacil (100%) – temporaneo (AR) SCAD. Q3 08 CASTOR, libreria, SRM, MONITORING, ACCOUNTING 1 FTE assistenza db – da rinnovare DB Antimo D’Apice (100%) – temporaneo (co.co.pro.) SCAD. Dic. 07 Assistenza hw, SAN, tape-server, libreria Daniele Gregori (100%) – temporaneo (AR) SCAD. Q2 09 Back-up, assistenza hw, CASTOR Pier Paolo Ricci (100%) – permanente SAN, libreria, CASTOR Luca dell’Agnello – permanente

Storage classes @ CNAF Implementation of 3 (2) Storage Classes needed for LHC Disk0Tape1 (D0T1)  CASTOR Space managed by system Data migrated to tapes and deleted from when staging area full Disk1tape0 (D1T0)  GPFS/StoRM Space managed by VO Disk1tape1 (D1T1)  CASTOR Space managed by VO (i.e. if disk is full, copy fails) Large buffer of disk with tape back-end and no gc

CASTOR 1 istanza di produzione + 1 istanza di test Istanza di test Name-server comune Istanza di test Test di upgrade, test srm 2.2 1 stager, 2 disk-server, 3 server con srm v. 2.2 Istanza produzione 4 server infrastruttura (stager, lsf, dlf, name-server) 2 server per db (name server, stager) 1 server per acsls (gestione libreria) 1 libreria STK L5500 (1 PB on-line) 12 tape server (7 9940b + 3 in ordine + 5 LTO2) 8 server srm v. 1.1 45 disk-server Sistema di monitoraggio/allarmistica (nagios) in funzione In test LEMON (disponibili alcuni sensori specifici per CASTOR)

CASTOR Setup (1) SAN 13 tape servers Core services are on machines with scsi disks, hardware raid1, redundant power supplies tape servers and disk servers have lower level hardware, like WNs Sun Blade v100 with 2 internal ide disks with software raid-1 running ACSLS 7.0 OS Solaris 9.0 45 disk servers attached to a SAN full redundancy FC 2Gb/s or 4Gb/s (latest...) connections (dual controller HW and Qlogic SANsurfer Path Failover SW or Vendor Specific Software) STK L5500 silos (5500 slots, partitioned wth 2 form-factor slots, about 2000 LTO2 for and 3500 9940B, 200GB cartridges, tot capacity ~1.1PB non compressed ) 6 LTO2 + 7 9940B drives, 2 Gbit/s FC interface, 20-30 MB/s rate (3 more 9940B going to be acquired). SAN 13 tape servers STK FlexLine 600, IBM FastT900, EMC Clarion …

CASTOR Setup (2) Name server Oracle DB (Oracle 9.2) CASTOR core services v2.1.3-15 on 4 machines Name server Oracle DB (Oracle 9.2) castor-6: rhserver, stager, rtcpclientd, MigHunter, cleaningDaemon Stager Oracle DB (Oracle 10.2) 2 SRMv1 endpoints, DNS balanced: srm://castorsrm.cr.cnaf.infn.it:8443 (used for disk pools with tape backend) srm://sc.cr.cnaf.infn.it:8443 (used for disk-only pool for atlas) srm://srm-lhcb durable.sc.cr.cnaf.infn.it (used as disk-only pool for lhcb) 1 SRMv22 endpoint: srm://srm-v2.cr.cnaf.infn.it:8443 castorlsf01: Master LSF, rmmaster, expert dlf01: dlfserver, Cmonit, Oracle for DLF castor-8: nsdaemon, vmgr, vdqm, msgd, cupvd 2 more machines for the Name Server and Stager DB

CASTOR Setup (3) Svc class Exp Disk pool Disk-servers Size (TB) alice 4 24 cms CMS cms1 12 110 atlas ATLAS atlas1 3 17 atlasdisk atlas1disk 118 lhcb LHCb lhcb1 11 lhcbdisk lhcb1disk 5 36 argo ARGO argo1 1 13 ams AMS ams1 pamela PAMELA pamela1 magic MAGIC archive1 2 condivisi 1.6 babar BABAR lvd LVD virgo VIRGO cdf CDF

Problemi con CASTOR Da prestazioni molto buone ….. 500/770 MB/s sustained/peak write … a instabilita’/inefficienze frequenti plugin rmmaster/LSF melt-down se # PEND jobs ≥ 1000 prepareToGet e putDone generano job LSF “inutili” Amministrazione catalogo stager necessita intervento manuale su db gsiftp is an external protocol. No way to tune parameters on the protocol (rfio, gsiftp) basis in order to limit disk servers load properly. Only possible modify the # LSF slots but it is not enough. GridFtp v2 will come as internal protocol, like rfio, but is not near. doc still poor Supporto ‘disk-only’ ancora non maturo Lentezza cancellazione file ATLAS ha impiegato giorni per liberare ~ 6 TB Draining dischi molto lento 2 Luglio 2007

Upgrade di CASTOR (1) Upgrade da v2.1.1-9 a 2.1.3-15. (9-11 Luglio) Nuovo plugin LSF - carico su db Oracle molto inferiore  Stabilita’ migliorata: non si verificano piu’ crash di rmmaster  Limite job passato da 1000 a 30000 Non vengono generati piu’ job per prepareToGet e putDone Le prestazioni sono soddisfacenti, tipicamente proporzionali alla quantita’ di disk server. Anche I/O su tape piu’ stabile. Pausa nei trasferimenti di CMS Accesso ai tape

Upgrade di CASTOR (2) Gestione dei pool DISK1TAPE0 ancora problematica  quando si riempie lo spazio disco le richieste vengono comunque accodate quasi impossibile per l’utente cancellare file da disco Altre issue: Necessario bilanciamento “manuale” carico disk servers. monitoring dei disk-server per evitare crash per sovraccarico Da studiare metodo per redistribuire i file piu’ richiesti recall da tape non ancora efficiente (vedi slide successive) Spesso necessario intervento manuale del gestore (anche su DB dello stager) Possibili inconsistenze tra catalogo dello stager e name server (i.e. file presenti su disco ma non nel piu’ name server) Rimozione file tramite procedure (lunghe e pesanti) tabelle del catalogo dello stager tendono ad esplodere. Cleaningdaemon non sufficientemente aggressivo procedure periodiche di cleanup (anche queste procedure sono pesanti e rischiano di degradare le prestazione dello stager) Repack ancora non supportato

Problemi recall da tape Tempistica dell'operazione e dinamica di gestione dell'operazione da parte dello stager impredicibili Variabilita' tempistica di esecuzione del recall legata a problemi di gestione del catalogo (bug: https://savannah.cern.ch/bugs/?17792) In tutti i diversi casi di errore (e.s. errori hw dei drive, o problemi di comunicazione tra le macchine di CASTOR, o temporanea indisponibilita' del disk server scelto per il recall, o problemi di accesso al filesystem scelto per il recall, etc..) lo stager dichiara fallito il recall  tuute le successive richieste rimangono in attesa fino all’interveto dell'amministratore stager effettua recall non necessariamente sul server piu' vuoto: se file viene scritto su volume con occupazione prossima al 90%, e’ altamente probabile che venga cancellato dal gc Caso dei job di merge di CMS (Agosto 2007) CMS usa solo SC T1D0 (esperienza di CSA06 con T0D1 di CASTOR ha dimostrato inadeguatezza)  necessario recall da tape file per job di merge Failure di recall di (almeno) 10%  ecatombe di job T1D0 non “ottimale” per questo uso (servirebbe D1T0)

Workaround per problema recall Implementazione procedura per forzare recall 2 tipologie principali di problemi generazione lista tape che nel catalogo dello stager risultano in stato FAILED contenenti file in stato WAITPERRECALL da troppo tempo (> 6 h) query sul db per estrarre tutti i file in questo stato ed individuare tape modifica stato dei tape da FAILED a PENDING per forzare il retry statisticamente ~ 50% recall file hanno successo generazione lista aggiornata e si forza il gc azione su db: si pone in GCCANDIDATE la replica su cache in stato WAITPERRECALL Si effettua restart della richiesta In studio differenziazione policy del gc in base alle diverse classi di file (eventualmente usare la SC D1T0). Settembre (G Lo Re, DB per CMS)

Problemi trasferimento CMS Problemi legati a CASTOR, dCache e FTS Configurazione di default del canale FTS, globus-url-copy, provoca, con l'accoppiata dcache/castor, un rate di trasferimento molto basso che produce timeout in FTS e/o Phedex senza evidenziare errori srm o gridftp. Problemi osservati da LHCb (senza Phedex) anche tra CERN e PIC Necessario variare la modalita’ di trasferimento da globus-url-copy a srmcopy. Modifica effettuta sui canali FTS PISA-T1, BARI-T1 e LEGNARO-T1 Calo efficienza dei server FTS carico eccessivo della CPU del cluster di back-end Oracle Attivata procedura puliza il db (sposta storico in tabella apposita) Problemi db CASTOR Entry spurie in db name service CASTOR Presenza file di dimensione 0 (dovuti a trasferimenti falliti) Provoca ulteriori fallimenti (tutte le ripetizioni) Phedex dovrebbe ripulire Entry spurie in db stager Pulizia sistematica effettuata Problema cache DNS di dCache (VM java) End-point CASTOR bilanciato via DNS Cache DNS non viene invalidata e quindi viene usato sempre solito end-point 2 Luglio 2007

“Task force” trasferimenti T1   T2 CMS Attivita’ congiunta CMS, T2, T1, SA1 Debug canali FTS T1   T2 Validazione “continua” Nessun end-point e’ perfettamente stabile Attivita’ in corso Procedura “oliata” ma articolata e time-consuming Da integrare con canali ATLAS

Strategia a lungo termine Attualmente setup molto semplice: un solo disk pool per SC per esperimento Occorre: diversificare policy del Migrator e del Garbage collector in funzione del tipo di file (lavoro in corso) eventualmente differenziare i disk pool tra quelli dedicati ai trasferimenti e quelli dedicati all’accesso dai WN. Necessario aumentare no. disk-server Installazione stager dedicato per esperimenti maggiori Esperienza di RAL da analizzare Issue della migrazione Issue del management NON ESISTE INTERFACCIA AMMINISTRAZIONE Implementazione D1T0 con GPFS/StoRM

Test di validazione infrastruttura storage LHC is coming  Last chance to finalize the technical issues of our setup Need to validate and perform final tests of CNAF storage infrastructure Validation of network interconnection with the farm Validation the SAN setup Validation of new hardware (EMC CX3-80) Storage system tuning and performance measurement CASTOR GPFS/StoRM Get use of Large file system with GPFS (>100 TB) Test of other storage systems (mainly for Tier2s) Xrootd dcache

Test-bed layout 1 Gbps 1 Gbps BD 1 Gbps

Sequential I/O throughput 5GB files (block size=64K) ~1100 CPU slots 8 wn racks 16 Gbps network available Read Write

A real analysis case: LHCb DaVinci 1000 analysis jobs running on production farm and accessing data via dCache, Xrootd and GPFS Network stats reported Test Total time [s] Avarage CPU usage (%) GPFS 9500 36.43 Dcache 14500 22.69 Xrootd 16000 21.17

Sequential I/O throughput summary Test TB tbt Transf. TB TB Network Disk Net Ratio Efficiency (%) Average Network Rate (GB/s) GPFS 5.29 5.21 5.56 0.94 98.43 1.16 Castor 4.52 4.49 4.89 0.92 99.37 0.82 Dcache 5.24 5.22 5.43 0.96 99.51 0.77 Xrootd 5.59 100.00 0.85 write Test TB tbt Transf. TB TB Network Disk Net Ratio Efficiency (%) Average Network Rate (GB/s) GPFS 5.21 5.53 0.94 100.00 1.43 Castor 4.49 4.11 4.37 91.58 1.13 Dcache 10.44 10.18 10.71 0.95 97.52 1.29 Xrootd 10.49 11.10 99.54 1.00 read TB tbt: foreseen TB based on the number of jobs effectively running Transferred TB : TB written on disk Efficiency: percentage of effectively transferred files Average Network Rate (GB/s): mean of 5 mns. mean values

GPFS Total 286 TB 29 disk-servers 20 file-systems off-line (due to HW failure) 8 TB 29 disk-servers 20 file-systems file-system size (min/max): 4/48 TB Disk-server/file-system (min/max) 2/4 File-system parallelo Ridondanza nell’accesso allo storage Fail-over efficiente Accesso nativo (POSIX) da wn Test LHCb, BABAR (70 TB da xrootd a GPFS)

Test con srm 2.2 End-point CASTOR e StorRM per PPS 2 server per CASTOR 4 server gridftp/GPFS, 2 server FE StoRM, 1 BE StoRM (Mysql) Test in corso (LHCb, successivamente ATLAS e CMS) LHCb ha gia’ effettuato throughput e stress test con StoRM (slide successive) Test dCache IN2P3  StoRM CNAF per VIRGO Per trasferimento dati LIGO Setup completato fine Luglio Test dCache srm 1.1 BARI   StoRM CNAF Primi test funzionalita’ in corso

StoRM: test trasferimento Sequenza test: prepareToPut, polling requestStatus, globus-url-copy, putDone, ls (per verificare la size del file trasferito) Rate CERN  CNAF: 360 MB/s Circa 20 TB trasferiti

StoRM: test di cancellazione 18 TB sono stati rimossi in circa 1600 secondi, (~ 27 minuti). L'effetto a gradini e' dovuto alla velocita' di aggiornamento dello spazio libero di GPFS, che ritarda qualche secondo. La rate di cancellazione e' praticamente costante Importante controllare in modo efficiente e rapido l'occupazione dello spazio disco

Evoluzione sistemi di storage Articolazione risorse CASTOR - Lo Re, Ricci, Dejan Differenziazione policy gc e “migratore” Settembre Splitting STAGER da concordare con gli exp Specializzazione disk-pool Q4 Consolidamento CASTOR - Ricci, Dejan, Martelli Ridondanza servizi principali (load balancing via DNS) Q1 08 Migrazione su RAC dei db (stager, ns) SLIDE SUCCESIVA GPFS - Vladimir + StoRM Test spostamento dati tra CASTOR e StoRM Settembre Test integrazione con storage pool esterno (es. CASTOR) Migrazione a SRM 2.2 - Giuseppe, Dejan, Vladimir Ottobre Migrazione a FTS 2 – SA1, Dejan Settembre

Database: Stato e sviluppi Db componente essenziale vari servizi (CASTOR, FTS, LFC etc…) Attivita’ in ambito LCG3D Tutti i db sono sotto backup con tool specifico (RMAN) Cluster per CASTOR – in fase di acquisto Attualmente db installati su server singoli (db sotto back-up) Upgrade 10g db ns CASTOR singola istanza Ottobre Cluster Grid FTS (migrazione a FTS 2 prevista per prima settimana Settembre) LFC “locale” (Atlas, Alice) Cluster per ATLAS (Repliche dei condition database) Effettuato con successo test di recovery del fallimento streams Stress test eseguiti da ATLAS sulla replica del CNAF La replica e’ risultata stabile, supporta fino a 75 job simultanei, 1000 job all’ora senza sostanziale degrado delle prestazioni. Ulteriori test in corso. Aggiunta del terzo nodo prevista Ottobre. Cluster per LHCb (LFC/Repliche dei condition database) installato Da migrare su nuovo hw - Settembre Cluster per LEMON - Settembre Test di replicazione VOMS Testbed locale con master e replica database replicati via Streams. Testbed consegnato agli sviluppatori per i functionality test. Setup CERN – CNAF Q4.

Prossimi acquisti In ordine espansione CX3-80 (~ 200 TB) Operativo per fine Q3 Da indagare possibilita’ acquisto DAS (per CASTOR) Avviata procedura per acquisto tape (su ME) Espansione storage/ # server per database (indagine di mercato in corso) Nel 2008 pledged 2. PB disco, 2.1 PB tape + non LHC Da acquistare ~ 2 PB raw disco Nuova libreria per soddisfare requisiti exp LHC (e non LHC) L5500 contiene tape per un massimo di 1 PB on line 2 soluzioni possibili: SUN SL8500 10000 slots (currently for 500 GB tapes 1 TB in 18 months) and up to 80 T10000 drives IBM 3584 7000 slots (currently for 500 GB tapes) Richiesta approvata dal CD Luglio