EEC 688/788 Secure and Dependable Computing

Slides:



Advertisements
Similar presentations
CS 5204 – Operating Systems1 Paxos Student Presentation by Jeremy Trimble.
Advertisements

CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Byzantine Fault Tolerance Steve Ko Computer Sciences and Engineering University at Buffalo.
EEC 688/788 Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 688/788 Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 15 Wenbing Zhao Department of Electrical and Computer Engineering.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering.
EEC 688/788 Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Chapter 6 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University Building Dependable Distributed Systems.
EEC 688 Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 14 Wenbing Zhao Department of Electrical and Computer Engineering.
Paxos Made Simple Jinghe Zhang. Introduction Lock is the easiest way to manage concurrency Mutex and semaphore. Read and write locks. In distributed system:
EEC 688/788 Secure and Dependable Computing Lecture 14 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 688/788 Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 688/788 Secure and Dependable Computing Lecture 9 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 688/788 Secure and Dependable Computing Lecture 10 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 688/788 Secure and Dependable Computing Lecture 15 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Chapter 4 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University Building Dependable Distributed Systems.
Building Dependable Distributed Systems, Copyright Wenbing Zhao
EEC 688/788 Secure and Dependable Computing Lecture 6 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
EEC 688/788 Secure and Dependable Computing Lecture 9 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Paxos 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.
EEC 688/788 Secure and Dependable Computing Lecture 10 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
The consensus problem in distributed systems
Distributed Systems – Paxos
EEC 688/788 Secure and Dependable Computing
View Change Protocols and Reconfiguration
EECS 498 Introduction to Distributed Systems Fall 2017
Implementing Consistency -- Paxos
Outline Announcements Fault Tolerance.
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
EEC 688/788 Secure and Dependable Computing
Active replication for fault tolerance
Fault-tolerance techniques RSM, Paxos
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
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
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
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
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
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
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
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
Implementing Consistency -- Paxos
Presentation transcript:

EEC 688/788 Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org

EEC688/788: Secure & Dependable Computing Outline Distributed consensus and Paxos algorithms Dynamic Paxos Cheap Paxos Fast Paxos 5/16/2019 EEC688/788: Secure & Dependable Computing

Dynamic Paxos Designed to accommodate reconfiguration Extension majority concept to quorum Classic Paxos => uses static quorum Dynamic quorum: quorum size may change dynamically Cheap Paxos uses dynamic quorum

Dynamic Paxos Fewer replicas are required by using spare replicas and reconfiguration provided no other fault during reconfiguration Without reconfiguration, 3f+1 replicas can only tolerate up to 3f/2 faulty replicas 2f+1 active replicas, plus f spares can tolerate up to 3f-1 faulty replicas via substitution and reconfiguration As long as 1 active replica and 1 spare are operating

Dynamic Paxos Reconfiguration request must be totally ordered with respect to regular application requests A reconf request includes both new membership and quorum definition Replicas in the new membership should not accept msgs unrelated to reconf from replicas that have been excluded from the membership External replicas should not be allowed to participate the consensus step Replica mistakenly excluded can join via reconfiguration

Cheap Paxos Cheap Paxos is a special instance of Dynamic Paxos Aims to minimize involvement of spare replicas Enable the use of f+1 active replicas to tolerate f faults, provided that sufficient spares are available (f or more) Active replicas are referred to as main replicas Spare replicas are referred to as auxiliary replicas

Cheap Paxos Primary quorum Secondary quorum Consists of all active replicas Secondary quorum Must be formed by the majority of combined replicas Consists of at least one main replica => Ensures intersection between primary and secondary quorums Question: what if only one active replica left?

Cheap Paxos Upon detection of the failure of an active replica, a reconfiguration request is issued New primary quorum still consists of all surviving active replicas When reconfig request is executed, switch to new configuration Auxiliary replicas are not bothered unless a reconfiguration is necessary What if the primary fails => view change

