7 3 ClientCentric Consistency Models Eventual Consistency Figure

  • Slides: 23
Download presentation
7. 3 Client-Centric Consistency Models Eventual Consistency Figure 7 -11. The principle of a

7. 3 Client-Centric Consistency Models Eventual Consistency Figure 7 -11. The principle of a mobile user accessing different replicas of a distributed database. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5 1

Client-Centric Consistency Client-centric consistency provides guarantees for a single client concerning the consistency of

Client-Centric Consistency Client-centric consistency provides guarantees for a single client concerning the consistency of accesses to a data store by that client. • • Monotonic reads Monotonic writes Read-your-writes Write-follows-reads • Notation: WS(xi[t]) is the set of write operations (at Li) that lead to version xi of x (at time t); WS(xi[t 1]; xj[t 2]) where t 1 < t 2 indicates that it is known that WS(xi[t 1]) is part of WS(xj[t 2]). 2 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Monotonic Reads A data store is said to provide monotonic-read consistency: If a process

Monotonic Reads A data store is said to provide monotonic-read consistency: If a process reads the value of a data item x any successive read operation on x by that process will always return that same value or a more recent value. Figure 7 -12. The read operations performed by a single process P at two different local copies of the same data store. (a) A monotonic -read consistent data store. (b) A data store that does not provide monotonic reads. 3 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Monotonic Writes In a monotonic-write consistent store, the following condition holds: A write operation

Monotonic Writes In a monotonic-write consistent store, the following condition holds: A write operation by a process on a data item x is completed before any successive write operation on x by the same process. Figure 7 -13. The write operations performed by a single process P at two different local copies of the same data store. (a) A monotonic-write consistent data store. (b) A data store that does not provide monotonic-write consistency. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5 4

Read Your Writes A data store is said to provide read-your-writes consistency, if :

Read Your Writes A data store is said to provide read-your-writes consistency, if : The effect of a write operation by a process on data item x will always be seen by a successive read operation on x by the same process. Figure 7 -14. (a) A data store that provides read-your-writes consistency. (b) A data store that does not. 5 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Writes Follow Reads A data store is said to provide writes-follow-reads consistency, if :

Writes Follow Reads A data store is said to provide writes-follow-reads consistency, if : A write operation by a process on a data item x following a previous read operation on x by the same process is guaranteed to take place on the same or a more recent value of x that was read. Figure 7 -15. (a) A writes-follow-reads consistent data store. 6 (b) A data store that does not. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

7. 4 Replica Management • Replica server placement • Content replication and placement •

7. 4 Replica Management • Replica server placement • Content replication and placement • Content distribution 7 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replica-Server Placement Essence: Figure out what the best K places are out of N

Replica-Server Placement Essence: Figure out what the best K places are out of N possible locations. • Select best location out of N −K for which the average distance to clients is minimal. Then choose the next best server. (Note: The first chosen location minimizes the average distance to all clients. ) Computationally expensive. • Select the K-th largest autonomous system and place a server at the best-connected host. Computationally expensive. • Position nodes in a d-dimensional geometric space, where distance reflects latency. Identify the K regions with highest density and place a server in every one. Computationally cheap. 8 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replica-Server Placement Figure 7 -16. Choosing a proper cell size for server placement. 9

