gfs杂谈

 

0 构建过程：

 

组件失效是一种常态：

应用程序bug  操作系统Bug  人为失误  硬盘 内存 连接器  网络  电源失效等造成的问题

因此需要持续监控， 错误侦测，灾难冗余，自动恢复的机制，

这样就是GFS慢慢构建成骨架的过程。

 

基于数亿个对象和TB级别数据量， 管理已KB为单位的文件显然不明智， IO和Block尺寸都需要重新考虑。

 

真实生活中，对文件随机写入操作几乎不存在，一旦写完，对文件的操作就只有读，通常都是顺序读，

大量的数据都符合上述规律， 对于海量文件的访问模式，客户端对数据的缓存没有意义，因为大部分程序要么以流的方式读取一个巨大文件, 要么工作集太大根本无法被缓存(无需考虑缓存相关的问题也简化了客户端和整个系统的设计和实现)

数据的追加操作是性能优化和原子性保证主要考量因素。

 

 

2 设计概述

 

2.1 设计预期

 

系统工作负载主要由两种读写操作组成： 大规模流式读写a和小规模随机读写b，

 

a方式通常一次读取1M甚至更多数据，来自同一客户机的连续操作通常读取同一文件中连续的一个区域，

b方式通常是在某个文件某个随机位置读取几个KB数据，如果应用程序对性能关注，通常将小规模随机读取

操作合并并排序，之后按顺序批量读取，这样避免了文件中前后来回移动读取位置。---？？？ 怎么实践

 

 

文件通常被用于 生产者--消费者队列，通常有数百个生产者，每个生产者进程运行在一台机器上，

同时对一个文件进行追加操作，实现最小的同步开销来实现原子的多路追加数据操作是必不可少的，

 

 

 

高性能的稳定网络带宽远比低延迟重要。

 

 

GFS API接口提供了 API接口函数， 快照  和 记录追加操作，

快照---> 以很低的成本创建一个文件或者目录树拷贝

记录追加---> 允许多个客户端同时对一个文件进行数据追加操作并保证每个操作都是原子性。

记录追加在生产者消费者队列以及多路结果合并中，多个客户端可以在不需要额外同步锁定情况下对同一个文件进行追加数据。 这点对于构建大型分布式应用非常重要。

 

 

2.3 架构

 

GFS存储的文件被分割成固定大小的Chunk(块)，Chunk创建的时候会被分配全球唯一的64位Chunk标识，

 

Master节点管理文件系统元数据， 包括(文件和Chunk的对应关系，每个Chunk副本存放地点，名字空间, 访问控制权限，文件 ， Chunk映射信息 ， Chunk位置)

Master接管管理系统范围内的活动 包括(Chunk租用管理，孤儿Chunk回收，Chunk服务器之间的迁移，Master心跳周期和每个Chunk服务器通讯)

 

2.4 单一Master节点：

单一Master节点策略大大简化了系统设计，可以通过全局信息精准定位Chunk的位置以及进行复制决策，

 

简单解释下读取流程：

客户端把文件名和程序指定的字节偏移，根据固定Chunk大小，转换成文件Chunk索引，然后将文件名和Chunk索引发送给Master节点，Master节点将相应得Chunk标识和副本位置信息发送给客户端，

客户端用文件名和Chunk索引作为key来缓存这些信息。

然后客户端发送请求到其中一个副本处，请求信息包含chunk标识和字节范围，在后续的对这个Chunk读写

操作中，客户端不在和Master节点通讯，除非客户端缓存的元数据信息过期或者文件被重新打开.

 

真实应用中，客户端通常在一次请求中查询多个Chunk信息，Master回应也会包含紧跟着这些请求Chunk后面的多个Chunk信息。

 

2.5 Chunk尺寸：

 选择64M这个尺寸有几个重要优点：

1 减少和Master节点通讯需求，一次获取足够多的数据范围对降低工作负载来说效果明显。

2 客户端可以轻松缓存1TB工作数据集所有的Chunk位置信息

3 较大的Chunk尺寸客户端可以对一个块进行多次操作，这样能和Chunk服务器保持较长的TCP连接，从而减少网络负载

4 较大的Chunk尺寸减少Master节点需要保存元数据的数量，从而能够保证将元数据全部放在内存中

 

