GFS是Google在2003年发表的一篇论文,虽然Morris在6.824上说这篇论文并没有太多的创新点,但是它成功构建了一个由1000多台廉价机器组成的分布式存储集群,在当时算是技惊四座的存在,于是就被计算机系统领域最顶级的会议接收了。

论文地址:https://pdos.csail.mit.edu/6.824/papers/gfs.pdf

image-20230219212055948

摘要

GFS文件系统是一个面向大规模数据密集型应用、可伸缩(scalable)的分布式文件系统。GFS虽然运行在廉价的普通硬件上,但是它提供了容错机制(fault tolerance),并且为大量的客户机提供了高性能的服务。

GFS的设计目标与传统的分布式文件系统类似,但是根据谷歌内部的应用负载情况和技术环境作出了一些改变。我们重新审视了传统文件系统在设计上的折衷选择,衍生出了完全不同的设计思路。

GFS满足了谷歌对于存储的需求,并且已经广泛部署在了谷歌内部,存储大量数据的同时还作为大规模数据集的研究和开发工作。在2003年,谷歌最大的集群用几千个硬盘提供了几百T的空间,可以为好几百个客户机服务。

1 简介

谷歌不同于传统分布式存储系统的设计思路如下:

  1. 将组件崩溃(component failures)视为常态而不是意外,由于GFS运行在成百上千台廉价的存储机器上,所以任何意外都有可能存在,比如应用程序bug,操作系统bug,人为错误,机器故障等等,因此必须将持续的监控、错误侦测、灾难冗余以及自动恢复集成到GFS中。
  2. 文件大,好几G的文件非常普遍,用管理小文件的方式来管理这些文件肯定不太合适,因此需要重新设计IO操作和Block的尺寸。
  3. 绝大部分的文件修改是在文件尾部添加数据,而不是覆盖操作。随机写入的操作也基本不存在。一旦文件写入以后,以后基本不会修改,只有读取,而且是按顺序读。对于这些访问模式,客户端对于数据块的缓存没有必要,因此,需要重点考虑的就是数据的追加操作,它是性能优化和原子保证的主要考量因素。
  4. 应用程序和文件系统API的协同设计提高系统的灵活性。GFS放松了对于一致性模型的要求,采用弱一致性的方式,简化了对于GFS的设计。引入原子性的记录追加操作,来保证多客户端之间数据追加的一致性,而不需要额外的同步操作

2 设计概述

2.1 设计需求

  • 组件失效是常态,所以需要好的容错机制
  • 能够对大文件进行有效管理,小文件也支持,但是不特殊优化
  • 对两种读操作的优化:大规模的流式读和小规模的随机读,在进行随机读的时候,如果程序对性能有要求,可以将随机读合并后排序,这样就可以按顺序批量读,而不需要来回移动
  • 对大规模、顺序的、数据追加方式的写操作
  • 重视吞吐量,不重视响应时间

2.2 接口

  • 类似传统文件系统的分层组织(目录树),用路径名来识别一个文件
  • 创建文件、删除文件、打开文件、关闭文件、读和写文件
  • 快照(快速实现对于一个文件的拷贝)
  • 原子操作在文件尾部追加记录

2.3 架构

一个GFS集群包含一个Master节点,多台chunk服务器,以及需要对数据读写的多个客户端

Master节点虽然说只有一个,但其实只是逻辑上的一个,在实际中可能有好几个,比如主Master服务器,备用的Master服务器和影子Master服务器,如果只有一个Master服务器,那么如果它挂了,集群恢复就会有些麻烦。

Master节点管理所有系统的元数据,包括:

  • 名称空间(路径名,以此确定文件)
  • 文件与chunk的映射(一个文件会被分割成多个chunk,每个chunk有一个64位的唯一标识,由于这些chunk分散在不同的机器上,所以需要有一个映射表,这样就能知道这个文件是由哪些chunk组成的)
  • 当前chunk存储在哪个chunk服务器上

同样它还管理一些活动,包括:

  • 周期性地和每个chunk服务器通信,检查它们是否活跃,chunk服务器也会将状态信息报告给Master
  • chunk的租用管理
  • 孤儿chunk的垃圾回收
  • chunk在不同的chunk服务器之间迁移

未完待续

立志成为一名攻城狮
最后更新于 2023-02-19