Grid monitoring: sviluppi futuri
Sergio Andreozzi [INFN-CNAF]
Natascia De Bortoli [INFN-Napoli]
Sergio Fantinel [INFN-LNL]
Gennaro Tortone [INFN-Napoli]
Technical Board INFN-GRID
Bologna, 16-17 giugno 2003
Introduzione

Il monitoring e’ un’attività strategica per il calcolo distribuito

Scenari di utilizzo:





performance analisys
resources/services fault detection
“problems spotting”
statistics and capacity planning
auditing system
GRID service
Obiettivi

da monitoring tool a monitoring service
Monitoring Tool
Grid Information Service
Grid Monitoring Service
Motivazioni

caratterizzazione delle informazioni di monitoring (eventi)




a differenza dei dati forniti da un GIS, alcuni eventi di monitoring
sono generati con una frequenza maggiore (es. 30 s) – non ha
senso parlare di “soft-state”
l’aggiunta di un nuovo tipo di evento deve comportare poche
modifiche al sistema – nel caso del monitoring basato sul GIS
occorre modificare lo schema per tutte le risorse
il formato degli eventi prodotti non deve dipendere da un
particolare protocollo – architettura indipendente dalla tecnologia
l’aggiunta delle funzionalita’ e’ possibile modificando un solo layer
di software – nel caso del monitoring basato sul GIS sia le
funzionalita’ di base che la scalabilita’ sono “ereditate”
General design
Consumer
4) Query
or
Subscribe
3) Event producer & Event schema
information
2) Lookup
5) Event
data
Producer
Directory
Service
1) Event publication
information
Attivita’ di sviluppo analoghe

R-GMA (DataGRID WP3)

il modello di rappresentazione degli eventi e’ il database
relazionale:




event producer: SQL INSERT/UPDATE
event consumer: SQL SELECT
utilizzo di servlet Java per l’implementazione dei vari componenti:
Consumer, Producer e Registry – application server su ogni tipo di
risorsa / molto codice e’ stato scritto per adattare la tecnologia
scelta alla problematica di base (servlet = generic server extension)
gli sviluppi futuri di R-GMA sono orientati all’utilizzo di SQL per
query distribuite – ma questo e’ lo scopo di un Grid Information
Service non di un Grid Monitoring Service
Proposal di un Grid Monitoring Service




premesse generali
architettura e funzionalita’ dei componenti
tecnologie
scenario di utilizzo: GOC monitoring
Premesse generali

l’architettura del monitoring e’ distribuita



utilizzo del modello GMA (Grid Monitoring Architecture) composto da
producer/consumer/registry;
la raccolta puo’ essere abilitata “ad hoc” secondo le richieste





non esistono database centrali o monitoring server nell’architettura di base
data challanges, stress test, …
deve essere garantita la scalabilita’ del monitoring service
il linguaggio di programmazione da utilizzare deve essere portabile
(es. Java, C, …)
gli eventi di monitoring devono essere standard e portabili (es. XML) in
modo da consentire la futura integrazione con altri sistemi o tool di
monitoring e controllo (es. Nagios)
l’installazione e la configurazione dei sensor di monitoring sulle risorse
deve essere semplice in modo da minimizzare l’impatto sui sitemanager
Architettura
(1/7)
registry
consumer
consumer
event proxy
sensor manager
sensor A
sensor B
sensor manager
sensor C
sensor A
sensor B
sensor D
sensor E
sensor C
Architettura

(2/7)
sensor


programma che genera eventi
a livello implementativo il sensor puo’ essere:




si dividono in:



una classe (Java)
uno script (Bash, Perl, …)
un programma eseguibile
host sensors: effettuano misure sull’host monitorato: ad es. CPU load, available
memory, ecc.
network sensors: utilizzano SNMP per interrogare i dispositivi di rete (router,
switch, …)
il funzionamento avviene secondo una delle seguenti modalita’:


continuous mode: l’evento viene generato ad ogni esecuzione del sensor; la
generazione degli eventi e’ sincrona
threshold mode: l’evento viene generato quando la misura effettuata e’
maggiore (o minore) di una determinata soglia; la generazione degli eventi e’
asincrona
Architettura
(3/7)
schema XML di un evento
<event>
<host name=”pluto.infn.it” ip=”192.135.13.1” timezone=”GMT+2” />
<header name=”system.processes” type=”continuous”
timestamp=”109832123” sample_period=”60” />
<body>
<measurement type=”system.process”>
<detail type=”total” value=”100” units=”abs” />
<detail type=”running” value=”30” units=”abs” />
<detail type=”sleeping” value=”69” units=”abs” />
<detail type=”zombie” value=”1” units=”abs” />
</measurement>
</body>
</event>
Architettura

