Difference between revisions of "DistOS 2014W Lecture 14"

From Soma-notes
Jump to navigation Jump to search
(Cleaned up some stuff a bit.)
Line 2: Line 2:


==What is the dream?==
==What is the dream?==
* High availabitility, universally available.
* High availabitility, universally accessible.
* Utility managed by multiple parties
* Utility managed by multiple parties.
* Highly redundant, fault tolerant
* Highly redundant, fault tolerant
* Basic assumption was that servers would NOT be trusted.
* Basic assumption was that servers would NOT be trusted.


* Highly persistent
* Highly persistent
** Effective archival
** Everything archived
** Everything saved, nothing deleted. "Commits"
** Everything saved, nothing deleted. "Commits"


* Service was untrusted
* Service was untrusted
** Held opaque data.
** Held opaque/encrypted data.
* Would be used for more than files. DB's, etc.
* Would have been used for more than files. (eg. DB's, etc.)
 


==Why did the dream die?==
==Why did the dream die?==
Line 20: Line 19:
=== Technology ===
=== Technology ===
* The trust model is the most attractive feature which ultimately killed it.
* The trust model is the most attractive feature which ultimately killed it.
** The untrusted assumption was a huge burden on the system. Forced technical
** The untrusted assumption was a huge burden on the system. Forced technical limitations made them uncompetitive.
  limitations Made them uncompetitive.
** It is just easier to trust a given system. More convenient.
** It is just easier to trust a given system
** Every system is compromisable despite this mistrust
** Every system is compromisable despite this mistrust
* Pub key system reduces usability
* Pub key system reduces usability
Line 34: Line 32:
===Use Cases===
===Use Cases===
* Subset of the features already exist
* Subset of the features already exist
** Black berry. Google.
** Blackberry and Google offer similar services.
** Current services owned by one company, not many providers.
** These current services owned by one company, not many providers.
** Can not sell back your services as a user.
** Can not sell back your services as a user.
*** ex. Can not sell your extra storage back to the utility.
*** ex. Can not sell your extra storage back to the utility.
Line 42: Line 40:


* They actually built it.
* They actually built it.
* Can't assume the use of any infrastructure, so they rebuild everything!
* Can't assume the use of any infrastructure, so they rebuild everything!
** Built over the internet.
** Built over the internet.
** Tapestry
** Tapestry (routing).
** GUID for object indentification. Object naming scheme.
** GUID for object indentification. Object naming scheme.


Line 56: Line 53:
* Expensive, but good value (data is backed up, replicated, etc..)
* Expensive, but good value (data is backed up, replicated, etc..)


==Update performance==
===Update performance===
* No data is mutated. It is diffed and archived.
* No data is mutated. It is diffed and archived.
* Creating a new version of an object and distributing that object.
* Creating a new version of an object and distributing that object.


===Benchmarks in a nutshell===
* Everything is expensive!
* High latency


==Other stuff==
==Other stuff==
* Byzantine fault tolerance
* Byzantine fault tolerance
** Assuming certain actors are malicious
** Assuming certain actors are malicious
==What's worth salvaging from the dream?==
* Using spare resources in other locations.

Revision as of 12:15, 4 March 2014

OceanStore

What is the dream?

  • High availabitility, universally accessible.
  • Utility managed by multiple parties.
  • Highly redundant, fault tolerant
  • Basic assumption was that servers would NOT be trusted.
  • Highly persistent
    • Everything archived
    • Everything saved, nothing deleted. "Commits"
  • Service was untrusted
    • Held opaque/encrypted data.
  • Would have been used for more than files. (eg. DB's, etc.)

Why did the dream die?

Technology

  • The trust model is the most attractive feature which ultimately killed it.
    • The untrusted assumption was a huge burden on the system. Forced technical limitations made them uncompetitive.
    • It is just easier to trust a given system. More convenient.
    • Every system is compromisable despite this mistrust
  • Pub key system reduces usability
    • If you loose your key, you're S.O.L.
  • security
    • there is no security mechanism in servers side.
    • can not now who access the data
  • economic side
    • The economic model is unconvincing as defined. The authors suggest that a collection of companies will host OceanStore servers, and consumers will buy capacity (not unlike web-hosting of today).

Use Cases

  • Subset of the features already exist
    • Blackberry and Google offer similar services.
    • These current services owned by one company, not many providers.
    • Can not sell back your services as a user.
      • ex. Can not sell your extra storage back to the utility.

Pond: What insights?

  • They actually built it.
  • Can't assume the use of any infrastructure, so they rebuild everything!
    • Built over the internet.
    • Tapestry (routing).
    • GUID for object indentification. Object naming scheme.

Benchmarks

  • Really good read speed, really bad write speed.

Storage overhead

  • How much are they increasing the storage needed to implement their storage model.
  • Factor of 4.8x the space needed (you'll have 1/5th the storage)
  • Expensive, but good value (data is backed up, replicated, etc..)

Update performance

  • No data is mutated. It is diffed and archived.
  • Creating a new version of an object and distributing that object.

Benchmarks in a nutshell

  • Everything is expensive!
  • High latency

Other stuff

  • Byzantine fault tolerance
    • Assuming certain actors are malicious

What's worth salvaging from the dream?

  • Using spare resources in other locations.