分布式文件系统

通过学习GFS的english paper 和中文翻译，学习，思考后的总结发出来，供大家共同学习讨论。

1 分布式文件系统的提出
满足：大规模数据密集型应用。连续读写大文件。
a scalable distributed file system for large distributed data-intensive applications.
It provides fault tolerance.
HDFS applications need a write-once-read-many access model for files
（1）几百万文件，文件的大小通常在100MB或者以上。数个GB大小的文件也是普遍存在，并且要能够被有效的管理。
（2）系统的工作负载主要由两种读操作组成：大规模的流式读取和小规模的随机读取。大规模的流式读取通常一次读取数百KB的数据，更常见的是一次读取1MB甚至更多的数据。来自同一个客户机的连续操作通常是读取同一个文件中连续的一个区域。小规模的随机读取通常是在文件某个随机的位置读取几个KB数据。如果应用程序对性能非常关注，通常的做法是把小规模的随机读取操作合并并排序，之后按顺序批量读取，这样就避免了在文件中前后来回的移动读取位置。
（3）高性能的稳定网络带宽远比低延迟重要。我们的目标程序绝大部分要求能够高速率的、大批量的处理数据，极少有程序对单一的读写操作有严格的响应时间要求。
（4）GFS提供了快照和记录追加操作。
2 大规模数据的组织方式
分布式文件系统
3 GFS灾难冗余实现
组件失效是常态，系统必须持续监控自身的状态.
灾难检测:heatbeat meassage & checksum
冗余: copy
4 GFS在设计，可靠性，性能，容错，可伸缩，数据存储，集群存储上的体现
5 google实现原理
GFS存储的文件都被分割成固定大小的Chunk。
5.1 chunk
5.1.1chunk创建
Master分配给chunk一个不变的，全球唯一的一个64位标示。
5.1.2 chunk server功能
Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上，并且根据指定的Chunk标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个块服务器上。缺省情况下，我们使用3个存储复制节点，不过用户可以为不同的文件命名空间设定不同的复制级别。
5.1.3 chunk metadata
5.1.4 chunk LRU buffer

