WP3 Realizzazione infrastruttura GRID - UR4

Presentazione sul tema: "WP3 Realizzazione infrastruttura GRID - UR4"— Transcript della presentazione:

1 WP3 Realizzazione infrastruttura GRID - UR4
OBIETTIVI:implementare e certificare un’infrastruttura di grid per le comunità scientifiche, partendo dai servizi di grid in corso di sviluppo nei progetti di ricerca internazionali ed nazionali (DATAGRID/DATATAG etc.) progettare e realizzare le componenti di gestione e operative necessarie e di orientarle ai requisiti di una Virtual Organization Sviluppare programmi di test appropriati delle funzionalita’ del middleware Definire Management oriented monitoring Adattare/ampliare i servizi di Grid esistenti alle necessità delle applicazioni previste nel progetto. E’ necessario stabilire preventivamente un programma comune di attività e definire il personale del WP applicativo o di sviluppo da impegnare e da affiancare al personale del WP3 Costruire Grid operation Center con supporto all’utente sulle funzionalità dei servizi di Grid Definire strumenti e tecnologie su cui basarsi per svolgere l’attività’ di supporto. Attualmente non esistono grid in produzione ne modelli di management operations & support.

2 Dal proposal originale
Implementazione di servizi di GRID:WP3 L’obiettivo è quello di offrire un ambiente grid di produzione per mezzo di applicazioni reali con dati reali presi dalla Biologia, Astrofisica, Osservazione della Terra, Geofisica e Vulcanologia. In Fisica delle Alte Energie questi servizi sono sviluppati nell’ambito di progetti Grid europei e americani...

3 WP3/5 UR4 Servizi di base Data intensive, WP 5 Il WP5 si propone di
Definire i requisiti di accesso ai dati della comunita’ scientifiche identificare servizi di accesso ai dati piu’ idonei a soddisfare tali requisiti. Realizzare i servizi selezionati e certificarli.

4 Scheduling temporale Modello architetturale della grid e selezione dei servizi (mese 6) Modello architetturale del management e definizione dei principali servizi (mese 12) Realizzazione dell’infrastruttura di grid con I servizi di base e sua certificazione.(mese 9) Set up del nucleo di GOC, start up (mese 6) Servizi e strumenti VO oriented, start up (mese 5) Inserimento di risorse di calcolo su piattaforme non attualmente supportate

5 WP3/5 UR4 Gruppi afferenti:
INFN inizialmente con le sedi di Cnaf/Padova/Napoli/Catania WP14 , WP10, WP12 concordato contributo in man power nelle attivita’ di management WP14 sedi di Napoli e Bologna, Definita attivita’ congiunta porting su NEC e gestione di job multipli con dipendenze (DAG) WP10 Padova/Trieste/Catania, definizione sedi e layout GRID WP12 Padova/Genova definizione sedi e layout GRID Interazioni con altri WP Con i WP1 e 2 qualora si ponga l’esigenza di definire i alcuni servizi di rete come servizi di Grid Con i WP applicativi (10,11,12,13,14) che vogliono usare i servizi implementati dal WP3/5 Con WP che sviluppano middleware per definire le opportune interfaccie. Le interazioni con i WP vanno valutate anche alla luce del man power che le possibili attivita’ possono richiedere

