JARS JavaActiveReplicationSupport Anno Accademico Bellocchi Marco Maria

Obiettivi Realizzazione di un supporto per sistemi distribuiti per lalta disponibilità Architettura Modulare Facilità despansione del supporto e semplicità di impiego Concetto di Risorsa Entità che permette di erogare servizi Replicazione Attiva Coordinazione tra Copie Attive Monitoring dei nodi HeartBeat

Obiettivi Bilanciamento di carico Fault Tollerance Protocolli e Meccanismi Protocollo decentralizzato di Mutua Esclusione Two Phase Commit Protocol Vector Clock e relazione di Lamport QoS Gestione della QoS Monitoring per controllo della QoS erogata

Architettura Generale RMI Socket Client Proxy RM I Sock et Richieste Callback Coordination Protocol File MAILBO X CHAT QUEUE Resources Mutua Esclusione Distribuita Two Phase Commit Protocol Protocollo di Recovery Protocollo Gestione Gruppo … Services Coordinamento Comunicazione

Risorse Entità gestite dai Server Replicate su ciascun Server Ognuna ha un identificativo univoco (ID) Permettono lerogazione di servizi sollecitate da richieste di Client Riflessività Definizione dellinterfaccia di operazioni visibili al cliente che possono essere richieste Invocazione dinamica di operazioni

Proxy Client Discovery Server Manager Servers Routing Table Communication with Client Application Comunication with Server Entity Failover Manager Applicazione locale a quella Client Trasparenza dalla locazione e di comunicazione tra Client e Server Applicazione Client svincolata dalla diretta conoscenza del gruppo di Server e del Server a cui è connesso Gestione della comunicazione tra Client e Server Discovery completamente dinamico nella rete locale dei Server attivi che erogano il servizio Routing Table e mantenimento di informazioni di carico dei Server per realizzare bilanciamento di carico Failover in caso di guasto Monitoraggio del Server a cui il Client è connesso per maggiore reattività in caso di guasto Comunicazione tramite RMI Richieste dal Cliente verso il Server Callback dal Server

Server Messages to other Server Client Manager GUI Listener for Incoming connection of a Server Node Client Request Manager HeartBeat Manager Receiver of incoming messages From another Server Receiver of incoming messages From another Server Receiver of incoming messages From another Server Discovery Listener Discovery Sender Connection Manager Coordinator Bridge Group Protocol Coordinator TwoPhase Protocol Coordinator Mutex Protocol Coordinator Recovery Protocol Coordinator …….. Configuration Manager Network AdministratorClient Proxy Comunication Incoming Messages

Server Comunicazione con Proxy Client tramite RMI Discovery completamente dinamico per individuare un altro elemento attivo nella rete locale e realizzare il gruppo di erogazione dei servizi Anche connessione esplicita verso un certo server di cui si conosce lindirizzo HeartBeat per rilevazione di possibili guasti dei nodi Possibilità di regolare runtime la frequenza del controllo per adattare il monitoraggio alla qualità o a una particolare esigenza Possibilità di richiedere al Server di non monitorare affatto Recovey in caso di guasto e controllo della consistenza delle risorse sui nodi Verifica di eventuali inconsistenze e correzioni basate su algoritmo di voting Possiede e gestisce le Risorse Riceve le richieste via Client Proxy per erogare un servizio Callback verso il Client Proxy se necessario Replicazione Attiva Risorse replicate su tutti i nodi Coordinazione con le altre copie per mantenere la consistenza delle risorse sui servers a fronte di richieste del client che ne modificano lo stato Approssimazione della perfetta sincronia Utilizzo del protocollo di mutua esclusione distribuito per laccesso, utilizzo e rilascio della risorsa

Semantica delle Richieste del Client Esecuzione senza notifica Il Client specifica nella richiesta di accesso alla risorsa lazione che deve essere effettuata su di essa, e non vuole essere notificato quando questo accade Fire and Forget Notifica-Esecuzione con rilascio implicito Il Client specifica solo la volontà di acquisire il lock della risorsa Il Server notifica il cliente quando ha acquisito il lock Callback Il Client realizza nel metodo-callback specificato le operazioni sulla risorsa inviando al server le azioni da eseguire su di essa e non effettua esplicitamente lunlock Il Server esegue quanto richiesto e effettua lunlock quando tutte le azioni sulla risorsa sono concluse Notifica-Esecuzione-Rilascio esplicito Semantica simile alla precedente Unlock deve essere effettuato esplicitamente dal cliente Il Server eventualmente può forzare il cliente a effettuare lunlock sulla risorsa Negli ultimi due casi discussi il Server monitorizza il Client che correntemente ha ottenuto laccesso alla risorsa e può utilizzarla Permette di accorgersi di eventuali cadute del Client e di effettuare quindi lunlock della risorsa

