分布式文件系统 and Google File System

1. 目标：

设计一个分布式文件系统，它是：

1.  用于大型的，分布式，和海量数据进行访问。

     它支持的数据必须是P级甚至是更高级别的。你可以像在本机器一样操纵文件，它提供必要的文件系统基本I/O功能，如创建，删除；但是设计的假设，I/O操作，文件块大小必须经过仔细斟酌。

2. 它运行在廉价的普通硬件上。硬件随时都也可能损害，磁盘每分钟都有可能损坏，网络随时都有可能受阻，宿主操作系统故障，应用程序bug，停电问题，人为的错误。因此，panggu必须持续的监控，错误检查，容错，自动故障恢复

3. 多clien和多用户访问.
    客户程序可能来自不同的机器，来自不同的用户。对不同用户，不同的应用程序，不同的机器上的程序，必须对文件进行读写保护。

4. 针对特殊的I/O操作进行优化：大多数文件I/O操作是append新的数据，而不是overwrite现存的数据。因此该文件系统不支持物理上的overwrite

但是它不是：

1。 它不是native file system，它应该构建在宿主操作系统之上，它通过操作系统api提供分布式文件处理的操作。

2.GFS 概览

2.1 假设

1. ---系统建立在大量廉价的容易出错的普通硬件上
2. ---系统存储大量的大块数据
3. ---系统的读负载主要由两类：大量流形式的读和少量的随机读。作为service的读多是几百k，几M量基的。
4. ---系统的写负载主要是大量的顺序的append写。每次写的大小跟读操作的数据量差不多
5. ---系统必须在逻辑上实现多客户程序同时append操作
6. ---高度稳定的带宽比低的延迟跟重要。
7. 2.2 接口：
8. GFS, 提供了类似文件系统的接口，但是不是实现标准的POSIX API. 支持create，delete，open，close，read，write操作；GFS,提供snapshot 和 append操作。

3.构架

1. single master 和 multiple chunkservers

multiple chunkservers：文件被分为固定大小的块，这个块成为chunk，每一个块有一个64-bit的标示，称为handle。handle是有master在文件创建时产生的。chunkserver在磁盘上将chunk存储起来，只需要指定handle和range就可以读写chunk，chunk就是像普通的linux文件。为了保证可靠性，每一个chunk为在多个chunkservers上存储几个备份。

single master：single master的构架是为了设计上的简化，同时也是GFS的一个弱点。master维护所有文件系统的元数据，如文件的大小，位置，用户，权限，等等。同时master也控制一些系统活动，如定期的垃圾回收。

chuncserver和master通过心跳消息完成状态传递。

第一个典型的读写过程如下：

step1.  应用程序向 master发送读写请求，（filename，chunk index）
step2.  master 查询文件系统，并定位chunk的位置，返回应用程序(chunk handle, chunk locations)
step3.  应用程序得到文件所在的机器，并向该机器的chunkserver发送请求( chunk handle, byte range)
step4.  chunkserver和应用程序相互传输数据。

注意这里的控制流：client<->aplication, master<->chunkserver, client->chunkserver 
数据流：client<->chunkserver   chunkserver<->chunkserver

chunksize: 64M. 从传统文件系统的观点来看，GFS存储的文件都是超大规模，数G大小的文件非常平常。在这种应用场景下，GFS将文件块大小定为64M，远远超过了一般文件系统中文件块的大小。大文件块的设置，给GFS系统带来很多好处：首先减少了客户与master交互的次数，客户只需要较少次数与master通信，就可以获得所需要的文件位置信息，节约了网络带宽，同时缓解了master压力；其次由于使用了大文件块，客户可以在一个chunk上完成更多操作，客户通过维持一个到chunkserver的TCP长连接来减少网络管理量；再次大文件块极大减小了master上元数据的大小，系统的元数据信息可以保存在master内存中，加快了元数据的操作速度

metadata: 1）file和chunk的名字空间，"/name/foo”，2）file到chunk的映射，3）chunk所有副本location的映射表。所有的原信息都保存在在master机器的内存中。namespace 和 file-to-chunk mapping 有 操作日志（operation log）保存在本地磁盘和远程磁盘上，以保证一致性。一旦master故障，master可以从operation log中逐条执行完成metadata的恢复。注意到，master并没有chunk locations，而是询问chunkserver，以获取相关的locations信息。

