DistOS 2015W Session 6: Difference between revisions
Hassansaid (talk | contribs) |
|||
| (16 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
==Midterm== | ==Midterm== | ||
| Line 4: | Line 5: | ||
The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available]. | The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available]. | ||
== | ==FARSITE== | ||
Farsite is a secure, scalable file system that logically functions as a centralized file server but is physically distributed among a set of untrusted computers. Farsite provides file availability and reliability through randomized replicated storage; it ensures the secrecy of file contents with cryptographic techniques; it maintains the integrity of file and directory data with a Byzantine-fault-tolerant protocol; it is designed to be scalable by using a distributed hint mechanism and delegation certificates for pathname translations; and it achieves good performance by locally caching file data, lazily propagating file updates, and varying the duration and granularity of content leases. We report on the design of Farsite and the lessons we have learned by implementing much of that design. | |||
[http://research.microsoft.com/apps/pubs/default.aspx?id=67917] | |||
==OCEAN STORE== | |||
Link to a mini review on the OceanStore Paper... | |||
[http://www.cse.lehigh.edu/~brian/course/advanced-networking/reviews/manura-oceanstore.html] | |||
==Group 1== | |||
'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan | |||
{| class="wikitable" | {| class="wikitable" | ||
| Line 28: | Line 36: | ||
! Implementation | ! Implementation | ||
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system | | Did not mention what programming they used, but it was based on Windows. They did not implement the file system | ||
| Implemented in | | Implemented in Java | ||
|- | |- | ||
! Scalability | ! Scalability | ||
| Scalable to a University or large corporations, maximum 10 | | Scalable to a University or large corporations, maximum 10<sup>5</sup> | ||
| Worldwide scalability, maximum 10 | | Worldwide scalability, maximum 10<sup>10</sup> | ||
|- | |- | ||
! File Usage | ! File Usage | ||
| Line 46: | Line 54: | ||
| Used the object model | | Used the object model | ||
|} | |} | ||
==Group 2== | |||
'''Team''': Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot | |||
<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0" class="wikitable"> | |||
<tr> | |||
<td><p>'''Farsite'''</p></td> | |||
<td><p>'''OceanStore'''</p></td> | |||
</tr> | |||
<tr> | |||
<td><p>Implemented Content Leases</p></td> | |||
<td><p>Update Model handled data consistency, no Leases</p></td> | |||
</tr> | |||
<tr> | |||
<td><p>Single tier, peer to peer model</p></td> | |||
<td><p>Two tier, server client model</p></td> | |||
</tr> | |||
<tr> | |||
<td><p>Scope of ten to the five</p></td> | |||
<td><p>Global Scope (ten to the ten)</p></td> | |||
</tr> | |||
<tr> | |||
<td><p>Cryptographic public, private key security</p></td> | |||
<td><p>Read and write privileges</p></td> | |||
</tr> | |||
<tr> | |||
<td><p>Randomized data replication</p></td> | |||
<td><p>Nomadic Data concept</p></td> | |||
</tr> | |||
</table> | |||
==Group 3== | |||
'''Team''': DANY, MOE, DEEP, SAMEER, TROY | |||
---- | |||
''' | |||
== FARSITE == | |||
''' | |||
'''Security''' | |||
• Cascading certificates system through directory hierarchy | |||
• Keys | |||
• Three types of certificates | |||
• CFS required to authorized certificate | |||
• Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make | |||
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users | |||
who are authorized writers to that directory and to files in it | |||
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy. | |||
'''System Architecture''' | |||
• Client Monitor, directory group, file host | |||
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group. | |||
---- | |||
''' | |||
== OCEANSTORE == | |||
''' | |||
'''Security''' | |||
• GUID and ACLs used for write, encryption used for reads. | |||
• To prevent unauthorized reads, it encrypts | |||
all data in the system that is not completely public and distributes the encryption key to those users with read permission | |||
Latest revision as of 18:37, 12 April 2015
Midterm
The midterm from last year is now available.
FARSITE
Farsite is a secure, scalable file system that logically functions as a centralized file server but is physically distributed among a set of untrusted computers. Farsite provides file availability and reliability through randomized replicated storage; it ensures the secrecy of file contents with cryptographic techniques; it maintains the integrity of file and directory data with a Byzantine-fault-tolerant protocol; it is designed to be scalable by using a distributed hint mechanism and delegation certificates for pathname translations; and it achieves good performance by locally caching file data, lazily propagating file updates, and varying the duration and granularity of content leases. We report on the design of Farsite and the lessons we have learned by implementing much of that design.
OCEAN STORE
Link to a mini review on the OceanStore Paper...
Group 1
Team: Kirill, Jamie, Alexis, Veena, Khaled, Hassan
| FARSITE | OceanStore | |
|---|---|---|
| Fault Tolerance | Used Byzantine Fault Tolerance Algorithm - Did not manage well | Used Byzantine Fault Tolerance Algorithm - Did not manage well |
| Cryptography | Trusted Certificates | A strong cryptographic algorithm on read-only operations |
| Implementation | Did not mention what programming they used, but it was based on Windows. They did not implement the file system | Implemented in Java |
| Scalability | Scalable to a University or large corporations, maximum 105 | Worldwide scalability, maximum 1010 |
| File Usage | Was designed for general purpose files | Was designed for small file sizes |
| Scope | All clients sharing the available resources | Transient centralized service |
| Object Model | Didn't use the object model | Used the object model |
Group 2
Team: Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot
Farsite |
OceanStore |
Implemented Content Leases |
Update Model handled data consistency, no Leases |
Single tier, peer to peer model |
Two tier, server client model |
Scope of ten to the five |
Global Scope (ten to the ten) |
Cryptographic public, private key security |
Read and write privileges |
Randomized data replication |
Nomadic Data concept |
Group 3
Team: DANY, MOE, DEEP, SAMEER, TROY
FARSITE
Security • Cascading certificates system through directory hierarchy • Keys • Three types of certificates • CFS required to authorized certificate • Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users
who are authorized writers to that directory and to files in it
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy.
System Architecture • Client Monitor, directory group, file host • When space runs out in directory group, delegate’s ownership to sub tree to other delegate group.
OCEANSTORE
Security • GUID and ACLs used for write, encryption used for reads. • To prevent unauthorized reads, it encrypts
all data in the system that is not completely public and distributes the encryption key to those users with read permission