(4/7)
sensor manager


componente responsabile della gestione dei sensor installati sull’host da
monitorare
un sensor gestito da un sensor manager e’:




off: se non ne e’ schedulata l’esecuzione
active: se ne e' schedulata l'esecuzione da parte del system manager;
on-line: se gli eventi che produce vengono trasmessi dal sensor manager
all‘event proxy;
ha il compito di:




cambiare lo stato dei sensor (off  active, active  on-line)
creare i thread di esecuzione dei sensor impostando l’intervallo di campionamento
inviare il messaggio di keep-alive dell’host al proprio event proxy
effettuare il caching dell’ultimo evento generato da ogni sensor per supportare il
funzionamento in modalita’ query
Architettura

(5/7)
event proxy



componente che si interfaccia con i vari consumer.
e’ possibile installare anche piu’ event proxy al fine di aumentare la
scalabilita’ del servizio di monitoring
ha il compito di:




dichiarare al registry gli eventi offerti dai sensor manager
accettare i subscribe/unsubscribe da parte dei consumer
attivare il forward degli eventi generati dai sensor ai consumer che hanno
effettuato il subscribe di quel tipo di evento
le modalita’ di forward degli eventi sono:


streaming: dopo il subscribe da parte di un consumer gli eventi vengono inviati
uno dopo l’altro fino all’unsubscribe
query: non viene effettuato il subscribe; l’event proxy invia al consumer l’ultimo
evento generato del tipo richiesto
Architettura

(6/7)
consumer


viene utilizzato da un client per la richiesta di eventi
le azioni previste per il subscribe di eventi sono le seguenti:






query al registry per l’individuazione degli event proxy che forniscono gli eventi
richiesti
dichiarazione degli eventi a cui e’ interessato tramite un documento XML inviato a
ciascun event proxy individuato; il documento deve specificare la modalita’ di
forward degli eventi (query o streaming)
subscribe a ciascun event proxy
ricezione degli eventi richiesti (in query o streaming)
durante la ricezione (periodicamente) invia il messaggio di keep-alive agli event
proxy
per terminare la connessione effettua l’unsubscribe verso ciascun event proxy
tramite un documento XML
Architettura

(7/7)
registry


viene utilizzato dai consumer per localizzare gli event proxy che forniscono
gli eventi richiesti
il deployment avvenire a livello:






virtual organization
site
…
contiene le registrazioni di keepalive degli event proxy insieme agli eventi
forniti
e’ un directory service; una possibile implementazione potrebbe essere un
OpenLDAP server
esempio di schema del registry:







ep_name
ep_address
event_type
vo_name
site
validfrom
validto
:
:
:
:
:
:
:
DNS name dell'Event Proxy
IP address dell'Event Proxy
tipo di evento prodotto [attributo multivalue]
virtual organization [attributo multivalue]
site
timestamp di generazione della entry
timestamp di scadenza della entry
Interazioni tra componenti
registry
consumer
eventi
query
event proxy
keep-alive
sensor manager
sensor A
sensor B
sensor C
Tecnologie

XML

JMS (Java Message Service)





specifica SUN per l’invio/ricezione di messaggi tra applicazioni
messaging models: queues e topics
message selection/priority
tipi di messaggi: Text, Byte, Object
API disponibili per Java,C++,…
JMS messaging models
Publisher3
Publisher3
publish
queue
Publisher2
Publisher1
consume
Subscriber2
topic
Publisher2
msg n
:
:
:
msg 7
msg 6
msg 5
msg 4
msg 3
msg 2
msg 1
publish
Publisher1
consume
consume
Subscriber1
Subscriber2
msg n
:
:
:
msg 7
msg 6
msg 5
msg 4
msg 3
msg 2
msg 1
consume
Subscriber1
Scenario di utilizzo: GOC monitoring
NAGIOS
NAGIOS
consumer
consumer
cfg
registry
event proxy
event proxy
event proxy
s.m.
s.m.
s.m.s.m.
s.m.
s.m.s.m.
s.m.
s.m.s.m.
s.m.
s.m.
s.m.
s.m.
s.m.s.m.
s.m.
s.m.s.m.
s.m.
s.m.s.m.
s.m.
s.m.
s.m.
s.m.
s.m.s.m.
s.m.
s.m.s.m.
s.m.
s.m.s.m.
s.m.
s.m.