Discovery Broadcast su rete locale mediante messaggi UDP Molteplici applicazioni del meccanismo: Individuazione di Server attivi Proxy Client to Server per connettere applicazione Client a un Server Server to Server per creare gruppo di lavoro Informazioni riguardanti il carico di ciascun Server attivo sulla rete locale Informazioni utilizzate per bilanciare il carico del sistema Ogni Server stesso numero di Proxy Client connessi Utilizzato anche per monitoraggio della QoS erogata Permette di individuare i Server in una rete a conoscenza zero

Coordinazione Copie Attive Il Client tramite proxy invia la richiesta per effettuare operazioni su una risorsa Il Server utilizza per poter acquisire il diritto di utilizzare la risorsa il protocollo di mutua esclusione distribuito Ricart & Agrawala Mutua esclusione per Ordinamento Atomico di operazioni su una stessa risorsa Per ogni Risorsa Una coda contenenti messaggi di richieste di accesso Logical Clock Ogni Server ha una priorità acquisita dinamicamente allingresso del gruppo

Coordinazione semplice Queue_Resource S1 S3 S2 S1_Ask_Queue S3_Ok_Queue S2_Ok_Queue S3_Ok_Queue S1_Release_Queue Lock della risorsa acquisito: inserisce/estrae un messaggio Update_Queue

Coordinazione con richieste concorrenti Queue_Resource S1 S3 S2 S1_Ask_Queue S2_Ask_Queue S1_Ask_Queue S2_Ask_Queue Ipotiziamo che S1 e S2 hanno rispettivamente lo stesso timestamp nel messaggio di richiesta che si sono inviati a vicenda S2 ha priorità maggiore di S1, quindi non effettua il reply immediato S1 si accorge di essere meno prioritario di S2 e pur avendo stesso timestamp, deve necessariamente dare lok a S2 S3_Ok_Queue S1_Ok_Queue Lock della risorsa acquisito: inserisce/estrae un messaggio Update_Queue S2_Release_Queue S2_Ok_Queue Lock della risorsa acquisito: inserisce/estrae un messaggio, Effettua lupdate della coda e Effettua infine il rilascio

Gestione Dinamicità del Gruppo dei Servers 1-Enter_Group 2-Freeze&Update Resources 3-Ok_To_Enter 4 -Enter_Group 6-Ok_To_Enter 7-Update_Resources 5-Freeze&Update Resources Nodo Entrante 8-Unfreeze_Resource Necessità di effettuare un momentaneo freeze del servizio affinchè il Server entrante possa copiare le risorse in uno stato consistente con il gruppo I Servers congelati bufferizzano le richieste dei Client che non vengono perse ma servite in ritardo Altre possibilità più efficienti… Una volta effettuata la copia delle risorse, il server entrante invia il messaggio di scongelamento Il gruppo incomincia ad erogare i servizi a partire dalle richieste che sono state bufferizzate Il Server entrante ottiene dinamicamente la priorità al momento del join con il gruppo

Gestione Dinamicità del Gruppo dei Servers 1-Leave_Group 2- Update_Routing_Table Nodo Uscente Alluscita del nodo, ciascun Server deve aggiornare la propria Routing Table Ogni Server deve eliminare i messaggi di Ask_Lock_IdResource e Ok_Lock_IdResource pendenti appartenenti al nodo uscito In questo modo si può continuare ad erogare il servizio non appena tutti si sono aggiornati alla nuova situazione

