ATLAS PRIN Alessandro De Salvo A. De Salvo – 12 novembre 2015 Cloud Computing Condivisione di risorse tra gruppi EventIndex LHCONE PoD T2D

Cloud Computing  Utilizzo del Cloud Computing per servizi o elaborazione dati  Servizi di grid  Workload Management  Servizi interattivi on-demand  Virtualized WN con Panda  Cluster di analisi su Cloud  Data Preservation  Altri tipi di servizi in alta affidabilità Roma 2

Cloud Computing: risultati  Test su OpenStack (Grizzly -> Kilo)  Implementazione e test dei principali servizi grid in cloud  WN/UI  Inclusi test di elasticità e interfacciamento con batch system  Squid  Scaling e performance aggregation con LBaaS  Integrazione con servizi di intallazione e configurazione  Integrazione dell’infrastruttura e della contestualizzazione con Foreman/Puppet  Test con Docker e Ansible (Kollaglue)  Integrazione con altri servizi per HA e scalabilità  Ovirt  Percona XtraDB  Applicazione dei risultati al progetto di Tier2 Distribuito  Sviluppi futuri  Integrazione completa con il Tier-2 Distribuito  Test con altri sistemi di storage (CEPH, DynaFed, …)  Completa elasticità dei servizi 3

Condivisione di risorse tra gruppi  Condivisione delle stesse risorse utilizzate per il lavoro su Grid nel centro locale ATLAS Tier-2  Condivisione di risorse tra gruppi diversi  Creazione di comunità di utenti con servizi uniformi di calcolo a livello dipartimentale  Capacità di utilizzo di risorse di calcolo distribuite Milano 4

Condivisione di risorse tra gruppi: risultati  Implementazione di un super-pool HTCondor multi-gruppo  Sistema capace di far coesistere job di tipo multi-core e single-core in modo dinamico  Possibilità di run di job paralleli  Implementazione di un sistema di monitoring  Basato su Ganglia  Risorse di storage basate su CEPH  Sviluppi futuri  Inclusione di più gruppi  Utilizzo concorrente di risorse del Tier-2  Ulteriori test e miglioramenti con CEPH 5

EventIndex: Progetto nel PRIN  Studiare la possibilità di semplificare il TagDB di ATLAS trasformandolo in un indice degli eventi (EventIndex) con puntatori allo storage che contiene gli eventi in vari formati (da RAW a NTUP)  EventIndex è l'equivalente del catalogo di una biblioteca  Sostituzione del database in Oracle con storage strutturato (Hadoop)  Divisione delle tre categorie di dati nei Tag:  Identificazione dell'evento e quantità immutabili (lumi block, trigger pattern)  Quantità dipendenti dalla ricostruzione (topologia, particelle, ecc.)  Puntatori ai files con gli eventi (GUID e offset interni)  Utilizzazione della tecnologia più appropriata per ogni categoria di dati  Sviluppo (o adattamento) dei servizi esterni: event counting, picking, skimming, consistency checks  Connessione a ProdSys e DDM per l'upload dei dati e la loro utilizzazione 6 Genova

EventIndex: risultati  Tutti i componenti più mportanti sono stati implementati e sono funzionanti  Data Collection (Producer/Consumer)  Stoccaggio dei dati in HDFS  Organizzazione dei dati in Hadoop e indicizzazione  Interfaccia di decoding del trigger  Sistema di query: interfacce CLI, Web e per event picking (EventLookup)  Monitoring in Kibana al CERN  Dati del Run-1 importati e funzionamento a regime per il Run-2  Sviluppi futuri  Ottimizzazioni  Ulteriore automazione del data flow  Interconnessioni di sistema e miglioramenti al monitoring  Controlli automatici di completamento di produzione 7

