Sondiamo

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

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. Scenario e Obiettivi

3. Architettura Logica (prima analisi)

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 Client: operare sui server

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 Server

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 Scalabilità e Ridondanza

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 • ImplementationRepository scarsamente supportato • MySQL: • Supporto a deploymulti-master • Gestione della replicazione • Facilità di configurazione • Possibilità di configurazione ad anello con auto-riconfigurazione in caso di guasti Tecnologie

8. Fornisce ai client le stesseinterfacce 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 Gestore

9. Un Server si registra presso il gestore • Nome con cui è registrato sul NameServer 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 Gestore: Funzionamento

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 Gestore di BAckup

11. Overhead • TCP/IP: aggiunge 40-48 bytes per packet (oltre overhead ethernet) • CORBA IIOP: aggiungealtri ~40-80 bytes per messaggio • Scarsaefficenza per moltipiccolimessaggi • CORBA: introduce ritarditemporali, suddivisi in: • Fissi: context-switch, invocazionesul proxy locale • Variabili: (un)marshaling e trasmissione • Scarsaefficenza per moltipiccolimessaggi • MySQLReplication: • 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. Comunicazione

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 • Deploymulti-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 Test

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 Risultati

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à Conclusioni