Download Distributed Software Develop - Replication - Lecture Slides | CS 682 and more Study notes Software Engineering in PDF only on Docsity!
Distributed Software Development
Replication
Chris Brooks Department of Computer Science University of San Francisco ?? Department of Computer Science — University of San Francisco – p.1/
Previously on cs682: Causal 12-0:
delivery
, then)^2 m( send → )^1 m( send says that if causal delivery when different processes are sending )^2 m( → )^1 m( deliver
.^2 m and^1 m Logical clocks aren’t enough to give us causal delivery. ?? Department of Computer Science — University of San Francisco – p.2/
Previously on cs682: Vector 12-1:
clocks
Solution: keep a “logical clock” for each process.
. V C these are stored in a vector Assumes number of processes in known and fixed. Update rule: for send and internal. ] + 1i[ V C ] =i)[e( V C for receive; then ))m( V C, T S( max ) =e( V C ] + 1i[ V C ] =i)[e( V C On receive, the vector clock takes the max on a component-by-component basis, then updates the local clock. ?? Department of Computer Science — University of San Francisco – p.3/
Previously on cs682: Vector 12-2:
Clock example
(^1) p (^2) p (^3) p (1,0,0) (0,1,0) (0,0,1) (2,1,0) (1,0,2)(1,0,3) (1,0,4) (3,1,3) (1,2,4) (4,1,3) (4,3,4) (5,1,6) (1,0,5) (6,1,3) (5,1,3) ?? Department of Computer Science — University of San Francisco – p.4/
Previously on cs682: 12-3:
Consensus
If we don’t have reliable communication, consensus is impossible, even without failures. With reliable communication, we can solve consensus for crash failures. In asynchronous systems, it is impossible to guarantee that we will reach consensus, even in the presence of a single crash failure. This means that we can’t do: Asynchronous Byzantine generals Asynchronous totally ordered multicast
Replication 12-4:
Replication is the maintenance of copies of data at multiple computers. Enhances a service by providing: Fault tolerance Improved performance Increased availability Information redundance
Why is replication useful? 12-5:
Increased performance. By moving data closer to a client, latency is reduced. Web caching, proxy servers are an example of this. Performance is improved most effectively with immutable data. If the client is going to change the data and send it back, performance gains are reduced. ?? Department of Computer Science — University of San Francisco – p.7/
Why is replication useful? 12-6:
Increased availability. Many services need to be highly available Replication provides a way of overcoming server failures. , then we canp If a server will fail with probability determine how many servers are needed to provide a given level of service: np^ −^ = 1^ Avail For example, if a server has a 5% chance of failure over a given time period, and we want 99.9% availability, we need at least 4 replicas. ?? Department of Computer Science — University of San Francisco – p.8/
Client-side replication 12-7:
Note that replication is not limited to servers. Multiple clients may need to replicate data. Shared code or documents being edited. Meeting scheduling Conferencing or whiteboard software. ?? Department of Computer Science — University of San Francisco – p.9/
Fault tolerance 12-8:
Highly available data may not be correct data. For example, in the presence of network outages. Fault tolerance guarantees correct behavior in the presence of a given number of faults. Similar to availability, but a coordination element is also required. We may also want to ensure against corruption of data. ?? Department of Computer Science — University of San Francisco – p.10/
Outline 12-9:
Passive Replication What problems must be solved for this? Active Replication What problems must be solved for this? Lazy Replication What problems must be solved for this?
Client Requirements 12-10:
Single logical copy. Multiple physical copies. Consistency The details of this will depend on the application.
Group Communication 12-17:
problem. group communication Updating replicas is a If groups can change dynamically, then a group membership service is needed. This keeps track of the processes that are currently in a group. ?? Department of Computer Science — University of San Francisco – p.19/
Group membership 12-18:
A group membership process needs to: Provide an interface for membership changes, creation, and destruction. Provide a failure detector Notify members of membership changes. Perform group address expansion. When a message is sent via multicast, it is sent to the group address. The membership process must then deliver that message to all processes. ?? Department of Computer Science — University of San Francisco – p.20/
View-synchronous 12-19:
communication
View-synchronous communication is an extension of reliable multicast. , which is a list of all processes currently in view It uses a the group. When membership changes, a new view is sent to all members. All messages that originate before a new view must be delivered before that new view is delivered. Provides a cut in the message timeline. Can also be thought of as providing a state transition. ?? Department of Computer Science — University of San Francisco – p.21/
View-synchronous 12-20:
communication
View-synchronous communication guarantees that if one process delivers a message within the context of a view, all processes deliver that message with that view’s context. Change of view is treated as anothe timestamped message. Allows us to break the timeline into states, or sequences of views. All processes agree on what has happened in that view. ?? Department of Computer Science — University of San Francisco – p.22/
Comments on passive 12-21:
replication
crash failures. n replicas are needed to tolerate + 1 n Very easy from the front end’s point of view; all that is needed is to communicate with a single server, and possible change servers if the primary fails. Problem: view-synchronous communication requires significant overhead. This can lead to latency in transmitting data back to the client.
Failures 12-22:
Passive replication deals nicely with crash failures. If a backup crashes, there’s no problem. if the primary crashes, it is replaced by a new primary. View-synchronous group communication allows the replicas to agree as to what operations have been performed. The new primary picks up at that point.
Active Replication 12-23:
Client Client RM RM RM FrontEnd^ FrontEnd In active replication, all replica managers are equal Front ends multicast requests to all replica managers. All managers process request independently If a replica crashes, oth- ers continue as normal. ?? Department of Computer Science — University of San Francisco – p.25/
Active Replication 12-24:
Sequence of events:
- Front end attaches a unique identifier to request and multicasts it to all RMs using totally ordered reliable multicast.
- Group communication system delivers messages to all RMs in the same order.
- Each replica manager evaluates the request.
- Since totally ordered multicast is used for communication, no agreement phase is needed.
- Each replica returns its response to the front end. ?? Department of Computer Science — University of San Francisco – p.26/
Active Replication 12-25:
When can the front end return a response to the client? Depends on what sorts of failures you want to tolerate. Crash failures: can return the first response.
- 1 responses.^23 Byzantine failures: Must collect ?? Department of Computer Science — University of San Francisco – p.27/
Active replication 12-26:
Notice that active replication assumes totally ordered reliable multicast. Recall that this is equivalent to the consensus problem. We need either: A synchronous system Failure detectors As with passive replication, totally ordered multicast may cause latencies. ?? Department of Computer Science — University of San Francisco – p.28/
Failures 12-27:
Failure is totally transparent here. Nothing new is needed if a replica manager crashes. Too many Byzantine failures can cause the usual problems.
Lazy Replication 12-28:
Active and passive replication provide fault tolerance and sequential consistency. They do this by immediately synchronizing before returning data to the client. This is great for fault tolerance, but not for availability. Some applications may not tolerate latency. We can trade latency for sequential consistency to get a highly available service.
Updating with lazy replication 12-35:
If the query’s timestamp precedes the replica manager’s, the update can proceed immediately. Otherwise, the update is queued until the causally-previous messages arrive. Once this happens, the replica manager logs the update and updates its timestamp. ?? Department of Computer Science — University of San Francisco – p.37/
Gossiping 12-36:
gossip Replicas synchronize with each other through
. messages A gossip message contains a log of past updates and a timestamp. When a gossip message is received, the receiver must: Merge the log with its own. (the log may reflect other updates it hasn’t seen) Apply stable updates Remove entries from the log that are known to have been applied everywhere. ?? Department of Computer Science — University of San Francisco – p.38/
Gossiping 12-37:
Update frequency (how often gossip messages are sent) is application-dependent. Bulletin board: minutes, or less. Inventorying systems: possibly less frequently. May also depend on network availability. (for example, meeting schedulers on PDAs) Who updates are sent to can also be tuned to fit the application. Can choose randomly Can choose the replica who is ’farthest behaind’ Can use a fixed topology. Trade off amount of communication against latency and effects of failure. ?? Department of Computer Science — University of San Francisco – p.39/
Comments on lazy replication 12-38:
Provides high availability; clients usually receive an immediate response. Works even when the network is partitioned. Not appropriate for applications where replicas must be tightly synchronized, such as video conferencing. Scalability is an issue, due to number of messages and size of timestamp. ?? Department of Computer Science — University of San Francisco – p.40/
Failures 12-39:
The gossip architecture can also deal nicely with failure. Front ends can connect to more than one RM. It’s possible for a transaction to be lost if it is submitted to an RM who immediately crashes before sending it on to any other RM.
Summary 12-40:
Replication is the maintenance of copies of data at multiple computers. Provides fault tolerance, increased performance, high availability. Passive replication: a single RM interacts with clients, and synchronizes with slaves. Active replication: All RMs communicate with clients and synchronize with totally ordered multicast. Lazy replication: RMs immediately return responses to clients and synchronize later.
