640 likes | 658 Views
Explore important issues in distributed systems to enhance reliability and performance through replication and consistency models, including strict consistency, linearizability, and weak consistency. Key focus on client-centric consistency and replica management.
E N D
Consistency and Replication Chapter 6 OS2 –2nd Semester, 94-95 Rasool Jalili
Replication • Important issue in DSs to enhance reliability and improve performance. • The major problem is how to make replicas consistent. • Much attention on consistency have been paid on consistency models of DSM systems by parallel computer designers. • Issue: • Client-Centric consistency • Implementation of replication and distribution of updates. • Models of consistency: Strong? How much? OS2 –2nd Semester, 94-95 Rasool Jalili
Object Replication (1) • Organization of a distributed remote object shared by two different clients. OS2 –2nd Semester, 94-95 Rasool Jalili
The first problem is how to handle concurrent accesses to the remote object by two clients. • 1- The object itself handles concurrent invocations • 2- The server is responsible for concurrency control and the object is unprotected. • The two scenarios in the next slide. OS2 –2nd Semester, 94-95 Rasool Jalili
Object Replication (2) • A remote object capable of handling concurrent invocations on its own. • A remote object for which an object adapter is required to handle concurrent invocations OS2 –2nd Semester, 94-95 Rasool Jalili
Object Replication (3) • A distributed system for replication-aware distributed objects. • A distributed system responsible for replica management OS2 –2nd Semester, 94-95 Rasool Jalili
Replication • Replication and Scaling Technology? • Consistency is against scalability! • Consistency Model is a contract between processes and the data store. OS2 –2nd Semester, 94-95 Rasool Jalili
Data-Centric Consistency Models • The general organization of a logical data store, physically distributed and replicated across multiple processes. OS2 –2nd Semester, 94-95 Rasool Jalili
Strict Consistency Any read on a data item X returns a value corresponding to the result of the most recent write on X • Behavior of two processes, operating on the same data item. • (a) A strictly consistent store. • (b) A store that is not strictly consistent. OS2 –2nd Semester, 94-95 Rasool Jalili
Linearizability and Sequential Consistency (1) • A sequentially consistent data store. • A data store that is not sequentially consistent. OS2 –2nd Semester, 94-95 Rasool Jalili
Linearizability and Sequential Consistency (2) • Three concurrently executing processes. OS2 –2nd Semester, 94-95 Rasool Jalili
Linearizability and Sequential Consistency (3) • Four valid execution sequences for the processes of the previous slide. The vertical axis is time. 000000 or 001001 are impossible. If a DSM do not produce some valid patterns!! OS2 –2nd Semester, 94-95 Rasool Jalili
Casual Consistency (1) • Necessary condition:Writes that are potentially casually related must be seen by all processes in the same order. Concurrent writes may be seen in a different order on different machines. OS2 –2nd Semester, 94-95 Rasool Jalili
Casual Consistency (2) • This sequence is allowed with a casually-consistent store, but not with sequentially or strictly consistent store. OS2 –2nd Semester, 94-95 Rasool Jalili
Casual Consistency (3) • A violation of a casually-consistent store. • A correct sequence of events in a casually-consistent store. OS2 –2nd Semester, 94-95 Rasool Jalili
FIFO Consistency (1) • Necessary Condition:Writes done by a single process are seen by all other processes in the order in which they were issued, but writes from different processes may be seen in a different order by different processes. OS2 –2nd Semester, 94-95 Rasool Jalili
FIFO Consistency (2) • A valid sequence of events of FIFO consistency OS2 –2nd Semester, 94-95 Rasool Jalili
FIFO Consistency (4) • Two concurrent processes. • Compare Sequential and FIFO consistency. OS2 –2nd Semester, 94-95 Rasool Jalili
Weak Consistency (1) Properties: • 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 performed. OS2 –2nd Semester, 94-95 Rasool Jalili
Weak Consistency (2) • A program fragment in which some variables may be kept in registers; a and b in registers, but when calling f, they should be synchronized. int a, b, c, d, e, x, y; /* variables */int *p, *q; /* pointers */int f( int *p, int *q); /* function prototype */ a = x * x; /* a stored in register */b = y * y; /* b as well */c = a*a*a + b*b + a * b; /* used later */d = a * a * c; /* used later */p = &a; /* p gets address of a */q = &b /* q gets address of b */e = f(p, q) /* function call */ OS2 –2nd Semester, 94-95 Rasool Jalili
Weak Consistency (3) • A valid sequence of events for weak consistency. • An invalid sequence for weak consistency. OS2 –2nd Semester, 94-95 Rasool Jalili
Release Consistency • Problem with Weak Consistency: Access to a synch variable might be because of finishing or starting of write operation on shared data items. in all cases, it should propagates all recent writes around the system. • A more efficient way is to separate entering and finishing of a critical region. • Acquire and Release. • The programmer is responsible to put them in its program • Similar to lock and unlock. OS2 –2nd Semester, 94-95 Rasool Jalili
Release Consistency (1) • A valid event sequence for release consistency. OS2 –2nd Semester, 94-95 Rasool Jalili
Release Consistency (2) Rules: • Before a read or write operation on shared data is performed, all previous acquires done by the process must have completed successfully. • Before a release is allowed to be performed, all previous reads and writes by the process must have completed • Accesses to synchronization variables are FIFO consistent (sequential consistency is not required). OS2 –2nd Semester, 94-95 Rasool Jalili
Lazy or Eager • Eager release consistency pushes the update on Release • Lazy release consistency does not do anything on release. The process doing Acquire after that, updates its copies. OS2 –2nd Semester, 94-95 Rasool Jalili
Entry Consistency (1) • A valid event sequence for entry consistency. OS2 –2nd Semester, 94-95 Rasool Jalili
Summary of Consistency Models • Consistency models not using synchronization operations. • Models with synchronization operations. OS2 –2nd Semester, 94-95 Rasool Jalili
Client-Centric Consistency • Previous discussion was concentrated on data items. • Assuming read operations are much more than concurrent writes:: so we need even weaker consistency • The level of concurrency and the level of requirement of being so consistent varies. The question is that: How fast updates should be made available to only-reading processes? • Example: DNS, Web pages? These are able to tolerate a high degree of inconsistency. • The base idea: If no updates take place for a long time, all replicas will gradually become consistent Eventual consistency. • Generally a small set of replicas do write and so write-write conflicts can be handled. OS2 –2nd Semester, 94-95 Rasool Jalili
Eventual Consistency The problem of having mobile clients moving around and connect to different replicas! Client-Centric Consistency. Guarantees consistency for a single client OS2 –2nd Semester, 94-95 Rasool Jalili
Client-Centric Consistency • Assume each client access its nearest replica and does its read and write • Updates are eventually propagated to the other copies. • We can simplify the issue by considering an owner for each data item who has the authority on the data item. • xi [t] means the version of x at Li at time t. • WS(xi [t]) denotes the set of writes on x. • 4 models of Client-Centric consistency as follows … OS2 –2nd Semester, 94-95 Rasool Jalili
Monotonic Reads (1) A data store is said to provide Monotonic Read consistency if: • When a process reads a data item x, successive read operations of the same process on x always returns the same value or a more recent value. • Example: Our mailbox, even when it is stored in a replicated and fully distributed around the world. OS2 –2nd Semester, 94-95 Rasool Jalili
Monotonic Reads The read operations performed by a single process P at two different local copies of the same data store. • A monotonic-read consistent data store • A data store that does not provide monotonic reads. OS2 –2nd Semester, 94-95 Rasool Jalili
Monotonic Writes(1) • A write operation by a process on a data item x is completed before any successive write on x by the same process, no matter where the operation was initiated. • Similar to the concept of FIFO consistency on data-centric approaches, but here we are restricted to a single process, not all concurrent processes. • Ex: software library update OS2 –2nd Semester, 94-95 Rasool Jalili
Monotonic Writes • The write operations performed by a single process P at two different local copies of the same data store • A monotonic-write consistent data store. • A data store that does not provide monotonic-write consistency. OS2 –2nd Semester, 94-95 Rasool Jalili
Read Your Writes • The effect of a write operation by a process on data item x will always be seen by a successive read op on x by the same process. • Ex: Updating web page and seeing that ! OS2 –2nd Semester, 94-95 Rasool Jalili
Read Your Writes • A data store that provides read-your-writes consistency. • A data store that does not. OS2 –2nd Semester, 94-95 Rasool Jalili
Writes Follow Reads • A write operation by a process on a data item x following a previous read on x by the same process, is guaranteed to take place on the same or a more recent value of x that was read. • Ex: Posting of a reaction on an article in newsgroups after seeing the original article. OS2 –2nd Semester, 94-95 Rasool Jalili
Writes Follow Reads • A writes-follow-reads consistent data store • A data store that does not provide writes-follow-reads consistency OS2 –2nd Semester, 94-95 Rasool Jalili
Replicas • Permanent replicas; number of them is limited. Mirroring is a form of permanent replicas • Server initiated replicas • Client-initiated replicas. OS2 –2nd Semester, 94-95 Rasool Jalili
Replica Placement • The logical organization of different kinds of copies of a data store into three concentric rings. OS2 –2nd Semester, 94-95 Rasool Jalili
Server initiated replicas • Copies of data store exist to enhance performance; created at the initiative of the owner of the data store due to a burst traffic :: Push cache. • Where and when replicas should be created and deleted? • An approach to dynamically replicate files , designed for web-hosting :: updates are rare compare to read ops. OS2 –2nd Semester, 94-95 Rasool Jalili
Two issues: • Replication for reduction of load on a server • Migration or replication of specific files to the server closer to the clients who issue many requests to those files. • Each server keeps track of access counts per file and the location of the access. Each server can determine which server is closest to a given client C. • When the number of req for a file at server S drops below a deletion threshold, it can be removed from S. • Two thresholds: del (S, F), and rep (S, F) OS2 –2nd Semester, 94-95 Rasool Jalili
Server-Initiated Replicas • Counting access requests from different clients. OS2 –2nd Semester, 94-95 Rasool Jalili
Client-initiated replicas • Created at the initiative of clients • Known as (client) caches. • Cache hit • Period of keeping data on caches OS2 –2nd Semester, 94-95 Rasool Jalili
Update Propagation • Update normally initiated at the client side and subsequently forwarded to one of the copies. update should be propagated toward other copies whilst maintaining consistency. • Issues: • What should be propagated: State or operations? • Only a notification of an update :: invalidation • Transfer data from one copy to another. • Propagate the update op to other copies. • Push updates or pull them? OS2 –2nd Semester, 94-95 Rasool Jalili
Pull versus Push Protocols A comparison between push-based and pull-based protocols in the case of multiple client (each having their own cache), single server systems. OS2 –2nd Semester, 94-95 Rasool Jalili
Consistency Protocols • So far, we concentrated on consistency models. • A consistency protocol describes an implementation of a specific consistency model. • Primary-Based protocols • Client-server: all RW ops from a server (distributed or centralized) • Primary-Backup protocols (Write operations toward the primary) OS2 –2nd Semester, 94-95 Rasool Jalili
Remote-Write Protocols (1) Primary-based remote-write protocol with a fixed server to which all read and write operations are forwarded. OS2 –2nd Semester, 94-95 Rasool Jalili
Remote-Write Protocols (2) • The principle of primary-backup protocol. OS2 –2nd Semester, 94-95 Rasool Jalili
Local-Write Protocols • Two kinds • Only a single copy of each item exists: No replicas • For each operation, a copy the data item is transferred to the process and the operation is done. • Overhead of maintaining who is where! • A variant is a primary-backup protocol in which the primary migrates between processes. OS2 –2nd Semester, 94-95 Rasool Jalili