P2P - Monitor e Logger Globale

Transcript

1 P2P - Monitor e Logger Globale Documento di presentazione per la tesina di Sistemi Distribuiti Dario Mazza, Paolo Pino, Pierluigi Sottile

2 Indice 1 Consegna 2 2 Logging Locale 2 3 Monitoring Locale 2 4 Ordinamento dei Messaggi 3 5 Logger e Monitor Globale 4 6 Transazioni 4 7 Replicazione 5 8 Deploy e Configurazione dell Applicazione 7 1

3 1 Consegna L obiettivo della tesina è di realizzare un servizio di Logging e un servizio di Monitor Globale che riceverà i dati provenienti dai peer realizzati nel primo step. I messaggi all interno dei componenti globali devono essere ordinati prima di essere scritti in dei file XML. I messaggi inviati ai componenti globali devono essere generati da un sistema di logging e monitoring locale ai peer. Deve essere replicato il contenuto di una delle tre code del peer utilizzando un sistema transazionale. Tutte le comunicazioni devono essere implementate utilizzando i Web Service di Java Enterprise Edition e l Application Server Glassfish. 2 Logging Locale Il sistema di logging locale si basa sull utility log4j dell Apache Software Foundation. Questa utility fornisce metodi per la creazione di logger e l associazione di appender specifici al sistema di logging. Il logging locale è diviso in due parti: la prima è composta da un serie di logger mappati sulle classi che li utilizzano e serve per lo sviluppo ed il debugging dell applicazione. Questa prima parte produce due file contenenti gli stessi dati: middleware p2p.out, scritto in formato humanreadable, e middleware p2p.log, formattato in XML in base al DTD di log4j. La seconda parte del logging è composta da un filtro sui logger della prima parte e serve per catturare i dati da inviare al componente globale. Questa seconda parte produce un file, middleware local.log, formattato in XML. I log che vengono inviati al logger globale sono solo quelli di livello INFO e devono essere del tipo MiddlewareLogEvent. Estendendo il layout XML (classe XMLLayout contenuta nelle API log4j) è stata personalizzata la formattazione del file ed è stata inserita una chiamata al Web Service GlobalLogger per eseguire il push dell evento di log. La classe MiddlewareLogEvent contiene l identificativo univoco del componente (ossia del peer), il timestamp locale dell evento, una stringa contenente la descrizione dell evento e il Vector Clock necessario all ordinamento degli eventi all interno del componente globale. L identificativo del componente viene generato applicando la funzione di hash MD5 alla stringa Component:peer ip:peer port. Interfaccia XMLSerializable e JAXB Tutte le classi, come MiddlewareLogEvent, che devono essere serializzate in XML implementano l interfaccia XmlSerializable (che estende java.io.serializable) che prevede il metodo public String toxmlstring(). Quest ultimo metodo viene utilizzato dai layout per ottenere la rappresentazione XML dell oggetto. La rappresentazione XML viene ottenuta tramite l uso di JAXB (Java Architecture for XML Binding). Per definire la struttura dell oggetto complesso XML vengono utilizzate @XmlElement. Per eseguire il marshalling si utilizza l oggetto Marshaller di JAXB. Utilizzare JAXB per la serializzazione XML ha diversi vantaggi: in primo luogo semplifica lo sviluppo dei metodi di serializzazione ed inoltre si tratta di un elemento di Java EE ed è utilizzato da JAX-WS (Java API for XML Web Service) per generare il WSDL dei Web Service. 3 Monitoring Locale Il monitoring locale si appoggia al sistema log4j per la scrittura dello stato e del contenuto delle code su file XML. Il sistema di monitoring è composto da quattro logger: middleware.p2p.monitor.wfqueue sul quale viene scritto il contenuto della coda di Workflow middleware.p2p.monitor.tdqueue sul quale viene scritto il contenuto della coda di Task Descriptor middleware.p2p.monitor.wfqueue status sul quale viene scritto lo stato della coda di Workflow middleware.p2p.monitor.tdqueue status sul quale viene scritto lo stato della coda di Task Descriptor 2

