Google File System(GFS)整理

摘要: 我们设计并实现了 我们设计并实现了 我们设计并实现了 我们设计并实现了 Google GFSGoogle GFS Google GFS Google GFS Google GFSGoogle GFSGoogle GFS文件系统，一个面向大规模数据密集型应用的、可伸缩分布式。 文件系统，一个面向大规模数据密集型应用的、可伸缩分布式。 文件系统，一个面向大规模数据密集型应用的、可伸缩分布式。 文件系统，一个面向大规模数据密集型应用的、可伸缩分布式。 文件系统，一个面向大规模数据密集型应用的、可伸缩分布式。 文件系统，一个面向大规模数据密集型应用的、可伸缩分布式。

1.服务器的各种不稳定性是个问题。

2.文件过小去管理，尺寸是个问题。

3.不断增加的海量数据加内存性能不合适的问题。

4.多客户端并行追加，提供了API和灵活性。

二.设计概述

1.随机大量小规模读取文件，可以把操作做一个排序，然后批量的执行要强于前后的来回移动。多进程并发的读写文件。或消费时读取。很多时候更突出高速率大批量处理数据（吞吐量效率，像火车站人流似的）。

2.结构对多客户端，实现多路结果合并，同时对同个文件追加。文件追加和快照对分布式应用是非常重要的。

三.架构



1.可以为不同的命名空间指定设定不同的设定级别。是一个Master控制管理一堆chunk信息，并探测地址和他们的通信调度等。

2.注意客户端只是从Master获得元数据，所有的数据操作都是由客户端和chunk服务器直接交互的。

3.客户端和chunk都不缓存数据，chunk以本地文件的方式保存，linux的文件系统会把经常访问的数据缓存再内存中。

4.Master单一节点，可以根据名称和偏移量定位文件chunk集合位置，避免客户端和chunk通信时频繁和Master交互。

5.Chunk尺寸，减少网络通信，对同个块多次操作，较大的减少元数据量。问题是某些chunk可能变成热点，比较好的解决方法是把客户端的数据也能作为服务数据提供上传。

二.元数据

1.元数据，chunk空间，关系，在那里，会保存在Master一个变更日志信息，也能传递，但不会永远保存在内存中，有新机器加入时会轮询chunk服务器中他们存储的chunk信息。

2.内存数据结构

chunk信息保存在master中，当发生chunk失效，垃圾收集可以及时的复制数据和收集垃圾，虽然把chunk保存在master的内存中，但是会受到系统承载能力的限制。绝大多数chunk都是满的。master增加有限的费用就能增加更到的chunk容量，提高简洁，高效，灵活。

3.chunk位置信息

master先保存chunk位置信息，然后会不断轮询chunk服务器，心跳检测，还是chunk服务自己最知道自己情况，所以没有在master中维护一个全局的信息。

4.操作日志

只有保证元数据变更历史及记录，而且是在元数据变更持久化之后日志文件被复制到别的机器之后才对客户端所见。而且有B-tree空间的功能和checkpoint功能，checkpoint足够小，恢复的时候也足够快。

5.一致性模型

a.region（一致），region&可以看到写入（已定义），如果是未定义的region，应用程序没必要再去细分。

b.顺序一致性，chunk版本号。

c.master会定时和chunk服务器握手，checksum是否损坏，如果有就会立刻用好的副本进行复制。一般检测窗口时间是几分钟。

6.程序的实现

a.典型的是顺序写入后的追加操作，有一些验证。

b.writers/reader都有一些checksum验证有效性。记录I/O功能包含在程序共享库中，也适用其他文件接口实现。

7.系统交互原则是最小化所有操作和master的操作

a.lease机制会以主chunk接受到的操作序列进行分派的方式，然后将其他二级副本返回的信息传递给client端，判断是操作是否成功，能保证一致性。lease就是master会租用一个primaryReplica作其他副本的代理。



b.数据流主要是线性的管道推送方式，避免拓扑推送时候均衡带宽。

c.原子的记录追加时用到了多生产/单消费的模式，避免竞争。不是每个chunk都有相同的字节，只会保证至少一次原子的事物性。这个原子性能保证region是一致性的。

d.快照，在找租约chunk前有个与master交互的过程就是快照的机会。如果发现有快照指向的chunk,那么再请求写数据时会创建个新的chunk直接写入。

8.master节点的操作，名称空间，如快照操作取消租约，名称空间的region上的锁保证正确顺序，虽然GFS有名称空间绝对路径对应的锁，但不可列出所有文件。暂时先了解文件父目录只有读取锁，可以防止被修改。锁是惰性所，在一个层级有排序，委会一个全局的一致性。

