pci matchmaker

Grid Computing e Linux
Gian Luca Rubini
INFN-CNAF
Al giorno d’oggi “fare scienza”
richiede collaborazione fra
diverse strutture….
Uno dei requirement più sentiti è quello di costruire
partnership temporanee (ad esempio per grossi
esperimenti di breve durata)
L’accesso a risorse eterogenee avviene on demand
What is the Grid ?
“Resource sharing & coordinated
Courtesy of
Carl Kesselman
problem solving in dynamic, multiinstitutional virtual organizations”
1. Enable integration of distributed resources
2. Using general-purpose protocols & infrastructure
3. To achieve better-than-best-effort service
Grid? Per fare cosa?
• Number crunching
– Simulazioni (ad esempio l’implementazione di
modelli climatici)
– Ingegneria (ad esempio analisi strutturali)
• Data intensive
– Analisi di esperimenti (high-energy physics)
– Analisi di immagini (astronomia)
Grid stack
Grid environments: alcuni concetti
riguardanti la standardizzazione
• Costruire sistemi distribuiti attraverso “l’unione” di
diverse componenti eterogenee richiede come
minimo alcune politiche di standardizzazione:
– Una strategia per l’identificazione delle risorse
– Un sistema per il manegement del lifetime delle
risorse
– Discovery delle risorse e monitoring delle stesse
– Un sistema comune di messaggistica degli errori
– Un sistema di notifiche
– E molto altro…
PBox
VO
GRID
PBox
GRID
PBox
Resource sharing
PBox
PBox
SITE
SITE
PBox
PBox
SITE
PBox
PBox
SITE
PBox
• VO = Virtual Organization
• PBox = Policy Box
SubSITE
SubSITE
SubSITE
Virtual Organizations (what is this ?)
• Sono insiemi dinamici di regole e di utenti che
permettono la condivisione di risorse facenti
parte di una o più organizzazioni fisiche.
Computer
Center 1
Utenti locali
Comp. Cent.1
VO
Utenti comuni ai
domini locali e alla
VO.
Computer
Center 2
Utenti locali
Comp. Cent.2
Utenti della VO
Ancora sul concetto di Grid
• Dopo la slide relativa ai Grid layers e
quella relativa allo sharing delle risorse
una Grid può essere vista come una sorta
di “livello” che permette un utilizzo
ordinato di insiemi eterogenei di risorse.
• Gli utilizzatori delle Grid sono
generalmente utenti appartenenti a Virtual
Organizations
Virtualizzazione delle risorse
• Attualmente le risorse “virtualizzate” sono 2: Computing
Element (CE) e Storage Element (SE).
• Sui CE vengono elaborati dei Job (sì: la Grid per ora
funziona con l’elaborazione batch “vecchio stampo”).
• I Job vengono sottomessi da parte degli utenti in 2 modi:
– Direttamente sui CE senza nessun processo di resource
discovery
– Passando da un Resource Broker, una sorta di router per i job,
che individua in base alla richiesta quali sono le migliori risorse
disponibili per l’elaborazione/memorizzazione (best effort job
submission)
• Gli SE sono utilizzati per memorizzare i risultati dei Job
oppure direttamente su richiesta dell’utente (in questo
caso la richiesta ha una scadenza temporale).
Grid Middleware
“User
interface”
Input “sandbox”
Replica
Catalogue
Information
Service
DataSets info
Output “sandbox”
er
ok
us
tat
Br
In
fo
Job Status
Computing
Element
Publish
”+
ox
”
ox
bS
fo
db
db
n
“sa
Jo
CE in
san
ut
tp
Ou
Logging &
Book-keeping
Job Query
Job Submit Event
Author.
&Authen.
SE &
t“
pu
In
Resource
Broker
Storage
Element
Security: terminologia
• Authentication: stabilisce l’identità
• Authorization: stabilisce i diritti/permessi
• Protezione dei messaggi
–Integrità
–Confidenzialità
• Non-repudiation
• Digital signature
• Accounting
• Delega
Un grosso problema: coniugare il
concetto di VO e security
No Cross-
Domain Trust
Certification
Authority
Certification
Authority
Policy
Authority
Policy
Authority
Sub-Domain B1
Sub-Domain A1
Domain A
Domain B
Task
Federation
Service
GSI
Server X
Virtual
Organization
Domain
Server Y
L’utente si presenta con delle credenziali
che verranno poi interpretati dai vari
domini amministrativi
Compute
Center
Service
Rights
VO
Compute
Center
Attenzione: ci sono diversi metodi
per gestire le credenziali
X.509
AC
Compute
Center
Rights
VO
X.509/SSL
SAML
attribute
Service
X.509
AC
Kerberos/
WS-Security
XACML
Doc
Compute
Center
Uno standard:
Grid Security Infrastructure (GSI)
• E’ basato sul concetto di PKI
– Utilizza il protocollo SSL per l’autenticazione e la
cifratura dei messaggi
• X.509 per l’identificazione degli attori in gioco
– Per utenti, servizi, hosts, etc.
• Certificati proxy
– Estensioni secondo lo standard GSI per i certificati
X.509 per la delega e il single sign-on
Certificati Proxy
Create
Service
CN=Jane Doe
X.509 Id
certificate
X.509 Proxy
Delegation
CN=Jane Doe/9874
Rights:
Can access file F1,
Service S1,
…
F1
L’utente si presenta
con delle credenziali
nell’accedere alle
risorse.
X.509 Proxy
certificate
S1
Ottenere un certificato
• Il comando grid-cert-request è utilizzato per
creare una coppia pubblica/privata di chiavi e un
certificato non firmato nella directory ~/.globus/:
– usercert_request.pem: Certificato non firmato
– userkey.pem: Chiave privata
• Spedire via mail usercert_request.pem alla
propria CA di riferimento
• Si ottiene in risposta un dertificato firmato
Memorizzarlo in ~/.globus/usercert.pem
Informazioni relative al certificato
• grid-cert-info
% grid-cert-info -subject
/C=US/O=Globus/O=ANL/OU=MCS/CN=Ian Foster
• Alcune opzioni relative al comando
-all
-startdate
-subject
-enddate
-issuer
-help
Effettuare il login sulla Grid
•
Il primo passo è generare un certificato proxy, così si effettua anche
autenticamente una sorta di login (l’utente viene infatti identificato
grazie ai certificati presenti nella directory ~/.globus :
% grid-proxy-init
Enter PEM pass phrase: ******
• Il certificato proxy ha una durata limitata e serve per effettuare
operazioni sulla Grid evitando di dovere ripetere la password per
ogni operazione.
• Alcune opzioni relative a grid-proxy-init:
-hours <lifetime of credential>
-bits <length of key>
-help
grid-proxy-init: alcune
considerazioni
• grid-proxy-init crea un certificato proxy locale.
• La chiave privata è utilizzata per firmare un certificato
proxy, con una nuova coppia di chiavi pubblica/privata.
– L’utente espone la propria chiave privata solo durante
la generazione del proxy, successivamente non sarà
più necessaria
• Il certificato proxy viene memorizzato in /tmp, è in readonly mode
• grid-proxy-info displays proxy details
Grid Sign-On With
grid-proxy-init
User
certificate file
Pass
Phrase
Private Key
(Encrypted)
User Proxy
certificate file
Eliminare il cert. proxy (logout)
• Per eliminare il proprio certificato proxy
locale:
% grid-proxy-destroy
• Attenzione: questo non elimina altri proxy
generati per delega
– Altri entità/domini amministrativi possono
utilizzare il proxy dell’utente per generarne
degli altri di brevissima durata
Delega
• Delega = creazione remota di un
certificato proxy
– Nuova coppia di chiavi generata
– Il proxy e la chiave pubblica sono inviati al
client
– Il client firma il proxy
– Generalmente il server memorizza il proxy in /
tmp
Secure Services
• Sui server di Grid il gatekeeper effettua la
conversione fra utenti di Grid e quelli locali
via Grid-Map-File.
• E’ un file creato/mantenuto a mano !
# Distinguished name
Local
#
username
"/C=US/O=Globus/O=NPACI/OU=SDSC/CN=Rich Gallup”
rpg
"/C=US/O=Globus/O=NPACI/OU=SDSC/CN=Richard Frost”
frost
"/C=US/O=Globus/O=USC/OU=ISI/CN=Carl Kesselman”
u14543
"/C=US/O=Globus/O=ANL/OU=MCS/CN=Ian Foster”
itf
User Interface
•
•
•
E’ il principale punto di accesso per I
servizi di Grid
Permette di connettersi a…. e/o
svolgere:
– Proxy server
– Job management
• Job submission
• Job monitoring
• Visualizzazione dell’output
– Operazioni sui dati
• Upload di file verso uno a
più SE
• Creare repliche di dati
• Effettuare il discovery di
repliche
– Altro…
Generalmente le UI forniscono API
in C++ e Java
UI
JDL
• La sottomissione di un job
richiede la formulazione della
richiesta secondo un JDL
(Job Description Language)
file
Struttura del CE (in Grid.It)
Un CE è visto come una coda
batch a cui è possibile accedere
tramite un Grid Gate front end
Logging
Logging
Job request
Gatekeeper
I.S.
Info
system
gridmapfile
Grid gate
Sistemi locali per il job submission:
Condor / PBS / LSF master
Farm di worker
nodes
Struttura di uno Storage Element
•
•
•
Storage elements: memorizza file
Replica Catalogue - Quali copie esistono per un file?
Replica Location Service - Dove sono queste copie ?
File transfer
Requests
Logging
Info system
Event
Logging
Local
Info
GridFTP
Gatekeeper
gridmapfile
Disk arrays or
tapes
Resource Broker
•
•
•
Implementa il “Workload Management System”
– Accetta sottomissioni di job
– Indirizza I job nei “giusti” (CE)
– Permette agli utenti di:
• Ottenere informazioni sullo status dei job
• Ottenere l’output
Generalmente le UI sono configurate con un Resource
Broker (RB) di default.
Il JDL permette di:
– Specificare direttamente un CE
– Specificare alcuni attributi che “aiuteranno” il Broker a
trovare il CE più adatto
– Specificare un SE (in questo caso il Broker cerca il CE
più “vicino e conveniente” interrogando il Replica
Location Service)
Information System
Si aggiorna ogni 5 minuti ricevendo delle notifiche dai vari CE,SE.
E’ utilizzato dal Resource Broker per effettuare il discovery delle
risorse che soddisfano i requisiti contenuti in una job submission
• “Leaf/node” system: currently BDII is used
•
•
Site
Element
Site a
CE
CE
Site b
CE
SE
CE
SE
RB node
Network
Server
UI
Workload
Manager
Replica
Location
Server
Inform.
Service
Job Contr.
CondorG
CE characts
& status
Computing
Element
SE characts
& status
Storage
Element
Job
RB node
Status
Replica
Location
Server
Network
Server
UI
Workload
Manager
Inform.
Service
UI: accesso al WMS
Job Contr.
CondorG
CE characts
& status
Computing
Element
SE characts
& status
Storage
Element
submitted
edg-job-submit myjob.jdl
Myjob.jdl
UI
Job
RB node
Statu
s
submitted
JobType = “Normal”;
Replica
Network
Executable = "$(CMS)/exe/sum.exe"; Location
Server
Server
InputSandbox = {"/home/user/WP1testC","/home/file*”,
"/home/user/DATA/*"};
OutputSandbox = {“sim.err”, “test.out”, “sim.log"};
Requirements =Workload
other. GlueHostOperatingSystemName
==
Inform.
Manager
“linux" &&
Service
other. GlueHostOperatingSystemRelease == "Red Hat 7.3“
&& other.GlueCEPolicyMaxCPUTime > 10000;
Job Contr.
Rank = other.GlueCEStateFreeCPUs;
CondorG
CE characts
& status
Computing
Element
JobSEDescription
Languag
characts
& status
(JDL):
si specificano i
requirement per la
sottomissione
Storage
Element
NS: network daemon
RB node
utilizzato per
sottometterejob
Network
Server
Job
RB
storage
Status
submitted
Replica
Location
Server
UI
Input
Sandbox
files
Job
Workload
Manager
Inform.
Service
Job Contr.
CondorG
CE characts
& status
Computing
Element
SE characts
& status
Storage
Element
waiting
RB node
Job
Job submission
Network
Server
UI
Status
Replica
Location
Server
Job
RB
storage
Workload
Manager
WM: è il front end di
un sistema decisionale,
sceglie la risorsa
“migliore”.
Computing
Element
Inform.
Service
Job Contr.
CondorG
CE characts
& status
SE characts
& status
Storage
Element
submitted
waiting
RB node
Job
Job submission
Network
Server
MatchMaker/
Broker
UI
RB
storage
Workload
Manager
Dove posso
eseguire il job ?
Status
Replica
Location
Server
Inform.
Service
Job Contr.
CondorG
CE characts
& status
Computing
Element
SE characts
& status
Storage
Element
submitted
waiting
RB node
Job
Job submission
Network
Matchmaker: è colui
che
Server
UI
decide su quale CE spedire
il job.
RB
storage
MatchMaker/
Broker
Workload
Manager
Status
Replica
Location
Server
Inform.
Service
Job Contr.
CondorG
CE characts
& status
Computing
Element
SE characts
& status
Storage
Element
submitted
waiting
RB node
Job submission
Network
Server
MatchMaker/
Broker
UI
RB
storage
Workload
Manager
Job Contr.
CondorG
Status
Replica
Location
Server
Inform.
Service
Qual è lo
status della
Grid ?
CE characts
& status
Computing
Element
Job
Dove sono gli SE
che contengono
eventuali dati ?
SE characts
& status
Storage
Element
submitted
waiting
RB node
Job
Job submission
Network
Server
MatchMaker/
Broker
UI
RB
storage
Workload
Manager
Status
Replica
Location
Server
Inform.
Service
CE choice
Job Contr.
CondorG
CE characts
& status
Computing
Element
SE characts
& status
Storage
Element
submitted
waiting
RB node
Job
Job submission
Network
Server
UI
RB
storage
Workload
Manager
Job Contr.
CondorG
Status
Replica
Location
Server
Inform.
Service
Job
Adapter
CE characts
SE characts
JA: effettua gli ultimi aggiustamenti
per
& status
& status
la sottomissione del job
(ad esempio la creazione di un wrapper script, etc.)
Computing
Element
Storage
Element
submitted
waiting
RB node
Job
Job submission
Network
Server
UI
RB
storage
Status
Replica
Location
Server
Inform.
Service
Job
Job Contr.
CondorG
Computing
Element
waiting
ready
Workload
Manager
JC: è il vero e proprio
Job manager (via
CondorG)
submitted
CE characts
& status
SE characts
& status
Storage
Element
RB node
Job
Job submission
Network
Server
UI
RB
storage
Workload
Manager
Status
Replica
Location
Server
Inform.
Service
Computing
Element
waiting
ready
scheduled
Job Contr.
CondorG
Input
Sandbox
files
submitted
CE characts
& status
SE characts
& status
Job
Storage
Element
RB node
Job submission
Network
Server
UI
RB
storage
Workload
Manager
Job
Status
Replica
Location
Server
Inform.
Service
submitted
waiting
ready
scheduled
Job Contr.
CondorG
running
Input
Sandbox
“Grid enabled”
data transfers/
accesses
Computing
Element
Job
Storage
Element
RB node
Job submission
Network
Server
UI
RB
storage
Workload
Manager
Job
Status
Replica
Location
Server
waiting
ready
Inform.
Service
Job Contr.
CondorG
scheduled
running
Output
Sandbox
files
Computing
Element
submitted
done
Storage
Element
RB node
edg-job-get-output <dg-job-id>
Job submission
Network
Server
UI
RB
storage
Workload
Manager
Job
Status
Replica
Location
Server
waiting
ready
Inform.
Service
Job Contr.
CondorG
scheduled
running
Output
Sandbox
Computing
Element
submitted
done
Storage
Element
RB node
Job submission
Network
Server
UI
Output
Sandbox
files
Job
Status
submitted
Replica
Location
Server
waiting
ready
RB
storage
Workload
Manager
Inform.
Service
scheduled
running
Job Contr.
CondorG
done
cleared
Computing
Element
Storage
Element
RB node
Job monitoring
edg-job-status <dg-job-id>
edg-job-get-logging-info <dg-job-id>
UI
LB: riceve e memorizza
gli eventi relativi ad un
Job.
Job
status
Network
Server
Workload
Manager
Logging &
Bookkeeping
Job Contr.
CondorG
Log
Monitor
LM: effettua il parsing
dei log di CondorG e
spedisce tutto al sistema LB
Computing
Element
•
Altri comandi relativi ai job che si
possono invocare da una UI
edg-job-cancel
– Per eliminare un job dalla coda
• edg-job-status
– Mostra lo status del job
• edg-job-get-output
– Restituisce l’output del job (OutputSandbox files)
• edg-job-get-logging-info
– Mostra le informazioni di log relative ad un job
• edg-job-list-match
– Mostra tutte le risorse che soddisfano una richiesta di job
submission
– Permette di effettuare un resource matching senza effettuare una
sottomissione vera e propria.
Job submission
•
edg-job-submit [–r <res_id>] [-c <config file>]
[-vo <VO>] <job.jdl>
– -r il job viene spedito direttamente al CE
indentificato da <res_id>
– -c specifica un apposito <config file>
– -vo la Virtual Organization
Esempio di file JDL
Executable = “gridTest”;
StdError = “stderr.log”;
StdOutput = “stdout.log”;
InputSandbox = {“/home/joda/test/gridTest”};
OutputSandbox = {“stderr.log”, “stdout.log”};
InputData = “lfn:testbed0-00019”;
DataAccessProtocol = “gridftp”;
Requirements = other.Architecture==“INTEL” && \
other.OpSys==“LINUX” && other.FreeCpus
>=4;
Rank = “other.GlueHostBenchmarkSF00”;
Ma allora Linux e la Grid ?
•
•
•
•
•
•
Come detto durante l’introduzione l’obiettivo delle Grid è quello di
permettere la cooperazione dei vari utenti della comunità scientifica
internazionale.
Sistemi software chiusi ostacolano la collaborazione perché non
consentono la modifica di programmi per adattarli alle particolare
esigenze della propria struttura di appartenenza.
Le varie Grid mondiali adottano quasi tutte sistemi operativi Unix, in
particolare Linux (percentuale vicina al 100%, le briciole rimangono
per Sun Solaris e IBM AIX).
Il middleware della Grid è prodotto totalmente con software Open
Source.
Il software prodotto dai vari enti di ricerca è rilasciato con licenze
che permettono la modifica dei sorgenti, ma non sono altrettanto
“libere” come la GPL.
E il sistema operativo più diffuso del mondo che ruolo gioca nella
Grid ? Zero. Fino ad ora non vi è traccia delle famose finestre.
2 progetti italiani (INFN-CNAF)
• Grid Policy Box (G-PBox)
• Grid monitoring (GridICE)
Policy e Grid: un problema aperto
• Il gruppo di studio dell’INFN-CNAF ha
individuato 3 tipi di policy:
– Policy riguardanti solo una VO
• “Users of VO cms/muon get their job on the
highest priority queue”
– Policy locali (relative ad esempio alle farm)
• “Local users always get top priority”
– Policy miste
• “User John.Simms, member of VO cms/muon,
cannot access the CNAF farm”
Policy e Grid: un problema aperto (2)
• I siti locali devono:
– Avere controllo assoluto sulle loro risorse
– Devono avere un’unica interfaccia per il management
delle policy (locali e non)
• VOs e ambienti di Grid devono:
– Distribuire policy a differenti domini amministrativi e
devono ottenere la loro approvazione
– Devono consentire un elevato livello di “granularità”
PBox
VO
GRID
PBox
PBox
GRID
Architettura del G-PBox,
un sistema Open Source
PBox per le
PBox
PBox
policy
SITE
SITE
PBox
PBox
SubSITE
SITE
PBox
SITE
PBox
SubSITE
SubSITE
56
Architettura del G-PBox
• I PBox….
– Ricevono richieste di accesso alle risorse ed
effettuano una valutazione
– Forniscono risposte del tipo DENY
[Obligations], PERMIT [Obligations],
UNDEFINED.
– Creano e distribuiscono policy
• Tutti I PBox sono strutturalmente identici
• Un PBox permette connessioni solo da
determinati client
X
PBox
P1
P2
P3
X
Y
A
P
A
P
A
P
P1
P2
X
PBox
X
Y
P1
A
A
P2
A
R
P3
A
A
P3
P1
P2
P3
Flusso distributivo delle policy
fra 2 PBox appartenenti a 2 livelli
Y
PBox
Y
A
PA
PB
A
PB
P1
P
P1
P2
P
P3
P
P2
P3
PA
Y
PBox
Y
PA
A
PA
PB
A
PB
P1
A
P1
P2
R
P2
P3
A
P3
58
Componenti interni
1 componenti interni
PR
Modulo
riceve
PATchePR
richieste di valutazione
da parte del PEP.
3 componenti “boundary”
PCI
PCI
PAT
PAT
PDP
PDP
PCI
PCI
PCI
Interfaccia per le
comunicazioni con gli altri
PBox
Operaz. di un utente
Intrefaccia amministrativa
su una risorsa
PBOX
PDP
PAT
PAT
del
PEP
PR
PDP59
Valutazione delle policy
Ogni client (for example a CE, SE, ecc.) deve
implementare un PEP (Policy Enforcement Point)
• Un client invia una richiesta al proprio PEP, il quale
trasforma la richiesta in un formato comprensibile al
PDP del PBox di riferimento e gliela invia (1)
• Il PDP restituisce una risposta (2)
• Il PEP effettua nuovamente una conversione verso il
formato proprietario del client.
1
client PEP
2
PDP
60
Policy Language
• Le policy sono espresse in XACML (eXtended
Access Control Markup Language)
– XACML può essere esteso in modo da implementare
policy di accounting e management
• Questo è possibile grazie al concetto di obligation policies
– Nuovi tipi di actions (direttiva XACML) potrebero
essere implementate (esempio: uri:pbox:1.0:submit,
per indicare la sottomissione di un job)
Alcuni problemi rimasti in sospeso
• Sottomissione diretta dei job
• Alcune policy, per la loro applicazione,
necessitano di una visione globale dell’utilizzo
delle risorse nella Grid (esempio: “Impedisci
l’accesso ai CE agli utenti che hanno già
sottomesso 50 jobs o più nell’intera Grid”)
– Soluzione: implementazione di un sistema di
accounting
Grid Monitoring
GridICE
Definizione di Grid Monitoring
• Grid Monitoring:
●
●
Consiste nel monitorare risorse di grid
significative con i relativi attributi
in order to
●
Analizzare la performance della Grid nel suo
complesso
●
Rilevare e segnalare
●
malfunzionamenti
●
Violazioni dei contratti di utilizzo delle
risorse (SLA)
●
Eventi programmati dall’utente
E’ un elemento fondamentale per la GMA
(Grid Management Activity), operata dai
GOC (Grid Operation Center) nazionali
Componenti per un servizio
Di monitoring per la Grid
●
Servizio di rilevazione:
●
●
●
Servizio di discovery:
●
Scoprire le risorse disponibili
●
Aggiornare il GRIS (Grid Information Service)
Servizio di notifica:
●
●
Errori, violazioni di SLA, eventi definiti dall’utente
Analisi dei dati:
●
●
Interrogazione delle risorse
Reports e statistiche
Servizio di presentazione:
●
Via web
Flusso dei dati: dalla risorsa all’utente
Presentation Service
Data
Analyzer
Data Collection
(historical)
Detection &
Notification
Grid Information Service
Measurement Service
Un esempio: raccolta di
informazioni da un cluster
web interface
ldap query
GIIS
First discovery phase
Central
Monitoring
Database
information index
Second discovery phase
ldap query
monitoring server
EDG-WP4
fmonserver
GRIS (GLUE
schema)
run
write
ldif output
information
providers
EDG-WP4 monitoring
agent
run
read
farm
monitoring
archive
cluster head node
metric output
WP4 sensor
read
metric output
EDG-WP4 monitoring
agent
run
metric output
WP4 sensor
read
metric output
/proc
filesystem
/proc
filesystem
cluster
worker node
cluster
worker node
Monitoring scenario:
GridICE deployment
GridICE Server
TOPLEVEL
GIIS
REGION
GIIS
REGION
GIIS
site INFN-CNAF
site CERN
LEMON Client
GRIS
SITE GIIS
LEMON Client
computing element
access node
SITE GIIS
broker
LEMON Client
LEMON Client
...
LEMON Client
worker nodes
GRIS
LEMON Server
GRIS
2136
storage element
access node
replica location
service
LEMON
Client
GRIS
LEMON Server
GRIS
2136
storage element
access node
Ciclo di vita delle risorse
•
Un sistema di monitoring deve essere in
grado anche di tenere la traccia storica dei
cambiamenti di stato.
Server Side processes layout
WEB
5B
1C
2A
Gfx/Presentation
5A
Monitoring
DB
Config
2B
1A
1B
3
GIIS
GRIS
Nagios/scheduler
4B
1: entities discovery
2: generation of config files
3: check scheduling
4: entities info collection
5: DB info rendering
Discovery
GRID
4A
Check
Grid Information System
LDAP Interface
Developed by
DataTAG WP4
GridICE all’opera
Grid.It
Alcuni link
• GridICE: http://infnforge.cnaf.infn.it/gridice
• Grid.It: http://grid-it.cnaf.infn.it
• Situazione della Grid Europea (e non solo):
http://gridice2.cnaf.infn.it:50080/gridice
• Globus (Grid Middleware):
http://www.globus.org
• EGEE: http://www.eu-egee.org
•