CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Consistency --- 2 Steve Ko Computer Sciences and Engineering University at Buffalo.

Slides:



Advertisements
Similar presentations
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Reliable Multicast Steve Ko Computer Sciences and Engineering University at Buffalo.
Advertisements

CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Byzantine Fault Tolerance Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Replication Steve Ko Computer Sciences and Engineering University at Buffalo.
DISTRIBUTED SYSTEMS II REPLICATION CNT. II Prof Philippas Tsigas Distributed Computing and Systems Research Group.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Systems Fall 2010 Replication Fall 20105DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
1 Chapter 14: Replication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001 Presentation.
Distributed Systems Fall 2011 Gossip and highly available services.
Distributed Systems Fall 2009 Replication Fall 20095DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Mid-Semester Overview Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Distributed Shared Memory Steve Ko Computer Sciences and Engineering University at Buffalo.
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Replication with View Synchronous Group Communication Steve Ko Computer Sciences and Engineering.
CSE 486/586 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Gossiping Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Wrap-up Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
IM NTU Distributed Information Systems 2004 Replication Management -- 1 Replication Management Yih-Kuen Tsay Dept. of Information Management National Taiwan.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Replication Steve Ko Computer Sciences and Engineering University at Buffalo.
CS542: Topics in Distributed Systems Replication.
Replication (1). Topics r Why Replication? r System Model r Consistency Models – How do we reason about the consistency of the “global state”? m Data-centric.
CSE 486/586 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Gossiping Steve Ko Computer Sciences and Engineering University at Buffalo.
Fault Tolerant Services
1 Distribuerede systemer og sikkerhed – 21. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion & Leader Election Steve Ko Computer Sciences and Engineering University.
Replication and Group Communication. Management of Replicated Data FE Requests and replies C Replica C Service Clients Front ends managers RM FE RM Instructor’s.
Replication Improves reliability Improves availability ( What good is a reliable system if it is not available?) Replication must be transparent and create.
CSE 486/586 Distributed Systems Consistency --- 3
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Replication Steve Ko Computer Sciences and Engineering University at Buffalo.
Lecture 13: Replication Haibin Zhu, PhD. Assistant Professor Department of Computer Science Nipissing University © 2002.
CSE 486/586 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Transactions on Replicated Data Steve Ko Computer Sciences and Engineering University at Buffalo.
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 Gossiping Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Computing Systems Replication Dr. Sunny Jeong. Mr. Colin Zhang With Thanks to Prof. G. Coulouris,
Replication Chapter Katherine Dawicki. Motivations Performance enhancement Increased availability Fault Tolerance.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586 Distributed Systems Reliable Multicast --- 1
CSE 486/586 Distributed Systems Wrap-up
CSE 486/586 Distributed Systems Consistency --- 2
CSE 486/586 Distributed Systems Mid-Semester Overview
CSE 486/586 Distributed Systems Consistency --- 2
CSE 486/586 Distributed Systems Consistency --- 1
CSE 486/586 Distributed Systems Logical Time
CSE 486/586 Distributed Systems Wrap-up
CSE 486/586 Distributed Systems Logical Time
Replication and Consistency
CSE 486/586 Distributed Systems Consistency --- 3
Replication and Consistency
CSE 486/586 Distributed Systems Consistency --- 1
Active replication for fault tolerance
CSE 486/586 Distributed Systems Concurrency Control --- 3
Lecture 21: Replication Control
Lecture 21: Replication Control
CSE 486/586 Distributed Systems Consistency --- 2
CSE 486/586 Distributed Systems Consistency --- 3
CSE 486/586 Distributed Systems Consistency --- 1
CSE 486/586 Distributed Systems Reliable Multicast --- 2
CSE 486/586 Distributed Systems Logical Time
CSE 486/586 Distributed Systems Concurrency Control --- 3
Replication and Consistency
CSE 486/586 Distributed Systems Reliable Multicast --- 1
Presentation transcript:

CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo

CSE 486/586, Spring 2014 Recap: Linearizability Linearizability –Should provide the behavior of a single copy –A read operation returns the most recent write, regardless of the clients. –“The most recent”: determined by time. Complication –In the presence of concurrency, read/write operations overlap. 2