9.副本的位置，除了防丢失，主要还有考虑带宽的利用率。

a.创建chunk时，首先选择低磁盘利用率。

b.希望限制最近chunk操作的次数。

c.复制chunk有游下级别，如丢失的多的，活跃高的，影响流程的 。

d.复制时也会均衡网络间带宽，机架，原chunk操作次数等的限制。

e.最后master还会逐步的根据带宽利用率和复制因子平衡磁盘的使用情况。

10.副本的删除，是会标记一个隐藏的删除时间戳，等待master扫描时进行判断，同步元数据。master和chunk心跳检测时，判断哪些chunk已经不再元数据中，chunk就可以统一执行删除。

不同的目录可以设定文件的删除策略。过期失效的副本检测会用版本号的方式判断那些是有效并保证一致性。

11.容错和诊断，硬盘网络机器的故障不可避免，如何处理？2个策略，快速回复和复制。

a.快速恢复，毫秒级回复机器状态。

b.chunk,复制因子保证chunk数量和验证和链路层网络层不相关错误验证，因为系统主要是只读和追加操作。

c.master操作保存到本机地址和备份节点，如果master失效，几乎可以立刻恢复机器状态，客户端甚至可以指向又GFS外部新启动的master进程。

d.master有个影子服务器，功能和master主服务器类似，提供状态变更小的或不敏感状态变化信息的chunk读取操作。定期通过master副本log保持状态，只有更新操作时会和master通信更新自己的状态。

12.数据完整性

a.因为磁盘可能坏道等原因可能导致数据保存了未必正确或有可能丢失，如何检查正确性，跨区是不实际的，每个chunk都在内存和硬盘维护一个自己的checksum和日志信息。

b.读取操作前，会在要读取的范围内检查checksum，如果有错误会通知请求端和master端，请求端会从别的chunk请求数据，master会负责修复损坏的副本，就绪后会删除副本。同时checksum是很有效率的，是很小的一部分，同时不需要I/O操作。checksum更新只同步最后增加的那个块信息是频率较高的操作。

c.写前会检查起始块和最后一块，如果不检测，那么新写入的checksum可能会覆盖之前损坏的数据。

d.checksum会在chunk服务器空闲的时候检测那些chunk是否损坏，提早通知master修复或避免欺骗master副本数量。

13.诊断工具

a.日志的记录是有必要的，它带来的好处远大于系统的消耗，近期的信息放在内存中可以提供持续不断在线的监控行为。

三.度量

1.理想的读取测试时，当多个客户同时读取同一个chunk服务器的几率增加时，可能导致整体读取效率的下降。

2.写入的时候由于网络协议栈和管道的方式不相适应，加上可能多个客户机对同个chunk进行写入，导致写入的延迟和降低。

3.记录追加受限于最后一个chunk服务器的带宽。

四.实际中的集群

1.存储的文件多chunk数量就比较多。

2.元数据会保存在master和chunk服务器上，所以恢复速度都比较快，只用数秒时间就可读取，master的元数据不会成为GFS的瓶颈。

3.读写速率，读是频繁且有效率的。这也是有效利用资源的一种方式。

4.master负载一般都可以200-500以上，结构用二分法优化后速率达到每秒数千次。

5.可以在服务器失效时快速的恢复副本。据测试的环境看速度在450m/s的速度。

五.工作符合分析

1.我们可以把一个操作分成几个详细的RPC请求，通过分析日志判断和分析集群运行情况。

2.有些涉及到的小文件的读取，因为随机seek也会导致工作的负荷。

3.追加的操作一般要大于写的操作。

4.集群的工作负荷主要还是findlocation,然后是release等。

六.经验

1.GFS生产系统是严格受控的，有一些架构来防止用户间干扰，也是渐渐完善的过程。还有一点是由于linux内核和硬盘驱动的问题可能导致数据被破坏，所以用checksum来检查可能协议不匹配的问题。

2.可能有文件所主网络线程的情况，linux开源的好处就是比较好的理解和探索系统行为，甚至可以联合解决。

七.相关工作

1.与位置无关的命名空间，复制方式，流式读取或seek少量读取，master集群管控方式的简洁以及master状态保存的灾难冗余。

八.结束语

1.持续监控 复制关键数据 快速自动恢复 控制流和数据流分离 大量并发读写操作提供高吞吐量。

2.分布式操作日志，全局均衡等。