Download Lecture Notes on Distributed Systems: Replication and Replica Management and more Study notes Computer Science in PDF only on Docsity!
2002 M.T. Harandi and J. Hou
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-1Lecture 23-
Computer Science
Distributed Systems
Computer Science
Distributed Systems
Lecture 23
Replication Control
Reading: Section 15.1-15.
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-2Lecture 23-
Replication Replication
Enhancing Services by replicating data
Load Balancing
Example: Workload is shared between the servers by
binding all the server IP addresses to the service’s DNS name. A DNS lookup of the site results in one of the servers’ IP addresses being returned, in a round-robin fashion.
Fault Tolerance
Under the fail-stop model, if up to f of f+1 servers crash, at
least one remains to supply the service.
Increased Availability
Service may not be available when servers fail or when the network is partitioned.
P: probability that one server fails= 1 – P= availability of service. e.g. P = 5% => service is available 95% of the time.
Pn: probability that n servers fail= 1 – Pn= availability of service. e.g. P = 5%, n = 3 => service available 99.875% of the time
^ ^ 2002, M. T. Harandi and J. Hou (modified: I. Gupta)^ Lecture 23-3Lecture 23-
Basic Mode of Replication Basic Mode of Replication
Replication Transparency
User/client need not know that multiple physical copies of data exist.
Replication Consistency
Data is consistent on all of the replicas (or is in the process of becoming consistent)
Client Front End RM
RM
RM
Client Front End
Client Front End
Service
server
server
server
Replica Manager`
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-4Lecture 23-
Replication Management Replication Management
Request Communication
Requests can be made to a single RM or to multiple RMs
Coordination: The RMs decide
whether the request is to be applied
the order of requests
FIFO ordering: If a FE issues r then r’, then any correct
RM handles r and then r’.
Causal ordering: If the issue of r “happened before”
the issue of r’, then any correct RM handles r and then r’.
Total ordering: If a correct RM handles r and then r’,
then any correct RM handles r and then r’.
Execution: The RMs execute the request
tentatively.
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-5Lecture 23-
Replication Management Replication Management
Agreement: The RMs attempt to reach
consensus on the effect of the request.
E.g., Two phase commit through a coordinator
If this succeeds, effect of request is made permanent
Response
One or more RMs responds to the front end.
In the case of fail-stop model, the FE returns the first
response to arrive.
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-6Lecture 23-
Group Communication Group Communication
“Member”= process (e.g., RM)
Static Groups: group membership is pre-defined
Dynamic Groups: Members may join and leave, as
necessary
Group Send
Address Expansion
Multicast Comm.
Membership Management
Leave
Fail
Join
Group
2002 M.T. Harandi and J. Hou
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-7Lecture 23-
Views Views
A group membership service maintains group
views, which are lists of current group members.
This is NOT a list maintained by a one member, but…
Each member maintains its own local view
A view Vp(g) is process p’s understanding of its
group (list of members)
Example: V (^) p.0(g) = {p}, V (^) p.1(g) = {p, q}, V (^) p.2 (g) = {p, q, r}, V (^) p.3 (g) = {p,r}
A new group view is disseminated, throughout the
group, whenever a member joins or leaves.
Member detecting failure of another member reliable multicasts a
“view change” message (requires causal-total ordering for multicasts)
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-8Lecture 23-
Views Views
An event is said to occur in a view vp,i(g) if the event occurs at
p, and at the time of event occurrence, p has delivered vp,i(g) but has not yet delivered vp,i+1(g).
Messages sent out in a view i need to be delivered in that view
at all members in the group (“What happens in the View, stays in the View”)
Requirements for view delivery
Order: If p delivers vi(g) and then vi+1(g), then no other process q
delivers vi+1(g) before vi(g).
Integrity: If p delivers vi(g), then p is in vi(g).
Non-triviality: if process q joins a group and becomes reachable
from process p, then eventually, q will always be present in the views that delivered at p.
Exception: partitioning of group. Solutions to partitioning:
Primary partition: allow only majority partition to proceed Allow any and all partitions to proceed Choice depends on consistency requirements.
Ignore partitions for the rest of the lecture.
^ ^ 2002, M. T. Harandi and J. Hou (modified: I. Gupta)^ Lecture 23-9Lecture 23-
View Synchronous Communication View Synchronous Communication
View Synchronous Communication = Group Membership
Service + Reliable multicast
The following guarantees are provided for multicast
messages:
Integrity: If p delivered message m, p will not deliver m again.
Also p ∈∈∈∈ group (m).
Validity: Correct processes always deliver all messages. That is,
if p delivers message m in view v(g), and some process q∈∈ ∈∈ v(g) does not deliver m in view v(g), then the next view v’(g) delivered at p will not include q.
Agreement: Correct processes deliver the same set of messages
in any view. if p delivers m in V, and then delivers V’, then all processes in V ∩∩∩∩ V’ deliver m in view V
All View Delivery conditions (Order, Integrity and Non-triviality
conditions, from last slide) are satisfied
“What happens in the View, stays in the View”
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-10Lecture 23-
Example: View Synchronous Communication Example: View Synchronous Communication
p
q
r
V(p,q,r)
p
q
r
V(p,q,r)
p
q
r
V(p,q,r)
p
q
r
V(p,q,r)
X X^ X
V(q,r)
V(q,r)
V(q,r)
V(q,r)
X
X (^) X
Not Allowed (^) Not Allowed
Allowed (^) Allowed
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-11Lecture 23-
View Synchrony View Synchrony
- When a new process joins, state transfer may be
needed (at view delivery point) to bring it up to
date
- “state” may be list of all messages delivered so far (wasteful)
- “state” could be list of current server object values (e.g., in a bank database)
- View Synchrony = “Virtual Synchrony”
- Provides an abstraction of a synchronous network that hides the asynchrony of the underlying network from distributed applications
- But does not violate FLP impossibility (since can partition)
- Used in ISIS toolkit (NY Stock Exchange)
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-12Lecture 23-
Back to Replication Back to Replication
Client Front End^ RM
RM
RM
Client Front End
Client Front End
Service
server
server
server
Need consistent updates to all copies of an object •Linearizability •Sequential Consistency
2002 M.T. Harandi and J. Hou
2002, M. T. Harandi and J. Hou (modified: I. Gupta) Lecture 23-19Lecture 23-
Summary Summary
- Replicating objects across servers improves
performance, fault-tolerance, availability
- Raises problem of Replica Management
- View Synchronous communication service
provides totally ordered delivery of
views+multicasts
- RMs can be built over this service
- Passive and Active Replication
- Reading for this lecture was: Sections 15.1-15.
- Reading for next lecture: Section 15.
