I Servizi GRID Architettura, Implementazione ed Interfacce

1. I Servizi GRIDArchitettura, Implementazione ed Interfacce Emanuele.Leonardi@roma1.infn.it

2. Ringraziamenti Questa parte del corso è parzialmente basata su “The EU DataGrid Project Tutorial” creato dal European DataGrid Project Team http://eu-datagrid.web.cern.ch/eu-datagrid/Tutorial/tutorial.htm I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

3. EDG GRID3 LCG Alien GLOBUS GRID middleware Architettura della GRID Applicazioni Interfaccia GRID Locali Servizi GRID collettivi Servizi GRID di base Risorse (CPU, Storage, Network) I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

4. Workload Management Sottomissione dei Job Matchmaking Logging e Bookkeeping Data Management Replica Management Metadata Management Accesso alle Risorse Gatekeeper (batch) Storage (dischi, nastri) Database (SQL,…) Network Information System Individuazione delle Risorse Monitoring dello Stato delle Risorse Security Autenticazione Autorizzazione I Servizi della GRID Servizi Collettivi Servizi di Base I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

5. Data Catalog Information System User submit query retrieve Resource Broker definisce la propria identità Computing Element Storage Element submit pubblica il proprio stato query retrieve Site X VOMS Un’Implementazione: EDG I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

6. La Security sulla GRID

7. PKI X.509 • La security sulle GRID è basata sullo standard PKI X.509 • PKI = Public Key Infrastructure (Infrastruttura a Chiave Pubblica) • Lo standard fu creato per aumentare il livello di confidenza negli scambi di informazioni su Internet • certezza della conformità dell’informazione scambiata • certezza della sorgente e destinazione dell’informazione • certezza della privatezza dell’informazione • possibilità di usare l’informazione in tribunale • Potete trovare un interessante (e divertente) riassunto dello standard, inclusi i suoi problemi, nel tutorial di Peter Gutmann dell’Università di Auckland (New Zealand) : http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

8. Autenticazione • La fase di Autenticazione risponde alla domanda: Chi è questo user? • Le Certification Authorities(CA) verificano l’identità della persona con metodi “tradizionali” … • p.es. lo user manda copia di un proprio documento al gestore della CA • una CA può avere delle Registration Authorities (RA) come front-end • …e rilasciano un certificato digitale personale. • Certificato = Carta di Identità GRID • Ad ogni richiesta di risorse lo user deve allegare una copia del proprio certificato (proxy) per comprovare la propria identità. • Le CA definiscono le proprie politiche e procedure: i gestori delle risorse possono scegliere di quali CA “fidarsi” e non dare accesso a user con certificati di CA indesiderate. • Ogni CA pubblica una Certificate Revocation List (CRL) con la lista dei certificati che sono stati compromessi. N.B. il certificato è un concetto utilizzato anche al di fuori delle GRID I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

9. Il Proxy • Un job GRID-enabled deve poter accedere a tutte le risorse a cui puo’ accedere lo user che lo ha sottomesso • P.es. Accesso a file immagazzinati sulla GRID • Creando un proxy uno user delega la propria identità al job per un periodo limitato di tempo • Il proxy include l’identità dello user, una chiave privata (specifica del proxy), la data di scadenza • Che succede se il job rimane in coda per molto tempo? • È possibile usare un servizio di Proxy renewal automatico • Grossi problemi di security ma minori di quelli che si hanno creando proxy di lunga durata I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

10. Autorizzazione • La fase di Autorizzazione risponde alla domanda: A quali risorse ha accesso questo user? • Ogni user registra il proprio certificato con una o più Virtual Organizations (VO) : • Un esperimento (ATLAS, ALICE, CMS, LHCb, BaBar, D0, …) • Un gruppo coordinato di ricercatiori (BioMedical, Earth Observation, …) • Il manager della VO contatta i gestori di risorse e concorda le modalità di accesso per i propri user. • Come fa il gestore a sapere se uno user fa parte di una VO? • La VO fornisce al gestore una lista dei propri user • Macchinoso, poco flessibile, possibili errori • VOMS: lo user estende il proprio certificato con informazioni relative alla VO di appartenenza e al ruolo rivestito nella VO • p.es. in HEP: ricercatore, manager produzione MC, manager ricostruzione VOMS consente un raffinamento del modello di accesso alle risorse. I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

