Studio di una soluzione distribuita per la gestione di un centro
sondaggi
SONDIAMO
SCENARIO E OBIETTIVI
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.
ARCHITETTURA LOGICA (PRIMA ANALISI)
CLIENT: OPERARE SUI SERVER

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
SERVER

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
SCALABILITÀ E RIDONDANZA

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


Assegnamento intervista (critico)


minimizzare tempo di propagazione
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
TECNOLOGIE

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
GESTORE






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
GESTORE: FUNZIONAMENTO

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
GESTORE DI BACKUP

All’avvio il gestore verifica se è già presente un gestore



Si registra presso il Gestore principale, analogamente ai
server
Riceve notifica dal gestore principale delle operazioni
implicite e esplicite di aggiunta/rimozione server



si configura come backup
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
COMUNICAZIONE

Overhead


TCP/IP: aggiunge 40-48 bytes per packet (oltre overhead
ethernet)
CORBA IIOP: aggiunge altri ~40-80 bytes per messaggio


CORBA: introduce ritardi temporali, suddivisi in:


Fissi: context-switch, invocazione sul proxy locale
Variabili: (un)marshaling e trasmissione


Scarsa efficenza per molti piccoli messaggi
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.
TEST

Funzionamento base




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




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
Scelta della modalità operativa: principale o backup
Sincronizzazione dello stato
Elevazione
Trasparenza di locazione:

Corretto funzionamento:

sul distribuito, concentrando componenti
RISULTATI

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


Ritardi CORBA per servizio non disponibile (timeout)


Richiesta servizio non disponibile
Caduta servizio durante erogazione


vanificato dai ritardi di rete
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
CONCLUSIONI

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à
