实现了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
网友评论