11. In concreto... • Richiesta di un certificato da una CA • Creazione della chiave pubblica/privata • Invio della chiave pubblica alla CA (o alla RA) • Verifica dell’identità dello user • Emissione del certificato • INFN Certification Authority: http://security.fi.infn.it/CA/ • Registrazione a una VO • Invio del certificato al gestore della VO • Verifica di appartenenza alla VO • Per gli esperimenti in LCG: http://lcg-registrar.cern.ch/ • Creazione di un proxy • Con o senza estensioni VOMS • Registrazione del proxy per il rinnovo N.B. se la chiave privata viene compromessa lo user deve contattare la propria CA per annullare il certificato (CRL). I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

12. Accesso alle Risorse

13. Computing: il Gatekeeper • Le risorse di calcolo sono disponibili attraverso un batch system: • controllo dell’accesso alle risorse • ottimizzazione dell’uso delle risorse disponibili • controllo delle priorità di accesso alle risorse • accounting • Esistono molti sistemi batch con caratteristiche e livelli di sofisticazione differenti… • LSF, CODINE, PBS, … • …tuttavia le funzionalità primarie viste dagli user sono comuni: • sottomissione di job • controllo dello stato dei job • recupero dell’output • cancellazione dei job • Il Gatekeeper esporta queste funzionalità verso la GRID • interfaccia indipendente dal batch system • autenticazione e autorizzazione GRID-enabled I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

14. Autorizzazione 1 • La VO e il Site Manager (SM) definiscono le modalità di accesso al batch system, p.es. • MC producer: accesso a tutte le risorse ma a bassa priorità • Data processing: accesso a tutte le risorse ad alta priorità • Analisi ufficiali: sub-farm riservata ma ad alta priorità • Analisi private: accesso a tutte le risorse a priorità media • Il SM configura il batch system locale secondo queste modalità e crea uno o più utenti locali corrispondenti a ciascuna di esse • p.es. cms_mcprod, cms_prod, cms_anal, cms_user • Quando uno user si presenta con un certificato di CMS e un ruolo (definito, p.es., col meccanismo VOMS) il suo job viene sottomesso al batch system come se a mandarlo fosse uno degli user locali: • Pinco Pallino si presenta con un certificato del VO di CMS con ruolo di MC producer: il job gira sotto lo user cms_mcprod • Carlo Rubbia vuol girare la sua analisi sugli Z e si presenta con un certificato del VO CMS generico: il job gira sotto lo user cms_user I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

15. Autorizzazione 2 • La mappatura di molti user diversi sullo stesso account locale può generare problemi di sicurezza: • Carlo Rubbia e Antonino Zichichi inviano i loro job di analisi alla GRID • I job vengono inviati allo stesso sito e gireranno quindi sotto lo stesso account cms_user • Il batch system usa macchine multiprocessore e i due job vengono inviati sullo stesso PC • Se uno dei due job è malizioso (o sbadato) può leggere o cancellare i dati dall’area di lavoro dell’altro • Soluzioni possibili: • creare più account locali per lo stesso VO/ruolo • non scalabile! • introdurre il concetto di identità GRID anche nelle risorse locali • buona soluzione ma intrusiva I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

16. Storage: SRM • I dati possono essere immagazzinati in differenti tipi di storage con diverse caratteristiche di gestibilità e affidabilità • JBOD (Just a Bunch Of Disks) • Disk pool servers (RAID) • Hierarchical Mass Storage (HMS) • Un’interfaccia GRID per lo storage deve consentire • accesso trasparente ai dati • file pinning • allocazione preventiva dello spazio • notifica dello stato dei file • gestione del sistema di storage • Lo Storage Resource Manager (SRM) è un servizio GRID (Web Service) che interagisce con i sistemi di storage locali e ne offre un’interfaccia GRID verso il mondo esterno • specifiche originali: LBL, JNL, FNAL, CERN, EDG I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

17. Caratteristiche dello SRM • SRM specifica solo l’interfaccia verso lo storage • ne esistono implementazioni per diversi storage systems • dCache (DESY, FNAL), CASTOR (CERN), HPSS (CCIN2P3), HRM (LBNL) • Supporto per le politiche locali • ogni risorsa di storage può essere gestita indipendentemente • priorità interne al sito non vengono condizionate da attività GRID • Risorse su disco e su nastro sono presentate in maniera omogenea • può gestire sia pool di dischi, sia HMS • Locking e pinning temporanei • uso di cache su disco per evitare multiple letture da nastro • protezione da sistemi di pulizia automatica della cache • Allocazione preventiva di spazio di storage • si può riservare dello spazio per la registrazione di un nuovo file • Esportazioni delle informazioni sui singoli file e sul sistema Il Global GRID Forum (GGF) sta esaminando l’interfaccia SRM per proporla come standard I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

