Reti di Calcolatori L-S
Sistema con supporto per la
Gestione dei Guasti
Gattari Gabriele
Obbiettivi
Il sistema che si è sviluppato consente di:
●
Dare un supporto Fault Tollerant per semplici
servizi
●
Gestire il carico sugli esecutori del sistema
●
Evitare la congestione del sistema
Architettura
Attori
●
●
●
●
Client: Effettua delle richieste al gestore che è
l'unico attore che conosce
Server Replicato: Compie materialmente il servizio
su richiesta del gestore. Non prevede stato.
Gestore: Controlla l'intera rete mediando le
richieste
dei clienti verso le Repliche e
appoggiandosi su
Server Backup per
il fault-tollerant.
Gestore Backup: Consente di salvare lo stato del
Gestore al fine di gestire eventuali situazioni di
guasto
Comunicazione
STREAM
RMI
STREAM
RMI ci consente di avere
trasparenza lato client, che
conosce solo il gestore.
Astrazione di
Oggetto Replicato
Modello CallBack di Risposta
Gli stream ci consentono
di avere la notifica di una
disconnessione.
Registrazione
●
●
Associato al gestore c'è un processo sempre i
esecuzione che accetta connessioni da Server
Replica e Backup
A seguito della registrazione, che può essere fatta
anche durante l'esecuzione di un servizio, vengono
allocate le risorse per la comunicazione
Registrazione
Registrazione
Accetta
Conn
Server Replica
Gestore
Backup
Schema Servizio
1
3
5
4
2
6
1)Il cliente effettua una richiesta
2)Il gestore salva lo stato sul backup
3)Inoltro alle repliche della richiesta
4)Risposta delle repliche interpellate
5)Restituzione risultato cliente
6)Aggiornamento stato backup
Carichi
Richiesta
+ locazione nuovo gestore
Le repliche coinvolte nella
richiesta rispondono al gestore
inoltrando anche informazioni
riguardo al carico della replica
stessa
(Numero di richieste in
elaborazione in parallelo)
L'invio di una richiesta ad un certo
server replica dipende dallo stato di
carico della replica stessa.
Queste informazioni sono conosciute dal
gestore ed esso invia solo le richieste alle
repliche scariche decidendo in base ad
una soglia.
Insieme alla richiesta invia anche
informazioni riguardanti il nuovo gestore
in caso di caduta.
Risposta
+ carico della replica
Congestione
●
●
●
Nel caso tutte le Repliche fossero
sovraccariche (livello di carico superiore alla
soglia) il sistema è in uno stato di congestione
Le richieste non vengono inoltrate ma
accodate localmente (aggiornando i backup)
Dopo un certo numero di accodamenti il
gestore risponde ai client rifiutando la richiesta
Si evita la congestione come nel modello
Leaky Bucket
Dettagli Comunicazione
Sia il gestore che i server
Replicati/Backup hanno a
disposizione una coda per
i messaggi.
In queste code vengono
inserite le richieste che il
sistema deve gestire.
Il funzionamento tende a
disaccoppiare l'invio delle
richieste dalla loro
esecuzione.
Gestione Thread-Pool
Sender e Receiver
gestiscono la connessione
per conto degli attori
Fault
Per la gestione dei Fault del Gestore si è scelto un modello di
Replicazione Passiva a copie calde.
Motivazioni:
●
Semplicità
●
Basso Costo
●
Rapida riconfigurazione
I gestore salva periodicamente il suo stato sui gestori di Backup che
forniscono l'astrazione di copie calde.
Se il gestore è in vita subiscono i checkpoint, non appena
determinano una caduta provvedono a rimpiazzarlo.
Ipotesi di Fault
Come è noto le ipotesi di fault semplificano il
progetto di architetture di supporto per la
tolleranza hai guasti:
●
Ipotesi di guasto singolo:
Si suppone che il tempo di individuazione di un
guasto più il tempo di recovery sia minore del
tempo tra due guasti di uno qualsiasi degli
attori.
●
Crash di un qualsiasi attore
●
Problemi con la connessione
Individuazione Fault
●
Per quanto riguarda i Fault in cui c'è disconnessione ci
possiamo affidare al supporto offerto dagli stream infatti
non appena la connessione viene meno (caduta nodo o
disconnessione) il supporto ci notifica un'eccezione che
dobbiamo gestire.
Alternativamente però uno qualsiasi degli attori
potrebbe andare in crash senza rilasciare le risorse di
rete...
●
Heartbeat
Occorre implementare un Heartbeat. Il gestore e i vari
attori (esclusi client) devono continuamente sollecitarsi
a vicenda per provare di essere vivi.
●
Il modello implementato:
Utilizzo di pacchetti applicativi affiancati da pacchetti
dummy in momenti di basso traffico.
Socket con timeout che viene resettato ad ogni ricezione.
Quindi finché c'è traffico i timeout vengono resettati, se
qualcuno non risponde -> gestione caduta.
In assenza di traffico applicativo?
Pacchetti dummy generati a intervalli regolari
Guasto Replica
Nel caso una delle repliche non risponda entro
un certo tempo o la connessione verso di lei
salti.
Il gestore prende atto della caduta e agisce per
escludere la replica.
●
Rilascia le risorse associate
●
Aggiorna il proprio stato
risposte)
●
Gestisce casi degeneri
(non attende oltre per le
Guasto Backup
Nel caso uno dei Backup non risponda entro
un certo tempo o la connessione verso di lui
salti.
●
●
Il gestore prende atto della caduta e agisce
per escludere il backup.
Aggiorna il proprio stato
Nel caso un backup si colleghi mentre il
servizio è in atto esso viene riconfigurato
mediante un pacchetto di aggiornamento
cumulativo
Pacchetti Gestore-Backup
Aggiornamento:
●ADD
aggiornamento selettivo di una richiesta client
●REM
rimozione selettiva una richiesta client
●COL
aggiornamento cumulativo (riconnessione)
●CAD
notifica caduta client
●DUMMY pacchetto di Are-you-Alive?
Risposte:
●DUMMY pacchetto generico di risposta al gestore
In PiggyBack il gestore comunica le sequenza di successione e il nuovo
successore a tutti.
(Ordine determinato staticamente alla connessione)
Guasto Gestore
La copia di Backup primaria diviene il nuovo
gestore
Nuovo Gestore:
●
Termina il suo lavoro di Backup
●
Si riallacciano le connessioni con gli attori
●
Si inoltrano nuovamente tutte le richieste pendenti
Gli attori:
●
Si ricollegano al nuovo gestore
●
Buttano via eventuali risultati intermedi (Repliche)
Guasto Client
Nel caso dei client l'accoppiamento è più lasco
di quello tra i server.
Individuazione caduta all'atto della risposta.
●
●
●
Rimozione delle richieste
localmente al gestore
ancora
in
coda
Rimozione di tutte le richieste salvate nei backup
Nessuna notifica
overhead)
alle
repliche
(limitazione