Cheap Paxos: View Change For history information: new primary must collect info from every active replica except the old primary For approval of the primary role, the new primary must collect votes from all surviving active replicas plus one or more auxiliary replica => a secondary quorum The secondary quorum is used to complete all Paxos instances started by old primary but not yet completed

Cheap Paxos Replicas in secondary quorum must propagate their knowledge to all replicas prior to moving back to primary quorum So that auxiliary replicas do not have to keep all requests and control msgs How to achieve this Primary notifies its latest state to all replicas not in secondary quorum Main replica (if it is not in secondary quorum) requests for retransmission of missing msgs Auxiliary replica keeps new info from primary and purge old data, and ack to the primary Primary resumes ordering requests after it receives ack from every replica

Example

Example

Example

Example

Fast Paxos Multi-Paxos: use one round of P1 for all instances of Paxos Fast Paxos: aims to further reduce the cost of consensus by running one P2a for all instances of Paxos Enables an acceptor to select a value (provide by a client) unilaterally and sends P2b to the primary However, there is no free lunch => we need more replicas to tolerate f faulty nodes (> 2f+1 for sure) We will also have to deal with collision recovery

Fast Paxos: Basic Steps Fast Paxos runs in rounds and each round has up to two phases In each round, 1st phase: prepare phase to enable the coordinator to solicit the status and promises 2nd phase for the coordinator to select a value to be voted on When an acceptor responded to P1a in round i, it has participated the round I When an acceptor sent P2b in response to P2a, it has casted its vote

Fast Paxos: Basic Steps Start from an initial membership, phase 1 will always enable the coordinator to select any value for P2b Need to run P1 once for all rounds Need to run P2a once for all rounds => eliminate another communication step Classic round is used only when a consensus is not reached in the fast round Due to coordinator failure Due to a collision

Fast Paxos: Normal Operation

Fast Paxos: Collision Recovery In the presence of multiple clients, acceptors may chose different requests (values) The coordinator must collect from a quorum of replicas on their values and select the right value On detecting a collision, i.e., the presence of multiple values, the coordinator initiates a Classic round Phase 1 can be omitted in Classic round because the coordinator already collected enough info

Fast Paxos: Quorum Requirement Quorum based on majority will not work Coordinator cannot rule out any value in the presence of collision Any value could have been chosen The coordinator must select a value that have been chosen or might have been chosen Intuition: coordinator selects a value only if it is present in the majority of the votes collected Need to make sure that a value in the minority could not have been chosen

Fast Paxos: Quorum Requirement How to ensure that a value in the minority could not have been chosen First, it cannot be chosen in the same fast round => the majority value makes it impossible Second, make sure two fast quorums (Rf) intersect in more than half of |Rf| acceptors Third, make sure any fast quorum Rf, and any classic quorum Rc intersect in more than half of |Rc| acceptors

Fast Paxos: Quorum Requirement Let total number of acceptors be n, number of faults tolerated in a fast round e, and # of faults tolerated in a classic round f Derive inequalities (n-f)+(n-f)-n>0 (n-e)+(n-e)-n>(n-e)/2 (n-e)+(n-f)-n>(n-f)/2 Reduce to n > 2f and n > 2e+f

Fast Paxos: Quorum Requirement First quorum formation: maximize e => e=f, n> 3f => |Rc| = n-f > 2f => n = 3f+1 Second quorum formation: maximize f f < n/2 e <= n/4 If e=1, n=4; |Rf| = |Rc| = 3

Fast Quorum: Coordinator Value Selection Rule If no acceptor has casted any vote, the coordinator gets to select any value for P2b If only a single value in the votes, select that value If multiple values, select that one that is in the majority, if one is present. Otherwise, select any value

Exercise 1: Fast Paxos Given the number of faulty acceptors that can be tolerated in fast round e=5 Find out the following: The minimum number of acceptors needed (n) The faulty acceptors that can be tolerated in a classic round (f) The size of classic quorum The size of fast quorum