谷歌技术“三宝”之一的Google文件系统和Kosmos 文件系统

 

    虽然针对大规模分布式存储系统，Google将推陈出新，推新的理由有很多，如"single-master design,…… but it was certainly unacceptable for latency-sensitive applications, such as video serving."。参考《Google File System II: Dawn of the Multiplying Master Nodes》和《GFS:Evolution on Fast-forward》。但是GFS毕竟为其服务了10年时间，连李开复博士也宣称每个计算机学生都有必要学学这套系统。

      本篇也一起谈谈Kosmos文件系统，传闻Google的两个共同创始人佩奇和布林有两个大学同窗，是两个印度人,名叫Anand Rajaraman和Venky Harinarayan，看到Google获得巨大成功之后，就动手做了个一个新的搜索引擎CloudStore (原先一直叫Kosmos filesystem，现在搭上了云计算的顺风车改了头衔)。在做这个搜索引擎的过程中，他们实现了一个类似GFS的文件系统KFS(很多理念都从GFS那里搬过来，比如constant monitoring, error detection, fault tolerance, and automatic recovery)。因为GFS的论文只是设计，而KFS是开源的，两者结合看效果可能比较好。

     首先，看过谷歌工程师写地这篇《The Google File System》的能不能做下面这道证明题：考虑一个拥有1000个节点的GFS集群，定性(不定量)证明：在有800个节点失效的情况下，剩下的200个节点仍然能够完成工作，即performance下降的情况下，scalability,reliability,availability等保持良好。

 

本文想阐释谷歌文件系统的一些设计理念。

一 架构：

下图为谷歌文件系统的结构图，一个GFS集群包含一个主服务器和多个块服务器, 这是一个单一主服务器模型：

      概括一下块(chunk)的一些信息：块尺寸是64MB；文件被分割成固定尺寸的块，在每个块创建的时候，服务器分配给它一个不变的、唯一的64位的块句柄对它进行标识；每个块都会复制到多个块服务器上。

      主服务器保存三种主要类型的metadata：文件和块的命名空间，文件到块的映射，以及每个块副本的位置，它通过全局的信息精确确定块的位置以及进行复制决定。主服务器的主要工作有：主服务器在后台周期扫猫自己的整个状态，用来在块服务器间实现块的垃圾收集的功能，用来实现块服务器失效的时复制新副本的功能，用来实现负载均衡的块移动的功能，以及用来实现统计硬盘使用情况的功能等。

      块服务器保存着块，并根据指定的块句柄和字节区间来读写块数据。

      客户端不通过主服务器读写数据。反之，客户端向主服务器询问它应该联系的块服务器。客户端短期缓存这些信息，后续的操作直接跟块服务器进行。

      读取流程:首先，利用固定的块尺寸，客户端把文件名和程序指定的字节偏移转换成文件的块索引。然后，它把文件名和块索引发送给主服务器。主服务器回答相应的块句柄和副本们的位置。客户端用文件名和块索引作为键值缓存这些信息。

      此系统可靠性方面相关的一些设计，下面概要叙述一下，后面会有详细描述：

      1主服务器不持久化保存块的位置信息。主服务器在自己启动以及块服务器加入集群的时候，询问块服务器它所包含的块的信息，然后定期的心跳信息监控块服务器的状态。

      2 名称空间和文件块映射的metadata，会用log的方式保存在主服务器的硬盘上的操作日志内，并在远程的机器内复制一个副本。使用log，可以更新主服务器的状态，而且不用担心服务器崩溃带来的数据不一致的风险。

      3. 主服务器通过重放operation log恢复其文件系统。operation log是metadata唯一的持久化存储记录，起到了定义同步操作顺序的逻辑时间线的作用。文件和块及其版本都是唯一和持久地由他们创建时的逻辑时间标识的。进行恢复仅需要最新的checkpoint和相应的日志文件。日志增长到一个特定尺寸的时候，主服务器汇总的状态为一个checkpoint。

4文件命名空间的修改（例如ÿ