2.6 元数据

 元数据中存储的 文件和Chunk的命令空间， 文件和Chunk的对应关系，每个Chunk副本的存放地点，

前两种也会通过记录变更日志方式保存到系统日志文件中，保存后日志也会被恢复到其他远程Master服务器上，这种日志方式能够简答可靠更新Master服务器状态，并且也不会导致Master服务器崩溃导致的数据不一致风险。

 

附带说明： 虽然元数据都会在Master服务器内存中存放，但是Master服务器不会持久保存Chunk位置信息，

Master服务器在启动时，或者在新的Chunk服务器加入时，会向各个Chunk服务器轮询Chunk信息。

 

 

2.6.1 内存中的数据结构：

基于内存的Master服务器能够简单高效周期性扫描自己保存的全部状态信息，同时也会周期性扫描和实现

Chunk垃圾收集，在Chunk服务器失效时重新复制数据，通过Chunk迁移实现跨Chunk服务器负载均衡以及磁盘使用情况统计。

 

基于内存的Master虽然会有内存受限问题，但是实际应用中，这并不是一个非常严重的问题，

Master服务器只需要不到64字节的元数据就能管理一个64M的Chunk,并且保存的文件名是用前缀压缩算法压缩过的。

即使需要支持更大的文件系统，为Master服务器增加额外内存的费用是很小的，通过增加有效费用，就能把元数据全部保存在内存中，增强了系统简洁性，可靠性，高速度处理和灵活性也是更划算的事情。

 

2.6.2 Chunk位置：

Master服务器并不持久化保存哪个Chunk服务器存有指定Chunk副本信息，会在启动的时候轮询Chunk服务器以获取这些信息，并定期轮询以获取更新，这种方式向比较将Chunk位置信息持久保存在Master服务器上更简单，这种设计简化Chunk服务器加入集群，离开，更名，失效，重启下和Master服务器数据同步的问题，并且真实场景中，比如在拥有数百台服务器集群中这种事件经常发生。

 

并且只有Chunk服务器才知道自己的Chunk信息。相对于Master服务器去拉的方式，用Chunk服务器的推方式更好。

 

 

2.6.3 操作日志：

 

 操作日志是元数据唯一的持久化存储记录，同时也作为判断同步操作顺序的逻辑事件基线

文件和Chunk, 以及它们的版本，都由它们创建的逻辑时间唯一永久标识。

 

我们必须保证操作日志完整性，元数据变化被持久化后，并且日志复制到多台远程机器后，才会响应客户端

的操作请求，Master服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近状态，

 为了缩短Master机器启动时间，我们必须使日志足够小，Master服务器在日志增长到一定量时会对系统做一次CheckPoint,将所有状态数据写入到一个Checkpoint文件， 在灾难恢复时，Master服务器会从磁盘读取这个Checkpoint文件并重演Checkpoint之后的有限个日志文件就能够恢复系统。

Checkpoint文件以B-树的数据结构存储，可以直接映射到内存中，并且在用于命名空间查询时候无需额外解析，这样大大提高了恢复速度，增强可用性。

 

基于创建一个Checkpoint文件需要一定时间，

Master服务器内部被组织为一种格式，此格式能确保Checkpoint过程中不会阻塞正在进行的修改操作，

Master服务器会使用独立线程切换到新的日志文件和创建新的Checkpoint文件，新的Checkpoint文件会

包含切换前所有的修改， 对于一个包含数百万个文件的集群，创建一个checkpoint文件需要1分钟左右时间

 

Master服务器恢复的时候仅需最新的Checkpoint文件和后续的日志文件，旧的checkpoint文件和日志文件可以被删除，当然真实中通常多保留一些历史文件。

 

2.7 一致性模型   (应该是说备份下的数据一致性吧)

 

2.7.1 GFS一致性保障机制：

 

GFS支持一个宽松的一致性模型，此模型能很好支撑我们高度分布的应用，

同时还保存了相对简单并容易实现的优点。

 

数据修改操作分为写入或者追加两种类型，写入操作把数据写在应用程序指定的文件偏移位置上，

即使有多个修改操作并行执行时，记录追加操作至少可以把数据原子性的追加到文件中一次，

偏移位置是由GFS决定的，GFS返回给客户端的偏移量会表示包含了写入记录，已定义region的起点。

 

由于chunk位置信息会被客户端缓存，所以在信息刷新前，客户端可能从一个失效的副本读取了数据，

