KLOE - Referee Paolo Checchia, Luca Lista, Ezio Menichetti, Pierluigi Paolucci con l’aiuto sostanziale di Luca dell’Agnello, Mauro Morandin CSN1

L’incidente La più nuova delle due tape library di KLOE ha mostrato una serie di errori di lettura e la rottura di due drive (sostituiti) a partire dal 16/06/2010 L’analisi dei danni si è conclusa il 24/02/2011, presso gli "IBM Media Development Laboratory", Tucson, AZ Rilevata contaminazione da insetti –6 cartucce hanno mostrato residui di insetti schiacciati Un analogo incidente è stato riportato anche a Fermilab [ * ] [ * ] CSN1Luca Lista2

Entità del danno Le cartucce potenzialmente contaminate sono 640 su 2800 (non si sa esattamente quante) –640 potenzialmente contaminate: 139 contengono dati RAW (non riproducibili!) 501: dati ricostruiti, DST, MC (riproducibili) – = 2160 incontaminate 316 con dati 1844 vuote –Tape size: 1TB/620 GB Il materiale (i drive!) contaminato non è considerato in manutenzione dall’IBM CSN1Luca Lista3

Proposta iniziale di KLOE La library più vecchia, incontaminata, potrebbe ospitare nuovi drive, le 2160 cassette incontaminate e nuove cassette da acquistare –Necessario acquistare: 12 drive nuovi 500 cassette nuove 64 TB di disco da usare come buffer per il riversamento –Costo stimato: ~ k€ (trattativa da avviare con IBM) –Valore di riferimento: gara fine 2009 Vanno comunque recuperati i RAW data ora registrati sui 139 nastri contaminati –Il costo per il “cleaning” dell’IBM: 5k€/nastro = 700k€ !!! –Necessario inviare i nastri in USA… CSN1Luca Lista4

Due problemi da affrontare Due problemi vanno affrontati separatamente e con priorità diverse: 1.Garantire a KLOE capacità di storage per la presa dati –Il sistema deve essere efficiente per il processamento (RAW  RECO  DST) e per la successiva analisi (DST) 2.Avviare il recupero dei dati e possibilmente del materiale contaminato (principalmente i drive) –Probabilmente un’attività penosa, ma visti i prezzi proibitivi è necessario fare un tentativo in casa –Se l’intervento funziona si potrebbero recuperare i drive e i nastri, almeno in parte –La library va comunque spostata dal luogo attuale CSN1Luca Lista5

Alternativa: la library del CNAF CSN1Luca Lista6 20 drives T10Kb IBM (1 TB, 1GB/s,  5TB; KLOE ne ha 12) Usata principalmente da esperimenti LHC, ma risorse sufficienti per lo storage di KLOE 4  10 PB nel 2011 (  upgrade a 20 PB nel 2012) + ~100TB di buffer disco –Al mese, assumendo ½ fb -1, KLOE ha bisogno di ~0.28 PB: 120 TB di RAW, 80 TB di RECO, TB di DST-dati, 50 TB di DST-MC Sistema già usato da KLOE (con protocollo TSM) Accesso a files su tape automatico quando si accede al file system GPFS, come se fosse un’area disco normale KLOE non usa un vero HSM e neanche SRM (gestisce “a mano” il pre-staging dei files)

Throughput library Esigenze di KLOE: ~200 MByte/s –50 MByte/s DAQ –50 MByte/s processing –50 MByte/s concurrent processing –50 MByte/s analisi La library ha mostrato performances sufficienti (×2.5) Necessario un upgrade di rete (300Mbit/s  1÷2Gbit/s), che dovrebbe essere fattibile senza troppi problemi Upgrade utile anche per il T2 di ATLAS CSN1Luca Lista7 Test fatti al CNAF con la library in questione

Uso dei nastri al CNAF Al momento, KLOE usa massicciamente i nastri, anche per l’analisi, per mancanza di spazio disco sufficiente come buffer Un uso “tal-quale” della library al CNAF è forse fattibile, con un upgrade di rete, ma sarebbe sub-ottimale L’uso dei tape principalmente come archivio dei RAW data per i (ri-)processamenti consentirebbe di ridurre il numero di stage dei nastri, quindi lo stress meccanico Necessario un buffer disco più ampio, solo per i DST, per garantire un accesso veloce per l’analisi Sembrerebbe un uso ragionevole, e migliorerebbe anche il workflow dell’analisi attuale CSN1Luca Lista8

Soluzioni analizzate (A) Copia o backup dei RAW data al CNAF Necessario comunque upgrade della library incontaminata Soluzione completamente da testare Copia  necessario rivedere il software per l’archiviazione, traserimento al CNAF e popolazione del DB con i dati relativi Backup  uso di TSM a basso livello, device FC-over-IP (disponibile al CNAF, da comprare a LNF, mai testato!) Espressi dubbi sulla sicurezza per il trasferimento dei dati in questo modo (B) Storage dei RAW al CNAF, processamento RECO a LNF e buffer disco con DST a LNF Il buffer disco evita la necessità di una library locale 135 TB di dati di KLOE TB per ogni fb -1 di KLOE-2 Upgrade di banda:1÷2GB/s Da definire il modo in cui effettuare le copie remote (GRID-FTP, …) Revisione del software di archiviazione e trasferimento comunque necessaria CSN1Luca Lista9

Soluzione estrema (C) Spostare l’intero sistema di calcolo di KLOE al CNAF Limitati gli interventi sul software Dopo una iniziale considerazione è apparsa troppo rischiosa e probabilmente troppo onerosa per il CNAF Si potrebbe riconsiderare dal 2012 in poi, con l’installazione dei nuovi detector CSN1Luca Lista10

Proposta su come procedere La proposta (B) appare la soluzione più solida sia sul breve che sul lungo termine. Proponiamo di: Avviare quanto prima la connessione con la library al CNAF per archiviare i nuovi dati Definire il piano degli interventi da fare per l’integrazione –es.: upgrade del software Aumentare lo spazio disco come buffer per l’analisi Avviare in parallelo la procedura di recovery, cercando di salvare il salvabile Valutare l’esito della strategia tra qualche mese (pochi…) –alla luce dei benchmark misurati col nuovo sistema, e di quanto si sarà potuto recuperare CSN1Luca Lista11

Altre richieste Bari, ME: + 4k€OK LNF, CON: +17k€OK –impegno per gara He Entrambe le richieste sono coperte dai s.j. assegnati a settembre su ME e CON a LNF CSN1Luca Lista12

Conclusioni La soluzione che richiede meno sforzo (acquisto di nuovi drive e nastri) è anche la più costosa La library al CNAF sembra adeguata, vanno dettagliati gli interventi da fare Il ripensamento dell’uso dei nastri limitato al ri- processamento e del disco per l’analisi potrebbe anche portare un miglioramento rispetto al modello attuale CSN1Luca Lista13