Tier-2 Legnaro-Padova Massimo Sgaravatto (INFN Padova) On behalf of the Legnaro-Padova T2 team Tier-2 Legnaro-Padova 1

Legnaro-Padova di nome e di fatto Tier-2 distribuito tra due sedi Condivisione di risorse hardware WNs distribuiti nei 2 siti Servizi (Computing Elements, Storage, VOBOX) a Legnaro Servizi di monitoring (Ganglia, Nagios, Cacti,…) a Padova Condivisione del personale Gestione: M. Biasotto (LNL), A. Crescente (PD), S. Fantinel (LNL), R. Ferrari (PD), G. Maron (LNL), M. Sgaravatto (PD)  Tutto personale strutturato  Coinvolgimento del personale dei Servizi Calcolo quando necessario Contatti con l’esperimento: A. Dainese (PD), A. Festanti (PD), L. Vannucci (LNL) Tier 2 di Alice e di CMS Tier-2 Legnaro-Padova 2

Infrastruttura Legnaro 220 KW di potenza elettrica 5 UPS da 80 KVA (condivisi con la Divisione Acceleratori) Gruppo elettrogeno da 630 KVA (condiviso con la Divisione Acceleratori) 2 chiller (capacita` di smaltimento del calore: 240 KW) 22 racks APC con 11 cooler di raffreddamento in row Impianto antincendio Padova Sala ex Tier-A di Babar condivisa con CED della Sezione e Dipartimento 180 KW di potenza elettrica 1 UPS (appena upgradato) 4 chiller (capacita` di smaltimento del calore: 180KW) + cond. sala UPS 5 racks di tipo standard Impianto antincendio a gas Tier-2 Legnaro-Padova 3

Rete Tier-2 Legnaro-Padova 4 Padova LNL Garr-X NAT 10 Gb/s 15 km 20 Gb/s 10 Gb/s 1 Gb/s

Rete (cont.ed) Link dedicato al T2 a 10 Gb/s tra LNL e Padova Singola rete privata di classe B attestata a LNL per i WNs No routing all’interno del T2 Tutto il traffico da/verso l’esterno attraverso il router di LNL Migrazione a GARR-X avvenuta a Giugno 2 link a 10 Gbps, uno usato come backup dell’altro Uso dei 2 link in trunk in previsione futura Update NAT a 10 Gb/s + NAT ridondato in progress Raddoppio link LNL – Padova in prospettiva futura 5Keuro di overhead delle gare trasferiti a Legnaro spesi per potenziamento rete 10 Gb/s (acquisto switch e ottiche) Tier-2 Legnaro-Padova 5

Storage xrootd nativo Senza layer intermedi (gpfs, lustre…) 1 redirector (su macchina virtuale) + 7 server LNL) 386 TB ~ pieno da Agosto Attivita’ recenti: Update xrootd da v dbg a v Migrazione redirector su nuova macchina virtuale Non particolari problemi da segnalare Tier-2 Legnaro-Padova 6 2 Apple Xserve 7TBJan 07/Feb 08Dismissed in Nexan SataBeast 32 TB Jan 09Obsolete in Nexan SanaBeast 32 TB Jan 10 1 Nexan SanaBeast 65TB Jan 11 2 Dell PowerVault MD TB Jan 12

CPU e Job submission Services Risorse dedicate ad Alice: 70 WNs 1016 cores 9752 HS06 Comprendono 8 WNs (192 cores, 1584 HS06) installati a Giugno Possibilita` di usare le risorse di CMS quando non usate ( 110 WNs, 1384 cores, HS06) WNs Distribuiti tra LNL (~ 60 %) e Padova (~ 40 %) Singolo cluster LSF Recentemente migrati a EMI-2 (OS: SL5) 6 CREAM CEs LNL) SL5, EMI-1 Usati da tutte le VO 1 VOBOX LNL) SL5, gLite 3.2 (in attesa di VOBOX-LCG) Su macchina virtuale Tier-2 Legnaro-Padova 7

CPU time e done jobs da inizio anno Tier-2 Legnaro-Padova 8

Resource LNL-PD Tier-2 Legnaro-Padova 9 Sistemata conf. Alice LDAP (maxjobs era troppo basso) Sistemata conf. Alice LDAP (maxjobs era troppo basso)

Efficienza Roma, Tier-2 Legnaro-Padova 10

LNL-PD Tier-2 Legnaro-Padova 11

Torrent Migrazione a Torrent effettuata a meta` Novembre Issues Problemi spazio disco VOBOX  Load alto e molto i/o wait usando un disco accessibile via NFS  Risolto installando un disco locale Problemi spazio disco sui WN  Due cause –Job disk footprint molto piu` grande con Torrent »Spesso molto piu` dei 10 GB dichiarati nella ALICE VO card –Spazio disco di job falliti (in particolare quelli uccisi dal batch system) non liberato »Cancellato dal cleanup cron job solo giorni dopo  Soluzione –Esclusi i WN piu` vecchi con poco disco –LSF post-exec script che pulisce la directory del job al termine della sua esecuzione Tier-2 Legnaro-Padova 12

Torrent (cont.ed) Issues (cont.ed) Problemi nel download del torrent client (via wget) da alitorrent.cern.ch  Molti retries prima che il download riuscisse  Il problema era che il server scartava pacchetti per timestamp mismatch  Questo perche` in alitorrent era abilitato tcp_tw_recycle –Aumenta le prestazioni ma puo` causare problemi con connessioni NAT  Risolto (da Costin) disabilitando tcp_tw_recycle Molte connessioni Torrent provenienti da WN di altri siti, bloccate dal nostro firewall  Non tutti i siti bloccano il traffico torrent verso l’esterno –Dovrebbe essere permesso solo verso gli altri WNs del sito e verso alitorrent.cern.ch Migrazione a CVMFS a inizio 2013 ? Lo stiamo gia` facendo per le altre VO LHC Tier-2 Legnaro-Padova 13

Memory Molti job uccisi dal batch system perche` usano troppa memoria Attualmente 4.5 GB di MEMLIMIT per slot/core Nella ALICE VO card si dice che sono richiesti solo 2 GB per job … Per le altre VO non abbiamo un limite a livello di LSF Cron jon che gira ogni 5 minuti che uccide i job che usano troppa memoria se il WN e` in sofferenza Provato a usare lo stesso approccio con ALICE, ma non ha funzionato:  Burst di job con velocissimo aumento dell’uso di memoria che hanno rapidamente ucciso diversi WN  Non possiamo nemmeno bannare gli utenti “problematici” visto che i pilot runnano tutti con lo stesso user Tier-2 Legnaro-Padova 14

Expired jobs (~ 90% killed by batch system) Tier-2 Legnaro-Padova 15