18. Storage e Autorizzazione • I sistemi di storage utilizzano gli account locali in modo più o meno sofisticato (Unix UID, ACL, AFS) per controllare l’accesso alle risorse • Utilizzando la mappatura su account locali in funzione del ruolo si creano buchi (voragini!) di sicurezza • tutti gli user mappati su cms_user si possono leggere(!)/scrivere(!!)/cancellare(!!!) i file a vicenda • il sistema di ACL spesso non è neanche sufficientemente potente per gestire la situazione in cui diversi ruoli hanno diversi tipi di accesso ai file (cms_prod rw, cms_anal e cms_user ro, ecc.) • La soluzione definitiva non è ancora stata trovata • proposti file system GRID-aware in cui le ACL sono basate sul certificato/ruolo dello user I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

19. L’Information System

20. L’Information System L’Information System (IS) ha due compiti principali: • permettere la scoperta delle risorse • il sito XYZ esiste, offre queste risorse, è accessibile da questi user, … • permettere il controllo dello stato delle risorse • # di CPU libere, spazio disco disponibile, … L’IS deve essere flessibile: • funzionamento in ambiente distribuito • rapidità di risposta • produttori di informazione dinamici • sicurezza nell’accesso ai dati • modello di informazioni estendibile • scalabilità • interfacce di accesso standard I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

21. Site X Site Y Site Z GIIS GIIS GIIS GRIS GRIS GRIS IS: Il Modello MDS • MDS = Monitoring and Discovery System • Introdotto nelle prime implementazioni di GLOBUS • Adottato inizialmente da EDG e attualmente da LCG • Basato su un modello gerarchico di raccolta delle informazioni • Il GRIS (Grid Resource Information Service) raccoglie le informazioni sulle risorse locali • Il GIIS (Grid Index Information Service ) pubblica le informazioni verso i livelli superiori della gerarchia GIIS I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

22. Problemi del Modello MDS • I GIIS usano un meccanismo push per la propagazione dei dati ai livelli superiori • questo è un tentativo di minimizzare il tempo di arrivo dei dati al top della gerarchia • se un GIIS serve troppi GIIS di livello più basso può andare in sovraccarico e bloccarsi • Il (o i) GIIS al top della gerarchia devono gestire troppi dati… • limiti alla scalabilità della GRID • …e troppi clienti • tutti gli user/RB/ROS vogliono usare solo i GIIS al top • In LCG il problema è stato mitigato(ma non risolto!) sostituendo alla gerarchia dei GIIS un harvester (chiamato BDII) e una lista dinamica dei siti esistenti scaricabile da web • Il BDII aggiorna regolarmente la lista dei siti… • …e contatta il GIIS di ciascun sito raccogliendone l’informazione • Troppi clienti = sovraccarico dei Site GIIS! • Rimangono i problemi di scalabilità! I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

23. …e contatta direttamente il Producer per ottenere l’informazione Site X Producer Il Consumer cerca i Producer utili sul Registry… GRIS Il Producer si registra sul Registry descrivendo che tipo di informazioni può pubblicare IS: il Modello GMA • Il modello GMA (GRID Monitoring Architecture) risolve il problema di scalabilità lasciando le informazioni lì dove vengono prodotte e pubblicando unicamente l’esistenza del produttore • Il GIIS è sostituito da un Producer che pubblica la propria esistenza e la natura delle informazioni prodotte su di un Registry • Il Consumer (user, RB, …) contatta il Registry per scoprire i Producer di interesse e poi parla direttamente coi Producer per avere le informazioni Registry I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

24. Producer Producer Producer GRIS GRIS GRIS Problemi del Modello GMA • Il Registry è un single point of failure • rendere ridondante il Registry e introdurre procedure di fall-back automatico • I Producer tendono a sovraccaricarsi • introduzione di una gerarchia locale • uso di risorse dedicate • EDG ha implementato il modello GMA usando un sistema di DB relazionale (R-GMA)  http://www.r-gma.org/ Registry Producer Site X Filter Consumer I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

25. Data Management

26. Replica Manager ‘Atomizza’ le operazioni di replica Unifica l’interfaccia cliente Orchestra l’intero sistema Site A Site B Storage Element A Storage Element B File A File X File A File C File B File Y File B File D File Management Replica Catalog Mappa i file logici ai siti che ne posseggono una copia Replica SelectionTrova il file “migliore” Security Replication Automation Sottoscrizione a una sorgente di dati Pre- Post-processing Prepara i file per il trasferimento Valida i file dopo il trasferimento Load Balancing Crea repliche secondo l’uso Metadata LFN metadata Transaction information Access patterns File Transfer I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

