DistOS 2014W Lecture 14

From Soma-notes
Revision as of 12:24, 4 March 2014 by Cdelahou (talk | contribs) (ADded more info for rest of class)
Jump to navigation Jump to search

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?

  • Biggest reason it died was it's assumption of mistrusting the actors.
    • Everything else they did was right.
  • Other successful distributed systems are built on a more trusted model.

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.

How to read a research paper

  • Start with Intro
    • Figure out what the problem is
  • then see the related work for context
  • then go to conclusion. Focus on results.
  • then fill in the gaps by reading specific parts of the body