Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Distributed File Systems


Published on

Distributed File Systems

Published in: Education
  • Be the first to comment

  • Be the first to like this

Distributed File Systems

  1. 1. DISTRIBUTED SYSTEMS B. Tech IV/IV, II Semester COMPUTER SCIENCE & ENGINEERING 02/06/17 1@Copyright Material
  2. 2. UNIT VI 02/06/17 2 Distributed Systems Foundation Middleware Support Systems Algorithms & Shared Data Characterization of Distributed Systems System Models Inter Process Communication Distributed Objects Remote Invocation Operating System Distributed File System Coordination & Agreement Transactions & Replications @Copyright Material
  3. 3. What we learnt till NOW 1. Characterization of a Distributed System 1. Need for a Distributed System 2. Evolution of a Distributed System. 3. Examples of it & details on Resource Sharing 4. Challenges of it 2. How to build a Distributed System Model 1. Introduction to a System Model 2. Types of System models 3. Functionalities of each of these models 3. How to achieve Inter process communication 1. Learned sockets for establishing communication 2. Fundamentals of Protocols required for communication 3. Learnt about XDR for handling heterogeneity 4. Handled Multicast communication 4. Various programming models 1. Object model & Distributed Object Model 2. RMI, CORBA & XML 3. Role of Events & Notification 4. Case study of RMI 02/06/17 3@Copyright Material
  4. 4. What we learnt in Unit V 1. Introduction to Operating System – Definition of network OS – Definition of distributed OS 1. Layers of an Operating System – Process Manager – Thread Manager – Communication Manager – Memory Manager – Supervisor 1. Protection 2. Processes & Threads – Processes, Threads 1. Communication & Invocation 2. Operating System Architecture – Monolithic and Micro-kernels 02/06/17 4@Copyright Material
  5. 5. What we learn in Unit VI 1. Introduction to File System – Characteristics of a File System – Requirements of a File System 1. Architecture of a File Service 2. Implementations of a Distributed File System – Sun Network File System • NFS Protocol, Architecture, Operations with an Example, Goals 1. Introduction to Peer-to-Peer Systems – Characteristics of Peer-to-Peer Systems – Routing Mechanisms 1. Napster & its Legacy 2. Need for Peer-to-Peer Middleware – Functional & Non-Functional Requirements 1. Routing Overlays – Tasks of Routing Overlays 02/06/17 5@Copyright Material
  6. 6. Learning Objective Upon completion of this unit, students will be able to: • Emphasize the design considerations and trade-offs that have led to a Distributed File System • Gain knowledge of the architecture and design of Distributed File Systems • Learn the functionality, the APIs and the underlying implementations of basic Distributed File Systems using Network File System • Understanding the basis for the design of a Peer-to- peer services through Napster Legacy • Analyze the algorithms that enable the responsibility of locating nodes and objects through Routing Overlays. 02/06/17 6@Copyright Material
  7. 7. 1. Introduction to File System • The sharing of stored information is the most important aspect of distributed resource sharing – Web servers provide a restricted form of data sharing in which files stored locally • The design of large-scale wide area read-write file storage systems poses problems of – Load Balancing – Reliability – Availability – Security • These are resolved using the peer-to-peer file storage systems, discussed later in this unit 02/06/17 7@Copyright Material
  8. 8. 1. Introduction to File System What is the NEED for a File System? 1. A convenient programming interface to disk storage 2. Provides access control & File locking mechanisms for data sharing • The file system is responsible for organizing files and directories, and keeping track of which areas of the media belong to which file and which are not being used Examples: MS-DOS, Unix V7, FAT-32, NTFS, AFS, NFS, ZFS, CODA • A File Service enables programs to store and access remote files exactly as they do local ones, allowing users to access their files from any computer in an intranet 02/06/17 8@Copyright Material
  9. 9. 1. Introduction to File System What are the different types of Storage Systems?  Distributed file systems support the sharing of information in the form of files and hardware resources.  The First generation of Distributed Systems (1974-75) file systems were the only Networked Storage Systems.  With the advent of distributed object systems (CORBA, Java) and the web, the picture has become more complex. The next slide compare the types of storage systems with respect to  Sharing: Ability to share the storage space  Persistence: Ability to retain data in a permanent storage  Distributed Cache/Replicas: Approach to optimize the performance  Consistency Maintenance: Consistency between multiple copies  Examples of each of these storage systems. 02/06/17 9@Copyright Material
  10. 10. 1. Introduction to File System 02/06/17 10 Sharing Persis- tence Distributed cache/replicas Consistency maintenance Example Main memory RAM File system UNIX file system Distributed file system Sun NFS Web Web server Distributed shared memory Ivy (Ch. 16) Remote objects (RMI/ORB) CORBA Persistent object store 1 CORBA Persistent Object Service Persistent distributed object store PerDiS, Khazana 1 1 1 Types of consistency between copies: 1 - strict one-copy consistency √ - approximate consistency X - no automatic consistency 2 – considerably weaker guarantee 2 @Copyright Material
  11. 11. 1. Introduction to File System What are the different Layers of a Non-Distributed File System? The implementation of a distributed file service requires all of the components shown there, with additional components to deal with client- server communication and with the distributed naming and location of files 02/06/17 11 Directorymodule: relates file names to file IDs File module: relates file IDs to particular files Access control module: checks permission for operation requested File access module: reads or writes file data or attributes Blockmodule: accesses and allocates diskblocks Device module: diskI/O and buffering File system modules @Copyright Material
  12. 12. 1. Introduction to File System File System Characteristics: 1. Files contain both data and attributes 02/06/17 12 File length Creation timestamp Read timestamp Write timestamp Attribute timestamp Reference count Owner File type Access control list updated by system: updated by owner: File Attribute Record Structure @Copyright Material
  13. 13. 1. Introduction to File System File System Characteristics 2. File systems are designed to store and manage large numbers of files, with facilities for creating, naming and deleting files 3. A directory is a file, often of a special type, that provides a mapping from text names to internal file identifiers. 4. Hierarchic file-naming scheme and the multi-part pathnames for files are used in UNIX and other operating systems 5. Metadata is often used to refer to all of the extra information stored by a file system that is needed for the management of files It includes file attributes, directories and all the other persistent information used by the file system 02/06/17 13@Copyright Material
  14. 14. 1. Introduction to File System File System Operations 02/06/17 14@Copyright Material
  15. 15. 1. Introduction to File System File System Requirements Transparency: – Access: Client programs should be unaware of the distribution of files – Location: Client programs should see a uniform file name space – Mobility: Neither client programs nor system administration tables inclient nodes need to be changed when files are moved – Performance: Client programs should continue to perform satisfactorily – Scaling: Upgrading or downgrading the requirements Concurrency: Changes to a file by one client should not interfere with the operation of other clients simultaneously accessing or changing the same file Replication: file may be represented by several copies of its contents at different locations Heterogeneity: Should support varied OS & Hardware Fault tolerance: service continue to operate in the face of client and server failures 02/06/17 15@Copyright Material
  16. 16. 1. Introduction to File System File System Requirements Consistency: A need for concurrent access to files in which the file contents seen by all of the processes accessing or updating a given file are those that they would see if only a single copy of the file contents existed Security: All file systems must provide access-control mechanisms based on the use of access control lists Efficiency: File services must provide same or at least offerings of the conventional file systems & should achieve a comparable level of performance 02/06/17 16@Copyright Material
  17. 17. Tranparencies Access: Same operations Location: Same name space after relocation of files or processes Mobility: Automatic relocation of files is possible Performance: Satisfactory performance across a specified range of system loads Scaling: Service can be expanded to meet additional loads Concurrency properties Isolation File-level or record-level locking Other forms of concurrency control to minimise contention Replication properties File service maintains multiple identical copies of files • Load-sharing between servers makes service more scalable • Local access has better response (lower latency) • Fault tolerance Full replication is difficult to implement. Caching (of all or part of a file) gives most of the benefits (except fault tolerance) Heterogeneity properties Service can be accessed by clients running on (almost) any OS or hardware platform. Design must be compatible with the file systems of different OSes Service interfaces must be open - precise specifications of APIs are published. Fault tolerance Service must continue to operate even when clients make errors or crash. • at-most-once semantics • at-least-once semantics •requires idempotent operations Service must resume after a server machine crashes. If the service is replicated, it can continue to operate even during a server crash. Consistency Unix offers one-copy update semantics for operations on local files - caching is completely transparent. Difficult to achieve the same for distributed file systems while maintaining good performance and scalability. Security Must maintain access control and privacy as for local files. •based on identity of user making request •identities of remote users must be authenticated •privacy requires secure communication Service interfaces are open to all processes not excluded by a firewall. •vulnerable to impersonation and other attacks Efficiency Goal for distributed file systems is usually performance comparable to local file system. Transparency Concurrency Replication Heterogeneity Fault tolerance Consistency Security Efficiency 1. Introduction to File System 02/06/17 17@Copyright Material
  18. 18. 2. File Service Architecture • An architecture that offers a clear separation of the main concerns in providing access to files is obtained by structuring the file service as three components:  A flat file service  A directory service  A client module. • The flat file service and the directory service each export an interface for use by client programs, and their RPC interfaces, taken together, provide a comprehensive set of operations for access to files • The client module provides a single programming interface with operations on files similar to those found in conventional file systems. • Next slide shows the architecture 02/06/17 18@Copyright Material
  19. 19. 2. File Service Architecture Client computer Server computer Application program Application program Client module Flat file service Directory service Lookup AddName UnName GetNames Read Write Create Delete GetAttributes SetAttributes 02/06/17 19@Copyright Material
  20. 20. 2. File Service Architecture The Client module implements exported interfaces by flat file and directory services on server side. Responsibilities of various modules in the Architecture 1. Flat file service: – Concerned with the implementation of operations on the contents of file. – Unique File Identifiers (UFIDs) are used to refer to files in all requests for flat file service operations. – UFIDs are long sequences of bits chosen so that each file has a unique among all of the files in a distributed system. 2. Directory service: – Provides mapping between text names for the files and their UFIDs. – Clients may obtain the UFID of a file by quoting its text name to directory service. – Directory service supports functions needed generate directories, to add new files to directories. 02/06/17 20@Copyright Material
  21. 21. 2. File Service Architecture Responsibilities of various modules in the Architecture 3. Client module: – It runs on each computer and provides integrated service (flat file and directory) as a single API to application programs. Ex: In UNIX hosts, a client module emulates the full set of Unix file operations. – It holds information about the network locations of flat-file and directory server processes; and achieve better performance through implementation of a cache of recently used file blocks at the client. 4.Access control – In distributed implementations, access rights checks have to be performed at the server because the server RPC interface is an otherwise unprotected point of access to files. 02/06/17 21@Copyright Material
  22. 22. 2. File Service Architecture Responsibilities of various modules in the Architecture 5. Flat File service Interface 02/06/17 22@Copyright Material
  23. 23. 2. File Service Architecture Responsibilities of various modules in the Architecture 6. Directory Service Interface: Directory services are used to provide a service for translating text names to UFIDs 02/06/17 23@Copyright Material
  24. 24. 2. File Service Architecture Responsibilities of various modules in the Architecture 7. Hierarchic file system A hierarchic file system such as the one that UNIX provides consists of a number of directories arranged in a tree structure 8. File Group A file group is a collection of files that can be located on any server or moved between servers while maintaining the same names. – A similar construct is used in a UNIX file system. – It helps with distributing the load of file serving between several servers. – File groups have identifiers which are unique throughout the system (and hence for an open system, they must be globally unique). To construct a globally unique ID we use some unique attribute of the machine on which it is created, e.g. IP number, even though the file group may move subsequently. 02/06/17 24@Copyright Material
  25. 25. 3. Implementation of a DFS Network File System: • An implementation and a specification (RFC) of a software system for accessing remote files across LANs (or WANs) • Developed at SUN Microsystems in 1985 • Built on the RPC/XDR based protocol • NFS protocol is operating system–independent • Can be configured to use either UDP or TCP, and the NFS protocol is compatible with both • The actual remote-file-access are distinct services • The submission of signed user credentials can be required as an optional security feature, as can the encryption of data for privacy and integrity 02/06/17 25@Copyright Material
  26. 26. 3. Implementation of a DFS NFS Architecture: 02/06/17 26@Copyright Material
  27. 27. 3. Implementation of a DFS NFS Architecture: Virtual file system: • The figure makes it clear that NFS provides access transparency: • User programs can issue file operations for local or remote files without distinction. • Other distributed file systems may be present that support UNIX system calls, and if so, they could be integrated in the same way. • The integration is achieved by a virtual file system (VFS) module, which has been added to the UNIX kernel to distinguish between local and remote files & to translate between the UNIX-independent file identifiers used by NFS and the internal file identifiers normally used in UNIX and other file systems 02/06/17 27@Copyright Material
  28. 28. 3. Implementation of a DFS NFS Architecture: Virtual File System • The file identifiers used in NFS are called file handles. A file handle is opaque to clients and contains whatever information the server needs to distinguish an individual file. • In UNIX implementations of NFS, the file handle is derived from the file’s i-node number by adding two extra fields as follows • The filesystem identifier field is a unique number that is allocated to each filesystem when it is created • The i-node generation number is needed because in the conventional UNIX file system i-node numbers are reused after a file is removed 02/06/17 28@Copyright Material
  29. 29. 3. Implementation of a DFS NFS Architecture: Virtual File System • The virtual file system layer has one VFS structure for each mounted file system and one v-node per open file • A VFS structure relates a remote file system to the local directory on which it is mounted. • The v-node contains an indicator to show whether a file is local or remote • If the file is local, the v-node contains a reference to the index of the local file (an i-node in a UNIX implementation). • If the file is remote, it contains the file handle of the remote file. 02/06/17 29@Copyright Material
  30. 30. 3. Implementation of a DFS Remote Access in NFS : 1. NFS Offers this mode of accessing files 2. FTP offers this mode of accessing files 02/06/17 30@Copyright Material Remote Access Model Upload/Download Model
  31. 31. 3. Implementation of a DFS Communication Model in NFS : a) Reading data from a file in NFS version 3. b) Reading data using a compound procedure in version 4. 02/06/17 31@Copyright Material NFS V 3 NFS V 4
  32. 32. 3. Implementation of a DFS Naming Conventions in NFS : Mounting (part of) a remote file system in NFS. 02/06/17 32@Copyright Material Client A & B can mount the exported directory into their File SystemServer has a Directory which has been mounted up for network sharing
  33. 33. 3. Implementation of a DFS Naming Conventions in NFS : Mounting nested directories from multiple servers in NFS. Server A imports directory from server B into its file system Client A mounts the exported directory from server A into its FileSystem 02/06/17 33@Copyright Material
  34. 34. 3. Implementation of a DFS File sharing in NFS : Semantics of File Sharing a. On a single processor, when a read follows a write, the value returned by the read is the value just written 02/06/17 34@Copyright Material b. In a distributed system with caching, obsolete values may be returned. Ex: 1. Client 1 reads a, b values from a file server 2. Client 1 Writes value of C 3. Client 2 reads a, b values which maybe obsolete
  35. 35. 3. Implementation of a DFS Caching in NFS : Server-side caching – Read operations: easy. – Write operations: • Write-through, or • Delayed-write: flush on commit operation (+file close) 02/06/17 35@Copyright Material
  36. 36. 3. Implementation of a DFS Caching in NFS: Client Caching Write back Cache: 02/06/17 36@Copyright Material Write Request Acknowledgement Cache Acknowledgement Application in the Server Application in the Client Disk
  37. 37. 3. Implementation of a DFS NFS Security: The security of NFS implementations has been strengthened by the use of the Kerberos scheme to authenticate clients 02/06/17 37@Copyright Material The security of NFS implementation has been achieved by establishing a secure channel for communication between the client & server stubs
  38. 38. 3. Implementation of a DFS Design goals achieved by NFS 1. Access transparency : YES 2. Location transparency : YES, (dependent on mounting) 3. Failure transparency : Partial 4. Mobility transparency : YES, (with update of mount tables) 5. Replication transparency : NO 6. HW/SW heterogeneity: YES 7. Consistency: Approximation to one-copy semantics (3 sec lag) 8. Scalability : NO 02/06/17 38@Copyright Material
  39. 39. 3. Implementation of a DFS NFS Architecture: Performance: With the early experiences, the following are the problem areas: • frequent use of the getattr call in order to fetch timestamps from servers for cache validation – Piggy-backing on every operation – Apply attributes to all cached blocks • Relatively poor performance of the write operation because write- through was used at the server. • LADDIS Benchmark has added improvements proving NFS performance • Effective in LAN intranets • The performance of NFS is much enhanced by the caching of file blocks at each client computer 02/06/17 39@Copyright Material
  40. 40. 4. Introduction to Peer-to-peer Systems Where are we in the Discussion? • Peer-to-peer systems (P2P systems) represent a paradigm for the construction of distributed systems and applications in which data and computational resources are contributed by many hosts on the Internet. • P2P systems enable sharing of data and resources on a very large scale by, eliminating requirements for separately managed servers.. • P2P systems have been used to provide file sharing, web caching, information distribution and other services, making use of the resources of tens of thousands of machines across the Internet. Examples 02/06/17 40@Copyright Material Peer-to-Peer
  41. 41. 4. Introduction to Peer-to-peer Systems Characteristics of Peer-to-Peer Systems – Their design ensures that each user contributes resources to the system. – Although they may differ in the resources that they contribute, all the nodes in a peer-to-peer system have the same functional capabilities and responsibilities. – Their correct operation does not depend on the existence of any centrally administered systems. – They can be designed to offer a limited degree of anonymity to the providers and users of resources. – A key issue for their efficient operation is the choice of an algorithm for the placement of data across many hosts and subsequent access to it in a manner that balances the workload and ensures availability without adding undue overheads 02/06/17 41@Copyright Material
  42. 42. 4. Introduction to Peer-to-peer Systems Three generations of peer-to-peer system and application development can be identified. – First generation was launched by the Napster music exchange service – A second generation of filesharing applications offering greater scalability, anonymity and fault tolerance quickly followed including gnutella, Bittorrent – The third generation is characterized by the emergence of middleware layers for the application-independent management of distributed resources on a global scale and are called as peer-to-peer middleware Peer-to-peer storage systems are inherently best suited to the storage of immutable objects The use of randomly distributed GUIDs assists by distributing the object replicas to randomly located nodes in the underlying network 02/06/17 42@Copyright Material
  43. 43. 4. Introduction to Peer-to-peer Systems Overlay Routing vs IP Routing: – Routing overlays share many characteristics with the IP packet routing infrastructure that constitutes the primary communication mechanism of the Internet. – But the subtle differences are specified here 02/06/17 43@Copyright Material Factor IP Overlay Routing Scale IPv4 is limited to 232 & IPv6 to 2128 addressable nodes. Addresses in both versions are hierarchically structured and much of the space is preallocated according to administrative requirements. Peer-to-peer systems can address more objects. The GUID namespace is very large and flat (>2128 ), allowing it to be much more fully occupied. Load Balancing Loads on routers are determined by network topology and associated traffic patterns. Object locations can be randomized and hence traffic patterns are divorced from the network topology Network Dynamics(additio n/deletion of nodes/objects IP routing tables are updated asynchronously on a best-effort basis with time constants on the order of 1 hour. Routing tables can be updated synchronously or asynchronously with fractions-of-a- second delays. Fault tolerance Redundancy is designed into the IP network by its managers, ensuring tolerance of a single router or network connectivity failure. n-fold replication is costly. Routes and object references can be replicated n-fold, ensuring tolerance of n failures of nodes or connections Target identification Each IP address maps to exactly one target node. Messages can be routed to the nearest replica of a target object
  44. 44. 5. Napster & its Legacy • In June 1999, the first peer-to-peer file sharing system, Napster was released. • The first application in which a demand for a globally scalable information storage and retrieval service emerged was the downloading of digital music files • It is a centralized unstructured peer-to-peer system that requires a central server for indexing and peer discovery. • Napster provided a service where they indexed and stored file information that users of Napster made available on their computers for others to download • These files were transferred directly between the host and client users after authorization by Napster. • July 2001 Napster was shut down as a result of legal proceedings 02/06/17 44@Copyright Material
  45. 45. 5. Napster & its Legacy Napster’s mode of Operation 02/06/17 45@Copyright Material
  46. 46. 5. Napster & its Legacy Lessons learned from Napster 1. Napster took advantage of special characteristics of the application, such as music files are never updated, and no guarantees are required concerning the availability of individual files. 2. The advantage of centralized systems is that they are simple to implement and they locate files quickly and efficiently. 3. Their main disadvantage is that they are vulnerable to censorship, legal action, surveillance, malicious attack, and technical failure, since the content shared are controlled by the single institution, company or user maintaining the central server. 4. Furthermore, these systems are considered inherently unscalable, as there are bound to be limitations to the size of the server database and its capacity to respond to queries. Large web search engines have however repeatedly provided counterexamples to this notion. 02/06/17 46@Copyright Material
  47. 47. 6. Peer-to-peer Middleware • Key problem in the design of peer-to-peer applications is providing a mechanism to enable clients to access data resources quickly and dependably wherever they are located throughout the network • Napster maintained a unified index of available files for this purpose, giving the network addresses of their hosts  • Second-generation peer-to-peer file storage systems such as Gnutella and Freenet employ partitioned and distributed indexes, but the algorithms used are specific to each system   • This location problem existed in several services that predate the peer-to-peer paradigm as well   Ex: SUN NFS • Peer-to-peer middleware systems are designed specifically to meet the need for the automatic placement and subsequent location of the distributed objects managed by peer-to-peer systems and applications        02/06/17 47@Copyright Material
  48. 48. 6. Peer-to-peer Middleware What are the Functional Requirements? – simplify the construction of services that are implemented across many hosts in a widely distributed network. – ability to add new resources and to remove them at will and to add hosts to the service and remove them – Peer-to-peer middleware should offer a simple programming interface to application programmers that is independent of the types of distributed resource that the application manipulates What are the Non-Functional Requirements? – Global Scalability: Support for applications that access millions of objects on tens of thousands or hundreds of thousands of hosts – Load Balancing: Balanced distribution of workload across distributed Systems 02/06/17 48@Copyright Material
  49. 49. 6. Peer-to-peer Middleware What are the Non-Functional Requirements? – Optimized for local interactions: The middleware should aim to place resources close to the nodes that access them the most – Accommodating to highly dynamic host availability: Peer-to- peer systems are constructed from host computers that are free to join or leave the system at any time – Security of data in an environment with heterogeneous trust: In global-scale systems with participating hosts of diverse ownership, trust must be built up by the use of authentication and encryption mechanisms – Anonymity, deniability and resistance to censorship: The hosts that hold data should be able to plausibly deny responsibility for holding or supplying it. 02/06/17 49@Copyright Material
  50. 50. 6. Peer-to-peer Middleware Middleware Design • How best to design a middleware layer to support global-scale peer-to-peer systems is therefore a difficult problem • The requirements for scalability and availability make it infeasible to maintain a database at all client nodes giving the locations of all the resources (objects) of interest. • Therefore, each node is made responsible for maintaining detailed knowledge of the locations of nodes and objects in a portion of the namespace as well as a general knowledge of the topology of the entire namespace. Next slide describes this with a diagram • Knowledge of the locations of objects must be partitioned and distributed throughout the network • A high degree of replication of this knowledge is necessary to ensure dependability in the face of the volatile availability of hosts and intermittent network connectivity 02/06/17 50@Copyright Material
  51. 51. 6. Peer-to-peer Middleware 02/06/17 51@Copyright Material
  52. 52. 7. Routing Overlays Distributed Object Location & Routing – The operation of any peer-to-peer content distribution system relies on a network of peer computers (nodes) and connections (edges) between them. – This network is formed on top of-and independently from-the underlying physical computer (typically IP) network, and is thus referred to as an "Overlay" network. – The topology, structure and degree of centralization of the overlay network, the routing and location mechanisms it employs for messages and content delivery are crucial to the operation of the system 02/06/17 52@Copyright Material
  53. 53. 7. Routing Overlays Distributed Object Location & Routing – The routing overlay ensures that any node can access any object by routing each request through a sequence of nodes, exploiting knowledge at each of them to locate the destination object – Peer-to-peer systems usually store multiple replicas of objects to ensure availability – The routing overlay maintains knowledge of the location of all the available replicas and delivers requests to the nearest ‘live’ node (i.e. one that has not failed) that has a copy of the relevant object. 02/06/17 53@Copyright Material
  54. 54. 7. Routing Overlays Tasks of a Routing Overlay 1. Routing of requests to objects: A client wishing to invoke an operation on an object submits a request including the object’s GUID to the routing overlay, which routes the request to a node at which a replica of the object resides 2. Insertion of objects: A node wishing to make a new object available to a peer-to-peer service computes a GUID for the object and announces it to the routing overlay, which then ensures that the object is reachable by all other clients 3. Deletion of objects: When clients request the removal of objects from the service the routing overlay must make them unavailable 4. Node addition and removal: Nodes (i.e., computers) may join and leave the service. When a node joins the service, the routing overlay arranges for it to assume some of the responsibilities of other nodes. When a node leaves (either voluntarily or as a result of a system or network fault), its responsibilities are distributed amongst the other nodes. 02/06/17 54@Copyright Material
  55. 55. Pastry: • It is a P2P overlay that is using Dynamic Hash Tables (DHT) with prefix- based routing with both peer ID and object ID. • Prefix routing narrows the search for the next node along the route by applying a binary mask that selects an increasing number of hexadecimal digits from the destination GUID after each hop. • It is originally developed Microsoft and Rice Uni but a free version (FreePastry) exists that is a prototypical implementation of Pastry. The latter is mostly used by scientific community. • Similar algorithms are Chord and CAN • In a network with N participating nodes, the Pastry routing algorithm will correctly route a message addressed to any GUID in O(log N) steps • If the GUID identifies a node that is currently active, the message is delivered to that node; otherwise, the message is delivered to the active node whose GUID is numerically closest to it 02/06/17 55@Copyright Material 7. Routing Overlay
  56. 56. Pastry: • Routing steps involve the use of an underlying transport protocol (normally UDP) to transfer the message to a Pastry node that is ‘closer’ to its destination. • The closeness referred to here is in an entirely artificial space – the space of GUIDs • To minimize the risk of unnecessarily extended transport paths, Pastry uses a locality metric based on network distance in the underlying network (such as a hop counts or round-trip latency measurements) to select appropriate neighbours when setting up the routing tables used at each node • When new nodes join the overlay they obtain the data needed to construct a routing table and other required state from existing members in O(log N) messages, where N is the number of hosts participating in the overlay • In the event of a node failure or departure, the remaining nodes can detect its absence and cooperatively reconfigure to reflect the required changes in the routing structure in a similar number of messages 7. Routing Overlay 02/06/17 56@Copyright Material
  57. 57. Pastry: ROUTING ALGORITHM • The full routing algorithm involves the use of a routing table at each node to route messages efficiently 2 Stages of it: • First stage describes a simplified form of the algorithm that routes messages correctly but inefficiently without a routing table • Second stage describes the full routing algorithm, which routes a request to any node in O(log N) messages In Pastry, the nodes and data items are uniquely connected to the L bit identifier, i.e., the integer in the range of 0 ~ 2L -1 between the integer (L is typically 128) The Pastry identifier is as the number of 2b -1 based series, in which b is typically 4 Leaf node is stored in the collection nearest in value from the view point of the current node identifier. Collection of leaf nodes is needed in the routing information 7. Routing Overlay 02/06/17 57@Copyright Material
  58. 58. Pastry: ROUTING ALGORITHM 7. Routing Overlay 02/06/17 58@Copyright Material
  59. 59. Tapestry: • Tapestry implements a distributed hash table and routes messages to nodes based on GUIDs associated with resources using prefix routing in a manner similar to Pastry • Tapestry’s API conceals the distributed hash table from applications behind a Distributed Object Location & Routing (DOLR) interface • Nodes that hold resources use the publish(GUID) primitive to make them known to Tapestry, and the holders of resources remain responsible for storing them • Replicated resources are published with the same GUID by each node that holds a replica, resulting in multiple entries in the Tapestry routing structure., giving its applications additional flexibility • 160-bit identifiers are used to refer both to objects and to the nodes that perform routing actions • For any resource with GUID G there is a unique root node with GUID RG that is numerically closest to G • Hosts H holding replicas of G periodically invoke publish(G) to ensure that newly arrived hosts become aware of the existence of G. 7. Routing Overlay 02/06/17 59@Copyright Material
  60. 60. Tapestry: Routing 7. Routing Overlay 02/06/17 60@Copyright Material 1. Replicas of the file Phil’s Books (G=4378) are hosted at nodes 4228 and AA932. Node 4377 is the root node for object 43783. The Tapestry routings shown are some of the entries in routing tables4. The publish paths show routes followed by the publish messages laying down cached location mappings for object 4378 5. The location mappings are subsequently used to route messages sent to 4378.
  61. 61. Summary • Learned the design considerations and trade-offs that have led to a Distributed File System • Gained the fundamentals of a File Service Architecture. • Applied the architecture to learn a concept in practice : NFS • Illustrated the basis need for a Peer-to-peer system & learned what not to do with peer-to-peer systems through Napster Legacy • Analyzed the improvement for a peer-to-peer model by enabling the responsibility of locating nodes and objects through Routing Overlays. 02/06/17 61@Copyright Material
  62. 62. QUIZ 1. Which of the following is not an example of a File System a. MS-DOS b. AFS c. DFS d. XFS 2. ________ is the approach to optimize the performance in the storage systems a. Sharing b. Distributed Cache c. Consistency d. Persistence 3. In what type of consistency model, programs cannot observe any discrepancies between cached copies and stored data after an update a. Strict one-copy b. Approximate c. Weaker Guarantee d. No Automatic 4. Metadata is often used to refer a. File-naming scheme b. Mapping from text names to internal file identifiers c. Information needed for the management of files d. Factor to differentiate file systems 02/06/17 62@Copyright Material
  63. 63. QUIZ 5. Which of the file system requirements concern about Access- Control Mechanisms a. Security b. Consistency c. Transparency d. Fault Tolerance 6. In a typical file service architecture which of the one module is not present a. Client Module b. Server Module c. Directory Service d. Daemon Module 7. A File group Identifier has the following attributes a. IP Address, Port Numbers, GUID b. IP Address, Date, iNode Number c. IP Address, iNode Number d. IP Address, Date 02/06/17 63@Copyright Material
  64. 64. QUIZ 8. Which of the following design goals are not achieved by NFS a. Location Transparency b. Replication Transparency c. Mobility Transparency d. None 9. Why did Napster peer-to-peer system failed a. Vulnerability to censorship b. Un-scalability c. Special characteristics of applications d. All of the above 10. Peer-to-peer middleware systems are designed specifically to meet the need for the automatic placement and subsequent location of the distributed objects a. Totally Agree b. Totally Disagree c. Partially Agree d. None of the above 02/06/17 64@Copyright Material
  65. 65. QUIZ 11. Which of the following is not an example of third generation peer- to-peer systems a. Gnutella b. Bittorrent c. Pastry d. Napster 12.Which of the tasks below are not a part of Overlay Networks a. Load Balancing b. Insertion of Objects c. Routing of Requests d. Node Addition 02/06/17 65@Copyright Material
  66. 66. Solution 1. D 2. B 3. A 4. C 5. A 6. D 7. D 8. B 9. D 10. D 11. C 12. A 02/06/17 66@Copyright Material