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 GRID service 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 - controllare il termine “spotting”

Obiettivi da monitoring tool a monitoring service Grid Information Service Monitoring Tool 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” ma le informazioni statiche (num di CPU, memoria totale) sono dei soft-state con il GIS attuale (LDAP) non e’ possibile l’event notification

General design Consumer Directory Service Producer 3) Event producer & Event schema information 4) Query or Subscribe 2) Lookup 5) Event data Directory Service e’ un buon punto di partenza sono supportati due modalita’ di invio degli eventi: streaming e query 1) Event publication information Producer

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 non esistono database centrali o monitoring server nell’architettura di base utilizzo del modello GMA (Grid Monitoring Architecture) composto da producer/consumer/registry; la raccolta puo’ essere abilitata “ad hoc” secondo le richieste 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 event proxy sensor manager sensor A sensor B sensor C sensor D sensor E

Architettura (2/7) sensor programma che genera eventi a livello implementativo il sensor puo’ essere: una classe (Java) uno script (Bash, Perl, …) un programma eseguibile  si dividono in: 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> - tramite schema XML o DTD e’ possibile anche validare il documento XML

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 : DNS name dell'Event Proxy ep_address : IP address dell'Event Proxy event_type : tipo di evento prodotto [attributo multivalue] vo_name : virtual organization [attributo multivalue] site : site validfrom : timestamp di generazione della entry validto : 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 topic queue

Scenario di utilizzo: GOC monitoring consumer NAGIOS cfg registry event proxy s.m.