CS 425 / ECE 428 Distributed Systems Fall 2017 Indranil Gupta (Indy)

Slides:



Advertisements
Similar presentations
CS 542: Topics in Distributed Systems Diganta Goswami.
Advertisements

CS425 /CSE424/ECE428 – Distributed Systems – Fall 2011 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S. Mitra, K. Nahrstedt, N. Vaidya.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Leader Election Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
CS 5204 – Operating Systems1 Paxos Student Presentation by Jeremy Trimble.
Paxos Lamport the archeologist and the “Part-time Parliament” of Paxos: – The Part-time Parliament, TOCS 1998 – Paxos Made Simple, ACM SIGACT News 2001.
1 Indranil Gupta (Indy) Lecture 8 Paxos February 12, 2015 CS 525 Advanced Distributed Systems Spring 2015 All Slides © IG 1.
6.852: Distributed Algorithms Spring, 2008 Class 7.
Distributed Systems Overview Ali Ghodsi
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 11: Leader Election All slides © IG.
Failure detector The story goes back to the FLP’85 impossibility result about consensus in presence of crash failures. If crash can be detected, then consensus.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 13: Impossibility of Consensus All slides © IG.
Computer Science 425 Distributed Systems CS 425 / ECE 428 Consensus
Consensus Hao Li.
Byzantine Generals Problem: Solution using signed messages.
Failure Detectors. Can we do anything in asynchronous systems? Reliable broadcast –Process j sends a message m to all processes in the system –Requirement:
Consensus Algorithms Willem Visser RW334. Why do we need consensus? Distributed Databases – Need to know others committed/aborted a transaction to avoid.
1 Principles of Reliable Distributed Systems Lectures 11: Authenticated Byzantine Consensus Spring 2005 Dr. Idit Keidar.
Asynchronous Consensus (Some Slides borrowed from ppt on Web.(by Ken Birman) )
Eddie Bortnikov & Aran Bergman, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Recitation.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 19: Paxos All slides © IG.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 18: Replication Control All slides © IG.
State Machines CS 614 Thursday, Feb 21, 2002 Bill McCloskey.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Paxos Made Simple Jinghe Zhang. Introduction Lock is the easiest way to manage concurrency Mutex and semaphore. Read and write locks. In distributed system:
Lecture 8-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2010 Indranil Gupta (Indy) September 16, 2010 Lecture 8 The Consensus.
Bringing Paxos Consensus in Multi-agent Systems Andrei Mocanu Costin Bădică University of Craiova.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 8 Instructor: Haifeng YU.
Lecture 11-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2010 Indranil Gupta (Indy) September 28, 2010 Lecture 11 Leader Election.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion & Leader Election Steve Ko Computer Sciences and Engineering University.
SysRép / 2.5A. SchiperEté The consensus problem.
Alternating Bit Protocol S R ABP is a link layer protocol. Works on FIFO channels only. Guarantees reliable message delivery with a 1-bit sequence number.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586 CSE 486/586 Distributed Systems Leader Election Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
The consensus problem in distributed systems
CSE 486/586 Distributed Systems Leader Election
CS 525 Advanced Distributed Systems Spring 2013
Distributed Systems – Paxos
Paxos and Raft (Lecture 21, cs262a)
Lecture 17: Leader Election
Lecture 16-A: Impossibility of Consensus
Computer Science 425 Distributed Systems CS 425 / ECE 428 Fall 2013
Paxos and Raft (Lecture 9 cont’d, cs262a)
Distributed Systems: Paxos
EECS 498 Introduction to Distributed Systems Fall 2017
Cloud Computing Concepts
Implementing Consistency -- Paxos
CS 525 Advanced Distributed Systems Spring 2018
Alternating Bit Protocol
Distributed Consensus
Distributed Systems, Consensus and Replicated State Machines
Distributed Consensus
EEC 688/788 Secure and Dependable Computing
CSE 486/586 Distributed Systems Leader Election
Consensus, FLP, and Paxos
Lecture 21: Replication Control
EEC 688/788 Secure and Dependable Computing
EECS 498 Introduction to Distributed Systems Fall 2017
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Lecture 21: Replication Control
Implementing Consistency -- Paxos
Distributed systems Consensus
CSE 486/586 Distributed Systems Reliable Multicast --- 2
CSE 486/586 Distributed Systems Byzantine Fault Tolerance
CSE 486/586 Distributed Systems Leader Election
CSE 486/586 Distributed Systems Consensus
Presentation transcript:

CS 425 / ECE 428 Distributed Systems Fall 2017 Indranil Gupta (Indy) Oct 24, 2017 Lecture 16-B: Paxos All slides © IG

What is Consensus? Formal problem statement N processes Each process p has input variable xp : initially either 0 or 1 output variable yp : initially b (can be changed only once) Consensus problem: design a protocol so that at the end, either: All processes set their output variables to 0 (all-0’s) Or All processes set their output variables to 1 (all-1’s) 2