Replica-Server Placement Figure 7 -16. Choosing a proper cell size for server placement. 9 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Content Replication and Placement Model: We consider objects (and don’t worry whether they contain

Content Replication and Placement Model: We consider objects (and don’t worry whether they contain just data or code, or both) Distinguish different processes: A process is capable of hosting a replica of an object or data: • Permanent replicas: Process/machine always having a replica • Server-initiated replica: Process that can dynamically host a replica on request of another server in the data store • Client-initiated replica: Process that can dynamically host a replica on request of a client (client cache) 10 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Content Replication and Placement Figure 7 -17. The logical organization of different kinds of

Content Replication and Placement Figure 7 -17. The logical organization of different kinds of copies of a data store into three concentric rings. 11 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Server-Initiated Replicas • Keep track of access counts per file, aggregated by considering server

Server-Initiated Replicas • Keep track of access counts per file, aggregated by considering server closest to requesting clients • Number of accesses drops below threshold D ⇒ drop file • Number of accesses exceeds threshold R ⇒ replicate file • Number of access between D and R ⇒ migrate file Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5 12

Content Distribution Model: Consider only a client-server combination: Possibilities for what is to be

Content Distribution Model: Consider only a client-server combination: Possibilities for what is to be propagated: 1. Propagate only a notification of an update. 2. Transfer data from one copy to another. 3. Propagate the update operation to other copies. Observation: No single approach is the best, but depends highly on available bandwidth and readto-write ratio at replicas. 13 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Pull versus Push Protocols • Pushing updates: server-initiated approach, in which update is propagated

Pull versus Push Protocols • Pushing updates: server-initiated approach, in which update is propagated regardless whether target asked for it. • Pulling updates: client-initiated approach, in which client requests to be updated. Figure 7 -19. A comparison between push-based and pull-based protocols in the case of multiple-client, single-server systems. 14 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Pull versus Push Protocols Issue: Make lease expiration time dependent on system’s behavior (adaptive

Pull versus Push Protocols Issue: Make lease expiration time dependent on system’s behavior (adaptive leases): • Age-based leases: An object that hasn’t changed for a long time, will not change in the near future, so provide a long-lasting lease • Renewal-frequency based leases: The more often a client requests a specific object, the longer the expiration time for that client (for that object) will be • State-based leases: The more loaded a server is, the shorter the expiration times become 15 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

7. 5 Consistency Protocols Consistency protocol: describes the implementation of a specific consistency model.

7. 5 Consistency Protocols Consistency protocol: describes the implementation of a specific consistency model. • Continuous consistency • Primary-based protocols • Replicated-write protocols 16 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Continuous Consistency Principle: consider a data item x and let weight(W) denote the numerical

Continuous Consistency Principle: consider a data item x and let weight(W) denote the numerical change in its value after a write operation W. Assume that ∀W : weight(W) > 0. W is initially forwarded to one of the N replicas, denoted as origin(W). TW[i, j] are the writes executed by server Si that originated from Sj: 17 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Continuous Consistency Problem: We need to ensure that v(t) − vi < δi for

Continuous Consistency Problem: We need to ensure that v(t) − vi < δi for every server Si. Approach: Let every server Sk maintain a view TWk[i, j] of what it believes is the value of TW[i, j]. This information can be gossiped when an update is propagated. Note: 0 ≤ TWk[i, j] ≤ TW[j, j] Solution: Sk sends operations from its log to Si when it sees that TWk[i, k] is getting too far from TW[k, k], in particular, when TW[k, k] − TWk[i, k] > δi /(N − 1). Note: Staleness can be done analogously, by essentially keeping track of what has been seen last from Si (see book). The ordering deviations could be bounded by specifying the maximal length of 18 the queue of tentative writes. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Primary-Based Protocols Primary-backup Protoco Example: Traditionally applied in distributed databases and file systems that

Primary-Based Protocols Primary-backup Protoco Example: Traditionally applied in distributed databases and file systems that require a high degree of fault tolerance. Replicas are often placed on same LAN. 19 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Primary-Based Protocols Local-Write Protocols Example: Mobile computing in disconnected mode (ship all relevant files

Primary-Based Protocols Local-Write Protocols Example: Mobile computing in disconnected mode (ship all relevant files to user before disconnecting, and update later on). 20 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replicated-Write Protocols Quorum-based protocols: Ensure that each operation is carried out in such a

Replicated-Write Protocols Quorum-based protocols: Ensure that each operation is carried out in such a way that a majority vote is established: distinguish read quorum and write quorum: Figure 7 -22. Three examples of the voting algorithm. (a) A correct choice of read and write set. (b) A choice that may lead to write-write conflicts. (c) A correct choice, known as ROWA (read one, write 21 all). Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Cache Coherence Protocols • Coherence Detection Strategy – Distributed Database • Pessimistic • Optimistic

Cache Coherence Protocols • Coherence Detection Strategy – Distributed Database • Pessimistic • Optimistic • When the transaction commits Coherence Enforcement Strategy • – – Shared data When a process modifies cached data • • • Update only by servers Write-through Write-back 22 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Implementing Client-Centric Consistency • A naïve Implementation – • Assign a globally unique identifier

Implementing Client-Centric Consistency • A naïve Implementation – • Assign a globally unique identifier to each write operation Improved Efficiency – Vector timestamps 23 Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5