HeartBeat I Server si controllano a vivenda mediante messaggi di HeartBeat Se ci si accorge o si presume che un nodo sia caduto Eliminazione dei messaggi di Ask_Lock_IdResource e Ok_Lock_IdResource pendenti appartenenti al presunto nodo caduto Possibilità di inconsistenza sulle risorse se il server caduto ha modificato la risorsa e non ha eseguito lupdate su tutti i nodi Necessità di un protocollo che permetta di controllare ed eventualmente rendere consistenti le risorse replicate sui vari nodi Il Server effettua il freeze delle risorse e bufferizza le richieste dei Client Il Server notifica agli altri elementi di aver terminato il freeze e si mette in attesa di ricevere da tutti lo stesso messaggio Ricevuti tutti i messaggi di freeze, il sistema si trova in uno stato di congelamento globale Il Server invia a tutti lo stato delle proprie risorse locali, aspettando di rivevere altrettanto da tutti i Server del gruppo Una volta acquisita la conoscenza globale, si impiega un algoritmo di voting Si modifica eventualmente lo stato delle risorse in accordo a quello concordato dalla maggioranza dei Server Il Server invia il messaggio che indica la fine del recovery e si mette in attesa della ricezione dello stesso messaggio da parte di tutti gli altri Si possono infine scongelare le risorse e riattivare i servizi servendo le richieste dei Client Recovery del Gruppo

Servizi e meccanismi aggiuntivi Realizzazione del protocollo Two Phase Commit Proprietà Tutto o Niente Utilizzato per inserire nel sistema nuove risorse dinamicamente Per un possibile coordinamento tra le copie Implementazione dei Vector Clock di Lamport API per laggiornamento e la gestione dinamica dei vector clock. Non sono ancora state implementate politiche di base da utilizzare per relizzare uno specifico ordinamento di determinati eventi allinterno del sistema

QoS: Broker Broker associato ad ogni Risorsa per garantire una determinata QoS nellerogazione dei servizi che essa offre Richieste del Client inserite in una coda prima di essere processate Broker realizza scheduling delle richieste di utilizzo delle risorse da parte dei Clienti manipolando la coda In base alla priorità del Cliente Prima quelli che pagano di più In base al tipo di richiesta eventualmente specificata dal Client Prima le richieste più brevi che occupano meno la risorsa in termini di tempo Politiche Semplici e poco impegnative nel rispetto del principio di minima intrusione!!! Client Proxy Richiesta Server Resource_A QoS Resource_A Resource_B QoS Resource_B Ordinamento delle richieste in una coda Politiche differenziate …

QoS: Monitoring Applicazione per monitoring della QoS erogata dal gruppo di Server Richieste rivolte ai Server per raccogliere informazioni per monitorare il Sistema Numero di Clienti connessi a ciascun Server Numero di Server a cui ciascuno è connesso Individuazione di partizionamento di rete Numero di operazioni eseguite in totale sulle risorse da ciascun server Utilizzo del discovery su rete locale per individuare i Server attivi Si monitorizza solo la rete locale

Implementazione concreta Risorse messe a disposizione dei Clienti Queue Counter File Chat Sperimentate le differenti semantiche di richieste del Client Lapplicazione Client comunica con il ProxyClient mediante diretta invocazione di metodi

Limiti del Supporto Canali di comunicazione devono essere affidabili Non possono essere persi messaggi, ma solo ritardati Connessioni tra Server punto a punto Grafo di connessione completo Forte over-head nellaccesso alle Risorse 2*(N-1) messaggi scambiati per ogni accesso Protocollo di recovery complesso Numero di messaggi scambiati molto elevato Scalabilità del sistema Era nota in partenza Replicazione Attiva!

Sviluppi Futuri Persistenza fisica dello stato delle risorse per salvataggio su file system ed eventuale ripristino Naming e Trading Service Ricerca dei servizi Notification Service Notifica per eventi a cui il Cliente ha espresso interesse Publish/Subscribe Servizio di Login per i Client Possibilità di gestire QoS in base alla priorità del Client Comunicazione Client-Proxy veicolata tramite protocolli standard SOAP … Possibilità di utilizzare risorse non replicate ma semplicemente partizionate su nodi differenti Il Supporto in realtà permette già una gestione simile… Architettura utilizzabile anche per alte prestazioni Tramite semplice espansione aggiungendo moduli opportini

Conclusioni Supporto facile da utilizzare e espandibile Utilizzabile per realizzare una infinità di applicazioni MOM facilmente implementabile FSDistribuiti Mailbox ad alta disponibilità … Approfondimento di molti aspetti affrontati nellambito della programmazione distribuita e nella realizzazione di Middleware