What is Consensus? (2) Every process contributes a value Goal is to have all processes decide same (some) value Decision once made can’t be changed There might be other constraints Validity = if everyone proposes same value, then that’s what’s decided Integrity = decided value must have been proposed by some process Non-triviality = there is at least one initial system state that leads to each of the all-0’s or all-1’s outcomes 3

Why is it Important? Many problems in distributed systems are equivalent to (or harder than) consensus! Perfect Failure Detection Leader election (select exactly one leader, and every alive process knows about it) Agreement (harder than consensus) So consensus is a very important problem, and solving it would be really useful! Consensus is Possible to solve in synchronous systems Impossible to solve in asynchronous systems 4

Can’t we just solve Consensus? Yes, we can! (Whut?) 5

Yes we Can! Paxos algorithm Paxos invented by? (take a guess) Most popular “consensus-solving” algorithm Does not solve consensus problem (which would be impossible, because we already proved that) But provides safety and eventual liveness A lot of systems use it Zookeeper (Yahoo!), Google Chubby, and many other companies Paxos invented by? (take a guess) 6 6

Yes we Can! Paxos invented by Leslie Lamport Paxos provides safety and eventual liveness Safety: Consensus is not violated Eventual Liveness: If things go well sometime in the future (messages, failures, etc.), there is a good chance consensus will be reached. But there is no guarantee. FLP result still applies: Paxos is not guaranteed to reach Consensus (ever, or within any bounded time) 7 7

Political Science 101, i.e., Paxos Groked Paxos has rounds; each round has a unique ballot id Rounds are asynchronous Time synchronization not required If you’re in round j and hear a message from round j+1, abort everything and move over to round j+1 Use timeouts; may be pessimistic Each round itself broken into phases (which are also asynchronous) Phase 1: A leader is elected (Election) Phase 2: Leader proposes a value, processes ack (Bill) Phase 3: Leader multicasts final value (Law) 8

Phase 1 – election Potential leader chooses a unique ballot id, higher than seen anything so far Sends to all processes Processes wait, respond once to highest ballot id If potential leader sees a higher ballot id, it can’t be a leader Paxos tolerant to multiple leaders, but we’ll only discuss 1 leader case Processes also log received ballot ID on disk If a process has in a previous round decided on a value v’, it includes value v’ in its response If majority (i.e., quorum) respond OK then you are the leader If no one has majority, start new round (If things go right) A round cannot have two leaders (why?) Please elect me! OK! 9

Phase 2 – Proposal (Bill) Leader sends proposed value v to all use v=v’ if some process already decided in a previous round and sent you its decided value v’ If multiple such v’ received, use latest one Recipient logs on disk; responds OK Value v ok? Please elect me! OK! OK! 10

Phase 3 – Decision (Law) If leader hears a majority of OKs, it lets everyone know of the decision Recipients receive decision, log it on disk Value v ok? v! Please elect me! OK! OK! 11

Which is the point of No-Return? That is, when is consensus reached in the system Value v ok? v! Please elect me! OK! OK! 12

Which is the point of No-Return? If/when a majority of processes hear proposed value and accept it (i.e., are about to/have respond(ed) with an OK!) Processes may not know it yet, but a decision has been made for the group Even leader does not know it yet What if leader fails after that? Keep having rounds until some round completes Value v ok? v! Please elect me! OK! OK! 13

Safety If some round has a majority (i.e., quorum) hearing proposed value v’ and accepting it, then subsequently at each round either: 1) the round chooses v’ as decision or 2) the round fails Proof: Potential leader waits for majority of OKs in Phase 1 At least one will contain v’ (because two majorities or quorums always intersect) It will choose to send out v’ in Phase 2 Success requires a majority, and any two majority sets intersect Value v ok? v! Please elect me! OK! OK! 14

What could go Wrong? 15 Process fails Leader fails Messages dropped Majority does not include it When process restarts, it uses log to retrieve a past decision (if any) and past-seen ballot ids. Tries to know of past decisions. Leader fails Start another round Messages dropped If too flaky, just start another round Note that anyone can start a round any time Protocol may never end – tough luck, buddy! Impossibility result not violated If things go well sometime in the future, consensus reached Value v ok? v! Please elect me! OK! OK! 15

What could go Wrong? A lot more! This is a highly simplified view of Paxos. See Lamport’s original paper: http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf Value v ok? v! Please elect me! OK! OK! Don’t think URL works -Bob 16

Summary Paxos protocol: widely used implementation of a safe, eventually-live consensus protocol for asynchronous systems Paxos (or variants) used in Apache Zookeeper, Google’s Chubby system, Active Disk Paxos, and many other cloud computing systems 17