I Servizi GRID
Architettura, Implementazione ed Interfacce
[email protected]
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
24/11/2004
I Servizi di GRID - [email protected]
2
Architettura della GRID
Applicazioni
Interfaccia GRID
EDG
GRID3
LCG
Servizi GRID
collettivi
Locali
GRID
middleware
Alien
Servizi GRID di base
GLOBUS
Risorse (CPU, Storage, Network)
24/11/2004
I Servizi di GRID - [email protected]
3
I Servizi della GRID
Servizi Collettivi
• 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
24/11/2004
• Information System
– Individuazione delle Risorse
– Monitoring dello Stato delle
Risorse
• Security
– Autenticazione
– Autorizzazione
Servizi di Base
I Servizi di GRID - [email protected]
4
Un’Implementazione: EDG
User
Information System
submit
query
retrieve
Resource
Broker
definisce
la propria
identità
query
Data Catalog
submit
retrieve
pubblica il
proprio stato
Site X
Computing Element
Storage Element
VOMS
24/11/2004
I Servizi di GRID - [email protected]
5
La Security sulla 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) :
http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
24/11/2004
I Servizi di GRID - [email protected]
7
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/2004
I Servizi di GRID - [email protected]
8
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/2004
I Servizi di GRID - [email protected]
9
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/2004
I Servizi di GRID - [email protected]
10
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).
24/11/2004
I Servizi di GRID - [email protected]
11
Accesso alle Risorse
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/2004
I Servizi di GRID - [email protected]
13
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/2004
I Servizi di GRID - [email protected]
14
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/2004
I Servizi di GRID - [email protected]
15
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/2004
I Servizi di GRID - [email protected]
16
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/2004
I Servizi di GRID - [email protected]
17
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
24/11/2004
I Servizi di GRID - [email protected]
18
L’Information System
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/2004
I Servizi di GRID - [email protected]
20
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
Site X
24/11/2004
Site Y
Site Z
GIIS
GIIS
GIIS
GRIS
GRIS
GRIS
I Servizi di GRID - [email protected]
21
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/2004
I Servizi di GRID - [email protected]
22
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
…e contatta direttamente il Producer
per ottenere l’informazione
Site X
Producer
GRIS
Il Producer si registra sul Registry descrivendo
che tipo di informazioni può pubblicare
24/11/2004
Registry
I Servizi di GRID - [email protected]
Il Consumer
cerca i
Producer utili
sul Registry…
23
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
Producer
Registry
Site X
Filter
Producer
Consumer
GRIS
Producer
Producer
GRIS
GRIS
• EDG ha implementato il modello GMA usando un sistema di DB
relazionale (R-GMA)  http://www.r-gma.org/
24/11/2004
I Servizi di GRID - [email protected]
24
Data Management
Replica Manager
File Management
‘Atomizza’ le operazioni di replica
Unifica l’interfaccia cliente
Orchestra l’intero sistema
Replica Catalog
Replica Selection
Mappa i file logici ai siti che
ne posseggono una copia
Trova il file “migliore”
Pre- Post-processing
Site A
Prepara
i file per il trasferimento
Valida i file dopo il trasferimento
Replication Automation
Sottoscrizione
Site B a una sorgente di dati
Load Balancing
Metadata
LFN Storage
metadata
Element A
Transaction information
Access patterns
File A File X
File B File Y
24/11/2004
Crea repliche secondo l’uso
Storage Element B
File Transfer
File A File C
File B File D
I Servizi di GRID - [email protected]
26
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
Replica
Replica
Replica
Location Service (RLS)
Metadata Service (RMC)
Optimisation Service (ROS)
Manager (RM)
RM
RLS
RMC
ROS
24/11/2004
I Servizi di GRID - [email protected]
27
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
Logical File Name 2
Logical File Name n
24/11/2004
Physical File SURL 1
GUID
Physical File SURL n
I Servizi di GRID - [email protected]
28
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
RMC
24/11/2004
Physical File SURL 1
GUID
Physical File SURL n
RLS
I Servizi di GRID - [email protected]
29
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 Nodes
RLI
LRC
RLI
LRC
Replica Location Index
Mappa tra GUID e LRC
RLI
LRC
LRC
Local Replica Catalog
Mappa tra GUID e PFN
Local Replica Catalogs
24/11/2004
I Servizi di GRID - [email protected]
30
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
24/11/2004
I Servizi di GRID - [email protected]
31
Interazione tra RM e SRM
Replica
Catalog
1
2
5
Replica Manager
client
3
6
1.
2.
3.
4.
5.
6.
SRM
4
5
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
24/11/2004
I Servizi di GRID - [email protected]
32
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 Manager
SRM
24/11/2004
SRM
Replica Location
Service
Il Replica Manager rende atomiche le
operazioni di replica, garantendo la
consistenza tra RLS e contenuto degli
SRM.
I Servizi di GRID - [email protected]
33
Servizi di Replicazione di Alto Livello
Gli user possono definire operazioni di
pre- e post-processamento per tutte le
operazioni
Il RM può di
utilizzare
replica il Replica Optimization
Service per trovare la replica “migliore”. Per
la selezione il ROS usa informazioni dagli
SRM e dal network.
Replica Manager
Replica Metadata
Catalog
Replica Location
Service
Replica Optimization
Service
SRM
24/11/2004
SRM
SRM
Monitor
Network Monitor
I Servizi di GRID - [email protected]
34
Interazione con altre componenti
User Interface o
Worker Node
Resource Broker
Information Service
Replica Metadata
Catalog
Replica Manager
Replica Location
Service
Replica Optimization
Service
Applicazioni e user usano il Replica
SRM
24/11/2004
SRM
SRM
Manager o direttamente
o attraverso il
Network Monitor
Monitor
Resource Broker. NON devono usare
direttamente l’SRM.
I Servizi di GRID - [email protected]
35
Workload Management
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/2004
I Servizi di GRID - [email protected]
37
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/2004
I Servizi di GRID - [email protected]
38
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/
[
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:
http://server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0142-0_2.pdf
24/11/2004
I Servizi di GRID - [email protected]
39
Funzionamento del WMS: EDG
UI
Job (JDL)
Network
Server
Input
Sandbox
RB
Storage
RB
Il Network Server
accetta le richieste
e le accoda
IS
Workload
Manager
Job Control
CondorG
CE characts
& status
CE
24/11/2004
RLS
I Servizi di GRID - [email protected]
SE characts
& status
SE
40
Funzionamento del WMS: EDG
Il Matchmaker
individua il miglior
CE per il job
Network
Server
UI
RLS
MatchMaker/
Broker
Il Workload ManagerRB
trova il modo diStorage
Workload
Manager
IS
Chi può
eseguire il
job?
soddisfare le
richieste
RB
Job Control
CondorG
CE
24/11/2004
I Servizi di GRID - [email protected]
SE
41
Funzionamento del WMS: EDG
Network
Server
UI
Su quale SE
sono i dati?
RLS
MatchMaker/
Broker
RB
Storage
RB
Workload
Manager
Job Control
CondorG
Quali CE
possono
eseguire il job?
Best CE
In futuro il Matchmaker potrà
usare il RM per creare nuove
repliche on demand
CE
24/11/2004
IS
I Servizi di GRID - [email protected]
SE
42
Funzionamento del WMS: EDG
RLS
Network
Server
UI
Il Job Adapter
crea un wrapper
attorno al job
RB
Storage
RB
IS
Workload
Manager
Job
Adapter
Job Control
CondorG
Sottometti il job
CE
24/11/2004
I Servizi di GRID - [email protected]
SE
43
Funzionamento del WMS: EDG
RLS
Network
Server
UI
RB
Storage
RB
IS
Workload
Manager
Job Control
CondorG
Il Job Controller
gestisce la
sottomissione e il
controllo del job
Job
Input Sandbox
24/11/2004
CE
I Servizi di GRID - [email protected]
SE
44
Funzionamento del WMS: EDG
RLS
Network
Server
UI
RB
Storage
RB
IS
Workload
Manager
Job Control
CondorG
Il CE esegue il job
interagendo con
SE e servizi locali
o remoti
GRID I/O
Controllo
CE
24/11/2004
I Servizi di GRID - [email protected]
SE
45
Funzionamento del WMS: EDG
RB
Storage
RB
Al termine del job
l’output viene
trasferito sul RB
24/11/2004
RLS
Network
Server
UI
IS
Workload
Manager
Job Control
CondorG
Output Sandbox
CE
I Servizi di GRID - [email protected]
SE
46
Funzionamento del WMS: EDG
get job
output
E lo user lo può
recuperare a suo
piacimento
RLS
Network
Server
UI
RB
Storage
RB
IS
Workload
Manager
Job Control
CondorG
CE
24/11/2004
I Servizi di GRID - [email protected]
SE
47
Funzionamento del WMS: EDG
get job
status
RLS
Network
Server
UI
RB
Storage
RB
IS
Workload
Manager
Job Control
CondorG
Logging &
Bookkeeping
In ogni momento il sistema di Logging &
Bookkeeping permette allo user di tenere
sotto controllo lo stato del job
24/11/2004
CE
I Servizi di GRID - [email protected]
SE
48