1. 1 Distribuerede systemer og sikkerhed – 21. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley 2001 Presentation based on slides for the book: Slides modified by Jens B Jorgensen, University of Aarhus

2. 2 Chapter 14: Replication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

3. 3 Replication – basics zGoals: yEnhanced performance. yIncreased availability. yFault tolerance. zRequirements: yReplication transparency. yConsistency.

4. 4 Replication – basic architectural model FE Requests and replies C Replica C Service Clients Front ends managers RM FE RM One logical object reprensented as more physical objects. Replica managers are state machines and can recover. Failure model: Crashes only. Phases: Request, coordination, execution, agreement, response.

5. 5 Group communication – group membership services Join Group address expansion Multicast communication Group send Fail Group membership management Leave Process group

6. 6 Group communication – views and view delivery zViews: Ordered lists of current group members. zFor each group g, the group management service delivers to any member p in g a series of views: yv0(g),v1(g),v2(g),... zA member delivers a view when a membership change occurs, and the application is notified. zAn event e occurs in a view v(g) at process p, if p has delivered v(g), but not the next view v’(g) when e occurs.

7. 7 Group communication – view delivery requirements zOrder: If a process p delivers view v(g) and then v’(g), then no other process q delivers v’(g) before v(g). zIntegrity: If process p delivers view v(g), then p is in v(g). zNon-triviality: If process q joins a group and is or becomes indefinitely reachable from process p, then eventually q is always in the views that p delivers (a converse condition is required when group partition occurs).

8. 8 Group communication – purpose of view-synchronous communication zEnsure that the delivery of a new view draws a conceptual line across the system. zEvery message that is delivered at all is consistently delivered one side or the other of that line. zExample: State transfer.

9. 9 Group communication – requirements of view-synchronous communication zAgreement: Correct processes deliver the same set of messages in any given view. zIntegrity: If a process p delivers message m, then it will not deliver m again. Furthermore, p is in group(m) and m was supplied to a multicast operation by sender(m). zValidity (closed groups): Correct processes always deliver the messages that they send. If the system fails to deliver a message to any process q, then it notifies the surviving processes by delivering a new view with q excluded, immediately after the view in which any of them delivered the message.

10. 10 Group communication – example of view-synchronous communication

11. 11 Fault tolerance – introductory example zClient 1: ysetBalance(B,x,1) ysetBalance(A,y,2) zClient 2: ygetBalance(A,y) -> 2 ygetBalance(A,x) -> 0

12. 12 Fault tolerance – linearizability correctness criteria zA replicated shared object service is said to be linearizable if for any execution there is some interleaving of the series of operations issued by all clients that satisfies the following two criteria: yThe interleaved sequence of operations meets the specification of a (single) correct copy of the objects. yThe order of operations in the interleaving is consistent with the real times at which the operations occurred in the actual execution.

13. 13 Fault tolerance – sequential consistency correctness criteria zA replicated shared object service is said to be sequentially consistent if for any execution there is some interleaving of the series of operations issued by all clients that satisfies the following two criteria: yThe interleaved sequence of operations meets the specification of a (single) correct copy of the objects. yThe order of operations in the interleaving is consistent with the program order in which each individual client executed them.

14. 14 Fault tolerance – correctness criteria example zClient 1: ysetBalance(B,x,1) ysetBalance(A,y,2) zClient 2: ygetBalance(A,y) -> 0 ygetBalance(A,x) -> 0 Linearizability? Sequentially consistency?

15. 15 Fault tolerance – the passive (primary-backup) model FE C C RM Primary Backup RM

16. 16 Fault tolerance – active replication FEC CRM

17. 17 Summary zReplication – what and why? zGroup communication: yViews. yView-synchronous communication. zFault tolerance: yLinearizability. ySequential consistency. yPassive (primary-backup) replication. yActive replication.