4 Agli appender su file delle API di log4j (contenuti nella classe org.apache.log4j.fileappender) viene applicato un filtro MonitorFilter che permette di applicare il layout MiddlewareMonitorLayout ad un logger con un determinato nome. Il layout si occupa di formattare i file XML in maniera appropriata e di inviare l evento al Web Service GlobalMonitor per effettuare il push. I file generati dal monitoring locale sono: middleware wfqueue content.log, middleware wfqueue status.log, middleware tqueue content.log, middleware tqueue status.log che contengono, rispettivamente,rispettivamente, il contenuto e lo stato della coda di Workflow ed il contenuto e lo stato della coda di TaskDescriptor. Gli oggetti che sono scritti nei logger del sistema di monitoring sono del tipo MiddlewareMonitorEvent e contengono il tipo della coda da cui è generato l evento di monitor, l identificativo del componente, il Vector Clock necessario all ordinamento degli eventi nel monitor globale, il timestamp locale dell evento, il numero totale di elementi inseriti nella coda, la dimensione corrente della coda e la serializzazione XML del contenuto della coda. Quest ultimo campo non viene serializzato da JAXB grazie all Estrazione dello stato e concorrenza Nel primo step del Progetto la concorrenza sulle code nei peer era stata gestita tramite la classe java.util.concurrent.linkedblockingdequeue che garantisce l atomicità e la concorrenza nelle operazioni di enqueue e dequeue. La necessità di estrarre lo stato della coda all interno della sezione critica che modifica lo stato ha imposto il cambiamento del sistema di gestione della concorrenza. La concorrenza sulle code è gestita applicando il problema di Produttori e Consumatori e utilizzando le classi java.util.concurrent.locks.lock (utilizzati allo stesso modo dei pthread mutex) e java.util.concurrent.locks.condition (utilizzati come i pthread cond). I metodi enqueue e dequeue sono stati modificati per ricevere un parametro supplementare di tipo MiddlewareMonitorEvent che sarà valorizzato in sezione critica con i dati sullo stato. 4 Ordinamento dei Messaggi Prima di analizzare i componenti globali (Monitor, Logger e Replica Manager) verrà illustrato il sistema di ordinamento dei messaggi basati sui Vector Clock e su un meccanismo di Gap Detection. Il sistema verrà illustrato in forma generica in quanto è stato utilizzato in modo sostanzialmente identico in tutti i componenti globali. Gli attori del sistema sono due EJB (Enterprise Java Beans): Service : EJB Stateless su cui viene mappato il Web Service QueueManager: EJB Statefull Singleton che viene utilizzato per gestire l ordinamento Il Web Service espone come WebMethod un metodo push per inserire nel sistema di ordinamento un nuovo elemento e un metodo resetclock che server per resettare il clock relativo ad un determinato componente. Questi metodi sono soltanto un punto di accesso per i metodi omonimi esposti dall interfaccia locale del QueueManager. Il QueueManager mantiene un Vector Clock utilizzato per ordinare i messaggi e una coda in cui vengono inseriti gli elementi che non sono consegnabili immediatamente. Il metodo push controlla se il messaggio è delivarable (consegnabile) e in tal caso chiama immediatamente il metodo privato deliver e controlla nella coda di messaggi se ci sono messaggio sbloccati dalla consegna del messaggio corrente e li consegna. Se il messaggio non è consegnabile immediatamente (immediate delivery impossibile) viene inserito nella coda di attesa. Un messaggio viene considerato delivarable se soddisfa una delle seguenti condizioni: 1. V C Q < V C m NOT Gap P rox 2. V C Q = V C m P rox 3

