CS425 / CSE424 / ECE428 — Distributed Systems — Fall 2011 2011-11-15Nikita Borisov - UIUC1 Some material derived from slides by Leslie Lamport.

Slides:



Advertisements
Similar presentations
Paxos and Zookeeper Roy Campbell.
Advertisements

Paxos Made Simple Leslie Lamport. Introduction ► Lock is the easiest way to manage concurrency  Mutex and semaphore.  Read and write locks in 2PL for.
CS425/CSE424/ECE428 – Distributed Systems – Fall 2011 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S. Mitra, K. Nahrstedt, N. Vaidya.
CS425 /CSE424/ECE428 – Distributed Systems – Fall 2011 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S. Mitra, K. Nahrstedt, N. Vaidya.
NETWORK ALGORITHMS Presenter- Kurchi Subhra Hazra.
Teaser - Introduction to Distributed Computing
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.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
1 Indranil Gupta (Indy) Lecture 8 Paxos February 12, 2015 CS 525 Advanced Distributed Systems Spring 2015 All Slides © IG 1.
Dept. of Computer Science & Engineering, The Chinese University of Hong Kong Paxos: The Part-Time Parliament CHEN Xinyu
Consensus Hao Li.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Byzantine Fault Tolerance Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
Consensus Algorithms Willem Visser RW334. Why do we need consensus? Distributed Databases – Need to know others committed/aborted a transaction to avoid.
State Machine Replication Project Presentation Ido Zachevsky Marat Radan Supervisor: Ittay Eyal Winter Semester 2010.
Paxos Made Simple Gene Pang. Paxos L. Lamport, The Part-Time Parliament, September 1989 Aegean island of Paxos A part-time parliament – Goal: determine.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering.
Eddie Bortnikov & Aran Bergman, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Recitation.
EEC 688/788 Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
CHUBBY and PAXOS Sergio Bernales 1Dennis Kafura – CS5204 – Operating Systems.
Chapter 6 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University Building Dependable Distributed Systems.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 19: Paxos All slides © IG.
Eddie Bortnikov & Aran Bergman, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Recitation.
Distributed Storage System Survey
Paxos Made Simple Jinghe Zhang. Introduction Lock is the easiest way to manage concurrency Mutex and semaphore. Read and write locks. In distributed system:
Bringing Paxos Consensus in Multi-agent Systems Andrei Mocanu Costin Bădică University of Craiova.
Distributed Transactions CS425 /CSE424/ECE428 – Distributed Systems – Fall 2011 Nikita Borisov - UIUC Material derived from slides by I. Gupta, M. Harandi,
CS425 /CSE424/ECE428 – Distributed Systems – Fall 2011 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S. Mitra, K. Nahrstedt, N. Vaidya.
Practical Byzantine Fault Tolerance
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
Paxos A Consensus Algorithm for Fault Tolerant Replication.
Paxos: Agreement for Replicated State Machines Brad Karp UCL Computer Science CS GZ03 / M st, 23 rd October, 2008.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Google Chubby Lock Service Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 60641: Operating Systems Implementing Fault-Tolerant Services Using the State Machine Approach: a tutorial Fred B. Schneider, ACM Computing Surveys.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion & Leader Election Steve Ko Computer Sciences and Engineering University.
Two-Phase Commit Brad Karp UCL Computer Science CS GZ03 / M th October, 2008.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Google Chubby Lock Service Steve Ko Computer Sciences and Engineering University at Buffalo.
Implementing Replicated Logs with Paxos John Ousterhout and Diego Ongaro Stanford University Note: this material borrows heavily from slides by Lorenzo.
Mutual Exclusion Algorithms. Topics r Defining mutual exclusion r A centralized approach r A distributed approach r An approach assuming an organization.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
CS 425 / ECE 428 Distributed Systems Fall 2015 Indranil Gupta (Indy) Oct 1, 2015 Lecture 12: Mutual Exclusion All slides © IG.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Paxos Steve Ko Computer Sciences and Engineering University at Buffalo.
Detour: Distributed Systems Techniques
Consensus, impossibility results and Paxos Ken Birman.
The consensus problem in distributed systems
CS 525 Advanced Distributed Systems Spring 2013
Distributed Systems – Paxos
Alternative system models
CSE 486/586 Distributed Systems Paxos
Lecture 17: Leader Election
EECS 498 Introduction to Distributed Systems Fall 2017
Implementing Consistency -- Paxos
CS 525 Advanced Distributed Systems Spring 2018
Fault-tolerance techniques RSM, Paxos
CS 425 / ECE 428 Distributed Systems Fall 2017 Indranil Gupta (Indy)
EEC 688/788 Secure and Dependable Computing
Consensus, FLP, and Paxos
EEC 688/788 Secure and Dependable Computing
EECS 498 Introduction to Distributed Systems Fall 2017
Replicated state machine and Paxos
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Prof. Leonardo Mostarda University of Camerino
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Paxos Made Simple.
Implementing Consistency -- Paxos
CSE 486/586 Distributed Systems Paxos
Presentation transcript:

