Replication management
Download
1 / 38

Replication Management - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on
  • Presentation posted in: General

Replication Management. Motivations for Replication. Performance enhancement Increased availability Fault tolerance. General Requirements. Replication transparency Consistency. An Architecture for Replication Management.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

Replication Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Replication Management


Motivations for Replication

  • Performance enhancement

  • Increased availability

  • Fault tolerance


General Requirements

  • Replication transparency

  • Consistency


An Architecture for Replication Management

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


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.


Services for Process Groups

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


View-Synchronous Group Communications

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


Sequential Consistency

  • The one-copy semantics of the replicated objects is respected.

  • The order of operations is preserved for each client.


The Primary-Backup Model

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


Active Replication

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


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


Operations in a Gossip Service

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


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.


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.


Timestamp Propagations

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


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.


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.


A Gossip Replica Manager

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


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.


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.


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.


Updates in Bayou

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


About Bayou

  • Consistency guarantees

  • Merging of updates

  • Dependency checks

  • Merge procedures


Coda vs. AFS

  • More general replication

  • Greater tolerance toward server crashes

  • Allowing disconnected operations


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.


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.


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


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.


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.


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.


Network Partition

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


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.


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.


An Example for Quorum Consensus

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


Two Network Partitions

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


Virtual Partition

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


Overlapping Virtual Partitions

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


Creating Virtual Partitions

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


ad
  • Login