5 dove V C Q e V C m sono i vector clock rispettivamente del QueueManager e del messaggio, Gap è vero se tra V C Q e V C m vi sono dei gap e P rox è vero se V C Q e V C m sono marcati come prossimi. Il metodo deliver esegue le operazioni specifiche del componente legate alla consegna ma prima aggiorna il vector clock del QueueManager in modo che V C Q [k] = max(v C Q [k], V C m [k]), k NS, dove k è l identificavo di un peer e NS è l insieme dei peer conosciuti dal componente. Confronti tra Vector Clock L ordinamento dei messaggi su Vector Clock si basa su tre metodi di confronto tra i Vector Clock: compareto: implementa il confronto diretto tra due Vector Clock detectgap: controlla se vi sono gap tra i due Vector Clock detectproximity: controlla se due Vector Clock sono prossimi Il confronto diretto tra i Vector Clock si basa sulla seguente definizione: V C 1 < V C 2 V C 1 [k] V C 2 [k]], k k : V C 1 [k ] < V C 2 [k ] Il gap detection conta le distanze tra i componenti del Vector Clock e ritorna Vero se le distanze positive sono presenti in più di una componente. Due Vector Clock sono considerati prossimi se vi è una distanza positiva solo su una componente e questa distanza è pari ad uno. 5 Logger e Monitor Globale Il Logger Globale sfrutta il meccanismo di ordinamento dei messaggi utilizzando il bean GlobalLogger per il Web Service e il bean EventQueueManager per gestire la coda. Il metodo deliver stampa gli eventi consegnati su un file middleware global log.log formattato in XML e contenuto nella seguente directory $GLASSFISH HOME/domains/$DOMAIN NAME/logs. Il Monitor Globale sfrutta il meccanismo di ordinamento dei messaggi utilizzando il bean GlobalMonitor per il Web Service e il bean MonitorQueueManager per gestire la coda. Per il monitor il paradigma per l ordinamento viene leggermente modificato inserendo, all interno del MonitorQueueManager, delle code separate per ogni tipo di coda del peer. Il metodo deliver stampa gli eventi consegnati su un file, differente per ogni coda, middleware $QUEUE TYPE status.log formattato in XML e contenuto nella seguente directory $GLASSFISH HOME/domains/$DOMAIN NAME/logs. 6 Transazioni Nel sistema delle transazioni si identificano tre attori: il Client, Transaction Coordinator e Transaction Partecipant. Il flusso di esecuzione della transazione inizia con il client che inizia la transazione e riceve un identificativo univoco della transazione dal Coordinator; il client esegue tutte le operazioni sui partecipant allegando alle richieste l identificativo della transazione (i partecipant eseguono il join alla transazione contattando il coordinator). Completate tutte le operazioni, il client richiede la chiusura della transazione ed il coordinator inizia l algoritmo 2PC (Two Phase Commit) e dopo le due fasi ritorna il risultato al client: tale risultato può essere Commit o Abort. Nell implementazione presentata il Web Service che interpreta il ruolo del Transaction Coordinator è mappato sul bean TransactionCoordinator che al suo interno contiene i riferimenti alle interfacce locali degli EJB TransactionRepository (Singleton Stateful) e TransactionLogger (Stateless). Ogni peer ha il suo Transaction Coordinator locale che chiama quando deve utilizzare il sistema di transazioni. Il TransactionLogger permette di scrivere su un log lo stato di avanzamento di una transazione; il log viene scritto su file con il nome della transazione all interno della directory logs/transaction/$ruolo (dove $RUOLO indica se si tratta di un coordinator o di un partecipant) contenuta nella root del domain Glassfish. Il file di log viene utilizzato nel caso di crash del coordinator per riprendere le operazioni che stava eseguendo. 4

