EEC 688/788 EEC 688/788 Secure and Dependable Secure and Dependable Computing Computing Lecture 9 Lecture 9 Wenbing Zhao Wenbing Zhao Department of Electrical and Computer Department of Electrical and Computer Engineering Engineering Cleveland State University Cleveland State University [email protected][email protected]
25
Embed
EEC 688/788 Secure and Dependable Computing Lecture 9 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University [email protected].
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
EEC 688/788EEC 688/788Secure and Dependable Secure and Dependable ComputingComputing
Lecture 9Lecture 9
Wenbing ZhaoWenbing ZhaoDepartment of Electrical and Computer EngineeringDepartment of Electrical and Computer Engineering
Cleveland State UniversityCleveland State University
IEEEtranBST.zip (bibliography) Final Report due: Dec 9th midnight (no extensions!)
Must upload to turnitin.com account (as early as possible to see plagiarism report)
Project outline due: Nov 11th in class (hardcopy, no extension!) Topic, title, list of 5 papers
EEC688/788 Secure and Dependable EEC688/788 Secure and Dependable ComputingComputing
Data and Service Replication Replication resorts to the use of space redundancy to
achieve high availability Instead of running a single copy of the service, multiple copies
are used Usually deployed across a group of physical nodes for fault
isolation
Data and service replication Usually use different approaches Transactional data replication Optimistic replication (omitted) Balance consistency and performance: CAP theorem (omitted)
Data and Service Replication
Service replication: State machine replication Each replica is modeled as a state machine:
state, interface, deterministic state change via interface
Replica consistency issue: coordination needed Total order of requests to the server replicas Sequential execution of requests
Data replication: Direct access on data Operation on data: read or write Context: transaction processing => concurrent access
to replicated data essential
Service Replication State is encapsulated Clients interact with exported interfaces (APIs) Replication algorithm used to coordinate replicas (for
Replication StylesReplication Styles Active replication
Every input (request) is executed by every replica Every replica generates the outputs (replies) Voting is needed to cope with non-fail-stop faults
Passive replication One of the replicas is designated as the primary replica Only the primary replica executes requests The state of the primary replica is transferred to the backups
periodically or after every request processing Semi-active replication
One of the replicas is designated as the leader (or primary) The leader determines the order of execution Every input is executed by every replica per the leader’s
Implementation of Service Replication:Ensuring Strong Replica Ensuring Strong Replica ConsistencyConsistency For active replication,
use a group communication system or a consensus algorithm that guarantees total ordering of all messages (plus deterministic processing in each replica)
Attempting to Fix Write-All-Available Problem caused by accessing the not-fully-recovered
replica => how about preventing this? Still won’t work
Ti does not precedes Tj because Tj reads y before Ti writes to y Tj does not precedes Ti because Ti reads x before Tj writes to x Ti: R(x), W(y) Tj: R(y), W(x) Hence, Ti and Tj are not serializable!
Insight to the Problem The problem is caused by the fact that conflicting
operations are performed at difference replicas We must prevent this from happening A solution: use quorum-based consensus What is a quorum?
Given a system with n processes, a quorum is formed by a subset of the processes in the system
Any two quorums must intersect in at least one process Read quorum: a quorum formed for read ops Write quorum: a quorum formed for write ops
A Quorum-Based Replication Algorithm Basic idea:
Write ops apply to a write quorum Read ops apply to a read quorum Fault tolerance: given total number replicas N and
write quorum size W (>= read quorum size R), can tolerate up to N-W failures
Quorum rule Each replica assigned a positive weight, e.g., 1 A read quorum has a min total weight RT A write quorum has a min total weight WT RT+WT > total weight && 2WT > total weight
A Quorum-Based Replication Algorithm Since update is applied to a quorum of replicas, we need to track which replica has the latest value => use version numbers Version number is incremented after each update
Read rule A read on data x is mapped to a read quorum replicas of x Each replica returns both the value of x and its version
number The client select the value that has the highest version
number
A Quorum-Based Replication Algorithm Write rule A write op on data x is mapped to a write quorum replicas
of x First, retrieve version numbers from the replicas, set
v=vmax+1 for this write op Write to the replicas (in the write quorum) with new value
and version # v. A replica overwrites both the value and version number v