即在缓存的超时时间和文件下一次被打开的时间之间存在一个时间窗，

文件再次被打开后会清除缓存中与该文件有关的所有Chunk位置信息，

即使在这个时间窗中读取到了失效副本的数据，因为我们的文件大部分都是只进行追加操作，因此

一个失效的副本返回的数据只能是上一次的数据而不是最新数据。

当一个新的reader重新连接master服务器时，会得到最新的chunk信息。

 

Master服务器和Chunk服务器通过定期握手来找到失效chunk服务器，使用checkSum来校验是否损坏。

Master节点检测到错误并采取对应措施的反应时间一般是几分钟。

 

 

 

2.7.2 程序的实现

 

采用追加写入而不是覆盖，

Checkpoint,

自验证的写入操作

自标识记录

 

真实应用中，应用程序从头到尾写入数据生成文件，写入数据后，应用程序自动将文件改名为一个永久保存

的文件名，或者周期性做checkpoint,记录成功写入多少记录。

Readers仅校验并处理上个checkpoint之后产生的文件region. 这种方式满足了我们一致性和并发处理的要求，Writers在每条写入的记录中都包含了额外的信息，比如checksum,用来校验有效性，

Readers可以利用checksum识别和抛弃额外的填充数据和记录片段。(没读懂)

 

 

 

3 系统交互

重要原则:  最小化所有操作和Master节点的交互。

 

3.1 租约和变更顺序(就是写入数据同时保证副本也能同步得到数据的过程)

变更: 1 改变chunk内容(原文件增加内容)  2 改变元数据(增加新文件) 

租约: 用于保持变更后所有chunk都能达到一致的规范

 

Master节点为Chunk的一个副本建立一个租约，这个副本叫做主Chunk,

主Chunk对Chunk的所有操作都进行序列化，所有副本都遵从这个序列进行修改操作以达成和主Chunk的一致，这个过程中， Master节点会选择好主Chunk，然后主Chunk分配序列号 最终形成了修改操作的全局顺序

 

设计租约机制是为了最小化Master节点的管理负担，

 

客户机向Master节点询问哪个Chunk服务器持有当前租约，以及副本位置，如果没有, Master节点会选择其中一个副本建立一个租约。

 

Master节点将主Chunk表示符以及副本Chunk(secondary副本)位置返回给客户机，客户机缓存这些数据，

此时客户机将不再和Master节点关联， 只有在主Chunk不可用或者主Chunk回复信息表明不再持有租约时，

客户机才会和Master节点联系。

 

客户机将数据推送到所有副本，可以是任意顺序推送，Chunk服务器接收到数据并保存到内部的LRU缓存中

直到数据被使用或者过期交换出去。

 

当所有副本都确认接收到数据，客户机才发送写请求到主Chunk服务器， 主Chunk为接收到所有操作分配

连续序列号，这些操作可能来自不同客户机，而序列号保证了操作的顺序执行，主Chunk把写请求传递到所有二级Chunk中，每个二级Chunk依照分配的序列号以相同顺序执行操作。

 

所有二级Chunk回复主Chunk已经完成操作

 

主Chunk服务器回复客户机， 任何副本Chunk产生的错误都会返回给客户机，如果是主Chunk出现错误，

操作不会再被分配序列号也不会再被传递， 如果是二级Chunk出现错误， 客户机代码会重复执上图中3-7步骤做几次尝试。

 

3.2 数据流( 数据推送链-管道方式 最小化网络延迟)

 

为了提高网络效率，系统设计将数据流和控制流分开。

 

控制流从客户机发起，到主Chunk服务器，然后在到所有二级Chunk服务器，数据已管道方式顺序沿着

一个精心选择的Chunk服务器链推送。 这个精心选择的链主要是为了达到 充分利用每台机器的带宽，

避免网络瓶颈，高延迟的连接的目的。

 

继续说说这个推送链：  数据是以一个Chunk服务器链推送，而不是其他拓扑形式分散推送(比如树状拓扑)，线性推送模式下，每台机器所有出口带宽都用于以最快速度传送数据，而不是在多个接受者之间分配带宽。

 

在线性推送下，每台机器都会尽量在拓扑结构中选择一台还没接收数据并离自己最近的机器作为目标了来推送数据，而计算就是通过IP地址就可以计算出节点之间的距离。

 

