Replication Management

1. Replication Management

2. Motivations for Replication • Performance enhancement • Increased availability • Fault tolerance

3. General Requirements • Replication transparency • Consistency

4. An Architecture for Replication Management Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

5. Phases of Request Processing • Issuance: unicast or multicast (from the front end to replica managers) • Coordination • Execution • Agreement • Response * The ordering varies for different systems.

6. Services for Process Groups Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

7. View-Synchronous Group Communications Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

8. Sequential Consistency • The one-copy semantics of the replicated objects is respected. • The order of operations is preserved for each client.

9. The Primary-Backup Model Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

10. Active Replication Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

11. The Gossip Architecture • A framework for providing high availability of service through lazy replication • A request normally executed at one replica • Replicas updated by lazy exchange of gossip messages (containing most recent updates).

12. Operations in a Gossip Service Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

13. Timestamps • Each front end keeps a vector timestamp reflecting the latest version accessed. • The timestamp is attached to every request sent to a replica. • Two front ends may exchange messages directly; these messages also carry timestamps. • The merging of timestamps is done as usual.

14. Timestamps (cont’d) • Each replica keeps a replica timestamp representing those updates it has received. • It also keeps a value timestamp, reflecting the updates in the replicated value. • The replica timestamp is attached to the reply to an update, while the value timestamp is attached to the reply to a query.

15. Timestamp Propagations Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

16. The Update Log • Every update, when received by a replica, is recorded in the update log of the replica. • Two reasons for keeping a log: * The update cannot be applied yet; it is held back. * It is uncertain if the update has been received by all replicas. • The entries are sorted by timestamps.

17. The Executed Operation Table • The same update may arrive at a replica from a front end and in a gossip message from another replica. • To prevent an update from being applied twice, the replica keeps a list of identifiers of the updates that have been applied so far.

18. A Gossip Replica Manager Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

19. Processing Query Requests • A query request q carries a timestamp q.prev, reflecting the latest version of the value that the front end has seen. • Request q can be applied (i.e., it is stable) if q.prev valueTS (the value timestamp of the replica that received q). • Once q is applied, the replica returns the current valueTS along with the reply.

20. Processing Update Requests • For an update u (not a duplicate), replica i * increments the i-th element of its replica timestamp replicaTS by one, * adds an entry to the log with a timestamp ts derived from u.prev by replacing the i-th element with that of replicaTS, and * return ts to the front end immediately. • When the stability condition u.prev  valueTS holds, update u is applied and u.prev is merged with valueTS.

21. Processing Gossip Messages • For every gossip message received, a replica does the following: * Merge the arriving log with its own; duplicated updates are discarded. * Apply updates that have become stable. • A gossip message need not contain the entire log, if it is certain that some of the updates have been seen by the receiving replica.

22. Updates in Bayou Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

23. About Bayou • Consistency guarantees • Merging of updates • Dependency checks • Merge procedures

24. Coda vs. AFS • More general replication • Greater tolerance toward server crashes • Allowing disconnected operations

25. Transactions with Replicated Data • A replicated transactional service should appear the same as one without replicated data. • The effects of transactions performed by various clients on replicated data are the same as if they had been performed one at a time on single data items; this property is called one-copy serializability.

26. Transactions with Replicated Data (cont’d) • Failures should be serialized with respect to transactions. • Any failure observed by a transaction must appear to have happened before the transaction started.

27. Schemes for One-Copy Serializability • Read one/write all • Available copies replication • Schemes that also tolerate network partitioning: * available copies with validation * quorum consensus * virtual partition

28. Client + front end Client + front end U T deposit(B,3); getBalance(A) B Replica managers Replica managers A A B B B A Transactions on Replicated Data Source: Instructor’s guide for G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

29. Available Copies Replication • A client's read request on a logical data item may be performed by any available replica, but a client's update request must be performed by all available replicas. • A local validation procedure is required to ensure that any failure or recovery does not appear to happen during the progress of a transaction.

30. Client + front end T U Client + front end getBalance(B) deposit(A,3); getBalance(A) Replica managers deposit(B,3); B M Replica managers B B A A N P X Y Available Copies Replication (cont’d) Source: Instructor’s guide for G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

31. Network Partition Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

32. Available Copies with Validation • The available copies algorithm is applied within each partition. • When a partition is repaired, the possibly conflicting transactions that took place in the separate partitions are validated. • If the validation fails, some of the transactions have to be aborted.

33. Quorum Consensus Methods • One way to ensure consistency across different partitions is to make a rule that operations can only be carried out within one of the partitions. • A quorum is a subgroup of replicas whose size gives it the right to execute operations. • Version numbers or timestamps may be used to determine whether copies of the data item are up to date.

34. An Example for Quorum Consensus Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

35. Two Network Partitions Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

36. Virtual Partition Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

37. Overlapping Virtual Partitions Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

38. Creating Virtual Partitions Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.