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 Attualmente non esistono grid in produzione ne modelli di management operations & support. 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

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.

WP3/5 UR4

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 UR4Gruppi 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

finanziamentiVoce di spesa (DM. 199 Ric. del 08/03/01; art.6, c.6)

Spesa (MLit) WP3-5 WP14 WP10 WP12 1/2 PD, 1/2GE

Spese di personale conferito 912.58 KEuro 293.35 195.21 290.76 135.24

A) Spese di personale a contratto (70%) 630 kEuro 105 (2 art. 2222 150k)

105 (2 art. 2222 150k

262.5 (5 art. 2222 375k

157.5 (3 art. 2222 225k

B) Spese generali direttamente imputabili all'attività di ricerca nella misura forfettizzata del 60% del costo del personale (compreso quello relativo ai ricercatori) (da verificare se rientra nel 20% dell’intero progetto)

500keuro (270keuro per 30% dei contratti:suddiv.) (230 per spese generali:suddiv.)

45k 44k

45k 30k

112.5k 82k

67.5k 74k

C) Spese per giovani ricercatori e ricercatori di chiara fama internazionale

300Keuro) 200k (2 art.23)

100k (1 art.23)

D) attrezzature 30k

E) Spese per stages e missioni all'estero di ricercatori coinvolti nel progetto

150kEuro 17 53 50

F) Costo dei servizi di consulenza e simili utilizzati per l'attività di ricerca

Altri costi di esercizio

Totale spese finanziate 1580 394 297 540 349

8

finanziamenti

Totale contratti (15)

WP3,5 INFN

Costi dei contratti per il

WP3,5 (KEuro)

Totale Finanziamento

Iniziale (Keuro)

Fondi da trasferire dall’ INFN alle altre

Istituzioni (KEuro)

INFN 4 contratti 4 394 394 /

INAF 5 contratti 2 150 540 390

INGV 3 contratti 1 75 297 222

BIO-INFORMATICA 3 contratti 1 75(37.5*2) 349 274 ½ a DEI(PD)

½ a DIST(GE)

totale 15 contratti 8 contratti 694 keuro 1580keuro 886Keuro

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 6 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 30

15 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)

OS & Net services

Basic Services

High level GRID middleware

LHCVOs common application layer

Other apps

ALICE ATLAS CMS LHCbSpecific application layer Other apps

GLOBUS 2.0

GRID middleware

22

EDG middleware GRID architecture

Collective ServicesCollective Services

Information &

Monitoring

Information &

Monitoring

Replica ManagerReplica

ManagerGrid

SchedulerGrid

Scheduler

Local ApplicationLocal Application Local DatabaseLocal Database

Underlying Grid ServicesUnderlying Grid Services

Computing Element Services

Computing Element Services

Authorization Authentication and Accounting

Authorization Authentication and Accounting

Replica CatalogReplica Catalog

Storage Element Services

Storage Element Services

SQL Database Services

SQL Database Services

Fabric servicesFabric services

ConfigurationManagement

ConfigurationManagement

Node Installation &Management

Node Installation &Management

Monitoringand

Fault Tolerance

Monitoringand

Fault Tolerance

Resource Management

Resource Management

Fabric StorageManagement

Fabric StorageManagement

Grid

Fabric

Local Computing

Grid Grid Application LayerGrid Application Layer

Data Management

Data Management

Job Management

Job Management

Metadata Management

Metadata Management

Service Index

Service Index

APPLICATIONS

GLOBUS

M / W

23

WMS Revised Architecture

UIReplicaCatalog

Inform.Service

NetworkServer

Job Contr.-

CondorG

WorkloadManager

RB node

CE characts& status

SE characts& status

RBstorage

Match-Maker/ Broker

JobAdapter

Log Monitor

Logging &Bookkeeping

WP 1

24

Network Monitoring Architecture

PCP

WEB RTPL

Distributed Data CollectorRaw

IPerf UDPmon GridFTPPingEr