27. RM RLS RMC ROS I Tool per il Data Management • Un sistema di data management per la GRID deve offrire tool per: • localizzare i dati • copiare i dati • gestire e replicare i dati • gestire i meta-dati • Nel caso di EDG questi tool sono basati su: • Replica Location Service (RLS) • Replica Metadata Service (RMC) • Replica Optimisation Service (ROS) • Replica Manager (RM) I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

28. I File nella GRID • Un file nella GRID è identificato in maniera univoca dal suo GUID (GRID Unique Identifier) • l’unicità è garantita in maniera algoritmica • non è user friendly: guid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 • Il SURL (Site URL) o PFN (Physical File Name) individua le copie fisiche dei file • include l’indirizzo dello Storage Element e il protocollo di accesso srm://pcrd24.cern.ch/flatfiles/cms/output10_1 • Il LFN (Logical File Name) definisce degli alias leggibili del GUID lfn:cms/20030203/run2/track1 Logical File Name 1 Physical File SURL 1 Logical File Name 2 GUID Physical File SURL n Logical File Name n I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

29. Logical File Name 1 Physical File SURL 1 Logical File Name 2 GUID RMC RLS Physical File SURL n Logical File Name n RLS e RMS • Il Replica Location Service (RLS) ed il Replica Metadata Catalog (RMC) gestiscono le mappature tra LFN, GUID e PFN • RMC: LFN  GUID • RLS: GUID  PFN I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

30. Il Replica Location Service • Il Replica Location Service (RLS) è il sistema che mantiene e rende disponibile le informazioni relative alla posizione fisica delle copie di file di dati • È un sistema distribuito che immagazzina una mappa tra il GUID e il PFN di tutte le repliche di ciascun file • EDG ha implementato, in collaborazione con GLOBUS, una prima versione dell’RLS basata su un unico server centralizzato (single point of failure!!!), attualmente usata da LCG2 • È in fase di test una versione realmente distribuita Replica Location Index Mappa tra GUID e LRC Local Replica Catalog Mappa tra GUID e PFN I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

31. Il Replica Manager • Il Replica Manager consiste in un set di comandi che lo user deve usare per interagire col sistema di Storage Management • Comandi di gestione dei file • copyAndRegisterFile, replicateFile, deleteFile • Comandi di gestione del catalogo • registerFile, registerGUID, listReplicas, addAlias • Comandi di ottimizzazione • listBestFile • Comandi per accesso a file fuori dalla GRID • copyFile, listDirectory • Anche RLS, RMC e ROS offrono una interfaccia utente per operazioni di gestione avanzate dei cataloghi • dovrebbero essere utilizzate solo dagli amministratori dei cataloghi • I comandi di trasferimento (interni ed esterni alla GRID) sono basati sul tool GridFTP http://www.globus.org/datagrid/gridftp.html I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

32. Interazione tra RM e SRM Replica Catalog 1 2 Replica Manager client 5 SRM 3 4 5 6 Storage • Il Client RM chiede al RLS di indicare la posizione di un dato file (GUID o LFN) • Il RLS risponde indicando un SRM (PFN) • Il Client RM chiede il file allo SRM • Lo SRM chiede allo Storage System di rendere disponibile il file al Client RM… • … o attraverso lo SRM stesso • … o direttamente I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

33. Servizi di Replicazione di Base Ogni file ha un unico GUID. Le posizioni delle repliche del file sono contenute nel RLS. Gli user possono assegnare degli alias a ogni GUID. Questi sono contenuti nel RMC. I File hanno diverse repliche in diversi siti e diversi SRM Replica Metadata Catalog Replica Location Service Replica Manager Il Replica Manager rende atomiche le operazioni di replica, garantendo la consistenza tra RLS e contenuto degli SRM. SRM SRM I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

34. Servizi di Replicazione di Alto Livello Gli user possono definire operazioni di pre- e post-processamento per tutte le operazioni di replica Il RM può utilizzare il Replica Optimization Service per trovare la replica “migliore”. Per la selezione il ROS usa informazioni dagli SRM e dal network. Replica Metadata Catalog Replica Location Service Replica Manager Replica Optimization Service SRM SRM SRM Monitor Network Monitor I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