最后总结:  管道方式推送中，2我们基于全双工交换网络，接收到数据后立即向前推送不会降低接收速度，

在没有网络阻塞情况下，传送B字节数据到R个副本理想时间是 B/T + RL 

T是网络吞吐量， L是两台机器数据传输延迟 比如 T(网络连接速度)=100Mbps,  L 远小于1ms

那么 1MB数据理想情况下 80ms就能分发出去。

 

3.3 原子的记录追加

 

记录追加在分布式应用中非常频繁，在这些分布式应用中，通常会有很多客户机并行对同一个文件追加写入操作，如果追加文件超过Chunk最大尺寸，主Chunk首先将当前Chunk填充到最大尺寸，之后通知所有二级副本做同样操作，然后回复客户机要求对下一个Chunk重新进行记录最佳操作。

 

GFS并不保证Chunk所有副本在字节级别上完全一致，它只保证数据作为一个整体原子的至少写入一次，

操作成功的话，数据一定是写入到Chunk所有副本的相同偏移位置上，这之后，所有副本至少都到了记录尾部的长度，任何后续的记录都会追加到更大的偏移地址，或者不同的Chunk上。

 

 

3.4 快照

快照的目的:  1  瞬间完成对一个文件/目录树的拷贝 2 不会对正在进行的其他操作造成任何干扰

                      3 轻松的提交或者回滚到备份的状态

 

 

4 Master节点的操作

 

 1) 执行所有名字空间操作

 2) 管理着整个系统中所有Chunk副本

 3) 决定Chunk存储位置(创建新的Chunk和副本)

 4)  协调各种系统活动以保证Chunk被完全复制

 5) 在所有Chunk服务器之间进行负载均衡 

 6) 回收不再使用的存储空间

 

4.1 名字空间管理和锁

 

Master节点很多操作都会花费很长时间， 比如快照操作必须取消Chunk服务器上快照所涉及的所有Chunk租约，我们不希望在这些操作运行时，延缓了其他Master节点操作，因此我们允许多个操作同时进行，并使用名字空间的region上的锁来保证执行的正确顺序。

 

 

逻辑上，GFS的名字空间是一个全路径和元数据映射关系查找表，这个表使用前缀压缩被高效存储在内存中，在存储名字空间的树形结构上，每个节点(绝对路径的文件名或绝对路径的目录名)都有一个关联的读写锁。

 

每个Master节点的操作在开始之前都要获取一系列锁，比如操作涉及文件/文件夹为:

/d1/d2/.../dn/leaf, 那么首先要获取/d1/d2/.../dn的读锁，以及/d1/d2/.../dn的读写锁。

 

以将/home/user 被快照到 /save/user的案例来说锁的处理:

快照操作获取 /home  /save的读取锁， 以及 /home/user 和  /save/user写入锁，

文件创建操作获取 /home读取锁和 /home/user 的读取锁， 以及 /home/user/foo的写入锁，这些操作要顺序执行，因为获取 /home/user的锁是互相冲突，而文件名的读取锁足以防止父目录被删除。

 

采用这种锁方案优点可以支持对同一目录的并行操作，目录上的读取锁是为了防止目录被删除，改名，快照

，文件名的写入锁序列化文件创建操作，确保不会多次创建同名的文件。

 

基于名称空间可能有很多节点，读写锁采用惰性分配策略， 即不再使用时立即删除，

并且锁的获取会依照一个全局一致的顺序来避免死锁，

这个顺序是： 先按照名字空间层次排序，在同一层次内按字典顺序排序。

 

 

4.2 副本的位置

 

 GFA集群是高度分布的多层布局结构，而不是平面结构， Chunk服务器被来自同一或者不同机架上的数百个

客户机轮流访问，不同机架上的两台机器间的通讯可能跨越一个或者多个网络交换机，并且机架的出入带宽

可能比机架内所有机器加在一起的带宽要小。 多层布局机架对数据灵活性，可靠性，和可用性提出特有挑战

 

Chunk副本位置选择策略两个目标: 1)最大化数据可靠性和可用性  2) 最大化网络带宽利用率

我们必须在多个机架之间分别存储Chunk副本，以保证一些副本在整个机架被破坏或者掉线(电源或网络交换机造成的问题)下依然能够可用，  这是第一个优点， 第二个： 在Chunk读操作中，能够有效利用多个机架的整合带宽，当然，多机架下写操作必须和多个机架设备进行网络通讯，但是这个代价相对于更频繁的多来说，是我们愿意付出的。

 

 

