Progetto e prototipazione di una infrastruttura di comunicazione per il supporto al monitoraggio distribuito del traffico di rete Progetto di Reti di Calcolatori.

Presentazione sul tema: "Progetto e prototipazione di una infrastruttura di comunicazione per il supporto al monitoraggio distribuito del traffico di rete Progetto di Reti di Calcolatori."— Transcript della presentazione:

1 Progetto e prototipazione di una infrastruttura di comunicazione per il supporto al monitoraggio distribuito del traffico di rete Progetto di Reti di Calcolatori LS di Paolo Battarra

2 Reti di Calcolatori LS2 Obiettivi del lavoro  Creare un supporto che: rendesse semplice controllare il traffico di una macchina fisicamente lontana; fornisse dati significativi con pochi comandi; mascherasse per quanto possibile all’utente interessato a queste informazioni la complessità dei passaggi che hanno portato al loro ottenimento.  Ottenere una architettura che garantisse portabilità, affidabilità e che assicurasse performance accettabili dal punto di vista di un utilizzatore.  Possibilità di avere un monitoraggio il più dinamico possibile, ove l’utente: non dovesse possedere alcuna informazione pregressa sulla struttura della specifica rete locale; potesse spostare il suo controllo e la sua attenzione su altri host senza troppo sforzo e con costi contenuti.

3 Reti di Calcolatori LS3 Il monitoraggio  Tutto il lavoro deve sempre tenere in considerazione il contesto particolare nel quale si vuole operare: trattare tutto nell’ambito del controllo e del monitoraggio  Punti fondamentali da tenere in considerazione: Concetto di minima intrusione; La garanzia della fornitura ed il mantenimento della qualità del servizio; La dinamicità delle operazioni legate al monitoraggio; Architettura logica di base con la quale sviluppare il lavoro: il ruolo del monitorante e quello del monitorato.  Sviluppo di una soluzione rispetto ad un caso particolare, ma ragionamenti di carattere generale che permettono di avere la possibilità di generalizzare i risultati ottenuti ed adattarli a contesti diversi, allargando in questo modo lo scenario di utilizzo.

4 Reti di Calcolatori LS4 Architettura Logica e Sistema di Nomi Necessità di trovare:  Uno schema architetturale, basato sul paradigma cliente- servitore;  Un protocollo di comunicazione che permetta di supportare e garantire il corretto flusso dei messaggi tra tutte le entità del sistema;  Un sistema di nomi dinamico, flessibile, portabile, scalabile e con costi accettabili, tenendo in considerazione tutte le possibili soluzioni: Dinamico Statico vs Dinamico; Distribuito. Centralizzato vs Distribuito.

5 Reti di Calcolatori LS5 Architettura - il Servitore  Il sistema dalla parte del servitore deve rispettare il principio della minima intrusione del controllo: Dovrà essere previsto un procedimento di istanziazione e rilascio dei monitor, a seconda delle richieste di monitoraggio ricevute sul monitor.  Introduzione di un meccanismo di replicazione a livello del monitor: Con 3 monitor si correggono errori singoli e si identificano quelli doppi.  Necessità di prevedere un’entità deputata al controllo dei risultati dei monitor, un gestore che ne coordini il funzionamento e ne controlli i risultati.  Esigenza di avere una entità che rimanga sempre attiva in attesa di richieste di broadcast da parte di clienti remoti, in modo da rendere possibile il sistema di nomi distribuito e dinamico.  Avere una sorta di stub che ci permetta di incapsulare le funzionalità di comunicazione con i clienti remoti.

6 Reti di Calcolatori LS6 Architettura - il Cliente  Dalla parte del cliente la struttura è affine, quasi duale a quella lato-server, con l’aggiunta dell’interfaccia utente per: facilitare gli utilizzatori; mascherare la complessità sottostante; fornire un elenco coi servizi disponibili; raccogliere le richieste dall’esterno; restituire i risultati ben formattati.  Un gestore per la coordinazione di quelle azioni legate al reperimento delle informazioni riguardanti il traffico di rete di un particolare nodo remoto.  Un gestore della QoS che ci permetta di negoziare determinati SLA, direttamente collegati alla frequenza con la quale si stimola il monitoraggio remoto e la decisione delle politiche atte a garantire questi livelli di servizio: Tecniche di real-time; Monitoraggio locale.  Un gestore con la responsabilità di farsi carico di tutte le domande di ottenimento della lista degli host attivi;  Il secondo end-point di comunicazione, un proxy, con compiti analoghi allo stub server-side.

7 Reti di Calcolatori LS7 Il protocollo di comunicazione  Protocollo a 6 fasi 1. Discovery 2. Reply 3. Start 4. Request 5. Result 6. Stop  Possibilità di calcolarsi time-out dinamicamente a partire dalle prime tre fasi in modo da rendersi conto di possibili problemi sul collegamento

