Applicazione di INDIGO a CMS per creazione di dynamic on-demand analysis clusters su risorse opportunistiche. INDIGO-DataCloud MidnightBlue Tutorials Days.

Presentazione sul tema: "Applicazione di INDIGO a CMS per creazione di dynamic on-demand analysis clusters su risorse opportunistiche. INDIGO-DataCloud MidnightBlue Tutorials Days."— Transcript della presentazione:

1 Applicazione di INDIGO a CMS per creazione di dynamic on-demand analysis clusters su risorse opportunistiche. INDIGO-DataCloud MidnightBlue Tutorials Days RIA Daniele Spiga: INFN-PG

2 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Outline LHC computing: Stato dell’arte ed evoluzione Motivazioni e Obiettivi Fronteggiare le esigenze del calcolo attese dall’evoluzione di LHC CMS Workload Management system: HTCondor GlobalPool Dynamic on-demand analisys cluster: Architecture Authentication and Authorization, Automation, PaaS orchestration Demo Prossimi passi Conclusioni 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

3 LHC Computing: Stato dell’arte
CPU = 3.6 MHS06 (~ cores) Disk = 310 PB Tape = 380 PB LHC non si può considerare il più grande attore del Calcolo Scientifico Tuttavia è il principale per quanto riguarda il calcolo distribuito su CPU in ambito scientifico. Ci si aspetta che mantenga la leadership anche nel futuro, nonostante si possano presentare “competitors” SKA, Human Brain Project, … Ma quanto è grande il Computing di LHC oggi? ~200 sites registered in WLCG 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

4 Cosa abbiamo difronte a noi
Ecco dove siamo 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

5 Dal punto di vista dei dati…
Fino ad ora abbiamo accumulato meno di 100/fb. Il totale atteso per ogni esperimento è circa 3000/fb.  Abbiamo fatto il primo 3% di LHC!!! 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

6 Impatto previsto sulle risorse di calcolo
L’evoluzione prevista per l’hardware non è sufficiente a colmare il gap che abbiamo rispetto ai requisiti del Run IV Quindi: il computing durante il Run IV risulterebbe 10x più costoso rispetto ad oggi… 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

7 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
E quindi? Tommaso Boccali Vanno identificati diversi assets che devono essere combinati insieme per ottenere il risultato atteso (“revolutionary approach”) Parameters Amount of raw data, thresholds etc. Core Algorithms ricostruzione, simulazione… Infrastructures Nuovi modelli grid/clouds Software performances performances/architetture/ memory 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

8 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Ma… a breve termine? Guardando al Run2 (in corso) La Macchina (LHC) ha prestazioni ben oltre I valori previsti LHC live time ( 37%  60%+ ) Luminosità ( 1.0x1034  1.2x1034 ) Pile-up (ALTAS, CMS) ( 21  33 in media ) Tutto ciò ha un impatto diretto sul computing: CPU, Disco, Tape E’ stimato un incremento del 15-30% rispetto alle precedenti valutazioni! Molta pressione ai 4 esperimenti di LHC per le risorse di calcolo necessarie per il ( dato il vincolo del “flat budget”). 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

9 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Una prima sintesi Sembra necessario capire come ottimizzare l’utilizzo delle risorse a disposione Non solo per HL-LHC ma fin da ora! E’ necessario essere efficienti in tutti gli aspetti Dalle infrastrutture alle applicazioni fino alle persone… Nuovi modelli grid/cloud; ottimizzazione CPU/Disco/network Utilizzo di clouds, HPC, Volunteer Computing, Opportunistic resources I Run 2 e 3 saranno gestibili con un “evolutionary approach” Possibilmente utilizzando nuove tecnologie dove possible HL-LHC richederà sicuramente un “revolutionary approach” 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

10 Nel frattempo: INDIGO-DataCloud
Gap Analysis 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

11 Mettendo tutto insieme: l’obiettivo
Utilizzare il “toolkit” fornito da INDIGO-DataCloud per sviluppare una soluzione semplice e automatica per la creazione, l’accesso e la gestione di un cluster HTCondor (container based) su risorse Cloud, finalizzato all’esecuzione dei workflows di analisi dati di LHC, in particolare per l’esperimento CMS Rendere possibile l’integrazione (senza soluzione di continuità) di cluster On-Demand, generato su risorse opportunistiche (ephemeral), con il modello di calcolo dell’esperimento Vantaggi: Sites management: A simple solution for elastic computing site extensions on “opportunistic” resources A easy procedure to dynamically instantiate a spot ‘ Data Analysis Facility’ Users experience: Generation of a ephemeral WLCG-Tier 3 as a Service and share resources with collaborators, using standard CMS Tools (such as CRAB). Experiment-Collaboration resources: A comprehensive approach to opportunistic computing. Orchestrating multiple campus centers to gather all free CPU cycles. 9 November 2016 GDB Meeting. Daniele Spiga

