Google File System
Google File System (GFS) is a proprietary
distributed file system based on Linux and developed by Google for their
applications' use
Design
GFS is optimized for Google's core data storage 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, the nodes of 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, even
when that makes latency worse.
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 chunks, 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
particular 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 by the Master server 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 desired chunks; if the chunks are not being operated on (if there are no
outstanding leases), 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- the code does not allow
multiple Masters. 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 Google's engineers argue that 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; for reliability, 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
|