4.3 创建 重新复制 重新负载均衡

 

 

chunk副本的三个用途: Chunk创建  重新复制  重新负载均衡

Master节点创建Chunk时会考虑如下：

1) 在低于平均硬盘使用率的Chunk服务器上存储新的副本，这样能平衡Chunk服务器之间的硬盘使用率

Chunk只有在Writer真正写入数据的时候才被创建，一旦写入成功后会变成只读的。

 

Master会周期性对副本进行重新负载均衡，检测当前副本分布情况，以一定优先级(比如副本确实2个的优先级就要比确实1个的高)移动或者复制副本，以便更好利用磁盘空间，更有效进行负载均衡，同时Master节点

必须选择哪个副本要被移走，通常情况会移走那些剩余空间低于平均值的Chunk服务器副本，从而平衡系统整体的磁盘使用率。

 

 

4.4 垃圾回收

 

GFS在文件删除后不会立即回收可用的物理空间，GFS空间回收采用惰性策略，只在文件和Chunk级的

常规垃圾收集时进行。

 

 

4.4.1 机制

 

 文件被删除时，Master节点立即把删除操作以日志方式记录下来，然后Master节点会把文件改名为一个包含

删除时间戳，隐藏的名字，当Master节点对文件系统命令空间常规扫描时，她会删除三天前的隐藏文件，(这个时间戳是可以设置的)，而还没有删除的隐藏文件可以通过新的特殊名字读取或者将隐藏文件改名为正常显示的文件名的方式来反删除。

当隐藏文件从名称空间删除，Master内存保存此文件的元数据才会被删除。

而Chunk副本的删除流程是：  对Chunk名字空间做常规扫描时，Master节点找到孤儿Chunk(不被任何文件包含的Chunk) 并删除它们的元数据，Chunk服务器在和Master心跳中，报告Chunk服务器所拥有的Chunk子集信息，Master节点回复Chunk节点哪些Chunk在Master节点中不存在，然后Chunk服务器可以任意删除这些Chunk的副本。

 

 

4.4.2 讨论(垃圾回收)

 

分布式垃圾回收需要一个复杂方案才能解决，但是在GFS系统中非常简单。

Chunk的所有引用都存储在Master服务器内存的文件到块的映射表中，

我们也可以轻易找到所有Chunk副本，他们都以linux形式存在Chunk服务器指定目录下，

所有Master节点不能识别的副本都是垃圾。

 

垃圾回收把存储空间的回收操作合并到Master节点规律性的后台活动中，比如例行扫描和Chunk服务器握手，因此操作被批量执行，开销会被分散。

并且，垃圾回收在Master节点相对空闲时候完成，这样Master节点就可以给那些需要快速反应的客户机提供更快捷的响应。

 

同时也延缓了 意外的，不可逆转的删除操作。

 

当然延迟回收空间的问题有：

阻碍用户调优存储空间的使用，尤其是存储空间紧缺时，

当然可以通过显示的再次删除一个已经被删除的文件的方案来加速空间回收的速度。

也允许用户为命名空间的不同部分设定不同的复制和回收策略， 比如用户可以指定某些目录下的文件不做复制，删除时被即时的不可恢复的从文件系统中移除。

 

 

4.5 过期失效的副本检测

 

当Chunk服务器失效时,Chunk的副本有可能因为错失了一些修改操作而过期失效，Master保存了每个Chunk的版本号，用来区分当前的副本和过期副本。

 

只要Master节点和Chunk签订一个新的租约,它就会增加Chunk的版本号，然后通知最新的副本，Master节点和这些副本都把版本号记录在他们持久化存储的信息中，  如果某个副本所在的Chunk服务器正好失效状态，副本的版本号不会增加，Master节点在这个Chunk服务器重启后，Chunk服务器向Master服务器报告所拥有的Chunk集合以及相应版本号时，Master节点会检测出过期的Chunk, 此时Master节点在检测别的Chunk服务器发现对应Chunk有更高版本时，Master节点会认为它和Chunk服务器签订租约失效了，因此会选择更高版本的版本号作为当前版本号。

Master节点在回复客户机Chunk请求时，简单的认为那些过期的块根本就不存在，

