138 CS Networked Information Systems
Uur etintemel
Lecture 14: Synchronization III
Copyright 2006
1
1
Elections
Choose a unique process to play a role We require that the elected process be chosen as the one with the largest ID
IDs must be unique & totally ordered, e.g.,
ID := IP address ID := <1/load, i>
Assumption: all processes know the ids of all other machines
they dont know which ones are currently up or down. don
2
Uur etintemel
Elections are used to choose a particular process to play a specific role. It is essential that all processes agree on the role. Without loss of generality, we assume that the elected process should be the one that has the largest ID (among those that are currently up).
2
Elections: Qualitative Requirements
Safety: nothing bad happens
A participant process has elected == P, where P is chosen as a non-crashed process with max ID, or elected is undefined
Liveness: something good eventually happens
All processes participate & eventually set elected, or crash
3
Uur etintemel
We care about two requirements: Safety relates to the correctness of the algorithm, whereas liveness requires that the election is completed within a finite amount of time (assuming a synchronous system, which is a system there is an upper bound on all the actions taken by a process).
3
The Bully Algorithm (Garcia-Molina, 1982)
Time-outs used to detect failures Assumes each process knows which processes have higher IDs
a process can elect itself Coordinator: to all processes w/ lower IDs Coordinator: Election: to all processes w/ higher IDs Election: OK: answer to election OK:
if not received within T, the sender sends coordinator Otherwise, process waits for T, to receive a coordinator If no message arrives, it begins a new election
4
Uur etintemel
3 message types:
When a process realizes that the coordinator is not responding (using a timeout mechanism), it initiates an election. A process P holds an election as follows: 1. P sends an election message to all other processes with higher timestamps 2. If no one responds (within T), P wins the election, sending a coordinator message to all processes with lower ids 3. The higher-ids that are up answer with an OK, and take over the election.
4
The Bully Algorithm: Example
1. Process 4 holds an election
2. Process 5 and 6 respond, telling 4 to stop
3. Now 5 and 6 each hold an election
4. Process 6 tells 5 to stop
Uur etintemel
5. Process 6 wins and tells everyone
5
Note: Here node 7 is dead.
5
Bully Algorithm: Analysis
Best case: The process with the 2nd highest ID is the first to detect coordinators failure:
(N -2) coordinator messages Turnaround time = 1
Worst case: The process with lowest ID is the first to detect coordinators failure:
O(N2) messages in (N-1) elections (N-
6
Uur etintemel
The slide analyses the best and worst case performance of the Bully algorithm.
6
Election: A Ring Algorithm
Processes 2 and 5 will discover simultaneously that process 7 failed
7
Uur etintemel
We now discuss another algorithm that is based on the notion of a ring, where the processes are organized according to a physical or a logical ring topology - each process knows who its successor is on the ring. Messages are always sent in the logical clockwise direction. A process detects the failure of the current coordinator and starts an election by sending an election message that contains its id. The election message traverses the ring, noting the id of the process at each hop. Once the message arrives back to the initiator, it contains the process with the highest id and the list of all available processes. At this point, the initiator changes the message type to coordinator, and circulates it once again to inform every process who the new coordinator is. Note that the ring organization is used only for election purposes and not as a general purpose communication topology.
7
Distributed Mutual Exclusion
Critical sections
no shared memory no support by single local kernel NFS lockd server enter(); resourceAccesses(); exit() resourceAccesses(); Safety: at most one process may execute in critical section at one time Liveness: Requests for entering and exiting critical sections are Liveness: eventually granted Fairness: Requests should be granted in the order they are received Fairness:
8
Uur etintemel
Example:
Primitives:
Requirements
If processes access shared resources, then mutual exclusion is required to ensure that they do not interfere and that consistency is maintained. This is the critical section problem. Mutual exclusion techniques used in centralized or shared memory systems (such as those based on the use of shared variables) are not sufficient for distributed mutual exclusion. An example service that provides mutual exclusion is NFSs lockd server that processes file lock requests. The application level primitives for executing a critical section are as follows: enter(), resourceAccesses(); and exit(). The requirements for mutual exclusion include safety, liveness, and fairness. Safety refers to the requirement that at most one process may execute in a critical section. Liveness refers to the requirement that requests for entering and exiting critical sections are eventually granted. Fairness refers to the requirement that requests should be granted in the order they are received.
8
Mutual Exclusion: A Centralized Algorithm
a)
b)
c)
Process 1 asks the coordinator for permission to enter a critical region. Permission is granted. granted. Process 2 then asks permission to enter the same critical region. The coordinator does not reply. When process 1 exits the critical region, it tells the coordinator, when then replies to 2. 2. Problem: single point of failure
9
Uur etintemel
Here is a simple centralized algorithm for ensuring mutual exclusion. A coordinator gets requests for access to the critical section, granting each in the order it receives them. It is easy to see that this approach satisfies the safety, liveness, and fairness requirements (assuming reliable communication and no failures). The primary limitation of this approach is that it suffers from single point of failure.
9
Mutual Exclusion: A Token Ring Algorithm
a) b)
An unordered group of processes on a network. A logical ring constructed in software.
10
Uur etintemel
Another distributed algorithm is based on the notion of a logical ring. The processes form themselves into a logical ring structure (the ordering on the ring is not important).
10
The Token Ring Algorithm
Three steps:
Each process waits for the token Retain it to enter() Release to neighbor when done Continuously consumes bandwidth Is not fair!
p1 pn
p
2
token
p
3
Problems:
p
4
11
Uur etintemel
Initially, process 0 is given the token. The token is then circulated around the ring. When a process receives a token, it can enter its critical region (only once). Once it is done, it the sends token to the next process on the ring. Note that this approach provides safety and liveness. It fails to provide fairness as the order in which each process receives the token is determined solely by its position on the ring. It also continuously incurs overhead because the token always needs to be circulated around the ring.
11
Unstructured Synchronization: Epidemic Algorithms
At each synchronization period, server P picks a random server Q and exchanges updates The protocol is called a simple epidemic (or antientropy) Three types:
Push: P -> Q (1 msg) Pull: P <- Q (2 msgs) Push-pull: P <-> Q (3 msgs)
12
Uur etintemel
Anti-entropy (or simple epidemic) works as follows: periodically, a server P randomly chooses a server Q and then the two exchange gossip (i.e., updates). Three modes of anti-entropy are possible. In the push mode, P pushes the updates that Q does not know. In the pull mode, P learns about the updates that it does not know from Q. Finally, the push-pull mode combines push and pull by ensuring that synchronization happens in both directions.
12
How to Summarize Database States
Timestamp (or version) vectors:
for each object, keep a timestamp number Compare the numbers to identify the most up-to-date one
What to do when P has 1M objects?
Need scalability in the number of objects
13
Uur etintemel
One important question in anti-entropy involves how to represent and summarize database states. One option is to use version vectors that describe the version number for each object. A version number indicates how many times a particular object has been updated since its creation. During synchronization, the version numbers at different servers can be compared to determine the most recent copy of the object. It is crucial to make the transfer and comparison of the version vectors efficient. Simply shipping 1M numbers and comparing them one by one are not scalable operations.
13
Scalability Technique I
Checksum-based synch
1. 2.
3.
compute a checksum of the vector send the checksum, and compare at the other end if checksums disagree, then send the entire vector
can be done for different subsets of the database
14
Uur etintemel
14
Scalability Technique II
Recent update lists
1. 2.
Maintain a checksum of the database Maintain a recent update list
1.
includes all items whose ages are less than t
3. 4.
Synch recent update lists first Then compare checksums
15
Uur etintemel
15
Scalability Technique III
Iterative checksums
1.
2.
Maintain an inverted index of the database by timestamp Exchange updates in reverse timestamp order
1. 2.
compute checksum at each step stop if checksum is the same
16
Uur etintemel
16
Epidemic Theory
Assume a fixed population of size n For now assume homogeneous spreading
anybody can infect anybody else with equal probability
Assume k members already infected Assume infection occurs in rounds
17
Uur etintemel
Lets now return to the fundamentals of epidemic theory in order to analyze the basic performance of the anti-entropy algorithms. Assume that any server can infect any other server (i.e., send an update that the destination has not yet seen) with equal probability. Also assume that k members are already infected and infections occur in rounds: at each round, each server randomly picks another server and performs antientropy.
17
Probability of Infection
Probability Pinfect(k, n):
#newly expected infections
a particular uninfected member is infected in a round if k are already infected
Pinfect(k, n) = 1 P(nobody infects member) = 1 (1 1/n)k E(#newly infected members) = (n - k) * Pinfect(k, n) Binomial distribution
#rounds
probability of picking another member
18
Uur etintemel
When we investigate the probability of infection, we observe that in follows a binomial distribution: the infection rate initially increases exponentially and then decreases exponentially.
18
Exponential Growth
Taken together: #rounds necessary to infect whole population grows O(log n) Base of log: 1.585 (experimental) Even under bad conditions:
Member failures Message losses But base of log decreases
19
Uur etintemel
It has been ...