Google文件系统（GFS）评析：（上）

最新推荐文章于 2024-05-23 21:59:25 发布

ifeves

最新推荐文章于 2024-05-23 21:59:25 发布

阅读量516

点赞数

原文链接：http://blog.jobbole.com/83500/

版权

GFS：一种根本的设计思想转变，还是一个古怪的例子？

正如大多读者所了解的那样，我认为企业现有的存储模型有很严重的弊端。当看到了跟现有存储模型不一样的模型之时，我就很想了解的更多。特别的，我会评估这些创新模型的市场前景。所以，遇到类似于GFS或者压缩备份的好的技术，我就会去考虑客户是否会以及以何种方式去购买它。

本文将会通过评估GFS商业可行性的方式来笼统的描述它，如果你需要关于GFS的技术文章，我只能推荐Ghemawat、Gobioff 和 Leung 合著的《The Google File System》。本文内容也很多取自于那篇论文的描述。至于维基百科的文章，则并没有很好的介绍GFS。

从太空看谷歌

GFS是实现有史以来最强大通用机群的关键技术之一。当大多数IT人为了备份有几千个用户的邮件服务器而损失睡眠时间的时候，谷歌的基础平台却既可以支持大规模用户群，又可以定期推出计算和数据密集型应用，这让竞争对手非常恐惧。谷歌员工是怎么做到的呢？

这一方面可能是因为谷歌员工比你聪明，谷歌招募了数以百计的计算机科学博士生以及更多的聪明人。一方面是由于他们的经历：穷博士根本负担不起用高性能硬件来运行他们的实验技术，所以他们一开始就成本很低而且越来越低。最后，聪明又贫穷的他们反思了整个IT平台搭建规范。

他们卓越的洞察力（insight）：与其将平台可用性建立在昂贵的高性能机器上，不如使用廉价的机器，而将平台可用性建立在这些廉价机器组成的系统上面。这完全改变了IT产业的经济学，正如上个世纪70年代的小型机以及上个世纪80年代的个人电脑以及90年代的局域网那样。当处理器、带宽以及存储都很廉价的时候，你就可以花费很多资源来实现IBM所提倡的自动计算。精心设计而且代价低廉的系统，其性能以及经济性都可以获得扩展。

所有这一切都表明，谷歌并没有用他们的平台来完成其他人都没有做过的任务。谷歌只是将很多技术拼接在一起并且将其扩展到一个前所未有的高度。

提醒首席信息官：您公司的用户们用不了多久就会发现谷歌可以做到，而您的公司不可以。您的日子将不会很轻松的。

从地球轨道上看GFS

尽管GFS被称为谷歌文件系统（不要和Sistina的GFS混淆（尽管怎么混淆我不知道）- 或许我们应该称之为GoogleFS），可是它可不仅仅是一个文件系统而已。它还包含数据冗余、支持低成本的数据快照，除了提供常规的创建、删除、打开、关闭、读、写文件操作，GFS还提供附加记录的操作。

那个附加记录的操作折射出谷歌工作任务独特的一面：通过数以百计的网页爬虫，谷歌的数据通过大规模序列写操作的方式得以持续更新。跟通过同步和协调来修改现有数据的方式相比，只将新数据附加在现有数据后面要方便的多。

谷歌工作任务另一个独特的方面是它经常包含两种读操作：大规模流读取和小规模随机读取。因为大规模读写操作非常常见，GFS注重对持续的高带宽而不是低延迟或者每秒输入输出量做出优化。因为许多文件大小达到几个GB，GFS针对数百万的文件处理进行优化，这也就是说一个单独的文件系统应当能够处理几个PB的数据。

而所有的这些都是建立在廉价的组件上面，考虑到机群的规模，可以理解故障是经常发生的。系统检测其本身，发现、承受并从组件错误中恢复过来，错误包括磁盘错误、网络错误以及服务器错误。

从SR-71黑鸟战机看GFS

GFS机群包含了一个master和许多chunkserver，并且会被许多客户访问。每个部件一般都是非常便宜的运行linux系统的机器（最新的一般具备2GHZ xeons处理器、2GB内存以及800GB左右的磁盘）。

文件被分割成了许多chunk，每一个chunk被一个64位的handle唯一标识，chunk被当做普通的文件存储在linux系统中。每个chunk至少会在另一个chunkserver上有备份，而默认会为每个chunk做三个备份。Chunk跟它们组成的文件一样，非常的大，标准大小是64MB。Chunkserver一般不会缓存数据，因为chunk都是存储在本地，故而linux已经将经常被访问的数据缓存在内存中了。