6 TransactionRepository L Enterprise Java Bean TransactionRepository è un Singleton che contiene una mappa che associa ad ogni Transaction Id un oggetto Transaction. Inoltre il TransactionRepository legge i timeout e l identificativo del coordinatore dal file di configurazione e permette di generare un nuovo Transaction Id assemblato come $COORDID $PROGNUM (dove $PROGNUM è un numero progressivo). Il TransactionRepository è segnato con l quindi viene caricato all avvio del Application Server Glassfish e nel costruttore viene letto il log file di tutte le transazioni e se si trovano in uno stato di Prepared o di Global Abort manda il segnale di Abort a tutti i partecipant mentre se si trovano in uno stati di Global Commit manda il segnale di Commit. 2PC Nel metodo closetransaction del coordinator viene implementato il protocollo 2PC. Il coordinator ottiene dal repository tutti i partecipant che hanno fatto join alla transazione e chiama in maniera asincrona il metodo cancommit su ognuno di loro. Una volta effettuate le chiamate, inizia la fase di raccolta dei voti: per ogni partecipant si attende un tempo pari a voting single timeout. Prima di controllare per la richiesta successiva si controlla che il tempo passato dall inizio della fase di raccolta dei voti sia minore di voting total timeout-voting delta. In caso siano violati i timeout si procede con il global abort. Se tutti i voti sono concordi sul READY si procede chiamando in maniera asincrona il docommit su tutti i partecipant altrimenti si chiama il doabort. Effettuate tutte le chiamate asincrone si attende l arrivo di tutti gli ack: si attende un tempo pari a completition single timeout e se scade il timemout si procede alla ritrasmissione ( il massimo numero di ritrasmissioni è indicato dal valore di completition max retry. Tutti i valori dei timeout sono letti dal TransactionRepository all avvio e vengono ottenuti attraverso il metodo getalltimeout(). 7 Replicazione È stato deciso di replicare lo stato della coda di TaskDescriptor utilizzando una modalità attiva di replicazione. Ogni peer ha il suo Replica Manager locale che può essere interrogato come Web Service per ottenere i dati sulle repliche possedute dal peer. La logica per ottenere e pubblicare delle repliche è contenuta all interno dell oggetto ReplicaFrontend istanziato nella classe CORE. All avvio del Worker si chiede al Frontend di trovare una replica della coda (getreplica) e se ne trova una coda non vuota si caricheranno i TaskDescriptor nella coda sincronizzata. Ogni volta che viene modificato lo stato della coda viene chiesto al Frontend di salvare in remoto la coda (storereplica). Replica Manager Il Replica Manager (RM) è implementato da un Web Service mappato su l EJB Stateless ReplicaManager ed utilizza il metodo di ordinamento dei messaggi illustrato in precedenza appoggiandosi al queue manager ReplicaQueueManager (EJB Stateful Singleton). Per implementare il 2PC il Replica Manager deve conservare traccia dello stato della transazione attraverso le varie chiamate (operazione-cancommit-docommit/doabort). A tale scopo si appoggia ad un EJB Singleton ReplicaTransactionCache che contiene una mappa che associa ad un transaction id un oggetto di tipo ReplicaCacheEntry. Quest ultimo oggetto contiene le seguenti informazioni: action : tipo enum che identifica se si tratta di un get o di una store component: identificativo del componente a cui è associata la replica content: stringa contenente la replica se si tratta di una store altrimenti la rappresentazione su stringa del boolean di ritorno del metodo getreplica tempfile: oggetto File contenente il riferimento al file temporaneo generato nel processo di store della replica, rimane sempre null durante il get. La cache è condivisa con l EJB che implementa la coda per l ordinamento. Quest ultima viene riempita attraverso i metodi del web service ReplicaManager con degli oggetti di tipo ReplicaRequest. I dati contenuti nell oggetto ReplicaRequest sono i seguenti: 5

7 vclock: vector clock della richiesta e necessario all ordinamento componentid : identificativo del componente a cui è associata la richiesta coordwsdl : URL del WSDL del transaction coordinator a cui fare il join replica : replica di cui fare la store, in caso di get vale null transid: identificativo della transazione all interno del quale è stata effettuata la richiesta responseaddr: indirizzo sul quale inviare la risposta della richiesta get: vale true se si tratta di una get, false se si tratta di una store. push: vale true se si tratta di una store, false se si tratta di una get. Il metodo deliver del Queue Manager decide in base all operazione indicata nell oggetto ReplicaRequest se eseguire il metodo privato storereplica del Queue Manager oppure il metodo privato getreplica del Queue Manager; raccolto il risultato dell invocazione di questi metodi li invia tramite socket all indirizzo indicato nell oggetto ReplicaRequest. Il metodo getreplica del Queue Manager effettua il join al coordinatore di transazione indicato e poi legge il file relativo alla replica ossia il file con nome $COMP ID.rpl nella cartella logs/replicastore all interno della root del domain dell Application Server Glassfish. Una volta letto il file il contenuto viene memorizzato all interno della cache sotto forma di ReplicaCacheEntry. Il metodo storereplica del Queue Manager effettua il join al coordinatore di transazione indicato e inserisce i dati sulla replica da memorizzare in un oggetto ReplicaCacheEntry che viene inserito nella cache. L EJB ReplicaManager è responsabile del protocollo 2PC dal lato del partecipant. Il metodo cancommit(), chiamato dal coordinator per ottenere il voto del partecipant, agisce in modo diverso a seconda che si tratti di una store o di una get. Se si tratta di una store viene scritto il contenuto del campo content della ReplicaCacheEntry all interno di un file temporaneo creato nella cartella temp all interno della replicastore (directory all interno del quale vengono registrate le repliche); il file temporaneo viene memorizzato nella entry all interno della cache. Se si tratta di una get non viene eseguita nessuna azione particolare (non ci sono dati da rendere permanenti). Il metodo docommit rende permanenti le modifiche della transazione. Nel caso di una store il file temporaneo contenuto nella entry della cache viene spostato nella directory replicastore e rinominato con l identificativo del componente a cui è associata la replica e gli viene assegnata l estensione.rpl; finite queste operazioni viene cancellata la entry dalla cache (le operazioni non sono più annullabili). Se si tratta di una get si cancella solamente la entry nella cache (non ci sono dati da rendere permanenti). Il metodo doabort cancella le entry nella cache e nel caso di store viene cancellato anche il file temporaneo generato dal metodo cancommit. Ricezione dei Response Il ReplicaFrontend permette all applicazione POJO di usufruire del sistema di replicazione mascherando la complessità del sistema distribuito. Le risposte provenienti dai Replica Manager arrivano al frontend attraverso delle socket aperte su un indirizzo passato al Web Service come parametro. Un thread implementato dalla classe ReplicaResponseHandler si occupa di creare la ServerSocket cercando una porta libera a partire da quella indicata nel file di configurazione. Questo thread rimane in ascolto in attesa delle risposte dei Replica Manager e inserisce tali risposte in una lista passatagli tramite costruttore; una volta raccolte tutte le risposte il thread termina. Il metodo getreplica inizia la transazione, avvia il thread per raccogliere le risposte e inizia ad eseguire le richieste di getreplica a tutti i Replica Manager conosciuti dal servizio di discovery (in questa implementazione il vicinato viene caricato dal file discovery peers.xml). Fatte tutte le richieste, il metodo fa join sul thread di ricezione delle risposte: quando tutte le risposte sono state raccolte, si chiama il metodo closetransaction del coordinator e si attende la response della transazione. 6

8 Il metodo storereplica è chiamato molte volte e durante l esecuzione dell applicazione POJO al contrario del getreplica che viene chiamato una volta sola in fase di caricamento dell applicazione. Per evitare che le chiamate alla storereplica peggiorino le performance dell applicativo, il frontend lancia un thread ReplicaStorerThread che esegue le operazioni di store della replica senza bloccare l esecuzione. Il thread avvia la transazione, avvia il thread per collezionare le risposte e invia le richieste di store a tutti gli RM conosciuti dal servizio di discovery. Finite le chiamate, effettua il join sul thread per collezionare le risposte e, quando riprende, effettua la closetransaction attendendo l esito della transazione. 8 Deploy e Configurazione dell Applicazione Il lavoro svolto è stato diviso in tre applicazioni Enterprise: MiddlewareGlobalLoggerApp: EJB per il Logger Globale contenente gli MiddlewareGlobalMonitorApp: contenente gli EJB per il Monitor Globale MiddlewareReplicationApp: contenente gli EJB per i Replica Manager e i Transaction Coordinator. L applicazione del primo step è contenuta nel progetto ProgettoMiddleware. Nella cartella dist/ si trovano i file EAR (Enterprise Archive) per le applicazioni e saranno inseriti, tramite l Administration Console di Glassfish, all interno dei domini appropriati. Oltre ai file EAR, vi è il file JAR dell applicazione POJO. I file di configurazione per l applicazione POJO sono : middleware config.xml: contenente i dati per configurare l applicazione. discovery peer.xml: contenente i dati sui peer conosciuti dal servizio di discovery. peer config.xml: contenente i dati per configurare il peer. I file di configurazione per l applicazione per la Replicazione sono: coordinator config.xml: contenente le configurazioni per il coordinatore delle transazioni replica manager config.xml: contenente i dati per configurare il Replica Manager. I file di configurazione dell applicazione POJO devono trovarsi nel path di esecuzione mentre i file di configurazione delle applicazioni Enterprise si devono trovare nella cartella config/ situata all interno della directory domains/domain name dell Application Server Glassfish. Segue una veloce descrizione del contenuto dei file XML di configurazione. middleware config.xml Il root tag <middleware> deve contenere i seguenti Child Node: <architecture>: indica il tipo di architettura del sistema, e.g. P2P <transport>: indica il protocollo da utilizzare per le comunicazioni, e.g. TCP <file transfer policy>: indica la politica di trasferimento dei File, e.g. PUSH <global logger wsdl>: contiene l URL dove trovare il file WSDL di descrizione del servizio di Logging globale, e.g. GlobalLogger?wsdl <global monitor wsdl>: contiene l URL dove trovare il file WSDL di descrizione del servizio di Monitor globale, e.g. GlobalMonitor?wsdl <local coordinator wsdl>: contiene l URL dove trovare il file WSDL di descrizione del servizio Coordinatore locale responsabile per le transazioni, e.g. TransactionCoordinatorService/ TransactionCoordinator?wsdl <replica response port>: indica da quale porta iniziare la scansione atta a trovare una porta libera per ricevere i response dal servizio di replica, e.g

9 discovery peer.xml Il root tag <discovery> deve contenere un numero N di elementi <peer> ognuno dei quali deve avere i seguenti Child Node: <ip>: indica l IP del peer conosciuto dal Discovery, e.g <port>: indica la porta sul cui contattare il peer, e.g <rm wsdl>: contiene l URL dove trovare il file WSDL di descrizione del Replica Manager del peer, e.g. ReplicaManager?wsdl peer config.xml Il root tag <peer config> deve contenere i seguenti Child Node : <ip> : Indirizzo IP del peer corrente, e.g <port>: Porta su cui contattare il peer corrente, e.g coordinator config.xml Il root tag <coordinator> deve avere l attributo id contenente un valore univoco che identifichi il coordinator (e.g. hash dell IP oppure random hash). Il tag <coordinator> deve contenere un elemento <timeouts> composto da elementi <timeout> con un attributo name rappresentante il nome del timeout e come contenuto il valore del timeout. I timeout da dichiarare sono i seguenti: voting single: timeout sulla singola richiesta di voto, e.g voting total: durata del timeout globale della fase di voto della transazione, e.b voting delta: delta associato all inizio di una nuova richiesta di voto, e.g completition single: timeout sulla singola richiesta di completamento, e.g completition max retry: numero massimo di ritrasmissioni in caso di timeout nella fase di completamento, e.g. 3 replica manager config.xml Il root tag <replica manager> deve contenere un singolo elemento, <wsdl url>, contenente l URL del Replica Manager da configurare. 8