PoD per PBS, gLite-WMS e Panda  Perfezionare e testare PoD, Proof on Demand, un insieme di tool pensati per instanziare, on demand, su richiesta dell’utente, un cluster PROOF con risorse di calcolo non dedicate ma gestite da un generico RMS locale o globale  Batch system  gLite-WMS  PanDA  Test del plugin di PoD per Panda, con i dati acceduti con protocollo XrootD/FAX e protocollo file: tre diverse analisi reali e test di solo accesso al disco, sulla Cloud IT e CERN  Test di performance di accesso al disco  Job che legge circa 40% dell’evento  Test di “calibrazione” con solo accesso al disco in lettura (dell’intero dato)  Utilizzati: DPM, StoRM/GPFS, EOS  FAX  LAN, WAN  Test di latenza di startup LNF Milano 8

PoD per Prodsys2, Federazione HTTP e Dynamic Workers Addition  Prodsys di ATLAS evolve con Prodsys2: configurare PoD e JEDI per poter ancora eseguire PoD con PanDA  PROOF aggiornato con dynamic workers addition  Questo risolve il problema dello spreco di risorse e dei tempi di attesa: la startup latency viene notevolmente ridotta  Studi di startup latency ripetuti e confronto con risultati 2013  ROOT viene aggiornato per accedere ai dati con protocollo HTTP  Ripetuti test di accesso con HTTP  Testato il test bed della Federazione HTTP LNF 9

PoD: risultati  Effettuati test completi del plugin di PoD per PanDA con analisi reali  Effettuati studi approfonditi della startup latency e test con la funzionalità di dynamic workers addition  Effettuati test approfonditi di accesso al disco con XrootD/FAX e protocollo file  Effettuati test con HTTP/Federazione HTTP  Sviluppi nell’immediato futuro:  Ripetere anche con Prodsys2 un’attività di test più intensiva con più utenti e diverse analisi “reali” e con accesso al disco con protocollo XrootD e HTTP  Ripetere test di “calibrazione” con versione attuale, più matura, della federazione HTTP. 10

LHCONE  Sviluppo di una nuova generazione di reti geografiche di comunicazione dati (overlay L2 network) denominata LHCONE (LHC Open Network Environment)  Configurazione dinamica degli apparati attivi (router o switch multilayer) che costituiscono la rete stessa  Realizzazione di servizi di Bandwidth on Demand (BOD)  Integrazione con il software di esperimento Napoli 11

LHCONE: risultati  Integrazione di tutti i siti in LHCONE  Sistemi automatici di monitoraggio delle performance di rete e tracciamento dei problemi  Scrittura della documentazione  Sviluppi futuri  Continuare la sperimentazione con i protocolli SDN 12

Tier-2 Distribuito  Realizzazione e test di un prototipo di Tier-2 distribuito tra Napoli e Roma  Infrastruttura di rete comune con collegamento Point-to-Point tramite VLAN dedicata (GARR)  Storage distribuito sincrono, in modo da poter effettuare operazioni di failover e/o crash recovery  Utilizzo di una infrastruttura ad alta affidabilità per i servizi di base  Utilizzo di una infrastruttura Cloud per la gestione dei servizi e per il running dei payload utente  Studi di affidabilità del sistema, scalabilità e failover attivo trasparente di un intero sito Tier-X Napoli Roma 13

Tier-2 Distribuito: risultati  Analisi di fattibilità per un Tier-2 Distribuito  In collaborazione con il GARR  Misure di latenza, performance e affidabilità del sistema di storage  Simulazione di siti geograficamente distribuiti O(1000) km  Fine tuning per ottenere l’affidabilità necessaria per un sistema di produzione  Analisi di resilienza e affidabilità del workload (VM) intra-sito  Fine tuning di storage e rete per ottenere la resilenza necessaria per crash recovery/migrazione/alta affidabilità di due o più siti  Sviluppi futuri  Estensione completa dell’infrastruttura di Cloud al Tier-2 Distribuito  Inclusione di altri siti e cambio di tipologia di rete (MPLS) 14