并在通知客户机哪个Chunk服务器持有租约，或者指示Chunk服务器从哪个Chunk服务器进行克隆时，

消息都会附带Chunk的版本号，客户机或者 Chunk服务器执行时都会验证版本号以确保访问当前版本的数据。

 

5 容错和诊断

 

设计GFS遇到最大挑战就是如何处理频发的组件失效， 组件的数量和质量让这些问题远远超过一般系统

意外发生的频率，机器的稳定性和硬盘可靠性并不能认为是恒定的，组件失效下会造成系统不可用，甚至是产生不完整数据。

下面是如何面对这些挑战并组件失效不可避免下GFS自带工具诊断系统故障。

 

5.1 高可用性

 

 

在GFS集群数百个服务器之中，在任何给定时间内必定有些服务器是不可用的，使用如下方式来保证整个系统高可用性: 快速恢复 + 复制

 

5.1.1 快速恢复

 

Master Chunk节点都被设计为可以数秒内恢复他们的状态并重新启动，

事实上 我们并不区分正常关闭和异常关闭，通常我们通过直接kill掉进程来关闭服务器，此时，客户机和其他的服务器都会感觉到系统有点颠簸，正在发出的请求会超时，需要直接连接到重启后的服务器，然后重试这个请求。

 

 

5.1.2 Chunk复制

 

 

用户可以为文件命名空间的不同部分设定不同的复制级别，缺省是3，当有Chunk服务器离线了，或者

通过Chunk校验发现了已经损坏的数据， Master节点通过克隆已有的副本保证每个Chunk都被完整复制，

虽然这种复制策略对我们很有效，但是我们也在寻找其他形式的跨服务器冗余解决方案，比如使用奇偶校验，erasure codes来解决我们日益增长的只读存储需求。

 

5.1.3 Master服务器的复制

 

 为了保证Master服务器的可靠性，Master服务器的所有操作日志和checkpoint文件都被复制到多台机器上，

当操作日志写入到Master服务器的备节点和本机磁盘时，Master服务器状态的修改操作才是提交成功的。

如果Master进程所在机器或磁盘失效了，处于GFS系统外部的监控程序会在其他存有完整操作日志的机器上启动一个新的Master进程。

 

5.2 数据完整性(数据读写下的checksum校验)

 

每个Chunk服务器都使用Checksum来检查保存的数据是否损坏，基于磁盘损坏导致数据在在读写过程中损坏或丢失，我们可以通过别的Chunk副本来解决数据损坏问题，但跨越Chunk服务区比较副本来检查数据是否损坏很不实际，另外GFS允许有歧义的副本存在，GFS原子记录追加的操作并不保证副本完全相同，

基于如上，每个Chunk服务器必须独立维护checksum来校验自己副本的完整性。

 

每个Chunk块都对应一个32位的Checksum,Checksum保存在内存和硬盘上，同时也记录操作日志。

 

对于读操作而言，数据返回给客户端或其他checksum服务器之前，chunk服务器会校验读取范围涉及的范围内块的checksum, 如果这个checksum不正确，chunk服务器返回给请求者一个错误信息，并通知Master服务器，作为回应，客户机应当从其他副本读取数据，Master服务器也会从其他副本克隆数据进行恢复。当一个新的副本就绪后，Master服务器通知副本错误的Chunk服务器删除掉错误的副本。

 

如果写操作覆盖已经存在的一个范围内的Chunk，我们必须读取和校验被覆盖的第一个和最后一个块，然后在执行写操作，操作完成之后再重新计算和写入新的Checksum.

 

在chunk服务器服务器空闲时, 它会扫描校验每个不活动的Chunk内容，这样能够发现很少被读取的Chunk

是否完整，一旦发现损坏，Master节点会创建拷贝新的chunk，删除损坏的Chunk,这套流程避免了非活动损坏的Chunk欺骗Master节点。

 

 

5.3 诊断工具

 

详尽深入细节的诊断日志，在问题隔离，调试，性能分析方面给我们带来无法估量的帮助。

没有日志的帮助，我们很难理解短暂的，不重复的机器之间的消息交互。

GFS服务器会记录大量关键事件以及所有RPC请求和回复。

