2012

Faculty of Information Technology Strathmore University College DAVID MBARANI 072438

MIT 8102-ADVANCED DISTRIBUTED SYSTEMS

A distributed file system or network file system allows access to files from multiple hosts sharing through a computer network, enabling multiple users on multiple machines to share files and storage resources. Identify and give a discussion of any three distributed file systems existing, with focus on some of the key design challenges. Give a summary of your study in a report of at least 4 typed pages.

FILE SYSTEMS
INTRODUCTION Development of distributed computing theory has enabled the sharing of data across networks. An important aspect of this is the sharing of resources across physically distributed computers using a common file system which is largely the purpose of a Distributed File System (DFS). The ideal DFS implementation tries to mimic the functionality of a local file system and the performance of a DFS is measured by its proximity to this goal. A file system is a subsystem of an operating system whose purpose is to organize, retrieve, store and allow sharing of data files. A Distributed File System is a distributed implementation of the classical time-sharing model of a file system, where multiple users who are geographically dispersed share files and storage resources. Accordingly, the file service activity in a distributed system has to be carried out across the network, and instead of a single centralized data repository there are multiple and independent storage devices REQUIREMENTS OF A DFS A distributed file system has to satisfy three requirements: Transparency Fault Tolerance Scalability Transparency measures the system ability to hide the geographic separation and heterogeneity of resources from the user and the application programmer so that the system is perceived as a whole rather as a collection of independent resources. The cost of implementing full transparency is prohibitive and challenging. Instead several types of transparencies, that are less transparent than full transparency, have been introduced such as network transparency and mobile transparency. Location Transparency is where the name of a file does not reveal any hint as to its physical storage location. Location Independence refers to a situation where a name of a file need not be changed when the files physical storage location changes. Access transparency is where Client programs should be unaware of the distribution of files and Performance transparency is where Client programs should continue to perform well on load within a specified range. Fault tolerance can be defined in terms of two types of responses to the occurrence of a fault. When a fault occurs in the system the fault tolerant files can be: (a) Recoverable Files: These files have the ability to revert to an earlier consistent state when a file operation fails or aborts. This is achieved by atomic update techniques either all changes are successfully applied, or no change to any file will be made. This all-or-nothing approach is called an atomic update (b) Robust Files : These files have the ability to survive crashes of the storage medium. This is achieved by redundancy techniques and stable storage. GOOGLE FILE SYSTEM The Google File System (GFS) is a proprietary distributed file system developed by Google. It is designed to provide efficient, reliable access to data using large clusters of commodity hardware. The files are huge and divided into chunks of 64 megabytes. Most files are mutated by appending new data rather than overwriting existing data: once written, the files are only read and often only sequentially. The GFS is optimized to run on computing clusters where the nodes are cheap computers. Hence, there is a need for precautions against the high failure rate of individual nodes and data loss. The GFS was developed based on the following assumptions:

FILE SYSTEMS
Systems are prone to failure. Hence there is a need for self-monitoring and self-recovery from failure. The file system stores a modest number of large files, where the file size is greater than 100 MB. There are two types of reads: Large streaming reads of 1MB or more. These types of reads are from a contiguous region of a file by the same client. The other is a set of small random reads of a few KBs. Many large sequential writes are performed. The writes are performed by appending data to files and once written the files are seldom modified. Need to support multiple clients concurrently appending the same file.

Architecture Master Chunk Servers Client Files are divided into fixed-size chunks. Each c h u n k i s i d e n t i f i e d b y an immutable and globally unique 64 bit chunk handle assigned by the master at the time of chunk creation. Chunkservers store chunks on local disks as Linux files and read or write chunk data specified by a chunk handle and byte range. For reliability, each chunk is replicated on multiple chunkservers. By default, we store three replicas, though users can designate different replication levels for different regions of the file namespace. The master maintains all file system metadata. This includes the namespace, access control information, the mapping from files to chunks, and the current locations of chunks. It also controls systemwide activities such as chunk lease management, garbage collection of orphaned chunks, and chunk migration between chunkservers. Chunk Size The GFS uses a large chunk size of 64MB. This has the following advantages: a. Reduces clients need to interact with the master because reads and writes on the same chunk require only one initial request to the master for chunk location information. b. Reduce network overhead by keeping a persistent TCP connection to the chunkserver over an extended period of time. c. Reduces the size of the metadata stored on the master. This allows keeping the metadata in memory of master.

Google File System Architecture In google file system file access is done through File read and file write methods. In file read the following takes place A simple file read is performed as follows: Client translates the file name and byte offset ,It sends the master a request containing the file name and chunk index, the master replies with the

