1 / 17

Depot: Cloud Storage with Minimal Trust OSDI 2010

Depot: Cloud Storage with Minimal Trust OSDI 2010. Prince Mahajan , Srinath Setty , Sangmin Lee, Allen Clement, Lorenzo Alvisi , Mike Dahlin , and Michael Walfish The University of Texas at Austin. Presented by: Masoud SAEIDA ARDEKANI 24/11/2011. Motivation. Cloud services are:

mirra
Download Presentation

Depot: Cloud Storage with Minimal Trust OSDI 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Depot: Cloud Storage with Minimal TrustOSDI 2010 Prince Mahajan, SrinathSetty, Sangmin Lee, Allen Clement, Lorenzo Alvisi, Mike Dahlin, and Michael Walfish The University of Texas at Austin Presented by: Masoud SAEIDA ARDEKANI 24/11/2011

  2. Motivation • Cloud services are: • Fault-prone • Black-box • Clients • Hesitate to trust cloud services • Rely on end-to-end checks of properties

  3. What is Depot? A cloud storage with minimal trust Minimizes trust for: Get availability Durability • Eliminate trust for: • Put availability • Eventual consistency • Staleness-detection • Dependency preservation

  4. Depot Overview Put (k, ) N2 • Consistency Despite Faults! • Add metadata to Puts • Add local states to nodes • Add checks on received metadata Gossip N1 Get (k) {nodeID, key, H(value), localClock, History}nodeID

  5. Checks upon receiving an update • Accept an update u sent by N if: • u must be properly signed • There is not omission • All updates in u’s history are also in local history • History is not modified • u is newer than any prior update by N

  6. But, faults can cause forks! N1 F N2 • Forks: • Node’s local view is consistent! • Inconsistent views between different nodes! • Prevent eventual consistency!

  7. Join forks for eventual consistency N1 N2 • Faulty node  Two (correct) virtual node

  8. Faults vs Concurrency • Converting faults into concurrency • Allow correct nodes to converge • Concurrency can introduce conflicts! • Already possible due to decentralized servers! • Applications for high availability allow concurrent writes • Depot exposes the conflicts to the application • GET operation returns set of most recent concurrent updates

  9. Consistency • Causal Consistency (CC) • If update u1 by a node depends on an update u0 by any node, then u0 becomes observable before u1 at any node. • Fork-Join Causal (FJC) Consistency • If update u1 by a correct node depends on an update u0 by any node, then u0 becomes observable before u1 at any correct node.

  10. Ensuring Properties • Safety (FJC consistency) • Local checks • Liveness • Reduce failures to concurrency • Joining forks

  11. Evaluation Setup • 8 Clients + 4 Servers • Quad-core Intel Xeon 2.4 GHz • 8 GB RAM • Two local 7200 RPM disk • 2 clients are connected to each other! • 1 Gbps link • Each client issue 1 request / Minute

  12. Variants • Baseline • Clients trust the servers (no local data, no checks) • B+hash • Clients attach hashes of values and verify hashes • B+hash+Signing • Clients sign the values and verifies signatures • B+hash+Signing+Store • Like B+hash+signing, plus locally store values that they put

  13. Latency of Depot

  14. Cost of Depot

  15. Behavior Under Faults • 50% Put, 50% Get • Total server failure after 300 seconds

  16. Fork by faulty clients • 50% Reads, 50% Writes • Failure after 300 seconds • No effect on Get or Put

  17. Conclusion • Depot: Cloud storage with minimal trust • Any node could fail in any way! • Eliminate trust for • Put availability • Eventual consistency • Minimize trust for • Get availability

More Related