1. 1 Chapter 14: Replication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001 Presentation based on slides by Coulouris et al; modified by Jens B Jorgensen and Jonas Thomsen, University of Aarhus

2. 2 Replication – basics zGoals: yEnhanced performance xCaching, has a limit of effectiveness. yIncreased availability x1 – probability(all RM failed) = 1 – p n yFault tolerance xGuarantees strictly correct behavior. zRequirements: yReplication transparency xClients access one logical object, don’t know physical objects. yConsistency xApplication dependent requirements.

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

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

5. 5 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: yv 0 (g),v 1 (g),v 2 (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.

6. 6 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).

7. 7 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.

8. 8 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.

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

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

11. 11 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.

12. 12 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.

13. 13 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?

14. 14 Fault tolerance – the passive (primary-backup) model (1/3) FE C C RM Primary Backup RM

15. 15 Fault tolerance – the passive (primary-backup) model (2/3) zRequest: yFE  primary. zCoordination: yNo (primary decides). zExecution: yOn primary, stores response. zAgreement: yRequest is sent to slaves. yResponse is awaited. zResponse: yPrimary’s response is sent to FE.

16. 16 Fault tolerance – the passive (primary-backup) model (3/3) zLinearizable (primary dictates the ordering) zLinearizable on primary failure if: yprimary is replaced by a unique backup. yall backups agree on which operations had been performed. zSolution: yUse view-synchronous group communication to send updates to backups.

17. 17 Fault tolerance – active replication (1/3) FEC CRM

18. 18 Fault tolerance – active replication (2/3) zRequest: yFE multicasts to all RMs. zCoordination: yThe group communication system delivers request totally ordered. zExecution: yAll RM executes request. zAgreement: yNo. zResponse: yEach RM’s response is sent to FE. FE decides what to deliver to client.

19. 19 Fault tolerance – active replication (3/3) zSequential Consistency yThe totally ordered multicast executes requests in program order. zNot linearizable yTotal order does not maintain real-time order.

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