FILE SYSTEMS
corresponding chunk handle and locations of the replicas, the client then sends a request to one of the replicas and further reads of the same chunk require no more client-master interaction until the cached information expires or the file is reopened. Consistency The GFS applies mutations to a chunk in the same order on all its replicas. A mutation is an operation that changes the contents or metadata of a chunk such as a write or an append operation Replication The GFS employs both chunk replication and master replication for added reliability. System Availability The GFS supports Fast Recovery to ensure availability. Both the master and the chunkserver are designed to restore their state and start in seconds no matter how they terminated. Data Integrity The GFS employs a checksum mechanism to ensure integrity of data being read / written. A 32 bit checksum is included for every 64KB block of chunk. HADOOP FILE SYSTEM Hadoop is a distributed parallel fault tolerant file system inspired by the Google File System. It was designed to reliably store very large files across machines in a large cluster. Each file stored as a sequence of blocks; all blocks in a file except the last block are the same size. Blocks belonging to a file are replicated for fault tolerance. The block size and replication factor are configurable per file. The files are write once and have strictly one writer at any time. This DFS has been used by Facebook and Yahoo Architecture The file system metadata and application data stored separately. The Metadata stored on a dedicated server called the NameNode. Application data are stored on other servers called DataNodes. File Access Method File Read When an application reads a file, the HDFS client first asks the NameNode for the list of DataNodes that host replicas of the blocks of the file. It then contacts a DataNode directly and requests the transfer of the desired block. File Write When a client writes, it first asks the NameNode to choose DataNodes to host replicas of the first block of the file. The client organizes a pipeline from node-to-node and sends the data. When the first block is filled, the client requests new DataNodes to be chosen to host replicas of the next block. Synchronization The Hadoop DFS implements a single-writer, multiple-reader model. The Hadoop client that opens a file for writing is granted a lease for the file; no other client can write to the file. The writing client periodically renews the lease. When the file is closed, the lease is revoked. Replication Management The blocks are replicated for reliability. Hadoop has a method to identify and overcome the issues of underreplication and over- replication. The default number of replicas for each block is 3. Consistency The Hadoop DFS use checksums with each data block to maintain data consistency. The checksums are verified by the client while reading to help detect corruption caused either by the client, the DataNodes, or network. When a client creates an HDFS file, it computes the checksum sequence for each block and sends it to a DataNode along with the data.

FILE SYSTEMS
Network File System (NFS) Sun Network File system is one of the most popular and widespread distributed file system in use today. The design goals of NFs include: Any Machine can be a client and /or a server NFS must support diskless workstations Heterogeneous systems should be supported clients and servers may have different hardware and/or operating system. Heterogeneous systems should be support The NFS client and server communicate over remote procedure calls (Suns RPC) using two protocols: the mounting protocol and the directory and file access protocol. The mounting protocol is used to request a access to an exported directory (and the files and directories within that file system under that directory). The directory and file access protocol is used for accessing the files and directories (e.g. read/write bytes, create files, etc.). The use of RPCs external data representation (XDR) allows NFS to communicate with heterogeneous machines. The initial design of NFS ran only with remote procedure calls over UDP. This was done for two reasons. The first reason is that UDP is somewhat faster than TCP but does not provide error correction (the UDP header provides a checksum of the data and headers). The second reason is that UDP does not require a connection to be present. This means that the server does not need to keep per-client connection state and there is no need to reestablish a connection if a server was rebooted. Clients send RPC messages to the server to manipulate files and directories. A file is accessed by performing a lookup remote procedure call. This returns a file handle and attributes. It is not like an open in that no information is stored in any system tables on the server. After that, the handle may be passed as a parameter for other functions. For example, a read(handle, offset, count) function will read count bytes from location offset in the file referred to by handle. Files are accessed through conventional system calls (thus providing access transparency). If you recall conventional UNIX systems, a hierarchical pathname is dereferenced to the file location with a kernel function called namei. This function maintains a reference to a current directory, looks at one component and finds it in the directory, changes the reference to that directory, and continues until the entire path is resolved. At each point in traversing this pathname, it checks to see whether the component is a mount point, meaning that name resolution should continue on another file system. In the case of NFS, it continues with remote procedure calls to the server hosting that file system. NFS performance was generally found to be slower than accessing local files because of the network overhead. To improve performance, reduce network congestion, and reduce server load, file data is cached at the client. Entire pathnames are also cached at the client to improve performance for directory lookups. The biggest problem with NFS is file consistency. The caching and validation policies do not guarantee session semantics. NFS assumes that clocks between machines are synchronized and performs no clock synchronization between client and server. One place where this hurts is in distributed software development environments. Conclusion. Clearly from the discussion above, each distributed file system has its own challenges; performance of each is largely centered on the approach and file system factors such as Architecture, the type of Processes, the Naming mechanism, the Replication and Synchronization schemes and the Consistency techniques employed

FILE SYSTEMS
REFERENCES Zhang S., Distributed Filesystems Review, Online Presentation, http://www.slideshare.net/schubertzhang/distributed- filesystems-review, May 2008 Distributed Operating Systems, Andrew Tanenbaum, ; 1995 Prentice Hall The NFS Distributed File Service: NFS White Paper, Sun Microsystems, March 1995 http://www.sun.com/software/white-papers/wp-nfs/ Distributed Systems, Concepts and Design, Third Edition, 2003, George Coulouris,Jean Dollimore and Tim Kindberg