Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007...

DISTRIBUTED SYSTEMSPrinciples and Paradigms

Second EditionANDREW S. TANENBAUM

MAARTEN VAN STEEN

Chapter 7Consistency And Replication

Reasons for Replication

• Data are replicated to increase the reliability of a system.

• Replication for performance Scaling in numbers Scaling in geographical area

Caveat Gain in performance Cost of increased bandwidth for maintaining

replication

Replication

Synchronous replication• A read operation returns the same results on every

copy;• Write operations are atomic: they are propagated on all

nodes before other operations can happen.

To improve synchronization the consistency constraints can be “relaxed”.

Data-centric Consistency Models

Figure 7-1. The general organization of a logical data store, physically distributed and replicated across multiple processes.

Consistency model

Consistency model • A “Contract” between processes and data store

Continuous consistency measure deviations in replicas:• numerical value: absolute/relative;• staleness: last time the replica was updated;• ordering of update operations.

Consistency unit

Conit: measure of inconsistency.

Continuous Consistency (1)

Figure 7-2. An example of keeping track of consistency deviations [adapted from (Yu and Vahdat, 2002)].

Figure 7-3. Choosing the appropriate granularity for a conit. (a) Two updates lead to update propagation.

Figure 7-3. Choosing the appropriate granularity for a conit. (b) No update propagation is needed (yet).

Sequential Consistency (1)

Figure 7-4. Behavior of two processes operating on the same data item. The horizontal axis is time.

A data store is sequentially consistent when:

The result of any execution is the same as if the (read and write) operations by all processes on the data store …

• were executed in some sequential order and …

• the operations of each individual process appear … in this sequence in the order specified by its program.

Figure 7-5. (a) A sequentially consistent data store. (b) A data store that is not sequentially consistent.

Figure 7-6. Three concurrently-executing processes.6!=720 possible execution sequences

Figure 7-7. Four valid execution sequences for the processes of Fig. 7-6. The vertical axis is time.

Examples of not valid sequences• 000000:

– statements must be executed in program order;

• 001001: – 00: y=z=0 both statements of P1 executed;

– 10: P2 must run after P1 starts;

– 01: P3 complete before P1 starts.

Causal Consistency (1)

For a data store to be considered causally consistent, it is necessary that the store obeys the following condition:

Writes that are potentially causally related …• must be seen by all processes• in the same order.

Concurrent writes …• may be seen in a different order • on different machines.

Figure 7-8. This sequence is allowed with a causally-consistent store, but not with a sequentially consistent store.

W1(x)c and W2(x)b are concurrent

Figure 7-9. (a) A violation of a causally-consistent store.

Figure 7-9. (b) A correct sequence of events in a causally-consistent store.

Note: this is not acceptable in sequentially consistency

Critical sections

Mutual exclusion, transactions

Use synchronization variables:• Acquire when enter in section• Release when leave the section

Solution to Critical-Section Problem1. Mutual Exclusion - If process Pi is executing in its critical section, then

no other processes can be executing in their critical sections

2. Progress - If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely

3. Bounded Waiting - A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is grantedAssume that each process executes at a nonzero speed No assumption concerning relative speed of the N processes

Grouping Operations (1)

Necessary criteria for correct synchronization:• An acquire access of a synchronization variable, not

allowed to perform until all updates to guarded shared data have been performed with respect to that process.

The acquire may not complete until the guarded shared data are up to date. All remote changes must be made visible.

• Before exclusive mode access to synchronization variable by process is allowed to perform with respect to that process, no other process may hold synchronization variable, not even in nonexclusive mode.

Before update shared data a process must enter in critical sections in exclusive mode to be sure no other processes can update the data at the same time.

• After exclusive mode access to synchronization variable has been performed, any other process’ next nonexclusive mode access to that synchronization variable may not be performed until it has performed with respect to that variable’s owner.

If a process wants to enter in a critical region in nonexclusive mode, it must first check with the owner of synchronization variables to fetch the most recent copies of shared data.

Figure 7-10. A valid event sequence for entry consistency.

Consistency and Coherence

Consistency model• what can be expected when a set of concurrent

processes operate on data. (Read and write operations on a set of data items)

Coherence model• what can be expected on a single data item.

(sequential consistency on a single data item).

Eventual consistency

Most application can tolerate a high degree of inconsistency.

If no update take place for a long time all replicas will gradually become consistent.

Es. DNS, web-pages

• updates are guaranteed to propagate to all replicas;• write-write conflicts are solved assuming that only few

processes can update data

Client-Centric Consistency

Figure 7-11. The principle of a mobile user accessing different replicas of a distributed database.

Client centric consistencyConsistency for a single client

NO guarantee of consistency for concurrent accesses of different client

Monotonic Reads (1)

A data store is said to provide monotonic-read consistency if the following condition holds:

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.

Ex. distributed email database

Monotonic Reads (2)

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.

Insieme delle operazioni su x1 e x2

Monotonic Reads (3)

Figure 7-12. The read operations performed by a single process P at two different local copies of the same data store.

(b) A data store that does not provide monotonic reads.

Monotonic Writes (1)

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.

A write operation by a process on a copy of item x is performed only if that copy is update by means of any preceding write operation on other copies of x

FIFO consistency.

Ex. Update systems: to apply an update all previous updates have to be applied.

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.

Figure 7-13. The write operations performed by a single process P at two different local copies of the same data store. (b) A data

store that does not provide monotonic-write consistency.

Read Your Writes (1)

A data store is said to provide read-your-writes consistency, if the following condition holds:

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.

Figure 7-14. (b) A data store that does not.

