Studio di una soluzione distribuita per la gestione di un centro sondaggi.

Presentazione sul tema: "Studio di una soluzione distribuita per la gestione di un centro sondaggi."— Transcript della presentazione:

1 Studio di una soluzione distribuita per la gestione di un centro sondaggi

2 Scenario:  In un centro sondaggi sono presenti diversi operatori che tramite una postazione PC compilano successivamente diverse interviste che vengono svolte telefonicamente.  Ogni intervista è relativa ad un questionario (lista di domande) e ad una persona da intervistare  Si vuole tutelare l’integrità delle risposte raccolte dagli operatori. Obiettivi :  Analizzare le problematiche nella gestione distribuita di un centro sondaggi e realizzare un prototipo per verificare la bontà del modello ottenuto.  Si vuole garantire:  tolleranza ai guasti: identificazione e recovery degli errori  affidabilità: integrità dei dati raccolti tramite replicazione  disponibilità: copie attive  scalabilità: adatta a deploy di diverse dimensioni.

3

4  Operazioni critiche:  Richiesta intervista: a un client non deve essere assegnata un’intervista già in corso in un altro client  Salvataggio risposte: occorre che il client abbia la conferma che l’operazione è andata a buon fine, in tempi ragionevoli:  Operazioni sincrone  Scalabilità: write predominanti  Altre operazioni:  su Server Interviste: autenticazione, chiusura intervista  su Server Questionari: ottieni questionario  Client Supervisore:  inserimento interviste da effettuare, stato di completamento, risultati aggregati risposte

5  Server Interviste  Utilizzo di Lease per determinare malfunzionamenti lato client  Autenticazione dei client  Operazione critica: assegnamento intervista  Interviste sospese: riassegnare con stato avanzamento  Scritture dominanti: save, assegnamento  Chiusura interviste: su richiesta, automatica  Analisi stato  Tempo di propagazione save fra i master

6  Deploy con ridondanza: copie attive con distribuzione carico  si minimizzano i costi dell’hardware in relazione alle performance attese  Gestore centralizzato  Coordinamento:  Scritture dominanti  Politica lazy  minimizzare tempo di propagazione  Assegnamento intervista (critico)  Sequenzializzato dal gestore  Trasparenza  fornisce ai client le stesse interfacce dei server  Consente cambio deploy senza configurazione client  Recovery delle situazione di errore sui server  Distribuisce il carico fra i server  Gestore di backup: Hot stand-by

7  Corba  Tipi di dati strutturati  Supporto alla trasparenza di locazione  Supporto per ambienti eterogenei  Supporto flessibile per la gestione thread lato server  Uso di Name Service per reperibilità dei servizi  Implementation Repository scarsamente supportato  MySQL :  Supporto a deploy multi-master  Gestione della replicazione  Facilità di configurazione  Possibilità di configurazione ad anello con auto-riconfigurazione in caso di guasti

8  Fornisce ai client le stesse interfacce dei server  Si occupa del recovery di situazioni di errore  Controlla periodicamente i server per prevenire situazioni di errore  Distribuisce il carico dei server  Mantiene aggiornato il Gestore di backup (se presente)  Simmetria fra gestore attivo e di backup

9  Un Server si registra presso il gestore  Nome con cui è registrato sul Name Server il servizio da erogare  Nome con cui è registrato sul Name Server il servizio disponibilità  Tipo: Server Interviste, Server Questionari, Gestore backup  Indicazione del carico di lavoro in grado di gestire  Un Server, in caso di terminazione soft, si rimuove dal gestore  Controlla periodicamente (ping) lo stato dei server, eventualmente rimuovendoli  Accetta le richieste dei client e le inoltra ad un opportuno server, bilanciando il carico  Recovery in caso di errore, inoltro ad un altro server (se presente)  Aggiorna sul gestore di backup lo stato dei server

10  All’avvio il gestore verifica se è già presente un gestore  si configura come backup  Si registra presso il Gestore principale, analogamente ai server  Riceve notifica dal gestore principale delle operazioni implicite e esplicite di aggiunta/rimozione server  Anche stato corrente all’arrivo del gestore  Controlla periodicamente il gestore principale (ping)  In caso di fallimento del gestore principale:  Si eleva  Aggiorna il riferimento al gestore nel Name Server  Notifica i server del cambiamento

11  Overhead  TCP/IP: aggiunge 40-48 bytes per packet (oltre overhead ethernet)  CORBA IIOP: aggiunge altri ~40-80 bytes per messaggio  Scarsa efficenza per molti piccoli messaggi  CORBA: introduce ritardi temporali, suddivisi in:  Fissi: context-switch, invocazione sul proxy locale  Variabili: (un)marshaling e trasmissione  Scarsa efficenza per molti piccoli messaggi  MySQL Replication:  Binary log (dall’avvio) delle operazioni che alterano il DB  Richiesto (pull) dagli altri DB: ripetono le operazioni  Possibilità di specificare un offset, per recuperare dati precedenti.

12  Funzionamento base  Corretta esecuzione delle operazioni sui server  Batteria di client per la simulazione  Uso di un simulatore del client supervisore per il popolamento delle interviste da effettuare  Deploy multi-server  (de)registrazione dei server nel gestore  Inoltro del gestore ai server  Trasparenza per i client a guasti/terminazione dei server  Bilanciamento carico dei server  Gestore di backup  Scelta della modalità operativa: principale o backup  Sincronizzazione dello stato  Elevazione  Trasparenza di locazione:  Corretto funzionamento:  sul distribuito, concentrando componenti

13  Ritardo sincronizzazione database:  <1s anche con carico elevato  Replicazione database e distribuzione save:  Scarsa scalabilità performance  Tutte le save devono essere propagate a tutti i server  Incremento performance solo se DB su stesso nodo  vanificato dai ritardi di rete  Ritardi CORBA per servizio non disponibile (timeout)  Richiesta servizio non disponibile  Caduta servizio durante erogazione  Tempo per accorgersene e recovery  In caso di caduta del gestore, necessario recovery lato client:  Non si ha trasparenza  La durata del recovery deve essere maggiore del tempo richiesto per l’elevazione del gestore di backup  Intervallo di ping del gestore  Tempo per aggiornamento Name Server

14  CORBA ha permesso la realizzazione di un prototipo flessibile in tempi rapidi  Flessibilità limitata dall’uso di Name Service  Difficoltà nella realizzazione di soluzioni scalabili nelle performance, in scenari con scritture dominanti.  Supporto multi-master dei DBMS  Efficienza  Scarso controllo  Poca flessibilità