High-Available Service Manager Diego Costantini - 0000170094 Università degli studi di Bologna Corso di Laurea Specialistica.

Presentazione sul tema: "High-Available Service Manager Diego Costantini - 0000170094 Università degli studi di Bologna Corso di Laurea Specialistica."— Transcript della presentazione:

1 High-Available Service Manager Diego Costantini - 0000170094 diego.costantini@gmail.com Università degli studi di Bologna Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS

2 Introduzione Obiettivi Obiettivi Architettura Architettura Contesti di utilizzo Contesti di utilizzo Protocolli Protocolli Considerazioni e sviluppi futuri Considerazioni e sviluppi futuri

3 Obiettivi Realizzare un servizio per la ricerca e lutilizzo di altri servizi in un ambiente in evoluzione, che garantisca almeno: Alta disponibilità Alta disponibilità Persistenza Persistenza e che sia soltanto unestensione per lambiente esistente, il quale continua a funzionare come prima. Si considerano ambienti di medio/grandi dimensioni

4 Architettura La figura del Manager è opzionale, senza di esso tutto funzionerebbe come prima Ai servizi che vogliono usufruirne è richiesto solo una piccola parte di codice da aggiungere al server

5 Architettura(2) I componenti fondamentali di questo sistema sono: Il client in grado di comunicare con il server su cui risiede il servant ed usufruire del servizio offerto Il client in grado di comunicare con il server su cui risiede il servant ed usufruire del servizio offerto Il server su cui risiede il servant Il server su cui risiede il servant Il servant che eroga il servizio Il servant che eroga il servizio

6 Contesti di utilizzo In generale il comportamento dellutente sarà: 1. Richiesta della lista dei servizi e individuazione del servizio desiderato 2. Esecuzione del servizio richiesto grazie alle informazioni ottenute al passo precedente

7 Contesti di utilizzo(2) Ambienti di dimensioni ridotte Ambienti di dimensioni ridotte sufficiente una coppia master/slave sufficiente una coppia master/slave Pochi servizi e poche interazioni Pochi servizi e poche interazioni Notifica time-driven (no overhead, copie tiepide, recupero da ultimo checkpoint) Notifica time-driven (no overhead, copie tiepide, recupero da ultimo checkpoint)

8 Contesti di utilizzo (3) Ambienti di grandi dimensioni (Internet) Ambienti di grandi dimensioni (Internet) Replicazione Replicazione Master raggruppati in zone Master raggruppati in zone Diversi slave per ogni master di zona Diversi slave per ogni master di zona Molti servizi e molte interazioni Molti servizi e molte interazioni Notifica event-driven (Notification service, copie calde) Notifica event-driven (Notification service, copie calde)

9 Contesti di utilizzo(4)

10 Protocolli Per ottenere persistenza e alta disponibilità, vanno studiate adeguate soluzioni e protocolli Time-driven: ad intervalli di tempo gli slave fanno un update del registro dal master, in caso di mancata risposta si eleggono master loro stessi; i servizi comunque mandano un heartbeat regolare al master per comunicare che sono online (soft state) Time-driven: ad intervalli di tempo gli slave fanno un update del registro dal master, in caso di mancata risposta si eleggono master loro stessi; i servizi comunque mandano un heartbeat regolare al master per comunicare che sono online (soft state) Event-driven: il master notifica ogni cambiamento di stato con un modello push publish/subscribe (Notification service) Event-driven: il master notifica ogni cambiamento di stato con un modello push publish/subscribe (Notification service) Bisogna scegliere un trade-off tra 2 diversi tipi di overhead Update regolari anche se non ci sono cambiamenti di stato Update regolari anche se non ci sono cambiamenti di stato Update solo in caso di cambiamento di stato Update solo in caso di cambiamento di stato

11 Protocolli(2) Fault tolerance 1 master – 1 slave: tollera un solo guasto 1 master – 1 slave: tollera un solo guasto M master – N slave: tollera guasti multipli M master – N slave: tollera guasti multipli Fault transparency garantita tranne per il tempo che intercorre tra la caduta del master e la sostituzione con uno slave (dipende quindi dalla frequenza dei ping)

12 Sviluppi futuri Più server che offrono lo stesso servizio (possibile load balancing se comunicano il carico in piggyback) Più server che offrono lo stesso servizio (possibile load balancing se comunicano il carico in piggyback) Classificazione più articolata dei servizi, utilizzo di Trading Service e ricerca con parole chiave Classificazione più articolata dei servizi, utilizzo di Trading Service e ricerca con parole chiave Una piattaforma dinamica aperta ad ogni nuovo servizio disponibile (automazioni lato client, scalabile, flessibile) Una piattaforma dinamica aperta ad ogni nuovo servizio disponibile (automazioni lato client, scalabile, flessibile)