了解 Google 的文件系统

讨论 黑客新闻

这些论文评论可以 每周发送到您的收件箱，或者您可以订阅 原子饲料。 一如既往，请随时联系 推特 有反馈或建议！

今天我读了 原论文 关于 Google 文件系统 (GFS)，该系统在公司早期为许多 Google 应用程序提供了存储层。 据报道，最初的实现已被名为 Colossus 的新版本所取代，但阅读原始方法仍然很有启发性，我想我应该快速写一篇关于它的文章。

为什么 GFS 如此重要？

原始论文于 2003 年在 SOSP（操作系统原理研讨会 – 如果不是最好的操作系统研究会议之一）发表。

GFS 因其当时的革命性而进入该计划 – 随附的论文详细介绍了 Google 如何在行业应用中大规模成功实现弱一致性和依赖单个主控制器（稍后详细介绍）的学术思想。

GFS 的最终目标是在 Google 数据中心的商品级机器上提供复制存储层（数据的冗余副本保存在多台机器上）。 开发这样一个系统的最初动机是为批处理作业提供动力，尽管该系统最终为其他项目提供动力。

由于 GFS 是为批处理作业而设计的，因此它主要针对附加文件而不是修改文件进行优化。 该程序的用户通常会立即写出大文件，而不是对文件的特定部分进行修改。

为 GFS 提供支持的抽象是什么？

GFS 的核心是一个概念，称为 块。 块用于将文件分割成固定大小的 64MB 段，然后在数据中心周围复制 †。 块被引用为 块句柄，基本上是一个块的唯一 ID。 将大文件分割成许多块，然后在许多机器上复制这些块可以实现两个目标：提高性能（因为现在单个文件可能有许多读取器和写入器），并允许大文件存在于简单的抽象后面。

为了使这种抽象如何工作的想法更加具体，想象一下使用库来打开磁盘上的文件。 在幕后，该库现在会从数据中心周围的计算机中获取您请求的文件的所有不同部分，然后提供一种透明的方式来与缝合在一起的数据进行交互 †。

上述库（由用户程序客户端调用）通过与 GFS 的多个组件交互来执行获取和写入操作：

• 掌握：主人有一些责任。 首先，这是客户想要与 GFS 交互时的第一个联系点。 除了该功能之外，主站还负责与一组 块服务器 那个主机块。 为了执行其功能，主站在 RAM 中存储了一些表：
  • 从文件名到的映射 块句柄 （块句柄基本上是块的 ID）。
  • 映射来自 块句柄 块所在机器的列表、有关块的版本信息（帮助管理对同一块的多次写入的数据）以及与管理对该块的写入相关的两条信息 – 主块和块租约。 我将在下一节中介绍主要部分和租赁部分。
• 块服务器：块服务器处理磁盘写入和读取的工作。 在主人的指示下，客户开始与他们交谈。

GFS 的写入和读取是如何工作的？

从 GFS 读取

为了将文件读取到 GFS，客户端对主设备说：“我想读取此文件中的这个字节偏移量”，其中该文件看起来像常规文件系统路径。

然后主设备接收来自客户端的请求并计算哪个块对应于关联的文件和字节偏移量。 使用计算出的块的块句柄，主服务器然后获取存储上述块的块服务器列表并将其提供给客户端。 然后，客户端选择一个块服务器，将其与所需的块和偏移量联系，然后向其提供所请求的数据。

在此过程中，客户端还会缓存有关该块的信息以及在需要重新请求该块时可以在其上找到该块的块服务器的信息。

写入 GFS

向 GFS 中的文件写入（在本例中为追加）比从 GFS 中读取要复杂得多。

要启动客户端，请向主服务器询问特定文件的最后一个块（文件末尾是必要的，因为我们正在追加）。 然后，主服务器使用返回的块句柄（块句柄本质上是块的 ID）检查其表中有关该块的信息。

然后，主服务器检查它存储的有关每个块的两条信息 – 主字段和租用字段。

这 基本的 是对已分配用于协调块服务器之间的写入的块服务器的引用。 此分配是短暂的，并受到期日的约束 租。 当租约到期时，主服务器可以分配一个新的块服务器来协调写入。

如果客户端请求的块没有 基本的 分配后，主站分配1，并递增数据的版本。 增加版本号允许主设备跟踪哪些数据是最新的。 如果该块已经有一个主块，则跳过此步骤。

下一步是将有关主服务器和辅助服务器（具有块的块服务器，但不是主服务器）的信息传输到客户端。 从那里，客户端将其想要写入的数据发送到相应的块服务器。 当所有块服务器都拥有数据后，客户端告诉主服务器写入数据。 主块服务器选择块中的字节偏移量（无论文件末尾是什么），并将其发送到所有辅助块服务器，之后所有辅助块服务器都执行正确的操作。

如果主节点和所有辅助节点都写入，则客户端收到成功！ 如果并非所有辅助节点都写入，则客户端会收到故障，此时它需要重新联系主节点并从头开始重复该过程。

包起来

我 找到采访 与一位参与 GFS 的工程师的交流相当有趣。 GFS 在其设计用途方面非常成功，并在 Google 内部得到了广泛采用。

不幸的是，由于一些原因，它无法很好地扩展到新的用例。 首先，系统使用单个主进程来存储块服务器以及其他元数据。 将所有这些信息存储在一台机器的 RAM 中也只能到此为止。

GFS 遇到的另一个问题是存储小文件。 例如，如果用户想要存储许多小于块大小的文件，则主服务器需要为每个文件存储一个条目，并在磁盘上分配完整的块大小。 Google 最终研究了其他系统并对 GFS 进行了调整来解决这个问题（特别是，所讨论的系统之一是 BigTable）。

• [1] 谷歌的新存储系统将尝试减小块大小，原因我将在本文末尾讨论。
• [2] 数据是否实际上缝合在一起在某种程度上是一个实现细节

参考：