DC_M5_L2_Data Centric Consistency (1).pdf
- 1. Distributed Computing(DC) Chapter 5 Replication, Consistency and Fault Tolerance By Dr. Nita S. Patil Computer Department Datta Meghe College of Engineering, Airoli * Dr. Nita Patil 1
- 2. Contents ❑ 5.1 Distributed Shared Memory: ⚫ Architecture, ⚫ design issues. ❑ 5.2 Introduction to replication and consistency,: ⚫ Data-Centric and ⚫ Client-Centric Consistency Models, ⚫ Replica Management. ❑ 5.3 Fault Tolerance: ⚫ Introduction, Process resilience, ⚫ Recovery. 27-Feb-23 DC Dr. Nita Patil 2
- 3. CO Covered ❑ CO5 : Demonstrate the concepts of Consistency, Replication Management and fault Tolerance. 27-Feb-23 DC Dr. Nita Patil 3
- 4. Data-Centric Consistency Models ❑ A consistency model is a contract between a DS data-store and its processes ❑ Since it is difficult to define precisely which write operation is the last one ❑ If the processes agree to the rules, the data- store will perform properly and as advertised
- 5. Data-Centric Consistency Models A data-store can be read from or written to by any process in a DS. A local copy of the data-store (replica) can support “fast reads”. However, a write to a local replica needs to be propagated to all remote replicas.
- 6. Data-Centric Consistency Models Strict consistency Linearizability & Sequential consistency Causal consistency FIFO consistency Weak consistency Release consistency Entry consistency
- 7. Strict Consistency Any read on a data item x returns a value corresponding to the result of the most recent write on x. (regardless of where the write occurred). Most stringent consistency “Most recent” must be unambiguous Problem: relies on absolute global time But Impossible to implement in a DS
- 8. Strict Consistency Diagrams the same data item: Behavior of two processes, operating on (a) A strictly consistent data-store. (b) A data-store that is not strictly consistent. • Consistency Model Diagram Notation • Wi(x)a – a write by process i to item x with a value of a. • Ri(x)b – a read by process i from item x producing the value b.
- 9. Sequential Consistency Any valid interleaving of read and write operations is acceptable and all processes see the same interleaving of operations Nothing about time Weaker than strict consistency
- 10. Sequential Consistency Diagrams • • a) A sequentially consistent data-store P3 and P4 sees the same interleaving of write operations by P1 and P2 (see P2 first and then P1) b) A data-store that is not sequentially consistent P3 and P4 do not see the same interleaving of write operations by P1 and P2
- 11. Sequential Consistency Example (Cont.) There are 4 (actually more) valid sequences The contract between processes and the distributed shared data store The DS guarantee sequential consistency The process must accept all of these sequences as valid results Problem with sequential consistency It is proven that r+w >= t r: read time, w: write time, t: minimal packet transfer time between nodes Adjust the protocol to favour reads could cause impact on write performance
- 12. Linearizability Linearizability All processes see the same sequential order of operations The operations of each individual process appear in this sequence follows the order specified by its program If timestamp(OP1) < timestamp(OP2), OP1 should proceed OP2 in the sequence i.e., sequential consistency + timestamp each operation Weaker than strict consistency but stronger than sequential consistency Linearizability consistency is also sequential consistency But take ordering according to a set of synchronized clocks into account
- 13. Causal Consistency This model distinguishes between events that are causally related and those that are not. If event B is caused or influenced by an earlier event A, Causal consistency requires that every other process see event A, then event B. Operations that are not causally related are said to be concurrent.
- 14. Causal Consistency (Cont.) Causal Consistency Writes that are potentially causally related must be seen by all processes in the same order Concurrent events may be seen in a different order on different machine Implementation: construct and maintain a dependency graph Keep with operation is dependent on which operation Use vector timestamp in previous section Mention later
- 15. Example1 This sequence is allowed with a causally-consistent store, but not with sequentially or strictly consistent store. Note: it is assumed that W2(x)b and W1(x)c are concurrent.
- 16. Example2 a) Violation of causal-consistency – assume W2(x)b is related to W1(x)a (all processes should see them in the same order). b) A causally-consistent data-store: assume the two writes are now concurrent. The reads by P3 and P4 are now OK. P3 and P4 see different order (x)
- 17. FIFO Consistency ❏ Writes done by a single process are seen by all other processes in the order in which they were issued ❏ But writes form different processes may be seen in a different order by different processes ❏ Easy to implement. Tag each write operation with a (process, sequence number) pair
- 18. Example1 A valid sequence of FIFO consistency events.
- 19. Weak Consistency ❏ Cope with synchronization variable ❏ Used to synchronize all local copies of the data store ❏ Three properties of weak consistency ❏ Accesses to synchronization variables associated with a data store are sequentially consistent ❏ No operation on a synchronization variable is allowed to be performed until all previous writes have been completed everywhere ❏ No read or write operation on data items are allowed to be performed until all previous operations to synchronization variables have been
- 20. Weak Consistency: What It Means So … 1st point: all processes see all operations on synchronization variables in the same order If P1 calls syn.(S1) and P2 calls syn.(S2), all processes see either “sync.(P1)sync.(P2)” or “sync.(P2)sync.(P1)” 2nd point: sync. flushes the pineline All previous writes are guaranteed to be done as well when the synchronization is done 3rdpoint: when data item are accessed (read or write), all previous synchronization will have been completed
- 21. Weak Consistency (Cont.) ❏ Enforce consistency on a group of operations ❏ Suitable when most accesses coming in clusters ❏ Limit only the time when consistency holds ❏ When we issue an synch. variable
- 22. Example 1 Like memory management The value of a variable may be temporary put in register and updated in register Result in a inconsistent memory Only when some events occur, the memory will then be kept consistent with register
- 23. Example 2 a) A valid sequence of events for weak consistency. This is because P2 and P3 have not yet synchronize, so there’s no guarantees about the value in ‘x’. b) An invalid sequence for weak consistency. P2 has synchronized, so it cannot read ‘a’ from ‘x’ – it should be getting
- 24. Release Consistency Problem of weak consistency: when synch., we have no idea Either the process is finished writing the shared data (exit critical section) Or the process is about to start reading (enter critical section)
- 25. Release Consistency (Cont.) As a result, when issues synch., weak consistency must guarantee All locally initiated writes have been completed that are propagated to all other copies Gather in all writes from other copies However, more efficient if we can tell the difference between in entering a C. S. or leaving one
- 26. Release Consistency (Cont.) Sol. two sync variables can be used acquire and release Leads to the release consistency model. When acquire, Ensure that all the local copies of the protected data are brought up to date When release Protected data that have been changed are propagated out to all local copies Protected data Shared data that are kept consistent Thus, before release, all write and read take place on its local cache
- 27. Example A valid event sequence for release consistency. P3 has not performed an acquire, so there are no guarantees that the read of ‘x’ is consistent. P2 does perform an acquire, so its read of ‘x’ is consistent. Even if Acq(L) in P2 before Rel(L) in P1, just delay until the release had occurred
- 28. Release Consistency Rules A distributed data-store is release consistent if it obeys the following rules 1. Before a read or write operation on shared data is performed, all previous acquires done by the process must have completed successfully. 2. Before a release is allowed to be performed, all previous reads and writes by the process must have completed. 3. Accesses to synchronization variables are FIFO consistent.
- 29. Release Consistency When a release is done Push out all the modified data to other processes that have a copy of the data All of these processes get everything that has changed But, if they actually will need it? Sol. Lazy release consistency The normal release consistency can be called eager release consistency
- 30. Lazy Release Consistency At the time of release, nothing is sent anywhere When an acquire is done Then try to get the most recent of data from the process holding the data How to guarantee the most recent=> timestamp
- 31. Entry Consistency Similar to release consistency Use acquire and release at the start and end of each critical section However, unlike to release consistency Each ordinary shared data item is associated with a synchronization variable E.g., elements of an array are associated with different synch. variable Increase the amount of parallelism
- 32. Entry Consistency Rules ❏ An acquire access of a synchronization variable is not allowed to perform with respect to a process until all updates to the guarded shared data have been performed with respect to that process. ❏ Before an exclusive mode access to a synchronization variable by a process is allowed to perform with respect to that process, no other process may hold the synchronization variable, not even in nonexclusive mode. ❏ After an exclusive mode access to a synchronization variable has been performed, any other process's next nonexclusive mode access to that synchronization variable may not be performed until it has performed with respect to that variable's owner.
- 33. Entry Consistency Rules (Cont.) So … 1st point: an acquire may not complete until all guarded shared data are up to date 2nd point: before updating a shared data item A process must enter a C. S. in exclusive mode To make sure that no other process is trying to update it at the same time 3rd point: if a process wants to enter a C.S. in nonexclusive mode Check the owner of the synch. variable to fetch the most recent copies of the guarded shared data
- 34. Example Locks associate with individual data items, as opposed to the entire data-store. Note: P2’s read on ‘y’ may return NIL as no locks have been requested. A valid event sequence for entry consistency.
- 35. Summary of Consistency Models (b) Models that do use synchronization operations. Consistency Description Weak Shared data can be counted on to be consistent only after a synchronization is done. Release Shared data are made consistent when a critical region is exited. Entry Shared data pertaining to a critical region are made consistent when a critical region is entered. (a) Consistency models that do not use synchronization operations Consistency Description Strict Absolute time ordering of all shared accesses matters. Linearizability All processes must see all shared accesses in the same order. Accesses are furthermore ordered according to a (nonunique) global timestamp. Sequential All processes see all shared accesses in the same order. Accesses are not ordered in time. Causal All processes see causally-related shared accesses in the same order. FIFO All processes see writes from each other in the order they were used. Writes from different processes may not always be seen in that order.