--- layout: post title: GFS的演进 category: 技术 tags: BigData GFS keywords: BigData GFS google 分布式系统 分布式文件系统 云存储 description: Kirk McKusick 和 Sean Quinlan 关于 GFS 的起源和演进的一些讨论 date: 2019-11-29 author: followtry published: true --- ## 人物介绍 1. Kirk McKusick : 以在 BSD Unix 上的工作而闻名，而且涉及了 BSD 上的 FFS(Fast File System) 2. Sean Quinlan : 担任了两年的 GFS技术负责人，现在继续担任 Google 的首席工程师 ## GFS 涉及预估 1. 数 GB大小的文件 2. 包含TB 级别的信息和百万对象的数据集 ## Q&A ### 是什么原因导致决定将 GFS 设计为单 Master 架构 ？ 从开始就涉及分布式的Master 太难了，而且需要花费更多的时间。而且使用单 Master设计，工程师可以简化很多问题。 围绕单Master可以更快的交付用户使用。在设计初期，因为预估量在几百 TB 和几百万的文件，因此 GFS 在一开始的时候运行状态是良好的。 ### 在什么情况下 GFS 状态变差了？ 随着存储量的增长，问题逐渐显现。存储量从几百 TB 到几PB，然后又到几十PB。存储量的增加也导致的 Master 中存储的元数据的线性成比例的增加。扫描元数据进行恢复操作的时间也成比例的增加，保存元数据的存储容量也在增长。 而且对客户端来说也是瓶颈。尽管客户端只会与 Master 有很少的交互。但在客户端启动时还是会与 Master对话。因单个 Master 的容量为几千 QPS。而当成千的客户端同时与 Master 连接时，Master 不能及时的处理所有这些请求。同时 MapReduce也会有成千个任务，每个任务都要打开几个文件进行读写。Master需要花费很长的时间来处理这些请求，很显然 ，Mater面临着 巨大的压力。 ### 历史上 GFS 每个数据中心只有一个单元，每个单元只有一个 Master ？ 最初的设计目标是这样的，但是并不能解决问题，一部分是因为单 Master设计的局限性，另一部分是因为隔离很困难。通常每个数据中心有一个以上的单元。 而我们也做了所谓的"多单元"方法，该方法是在ChunkServer 池的上面放置多个 GFS Master 。然后这些 Chunkserver 可以配置多个 GFS Master。这样就可以提供一个基础的存储池，多个 GFS 的 Master。然后使用应用程序在这些单元之间划分数据。 ### 每个应用程序都将拥有自己的主服务器，该主服务器将负责管理自己的小文件系统。基本上是这个主意吗？ 在提出所谓的“多单元”改进的时候，也提供了叫命名空间的东西。其只是对命名空间进行分区的一种静态方式。可以对上层使用的应用程序隐藏这些`多单元改进`的内容。比如一个日志系统耗尽了单个单元的能力，可以将系统移至多单元上。 命名空间描述了如何在不同的单元间进行数据分区。 **Hadoop在 2.x做出的联邦机制跟 GFS 的多单元机制比较相似。都是将多个 Master 构建在一个基础的 Chunkserver 之上，然后通过统一的层隐藏这些细节。** 虽然 Google 的架构师们已经为至少几个数量级的增长提供了足够的资源，但是Google 还是很快超过了该数量级。 ### 文件数量一致是 GFS 的重要问题吗？ 是的，随着Google 的快速增长，对 GFS 的另一个参数也带来了压力。将 Chunk 设置为 64MB 大小。只是因为起初 Google 爬取的文件非常大。但随着变化，现在需要的文件远远小于 64MB，比如 Gmail。这样为了存储文件，而在主 Master 上要存储更多的元数据，也就导致了 GFS 的瓶颈。 如果文件大小降低到小于 64MB,甚至很小，那么对于每个文件仍然需要再 Master 中存储同样大小的元数据。这样实际数据文件和元数据大小的比值就会降低，master 需要存储更多的元数据。而 master 的内存限制决定了在内存耗尽前只能容纳有限的文件。 即使应用了`多单元`的改进,但仍然需要限制文件的数量，而Chunkserver中存储的实际数据文件的容量却不是问题，因为可以线性扩展。 ### 您想出什么长期策略来解决文件计数问题，分布式Master？ 分布式Master肯定会允许增加文件数量，只要愿意为此添加机器，还是很有帮助的。 分布式 Master 的吸引力之一就是如果你将元数据扩大两个数量级，将文件大小降低平均 1MB 大小，相对于涉及文件大小64MB 的系统来说有很多的事情要做。 如果设计文件大小为 1MB，那么相对于设计64MB 文件来说可以提供更多的功能，而且1MB 是一个折中的方案。 ### 基于以上讨论，您正在做什么来设计GFS以处理1-MB文件？ 没有改进 GFS，而是对提供1MB 文件的分布式 Master 系统进行全薪的设计。这样可以将每个 master 的文件数量目标定位 1亿左右。没有任何单一的 Master 会拥有全部的元数据。 这个系统就是后来被命名为`Colossus`的全新的分布式文件系统。可参考，该系统被设计用来面向实时的，低延时的读写请求。如视频服务(Youtube) ### 设计GFS的最初重点是批处理效率，而不是低延迟。现在又回来给您带来麻烦，尤其是在处理视频等方面。您如何处理？ 一开始的GFS设计模型就是要实现吞吐量，而不是要达到的延迟时间。当我们进行一次pullchunk时，我们将其每秒限制为大约5-10 MB。因此，对于64 MB，您说的是恢复需要10秒。像这样的许多其他事情可能需要10秒钟到一分钟的时间，对于批处理类型的操作来说效果很好。如果您要执行大型MapReduce操作，只要其中一项不是真正的散乱者，就可以了，在这种情况下，您会遇到另一种问题。通常来说，在一个小时的批处理过程中，大约一分钟的打h并没有真正出现。我们的Master故障转移也有类似的问题。最初，GFS没有提供Master自动故障转移的准备。这是一个手动过程。尽管发生的次数很少，但每次发生时，电池可能会停机一个小时。甚至我们最初的Master故障转移实施也需要几分钟的时间。但是，在过去的一年中，我们将其降低到数十秒左右。 但是对于面向用户的应用程序，这是不可被接受的。因为GFS 的用户群已经从基于 MapReduce 的批处理世界转移到更依赖 Bigtable 之类的交互式世界。但是在面向批处理设计的文件系统上构建交互式文件系统本身就是一个很糟糕的问题。 ### 可以认为通过转移到分布式主文件系统，您肯定可以解决某些延迟问题吗？ 这肯定是设计目标之一，而且 Bigtable 是个非常善于识别故障的系统，它试图比以前更快的响应故障。将其用作元数据存储也可以解决一些延时问题。 ### 怎么可能最终得到不一致的结果？ 客户端故障有一种使问题恶化的方法。基本上，GFS中的模型是客户端只是继续推动写入，直到成功为止。如果客户端在操作过程中最终崩溃，那么事情将处于不确定状态。 早期，这被认为是可以的，但是随着时间的流逝，我们拉紧了可以容忍不一致之处的时间，然后我们继续缓慢地减少这种情况。否则，每当数据处于不一致状态时，文件的长度就可能不同。这可能会导致一些混乱。我们必须有一些后门接口来检查那些实例中文件数据的一致性。我们还有一个叫做RecordAppend的东西，它是一个接口，供多个编写者同时添加到日志中。那里的一致性被设计得非常松散。回想起来，事实证明，这比任何人想象的都要痛苦得多。 ## 参考文献 >