一致性模型：

1. File namespace（如创建）的改变是原子性的。即，同一个时间不会有对同一个filenamespace的两个不同操作，例如不能同时删除和重命名。
2. file region 对所有的client是一样的，不论是从那个个副本中获取数据。
3. 记录append操作的原子的。
保证一致性的方法是：1）在所有的副本上以同样的顺序来操作chunk。 2）每一个chunk都有一个version，每一更新都会修改version。

4.系统交互

1. 控制流（Leases 和 mutation 顺序）：
   多副本下，master会授予其中一个副本以chunk lease，这个副本称为primary。由primary选择chunk mutation的顺序，所有的副本都保持同一个顺序来操作一个chunk。每一个lease由超时时间，如60s，如果chunk mutation没有完成，primary可向master请求续约。如果master和primary失去联系（由心跳消息实现），master会选择另一个primary，然后重新做chunk mutation。

下面是一次写操作的控制流程：
1）. clent请求master， 向持有lease的chunkserver索取chunk和副本地址。
2）. master返primary和其他副本的唯一标识。client 缓存此数据。
3）.  clent将数据推向所有副本。
4）.  当所有的副本接收到数据，并作出响应是，clent想primary发出写请求。
5）.  primary将写请求推送给所有的二级副本
6）. 所有的二级副本向primary发出写完成响应。
7）. primary 通知client 写完成。

2.数据流：
     一个好的设计是，控制流和数据流分开。控制流是从client->primary—>secondaries, 数据流是线性的从一个chunkserver到另一个chunkserver的数据链，当然这个数据链是经过仔细挑选的。挑选的目标是： 尽可能利用每台机器的带宽，防止网络的瓶颈和高延迟的连接，同时最小化推送数据的延迟时间。
      为了最大化带宽的使用，数据的传输是线性的，而不是以某种拓扑结构（如：树）传输的。因此大量的带宽用于传输数据
      为了防止网络的瓶颈和避免高延迟的连接， 每一台机器尽可能选择“近”的节点传输数据。机器之间的远近可以ip或者其他途径获得。
      为了最小化延迟，数据采用TCP连接，一旦chunkserver接收到数据，马上开始转发给下一个节点。数据传输几乎是同步的。

3. Atomic Record Append
    传统的写操作需要 client端说明数据和写起点位置（偏移量），在一个region里的同步写操作是不可以序列化的：因为region可能会包括来自多个client的数据碎片。GFS的Record Append仅仅需要在前面描述的控制流中primary端加入一些判断逻辑。clients推送数据，然后向primary发送写请求，primary检查 当前append的数据是否操作chunk的最大size（64M), 如果是，primary会填充chunk到最大size，然后告诉所有的secondaries做同样的操作。然后返回clients 写操作应该在写一个chunk上执行。（为了确保在最差情况下的碎片也能接受，Record Append被限制在最多1/4 chunk size）。
    如果一个record append 在任何一个副本上失败，clients 会重新执行此次操作。结果是，同一个chunk的副本可能包含不同的数据。GFS并不保证所有的 replicas 都是按位一致的，它仅仅保证写的时候所有的replicas是一个原子单元。

4. Snapshot
    Snapshot 将 文件或者目录树 做快速的拷贝。Snapshot采用copy-on-write的技术，但master接收到snapshot的请求，首先master收回在file上所有的lease。在所有lease都被收回或者过期以后，master 在 磁盘上做log。然后在in-memory上应用这些log记录。最新的snapshot指向和源文件相同的chunk。一旦client需要在chunk（命名为C）上做写操作，client发送请求到master，寻找primary，master马上意识到chunk C上的count计数大于1，master推迟响应client，而是选择一个新的chunk C‘ ，然后请求所有包含chunk C的chunserver 创建新的chunk C'.

5. Master 的操作

master执行的操作包括：

名字空间（namespace）的管理和锁
副本放置（Replica Placement）
创建（Creatation），再复制（Re-replicattion），在平衡（Rebalance）
垃圾回收（Garbage Collection）
陈旧副本删除（Stale Replica Detection）

具体参考 The Google File SyStem