Prophecy: Using History for High Throughput Fault Tolerance
|
|
|
- Lily Stevens
- 5 years ago
- Views:
Transcription
1 Prophecy: Using History for High Throughput Fault Tolerance Siddhartha Sen Joint work with Wyatt Lloyd and Mike Freedman Princeton University
2 Non crash failures happen
3 Non crash failures happen Model as Byzantine (malicious)
4 Mask Byzantine faults Service
5 Mask Byzantine faults Throughput Replicated service
6 Mask Byzantine faults Throughput Replicated service
7 Mask Byzantine faults Throughput Replicated service
8 Mask Byzantine faults Throughput Replicated service
9 Mask Byzantine faults Throughput Linearizability (t (strong consistency) it Replicated service
10 Byzantine fault tolerance (BFT) Low throughput Modifies clients Long lived sessions
11 Prophecy High throughput + good consistency No free lunch: Read mostly workloads Slightly weakened consistency
12 Byzantine fault tolerance (BFT) Low throughput Modifies clients Long lived sessions D Prophecy Prophecy
13 Traditional BFT reads application Replica Group
14 Traditional BFT reads application Agree? Replica Group
15 A cache solution cache application Replica Group
16 A cache solution cache application Agree? Replica Group
17 A cache solution cache application Problems: Agree? Huge cache Invalidation Replica Group
18 A compact cache cache application Requests req1 req2 req3 Responses resp1 resp2 resp3 Replica Group
19 A compact cache cache application Requests sketch(req1) sketch(req2) sketch(req3) Responses sketch(resp1) sketch(resp2) sketch(resp3) Replica Group
20 A sketcher sketcher application Replica Group
21 Executing a read sketch webpage Replica Group
22 Executing a read sketch webpage Replica Group
23 Executing a read sketch webpage Replica Group
24 Executing a read sketch webpage Agree? Replica Group
25 Executing a read sketch webpage Agree? Fast, load balanced reads Replica Group
26 Executing a read sketch webpage Agree? Replica Group
27 Executing a read sketch webpage Replica Group
28 Executing a read sketch webpage key value store replicated state machine Replica Group
29 Executing a read sketch webpage Replica Group
30 Executing a read sketch webpage Replica Group
31 Executing a read sketch webpage Replica Group
32 Executing a read sketch webpage Agree? Replica Group
33 Executing a read sketch webpage Agree? Maintain a fresh cache Replica Group
34 Did we achieve linearizability? i NO!
35 Executing a read sketch webpage Replica Group
36 Executing a read sketch webpage Replica Group
37 Executing a read sketch webpage Agree? Replica Group
38 Executing a read sketch webpage Replica Group
39 Executing a read sketch webpage Agree? Replica Group
40 Executing a read sketch webpage Agree? Fast reads may be stale Replica Group
41 Load balancing sketch webpage Replica Group
42 Load balancing sketch webpage Agree? Replica Group
43 Load balancing sketch webpage Agree? Pr(k stale) = g k Replica Group
44 D Prophecy vs. BFT Traditional BFT: Each replica executes read Linearizability Replica Group D Prophecy: One replica executes read Delay once linearizability
45 Byzantine fault tolerance (BFT) Low throughput Modifies clients Long lived sessions D Prophecy Prophecy
46 Key exchange exchange overhead
47 Key exchange exchange overhead 11%
48 Key exchange exchange overhead 3% 11%
49 Internet services Replica Group
50 A proxy solution Sketcher Proxy Replica Group
51 A proxy solution Consolidate sketchers Sketcher Proxy Replica Group
52 A proxy solution Consolidate sketchers Sketcher Replica Group
53 A proxy solution Sketcher must be fail stop Sketcher Trusted Replica Group
54 A proxy solution Sketcher mustbefail stop stop Trust middlebox already Small and simple Sketcher Trusted Replica Group
55 Executing a read q Sketcher Trusted Replica Group
56 Executing a read Sketcher Trusted Replica Group
57 Executing a read Sketcher Trusted Replica Group
58 Executing a read Sketcher Req s(q) ( ) Trusted Resp Replica Group
59 Executing a read Sketcher Trusted Replica Group
60 Executing a read Sketcher Trusted Replica Group
61 Executing a read Sketcher Trusted Replica Group
62 Executing a read Sketcher Req s(q) ( ) Trusted Resp Replica Group
63 Executing a read Sketcher Req s(q) ( ) Trusted Resp Replica Group
64 Prophecy Sketcher Trusted Replica Group
65 Prophecy Fast, load balanced reads Sketcher Trusted Replica Group
66 Prophecy Fast reads may be stale Sketcher Req s(q) ( ) Trusted Resp Replica Group
67 Delay once linearizability
68 Delay once linearizability
69 Delay once linearizability W, R, W, W, R, R, W, R
70 Delay once linearizability Read after write property W, R, W, W, R, R, W, R
71 Delay once linearizability Read after write property W, R, W, W, R, R, W, R
72 Example application Upload embarrassingphotos 1. Remove colleagues from ACL 2. Upload photos 3. (Refresh) Weak may reorder Delay once preserves order
73 Byzantine fault tolerance (BFT) Low throughput Modifies clients Long lived sessions D Prophecy Prophecy
74 Implementation Modified PBFT PBFT is stable, complete Competitive with Zyzzyva et. al. C++, Tamer async I/O Sketcher: 2000 LOC PBFT library: 1140 LOC PBFT client: 1000 LOC
75 Evaluation Prophecy vs. proxied PBFT Proxied systems D Prophecy vs. PBFT Non proxied systems
76 Evaluation Prophecy vs. proxied PBFT Proxied systems We will study: Performance on null workloads Performance with real replicated service Where system bottlenecks, how to scale
77 Basic setup Sketcher (100) (concurrent) Replica Group (PBFT)
78
79 Fraction of failed Fraction of failed fast reads
80 Alexa top sites: < 15% Fraction of failed fast reads
81 Small benefit on null reads
82 Small benefit on null reads
83 Apache webserver setup Sketcher Replica Group
84 Large benefit on real workload
85 Large benefit on real workload 3.7x
86 Large benefit on real workload 3.7x 2.0x
87 Large benefit on real workload 3.7x 2.0x
88 Benefit grows with work
89 Benefit grows with work
90 Benefit grows with work
91 Benefit grows with work 94μs (Apache)
92 Benefit grows with work 94μs (Apache) Null workloads are misleading!
93 Benefit grows with work
94 Single sketcher bottlenecks
95 Single sketcher bottlenecks
96 Scaling out
97 Scales linearly with replicas
98 Summary Prophecy ygood for Internet services Fast, load balanced reads D Prophecy good for traditional services Prophecy scaleslinearly linearly whilepbft stays flat Limitations: Read mostly workloads (meas. study corroborates) Delay once linearizability (useful for many apps)
99 Thank You
100 Additional slides
101 Transitions Prophecy good for read mostly workloads Are transitions ii rare in practice?
102 Measurement study Alexa top sites Access main page every 20 sec for 24 hrs
103 Mostly static content
104 Mostly static content
105 Mostly static content 15%
106 Dynamic content Rabin fingerprinting on transitions 43% differ by single contiguous change Sampled 4000 of them, over half due to: Load balancing directives Random IDs in links, function parameters
Viewstamped Replication to Practical Byzantine Fault Tolerance. Pradipta De
Viewstamped Replication to Practical Byzantine Fault Tolerance Pradipta De pradipta.de@sunykorea.ac.kr ViewStamped Replication: Basics What does VR solve? VR supports replicated service Abstraction is
Reducing the Costs of Large-Scale BFT Replication
Reducing the Costs of Large-Scale BFT Replication Marco Serafini & Neeraj Suri TU Darmstadt, Germany Neeraj Suri EU-NSF ICT March 2006 Dependable Embedded Systems & SW Group www.deeds.informatik.tu-darmstadt.de
Zyzzyva. Speculative Byzantine Fault Tolerance. Ramakrishna Kotla. L. Alvisi, M. Dahlin, A. Clement, E. Wong University of Texas at Austin
Zyzzyva Speculative Byzantine Fault Tolerance Ramakrishna Kotla L. Alvisi, M. Dahlin, A. Clement, E. Wong University of Texas at Austin The Goal Transform high-performance service into high-performance
Robust BFT Protocols
Robust BFT Protocols Sonia Ben Mokhtar, LIRIS, CNRS, Lyon Joint work with Pierre Louis Aublin, Grenoble university Vivien Quéma, Grenoble INP 18/10/2013 Who am I? CNRS reseacher, LIRIS lab, DRIM research
Replication in Distributed Systems
Replication in Distributed Systems Replication Basics Multiple copies of data kept in different nodes A set of replicas holding copies of a data Nodes can be physically very close or distributed all over
Exploiting Commutativity For Practical Fast Replication. Seo Jin Park and John Ousterhout
Exploiting Commutativity For Practical Fast Replication Seo Jin Park and John Ousterhout Overview Problem: replication adds latency and throughput overheads CURP: Consistent Unordered Replication Protocol
Byzantine Fault Tolerance and Consensus. Adi Seredinschi Distributed Programming Laboratory
Byzantine Fault Tolerance and Consensus Adi Seredinschi Distributed Programming Laboratory 1 (Original) Problem Correct process General goal: Run a distributed algorithm 2 (Original) Problem Correct process
Tolerating Latency in Replicated State Machines through Client Speculation
Tolerating Latency in Replicated State Machines through Client Speculation April 22, 2009 1, James Cowling 2, Edmund B. Nightingale 3, Peter M. Chen 1, Jason Flinn 1, Barbara Liskov 2 University of Michigan
Exploiting Commutativity For Practical Fast Replication. Seo Jin Park and John Ousterhout
Exploiting Commutativity For Practical Fast Replication Seo Jin Park and John Ousterhout Overview Problem: consistent replication adds latency and throughput overheads Why? Replication happens after ordering
Practical Byzantine Fault Tolerance (The Byzantine Generals Problem)
Practical Byzantine Fault Tolerance (The Byzantine Generals Problem) Introduction Malicious attacks and software errors that can cause arbitrary behaviors of faulty nodes are increasingly common Previous
Byzantine fault tolerance. Jinyang Li With PBFT slides from Liskov
Byzantine fault tolerance Jinyang Li With PBFT slides from Liskov What we ve learnt so far: tolerate fail-stop failures Traditional RSM tolerates benign failures Node crashes Network partitions A RSM w/
Replication. Consistency models. Replica placement Distribution protocols
Replication Motivation Consistency models Data/Client-centric consistency models Replica placement Distribution protocols Invalidate versus updates Push versus Pull Cooperation between replicas Client-centric
Towards Recoverable Hybrid Byzantine Consensus
Towards Recoverable Hybrid Byzantine Consensus Hans P. Reiser 1, Rüdiger Kapitza 2 1 University of Lisboa, Portugal 2 University of Erlangen-Nürnberg, Germany September 22, 2009 Overview 1 Background Why?
Today: Fault Tolerance. Replica Management
Today: Fault Tolerance Failure models Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Failure recovery
Consistency & Replication
Objectives Consistency & Replication Instructor: Dr. Tongping Liu To understand replication and related issues in distributed systems" To learn about how to keep multiple replicas consistent with each
Implementation Issues. Remote-Write Protocols
Implementation Issues Two techniques to implement consistency models Primary-based protocols Assume a primary replica for each data item Primary responsible for coordinating all writes Replicated write
Replication of Data. Data-Centric Consistency Models. Reliability vs. Availability
CIS 505: Software Systems Lecture Note on Consistency and Replication Instructor: Insup Lee Department of Computer and Information Science University of Pennsylvania CIS 505, Spring 2007 Replication of
RailCloud: A Reliable PaaS Cloud for Railway Applications
Platzhalter für Bild, Bild auf Titelfolie hinter das Logo einsetzen RailCloud: A Reliable PaaS Cloud for Railway Applications Bijun Li, Rüdiger Kapitza TU Braunschweig 06.10.2016 This work is supported
There Is More Consensus in Egalitarian Parliaments
There Is More Consensus in Egalitarian Parliaments Iulian Moraru, David Andersen, Michael Kaminsky Carnegie Mellon University Intel Labs Fault tolerance Redundancy State Machine Replication 3 State Machine
Last Class: Consistency Models. Today: Implementation Issues
Last Class: Consistency Models Need for replication Data-centric consistency Strict, linearizable, sequential, causal, FIFO Lecture 15, page 1 Today: Implementation Issues Replica placement Use web caching
CPS 512 midterm exam #1, 10/7/2016
CPS 512 midterm exam #1, 10/7/2016 Your name please: NetID: Answer all questions. Please attempt to confine your answers to the boxes provided. If you don t know the answer to a question, then just say
EECS 498 Introduction to Distributed Systems
EECS 498 Introduction to Distributed Systems Fall 2017 Harsha V. Madhyastha Implementing RSMs Logical clock based ordering of requests Cannot serve requests if any one replica is down Primary-backup replication
Scalable Causal Consistency for Wide-Area Storage with COPS
Don t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS Wyatt Lloyd * Michael J. Freedman * Michael Kaminsky David G. Andersen * Princeton, Intel Labs, CMU The Key-value
Practical Byzantine Fault Tolerance
Practical Byzantine Fault Tolerance Robert Grimm New York University (Partially based on notes by Eric Brewer and David Mazières) The Three Questions What is the problem? What is new or different? What
Failure models. Byzantine Fault Tolerance. What can go wrong? Paxos is fail-stop tolerant. BFT model. BFT replication 5/25/18
Failure models Byzantine Fault Tolerance Fail-stop: nodes either execute the protocol correctly or just stop Byzantine failures: nodes can behave in any arbitrary way Send illegal messages, try to trick
Distributed File Systems II
Distributed File Systems II To do q Very-large scale: Google FS, Hadoop FS, BigTable q Next time: Naming things GFS A radically new environment NFS, etc. Independence Small Scale Variety of workloads Cooperation
ECE 7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective
ECE 7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective Part II: Data Center Software Architecture: Topic 1: Distributed File Systems GFS (The Google File System) 1 Filesystems
Designing Distributed Systems using Approximate Synchrony in Data Center Networks
Designing Distributed Systems using Approximate Synchrony in Data Center Networks Dan R. K. Ports Jialin Li Naveen Kr. Sharma Vincent Liu Arvind Krishnamurthy University of Washington CSE Today s most
SpecPaxos. James Connolly && Harrison Davis
SpecPaxos James Connolly && Harrison Davis Overview Background Fast Paxos Traditional Paxos Implementations Data Centers Mostly-Ordered-Multicast Network layer Speculative Paxos Protocol Application layer
Replications and Consensus
CPSC 426/526 Replications and Consensus Ennan Zhai Computer Science Department Yale University Recall: Lec-8 and 9 In the lec-8 and 9, we learned: - Cloud storage and data processing - File system: Google
Scalable Enterprise Networks with Inexpensive Switches
Scalable Enterprise Networks with Inexpensive Switches Minlan Yu minlanyu@cs.princeton.edu Princeton University Joint work with Alex Fabrikant, Mike Freedman, Jennifer Rexford and Jia Wang 1 Enterprises
The Google File System
The Google File System Sanjay Ghemawat, Howard Gobioff and Shun Tak Leung Google* Shivesh Kumar Sharma fl4164@wayne.edu Fall 2015 004395771 Overview Google file system is a scalable distributed file system
Recall use of logical clocks
Causal Consistency Consistency models Linearizability Causal Eventual COS 418: Distributed Systems Lecture 16 Sequential Michael Freedman 2 Recall use of logical clocks Lamport clocks: C(a) < C(z) Conclusion:
Consistency and Replication. Why replicate?
Consistency and Replication Today: Introduction Consistency models Data-centric consistency models Client-centric consistency models Thoughts for the mid-term Lecture 14, page 1 Why replicate? Data replication:
Important Lessons. Today's Lecture. Two Views of Distributed Systems
Important Lessons Replication good for performance/ reliability Key challenge keeping replicas up-to-date Wide range of consistency models Will see more next lecture Range of correctness properties L-10
Middleware and Distributed Systems. System Models. Dr. Martin v. Löwis
Middleware and Distributed Systems System Models Dr. Martin v. Löwis System Models (Coulouris et al.) Architectural models of distributed systems placement of parts and relationships between them e.g.
Fault Tolerance via the State Machine Replication Approach. Favian Contreras
Fault Tolerance via the State Machine Replication Approach Favian Contreras Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial Written by Fred Schneider Why a Tutorial? The
Zyzzyva: Speculative Byzantine Fault Tolerance
: Speculative Byzantine Fault Tolerance Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong Dept. of Computer Sciences University of Texas at Austin {kotla,lorenzo,dahlin,aclement,elwong}@cs.utexas.edu
Practical Byzantine Fault
Practical Byzantine Fault Tolerance Practical Byzantine Fault Tolerance Castro and Liskov, OSDI 1999 Nathan Baker, presenting on 23 September 2005 What is a Byzantine fault? Rationale for Byzantine Fault
Key-value store with eventual consistency without trusting individual nodes
basementdb Key-value store with eventual consistency without trusting individual nodes https://github.com/spferical/basementdb 1. Abstract basementdb is an eventually-consistent key-value store, composed
Distributed Systems. replication Johan Montelius ID2201. Distributed Systems ID2201
Distributed Systems ID2201 replication Johan Montelius 1 The problem The problem we have: servers might be unavailable The solution: keep duplicates at different servers 2 Building a fault-tolerant service
Goals. Facebook s Scaling Problem. Scaling Strategy. Facebook Three Layer Architecture. Workload. Memcache as a Service.
Goals Memcache as a Service Tom Anderson Rapid application development - Speed of adding new features is paramount Scale Billions of users Every user on FB all the time Performance Low latency for every
Eventual Consistency. Eventual Consistency
Eventual Consistency Many systems: one or few processes perform updates How frequently should these updates be made available to other read-only processes? Examples: DNS: single naming authority per domain
Today: World Wide Web! Traditional Web-Based Systems!
Today: World Wide Web! WWW principles Case Study: web caching as an illustrative example Invalidate versus updates Push versus Pull Cooperation between replicas Lecture 22, page 1 Traditional Web-Based
A Byzantine Fault-Tolerant Ordering Service for the Hyperledger Fabric Blockchain Platform
A Byzantine Fault-Tolerant Ordering Service for the Hyperledger Fabric Blockchain Platform João Sousa, Alysson Bessani, Marko Vukolić* Faculdade de Ciências, Universidade de Lisboa *IBM Research Zurich
Causal Consistency. CS 240: Computing Systems and Concurrency Lecture 16. Marco Canini
Causal Consistency CS 240: Computing Systems and Concurrency Lecture 16 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. Consistency models Linearizability
CS6450: Distributed Systems Lecture 15. Ryan Stutsman
Strong Consistency CS6450: Distributed Systems Lecture 15 Ryan Stutsman Material taken/derived from Princeton COS-418 materials created by Michael Freedman and Kyle Jamieson at Princeton University. Licensed
IX: A Protected Dataplane Operating System for High Throughput and Low Latency
IX: A Protected Dataplane Operating System for High Throughput and Low Latency Belay, A. et al. Proc. of the 11th USENIX Symp. on OSDI, pp. 49-65, 2014. Reviewed by Chun-Yu and Xinghao Li Summary In this
All about Eve: Execute-Verify Replication for Multi-Core Servers
All about Eve: Execute-Verify Replication for Multi-Core Servers Manos Kapritsos, Yang Wang, Vivien Quema, Allen Clement, Lorenzo Alvisi, Mike Dahlin Dependability Multi-core Databases Key-value stores
Practical Byzantine Fault Tolerance Consensus and A Simple Distributed Ledger Application Hao Xu Muyun Chen Xin Li
Practical Byzantine Fault Tolerance Consensus and A Simple Distributed Ledger Application Hao Xu Muyun Chen Xin Li Abstract Along with cryptocurrencies become a great success known to the world, how to
Today: Fault Tolerance. Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
ZZ and the Art of Practical BFT Execution
To appear in EuroSys 2 and the Art of Practical BFT Execution Timothy Wood, Rahul Singh, Arun Venkataramani, Prashant Shenoy, And Emmanuel Cecchet Department of Computer Science, University of Massachusetts
GFS Overview. Design goals/priorities Design for big-data workloads Huge files, mostly appends, concurrency, huge bandwidth Design for failures
GFS Overview Design goals/priorities Design for big-data workloads Huge files, mostly appends, concurrency, huge bandwidth Design for failures Interface: non-posix New op: record appends (atomicity matters,
Zzyzx: Scalable Fault Tolerance through Byzantine Locking
Zzyzx: Scalable Fault Tolerance through Byzantine Locking James Hendricks Shafeeq Sinnamohideen Gregory R. Ganger Michael K. Reiter Carnegie Mellon University University of North Carolina at Chapel Hill
Today: Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Distributed Systems. Lec 10: Distributed File Systems GFS. Slide acks: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
Distributed Systems Lec 10: Distributed File Systems GFS Slide acks: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung 1 Distributed File Systems NFS AFS GFS Some themes in these classes: Workload-oriented
CPSC 426/526. Cloud Computing. Ennan Zhai. Computer Science Department Yale University
CPSC 426/526 Cloud Computing Ennan Zhai Computer Science Department Yale University Recall: Lec-7 In the lec-7, I talked about: - P2P vs Enterprise control - Firewall - NATs - Software defined network
Performance Evaluation of Virtualization Technologies
Performance Evaluation of Virtualization Technologies Saad Arif Dept. of Electrical Engineering and Computer Science University of Central Florida - Orlando, FL September 19, 2013 1 Introduction 1 Introduction
The Google File System (GFS)
1 The Google File System (GFS) CS60002: Distributed Systems Antonio Bruto da Costa Ph.D. Student, Formal Methods Lab, Dept. of Computer Sc. & Engg., Indian Institute of Technology Kharagpur 2 Design constraints
Flexible, Wide-Area Storage for Distributed Systems Using Semantic Cues
Flexible, Wide-Area Storage for Distributed Systems Using Semantic Cues Jeremy Stribling Thesis Defense, August 6, 2009 Including material previously published in: Flexible, Wide-Area Storage for Distributed
Security (and finale) Dan Ports, CSEP 552
Security (and finale) Dan Ports, CSEP 552 Today Security: what if parts of your distributed system are malicious? BFT: state machine replication Bitcoin: peer-to-peer currency Course wrap-up Security Too
Zeno: Eventually Consistent Byzantine-Fault Tolerance
Zeno: Eventually Consistent Byzantine-Fault Tolerance Atul Singh 1,2, Pedro Fonseca 1, Petr Kuznetsov 3, Rodrigo Rodrigues 1, Petros Maniatis 4 1 MPI-SWS, 2 Rice University, 3 TU Berlin/Deutsche Telekom
Ovid A Software-Defined Distributed Systems Framework. Deniz Altinbuken, Robbert van Renesse Cornell University
Ovid A Software-Defined Distributed Systems Framework Deniz Altinbuken, Robbert van Renesse Cornell University Ovid Build distributed systems that are easy to evolve easy to reason about easy to compose
Evaluating BFT Protocols for Spire
Evaluating BFT Protocols for Spire Henry Schuh & Sam Beckley 600.667 Advanced Distributed Systems & Networks SCADA & Spire Overview High-Performance, Scalable Spire Trusted Platform Module Known Network
AS distributed systems develop and grow in size,
1 hbft: Speculative Byzantine Fault Tolerance With Minimum Cost Sisi Duan, Sean Peisert, Senior Member, IEEE, and Karl N. Levitt Abstract We present hbft, a hybrid, Byzantine fault-tolerant, ted state
Architekturen für die Cloud
Architekturen für die Cloud Eberhard Wolff Architecture & Technology Manager adesso AG 08.06.11 What is Cloud? National Institute for Standards and Technology (NIST) Definition On-demand self-service >
CA485 Ray Walshe Google File System
Google File System Overview Google File System is scalable, distributed file system on inexpensive commodity hardware that provides: Fault Tolerance File system runs on hundreds or thousands of storage
Dynamic Metadata Management for Petabyte-scale File Systems
Dynamic Metadata Management for Petabyte-scale File Systems Sage Weil Kristal T. Pollack, Scott A. Brandt, Ethan L. Miller UC Santa Cruz November 1, 2006 Presented by Jae Geuk, Kim System Overview Petabytes
Strong Consistency & CAP Theorem
Strong Consistency & CAP Theorem CS 240: Computing Systems and Concurrency Lecture 15 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. Consistency models
ZHT: Const Eventual Consistency Support For ZHT. Group Member: Shukun Xie Ran Xin
ZHT: Const Eventual Consistency Support For ZHT Group Member: Shukun Xie Ran Xin Outline Problem Description Project Overview Solution Maintains Replica List for Each Server Operation without Primary Server
Advanced Database Systems
Advanced Database Systems DBMS Internals Data structures and algorithms to implement RDBMS Internals of non relational data management systems Why to take this course? To understand the strengths and weaknesses
NFS: Naming indirection, abstraction. Abstraction, abstraction, abstraction! Network File Systems: Naming, cache control, consistency
Abstraction, abstraction, abstraction! Network File Systems: Naming, cache control, consistency Local file systems Disks are terrible abstractions: low-level blocks, etc. Directories, files, links much
Fault Tolerance. Goals: transparent: mask (i.e., completely recover from) all failures, or predictable: exhibit a well defined failure behavior
Fault Tolerance Causes of failure: process failure machine failure network failure Goals: transparent: mask (i.e., completely recover from) all failures, or predictable: exhibit a well defined failure
Erasure Coding in Object Stores: Challenges and Opportunities
Erasure Coding in Object Stores: Challenges and Opportunities Lewis Tseng Boston College July 2018, PODC Acknowledgements Nancy Lynch Muriel Medard Kishori Konwar Prakash Narayana Moorthy Viveck R. Cadambe
DISTRIBUTED COMPUTER SYSTEMS
DISTRIBUTED COMPUTER SYSTEMS CONSISTENCY AND REPLICATION CONSISTENCY MODELS Dr. Jack Lange Computer Science Department University of Pittsburgh Fall 2015 Consistency Models Background Replication Motivation
Consistency and Replication
Topics to be covered Introduction Consistency and Replication Consistency Models Distribution Protocols Consistency Protocols 1 2 + Performance + Reliability Introduction Introduction Availability: proportion
SAREK: Optimistic Parallel Ordering in Byzantine Fault Tolerance
SAREK: Optimistic Parallel Ordering in Byzantine Fault Tolerance Bijun Li TU Braunschweig bli@ibr.cs.tu-bs.de Wenbo Xu TU Braunschweig wxu@ibr.cs.tu-bs.de Muhammad Zeeshan Abid KTH Stockholm mzabid@kth.se
Hyperbolic Caching: Flexible Caching for Web Applications
Hyperbolic Caching: Flexible Caching for Web Applications Aaron Blankstein Princeton University (now @ Blockstack Inc.) Siddhartha Sen Microsoft Research NY Michael J. Freedman Princeton University Modern
EECS 482 Introduction to Operating Systems
EECS 482 Introduction to Operating Systems Winter 2018 Baris Kasikci (Thanks, Harsha Madhyastha and Jason Flinn for the slides!) Distributed file systems Remote storage of data that appears local Examples:
Consistency-preserving Caching of Dynamic Database Content
Consistency-preserving Caching of Dynamic Database Content Niraj Tolia M. Satyanarayanan Carnegie Mellon University Motivation Database Server Web and App. Servers Easy to geographically distribute web
Verdi: A Framework for Implementing and Formally Verifying Distributed Systems
Verdi: A Framework for Implementing and Formally Verifying Distributed Systems Key-value store VST James R. Wilcox, Doug Woos, Pavel Panchekha, Zach Tatlock, Xi Wang, Michael D. Ernst, Thomas Anderson
The Google File System
October 13, 2010 Based on: S. Ghemawat, H. Gobioff, and S.-T. Leung: The Google file system, in Proceedings ACM SOSP 2003, Lake George, NY, USA, October 2003. 1 Assumptions Interface Architecture Single
NPTEL Course Jan K. Gopinath Indian Institute of Science
Storage Systems NPTEL Course Jan 2012 (Lecture 39) K. Gopinath Indian Institute of Science Google File System Non-Posix scalable distr file system for large distr dataintensive applications performance,
Failure Models. Fault Tolerance. Failure Masking by Redundancy. Agreement in Faulty Systems
Fault Tolerance Fault cause of an error that might lead to failure; could be transient, intermittent, or permanent Fault tolerance a system can provide its services even in the presence of faults Requirements
Byzantine Fault Tolerance
Byzantine Fault Tolerance CS 240: Computing Systems and Concurrency Lecture 11 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. So far: Fail-stop failures
Distributed Systems. Characteristics of Distributed Systems. Lecture Notes 1 Basic Concepts. Operating Systems. Anand Tripathi
1 Lecture Notes 1 Basic Concepts Anand Tripathi CSci 8980 Operating Systems Anand Tripathi CSci 8980 1 Distributed Systems A set of computers (hosts or nodes) connected through a communication network.
Distributed Systems. Characteristics of Distributed Systems. Characteristics of Distributed Systems. Goals in Distributed System Designs
1 Anand Tripathi CSci 8980 Operating Systems Lecture Notes 1 Basic Concepts Distributed Systems A set of computers (hosts or nodes) connected through a communication network. Nodes may have different speeds
TAPIR. By Irene Zhang, Naveen Sharma, Adriana Szekeres, Arvind Krishnamurthy, and Dan Ports Presented by Todd Charlton
TAPIR By Irene Zhang, Naveen Sharma, Adriana Szekeres, Arvind Krishnamurthy, and Dan Ports Presented by Todd Charlton Outline Problem Space Inconsistent Replication TAPIR Evaluation Conclusion Problem
Blockchain. CS 240: Computing Systems and Concurrency Lecture 20. Marco Canini
Blockchain CS 240: Computing Systems and Concurrency Lecture 20 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. Bitcoin: 10,000 foot view New bitcoins
Last Class:Consistency Semantics. Today: More on Consistency
Last Class:Consistency Semantics Consistency models Data-centric consistency models Client-centric consistency models Eventual Consistency and epidemic protocols Lecture 16, page 1 Today: More on Consistency
SDPaxos: Building Efficient Semi-Decentralized Geo-replicated State Machines
SDPaxos: Building Efficient Semi-Decentralized Geo-replicated State Machines Hanyu Zhao *, Quanlu Zhang, Zhi Yang *, Ming Wu, Yafei Dai * * Peking University Microsoft Research Replication for Fault Tolerance
Distributed Systems COMP 212. Lecture 19 Othon Michail
Distributed Systems COMP 212 Lecture 19 Othon Michail Fault Tolerance 2/31 What is a Distributed System? 3/31 Distributed vs Single-machine Systems A key difference: partial failures One component fails
A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm
Appears as Technical Memo MIT/LCS/TM-590, MIT Laboratory for Computer Science, June 1999 A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm Miguel Castro and Barbara Liskov
A definition. Byzantine Generals Problem. Synchronous, Byzantine world
The Byzantine Generals Problem Leslie Lamport, Robert Shostak, and Marshall Pease ACM TOPLAS 1982 Practical Byzantine Fault Tolerance Miguel Castro and Barbara Liskov OSDI 1999 A definition Byzantine (www.m-w.com):
Basic vs. Reliable Multicast
Basic vs. Reliable Multicast Basic multicast does not consider process crashes. Reliable multicast does. So far, we considered the basic versions of ordered multicasts. What about the reliable versions?
Eventual Consistency Today: Limitations, Extensions and Beyond
Eventual Consistency Today: Limitations, Extensions and Beyond Peter Bailis and Ali Ghodsi, UC Berkeley - Nomchin Banga Outline Eventual Consistency: History and Concepts How eventual is eventual consistency?
ECE 7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective
ECE 7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective Part II: Software Infrastructure in Data Centers: Distributed File Systems 1 Permanently stores data Filesystems
Atomicity. Bailu Ding. Oct 18, Bailu Ding Atomicity Oct 18, / 38
Atomicity Bailu Ding Oct 18, 2012 Bailu Ding Atomicity Oct 18, 2012 1 / 38 Outline 1 Introduction 2 State Machine 3 Sinfonia 4 Dangers of Replication Bailu Ding Atomicity Oct 18, 2012 2 / 38 Introduction
Process groups and message ordering
Process groups and message ordering If processes belong to groups, certain algorithms can be used that depend on group properties membership create ( name ), kill ( name ) join ( name, process ), leave
Two New Protocols for Fault Tolerant Agreement
Two New Protocols for Fault Tolerant Agreement Poonam Saini 1 and Awadhesh Kumar Singh 2, 1,2 Department of Computer Engineering, National Institute of Technology, Kurukshetra, India nit.sainipoonam@gmail.com,