CS425 / CSE424 / ECE428 — Distributed Systems — Fall Nikita Borisov - UIUC1 Some material derived from slides by Leslie Lamport

 Achieve consensus  In an asynchronous network  Non-Byzantine failures  Safety requirements  Only a proposed value may be chosen  Only a single value is chosen  Process never learns of a chosen value unless it has actually been chosen  Also, liveness Nikita Borisov - UIUC2

 Proposer  Proposes values  Acceptor  Accepts (or rejects) values  Learner  Finds out what value has been chosen  Typically a process acts as one or more of these (often all 3) Nikita Borisov - UIUC3

 Acceptor:  Accepts or rejects (ignores) proposals  Consistency guarantee  Value is chosen if and only if a majority of acceptors accepted this value  Simple (common!) case: one proposer  Must accept proposal, o/w no progress! P1: Acceptor must accept the first proposal it receives Nikita Borisov - UIUC4

 What if there are two proposers?  Proposer 1 sends value v to N/2 acceptors  Proposer 2 sends value v’ to the other N/2 acceptors  P1 means that each acceptor accepts the corresponding proposal  No majority, therefore deadlock  Solutions? Nikita Borisov - UIUC5

 Acceptors must accept multiple proposals  Therefore, multiple proposals may be chosen (accepted by a majority). (Why?)  Therefore, must ensure safety P2. If a proposal with value v is chosen, then every higher-numbered proposal that is chosen has value v.  Note: every proposal must have unique number Nikita Borisov - UIUC6

P2. If a proposal with value v is chosen, then every higher-numbered proposal that is chosen has value v.  A chosen proposal is accepted by at least one acceptor, so: P2 a. If a proposal with value v is chosen, then every higher-numbered proposal accepted by any acceptor has value v. (P2 a => P2) Nikita Borisov - UIUC7

P1: Acceptor must accept the first proposal it receives. P2 a. If a proposal with value v is chosen, then every higher- numbered proposal accepted by any acceptor has value v.  Asynchronous network  Acceptor c does not hear some chosen proposal v  Proposer p makes a new proposal v’ to c  By P1, c must accept. By P2, v’ = v. P2 b. If a proposal with value v is chosen, then every higher- numbered proposal issued by any proposer has value v. (P2 b => P2 a => P2) Nikita Borisov - UIUC8

P2 b. If a proposal with value v is chosen, then every higher- numbered proposal issued by any proposer has value v.  A chosen proposal is accepted by majority of acceptors P2 c. For any v and n, if a proposal with value v and number n is issued, then there is a set S consisting of a majority of acceptors such that either: (a) no acceptor in S has accepted any proposal numbered less than n, or (b) v is the value of the highest-numbered proposal among all proposals numbered less than n accepted by acceptors in S Nikita Borisov - UIUC9

 Proposer must know what proposals have been accepted by a majority of acceptors.  Ask acceptors about what they have accepted  But, remember, asynchronous  New proposals may be made after reply is sent  E.g.:  p asks c about accepted proposals  c replies with empty set {}  p’ proposes (n,v) to c  c accepts  p proposes (m,v’) with m>n to c, violating P2 c Nikita Borisov - UIUC10

 Don’t accept proposal from p’!  p asks c about accepted proposals with numbers less than m (prepare request)  c replies with empty set {}, and promises not to accept proposals with numbers less than m  p’ proposes (n,v) to c, with n < m  c rejects (ignores) p’s proposal  p proposes (m,v’) with m>n to c P1 a. An acceptor can accept a proposal numbered n if and only if it has not responded to a prepare request with a number > n Nikita Borisov - UIUC11

 Phase 1 (prepare):  A proposer selects a proposal number n and sends a prepare request with number n to majority of acceptors.  If an acceptor receives a prepare request with number n greater than that of any prepare request it saw, it responses YES to that request with a promise not to accept any more proposals numbered less than n and include the highest-numbered proposal (if any) that it has accepted Nikita Borisov - UIUC12

 Phase 2 (accept):  If the proposer receives a response YES to its prepare requests from a majority of acceptors, then it sends an accept request to each of those acceptors for a proposal numbered n with a values v which is the value of the highest-numbered proposal among the responses.  If an acceptor receives an accept request for a proposal numbered n, it accepts the proposal unless it has already responded to a prepare request having a number greater than n Nikita Borisov - UIUC13

 A value is chosen at proposal number n iff majority of acceptor accept that value in phase 2 of the proposal number Nikita Borisov - UIUC14

 P1: Any proposal number is unique.  P2: Any two set of acceptors have at least one acceptor in common.  P3: the value sent out in phase 2 is the value of the highest-numbered proposal of all the responses in phase Nikita Borisov - UIUC15

14 αa 2 a 4 a 5 5βa1 a2 a3 a55βa1 a2 a3 a5 29β a 2 a 3 a 4 27β a 1 a 3 a 4 2αa1 a2 a3 a42αa1 a2 a3 a4 # valuepool of acceptors Nikita Borisov - UIUC16

 Claim: if a value v is chosen at proposal number n, any value that is sent out in phase 2 of any later prososal numbers must be also v.  Proof (by contradiction): Let m is the first proposal number that is later than n and in phase 2, the value sent out is not v Nikita Borisov - UIUC17

… n+1 v… m v ’ … m-1v … nv…nv… # valuepool of acceptors aaaa the highest # that a accept ≥ nthe highest # chosen in phase 2 ≥ Nikita Borisov - UIUC18

 There are some options:  Each acceptor, whenever it accepts a proposal, informs all the learners.  Acceptors informs a distinguished learner (usually the proposer) and let the distinguished learner broadcast the result Nikita Borisov - UIUC19

 Acceptors have many options to response:  Prepare request: No/Yes  Accept request: No/Yes if it didn ’ t promise not to do so  Back off time after abandon a proposal: exponential back-off/pre-assigned values  Should we wait for nodes to online in each phase? Nikita Borisov - UIUC20

 Chubby lock service.  Petal: Distributed virtual disks.  Frangipani: A scalable distributed file system Nikita Borisov - UIUC21