或许跟我一样，当你看到单一master之后会认为存在瓶颈或者单点故障，那么你需要像我一样多了解一下背后的架构。Master仅仅通过几个字节的信息来告诉客户端哪个chunkserver具有它所需要的chunk。现在可以直观的知道chunk size很大的一个好处：客户端不必跟master有很多交互就可以哦获得大量数据。

这解决了性能瓶颈问题，但是当master会不会成为单点故障呢？我们知道普通数据是被拷贝三次（因为磁盘很便宜，所以可以这样做），但是那些至关重要的存储包括chunk位置在内的元数据呢。

Master处于性能考虑在内存中主要存储了三种元数据：

文件和chunk的名称（也即是程序员术语中的命名空间）
文件和chunk之间的映射关系，比如说每个文件是由哪些chunk共同组成
每个chunk备份的位置

那么，如果master宕机了，其存储的数据必须很快被替代。前两种元数据——命名空间和映射——通过在master机器磁盘中存储日志以及在其他机器上备份的方式被确保安全。日志文件会被经常检查更新以便在需要新master的时候快速恢复数据。多快呢？由于shadow master（在后台跟master保持同步）的存在，读取操作几乎可以立刻执行。写操作会被暂停30秒到60秒以便新的master和chunkserver之间同步数据。许多廉价磁盘冗余阵列的恢复不会比这个速度更快。

最后一种元数据，chunk备份的位置，是在各个chunkserver上面存储的（且在临近的机器上有备份），当master重启或者一个新的chunkserver加入机群的时候会将这个元数据告知 master。由于是master控制chunk的放置位置的，所以它也可以在行chunk创建的时候自行更新自己的元数据。

Master也通过和chunkserver“握手“的方式来追踪机群机器的健康状况。通过checksum（译者注：一种被用来校验数据完整性的方法）来检测数据损坏。即便如此，数据还是可能会被混杂。于是，GFS依靠附加新数据的方式而不是重写现有数据的方式来完成写操作。再通过经常性的检查更新、快照、以及备份，使得数据损失的概率非常的低，而且即便数据损失了也只是导致数据不可访问而不是获得损坏的数据。

GFS 廉价磁盘冗余阵列(RAID)

谷歌员工并没有这样去称呼它，但是本网站非常关心存储，而且我发现这一部分特别的有趣。GFS并没有使用任何的RAID控制、光纤通道、iSCSI、HBAs、 FC 或者SCSI磁盘、双端口或者其它在wide-awake数据中心常见的昂贵设备。然而，它却可以工作并且工作的还很好。

拿创建备份（你我称之为镜像）做个例子。机群中的所有机器通过全通以太网光纤管道连接，可以并行传输数据。这意味着只要新的chunk数据传输到chunkserver，chunkserver就可以立刻以全部网路带宽（大约12MB/秒）开始传输数据到备份chunk，而不用降低接收数据速率。而第一个备份所在的chunkserver一旦接收到数据也重复这个操作，所以两个备份chunk可以与第一个chunk同时完成数据传输。

除了可以快速创建备份，master的备份防止规则还会降备份放置在不同的机器以及不同的机架上面，以便降低因为电源或者网络转换损失导致的数据不可用的概率。

池和均衡

也许虚拟化存储正处在该技术运用的hype cycle(炒作周期)下降阶段，而通过GFS你可以看到当虚拟化被建立在文件系统中的时候是有多么的简单。与其采用一个复杂的软件层来在RAID阵列之间管理数据块，GFS的master将新chunk备份放置在磁盘利用率低于平均水平的磁盘中。所以在没有使用任何棘手而昂贵的软件的情况下，经过一段时间，各个chunkserver的磁盘利用率也会相差无几。

Master也会周期性的对chunk备份位置做再均衡处理，主要考虑的因素是磁盘的空间利用率以及负载均衡。这个过程也避免了新加入机群的chunkserver在加入的一刻被大量数据搞崩溃。Master会逐渐向这个行chunkserver中添加数据。Master也会将chunk从高磁盘利用率的chunkserver上面转移到其他chunkserver上面。

释放存储空间的过程会很慢。Master会让旧的chunk继续存在几天然后批量释放空间，而不是立即删除释放空间。释放操作会在master不忙的时候在后台执行，这也减少了对机群的影响。此外，因为被删除的chunk一开始仅仅是被重命名了，故而系统也提供了针对意外数据丢失的一层保障。

我们知道这一定是在现实世界中可行的，毕竟我们天天都会使用谷歌。但是它工作效果有多好？在论文中作者提供了基于一些谷歌GFS机群实验而来的统计结果。