Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 DISTRIBUTED SYSTEMS.

Presentazione sul tema: "Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 DISTRIBUTED SYSTEMS."— Transcript della presentazione:

1 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN Chapter 8 Fault Tolerance

2 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Fault Tolerance Basic Concepts Being fault tolerant is strongly related to what are called dependable systems Dependability (attendibilità) implies the following: 1.Availability (disponibilità) 2.Reliability (affidabilità) 3.Safety 4.Maintainability

3 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Fault Tolerance Basic Concepts failure: il sistema non “mantiene le promesse”, es. alcuni servizi non vengono (comlpetamente) forniti; error: stato del sistema che porta a failure; fault: causa di un errore: –transient fault; –intermittent fault; –permanent fault.

4 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Failure Models Figure 8-1. Different types of failures.

5 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Failure Models Fallimenti arbitrari: difficili da riconoscere e gestire (bizantini…); fail-safe: il sistema può produrre dati arbitrari ma è in grado di riconoscere queste situazioni e gestirle;

6 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Failure Masking by Redundancy ridondanza informativa; –Aggiunta di informazioni aggiuntive, es. codici di Hamming. ridondanza temporale; –Ripetizione delle azioni, finchè non hanno successo. ridondanza fisica (in hardware o in software) –I processi (macchine) vengono replicati.

7 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Failure Masking by Redundancy Figure 8-2. Triple modular redundancy.

8 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Process resilience Protezione contro i fallimenti dei processi: –Replica e raggruppamento dei processi. Resilienza (resistenza): –capacità di un materiale di resistere a deformazioni o rotture dinamiche, rappresentata dal rapporto tra il lavoro occorrente per rompere un’asta di tale materiale e la sezione dell’asta stessa: indice, valore di r. –capacità di un filato o di un tessuto di riprendere la forma originale dopo una deformazione.

9 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Process resilience: grouping Raggruppamenti di processi identici (replicati): –Replica e raggruppamento dei processi ; –Un gruppo permette la gestione di collezioni di processi. I messaggi vengono ricevuti dall’intero gruppo di processi: se uno fallisce gli altri possono intervenire. I gruppi vengono gestiti dinamicamente.

10 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Flat Groups versus Hierarchical Groups Figure 8-3. (a) Communication in a flat group. (b) Communication in a simple hierarchical group.

11 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Gestione dei gruppi Centralizzata: group server; Decentralizzata: –multicast ai membri di un gruppo; –riconoscimento dei crash e rimozione dai gruppi;

12 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Mascheramento delle failure Primary-based replication: –Organizzazione gerarchica con una copia primaria che coordina; –In caso di crash della copia primaria un algoritmo di elezione sceglie un’altra replica. Replicated-write protocols (active replication): –Gruppi flat; –Nessun punto critico singolo;

13 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems Sistema “k-fault tolerant”: –Sopporta il fallimento di k elementi; –Ulteriori fallimenti generano risultati impredicibili. Es. sistema a votazione con tolleranza k sono necessare 2k+1 repliche. Con n repliche la tolleranza è n/2-1

14 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems (1) Possible cases: 1.Synchronous versus asynchronous systems. 2.Communication delay is bounded or not: messaggi trasmessi in un tempo max. 3.Message delivery is ordered or not. 4.Message transmission is done through unicasting or multicasting.

15 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems (2) Figure 8-4. Circumstances under which distributed agreement can be reached.

16 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems (3) The Byzantine agreement problem for three non-faulty and one faulty process In questo caso i processi possono comunicare dati sbagliati; Processi sincroni; Messaggi unicast; Ordinamento dei messaggi preservato; Tempo di comunicazione limitato.

17 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems (3) Figure 8-5. The Byzantine agreement problem for three nonfaulty and one faulty process. (a) Each process sends their value to the others.

18 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems (4) Figure 8-5. The Byzantine agreement problem for three nonfaulty and one faulty process. (b) The vectors that each process assembles based on (a). (c) The vectors that each process receives in step 3.

19 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Agreement in Faulty Systems (5) Figure 8-6. The same as Fig. 8-5, except now with two correct process and one faulty process.

20 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 RPC Semantics in the Presence of Failures Five different classes of failures that can occur in RPC systems: 1.The client is unable to locate the server. 2.The request message from the client to the server is lost. 3.The server crashes after receiving a request. 4.The reply message from the server to the client is lost. 5.The client crashes after sending a request.

21 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Il client non individua il server Tutti i server sono caduti; C’è un problema di versione tra stub del client e server; Soluzioni: Eccezioni; Signal handlers; …

22 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Perdita dei messaggi di richiesta Timers; Time-out; …

23 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server Crashes (1) Figure 8-7. A server in client-server communication. (a) The normal case. (b) Crash after execution. (c) Crash before execution.

24 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server Crashes (1) Tipi di semantica per l’esecuzione: Esattamente una volta –semantica desiderata. Almeno una volta –In caso di fallimento si riavvia la macchina (server) e si reitera la richiesta. Al massimo una volta –In caso di fallimento si restituisce un errore Nessuna garanzia –semplice da implementare

