https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=DistOS_2021F_2021-10-05 2026-05-12T23:28:13Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2021F_2021-10-05&diff=23408&oldid=prev 2021-10-13T02:22:46Z

<p>Created page with &quot;==Notes== &lt;pre&gt; Lecture 8: NASD &amp; GFS --------------------- Questions? - is NASD a NAS? - how cost efficient? NASD or GFS? - having the file server out of the loop, secu...&quot;</p> <p><b>New page</b></p><div>==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 8: NASD &amp; GFS<br /> ---------------------<br /> <br /> Questions?<br /> - is NASD a NAS?<br /> - how cost efficient? NASD or GFS?<br /> - having the file server out of the loop, security issues with<br /> NASD?<br /> - checkpoint system?<br /> - NASD in use?<br /> - why just kill chunkservers? Not shut down?<br /> - GFS file security?<br /> <br /> NAS is just a file server<br /> - dedicated, but a file server<br /> - generally use standard network file sharing protocols<br /> (CIFS, NFS)<br /> <br /> NASD is a different beast<br /> - disks are object servers, not file servers<br /> - objects are just variable-sized chunks of data + metadata<br /> (no code)<br /> - contrast with blocks<br /> <br /> With object-based distributed filesystems, we&#039;ve added a level of indirection<br /> - file server translates files to sets of objects, handle file<br /> metadata<br /> - object servers store objects<br /> <br /> Why add this level of indirection? Why not just use fixed-sized blocks?<br /> <br /> (In GFS, instead of objects we have chunks, bit less metadata)<br /> <br /> <br /> Objects are all about parallel access<br /> - to enable performance<br /> <br /> Client can ask for objects from multiple object servers at once<br /> - file server doesn&#039;t have to be involved at all<br /> <br /> The classic way we did redundancy &amp; reliability in storage is with RAID<br /> <br /> Sounds like most of you haven&#039;t used RAID<br /> - Redundant Array of Inexpensive/Independent Disks<br /> - idea is to combine multiple drives together to get<br /> more, higher performance, more reliable storage<br /> <br /> RAID-0: striping<br /> RAID-1: mirroring<br /> RAID-5: striping + parity<br /> <br /> With RAID, data is distributed across disks at the block level<br /> - drives have no notion of files, just blocks<br /> <br /> The modern insight with distributed storage is distributing at the block layer is too low level<br /> - better to distribute bigger chunks, like objects!<br /> <br /> Read objects in parallel, rather than blocks<br /> - files are big, so feasible to read multiple objects in parallel<br /> <br /> We do &quot;mirroring&quot; with objects/chunks, i.e. have multiple copies<br /> - parity/erasure codes mostly not worth the effort for<br /> these systems (but later systems will use such things)<br /> <br /> Security<br /> - NASD security? How can clients securely access<br /> individual drives?<br /> <br /> In Linux (POSIX) capabilities are a way to split up root access<br /> - but that is actually not the &quot;normal&quot; meaning of capabilities<br /> in a security context<br /> <br /> Capabilities are tokens a process can present to a service to enable access<br /> - separate authentication server gives out capability tokens<br /> - idea is the authentication server doesn&#039;t have to check<br /> when access is done, it can be done in advance<br /> <br /> With capabilities, the drives can control access without<br /> needing to understand about users, groups, etc<br /> - it just has to understand the tokens, have a way to<br /> verify them<br /> - make sure the tokens can&#039;t be faked!<br /> <br /> Most single sign on systems tend to have some sort of capability-like token underneath if they are really distributed<br /> <br /> Note that capability tokens are ephemeral<br /> - normally expire after a relatively short period of time (minutes or hours)<br /> - needed to prevent replay attacks<br /> <br /> Imagine having 10,000 storage servers and one authentication server<br /> - if auth server had to be involved in every file access,<br /> would become a bottleneck<br /> - but with capabilities it can issue them at a much slower rate<br /> and sit back while mass data transfers happen<br /> <br /> Capabilities are at the heart of NASD<br /> <br /> What about GFS?<br /> - nope, assumes a trusted data center<br /> - I think it has UNIX-like file permissions, but<br /> nothing fancy<br /> - just to prevent accidental file damage<br /> <br /> What was GFS for?<br /> - building a search engine<br /> - i.e., downloading and indexing the entire web!<br /> - data comes in from crawlers<br /> - indices built as batch jobs<br /> <br /> Are GFS files regular files?<br /> - they are weird because they are sets of records<br /> - records can be duplicated, must have unique id&#039;s<br /> - record, think web page<br /> - have to account for crawler messing up and<br /> downloading same info multiple times<br /> (i.e., if the crawler had a hardware or<br /> software fault)<br /> &lt;/pre&gt;</div>

Soma