Writes Follow Reads (1)

A data store is said to provide writes-follow-reads consistency, if the following holds:

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.

Figure 7-15. (b) A data store that does not provide writes-follow-reads consistency.

Replica-Server Placement

Replica servers• scegliere il miglior posto per posizionare un server

Content• Scegliere il miglior server per inserire i contenuti

Replica-Server Placement

Figure 7-16. Choosing a proper cell size for server placement.

Content Replication and Placement

Figure 7-17. The logical organization of different kinds of copies of a data store into three concentric rings.

Content Replication and PlacementEs. siti web:• Cluster web server• Mirroring

Server-Initiated Replicas

Figure 7-18. Counting access requests from different clients.

Server-Initiated Replicas

• Conteggio degli accessi per capire quando replicare o cancellare le repliche;

• Meccanismi per garantire che almeno una copia sopravviva.

State versus Operations

Possibilities for what is to be propagated:

1. Propagate only a notification of an update (invalidation protocols).

2. Transfer data from one copy to another.

3. Propagate the update operation to other copies (active replication).

Pull versus Push ProtocolsPush• Protocolli Server-based• Le modifiche sono propagate senza che le repliche lo

richiedano• Alto grado di consistenza

Pull• Protocolli client-based• Le modifiche sono propagate solo quando richieste da

chi le deve usare

Pull versus Push Protocols

Figure 7-19. A comparison between push-based and pull-based protocols in the case of multiple-client, single-server systems.

Push temporaneo:• Un client richiede update automatici per un tempo

limitato• Scaduto il periodo si usano protocolli pull, o si richiede

un nuovo lease

Protocolli di consistenza

Implementazione di un modello di consistenza.

Primary-based protocols• Usati per la consistenza sequenziale• Ogni item ha una replica primaria• Tutte le scritture sono applicate e coordinate dalla

copia primaria

Replication-based• Le operazioni possono essere eseguite su una replica

qualsiasi.

Remote-Write Protocols

Figure 7-20. The principle of a primary-backup protocol.

Local-Write Protocols

Figure 7-21. Primary-backup protocol in which the primary migrates to the process wanting to perform an update.

Replicated-write protocols

• No single primary copy• Writes can be performed at multiple replicas• Two types:

– Active Replication: All operations are forwarded to all replicas

– Quorum-based: Operations are forwarded to a subset of all replicas

Active replication

• All operations are propagated to all replicas• More complex to achieve consistency• Need to order operations

– Use Lamport timestamps

– Central sequencer

Quorum-Based Protocols• Operations are sent to a subset of replicas• Maintaining consistency• Use voting

– If a quorum (e.g.: majority) agrees, then, consistency is maintained

– Write: Apply write only if majority of replicas agree on the update

– Read: Perform read only if majority of replicas agree on the current data value

Quorum-Based Protocols

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

Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007...

Documents

New Distributed File Systems: Concepts and Examplesdcslab.snu.ac.kr/courses/dip2016f/Papers/_Levy90.pdf · 2019. 3. 16. · Distributed File Systems l 323 the survey paper by Tanenbaum

Distributed Systems: Principles and Paradigms S... · 2019. 6. 17. · Tanenbaum. Andrew S. Distributed systems: principles and paradigms I Andrew S. Tanenbaum, Maarten Van Steen

Datalinklayer tanenbaum

Distributed Operating Systems 66464 Fall 2013 Luai Malhis, Ph.D Required Textbook: Distributed Systems: Principles and Paradigms Andrew S. Tanenbaum and

TANENBAUM CENTER FOR INTERRELIGIOUS …...TANENBAUM CENTER FOR INTERRELIGIOUS UNDERSTANDING • ISSUE 21 • SPRING 2013 ... The TANENBAUM / Center for Interreligious Understanding

Distributed Systems (3rd Edition) Maarten van Steen and ... · Distributed Systems (3rd Edition) Maarten van Steen and Tanenbaum Edited by Ghada Ahmed, PhD ... Immediately ﬂushing

Network layer tanenbaum

May 15th, 20021 505 review – distributed systems and security (slides mostly from Tanenbaum) Jonathan M. Smith University of Pennsylvania posse

A Security Architecture for Object-Based Distributed Systems · A Security Architecture for Object-Based Distributed Systems Bogdan Popescu Maarten van Steen Andrew S. Tanenbaum Vrije

Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN …teaching.yfolajimi.com/uploads/3/5/6/9/3569427/_chap-02v... · 2020. 3. 19. · Tanenbaum & Van Steen, Distributed Systems:

Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 DISTRIBUTED SYSTEMS

Distributed Systems 1 Introduction - Os · Recommended Reading Andrew S. Tanenbaum, Maarten van Steen: “Distributed Systems: Principles and Paradigms”, Prentice-Hall, 2nd Edition,

Sistemas Distribuidos Introducción. Generalidades Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc

Tanenbaum Solutions

A S Tanenbaum - Distributed Operating SystemsOperating Systems

Chorus Distributed OS ppt - Tanenbaum

Chapter 10 DISTRIBUTED OBJECT-BASED SYSTEMSresearch.iaun.ac.ir/pd/faramarz_safiold/pdfs/HomeWork_3403.pdf · Introduction Tanenbaum & Van Steen, Distributed Systems: Principles and

Tanenbaum Slides 5

Distributed Systems Tanenbaum Chapter 2

Distributed Systems (3rd Edition) Maarten van …...Distributed Systems (3rd Edition) Maarten van Steen and Tanenbaum Edited by Ghada Ahmed, PhD Fall 2017 Security: Introduction to