La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Grid monitoring: sviluppi futuri Sergio Andreozzi [INFN-CNAF] Natascia De Bortoli [INFN-Napoli] Sergio Fantinel [INFN-LNL] Gennaro Tortone [INFN-Napoli]

Presentazioni simili


Presentazione sul tema: "Grid monitoring: sviluppi futuri Sergio Andreozzi [INFN-CNAF] Natascia De Bortoli [INFN-Napoli] Sergio Fantinel [INFN-LNL] Gennaro Tortone [INFN-Napoli]"— Transcript della presentazione:

1 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, giugno 2003

2 Introduzione Il monitoring e unattività strategica per il calcolo distribuito Scenari di utilizzo: performance analisys resources/services fault detection problems spotting statistics and capacity planning auditing system GRID service

3 Obiettivi da monitoring tool a monitoring service Grid Monitoring Service Grid Information Service Monitoring Tool

4 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 laggiunta 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 laggiunta 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

5 General design Producer Directory Service Consumer 1) Event publication information 2) Lookup 3) Event producer & Event schema information 5) Event data 4) Query or Subscribe

6 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 limplementazione 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 allutilizzo di SQL per query distribuite – ma questo e lo scopo di un Grid Information Service non di un Grid Monitoring Service

7 Proposal di un Grid Monitoring Service premesse generali architettura e funzionalita dei componenti tecnologie scenario di utilizzo: GOC monitoring

8 Premesse generali larchitettura del monitoring e distribuita non esistono database centrali o monitoring server nellarchitettura 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) linstallazione e la configurazione dei sensor di monitoring sulle risorse deve essere semplice in modo da minimizzare limpatto sui sitemanager

9 Architettura (1/7) sensor manager sensor Asensor Bsensor Csensor Asensor Bsensor C sensor Dsensor E event proxy registry consumer

10 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 sullhost 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: levento viene generato ad ogni esecuzione del sensor; la generazione degli eventi e sincrona threshold mode: levento viene generato quando la misura effettuata e maggiore (o minore) di una determinata soglia; la generazione degli eventi e asincrona

11 Architettura (3/7) schema XML di un evento


12 Architettura (4/7) sensor manager componente responsabile della gestione dei sensor installati sullhost da monitorare un sensor gestito da un sensor manager e: off: se non ne e schedulata lesecuzione active: se ne e' schedulata l'esecuzione da parte del system manager; on-line: se gli eventi che produce vengono trasmessi dal sensor manager allevent proxy; ha il compito di: cambiare lo stato dei sensor (off active, active on-line) creare i thread di esecuzione dei sensor impostando lintervallo di campionamento inviare il messaggio di keep-alive dellhost al proprio event proxy effettuare il caching dellultimo evento generato da ogni sensor per supportare il funzionamento in modalita query

13 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 laltro fino allunsubscribe query: non viene effettuato il subscribe; levent proxy invia al consumer lultimo evento generato del tipo richiesto

14 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 lindividuazione 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 lunsubscribe verso ciascun event proxy tramite un documento XML

15 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

16 Interazioni tra componenti sensor manager sensor Asensor Bsensor C event proxy registry consumer eventi query keep-alive

17 Tecnologie XML JMS (Java Message Service) specifica SUN per linvio/ricezione di messaggi tra applicazioni messaging models: queues e topics message selection/priority tipi di messaggi: Text, Byte, Object API disponibili per Java,C++,…

18 JMS messaging models queue topic

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


Scaricare ppt "Grid monitoring: sviluppi futuri Sergio Andreozzi [INFN-CNAF] Natascia De Bortoli [INFN-Napoli] Sergio Fantinel [INFN-LNL] Gennaro Tortone [INFN-Napoli]"

Presentazioni simili


Annunci Google