JARSJavaActiveReplicationSupp

ort

Anno Accademico 2004-2005

Bellocchi Marco Maria

Obiettivi Realizzazione di un supporto per sistemi

distribuiti per l’alta disponibilità Architettura Modulare

Facilità d’espansione 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

RMIRMI RMIRMI

SocketSocket

Client Proxy

RMI

RMI

Socket

Socket

Richieste Callback

Coordination Protocol

FileFileMAILBOXMAILBOX

CHAT

QUEUE

Resources

•Mutua Esclusione Distribuita•Two Phase Commit Protocol•Protocollo di Recovery•Protocollo Gestione Gruppo•…

Services Coordinamento

Comunicazione Comunicazione

Risorse Entità gestite dai Server

Replicate su ciascun Server Ognuna ha un identificativo univoco (ID)

Permettono l’erogazione di servizi sollecitate da richieste di Client

Riflessività Definizione dell’interfaccia di operazioni

visibili al cliente che possono essere richieste

Invocazione dinamica di operazioni

Proxy Client

Discovery ServerManager

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 ServerDiscovery completamente dinamico nella rete locale dei Server attivi che erogano il servizioRouting Table e mantenimento di informazioni di carico dei Server per realizzare bilanciamento di caricoFailover 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 forIncoming

connectionof 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

DiscoveryListener

Discovery Sender

Connection Manager

Coordinator Bridge

Group Protocol Coordinator

TwoPhase Protocol Coordinator

Mutex Protocol Coordinator

Recovery Protocol Coordinator

……..

Configuration Manager

Network Administrator Client Proxy Comunication

Incoming Messages Incoming Messages 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

l’indirizzo 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 l’accesso, utilizzo e rilascio della risorsa

Semantica delle Richieste del Client

Esecuzione senza notifica Il Client specifica nella richiesta di accesso alla risorsa l’azione 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 l’unlock

Il Server esegue quanto richiesto e effettua l’unlock 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 l’unlock sulla

risorsa Negli ultimi due casi discussi il Server monitorizza il Client che

correntemente ha ottenuto l’accesso alla risorsa e può utilizzarla Permette di accorgersi di eventuali cadute del Client e di effettuare quindi

l’unlock 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

all’ingresso del gruppo

Coordinazione semplice

Queue_Resource Queue_Resource Queue_Resource

S1 S3S2

S1_Ask_Queue

S1_Ask_Queue S1_Ask_QueueS1_Ask_Queue

S3_Ok_Queue

S2_Ok_Queue

S2_Ok_Queue

S3_Ok_Queue

S1_Release_QueueLock della risorsa acquisito:

inserisce/estrae un messaggio

Update_Queue

Coordinazione con richieste concorrenti

Queue_Resource Queue_Resource Queue_Resource

S1 S3S2

S1_Ask_Queue

S2_Ask_Queue

S1_Ask_Queue S1_Ask_QueueS1_Ask_Queue

S2_Ask_Queue S2_Ask_QueueS2_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 l’ok a S2

S3_Ok_Queue S3_Ok_Queue

S3_Ok_Queue S3_Ok_Queue

S1_Ok_Queue

S1_Ok_QueueLock della risorsa

acquisito: inserisce/estrae un

messaggio

Update_Queue Update_QueueS2_Release_Queue S2_Release_Queue

S2_Ok_Queue

S2_Ok_Queue

Lock della risorsa acquisito: inserisce/estrae un messaggio,

Effettua l’update della coda eEffettua infine il rilascio

Gestione Dinamicità del Gruppo dei Servers

1-Enter_Group

2-Freeze&UpdateResources

3-Ok_To_Enter

4 -Enter_Group

6-Ok_To_Enter

7-Update_Resources

5-Freeze&UpdateResources

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

1-Leave_Group

2- Update_Routing_Table

2- Update_Routing_Table

Nodo Uscente All’uscita 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 l’update 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 l’aggiornamento 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 all’interno del sistema

QoS: Broker Broker associato ad ogni Risorsa per garantire

una determinata QoS nell’erogazione 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

L’applicazione 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 nell’accesso 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 nell’ambito della programmazione distribuita e nella realizzazione di Middleware