Google File System阅读笔记

Google File System

Master metadata

1. 文件和chunk的namespace（持久化到log）
2. 文件到chunk的map（持久化到log）
3. chunk副本的位置location

master启动、重启时询问所有chunkserver其chunk位置，当一个chunkserver加入时也如此

replica

所有副本不保证一样，插入时插入到一个相同且确定的offset，但是数据之间可能会有空白，数据块也可能会在同一个文件有多个复制版本

部署选址条件：

1. chunkservers的硬盘空间低于平均
2. 每个chunkserver最近一段时间新建的chunk数量，因为有了写命令才会新建的chunk，而由于是 append-once-read-many workload，新建好后可能有大量的读traffic导致拥塞
   3.副本的部署应该跨机架

副本重新复制

chunkserver挂了，其下所有chunk都需要重新复制副本

副本重新复制选址条件：

1. 距离被复制目标的远近，越近越好
2. 先为活着的文件复制，而不是最近删除过的文件
3. 阻塞client进程的chunk优先级更高

chunkserver限制了花在复制上的带宽

master周期性平衡副本分布：
把副本往硬盘空间更充裕和负载更均衡的地方移动，
在这个过程中，master逐渐地充满新的chunkserver而不是立马塞满，那样会有heavy write traffic

Snapshot

log从最新的snapshot后开始记，新建snapshot后会换个log文件

一致性

内容一致性

consistent：不论副本在哪，所有client都能看到同样的结果。
场景：写过程中被干扰了，内容中包含多个写操作的内容。

defined：consistent 且client会看到全部写的内容。

场景：写过程中没有被干扰。（类似完美单线程情况）

inconsistent：不同的客户端看到不同的数据
场景：写失败

区分defined区域

写分为两种：

1. write：在应用指定的offset写。GFS不用这种写
2. record append：原子性的，至少写入一次的，在GFS选择的offset追加。offset会返回给client，标志着记录的开始位置（defined区域）。offset之前可能有padding或记录的多份复制

副本的一致性保证

1. 对所有的副本以相同的顺序操作
2. chunk版本号

由于client缓存了chunk的位置，它可能从过时的副本处读数据。
限制办法：

1. 通过缓存失效时间限制
2. 下次打开文件时，更新缓存此文件所有chunk信息
3. 过期的副本经常会回复一个premature end of chunk，而不是过期的数据（过期机制保证）。当client重试并与master通信后，他会得到所有chunk位置

lease

用于同步副本的一致性，包含版本号，新选primary时才升级版本号，但是会等前一个lease 60s超时。但是只要chunk正在被mutation，primary可以向master无限申请续租。续租申请附在HeartBeat上。

有时master会在lease超时之前撤销lease，例如master想禁用对某个正被重命名文件的mutation

用lease指定primary，primary决定一系列mutation的顺序，所有secondary副本按此顺序执行mutation

写流程

3. chunkserver收到client数据后，把他存到LRU buffer中
4. 一旦所有的replica都ACK收到了数据，client给primary发送写请求，请求中包含了这批数据的标识符（如id）。primary给收到的mutation用连续的序列号编号，其中可能有多个client的请求。primary按序列号顺序执行请求
5. primary将所有的请求转给secondary，secondary按序列号顺序执行请求
6. 所有的secondary都向primary返回，表示操作成功
7. primary给client回应。若中途有任何错误，则操作失败，变更过的区域处于inconsistent。client会重试失败的操作

如果一个写操作超过了chunk的边界，GFS会将其分为多个写操作

数据传输TCP以流水线的方式

耗时：

$B/T + RL$

B —— 文件含B字节；R —— R个副本；T —— 网络吞吐量；L —— 两机器间的传输延迟；

Namespace Management and Locking

通过namespace锁保证对namespace的操作都是原子性的

namespace表

key:全量路径 value:元数据
 

路径锁

处理 /d1/d2/.../dn/leaf
读锁：/d1，/d1/d2, /d1/d2/.../dn
写锁：/d1/d2/.../dn/leaf

顺序拿锁来避免死锁:
they are first ordered by level in the
namespace tree and lexicographically within the same level

垃圾回收

文件删除时，master日志里立即记删除操作，然后将文件重命名为包含删除时间戳的隐藏名。

当master周期性扫描namespace时，再将超过三天（参数可调）的这种隐藏文件删除，并删除其在master内存中的元数据。在此之前，这些文件可以被通过重命名还原。

通过chunk中类似的常规扫描namespace，master能判别出orphaned chunks并删除这些chunk在master内存中的元数据。

master中有保存 file-chunk 映射的表。chunk replicas在chunkserver的特定的文件夹中。其他未知的文件都被master认为是垃圾。

不立即删除的好处：

1. 简单可信赖
2. 把回收放在master常规批处理后台程序中，cost被分摊掉了。只会当master相对空闲时跑批
3. 拖延删除更安全，相对于立即的、不可恢复的删除

过时副本检测

master维护了chunk版本号

如果master看到了一个更大的版本号，当赋lease时此chunk被认为过时的并更新版本

master把过时副本在常规垃圾回收中删除

client和chunkserver在操作时会验证版本号

容错

高可用

快速恢复

master和chunkserver挂了后会在秒级时间恢复，不区分正常和非正常关闭

chunk副本数

默认是3，参数可调

master备份

log

master的log和检查点在多个机器上备份。

对client请求的response只会在log刷盘（包括本地和远端副本）后发出

master会把几条log记录一同刷盘来增加吞吐量

检查点

master通过重做最近检查点后的log来从故障中恢复，恢复时会跳过未完成创建的检查点

当log超过一个指定大小时，master会创造检查点

检查点是一种紧凑的B树形式，可以直接映射到内存中，用于namespace查找，而无需额外的解析

创建检查点的过程中不会delay请求，在另一个线程中做

master挂了

如果机器或硬盘挂了，GFS外的基础设施会用备份的log开一个新的master进程。由于client只是用的master的名字，所以只需改DNS即可打到另一台机器

当master挂了时，假master只会提供只读的入口

由于文件具体内容是从chunkserver读入，应用不会发现过时的文件内容。在这段短时间窗口内，可能过时的有文件元数据，如目录内容或访问权限

数据完整性

checksum

每个chunk分成64KB的块，每个块有32bit的checksum，此checksum保存在内存和持久化到log中。checksum的计算结果被加在chunk的末尾。checksum只会增量地被更新，计算最后一个块，追加后再计算新的checksum。就算最后一个块挂了而不知情，新checksum也不会和存储的数据匹配，则下一次读时，此挂掉也会被检查到。

读的时候，chunkserver在回复给client或其他chunkserver之前会校验checksum，以保证错误不会传播出此chunkserver。

若校验失败，chunkserver返回error，并向master报告。master会从其他副本另外复制一份chunk，当复制完成时，master命令此chunkserver删除错误chunk。

如果一个写请求要覆盖原数据，必须校验第一个和最后一个块。

诊断工具

GFS诊断log记录了重要的事件，如新加chunkserver或chunkserver挂了，和所有的RPC请求及回应。此log被异步的写

MEASUREMENTS

读比写多