Slides

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
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
Garr-X
Rete
LNL
Padova
10 Gb/s
20 Gb/s
20 Gb/s
1 Gb/s
NAT
10 Gb/s
15 km
Tier-2 Legnaro-Padova
4
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. 3.0.2.dbg a v. 3.1.1
Migrazione redirector su nuova macchina virtuale
Non particolari problemi da segnalare
Tier-2 Legnaro-Padova
2 Apple Xserve 7TB
Jan 07/Feb 08
Dismissed in 2012
1 Nexan SataBeast
32 TB
Jan 09
Obsolete in 2013
1 Nexan SanaBeast
32 TB
Jan 10
1 Nexan SanaBeast
65TB
Jan 11
2 Dell PowerVault
MD3600 130TB
Jan 12
6
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,
15099 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 Usage @ LNL-PD
Sistemata conf.
Alice LDAP
(maxjobs era
troppo basso)
Tier-2 Legnaro-Padova
9
Efficienza
Roma, 19.07.2012
Tier-2 Legnaro-Padova
10
Efficienza @ 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