6 Premessa La rimodulazione delle attivita’ del WP3 e WP5 parte da quanto inserito nella proposta di progetto e prende in considerazione la riduzione di fondi per la UR4 all’approvazione del progetto, cui il WP3/5 afferisce. Si considera che il nuovo man power a disposizione per svolgere le attivita’ di WP3/5 sia quello previsto dal documento di rimodulazione finanziaria dell’unita’ di ricerca e che sia cosi’ ripartito: 4 FTE dai finanziamenti INFN, 2 FTE dai finanziamenti INAF, 1 FTE dai finanziamenti INGV, 1 FTE dai finanziamenti Università di `Genova, Universita’ di Padova per le Applicazioni Biologiche. Inoltre ci sono altri due ricercatori che pur all’interno del WP13 e WP12, partecipano direttamente alle attivita’ comuni con il WP3/5, principalmente per la gestione dei servizi di GRID legati alle virtual organization. I WP3/5 considerano quindi di avere a disposizione per svolgere e raggiungere gli obiettivi della propria ricerca descritta nel proposal, 8 ricercatori per la durata del progetto..  

7 finanziamenti

8 finanziamenti

9 Obiettivi WP3  implementare e certificare un’infrastruttura di grid generale per le comunità scientifiche nazionali sviluppare e progettare le componenti necessarie per la gestione e l’operazione di una grid complessa multi-settoriale ·verificare le potenzialità dei servizi di grid esistenti e il loro adattamento ai requisiti di una Virtual Organization con lo scopo di definire e realizzare l’architettura di GRID più adatta per le applicazioni di riferimento. Dapprima si valuteranno i servizi offerti da Datagrid, Datatag, LCG etc., poi si definira l’architettura di grid piu’ adatta ed infine l’infrastruttura di grid sarà implementata e sarà definito un piano per lo sviluppo o l’adattamento dei i servizi necessari. ·Come fase finale si arriverà alla certificazione di una grid nazionale a livello di produzione e degli strumenti necessari per garantirne la gestione.

10 Obiettivi WP3-cont Dall’inizio dell’interesse della comunita’ scientifica internazionale per la GRID sono stati finanziati numerosi progetti, in particolare in Europa DataGrid, DataTAG e negli USA PPDG, GriPhyN. Il software sviluppato da questi progetti e’ gia’ da qualche tempo configurato su testbed internazionali e presenta un grado di affidabilita’ sufficiente per essere utilizzato dalle applicazioni. Sulla base di queste considerazioni il WP3,5 si propone di realizzare una Grid nazionale con due obiettivi principali: 1)      validare una infrastruttura per un uso di produzione con i servizi ritenuti piu’ consolidati, 2)      studiare e realizzare un Grid Operational Centre (GOC) per il management della Grid e il supporto agli utenti. Quest’ultimo obiettivo riguarda aspetti mai affrontati finora ed e’ completamente innovativo. Per raggiungere questi obiettivi e’ fondamentale la collaborazione con le componenti-utenti che oltre ad utilizzare e adattare le loro specifiche applicazioni sulla Grid, contribuiscono allo studio e realizzazione di strutture e strumenti di supporto per l’accesso alla Grid stessa.

11 Attivita’1  Attivita’ 1: Definizione dei requisiti del workpakage Durata mese 0-9  Coinvolgimento: 9 mesi uomo INFN, 1 INGV, 1 INAF, 1 BIO (1 FTE per 9 mesi) Deliverable 1.1 Definizione dell’infrastruttura di GRID da realizzare mese 9   

12 Attivita’2 Definizione dell’architettura del sistema di gestione di deployment della GRID. Durata mese 6-36 Identificazione dei servizi software di Grid, da implementare partendo dai servizi di grid disponibili e sviluppati nei progetti di grid in corso (Datagrid/Datatag/INFN-GRID). Strumenti ed il modello di gestione della GRID orientata alle Virtual Organization. gli strumenti di management e di gestione devono essere totalmente sviluppati e progettati. 2 gruppi di servizi che il progetto deve coprire;       Servizi per l’infrastruttura di gestione e amministrazione.       Servizi per le virtual organization e gli utenti. Deliverable 2.1 Stato dell’arte e requisiti di un sistema di management orientato alle VO e architettura del sistema di GRID management mese 12 Coinvolgimento: 60 mesi uomo, INFN (2 persone per la durata del progetto)

13 Attivita’ 3 Sviluppo ed adattamento dei servizi di Grid
L’infrastruttura di servizio per la Virtual Organization e gli utenti deve fornire I servizi di GRID base, oltre ai servizi si calcolo e storage sulla GRID: Resource Brokers/ User Interfaces Virtual Organization Members repository , Data and replica catalogs, Information Services. devono essere adattati alle esigenze delle organizzazioni ed integrate in modo da fornire un modello di servizi con risorse e servizi comuni a tutte le Virtual Organization e servizi dedicati o specifici della singola organizzazione in modo dinamico e flessibile Coinvolgimento : 15 mm INFN 30 mm INAF, 15 mm INGV Bio (2.5 persone per la durata del progetto) Deliverable 3.1 Piano di realizzazione dell’infrastruttura dei servizi di GRID  

14 Attivita’ 4 Packaging/integrazione e supporto
durata 0-36 I servizi di Grid saranno ‘confezionati’/integrati. Archivi per il codice e per la documentazione saranno messi a disposizione degli utenti. Supporto all’utente sulle funzionalità dei servizi di Grid. Essendo la grid un sistema di calcolo distribuito in ambienti eterogenei e con comunità di utenti molto diverse tra loro e’ necessario prima di tutto definire i nuovi strumenti e le nuove tecnologie su cui basarsi per svolgere l’attività’ di supporto. Questa attività sarà svolta nel corso del primo anno. Deliverable 4.1. Definizione dei servizi di packaging, archivio della documentazione e supporto mese 12 Coinvolgimento: 15 mm INFN 30mm INAF 15mm INGV, 15mm Bio (2.5 persone per la durata del progetto

15 Attivita’ 5 Implementazione e certificazione della Grid
Durata 12-36 L’infrastruttura di grid sarà certificata per facilitare l’utilizzo da parte delle reali applicazioni degli utenti realizzare una grid che consente l’esecuzione di applicazioni scientifiche reali Gli strumenti per verificare/certificare una installazione configurazione di base di un nodo di GRID, la configurazione dell’ambiente locale l’interconnessione più ampia in GRID, al momento non ancora disponibili in maniera completa anche se sono indispensabili.. Coinvolgimento: 30 mm INFN (1 persona per la durata del progetto) Deliverable: Strumenti di certificazione e supporto (mese 24)

16 WP5: Attivita’ 2 Valutazione dei servizi software esistenti per il trasferimento di file ad alta velocità e accessi frequenti a database eterogenei. Questa architettura dovrà ovviamente tener conto dell’infrastruttura di grid definita nel work package 3 e della sua possibile estensione. D.5.1 Definizione e valutazione sistemi di data management (mese 12) Coinvolgimento: 0.5 mm INFN, (0.5 FTE per la durata del progetto)

17 Interazioni con gli altri WP
Programma per adattare/ampliare i servizi di Grid esistenti alle necessità delle applicazioni Contributo esplicito WP Applicativi in man power per VOMS/RC Organization specific e per Application/user supporto e integratione in GRID Con altre applicazioni o servizi sviluppati all’interno del progetto, ma e’ necessario stabilire preventivamente un programma comune di attività e definire il personale del WP applicativo o di sviluppo da impegnare in e da affiancare al personale del WP3

18 Grid Service Sharing policies of the resources.
Dynamic allocation of resources (according to the scientific activities of each VO) Mechanisms for defining the sharing degree of each resource at each moment. Specific VO services to manage the authentication and authorization steps, to define and publish the grid access policies etc. Resource Broker and scheduler: configuration in a production environment with multiple VO Information Service Data-management, catalogs etc.

19 Multiple-VO GRID management
define a management architecture for the grid with particular attention to the following items: Stability and production quality of the middleware: testing application Monitoring: for users, virtual organization, site manager, resource and services planning development of Management architecture and tools new Authentication & Authorization tools evolution of the Monitoring tools Deployment planning Policies management

20 Multiple-VO GRID Operations
User Access control and security (Certification Authority/ Virtual Organization Membership management, etc. ) Monitoring and performance issues Use Policies repository Application toolkits repository Grid Middleware Toolkits distributions, packaging and documentation User Support Site Managers Support

21 EDG Globus-based middleware architecture
Current EDG architectural functional blocks: Basic Services (authentication, authorization, Replica Catalog , secure file transfer, Info Providers) rely on Globus 2.0 Higher level EDG middleware (developed within EDG) Applications (HEP,BIO,EO) Specific application layer ALICE ATLAS CMS LHCb Other apps VOs common application layer LHC Other apps GRID middleware High level GRID middleware GLOBUS 2.0 Basic Services OS & Net services

22 EDG middleware GRID architecture
APPLICATIONS Local Computing Local Application Local Database Grid Grid Application Layer Job Management Data Management Metadata Management Collective Services Grid Scheduler Replica Manager Information & Monitoring Underlying Grid Services SQL Database Services Computing Element Services Storage Element Services Replica Catalog Authorization Authentication and Accounting Service Index M / W Grid Fabric services GLOBUS Fabric Resource Management Configuration Management Monitoring and Fault Tolerance Node Installation & Management Fabric Storage Management

23 WMS Revised Architecture
WP 1 Replica Catalog UI RB node Network Server Match- Maker/ Broker Inform. Service Workload Manager Job Adapter RB storage Logging & Bookkeeping Job Contr. - CondorG The overall plan defined for the quality objectives is described here after : CE characts & status SE characts & status Log Monitor

24 Network Monitoring Architecture
WP 7 Processing Visualization Replica Managers & resources brokers Network Managers WEB RTPL MapCenter NetworkCost Forecaster Collect And Storage Info Services (R-GMA) Archive Raw The overall plan defined for the quality objectives is described here after : Distributed Data Collector Measure PCP GridFTP PingEr IPerf UDPmon

25 Replica Management Services
WP 2 EDG-ReplicaManager Replica Management Services Client Optimization File Transfer Replica Metadata Replica Location Subscription

26 Information & Monitoring: R-GMA
WP 3 Use the GMA from GGF A relational implementation Relational model is better able to describe real world systems than the hierarchical Applied to both information and monitoring Creates impression that you have one RDBMS per VO Not a general distributed RDBMS system, but a way to use the relational model in a distributed environment where global consistency is not important. Supports streaming System allows you to publish what you want and to find out what you want Producer Store location Registry execute or stream Lookup location Consumer Producers announce: SQL “CREATE publish: SQL “INSERT” Consumers collect: SQL “SELECT”

27 Grid monitoring architecture
web interface ldap query GIIS (GLUE schema) discovery service information index monitoring service ldap query monitoring server Monitoring DB EDG WP4 fmonserver GRIS (GLUE schema) write run ldif output EDG WP4 mon. agent EDG WP4 mon. agent information providers farm monitoring archive read run metric output run metric output computing element WP4 sensor WP4 sensor read read metric output metric output /proc filesystem /proc filesystem worker node worker node

28 VOMS Architecture user VOMS server Voms- proxy-init DB Perl CLI
Authentication vomsd GSI request Tomcat & java- sec axis VOMS impl servlet DB VOMS pseudo-cert JDBC soap Apache & mod_ssl voms-httpd C=IT/O=INFN /L=CNAF /CN=Pinco Palla /CN=proxy VOMS pseudo-cert DBI http Perl CLI https Java GUI browser mkgridmap VO: CMS

29 http://grid.infn.it/firb-grid FIRB-GRID - WP3/5 Il progetto
Il progetto Documenti e presentazioni Partecipanti Riunioni Come si accede alla GRID Progetti correlati          INFN-GRID          DataGRID

30 istruzioni Accedere a Grid.it 1. Richiesta certificato
Questa pagina raccoglie una prima bozza delle istruzioni necessarie per accedere a Grid.it. Richiedere il proprio certificato ad una Certification Authority Registrare il proprio certificato presso la VO di cui si fa parte Installare e configurare la UserInterface Installare il proprio certificato nella UI Sottomettere un job 1. Richiesta certificato Per il momento l'unica Certification Authority (CA) operativa per FIRB-GRID è quella dell'INFN: La policy prevede che presso l'organizzazione di cui si fa parte sia presente una Registration Authority, cioè una persona che si faccia garante dell'identità di chi richiede un certificato digitale. Il richiedente dovrà: Recarsi dalla propria RA che avvierà la richiesta del certificato, restituendo un codice identificativo (ID). Installare nel proprio browser il certificato della CA seguendo il link: Certificato CA INFN Richiedere il certificato compilando tutti i campi richiesti e inserendo l'identificativo restituito dalla RA: Richiesta certificato Entro pochi giorni si riceverà un messaggio con le istruzioni e il link da cui scaricare il certificato e installarlo nel proprio browser. Tale certificato può essere utilizzato per inviare posta cifrata con S/MIME. Attenzione: è importante che l'installazione del certificato avvenga utilizzando lo stesso browser e macchina utilizzati per la generare richiesta (e quindi la chiave privata). 2. Registrare il proprio certificato Il passo successivo è registrare il proprio certificato presso un registro di tutti gli appartenenti alla propria Virtual Organization (VO). A questo scopo è necessario connettersi al server:

31 Istruzioni cont. 3. Installare e configurare la UserInterface
L'installazione di una UserInterface, cioè dell'elemento della grid utilizzato per accedere alla grid stessa, è descritta nella: EDG Installation Guide al paragrafo 4.4.1: 4.4.1 Manual installation [da completare, in particolare quale sarà il broker da settare?] 4. Installare il proprio certificato nella UI Ottenuto il certificato è necessario esportarlo dal browser web e installarlo nella UserInterface. Generalmente è necessario convertirlo dal formato PKCS12 al formato PEM; per questo scopo alcuni utili comandi del tool openssl sono descritti nella EDG User's Guide all'appendice B: EDG User's Guide Appendix B Una volta ottenuti userkey.pem e usercert.pem, creare nella propria home la directory ./globus e copiarvi i due files facendo attenzione ai permessi: .globus]$ pwd /home/rossi/.globus .globus]$ ll total 8 -rw rossi rossi 2008 Nov 13 16:50 usercert.pem -r rossi rossi 963 Nov 13 16:50 userkey.pem 5. Sottomettere un job Per iniziare una sessione è necessario creare un proxy, una sorta di "lasciapassare" firmato con la propria chiave privata che autenticati ed avere accesso alle risorse cui si è autorizzati. Si utilizza il comando grid-proxy-init. mario]$ grid-proxy-init Your identity: /C=IT/O=RRI/OU=Personal Certificate/L=RossiResearchInstitute/CN=Mario Enter GRID pass phrase for this identity: Creating proxy Done Your proxy is valid until Tue Apr 15 22:47: Per sottomettere un job è necessario descriverne le caratteristiche (programma da eseguire, parametri, etc...) in un file di testo utilizzando la sintassi JDL (Job Description Language). Un esempio: rossi]$ cat hello.jdl Executable = "/bin/echo"; Arguments = "hello world"; StdOutput = "message.txt"; StdError = "stderror"; OutputSandbox = {"message.txt", "stderror"}; Per sottomettere un job e recuperarne l'output, si rimanda alla guida di EDG, in particolare al capitolo 4, ove sono descritti i comandi di base dg-job-submit, dg-job-status, dg-job-get-output e dg-job-cancel: 4. Job Submission Ulteriori dettagli sull'utilizzo dei files .jdl si trovano sul sito del WP1 Datagrid: Job Description Language HowTo JDL Attributes