25 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server Crashes (2) Three events that can happen at the server: Send the completion message (M), Print the text (P), Crash (C).

26 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server Crashes (3) These events can occur in six different orderings: 1.M →P →C: A crash occurs after sending the completion message and printing the text. 2.M →C (→P): A crash happens after sending the completion message, but before the text could be printed. 3.P →M →C: A crash occurs after sending the completion message and printing the text. 4.P→C(→M): The text printed, after which a crash occurs before the completion message could be sent. 5.C (→P →M): A crash happens before the server could do anything. 6.C (→M →P): A crash happens before the server could do anything.

27 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server Crashes (4) Figure 8-8. Different combinations of client and server strategies in the presence of server crashes.

28 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Lost reply messages Misure dei time-out e ritrasmissione; Richieste indepondenti (es. lettura…) non generano effetti collaterali; Per rendere indepondenti i messaggi si può: –numerarli; –assegnare un bit che indica la ritrasmissione.

29 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Client crash Orfani: il calcolo continua ma non c’è il client a ricevere i risultati: –Occupazione di risorse, –Blocco dei file, –… 1.Eliminazione dei processi orfani: (si individuano usando dei log); 2.Reincarnazione: i server sono legati ad un’ ”epoca” dei client, quando un client si riavvia richiede il riavvio di tutti i server legati alla precedente epoca; 3.Si può controllare che non tutti i server vengano riavviati (solo gli orfani) 4.Expiration: si assegna un tempo di esecuzione massimo.

30 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Multicast affidabili Un messaggio inviato ad un gruppo di processi deve essere ricevuto da ciascun membro del gruppo, ma se durante la comunicazione: un nuovo processo si aggiunge al gruppo? un processo va in crash?

31 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Basic Reliable-Multicasting Schemes Figure 8-9. A simple solution to reliable multicasting when all receivers are known and are assumed not to fail. (a) Message transmission. (b) Reporting feedback.

32 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Scalability in Reliable-Multicasting Per n repliche che ricevono i messaggi, ci devono essere n messaggi di ACK: feedback implosion Si possono inviare notifiche per i messaggi persi, non per quelli ricevuti: abbattimento dei feedback. Chi invia deve tener traccia della storia dei messaggi per poterli ritrasmettere in caso di necessità.

33 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Scalable Reliable Multicasting Chi riceve un messaggio non notifica niente Vengono notificati solo i messaggi persi; La notifica viene inviata a tutti –un altro ricevente che deve segnalare la perdita di un messaggio, può inibire la propria notifica –anche i riceventi che non hanno avuto problemi devono riprocessare i messaggi.

34 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Nonhierarchical Feedback Control Figure 8-10. Several receivers have scheduled a request for retransmission, but the first retransmission request leads to the suppression of others.

35 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Hierarchical Feedback Control Figure 8-11. The essence of hierarchical reliable multicasting. Each local coordinator forwards the message to its children and later handles retransmission requests.

36 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Atomic multicast Un messaggio deve essere spedito a tutti o a nessuno L’ordine di spedizione deve essere rispettato Es. Se un processo del gruppo va in crash, viene estromesso dal gruppo stess Il multicast avviene solo sulle repliche attive Se il processo viene ripristinato, può essere ammesso al gruppo solo quando raggiunge uno stato consistente con le altre repliche.

37 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Atomic multicast Ogni messaggio m è associato univocamente ad una lista di processi al quale deve essere spedito

38 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Virtual Synchrony (1) Figure 8-12. The logical organization of a distributed system to distinguish between message receipt and message delivery.

39 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Virtual Synchrony (1) Virtual synchrony: Un messaggio multicast spedito ad un gruppo G deve essere consegnato ad ogni processo di G non fallito. Se durante l’invio un processo fallisce (crash), il messaggio deve essere inviato a tutti gli altri o a nessuno.

40 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Virtual Synchrony (2) Figure 8-13. The principle of virtual synchronous multicast.

41 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Message Ordering (1) Four different orderings are distinguished: Unordered multicasts FIFO-ordered multicasts Causally-ordered multicasts Totally-ordered multicasts (nello stesso ordine a tutti I membri del gruppo)

42 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Message Ordering (2) Figure 8-14. Three communicating processes in the same group. The ordering of events per process is shown along the vertical axis.

43 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Message Ordering (3) Figure 8-15. Four processes in the same group with two different senders, and a possible delivery order of messages under FIFO-ordered multicasting

44 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Implementing Virtual Synchrony (1) Figure 8-16. Six different versions of virtually synchronous reliable multicasting.

45 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Implementing Virtual Synchrony (1) Si deve garantire che il multicast verso un gruppo G termini prima che G possa cambiare. Ogni processo deve conservare il messaggio e processarlo solo quando è sicuro che gli altri membri del gruppo lo hanno ricevuto. Un messaggio ricevuto da tutti è detto stabile Solo i messaggi stabili possono essere consegnati

46 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Implementing Virtual Synchrony (2) Figure 8-17. (a) Process 4 notices that process 7 has crashed and sends a view change.