5.2 master
Master节点管理所有的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置信息。Master节点还管理着系统范围内的活动，比如，Chunk租用管理(alex注：BDB也有关于lease的描述，不知道是否相同)、孤儿Chunk(alex注：orphaned chunks)的回收、以及Chunk在Chunk服务器之间的迁移。Master节点使用心跳信息周期地和每个Chunk服务器通讯，发送指令到各个Chunk服务器并接收Chunk服务器的状态信息。
What is stored in cache
(1) The file and chunkna mespaces.
(2) the mapping from files to chunks.
(3) the locations of each chunk’s replicas.
The first two types (namespaces and file-to-chunkma pping) are also kept persistent by logging mutations to an operation log stored on the master’s local disk and replicated on remote machines.
.存储3种主要类型的元数据，包括：
文件和Chunk的命名空间、文件和Chunk的对应关系、每个Chunk副本的存放地点。所有的元数据都保存在Master服务器的内存中。
前两种类型的元数据（命名空间、文件和Chunk的对应关系）同时也会以记录变更日志的方式记录在操作系统的系统日志文件中，日志文件存储在本地磁盘上，同时日志会被复制到其它的远程Master服务器上。采用保存变更日志的方式，我们能够简单可靠的更新Master服务器的状态，并且不用担心Master服务器崩溃导致数据不一致的风险。Master服务器不会持久保存Chunk位置信息。Master服务器在启动时，或者有新的Chunk服务器加入时，向各个Chunk服务器轮询它们所存储的Chunk的信息。
Chunk locations
The master does not keep a persistent record of which chunkservers have a replica of a given chunk. It simply polls
chunkservers for that information at startup. The master
can keep itself up-to-date thereafter because it controls all
chunk placement and monitors chunkserver status with regular
HeartBeat messages.
Operation log
Since the operation log is critical, we must store it reliably
and not make changes visible to clients until metadata
changes are made persistent.
Master启动时轮询chunk的实现
只有Chunk服务器才能最终确定一个Chunk是否在它的硬盘上。
master操作日志
(1)we must store it reliably and not make changes visible to clients until metadata changes are made persistent.
(2)So responds to a client operation only after flushing the corresponding log record to disk both locally and remotely.
(3)The master batches several log records together before flushing thereby reducing the impact
of flushing and replication on overall system throughput.
(4)对日志做检查点operation.
操作日志包含了关键的元数据变更历史记录。这对GFS非常重要。这不仅仅是因为操作日志是元数据唯一的持久化存储记录，它也作为判断同步操作顺序的逻辑时间基线（alex注：也就是通过逻辑日志的序号作为操作发生的逻辑时间，类似于事务系统中的LSN）。
垃圾回收
垃圾回收机制
当一个文件被应用程序删除时，Master节点象对待其它修改操作一样，立刻把删除操作以日志的方式记录下来。但是，Master节点并不马上回收资源，而是把文件名改为一个包含删除时间戳的、隐藏的名字。当Master节点对文件系统命名空间做常规扫描的时候，它会删除所有三天前的隐藏文件（这个时间间隔是可以设置的）。直到文件被真正删除，它们仍旧可以用新的特殊的名字读取，也可以通过把隐藏文件改名为正常显示的文件名的方式“反删除”。当隐藏文件被从名称空间中删除，Master服务器内存中保存的这个文件的相关元数据才会被删除。这也有效的切断了文件和它包含的所有Chunk的连接（alex注：原文是Thiseffectively severs its links to all its chunks）。
在对Chunk名字空间做类似的常规扫描时，Master节点找到孤儿Chunk（不被任何文件包含的Chunk）并删除它们的元数据。Chunk服务器在和Master节点交互的心跳信息中，报告它拥有的Chunk子集的信息，Master节点回复Chunk服务器哪些Chunk在Master节点保存的元数据中已经不存在了。Chunk服务器可以任意删除这些Chunk的副本。
过期失效的副本检测
Master节点保存了每个Chunk的版本号，用来区分当前的副本和过期副本。
无论何时，只要Master节点和Chunk签订一个新的租约，它就增加Chunk的版本号，然后通知最新的副本。Master节点和这些副本都把新的版本号记录在它们持久化存储的状态信息中。这个动作发生在任何客户机得到通知以前，因此也是对这个Chunk开始写之前。如果某个副本所在的Chunk服务器正好处于失效状态，那么副本的版本号就不会被增加。Master节点在这个Chunk服务器重新启动，并且向Master节点报告它拥有的Chunk的集合以及相应的版本号的时候，就会检测出它包含过期的Chunk。如果Master节点看到一个比它记录的版本号更高的版本号，Master节点会认为它和Chunk服务器签订租约的操作失败了，因此会选择更高的版本号作为当前的版本号。
容错和诊断
Chunk 复制
每个Chunk都被复制到不同机架上的不同的Chunk服务器上。用户可以为文件命名空间的不同部分设定不同的复制级别。缺省是3。当有Chunk服务器离线了，或者通过Chksum校验发现了已经损坏的数据，Master节点通过克隆已有的副本保证每个Chunk都被完整复制。
Master服务器的复制
为了保证Master服务器的可靠性，Master服务器的状态也要复制。Master服务器所有的操作日志和checkpoint文件都被复制到多台机器上。对Master服务器状态的修改操作能够提交成功的前提是，操作
日志写入到Master服务器的备节点和本机的磁盘。
数据完整性（理论了解）
每个Chunk服务器都使用Checksum来检查保存的数据是否损坏。每个Chunk服务器必须独立维护Checksum来校验自己的副本的完整性。
我们把每个Chunk都分成64KB大小的块。每个块都对应一个32位的Checksum。和其它元数据一样，Checksum与其它的用户数据是分开的，并且保存在内存和硬盘上，同时也记录操作日志。

灾难恢复
Master服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。为了缩短Master启动的时间，我们必须使日志足够小（alex注：即重演系统操作的日志量尽量的少）。Master服务器在日志增长到一定量时对系统状态做一次Checkpoint(alex注：Checkpoint是一种行为，一种对数据库状态作一次快照的行为)，将所有的状态数据写入一个Checkpoint文件（alex注：并删除之前的日志文件）。在灾难恢复的时候，Master服务器就通过从磁盘上读取这个Checkpoint文件，以及重演Checkpoint之后的有限个日志文件就能够恢复系统。Checkpoint文件以压缩B-树形势的数据结构存储，可以直接映射到内存，在用于命名空间查询时无需额外的解析。这大大提高了恢复速度，增强了可用性。
5.3 gfs client
GFS客户端代码以库的形式被链接到客户程序里。客户端代码实现了GFS文件系统的API接口函数、应用程序与Master节点和Chunk服务器通讯、以及对数据进行读写操作。客户端和Master节点的通信只获取元数据，所有的数据操作都是由客户端直接和Chunk服务器进行交互。
Gfs client knows：
Chunk的大小（64MB），文件名，
Gfs cache：
Key：文件名 + chunk index； // Chunk index = 字节偏移 + 固定的chunk大小。
Value：chunk标识和副本信息。
客户端可以轻松的缓存一个数TB的工作数据集所有的Chunk位置信息。
无论是客户端还是Chunk服务器都不需要缓存文件数据。Chunk服务器不需要缓存文件数
据的原因是，Chunk以本地文件的方式保存，Linux操作系统的文件系统缓存会把经常访问的数据缓存在内存中。
Gfs client需要缓存从master得到的元数据信息。
5.4 client,master 与chunk的通信
GFS通过Master服务器和所有Chunk服务器的定期“握手”来找到失效的Chunk服务器，并且使用Checksum来校验数据是否损坏。

