GFS_论文笔记

GFS 论文笔记

Google 三驾马车之一

1. 介绍

列出了设计 GFS 的三大基本假设

• 首先，组件故障是一种常态，而不是例外。因此，持续监控、错误检测、容错和自动恢复必须与系统集成在一起。
• 其次，文件大小很大 ，因此，设计假设和参数(如I/O操作和块大小)必须重新考虑。
• 第三，大多数文件是通过追加新数据而不是覆盖现有数据来改变的

2. 设计摘要

系统由大量廉价的普通服务器组成，需要容错

负载基本是 大量的流式读取和小量随机读

高持续带宽比低延迟更重要。

此外，GFS还有快照和记录追加操作。

2.3 架构

GFS集群由单个主服务器（其实还有几个影子 master）和多个chunkserver组成，并由多个客户机访问，架构图如下所示：

文件被分成固定大小的块。每个块都由一个不可变且全局唯一的64位块句柄标识，该句柄是在创建块时由master分配的。Chunkservers将块作为Linux文件存储在本地磁盘上，并读取或写入由块句柄和字节范围指定的块数据。为了提高可靠性，每个块都被复制到多个chunkserver上。默认情况下，存储三个副本

master 主服务器维护所有文件系统元数据，主服务器定期与心跳消息中的每个块服务器通信，给它指令并收集它的状态。

客户端和chunkserver都不会缓存文件数据，然而，客户端会缓存元数据。

2.4 单 master

客户端从不通过主服务器读写文件数据。相反，客户端询问主服务器它应该联系哪个块服务器。它在有限的时间内缓存这些信息，并直接与chunkserver进行交互以进行许多后续操作。

然后，它向主服务器发送一个包含文件名和块索引的请求。主服务器使用相应的块句柄和副本的位置进行响应。客户端使用文件名和块索引作为键来缓存该信息。

直到缓存的信息过期或文件重新打开。

2.5 块大小

块大小的设计：

• 首先减少了客户与主机交互的需求

• 其次减少网络开销

• 第三，它减少了存储在主服务器上的元数据的大小。

一个小文件由少量块组成，可能只有一个块。

对于热点块的数据，我们通过使用较高的复制因子存储这些可执行文件，并使批处理队列系统错开应用程序的启动时间，解决了这个问题。

2.6 元数据

master 存储三种类型的元数据：文件和块名称空间、从文件到块的映射以及每个块副本的位置。

前两种类型(名称—块名称空间和文件到块的映射)也通过将突变记录到存储在master的本地磁盘上并复制到远程机器上的操作日志来保持持久化

master不会持久地存储块位置信息。相反，它会在主服务器启动时询问每个chunkserver关于它的chunk的信息，以及每当有chunkserver加入集群时。