Google File System

实现了1k多台的机器提供数百TB的存储文件服务器

设计原则

• 组件失效是正常现象。由于程序的bug、人为失误、磁盘、内存、网络或者电力供应引起的问题。一次持续检测、错误检测、容错核自动恢复必须集成到系统中
• 文件是巨大的。大小为数G的文件很普遍。
• 文件的修改方式是追加而不是重写。数据一旦被写入，则仅供读取。随机写遇到并发会产生数据不一致现象，带来设计的复杂度会相当高。
• 松弛的一致性。允许副本出现内容不一致的现象。这样可以让系统更容易设计和实现

API

• create
• delete
• open
• close
• read
• write
• snapshot
• append

架构

gfs-ar

GFS集群由一个master和多个chunkserver组成

每个文件分成固定大小的chunk块，每个快由一个全局唯一的64bit的句柄（由master在块创建的时候赋予），每个块会有若干个副本。

maste（single master）r维护文件系统的元数据。包括命名空间、访问控制信息、文件到块的映射、块的当前位置。它还控制系统的活动，例如块租约管理（块master）、垃圾回收、块迁移、心跳检测

客户端只询问master文件的信息，后续的所有操作都只跟chunckserver有关

块的信息不会在chunkserver缓存，因为文件太大，无法缓存。

块大小

为64M。

块热点

通过增加块副本来解决

元数据

所有关于元数据的操作，都会记录在日志里面，日志通过复制到远端的机器，以便master崩溃后，不会出现不一致的风险。块位置的信息不会保存持久化，而会通过由chunkserver来上传这些信息到master

一致性

客户端的每个写操作，都必须等所有副本都写成功后，才会正确返回；如果都正确写入，那么数据是一致的。

如果副本写入失败，那么块master和部分副本写入成功，这时客户端会收到写入失败。此时客户端会重新发起写入请求。由于数据不回滚，这就导致了master块和部分副本存在重复数据，而失败的副本在写入成功后，数据会跟其他块不一致。

因此数据保证了至少写入成功一次。

客户端需要进行排重处理。

gfs-write

数据流写入

相对于上面的写入，例如有S1，S2，S3三个server。

可以通过S1->S2->S3这样的数据流传递写数据

Master操作

• 副本放置

  目标：最大化数据的可靠和可用性；最大化网络带宽利用率

  考虑磁盘、不同机架、网络带宽

• 创建

  考虑利用率低的chunkserver

• 再复制

  chunkserver变得不可用

  副本已损坏

  复制目标增加

• 再平衡

  master会周期的进行副本再平衡

• 垃圾回收

  文件被删除后，master会改变元数据，但文件没有马上被回收

  master会周期的检测孤儿块，然后由chunkserver自由删除

• 过期副本检测

  chunkserver如果失效或者宕机错过了块变更，块副本会变过期，对于每个块，都会记录一个版本号。master通过对比块版本，发现过期副本会进行丢弃

容错

• 高可用

  • 快速恢复

    master和chunkserver被设计成可以再几秒重启恢复状态。客户端发现请求异常，可以通过重新请求来恢复业务

  • 块复制

    每个块由校验字段。

• master复制

  master可以快速重启。

  通过操作日志，可以在新的server快速启动一个新的master