5.4.1租约机制(Leases and Mutation Order)
我们使用租约（lease）机制来保持多个副本间变更顺序的一致性。Master节点为Chunk的一个副本建立一个租约，我们把这个副本叫做主Chunk。主Chunk对Chunk的所有更改操作进行序列化（client重新向primary发起通知写入刚才的数据。primary会为每个写入请求分配一个serial number，primary首先按照这个顺序写入，并且将这个顺序传播到secondary上面等待secondary按照这个顺序写入）。所有的副本都遵从这个序列进行修改操作。因此，修改操作全局的顺序首先由Master节点选择的租约的顺序决定，然后由租约中主Chunk分配的序列号决定。
5.4.2 并发mutation的一直性保证

Step1：client首先询问master要到所有的chunk location.如果这个chunk没有primary的话，那么就分配一个并且指定一个lease 。
Step3：client将所需要write的data部分push到所有的replicas（至于如何push后面会说）。replicas接受到之后将这个数据放在一个LRU buffer里面，直到确认写入或者是aged out 。
Step4：client重新向primary发起通知写入刚才的数据。primary会为每个写入请求分配一个serial number，primary首先按照这个顺序写入。
解读step4，这样做在不使用锁的情况下，做到了一致性保证。LRU buffer缓存接受到的数据。
所有用户发过来的数据，是如何确定存放位置的？ 每个客户认定自己发过来的数据都是追加写到文件末尾的，并不需要确定文件写入位置。
这样的话，每个客户两次写入的内容不能有联系。这样对大文件的分批写入是不支持的。
Step5：将这个顺序传播到secondary上面等待secondary按照这个顺序写入。
Step6：secondary按照写入顺序写入数据的结果返回给primary。
Step7：primary等待secondary写完消息之后，primary通知client OK。如果错误的话，那么会存在inconsistent的状态。
5.4.3 Concurrent Mutation failed
append相对于write来说处理非常简单，因为不会存在overwrite的问题。每次失败的话，要不就把写失败的地方重新覆盖掉（正常情况），要不就会追加造成重复记录和padding。对于重复记录可以通过判重过滤，对于padding可以通过record本身校验判断出来）。而对于write来说就没有这么简单了，write失败的话只有放弃整个chunk块。
5.4.4 Atomic Record Appends
In a record append, however, the client specifies only the data. GFS appends it to the file at least once atomically.
such files often serve as multiple-producer/single-consumer.
such files:different clients write the same file concurrently by appending.
5.4.5 inserting result to exceed 64Mbytes
The primary checks to see if appending the record to the current chunkw ould cause the chunkto exceed the maximum size (64 MB). If so, it pads the chunkto the maximum size, tells secondaries to do the same, and replies to the client indicating that the operation should be retried on the next chunk (Record append is restricted to be at most one-fourth of the maximum chunks ize to keep worstcase fragmentation at an acceptable level.)
5.4.6 并发写入大于64Mbytes的数据
此时用户要求是按照顺序写入到两个连续的chunk中，此种情况下，需要使用锁来实现了。5.4.2的并发写不适用此种情况。

