Sistemi Distribuiti soggetti a Guasti

Transcript

1 Sistemi Distribuiti soggetti a Guasti Overview i guasti... Fino ad ora abbiamo assunto un modello di sistema senza guasti, abbiamo analizzato l effetto della concorrenza sugli algoritmi distribuiti (mutua esclusione) Ora consideriamo l effetto dei guasti, in particolare da ora in poi assumiamo un modello di guasto crash Analizzeremo come i guasti incidono - nella comunicazione punto-punto modellando canali punto-punto astratti, - come la gestione dei guasti venga astratta attraverso appositi moduli software chiamati failure detector. Quindi COSTRUIREMO algoritmi che risolvono i seguenti problemi: 1. Comunicazioni Broadcast 2. Leader Election 3. Consenso 4. Comunicazioni ordinate utilizzando come mattoncini di base i canali punto-punto ed i failure detector sistemi distribuiti soggetti a guasti 1 1

2 Mattoncino 1: Canali Punto-Punto sistemi distribuiti soggetti a guasti-canali punto-punto 2 Canale punto-punto o semplicemente link Ogni coppia di processi è connessa da un link bidirezionale (rete completamente connessa) Questa astrazione puo essere implementata con l uso di differenti topologie e uso di algoritmi di routing Alcuni algoritmi non assumono un canale per ogni coppia di processi, ma assumono altri tipi di topologie (es ring ) per fare uso delle proprietà di queste topologie sistemi distribuiti soggetti a guasti-canali punto-punto 3 2

