DistOS 2014W Lecture 14: Difference between revisions
Cleaned up some stuff a bit. |
|||
| Line 2: | Line 2: | ||
==What is the dream?== | ==What is the dream?== | ||
* High availabitility, universally | * 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 | ||
** | ** 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 | * 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. | ||
** 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 | ||
** | ** 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. | ** 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 16: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.