8 Reti di Calcolatori LS8 Recuperare informazioni sul traffico di rete: Il protocollo SNMP  Il protocollo SNMP (Simple Network Management Protocol): Standard de facto per la comunità internet; Portabilità e nessun problema di compatibilità.  Possibilità di ricorrere, per ottenere i dati che ci interessano, a tool già pronti che sono disponibili in rete e che fanno uso del protocollo SNMP, in modo da semplificare e velocizzare la successiva fase di prototipazione, integrando il nostro codice con queste librerie.  Opportunità di ottenere un numero molto elevato, variegato ed eterogeneo di informazioni grazie alla struttura del MIB organizzato per tipi di traffico a seconda dei protocolli di trasmissione utilizzati.  Problemi tipici: Quali informazioni sono rilevanti per lo scopo del mio monitoraggio? Come organizzare i dati da far transitare sulla rete?  Necessità di personalizzazione, a seguito di uno studio sulle informazioni ottenibili dal protocollo, in modo da: Ottimizzare l’impiego di risorse; Ridurre l’overhead di comunicazione; Avere performance e QoS superiori.

9 Reti di Calcolatori LS9 La fase realizzativa (1/2)  Prototipo scritto in linguaggio Java: Supporto alle applicazioni distribuite (package java. rmi); Supporto per le applicazioni grafiche (packages java. awt e javax. swing); Familiarità dello sviluppatore  Meccanismo di discovery (prime 2 fasi del protocollo), realizzato implementando una sorta di “ping” su tutti gli indirizzi “interessanti”, servendosi di una comunicazione cliente – servitore senza connessione: Ogni nodo che dichiara attivo il servizio ha un servitore datagram in ascolto su una determinata porta; Il numero di questa porta è l’unica nozione che il cliente deve possedere per il corretto funzionamento del meccanismo; Si deve stabilire un time-out ed un giusto compromesso accuratezza/tempo di risposta.  Realizzazione delle ultime 4 fasi del protocollo di comunicazione mediante strumenti propri di Java ed in particolare utilizzando il meccanismo del RMI (Remote Method Invocation) e definendo una interfaccia remota che dichiari le funzionalità necessarie: Un comando di Start che provoca l’istanziazione di tre monitor SNMP e di un gestore per il loro controllo e coordinamento; Un comando di Request con cui il cliente interroga il servitore e che incarna anche la successiva fase di Result tramite il relativo valore di ritorno; Una richiesta di Stop a fronte della quale si rilasciano tutte le risorse.

10 Reti di Calcolatori LS10 La fase realizzativa (2/2)  Recupero delle informazioni di rete attraverso il protocollo SNMP e l’utilizzo delle librerie SnmpApi realizzate e sviluppate da AdventNet: Semplici da utilizzare e da integrare con il codice del prototipo; Basate sulla semplice scelta delle informazioni rilevanti tramite OID ed operazioni sul MIB. Astrazione del pacchetto informativo ottenuta tramite la classe ReportSNMP.  Il gestore della qualità del servizio realizzato come un demone che stimola periodicamente il controllo a seconda della frequenza stabilita: comunicazione realizzata con un sistema ad eventi.

11 Reti di Calcolatori LS11 Applicazione di prova e testing  Piccola applicazione grafica per la fase di testing e la prova del comportamento dinamico del sistema sviluppato, articolata su due finestre: La prima per settare i parametri del controllo da concretizzare:  Host da monitorare;  Livello di QoS;  Tipo di traffico (informazioni rilevanti). La seconda per visualizzare i risultati.

12 Reti di Calcolatori LS12 Conclusioni e sviluppi futuri  L’architettura che abbiamo descritto risponde ai requisiti propri delle del problema del controllo e del monitoraggio distribuito in generale e di quello sul traffico di rete in particolare.  E’ pensata per essere: Distribuita e per nulla centralizzata; Portabile; Resistente ai guasti; Poco intrusiva, per realizzare al meglio le politiche di controllo e non andare ad utilizzare inutilmente risorse.  La scelta di ricorrere al protocollo SNMP ha facilitato la realizzazione del prototipo, dal momento che risulta essere molto funzionale e la sua diffusione permette l’uso di tools già pronti per il reperimento locale su un nodo remoto delle informazioni riguardanti il traffico di rete.  Ci sono diverse possibilità nell’ottica di sviluppi seguenti sul prototipo: Si potrebbe realizzare un tool che facilitasse ed automatizzasse la fase iniziale di personalizzazione; Inoltre si potrebbero apportare miglioramenti incrementali al fine di incrementare le prestazioni del sistema, nell’ottica di:  Garanzia della QoS;  Resistenza ai guasti;  Aggiunta di funzionalità ulteriori.