12 L’infrastruttura di sottomissione jobs di CMS
• In the first stage of matchmaking, glideinWMS frontend matches jobs to their desired sites and requests the glideinWMS factory to send glideins (properly configured condor tar ball) • The 2nd stage of matchmaking is when a job gets matched to a slot once the condor starts on the worker node and makes itself available in the pool • Glidein pulls in the job and then GLExec is used to switch to central production or analysis user’s credentials 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

13 Modello di Integrazione di “ephemeral sites”
Pull Mode: principali challenges… Risorse non note a priori, central manager deve accettare connessioni da clients Autoscaling AuthN/Z “Enforced match making” Accounting delle risorse Ephemeral Site HTCondor Startd Docker container VM Opportunistic Cloud 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

14 HTCondor ruolo centrale
Semplificazione dell’architettura: NO CE No GlideinWMS (Frontend/Factory) Ephemeral site 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

15 Selezione delle Soluzioni INDIGO: cherry picking
Data Center Solutions Mesos, Marathon, CLUES Data/Storage Solution: Dynafed, FTS , Onedata Automated Solutions TOSCA templates, Orchestrator Common Solution Identity Access Management (IAM), Token Translation Service ( TTS ) 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

16 GDB Meeting. Daniele Spiga
Four Pillars Cluster Management: Mesos clusters as a solution in order to execute docker for all the services required by a regular CMS site (Worker Node, HTCondor Schedd and squids). Marathon guarantees us the dynamic scaling up and down of resources, a key point. AuthN/Z & Credential Management: INDIGO Identity Access Management (IAM) service is responsible for AuthN/Z to the cluster generation. Token Translation Service (TTS) enables the conversion of IAM tokens in to a X.509 certificates NOTE: This allow Mesos slaves (running HTCondor_startd daemon) to join CMS central queue (HTCondor_schedd) as a regular Grid WN Data Management: Dynafed & FTS is the approach currently followed by the project. We will investigate Oneclient (from Onedata) as a tool allowing to mount remote Posix file-system. Automation: TOSCA templates, meant to be managed by INDIGO PaaS Orchestrator, allow the automation of the overall setup. The aim is to produce a single YAML file describing the setup of all required services and deps. CLUES is able to scale the Mesos cluster as needed by the load of the users jobs. 9 November 2016 GDB Meeting. Daniele Spiga

17 CMS GRID Computing Infrastrucure INDIGO PaaS Orchestrator
Soluzione Sviluppata Campus Facility Private Cloud Opportunistic CMS GRID Computing Infrastrucure Global Pool End User INDIGO PaaS Orchestrator INDIGO IAM INDIGO TTS TOSCA template AuthN Instanciates Joins Translates 9 November 2016 GDB Meeting. Daniele Spiga

18 Automation: TOSCA (+Ansible) template
Siamo partiti dal template TOSCA (+Ansible) per la generazione di un cluster Mesos (+Marathon) fornito da INDIGO Master – Slaves - Load Balancer Virtual IP Fondamentale per l’interazione tra I servizi CMS (vedi sotto) e ne abbiamo esteso il supporto ai servizi necessari ad un cluster di CMS CVMFS Configurato su host node Squid Proxy docker application HTCondor Startd (aka WN) Docker application: condor startd e configurazione per CMS GlobalPool ( CERN/FNAL ) X.509 certificate service Docker application: interfaccia verso IAM – TTS e cache per proxy cert.  Abbiamo completamente automatizzato il depoy del cluster: dall’istanziazione delle VM, alla configurazione di Mesos/Marathon alle applicazioni docker dei servizi di CMS. 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

19 Configurazione slave host (CMS specifications)
CVMFS ENVIRONMENT Questa è l’unica parte della configurazione che caratterizza il sito Informazioni site-specific sono tutte parametrizzabili Definite dall’utente al momento depoy del cluster ( come input parameters ) 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga CMS TFC

20 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Squid Proxy Nessuna “customizzazione” del servizio. La configurazione di questo servizio sfrutta le funzionalità del Load Balancer… 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

