Cornelia Davis, Meaghan Kjelland, Erin Schnabel, Therese Stowell, and Mathangi Venkatesan at SpringOne Platform 2017
•
1 like•393 views
Cornelia Davis (Sr Director of Technology, Pivotal); Meaghan Kjelland (Software Engineer, Google); Erin Schnabel (Senior Technical Staff Member, IBM); Therese Stowell (Staff Product Manager, Pivotal); and Mathangi Venkatesan (Senior Member of Technical Staff, VMware) speaks on the Main Stage at SpringOne Platform 2017.
Recommended
More Related Content
Similar to Cornelia Davis, Meaghan Kjelland, Erin Schnabel, Therese Stowell, and Mathangi Venkatesan at SpringOne Platform 2017
Similar to Cornelia Davis, Meaghan Kjelland, Erin Schnabel, Therese Stowell, and Mathangi Venkatesan at SpringOne Platform 2017 (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
Cornelia Davis, Meaghan Kjelland, Erin Schnabel, Therese Stowell, and Mathangi Venkatesan at SpringOne Platform 2017
- 2. When There are Nine (Some) Algorithms of Distributed Computing 2
- 7. A B C D E
- 8. D C A B E
- 12. Where is Leader Election Used? • Identical processes that need coordination • Resource sharing • Decomposable problems • No natural choice for leader
- 13. B A C D E I want to be leader now! Can I?
- 15. B A C E D
- 16. B A D I want to be leader now! Can I? C E
- 17. E D I want to be leader now! Can I? No one can hear me now, I’m not the leader! C OK! B OK! OK! A
- 18. B Yea, I remember! A How could I forget! C Thanks for the reminder! D I remember! E Don’t forget me, I’m the leader!
- 20. Paxos
- 21. Why Paxos? What do distributed systems achieve? • High availability • Eliminate single point of failure How? • Replicated servers in a cluster • Consensus module - Consistency of data - Same order of commands to the replica
- 22. Paxos Consensus Protocol Safety rules • System must agree on a value as “chosen” value • Only one value is ever chosen • A value is chosen if its accepted by a majority of servers ( quorum ) Actors • Proposers • Acceptors • Learners * https://angus.nyc/2012/paxos-by-example/
- 23. Problems to solve • Agree on one value • Do not allow multiple chosen values How can this be solved ? • Reject competing proposals on chosen value - Proposal numbers • 2 phase approach ✓Prepare (Find out chosen, block older) ✓Accept Global sequence number Unique Server Id
- 24. S1 S2 S3 S4 S5 A Paxos instance… P(n.1) -> x P(n.1) -> x P(n.1) -> x P(n+1.5 ) -> y P(n+1.5 ) -> y P(n+1.5 ) -> y A(n.1 , x) A(n.1 , x) A(n+1.5 , y) A(n+1.5 , y) A(n.1 , x) A(n+1.5 , y) A(n+1.5 , y) Chosen value : “y” Prepare, then Accept P(?, ?)
- 26. Partition Tolerance Availability Consistency The CAP Theorem Proved that a distributed data store can only have two of these three things That is, you can only have AP, CP or AC
- 27. For any distributed system Partitions will happen so you can only achieve AP or CP Assumption:
- 28. But what about…
- 29. You might have heard… Google owns their own fibre Google gets redundancy (redundant fibre, redundant switches, redundant everything) Google gets failure boundaries (limits the blast radius) So arguably, for much of the time, Spanner is AC!!!!
- 30. Let’s talk about Consistency…
- 31. Consistency in CAP theorem Every read receives the most recent write, or an error Multiple nodes
- 32. Atomicity: Two Phase Commit Transaction Manager Consensus between Resource Managers 1. Prepare • Can commit? Y / N • Resource Managers Lock 2. Commit • Decide: Commit or Abort RM RM RM TM 1. Prepared 1a. Prepare 1b. Prepared 2. Commit 2b. Committed
- 33. Two Phase Commit does not work on large-scale distributed systems Assumption:
- 34. Two Phase Commit Technically correct: Failures can be nasty Worst case: RMs blocked waiting for TM! RM RM RM TM 1. Prepared 1a. Prepare 1b. Prepared 2. Commit 2b. Committed
- 35. Paxos Commit: 2PC without horrible failure mode ATOMICITY (safely all or nothing) But.. Async?! (!!) What about ISOLATION? But what if we used Paxos for consensus? Client 1. Prepare (Paxos Request) 2. Consensus / Prepared 3. Commit WARNING: OVERSIMPLIFICATION 4. DONE
- 36. TrueTime “Global wall clock time” with bounded uncertainty — you can wait it out! TrueTime is its own distributed system: GPS and Atomic-clock time masters in every data center Client contacts several, computes reference [earliest, latest] = now ± ε TrueTime — monotonically increasing timestamps [ ]TT.now() earliest latest 2*ℇ
- 37. TrueTime Invariant: time stamp order == commit order; ISOLATION & external consistency All transaction logs for the commit have the same timestamp There it is: Two-phase commit for a large-scale distributed system Commit wait time Pick s = TT.now().latest Wait: TT.now().earliest > ss T acquired locks release locks start consensus achieve consensus notify participants
- 38. Let’s talk about Availability…
- 39. R L R Availability in CAP theorem Every request receives a (non-error) response
- 40. An Available distributed system will sometimes return Stale Data Assumption:
- 42. R L R Paxos driven writes Query Do I have the latest? Dunno - latest is at tn
- 43. R L R Paxos driven writes Query Do I have the latest? An independent control loop to propagate changes Dunno - latest is at tn
- 44. R L R Paxos driven writes Query Do I have the latest? An independent control loop to propagate changes Dunno - latest is at tn
- 45. Cloud Spanner is ALL about TrueTime Assumption:
- 46. Multiple nodes
- 48. Redundant Networks Multiple nodes L R RLeader Elections
- 49. Redundant Networks Multiple nodes L R R Leader Elections Consensus Protocol
- 50. Redundant Networks Multiple nodes L R R Leader Elections Consensus Protocol Retries
- 51. Redundant Networks Multiple nodes L R R Leader Elections Consensus Protocol Retries TrueTime
- 52. Couple rarity of network partitions with common distributed systems algorithms and a new view of time and you get a globally distributed, highly available, ACID compliant database
- 55. When ask when there would be “enough” women on the supreme court, she said: “When there are nine”