47 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Implementing Virtual Synchrony (3) Figure 8-17. (b) Process 6 sends out all its unstable messages, followed by a flush message.

48 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Implementing Virtual Synchrony (4) Figure 8-17. (c) Process 6 installs the new view when it has received a flush message from everyone else.

49 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Distributed Commit Un’operazione deve essere eseguita da ogni membro di un gruppo di processi, o da nessuno. Protocollo di commit a una fase: Un coordinatore gestisce le fasi di commit Chiede a tutti I partecipanti se eseguire o no il commit

50 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (1) 1.Il coordinatore invia un messaggio VOTE_REQUEST a tutti i partecipanti 2.I partecipanti rispondono con VOTE_COMMIT o VOTE_ABORT 3.Se tutti hanno risposto VOTE_COMMIT il coordinatore invia a tutti GLOBAL_COMMIT altrimenti GLOBAL_ABORT 4.I partecipanti aspettano la risposta per eseguire le proprie azioni

51 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (1) Figure 8-18. (a) The finite state machine for the coordinator in 2PC. (b) The finite state machine for a participant.

52 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (1) Che succede se il coordinatore fallisce e non invia il messaggio GLOBAL_ a tutti i partecipanti: caso con due processi P e Q

53 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (2) Figure 8-19. Actions taken by a participant P when residing in state READY and having contacted another participant Q.

54 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (3) Figure 8-20. Outline of the steps taken by the coordinator in a two-phase commit protocol....

55 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (4) Figure 8-20. Outline of the steps taken by the coordinator in a two-phase commit protocol....

56 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (5) Figure 8-21. (a) The steps taken by a participant process in 2PC.

57 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (7) Ogni partecipante esegue un thread per prendere una decisione in funzione dei messaggi ricevuti.

58 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (7) Figure 8-21. (b) The steps for handling incoming decision requests..

59 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Two-Phase Commit (7) Il commit a due fasi è sensibile ai crash del coordinatore Viene usato perchè è comunque abbastanza robusto

60 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Three-Phase Commit (1) The states of the coordinator and each participant satisfy the following two conditions: 1.There is no single state from which it is possible to make a transition directly to either a COMMIT or an ABORT state. 2.There is no state in which it is not possible to make a final decision, and from which a transition to a COMMIT state can be made.

61 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Three-Phase Commit (1) Il coordinatore invia VOTE_REQUEST a tutti e si mette in attesa Se almeno un partecipante risponde con un Abort il coordinatore effettua un GLOBAL_ABORT Altrimenti invia un messaggio PREPARE_COMMIT Quando tutti i partecipanti hanno acconsentito effettua il GLOBAL_COMMIT

62 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Three-Phase Commit (2) Figure 8-22. (a) The finite state machine for the coordinator in 3PC. (b) The finite state machine for a participant.

63 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Recovery Backward recovery: si vuole portare il sistema da uno stato erroneo ad uno stato precedente non erroneo: –Si registra lo stato in un determinato punto –Si ripristina il sistema dai dati salvati (chekpointing) –Es. rispedizione dei messaggi errati Forward recovery: se il sistema è in uno stato errato lo si porta in un nuovo stato dal quale l’esecuzione può continuare –Es. correzione degli errori

64 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Memoria stabile Memoria: –RAM –Di Massa: sopravvive ai crash di sistema ma non a quelli di disco –Stabile: sopravvive a situazioni non catastrofiche. To implement stable storage –Replicate information on more than one nonvolatile storage media with independent failure modes. –Update information in a controlled manner to ensure that we can recover the stable data after any failure during data transfer or recovery.

65 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Recovery – Stable Storage Figure 8-23. (a) Stable storage. (b) Crash after drive 1 is updated. (c) Bad spot.

66 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 RAID (cont) Several improvements in disk-use techniques involve the use of multiple disks working cooperatively. Disk striping uses a group of disks as one storage unit. RAID schemes improve performance and improve the reliability of the storage system by storing redundant data. –Mirroring or shadowing keeps duplicate of each disk. –Block interleaved parity uses much less redundancy.

67 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 RAID Levels

68 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 RAID (0 + 1) and (1 + 0)

69 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Checkpointing Registrazione dello stato In caso di fallimento viene ripristinato lo stato consistente più recente (recovery line) –Questo può portare ad un effetto domino –Si usano allora checkpoint indipendenti o coordinazione globale

70 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Checkpointing Figure 8-24. A recovery line.

71 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Independent Checkpointing Figure 8-25. The domino effect.

72 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Coordinated Checkpointing I processi si accordano su quando fare il checkpointing Un coordinatore invia il messaggio CHECKPOINT_REQUEST, e quando tutti rispondono invia CHECKPOINT_DONE

73 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Characterizing Message-Logging Schemes Figure 8-26. Incorrect replay of messages after recovery, leading to an orphan process.

74 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Log Structured File Systems Log structured (or journaling) file systems record each update to the file system as a transaction All transactions are written to a log –A transaction is considered committed once it is written to the log –However, the file system may not yet be updated The transactions in the log are asynchronously written to the file system – When the file system is modified, the transaction is removed from the log If the file system crashes, all remaining transactions in the log must still be performed