CSE 486/586, Spring 2014 Recap: Linearizability Complications Non-overlapping ops: time-based clear-cut ordering Overlapping ops: not clear-cut with time 3 a.write(x) a.read() a.write(x) a.read() a.write(y)

CSE 486/586, Spring 2014 Linearizability Examples Example 1 Example 2 4 a.write(x) a.read() -> x a.write(x) a.read() -> 0 a.read() -> x If this were a.read() -> 0, it wouldn’t support linearizability.

CSE 486/586, Spring 2014 Linearizability Examples Example 3 5 a.write(x) a.read() -> x a.read() -> y a.read() -> x a.write(y)

CSE 486/586, Spring 2014 Chain Replication One technique to provide linearizability 6 N0N1N2 ReadsReplies Writes HeadTail

CSE 486/586, Spring 2014 Passive (Primary-Backup) Replication Request Communication: the request is issued to the primary RM and carries a unique request id. Coordination: Primary takes requests atomically, in order, checks id (resends response if not new id.) Execution: Primary executes & stores the response Agreement: If update, primary sends updated state/result, req-id and response to all backup RMs (1-phase commit enough). Response: primary sends result to the front end 7 Client Front End RM Client Front End RM primary Backup ….

CSE 486/586, Spring 2014 CSE 486/586 Administrivia PA3 deadline: 4/11 (Friday) 8

CSE 486/586, Spring 2014 Linearizability vs. Sequential Consistency Both care about giving an illusion of a single copy. –From the outside observer, the system should (almost) behave as if there’s only a single copy. Linearizability cares about time. –Steve writes on his facebook wall at 11am. –Atri writes on his facebook wall at 11:05am. –Everyone will see the posts in that order. Sequential consistency cares about program order. –Steve writes on his facebook wall at 11am. –Atri writes on his facebook wall at 11:05am. –It’s not necessarily that the posts will be ordered that way (though everyone will see the same order). 9

CSE 486/586, Spring 2014 Sequential Consistency Sequential consistency –Should provide the behavior of a single copy –A read operation returns the most recent write, regardless of the clients. “most recent” – Ops within the same client: determined by time (program order) –Ops across clients: Not determined by time, i.e., we can re- order them. –I.e., we just need to preserve the program order 10

CSE 486/586, Spring 2014 Sequential Consistency To the outside observer, the system needs to provide a global ordering of operations where: –It works like a single copy. –The ordering of ops coming from the same client is preserved. Linearizability vs. sequential consistency –With sequential consistency, the system has freedom as to how to interleave operations coming from different clients, as long as the ordering from each client is preserved. –With linearizability, the interleaving across all clients is pretty much determined already based on time. 11

CSE 486/586, Spring 2014 Sequential Consistency Examples Example 1 –P1: a.write(A) –P2: a.write(B) –P3: a.read()->B a.read()->A –P4: a.read()->B a.read()->A Example 2 –P1: a.write(A) –P2: a.write(B) –P3: a.read()->B a.read()->A –P4: a.read()->A a.read()->B 12

CSE 486/586, Spring 2014 Active Replication 13 Request Communication: The request contains a unique identifier and is multicast to all by a reliable totally-ordered multicast. Coordination: Group communication ensures that requests are delivered to each RM in the same order (but may be at different physical times!). Execution: Each replica executes the request. (Correct replicas return same result since they are running the same program, i.e., they are replicated protocols or replicated state machines) Agreement: No agreement phase is needed, because of multicast delivery semantics of requests Response: Each replica sends response directly to FE Client Front End RM Client Front End RM ….

CSE 486/586, Spring 2014 Two More Consistency Models Even more relaxed –We don’t even care about providing an illusion of a single copy. Causal consistency –We care about ordering causally related write operations correctly. Eventual consistency (next lecture) –As long as we can say all replicas converge to the same copy eventually, we’re fine. 14

CSE 486/586, Spring 2014 Summary Linearizability –The ordering of operations is determined by time. –Primary-backup can provide linearizability. –Chain replication can also provide linearizability. Sequential consistency –The ordering of operations preserves the program order of each client. –Active replication can provide sequential consistency. 15

CSE 486/586, Spring Acknowledgements These slides contain material developed and copyrighted by Indranil Gupta (UIUC).