I Servizi GRID Architettura, Implementazione ed Interfacce

24/11/2004I Servizi di GRID - Ringraziamenti Questa parte del corso è parzialmente basata su “The EU DataGrid Project Tutorial” creato dal European DataGrid Project Team

24/11/2004I Servizi di GRID - GRID middleware Architettura della GRID Risorse (CPU, Storage, Network) Applicazioni Interfaccia GRIDLocali EDG GRID3 LCG Servizi GRID di base Servizi GRID collettivi Alien GLOBUS

24/11/2004I Servizi di GRID - I Servizi della GRID 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 Servizi di Base Servizi Collettivi

24/11/2004I Servizi di GRID - Un’Implementazione: EDG Computing Element Storage Element Site X Information System submit query retrieve User pubblica il proprio stato Data Catalog VOMS query definisce la propria identità Resource Broker

La Security sulla GRID

24/11/2004I Servizi di GRID - 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) :

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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.

24/11/2004I Servizi di GRID - 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: Registrazione a una VO –Invio del certificato al gestore della VO –Verifica di appartenenza alla VO –Per gli esperimenti in LCG: 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).

Accesso alle Risorse

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

L’Information System

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - GRIS GIIS Site Z GRIS GIIS Site Y GRIS GIIS Site X 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

24/11/2004I Servizi di GRID - 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à!

24/11/2004I Servizi di GRID - 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 IS: il Modello GMA GRIS Producer Site X Registry Il Producer si registra sul Registry descrivendo che tipo di informazioni può pubblicare Il Consumer cerca i Producer utili sul Registry… …e contatta direttamente il Producer per ottenere l’informazione

24/11/2004I Servizi di GRID - 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)  Site X GRIS Producer Consumer Registry GRIS Producer GRIS Producer Filter

Data Management

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

24/11/2004I Servizi di GRID - 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) RLS ROS RMC RM

24/11/2004I Servizi di GRID - 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/ /run2/track1 Logical File Name 1 Logical File Name 2 Logical File Name n GUID Physical File SURL n Physical File SURL 1

24/11/2004I Servizi di GRID - 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 Logical File Name 1 Logical File Name 2 Logical File Name n GUID Physical File SURL n Physical File SURL 1 RMC RLS

24/11/2004I Servizi di GRID - 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 Local Replica Catalog Mappa tra GUID e PFN Replica Location Index Mappa tra GUID e LRC

24/11/2004I Servizi di GRID - 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 

24/11/2004I Servizi di GRID - Interazione tra RM e SRM Replica Manager client SRM Replica Catalog Storage Il Client RM chiede al RLS di indicare la posizione di un dato file (GUID o LFN) 2.Il RLS risponde indicando un SRM (PFN) 3.Il Client RM chiede il file allo SRM 4.Lo SRM chiede allo Storage System di rendere disponibile il file al Client RM… 5.… o attraverso lo SRM stesso 6.… o direttamente 5 5

24/11/2004I Servizi di GRID - Servizi di Replicazione di Base SRM Replica Location Service Replica Metadata Catalog SRM I File hanno diverse repliche in diversi siti e diversi SRM 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. Replica Manager Il Replica Manager rende atomiche le operazioni di replica, garantendo la consistenza tra RLS e contenuto degli SRM.

24/11/2004I Servizi di GRID - Servizi di Replicazione di Alto Livello SRM Replica Location Service Replica Metadata Catalog SRM Monitor Network Monitor SRM Replica Manager Gli user possono definire operazioni di pre- e post-processamento per tutte le operazioni di replica Replica Optimization Service 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.

24/11/2004I Servizi di GRID - Interazione con altre componenti SRM Replica Location Service Replica Metadata Catalog SRM Monitor Network Monitor Information Service SRM Replica Manager Resource Broker User Interface o Worker Node Replica Optimization Service Applicazioni e user usano il Replica Manager o direttamente o attraverso il Resource Broker. NON devono usare direttamente l’SRM.

Workload Management

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - 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

24/11/2004I Servizi di GRID - Un linguaggio del WMS: JDL EDG ha creato il Job Description Language (JDL) –basato sul linguaggio di CLASSified ADvertisement di Condor: [ 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 Per maggiori informazioni sul JDL:

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE SE characts & status CE characts & status Job (JDL) Input Sandbox Il Network Server accetta le richieste e le accoda

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

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

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE Job Adapter Il Job Adapter crea un wrapper attorno al job Sottometti il job

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE Il Job Controller gestisce la sottomissione e il controllo del job Job Input Sandbox

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE Il CE esegue il job interagendo con SE e servizi locali o remoti Controllo GRID I/O

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE Al termine del job l’output viene trasferito sul RB Output Sandbox

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE E lo user lo può recuperare a suo piacimento get job output

24/11/2004I Servizi di GRID - Network Server Job Control - CondorG Workload Manager RB Storage Funzionamento del WMS: EDG UI RLS IS SE CE In ogni momento il sistema di Logging & Bookkeeping permette allo user di tenere sotto controllo lo stato del job Logging & Bookkeeping get job status