[分布式系统学习] 6.824 LEC3 GFS 笔记

Google File System

第三课的准备是阅读论文GFS。该论文是分布式系统中经典论文之一。

读完做一点小总结。

GFS的feature

1. 非POXIS接口API，支持对文件和文件夹的创建，读，写，增加，重命名和创建快照操作。

2. 有多个商用Linux机器做节点，称为chunk server，数据存放在chunk server上。

3. 有一个master节点，用于发送控制指令。

4. client通过调用API，和master做控制命令交换，和check server 做数据交换。

5. 对Append操作友好，对小文件随机读写不友好。

6. 重命名和Recore Append是原子操作。

7. 读操作可能返回不一致数据。

GFS的一些实现细节

1. 读写最小单位是所谓的64M大小的chunk。chunk存放在chunk server上。

2. 每个chunk 用64位唯一的handle表示。

3. master节点存放控制信息/chunk位置在内存中，同时持久化operation log用于recover。

4. master节点以一定策略决定chunk 的replacement，保证chunk均匀分布。

5. chunk server在restart的时候发送其本机上chunk信息。

6. chunk server随时可能宕机，master节点通过heartbeat消息报活。

7. 每个chunk有三份拷贝。其中一个称为primary。对chunk数据的更改顺序，统一由primary统筹，然后apply到其他拷贝。

8 每个chunk又分为64KB的block，每个block包含checksum，用于数据完整性检查。

GFS的读操作

1. client 把文件名和要读取的byte位移，通过API，映射成该文件中的chunk 序号。

2. client 发送包含文件名和chunk序号的请求信息给master，master返回chunk handle和所有拷贝所在的位置。

3. client会cache master返回的信息。

4. client发送请求到其中一个拷贝，根据策略，可能是离client较近的一个。

5. 拷贝所在的chunk server根据chunk handle和offset返回数据给client。

6. 接下来的读操作无需master介入，除非cache失效或者文件重新打开。

GFS的写操作

写操作很类似2PC。

1. client 询问master 某chunk的primary 位置，以及其他replica位置。

2. master 返回primary和sencondary replica的位置，图中的A，B和C。client会cache这些信息，除非与primary失联，或者primary告知自己以及失去primary地位。

3. client发送所有要写的数据到A，B和C。这些chunk server会暂存这些数据，直到被下面的步骤用到或者过期。注意这时候写操作依然进行中，并没有生效。

4. 当A，B和C表示暂存完成，client发送正式的写请求给primary，告知暂存完成。primary于是给其收到的所有数据更改赋予一个序列号，然后依次应用到本地拷贝。

5. primary 发送写请求到其他拷贝，并要求按同样序列应用到各自拷贝中。

6. secondary拷贝向primary表示，应用成功。

7. primary向client表示，写完成。

在遇到写错误时，3）-7）可能会多次重试。失败后将重新从1）开始。

写操作是不安全的。如果有多个client同时写同一个地方，该区域将变成“Consistent but undefined”，就是说所有client最终看到同样的结果，但是数据乱了。

但是所谓的“Record Append”是安全的。在Record Append中，client仅仅指明这是一个Append操作，并不指明offset。GFS选择一个offset写入数据，并返回该offset给client。

 

和普通写一样，client把数据推送到所有的拷贝，然后发送写请求给primary。

primary 检查 append是否会使当前chunk超过最大64M限制。如果是，当前chunk pad到最大size，然后告知其他拷贝做同样操作，并回复client，表示操作应在下一个chunk重试。

如果并没有超过64M限制，primary 把数据放入拷贝，并告知其他拷贝，数据要写在“exact the same offset as primary”，也就是说，必须和我primary保持绝对一致的offset。

如果上面任意一步错误，client将重试。这种行为可能造成拷贝之间并不是完全一致。chunk中可能包含record中的一些重复数据。GFS在这里通过重试能保证的是，数据存在所有拷贝中的某些chunk中，有同样的offset，并且只有当所有步骤完成后，primary返回的offset被认为是该Record的“defined start”。这中间可能包含无定义的，不一致信息。

而client在读取的时候，可以通过checksum来判断数据的重复性和一致性。