Measure

CollectAndStorage

Visualization

MapCenter

Replica Managers & resources brokers

Network Managers

Forecaster

Processing

ArchiveInfo

Services(R-GMA)

Info Services

(R-GMA)

NetworkCost

WP 7

25

Replica Management Services

Replica Management

Services

Optimization

Replica Metadata

Subscription

Client

Replica Location

File Transfer

EDG-ReplicaManager

WP 2

26

Information & Monitoring: R-GMA• 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

Consumer

Registry

Store location

Lookup

locatio

n

execute or

stream

•Producers

•announce: SQL “CREATE

•Producers

•publish: SQL “INSERT”

•Consumers

•collect: SQL “SELECT”

WP 3

27

GRIS (GLUE schema)

EDG WP4 fmonserver

computing element

information providers farm monitoringarchive

runldif output

write

read

EDG WP4 mon. agent

worker node

/procfilesystem

WP4 sensor

run

readmetric output

metric output

EDG WP4 mon. agent

worker node

/procfilesystem

WP4 sensor

run

readmetric output

metric output

information index

GIIS (GLUE schema)

monitoring server

discovery service

monitoring service

ldap query

ldap query

web interface

MonitoringDB

Grid monitoring architecture

28

VOMS Architecture

Authentication

C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy

VOMS

pseudo-cert

VOMSpseudo-

cert

soap

DBJDBC

GSI

https

Tomcat & java-sec

Tomcat & java-sec

axisaxisVOM

Simpl

VOMS

implservletservlet

vomsdvomsd

Perl CLI

Java GUI

browser

Voms-proxy-init

Apache & mod_ssl

Apache & mod_ssl

voms-httpdvoms-httpdDBI

http

VOMS VOMS serverserver

request

mkgridmap

VO: CMSVO: CMS

29

http://grid.infn.it/firb-grid

• FIRB-GRID - WP3/5•  • Il progetto• Documenti e presentazioni• Partecipanti• Riunioni• Come si accede alla GRID• Progetti correlati•          INFN-GRID•          DataGRID

30

istruzioniAccedere a Grid.itQuesta pagina raccoglie una prima bozza delle istruzioni necessarie per accedere a Grid.it.

1.Richiedere il proprio certificato ad una Certification Authority 2.Registrare il proprio certificato presso la VO di cui si fa parte 3.Installare e configurare la UserInterface 4.Installare il proprio certificato nella UI 5.Sottomettere un job

1. Richiesta certificatoPer il momento l'unica Certification Authority (CA) operativa per FIRB-GRID è quella dell'INFN:

•http://security.fi.infn.it/CA 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à:

1.Recarsi dalla propria RA che avvierà la richiesta del certificato, restituendo un codice identificativo (ID). 2.Installare nel proprio browser il certificato della CA seguendo il link:

•Certificato CA INFN 3.Richiedere il certificato compilando tutti i campi richiesti e inserendo l'identificativo restituito dalla RA:

•Richiesta certificato Entro pochi giorni si riceverà un messaggio e-mail 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 certificatoIl 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:

•https://grid-vo.cnaf.infn.it/subscribe.php

31

Istruzioni cont.

3. Installare e configurare la UserInterfaceL'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 UIOttenuto 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: [rossi@userinterface .globus]$ pwd /home/rossi/.globus [rossi@userinterface .globus]$ ll total 8 -rw------- 1 rossi rossi 2008 Nov 13 16:50 usercert.pem -r-------- 1 rossi rossi 963 Nov 13 16:50 userkey.pem

5. Sottomettere un jobPer 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@userinterface mario]$ grid-proxy-init Your identity: /C=IT/O=RRI/OU=Personal Certificate/L=RossiResearchInstitute/CN=Mario Rossi/Email=mario.rossi@rossiresearch.it Enter GRID pass phrase for this identity: Creating proxy ............................................... Done Your proxy is valid until Tue Apr 15 22:47:44 2003 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@userinterface 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