Thesis Reading Notes-the Google File System

Author: Liu Xuhui Raymond reprinted. Please indicate the source

Email: colorant at 163.com

Blog: http://blog.csdn.net/colorant/

More paper Reading Note http://blog.csdn.net/colorant/article/details/8256145

 

Keywords

GFS Distributed File System

 

= Target question =

 

Build large-scale, scalable, high-reliability, and distributed file systems on relatively inexpensive machines

 

= Core idea =

 

GFS's design philosophy closely revolves around its goals. Its important basic assumptions are:

• Because the system is built on a large number of relatively inexpensive machines, hardware failure is the norm and it is necessary to effectively tolerate hardware failures at various levels.
• The size of a file is larger than that of a conventional file, usually in GB.
• File batch read/write operations are more frequent than random read/write operations, and write operations are mainly added to optimize these application modes.
• Concurrent write operations are required, and data throughput is higher than low latency.

 

Shows the basic system architecture and working mode of GFS.

 

 

Basically, the system framework of GFS can be summarized:

• Single master node + multiple data service nodes
• The master node maintains meta information such as file namespaces, permissions, data block ing, and storage locations, coordinates load balancing among data service nodes, and schedules read/write operations. The data location information must be obtained from the master node for the first read and write operations on all clients.
• To minimize the burden on the master node, the client directly interacts with the data service node to read and write data in the future. The client caches some data meta information at the same time, further reducing the burden on the master node.
• The master node maintains related meta information in the memory to accelerate retrieval, and uses log, snapshot, and multi-machine backup mechanisms to ensure the reliability of meta data.
• Files are stored in chunks of fixed size. Each Chunk is stored in different data service nodes in the form of multiple backups. On the one hand, for reliability, on the other hand, it can increase the throughput of read data operations.
• No cache data is used for data service nodes or client code (not required), which simplifies the complexity of the system.

 

= Implementation =

 

There are also various details to consider.

 

Chunk Size: The size of the file block set by GFS by default is 64 mb. A larger file block size can reduce the management overhead of the master node. For example, less meta data needs to be stored, less client communication requirements. However, a large file block size also results in a hotspot of some files simultaneously read by multiple clients on a data service node (because of the large chunk
Size leads to fewer file blocks. Reading the same file may eventually read the same file block)

 

ChunkLocation Information:The master node needs to make the meta information managed in the memory persistent in the form of log/snapshot, but does not persist the specific location information of the file block, but queries the data service node at each startup, on the one hand, it simplifies data consistency in various disaster recovery scenarios. On the other hand, whether data exists is ultimately determined by the data service node.

 

Data Interaction Process and consistency:To ensure the consistency of data backup replica, we need to ensure the consistency of all replica update operations. To reduce the burden on the master node, gfs designs a lease to manage replica, each operation will have a replica to get the lease of the specific chunk. This replica is called primary. When the lease is effective, the client will execute and distribute the control information for data updates through this primary, however, the data itself is not necessarily written to primary before distribution, but written to the node closest to the client, and then written to the adjacent node in sequence by the node. This is done to maximize the utilization of network bandwidth.

 

 

 

Data Integrity: The internal data of a chunk is divided into 64 KB data blocks for verification. Each data service node is responsible for verifying its own data and regularly scanning all file blocks, this helps to detect data corruption as soon as possible.

 

Space recycling, expired Data Detection, etc.: GFS does not delete the physical files corresponding to the deleted data blocks in real time. Instead, gfs renames and marks them and periodically recycles them in batches. This reduces the complexity of State synchronization, batch Processing also improves the performance. In various disaster recovery scenarios, data updates may be inconsistent on certain nodes. GFS maintains a version for each chunk, each update operation adds a version number corresponding to the chunk, which is used in various read/write operations to check data validity.

 

= Related research, project, etc. =

 

HDFS is an open-source implementation of GFS design ideas.