35. Interazione con altre componenti User Interface o Worker Node Resource Broker Information Service Replica Metadata Catalog Replica Location Service Replica Manager Replica Optimization Service Applicazioni e user usano il Replica Manager o direttamente o attraverso il Resource Broker. NON devono usare direttamente l’SRM. SRM SRM SRM Monitor Network Monitor I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

36. Workload Management

37. Il Workload Management System • Lo user interagisce con la GRID attraverso un sistema di Workload Management (WMS) • Lo scopo del WMS è la gestione dell’accesso alle risorse della GRID • Un WMS offre agli user i mezzi per: • sottomettere i propri job sulla GRID • eseguirli sulla risorse “migliori” • il WMS cerca di ottimizzare l’uso delle risorse • l’ottimizzazione è trasparente ma pilotabile dallo user • ottenere informazioni sullo stato dei propri job • recuperare l’output I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

38. Preparazione dei Job • Perchè il WMS possa fare il proprio lavoro lo user deve rendere esplicite le caratteristiche del proprio job: - richieste sull’ambiente di esecuzione • architettura • RAM • dimensione dell’area di lavoro su disco - dipendenze software • sistema operativo • librerie • pacchetti software specifici - necessità di accesso ai dati • disponibilità dei dati di input • possibilità di immagazzinare l’output • Il WMS utilizza queste informazioni per decidere dove inviare il job I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

39. [ JobType=“Normal”; Executable = “gridTest”; StdError = “stderr.log”; StdOutput = “stdout.log”; InputSandbox = {“home/joda/test/gridTest”}; OutputSandbox = {“stderr.log”, “stdout.log”}; InputData = {“lfn:cms/MC07_0001”, “guid:f81d4fae-7dec-11d0-a765”}; DataAccessProtocol = “gridftp”; Requirements = other.GlueHostOperatingSystemNameOpSys == “LINUX” && other.GlueCEStateFreeCPUs>=4; Rank = other.GlueCEPolicyMaxCPUTime; ] Un esempio di JDL Un linguaggio del WMS: JDL • EDG ha creato il Job Description Language (JDL) • basato sul linguaggio di CLASSified ADvertisement di Condor: http://www.cs.wisc.edu/condor/classad/ Per maggiori informazioni sul JDL: http://server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0142-0_2.pdf I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

40. Network Server Job (JDL) UI Input Sandbox Workload Manager RB Storage CE characts & status SE characts & status Job Control - CondorG RB CE SE Funzionamento del WMS: EDG RLS Il Network Server accetta le richieste e le accoda IS I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

41. Network Server UI Workload Manager Chi può eseguire il job? RB Storage Job Control - CondorG RB CE SE Funzionamento del WMS: EDG Il Matchmaker individua il miglior CE per il job RLS Match- Maker/ Broker IS Il Workload Manager trova il modo di soddisfare le richieste I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

42. Su quale SE sono i dati? Network Server UI Workload Manager Quali CE possono eseguire il job? Best CE RB Storage Job Control - CondorG RB CE SE Funzionamento del WMS: EDG RLS Match- Maker/ Broker IS In futuro il Matchmaker potrà usare il RM per creare nuove repliche on demand I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

43. Network Server UI Workload Manager RB Storage Sottometti il job Job Control - CondorG RB CE SE Funzionamento del WMS: EDG RLS Il Job Adapter crea un wrapper attorno al job IS Job Adapter I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

44. Network Server UI Workload Manager RB Storage Job Control - CondorG RB Job Input Sandbox CE SE Funzionamento del WMS: EDG RLS IS Il Job Controller gestisce la sottomissione e il controllo del job I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

45. Network Server UI Workload Manager RB Storage Job Control - CondorG RB GRID I/O Controllo CE SE Funzionamento del WMS: EDG RLS IS Il CE esegue il job interagendo con SE e servizi locali o remoti I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

46. Network Server UI Workload Manager RB Storage Job Control - CondorG RB Output Sandbox CE SE Funzionamento del WMS: EDG RLS IS Al termine del job l’output viene trasferito sul RB I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

47. Network Server UI get job output Workload Manager RB Storage Job Control - CondorG RB CE SE Funzionamento del WMS: EDG RLS IS E lo user lo può recuperare a suo piacimento I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it

48. Network Server UI Workload Manager RB Storage get job status Job Control - CondorG RB CE SE Funzionamento del WMS: EDG RLS IS Logging & Bookkeeping In ogni momento il sistema di Logging & Bookkeeping permette allo user di tenere sotto controllo lo stato del job I Servizi di GRID - Emanuele.Leonardi@roma1.infn.it