1 / 21

FAUST: Fail-Aware Untrusted Storage

Alex Shraer, Technion, Israel. FAUST: Fail-Aware Untrusted Storage. Joint work with:. Christian Cachin IBM Zurich. Idit Keidar Technion. Agenda. Motivation Defining a Fail-Aware Untrusted Service FAUST: F ail- A ware U ntrusted ST orage Conclusions. Once upon a time ….

catherine-beasley
Download Presentation

FAUST: Fail-Aware Untrusted Storage

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. Alex Shraer, Technion, Israel FAUST: Fail-Aware Untrusted Storage Joint work with: Christian Cachin IBM Zurich Idit Keidar Technion

  2. Agenda • Motivation • Defining a Fail-Aware Untrusted Service • FAUST: Fail-Aware Untrusted STorage • Conclusions

  3. Once upon a time… strong consistency (linearizability/atomicity) strong liveness (wait-freedom) Don't be Evil (DobeE) Inc. DobeE OnlineDocs DSN paper Alice Bob Jlduiy baios kjshh jcouhc lj ljxc jcjjzxkcj hyah dg dgf gh hnbbv dg dgf gh hnbbv hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d ji khcgtu jnn mckpkk,c jjkpackm kj ihgdiash hasdg gdsihasd jdsihjhd dfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c jjkpackm kj ihgdiashhasdg hays v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcg tujnn mckpkk,c jjkpackm kj ihgdiashhasdg gdsihasd jdsihjhd dfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c jjkpackm kj ihgdiashhasdg dsihasd jdsihjhd dfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c jjkp ackm kj ihgdiashhasdg hjy v fg djjiaj djsjd ,lm cgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c packm kj ihgdiashhasdg gdsihasd jddfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb Alice Bob sometimes (email)

  4. But what if… Back in High school… DSN paper Alice Bob Jlduiy baios kjshh jcouhc lj ljxc jcjjzxkcj hyah dg dgf gh hnbbv dg dgf gh hnbbv hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d ji khcgtu jnn mckpkk,c jjkpackm kj ihgdiash hasdg gdsihasd jdsihjhd dfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c jjkpackm kj ihgdiashhasdg hays v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcg tujnn mckpkk,c jjkpackm kj ihgdiashhasdg gdsihasd jdsihjhd dfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c jjkpackm kj ihgdiashhasdg dsihasd jdsihjhd dfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c jjkp ackm kj ihgdiashhasdg hjy v fg djjiaj djsjd ,lm cgg nhycgygb cnjik d mjikhcgtujnn mckpkk,c packm kj ihgdiashhasdg gdsihasd jddfg dgtrsd hjy v fg djjiaj djsjd ,lmcgg nhycgygb Alice Bob

  5. What would we like to achieve? No bogus data Still, inconsistencies are possible Alice and Bob to detect inconsistencies Rollback to consistent state When server is correct (the common case) clients should have strong consistency and liveness for their operations Linearizability and wait-freedom

  6. Agenda • Motivation • Defining a Fail-Aware Untrusted Service • FAUST: Fail-Aware Untrusted STorage • Conclusions

  7. Eventual Consistency Client’s operations can complete even though they are only “weakly” consistent Client is notified when its operations become “strongly” consistent May invoke other operations without waiting for notifications Eventual consistency is widely accepted and used Starting with Bayou (SOSP 95) Today in commercial systems, e.g., Amazon’s Dynamo (SOSP 07)

  8. Fail-Awareness [Fetzer & Cristian 96] Provide notifications when the service does not guarantee its specified semantics means that the service shouldn’t be used Allows clients to take appropriate recovery actions

  9. Fail-Aware Untrusted Service When the server is correct – strong consistency and strong liveness Execution is always “weakly” consistent at least causal consistency Stability notifications (next slide) Accurate failure notifications Detection completeness: All operations eventually become stable unless failure is detected

  10. Example with Correct Server • Alice & Bob are from Europe, Carlos is from America • Its daytime in Europe, and Carlos is asleep • Alice’s “stability cut”: • Stability w.r.t all clients = perfect consistency

  11. Agenda • Motivation • Defining a Fail-Aware Untrusted Service • FAUST: Fail-Aware Untrusted STorage • Conclusions

  12. Fork consistency [Mazières&Shasha, PODC 02] • Server may present different views to clients • “Fork” their views of the history • In such case, their views are forked ever after (never again see each others new updates) • or else, server is exposed as faulty

  13. C1 is forked from C3 Fork-Consistency – an Example C2 is forked from C1 write(X1,u) read(X3) → null C3 is forked from C2 C1 C1 read(X3) → null read(X1) → null C2 read(X1) → u write(X3,w) C3 start (X1= X2 = X3 = null) C2 write(X1,u) read(X1) → null read(X1) → u read(X3) → null C3 C1 write(X3, w) read(X3) → null

  14. What about the common case? SUBMIT write operation SUBMIT read operation REPLY: I scheduled op1, op2, … before you value, signed context of corresponding write REPLY: I scheduled op1, op2, … before you • C2 must receive signed context of the write • Must wait until the write commits • What if the write crashes? • Formal proof in [Cachin, Shelat, Shraer 07] COMMIT op (signed context) Client Server My context is: start (I am the first operation) A Join – not allowed with fork consistency C2 is forked from C1 write(X1,u) C1 C1 read(X1) → null read(X1) → u C2 Something is wrong! My context is: start (I am the first operation)

  15. We need a weaker consistency notion • Two weaker conditions have been defined recently: • Fork-* [Li & Mazieres, NSDI 2007] • Fork-sequential-consistency [Oprea & Reiter, DISC 2006] • We show: both require blocking, in executions with 1 correct server C2

  16. Weak fork • At-most one join: If server forks the views of two clients, they may see at most one more common operation • Same as in Fork-* • Trust server about last operations by other clients in context • No checks needed • Weaker than Fork-* • Causally consistent views • Stronger than Fork-* • No blocking needed - allows wait-free protocols. In fact, suffices to achieve all properties of FAUST C2

  17. USTOR: The untrusted storage protocol SUBMIT read operation REPLY: I scheduled op1, op2, … before you value, signed context of last committed op of writer COMMIT op (signed context) Client Server Server claims that C1 committed no operations write(X1,u) C1 C1 read(X1) → null read(X1) → u C2 write(X1,u) write(X1,v) C1 C1 C2 read(X1) → v read(X1) → null read(X1) → u C2 Server can hide context of second write, but must provide context of first write C2 detects the error

  18. Some properties of USTOR • Linearizable executions with correct server • A correct server schedules & processes the ops in order of receipt • Wait-free with correct server • A read does not need to wait till some write COMMITs • COMMIT info can arrive with SUBMIT of next operation • All executions are causally consistent • From properties of Weak-fork • Detects server failure, if server returns inconsistent context information • What’s missing for FAUST? • Accurate notifications to clients: operation stability, server failure • Completeness: for every op, eventually one of the following happens: • op indicated as stable with respect to other clients • server failure detected

  19. From USTOR to FAUST Application stability notifications server failure notifications read / write FAUST Protocol read / write PROBE CONTEXT FAILURE USTOR Protocol (client side) SUBMIT COMMIT REPLY Client-Server Channel Client-to-Client Comm.

  20. FAUST Layer at client Ci • Maintain the latest known context: contexti • Periodically (when no user ops) read data stored by others • Find out their latest known context, update contexti • Ci always makes operations – others will see that contexti changes • If no new info from Ck for a long time: • send a direct PROBE message (e.g., email) to Ck • Ck responds with CONTEXT message containing contextk • If contextk is inconsistent with contexti • send a FAILURE message to all • report failure to application • Otherwise, if contextk includes j-th operation of Ci • j-th operation reported stable at Ci w.r.t. Ck

  21. Conclusion • Need for semantics and client-side tools for services provided by “clouds” • Clients should be able to detect if semantics are violated • ACM SIGACT News Column 34, Distributed Computing in the Clouds; http://www.ee.technion.ac.il/~idish/sigactNews • Our suggestion: Fail-Aware Untrusted Service • FAUST provides such semantics for simple storage • When a read/write operation completes causal consistency (at least) is guaranteed • Eventually, more information is obtained. Then: • Indicate to client that his operation preserves stronger semantics OR: report server failure • Common case: when server is correct, each operation completes independently of others + perfect consistency

More Related