21 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
HTCondor startd Acquisizione del proxy Per autenticazione con il central manager Avvenuto la fase di matchmaking e il claim, si avvia l’esecuzione del job CMS software via CVMFS Conditions via squid 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

22 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
AuthN/Z La generazione del cluster Mesos richiede uno IAM access token valido (Openid Connect) che viene passato come parametro al momento del deploy Tutto il resto viene gestito in maniera trasparente all’utente attraverso i servizi INDIGO Credential renewal, Token transaltion.. Abbiamo sviluppato una applicazione (docker) che: TTS IAM HTCondor Startd docker IAM access_token IAM client: token_exchange TTS-Client: Retrieve X.509 certificate curl Generate, caching and serving proxy certificate Get Proxy 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

23 Un secondo livello di autorizzazione
Dobbiamo assicurarci ( assicurare CMS ) di avere assoluto potere decesionale di quali workflow debbano essere destinati ai cluster opportunistici E’ necessario saper fare un enforcement al livello centrale e non delegare la decisione al client (come nel caso di HLT) Central manager/negotiator devono saper decidere quali workflow destinare alle risorse che si autenticano La nostra attuale visione: 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

24 Few words on Data Ingestion
The current implementation of the use case relies on the storage solution already adopted by CMS Computing model: Job input data is accessed through xrootd data federation Job produced output go through “gfal-cp” As next step: The plan for the second phase of the use case development foresees the usage of INDIGO data management solutions, Onedata, Dynafed and FTS 9 November 2016 GDB Meeting. Daniele Spiga

25 Workflow attualmente implementato
USER Schedd (CMS Global or private) CRAB CFG User analysis job description pointing to SITENAME VM#1 Squid1 VM#2 WN1 VM#3 WN2 VM#4 WN3 Cloud#1 Mesos cluster SITENAME #/type of services SQUIDs Schedd if needed WNs (range desired) Onedata / Dynafed attached Storage TFC rules Fallback strategy Temp storage to be used Cloud#2 Data Management Data as defined in TFC (Onedata, Dynafed, Xrootd Fed) PaaS Orchestrator TTS Provides Submits Configures Instantiates Translates Reads Joins IAM 9 November 2016 GDB Meeting. Daniele Spiga

26 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Vediamolo in pratica Demo 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

27 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Stato dei test Attualmente abbiamo testato il deploy, e l’esecuzione dei job in più istanze di Openstack Bari, Padova, Perugia Direttamente via HEAT e/o con Orchestratore Stiamo programmando tests su Egi FedCloud (OCCI), Azure Infrastructure Manager Estratto dallo schema architetturale di INDIGO 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

28 Possibili estenzioni:
Includendo uno schedd tra I servizi deployati dal sistema automatico potremmo: Abilitare le sottomissioni a risorse locali di CMS CRAB/WMAgent possono definire quale schedd vogliono utilizzare Abilitare ed esplorare il Flocking mechanism di HTCondor Contributo al miglioramento delle perfomamces dell’infrastruttura centrale (GlobalPool) Includendo inoltre Collector e Negotiator… Importanti sinergie con progetto HTMesos 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

29 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Alcune note finali Sebbene il prototipo presentato è finalizzato all’esecuzione dei workflows di analisi dati di CMS, l’approccio è assolutamente generale e può essere adottato da chiunque utilizzi o possa utilizzare HTCondor Indipendentemente da HTCondor, l’approccio mostrato potrebbe essere un “pilota” per casi d’uso (aka workflow) più revolutionary che evolutionary come mostrato ad oggi: Big Data Approaches 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

30 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Next Steps Exploiting INDIGO Data Management: Onedata Multi IaaS Interoperability Extending the cluster service with a local schedD Dynamic auto scaling of cluster : CLUES 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

31 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Conclusion We developed a prototype for generating a “T* ephemeral site as a service” We enabled the complete automation of the cluster generation We integrated the INDIGO credential harmonization We successfully execute CMS analysis jobs By simplifying and automating the process of creating, managing and accessing a pool of computing resources the project aims to impact on: Sites, Users and Experiment collaboration 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga

32 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga
Contributors Marica Antoniacci (INFN-BA) Tommaso Boccali (INFN-PI) Andrea Ceccanti (CNAF) Stefano Dal Pra (CNAF) Giacinto Donvito (INFN-BA) Davide Salomoni (CNAF) Sonja Taneja (CNAF) 21 Dicembre 2016 INDIGO-DataCloud MidnightBlue Tutorial Days. Daniele Spiga