GFS读后笔记
Q&A
ANS: 可能取得某些平衡点
- Chunk的大小为何选择64MB?这个选择主要基于哪些考虑?
ANS:
- GFS主要支持append,overwrite操作比较少。为什么这样设计?如何基于一个只支持Append操作的文件系统构建分布式表格系统Bigtable?
GFS主要是为了追加(Append)而不是改写(Overwrite)而设计的。一方面是因为是改写的需求比较少,或者可以通过追加来实现,比如可以只使用GFS的追加功能构建分布式表格系统Bigtable;另一方面是因为追加的一致性模型相比改写要更加简单有效。考虑Chunk A的三个副本A1,A2,A3,有一个改写操作修改了A1,A2但没有修改A3,这样,落到副本A3的读操作可能读到不正确的数据;相应地,如果有一个追加操作往A1,A2上追加了一个记录但是追加A3失败,那么即使读操作落到副本A3也只是读到过期而不是不正确的数据。
- 为什么要将数据流和控制流分开?如果不分开,如何实现Append流程?
主要是为了优化数据传输,每一台机器都是把数据发送给网络拓扑上”最近“的尚未收到数据的机器。
如果不分开,可以像传统的主备复制的方法。
- GFS有时会出现重复记录或者padding,为什么?
如果记录追加操作在任何一个副本上失败了, 客户端就需要重新进行操作。重新进行记录追加的结果是,同一个Chunk的不同副本可能包含不同的数据–重复包含一个记录全部或者部分的数据。GFS并不保证Chunk的所有副本在字节级别是完全一致的。它只保证数据作为一个整体原子的被至少写入一次。
- Lease是什么?在GFS起什么作用?它与heartbeat有何区别?
使用lease机制来保持多个副本间变更顺序的一致性。目的是为了最小化Master节点的管理负担。首先由Master决定一个主chunk,主chunk对其他的Chunk的所有更改操作进行序列化。HB是定时发送的,而Lease是用于变更时。客户机把数据推送到所有的副本上。客户机可以以任意的顺序推送数据。当所有的副本都确认接收到了数据,客户机发送写请求到主Chunk服务器。这个请求标识了早前推送到所有副本的数据。主 Chunk为接收到的所有操作分配连续的序列号,这些操作可能来自不同的客户机,序列号保证了操作顺序执行。
- GFS append过程中如果Secondary出现故障,如何处理?如果Primary出现故障,如何处理?
客户端的请求被确定为失败,被修改的region处理不一致的状态,client通过重试执行失败的操作来处理这样的操作。如果primary挂了,操作不会被分配序列号,不能被传递。
- GFS Master需要存储哪些信息?Master数据结构如何设计?
MASTER上保存了三种元数据信息:
1)命名空间NameSpace,也就是整个文件系统的目录结构及Chunk基本信息;2)文件到CHUNK之间的映射;3)CHUNK副本的位置信息。
持久化前两种元数据的映射。CHUNK数据由SERVER启动时上报给MASTER.
- 假设服务一千万个文件,每个文件1GB,Master中存储的元数据大概占用多少内存?
管理每个64MB的CHUNK服务器不到64byte。
- Master如何实现高可用性?负载的影响因素有哪些?如何计算一台机器的load值?
快速恢复和复制。
负载的影响因素包括:网络拓扑、机器分布、磁盘利用率等。
load值:
- Master新建chunk时如何选择ChunkServer?如果新机器上线,load值特别低,是否需要有些特殊考虑?
系统中有三种需要创建chunk副本的情况:chunk创建,chunk重新复制(re-replication)以及重新平衡(rebalancing)。
当Master创建了一个chunk,它会根据如下因素来选择chunk副本的初始位置:(1) 新副本所在的Chunk Server的磁盘利用率低于平均水平;(2) 限制每个Chunk Server”最近”创建的数量。(3)每个chunk的所有副本不能在同一个机架。
第二点容易忽略但却很重要,因为创建完chunk以后通常需要马上写入数据,如果不限制”最近”创建的数量,当一台空的Chunk Server上线时,由于磁盘利用率低,可能导致大量的chunk瞬间迁移到这台机器从而将它压垮。
- 如果某台ChunkServer报废,GFS如何处理?
RE-BALANCE。当有 Chunk服务器离线了,或者通过 Chksum 校验(参考5.2节)发现了已经损坏的数据,Master节点通过克隆已有的副本保证每个 Chunk 都被完整复制 。
- 如果ChunkServer下线后过一会重新上线,GFS如何处理?
Master节点在这个Chunk服务器重新启动,并且向 Master 节点报告它拥有的 Chunk 的集合以及相应的版本号的时候,就会检测出它包含过期的Chunk。如果 Master 节点看到一个比它记录的版本号更高的版本号,Master 节点会认为它和Chunk服务器签订租约的操作失败了,因此会选择更高的版本号作为当前的版本号。
增加引用,写时拷贝。
64MB的CHUNK,尽可能均匀地分布在不同的磁盘之中。
- 磁盘可能出现“位翻转”错误,ChunkServer如何应对?
Chunk Server会对存储的数据维持校验和。GFS以64MB为Chunk大小来划分文件,每一个Chunk又以Block为单位进行划分,大小为64KB,每一个Block对应一个32位的校验和。当读取一个Chunk副本时,Chunk Server会将读取的数据和校验和进行比较,如果不匹配,就会返回错误,客户端将选择其它Chunk Server上的副本。
- ChunkServer重启后可能有一些过期的chunk,Master如何能够发现?
当 Chunk 服务器失效时,Chunk 的副本有可能因错失了一些修改操作而过期失效。Master 节点保存了每个 Chunk 的版本号,用来区分当前的副本和过期副本。