5.4.7 snapshot(针对文件)
When the master receives a snapshot request, it first revokes(撤销) any outstanding（未完成的） leases on the chunks in the files it is about to snapshot。
对快照操作时，在将真正的内容拷贝到快照指定的chunk上。
Snapshot作用
快照操作几乎可以瞬间完成对一个文件或者目录树（“源”）做一个拷贝，并且几乎不会对正在进行的其它操作造成任何干扰。我们的用户可以使用快照迅速的创建一个巨大的数据集的分支拷贝（而且经常是递归的拷贝拷贝），或者是在做实验性的数据操作之前，使用快照操作备份当前状态，这样之后就可以轻松的提交或者回滚到备份时的状态.
就像AFS（alex注：AFS，即Andrew File System，一种分布式文件系统），我们用标准的copy-on-write 技术实现快照。当Master节点收到一个快照请求，它首先取消作快照的文件的所有Chunk的租约。
这个措施保证了后续对这些Chunk的写操作都必须与Master交互交互以找到租约持有者。这就给Master 节点一个率先创建Chunk的新拷贝的机会。租约取消或者过期之后，Master节点把这个操作以日志的方式记录到硬盘上。然后，Master节点通过复制源文件或者目录的元数据的方式，把这条日志记录的变化反映到保存在内存的状态中。新创建的快照文件和源文件指向完全相同的Chunk地址。
在快照操作之后，当客户机第一次想写入数据到Chunk C，它首先会发送一个请求到Master节点查询当前的租约持有者。Master节点注意到Chunke C的引用计数超过了1(说明此chunk上进行了snapshot)。Master节点不会马上回复客户机的请求，而是选择一个新的Chunk
句柄C`。之后，Master节点要求每个拥有Chunk C当前副本的Chunk服务器创建一个叫做C`的新Chunk。通过在源Chunk C所在Chunk服务器上创建新的ChunkC`，我们确保数据在本地而不是通过网络复制（我们的硬盘比我们的100Mb以太网大约快3倍）。从这点来讲，请求的处理方式和任何其它Chunk没什么不同：Master节点确保新Chunk C`的一个副本拥有租约，之后回复客户机，客户机得到回复后就可以正常的写这个Chunk，而不必理会它是从一个已存在的Chunk克隆出来的。
Snapshot实现技术
Snapshot时，只是在chunk上的引用计数 + 1，而不是真正的copy data。当做快照的chunk进行insert时，这时才真正的拷贝数据。
使用cow（copy-on-write）技术。
WIKI上对COW的解释：
Copy-on-write (sometimes referred to as "COW") is an optimization strategy used in computer programming. The fundamental idea is that if multiple callers ask for resources which are initially indistinguishable, they can all be given pointers to the same resource. This function can be maintained until a caller tries to modify its "copy" of the resource, at which point a true private copy is created to prevent the changes becoming visible to everyone else. All of this happens transparently to the callers. The primary advantage is that if a caller never makes any modifications, no private copy need ever be created.
意思上就是：在复制一个对象的时候并不是真正的把原先的对象复制到内存的另外一个位置上，而是在新对象的内存映射表中设置一个指针，指向源对象的位置，并把那块内Copy-On-Write位设置为1.这样，在对新的对象执行读操作的时候，内存数据不发生任何变动，直接执行读操作；而在对新的对象执行写操作时，将真正的对象复制到新的内存地址中，并修改新对象的内存映射表指向这个新的位置，并在新的内存位置上执行写操作。

GFS架构图

Chunk index = 字节偏移 + 固定的chunk大小。
6 GFS一致性保证
数据修改操作分为写入或者记录追加两种。写入操作把数据写在应用程序指定的文件偏移位置上。即使有多个修改操作并行执行时，记录追加操作至少可以把数据原子性的追加到文件中一次，但是偏移位置是由GFS选择的一个Chunk有多个副本。

如何保证一次文件修改在多个chunk上是一致性
（a） 对Chunk的所有副本的修改操作顺序一致。
（b）使用Chunk的版本号来检测副本是否因为它所在的Chunk服务器宕机（4.5章）而错过了修改操作而导致其失效。失效的副本不会再进行任何修改操作，Master服务器也不再返回这个Chunk副本的位置信息给客户端。它们会被垃圾收集系统尽快回收。

Defined region:
A region is defined after a file data mutation if it is consistent and clients will see what the mutation writes in its entirety.
Undefined region:

how our applications can distinguish defined regions from undefined regions.
component failure
component failures can of course still corrupt or destroy data. GFS identifies failed chunkservers by regular handshakes between master and all chunkservers and detects data corruption by checksumming.
Once a problem surfaces, the data is restored from valid replicas as soon as possible.

并发insert同一个文件保证一致性方法
Consistency Model
GFS主要是为了追加（Append）而不是改写（Overwrite）而设计的。
Guarantees
(1)File namespace mutations (e.g., file creation) are atomic. namespace
locking guarantees atomicity and correctness.
(2) The state of a file region after a data mutation depends
on the type of mutation, whether it succeeds or fails, and
whether there are concurrent mutations.
(3) A file region is consistent if all clients will
always see the same data, regardless of which replicas they
read from. A region is defined after a file data mutation if it is consistent and clients will see what the mutation writes in its entirety.
(4) Concurrent successful mutations leave the region undefined but consistent.
(5) When a mutation succeeds without interference
from concurrent writers, the affected region is defined (and
by implication consistent).
Mutation operation
记录变化的顺序。
Data mutations may be writes or record appends.
After a sequence of successful mutations, the mutated file
region is guaranteed to be defined and contain the data written
by the last mutation. GFS achieves this by (a) applying
mutations to a chunk in the same order on all its replicas and （b）using chunk version numbers to detect any replica that has become stale because it has missed mutations while its chunkserver was down。
GFS applications can accommodate the relaxed consistency
model with a few simple techniques already needed for
other purposes: relying on appends rather than overwrites,
checkpointing, and writing self-validating, self-identifying
records.