19 Ottobre 2012ATLAS Milano1 Stato delle risorse locali di calcolo L. Carminati, L. Perini, D. Rebatto, L. Vaccarossa

19 Ottobre 2012ATLAS Milano2 Argomenti :  Breve descrizione del Tier2 di Milano (macchine, disco etc) e summary delle performance  Discussione principali problemi osservati negli ultimi tempi  Overview delle principali modalita’ di utilizzo delle risorse di calcolo da parte dei diversi working groups di Milano  Analisi (quasi) post mortem del recente crash del disco  Contromisure e prossimi passi

19 Ottobre 2012ATLAS Milano3 Il TIER 2 di Milano in pillole  CPU : al momento stiamo ospitando circa 1100 job slots  CPU : al momento stiamo ospitando circa 1162 TB di disco (sfondata la soglia del PetaByte)  Il disco e’ organizzato in 8 ‘storage’ per un totale di ~ 50 jbod e piu’ di 500 dischi  Ogni storage ha due controller (ridondanza)  Ogni jbod e’ configurato in RAID6 ( ie si possono rompere fino a 2 dischi senza perdere dati)  Al momento abbiamo :  650TB per DATADISK  200 TB di groupdisk  120 TB di localgroupdisk (+ spippioli )

19 Ottobre 2012ATLAS Milano4 Il TIER3 di Milano in pillole  CPU : 8 macchine da 24 cores (totale 192 cores) per il cluster PROOF e 6 macchine da 8 cores ( 48 cores ) su tier3 (code batch)  Disco : 120 TB per LOCALGROUPDISK (visibile dalla grid) + 30 TB di spazio scratch (“storage4”) + le home degli utenti (separate e quotate)  Stato di occupazione attuale : 100 TB ( su 120)  Localgroupdisk e’ nello stesso filesystem storage_2

19 Ottobre 2012ATLAS Milano5 Come gli utenti milanesi utilizzano le risorse  Accesso diretto ad ntuples di gruppo (ATLAS) su GROUPDISK : Il gruppo di fisica produce centralmente ntuple di gruppo inviate automaticamente a Milano via Production system  utilizzato per analisi di fotone  si usa spazio pledged come locale  sfruttano tutte le potenzialita’ del production system  Skimming di ntuples di gruppo su altri siti via prun. Si gira un codice di skimming su ntuple di gruppo prodotte centralmente ( ma che non necessariamente stanno a Milano ) e si sottoscrive l’output a Milano  utilizzato da analisi SUSY, MissingET  ciclo tipico alcuni giorni sul tipico dataset ICHEP  Utilizzo di skims gia’ esistenti : gruppi di fisica producono streams di ntuple gia’ skimmate in modo semi-ufficiale. Gli skims vengono semplicemente sottoscritti a Milano  utilizzato dal gruppo H->tau tau  sottoscrizioni problematiche : fino a 2 o 3 settimane per il tipico dataset ICHEP

19 Ottobre 2012ATLAS Milano6 Le performance del sito  Il TIER2 di Milano e’ un T2D (in classe alpha), la categorizzazione piu’ alta tra I T2.  Possiamo ospitare groupdisk  Soffriamo un po’ il confronto con gli altri TIER2 italiani : 87% contro 91%-NA, 95-RM e 96%-FR ( finestra degli ultimi 6 mesi, a noi particolarmente sfavorevoli )  Il nostro comportamento e’ mediamente in linea con gli altri : alcuni grossi incidenti  Stacco di corrente  Sostituzione di un disco in un jbod E4  Sostituzione di un controller

19 Ottobre 2012ATLAS Milano7 Analisi degli incidenti con lo storage  Allo stato attuale abbiamo circa 500 dischi, la probabilita’ di avere crash di un singolo disco non e’ trascurabile  Gli storage systems sono disegnati in modo da sopportare in modo trasparente la rottura di un disco o di un controller  l’informazione e’ ridondata. Il disco viene sfilato e sostiuito senza spegnimenti e l’informazione di nuovo ottimizzata  Ai primi di giugno abbiamo avuto un problema di questo tipo con un disco in uno storage system di E4  la sostituzione ha generato il primo crash  Lungo lavoro di diagnosi con E4 e IBM : ipotesi di un controller difettoso  Sostituzione del controller sotto la guida diretta dei tecnici E4 ( e chiamata aperta con IBM ) : secondo incidente.

19 Ottobre 2012ATLAS Milano8 Gestione situazione post-incidente  Immediatamente attivato il sistema centralizzato di recovery : il sistema controlla se esiste una replica dei files danneggiati e ripristina il file  Sistema di recovery particolarmente lento : messa a disposizione un’area temporanea scratch ( rubata al disco pledged ! )  Nel frattempo per alcuni gruppi i datasets su localgroupdisk erano diventati obsoleti  risottoscritti nuovi datasets su localgroupdisk ( lento ! )  dq2-get diretto sull’area temporanea  Gli utenti si sono salvati tramite il dq2 diretto sull’area temporanea con un ritardo medio di 2-3 giorni  il gruppo tau ha avuto particolari problemi presumibilmente legati alla lentezza del trasferimento dei loro datasets  migliaia di sottoscrizioni accodate principalmente sui datasets tau  stiamo cercando di capire la ragione della lentezza di questo tipo di sottoscrizioni

19 Ottobre 2012ATLAS Milano9 Datasets tau  Abbiamo fatto dei test dettagliati comparando le caratteristiche di datasets ‘lenti’ rispetto a datasets ‘veloci’ : caso considerato : dati 2012 periodi A+B  Datasets ‘veloci’ :  size totale : 400 GB  numero di dataset ~ 200  numero di files totale ~ 400  Datasets ‘Lenti’  size totale : 400 GB  numero di datasets ~ 100  numero di files totale 8000  Non abbiamo ancora una misura definitiva ma il numero totale di files e’ un indiziato forte:  ritentare il trasferimento dopo un merging per misurare la velocita’ (ongoing)

19 Ottobre 2012ATLAS Milano10 Prossimi passi Molte discussioni per capire come procedere al meglio per ottimizzare l’uso delle risorse (aggiungere spazio!) e minimizzare i rischi per gli utenti  Ristrutturare il filesystem in disk pools : failures in DATADISK per esempio non si ripercuotono su LOCALGROUPDISK  Separate fisicamente LOCALGROUPDISK dal resto :  Cambiare completamente il tipo di hardware : muovere a sistemi NAS, 10K euro per 70 TB : sempre in RAID6 ma controller NON ridondati  Con avanzi di gara potremmo comprare 2 sistemi (140TB lordi) e muoverci sopra LOCALGROUPDISK  Eventualmente potremmo aggiungere altri 70 TB con fondi ‘locali’