|
|
|
|
|
Google File SystemGoogle File System (GFS) is a proprietary distributed database system custom developed by Google for their applications to use. It is not, however, a file system in the conventional sense like Ext3 or ReiserFS, which directly address the raw physical disks; files are stored in conventional Linux filesystem formats. Design GFS is optimized for Google's core database needs, web searching. The data is stored persistently, in very large, even multiple gigabyte-sized files which are only extremely rarely deleted, overwritten, or shrunk; files are usually appended to or read. It is also designed and optimized to run on Google's computing clusters, which are comprised of cheap, "commodity" computers, which means precautions must be taken against the high failure rate of individual nodes and the subsequent data loss. Other design decisions select for high data throughputs, at the expense of low latency. The nodes are divided into two types: Master nodes and Chunkservers. Chunkservers store the data files, with each individual file broken up into fixed size chunks (hence the name), similar to clusters or sectors in regular file systems. Each chunk is assigned a unique 64-bit label, and logical mappings of files to constituent chunks are maintained. Each chunk is replicated a fixed number of times throughout the network, the default being three, but even more for high demand files like executables. The Master server doesn't usually store the actual chunk but rather all the metadata associated with the chunks, such as the tables mapping the 64-bit labels to chunk locations and the files they make up, the locations of the copies of the chunks, what processes are reading or writing to a chunk, or taking a "snapshot" of the chunk pursuant to replicating it (usually at the instigation of the Master server, when, due to node failures, the number of copies of a chunk has fallen beneath the set number). All this metadata is kept current by the Master server periodically receiving updates from each chunk server ("Heart-beat messages"). Permissions for operations are handled by a system of time-limited, expiring "leases", where the Master server grants permission to a process for a finite period of time during which no other process will be granted permission to access the chunk. The modified chunkserver, which is always the primary chunk holder, then propagates the changes to the chunkservers with the backup copies. The changes are not saved until all chunkservers acknowledge, thus guaranteeing the completion and atomicity of the operation. Programs access the chunks by first querying the Master server for the locations of the sought chunks; if the chunks are not being operated on, the Master replies with the locations, and the program then contacts and receives the data from the chunkserver directly (similar to Kazaa and its Supernodes). Criticism There can only be one Master server. This appears to be a flaw limiting the system's scalability and reliability, since its maximum size and up-time is limited by the Master server's capability and up-time, and since it catalogs all the metadata, and since also almost all actions and requests flow through it; but it isn't really. Metadata is very compact, mere kilobytes to the megabyte, and the Master server is typically one of the most capable nodes on the network, and there is typically a "shadow" Master server, mirroring the main Master server which steps in if the Master server fails. Also, it is rarely a bottleneck, since clients only request the metadata, and typically cache it; subsequent interactions proceed directly with the chunkservers. Similarly, using a single Master server drastically cuts down on the software complexity that would be requisite to ensure data integrity, atomicity of operations, load balancing, and security, if there were multiple Master servers. See also External links File System
|
 |
|
| Copyright 2005-2009 OnPedia.com. All Rights Reserved |
|
|