3 Link e guasti I messaggi possono perdersi, tuttavia è improbabile che vengano tutti sistematicamente persi (a meno di partizioni di rete) Meccanismo base per affrontare il problema: ritrasmissione Nel seguito saranno presentati tre differenti astrazioni di link punto-punto, dalla piu debole alla piu forte in termini di garanzie di consegna - fair-loss links: i messaggi possono perdersi, ma la probabilità che un messaggio si perda è non-zero - stubborn links: costruiti sopra i fair loss - perfect links: costruiti sopra gli stubborn sistemi distribuiti soggetti a guasti-canali punto-punto 4 Fair-loss link Un processo P i invia il messaggio m al processo P j attraverso il fair-loss link eseguendo l istruzione flp2psend(m, P j ) Un processo P i riceve un messaggio m inviato dal processo P j attraverso il fair-loss link eseguendo l istruzione flp2pdeliver(m, P j ) Proprietà del canale Fair-loss Delivery: se un processo Pi invia un messaggio m infinite volte su un canale fair-loss (infinite esecuzioni di flp2psend(m, P j ad un processo Pj e né Pi né Pj fanno crash, allora Pj riceverà il messaggio m infinitamente spesso (inifinite esecuzioni di flp2pdeliver(m, P i Finite Duplication: se un messaggio m è inviato da Pi a Pj un numero finito di volte su un canale fair-loss (finite esecuzioni di flp2psend(m, P j, allora m non puo essere ricevuto un numero infinito di volte (finite esecuzioni di flp2pdeliver(m, P i No Creation: se un messaggio m viene ricevuto da un processo Pj su un canale fair-loss (esecuzione di flp2pdeliver(m, P i allora il messaggio è stato precedentemente inviato da Pi (Pi ha necessariamente già eseguito almeno una flp2psend(m, P j sistemi distribuiti soggetti a guasti-canali punto-punto 5 3

4 Stubborn link Un processo P i invia il messaggio m al processo P j attraverso lo stubborn link eseguendo l istruzione sp2psend(m, P j ) Un processo P i riceve un messaggio m inviato dal processo P j attraverso lo stubborn link eseguendo l istruzione sp2pdeliver(m, P j ) Proprietà del canale Stubborn Delivery: se un processo Pi invia un messaggio m su un canale stubborn (una esecuzione di sp2psend(m, P j ad un processo Pj e né Pi né Pj fanno crash, allora Pj riceverà il messaggio m infinitamente spesso (inifinite esecuzioni di sp2pdeliver(m, P i No Creation: se un messaggio m viene ricevuto da un processo Pj su un canale stubborn (esecuzione di sp2pdeliver(m, P i allora il messaggio è stato precedentemente inviato da Pi (Pi ha necessariamente già eseguito una sp2psend(m, P j sistemi distribuiti soggetti a guasti-canali punto-punto 6 Stubborn link - algoritmo when init timer:=null; tx:=empty; sp2psend(m, Pj) % implementazione dell istruz. chiamata da un % altro possibile programma, che gira cmq su Pi tx:= tx {m, Pj} timer:=δ when timer==0 for all (m, Pj) tx flp2p(tx, Pj) timer:=δ % da questo momento in poi il timer comincia a decrescere fino a zero when flp2pdeliver(m, Pj) % chiamata dal piano inferiore (la rete) sp2pdeliver(m,pj) % restituzione del msg al piano superiore sistemi distribuiti soggetti a guasti-canali punto-punto 7 4

5 Perfect link Un processo P i invia del messaggio m al processo P j attraverso un perfect link eseguendo l istruzione pp2psend(m, P j ) Un processo P i riceve un messaggio m inviato dal processo P j attraverso un perfect link eseguendo l istruzione pp2pdeliver(m, P j ) Proprietà del canale Reliable Delivery: se un processo Pi invia un messaggio m su un canale perfect (un esecuzione di pp2psend(m, P j ad un processo Pj e né Pi né Pj fanno crash, allora Pj riceverà il messaggio m prima o poi (un esecuzione di pp2pdeliver(m, P i No Duplication: un messaggio m non puo essere ricevuto piu di una volta (al piu un esecuzione di pp2pdeliver(m, P i No Creation: se un messaggio m viene ricevuto da un processo Pj su un canale perfetto (esecuzione di pp2pdeliver(m, P i allora il messaggio è stato precedentemente inviato da Pi (Pi ha necessariamente già eseguito almeno una pp2psend(m, P j sistemi distribuiti soggetti a guasti-canali punto-punto 8 Perfect link - algoritmo when init delivered:=empty; pp2psend(m, Pj) % chiamata di chi usa il canale perfetto sp2psend(m, Pj) % qui viene usato lo stubborn when sp2pdeliver(m, Pj) % chiamata dallo stubborn if (m delivered) then delivered:= delivered {m} pp2pdeliver(m, Pj) % restituzione del messaggio chi usa il canale perfetto sistemi distribuiti soggetti a guasti-canali punto-punto 9 5

6 Best effort links I link best effort fanno del loro meglio per fornire l astrazione di perfect link, ma ci riescono solo in caso in cui non ci siano guasti sospettati I link best effort infatti smettono di ritrasmettere prima o poi. A tal fine il sender comincia a ritrasmettere, mentre il receiver manda un acknowledgement indietro. Il sender deve settare un timeout per poter smettere di ritrasmettere anche quando non riceve un acknowledgment. MA non c è un limite conosciuto sul ritardo massimo dei messaggi. A quanto pone il timeout? Cmq lo ponga il timeout potrebbe scadere per i seguenti motivi: - crash del ricevente - guasto del link - ricevente temporaneamente lento - link temporaneamente lento Quando il timeout scade, il sospetto occorre, allora il canale best effort smette di ritrasmettere...tcp è un esempio di canale best effort Nota che lo stubborn garantisce delivery indipendemente dai sospetti sistemi distribuiti soggetti a guasti-canali punto-punto 10 Best effort links Proprietà del canale Best Effort Delivery: se un processo Pi invia un messaggio m su un canale best effort (un esecuzione di p2psend(m, P j ad un processo Pj e né Pi né Pj sospettano l altro, allora Pj riceverà il messaggio m prima o poi (un esecuzione di p2pdeliver(m, P i No Duplication: un messaggio m non puo essere ricevuto piu di una volta (al piu un esecuzione di p2pdeliver(m, P i No Creation: se un messaggio m viene ricevuto da un processo Pj su un canale best-effort (esecuzione di p2pdeliver(m, P i allora il messaggio è stato precedentemente inviato da Pi (Pi ha necessariamente già eseguito almeno una p2psend(m, P j sistemi distribuiti soggetti a guasti-canali punto-punto 11 6

7 Mattoncino 2: Failure Detector sistemi distribuiti soggetti a guasti-failure detector 12 Assunzioni di sincronia Abbiamo già visto i due modelli estremi che astraggono due differenti sistemi distribuiti: - modello sincrono che astrae un sistema in cui - la comunicazione è sincrona - la computazione è sincrona - i clock fisici sono sincroni - modello asincrono: non viene fatta alcuna assunzione su processi e comunicazione Modelli di Sincronia Parziale: catturano il comportamento di sistemi caratterizzati dall essere sincroni per la maggior parte del tempo. Questo viene catturato dall assumere che le assunzioni di sincronia valgono solo da un certo tempo in poi (non conosciuto) Sincrono Parzialmente sincrono Asincrono sistemi distribuiti soggetti a guasti-failure detector 13 7

8 Failure detector Progettare algoritmi che integrino le assunzioni di sincronia non è agevole, si tratterebbe di estendere le astrazioni di processo e link per considerare le loro caratteristiche di sincronia. Invece di fare ciò si considera un specifica e separata astrazione: Failure Detectors: astrazione per incapsulare le proprietà di sincronia del sistema Le applicazioni vengono sviluppate come per Sistema Asincrono + Failure Detectors applicazione sistema asincrono+ F.D. sistema parzialm. sincrono sistemi distribuiti soggetti a guasti-failure detector 14 Failure detector Failure Detector: oracolo distribuito. Ogni processo applicazione P i ha un modulo FD locale FD i. Un modulo FD mantiene una lista di processi del sistema sospettati di essere guasti. I processi consultano i loro FD locali per informarsi dello stato degli altri processi. I moduli FD scambiano info sui processi sospettati. Un modulo FD potrebbe erroneamente sospettare un processo; un processo potrebbe essere rimosso dalla lista dei sospettati - unreliable FDs. processes p i FD i communication medium sistemi distribuiti soggetti a guasti-failure detector 15 8

9 Failure detector L informazione che il failure detector fornisce è tanto piu accurata quanto piu è sincrono il sistema sottostante Ad esempio se il sistema sottostante è completamente sincrono si puo implementare un failure detector perfetto: ogni processo riportato come sospettato è effettivamente guasto Se però abbiamo un sistema parzialmente sincrono che tipo di output abbiamo? che accuratezza? A questa domanda rispondono i diversi tipi di failure detectors, specificati in termini di proprietà sistemi distribuiti soggetti a guasti-failure detector 16 Failure detector - specifica L algoritmo si basa su FD specs e non su implem. di FD. In questo modo: L algoritmo è indipendente dalle vere assunzioni di sincronia sottostanti L algoritmo è portabile in differenti modelli Cambiando modelli di sistema, solo l implementazione di FD (s/w o h/w) deve cambiare (non l implementazione dell algoritmo)! specifica di FD importante per la progettazione dell algoritmo! 2 proprietà completeness: accuracy: i processi guasti nel sistema sono sospettati i processi corretti nel sistema non sono sospettati sistemi distribuiti soggetti a guasti-failure detector 17 9

10 Failure Detector - specifica Perfect Failure Detector P: Strong Completeness: Ogni processo guasto è prima o poi sospettato permanentemente da ogni processo corretto. Strong Accuracy: Se un processo p è sospettato da un qualsiasi processo, allora p si è guastato sistemi distribuiti soggetti a guasti-failure detector 18 Algoritmo per realizzare il failure detector P L algoritmo che vediamo lavora su un sistema sincrono e si basa sull uso di timeout Come al solito ogni processo fa girare una copia dell algoritmo che segue le seguenti regole: - Un processo invia un messaggio ad un altro processo ed aspetta una risposta - Se il processo ricevente non si guasta allora la risposta arriva entro un periodo di tempo uguale a - worst case processing delays volte il worst case per i message transfer delays - (ignoriamo i clock drifts) - Il processo mittente usa il suo clock locale per misurare il worst case delay (periodo di timeout) richiesto per ottenere una risposta e rileva un guasto nel caso di assenza di risposta da parte del ricevente entro il periodo di timeout sistemi distribuiti soggetti a guasti-failure detector 19 10

11 Algoritmo per realizzare il failure detector P Possibile algoritmo tra due processi Pi e Pj when init do alive:={pj} crashed:= timer:=δ when timer==0 do if (Pj alive) (Pj crashed) then crashed:=crashed {Pj} else pp2psend ( ci sei?,pj) alive:= timer:=δ Generalizzare in maniera diretta questo algoritmo significherebbe settare un timeout per ogni processo che viene monitorato e gestire quindi ogni scambio di messaggi in maniera indipendentente. Questo è costoso Ma allora perché non sfruttare una computazione round-based sincrona? - Un round deve durare almeno Δ. when pp2pdeliver( ci sono,pj) do alive:=alive {Pj} when pp2pdeliver( ci sei?,pj) do pp2psend ( ci sono,pj) - Tutti i processi iniziano e finiscono il round nello stesso istante di tempo. sistemi distribuiti soggetti a guasti-failure detector 20 Algoritmo per realizzare il failure detector P when init do alive:={p1, P2,, PN} crashed:= timer:=δ All inizio del nuovo round alive è resettato a zero in tutti i processi vivi Durante il round si raccolgono gli heartbeat when timer==0 do for all Pi {P1, P2,, PN}do if (Pi alive) (Pi crashed) then crashed:=crashed {Pi} pp2psend ( heartbeat,pi) alive:= timer:=δ when pp2pdeliver( heartbeat,pi) do alive:=alive {Pi} Alla fine del round si pongono nella variabile crashed quei processi dai quali non è arrivato nessun heartbeat Si suppone che la variabile crashed ogni volta che viene aggiornata venga consegnata al piano superiore, cioè a qualunque algoritmo che gira contemporaneamente sul processo e usa il failure detector sistemi distribuiti soggetti a guasti-failure detector 21 11

12 Limiti dell implementazione di P Il failure detector P è molto conveniente per scrivere algoritmi distribuiti, l indicazione che dà su un processo che si è guastato è sempre vera Tuttavia un FD P è difficile da implementare, necessita un sistema sincrono per essere implementato A questo scopo la specifica dei Failure Detector puo essere piu debole in modo da permettere implementazioni di FD piu deboli (ma comunque utili) in sistemi parzialmente sincroni indeboliamo il Perfect FD sistemi distribuiti soggetti a guasti-failure detector 22 Altri failure detector - specifica in termini di Completeness : Weak Completeness: Ogni processo guasto è alla fine sospettato permanentemente da qualche processo corretto in termini di Accuracy : Weak Accuracy: Qualche processo corretto non è mai sospettato da un altro processo corretto Eventual Strong Accuracy: Esiste un tempo dopo il quale nessun processo corretto viene più sospettato da un altro processo corretto Eventual Weak Accuracy: Esiste un tempo dopo il quale qualche processo corretto non viene più sospettato da un altro processo corretto sistemi distribuiti soggetti a guasti-failure detector 23 12

13 Classi di failure detector 2 versioni di completeness x versioni di 4 accuracy = 8 FDs Accuracy Completeness S W S W ES EW P Q S W P Q S W Ref: Chandra, Toueg Unreliable failure detectors for reliable distributed systems, Journal of the ACM, March sistemi distribuiti soggetti a guasti-failure detector 24 Eventually Perfect Failure Detector P P incapsula le assunzioni di sincronia di un sistema quando esse valgono solo da un certo tempo in poi (non conosciuto) Fondamentalmente P garantisce che c è un tempo dopo il quale i guasti possono essere rilevati con accuratezza: prima o poi si comporta come P, ma non si sa quando lo farà Strong Completeness: Ogni processo guasto è prima o poi sospettato permanentemente da ogni processo corretto. Eventual Strong Accuracy: Prima o poi nessun processo corretto è piu sospettato da nessun processo corretto sistemi distribuiti soggetti a guasti-failure detector 25 13

14 Algoritmo che realizza un failure detector P Anche qui si fa uso di timeout, ma si dà la possibilità di ricevere la risposta del ricevente anche dopo la scadenza del timeout stesso: in questo caso significa che il sospetto era infondato Nel caso di sospetto infondato su Pj da parte di Pi, allora Pi smette di sospettare Pj I timeout sono adattivi: se si scopre che il ricevente è vivo dopo la scadenza del timeout, allora il timeout viene incrementato. Assunzioni di sincronia: questo algoritmo funziona nell ipotesi che prima o poi esisterà un tempo di ritardo massimo sempre rispettato. Il timeout adattivo è capace di acchiapparlo. Si noti che avere timeout piccoli significa aumentare la probabilità di commettere falsi sospetti ma dà la possibilità di rilevare con maggior rapidità i guasti veri sistemi distribuiti soggetti a guasti-failure detector 26 Algoritmo che realizza un failure detector P when init do alive:={p1, P2,, PN} suspected:= period:=δ timer:=period when timer==0 do if (alive suspected) then period:=period + Δ for all Pi {P1, P2,, PN}do if (Pi alive) (Pi suspected) then suspected:=suspected {Pi} else if (Pi alive) (Pi suspected) then suspected:=suspected \ {Pi} pp2psend ( heartbeat,pi) alive:= timer:=period when pp2pdeliver( heartbeat,pi) do alive:=alive {Pi} sistemi distribuiti soggetti a guasti-failure detector 27 14

15 Comparazione tra Failure Detector P P Q Q introducing eventuality in accuracy weakening S S completeness weakening accuracy W W FD FD : Se un problema può essere risolto usando FD e FD FD : allora il problema può essere risolto usando FD. FD può essere trasformato in FD sistemi distribuiti soggetti a guasti-failure detector 28 Comparazione tra Failure Detector Le frecce nel cubo apparentemente indicano relazioni di forza... P P S S Possono essere trasformati Q Q W W si può dimostrare anche... Q Q W W P P S S Gli insiemi di FD {Q, Q,W, W} sono rispettivamente equivalenti a {P, P,S, S}, quindi Q P Q P W S W S cosa significa? weak e strong completeness sono equivalenti sistemi distribuiti soggetti a guasti-failure detector 29 15

16 Esercizi 1. Considerate l astrazione di canale punto-punto stubborn. Alla base dell algoritmo che lo implementa c è una ritrasmissione infinita di messaggi. D altro canto, un algoritmo si dice quiescente se prima o poi nel canale non fluiscono piu messaggi. Dire se esiste un algoritmo quiescente per implementare un quiescent stubborn link che dia la garanzia che un messaggio m venga consegnato almeno una volta (anche piu di una) nel caso né il sender né il recevier facciano crash, nei seguenti casi: 1) Non sono assunti guasti nel sistema: tutti processi corretti 2) Il receiver fa crash 3) Il sender fa uso di un failure detector P 4) Il sender fa uso di un failure detector P 5) Dire in che modello di sincronia l algoritmo che implementa TCP si comporta come un quiescent stubborn link considerando che TCP usa un buffer limitato a priori. 2. Scrivete un algoritmo che implementa P facendo uso di Q 3. Provate a spiegare (anche con esempi) perché facendo uso di S non si riesce ad implementare P sistemi distribuiti soggetti a guasti-canali punto-punto 30 16