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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.