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 的版本号，用来区分当前的副本和过时副本。