RPC日志包含了网络上发生的所有请求响应的详细记录，通过匹配请求和回应，以及收集不同机器上的RPC日志，我们可以重演所有消息交互来诊断问题，日志还用来追踪负载测试和性能分析。

 

6 度量

 

来  使用小规模基准测试来展示GFS系统架构和实现上的一些固有瓶颈，并展示GOOGLE内部真实GFS集群的基准数据。

 

6.1 小规模基准测试

 

1台Master服务器，2台Master服务器复制节点，16台Chunk服务器和16个客户机组成的GFS集群。

 

典型GFS集群有数百台Chunk服务器和数百个客户机。

 

随着客户机增加，数据

 

 

 

6.1.1 读取

 

6.1.2 写入

 

6.1.3 记录追加

 

6.2 实际应用中的集群

 

6.2.1 存储

 

6.2.2 元数据

 

Master服务器上存放的元数据包含了 文件所有者和权限，文件到chunk的映射关系，每一个chunk当前版本号。

 

6.2.3 读写速率

 

6.2.4 Master服务器的负载

 

Master服务器的数据结构，通过对名字空间进行二分查找提高效率，取代顺序扫描目录来查找特定目录。

Master服务器可以轻松的每秒钟进行数千次文件访问。

 

6.2.5 恢复时间(chunk副本小于设定因子时的拷贝)

 

恢复所有chunk副本所花的时间取决于资源的数量，看下例:

 

将集群B上的一个chunk服务器kill掉，此chunk服务器上大约有15000个chunk,共600GB，为了减少克隆操作

对正在运行的应用程序的影响，以及为GFS调度策略提供修正空间， 我们缺省吧集群中并发克隆操作的数量设置为91个(chunk服务器数量的40%),每个克隆操作最多允许使用的带宽是 6.25MB/s,

所有的chunk在23.2分钟恢复了，复制的速度高达 440MB/s。

 

 

6.3 工作负荷分析

 

 

6.3.1 方法论和注意事项

 

6.3.2 Chunk服务器工作负荷

 

6.3.3 记录追加 VS  写操作

 

6.3.4 Master的工作负荷

 

7 经验

 

GFS最初被设想为生产系统后端文件系统，随着时间推移，GFS使用中逐步增加对研究和开发任务的支持。

 

 

8 相关工作

 

GFS提供一个与位置无关的名字空间，这样数据可以为了负载均衡或者灾难冗余等目的在不同位置透明迁移

由于磁盘相对便宜，并且复制方式比较简单，因此选择复制方式实现冗余。

 

GFS并没有在文件系统层面提供任何Cache机制，主要工作就是去流式读取一个大型的数据集。

 

某些分布式文件系统，去掉了中心服务器，只依赖于分布式算法来保证一致性和管理性。

GFS选择中心服务器方式目的是为了简化设计，增加可靠性，能灵活扩展，并控制着所有Chunk的变更，

因此极大简化了原本非常复杂的Chunk分配和复制策略的实现方法。

 

Master服务器的扩展性和高可用性(对于读取)目前是影子Master服务器机制来保证，Master服务器状态更改

通过预写日志方式实现持久化。

 

灾难冗余方案是我们设计的核心， 并关注使用普通设备来解决复杂分布式系统日常的数据处理。

 

 

9 结束语

 

 我们根据当前和可预期的将来的应用规模和技术环境来评估传统的文件系统特性，我们的评估结果又将我们

引导到一个使用完全不同于传统的设计思路上，比如 组件失效是常态而不是异常， 针对采用追加方式写入然后在读取(序列化读取)的大文件进行优化，扩展标准文件系统接口，放松接口限制来改进整个系统。

 

系统通过持续监控，复制关键数据，快速和自动恢复提供灾难冗余，周期性透明修复损坏数据并在第一时间重新建立丢失的副本，并使用checksum在磁盘或者IDE子系统级别检测数据损坏。

 

系统设计保证了有大量并发读写操作时能提供很高的合计吞吐量，系统通过分离控制流和数据流实现这个而目标。流程控制在Master服务器处理， 而数据流在Chunk服务器和客户端处理，当一般操作涉及到Master服务器时，由于GFS选择的Chunk尺寸较大，以及通过Chunk Lease将控制权交给主副本，这些措施将Master服务器的负担降到最低，这样使得一个简单 中心的Master不会成为瓶颈。

GFS是google持续创新和处理整个WEB范围内难题的一个重要工具。