gfs论文笔记

GFS论文：

Design Assumptions：

Failure detection, recovery

对大文件multi-gb优化

Large streaming read。（支持small random read但不是主要场景）

Large, sequential write, appending to theend of the file。一旦写入，很少更改。（支持随机写，但不是主要场景，不对其优化）

多个client并发append同一个文件

高带宽比低延迟重要

 

接口：

Create/delete/open/close/read/write/snapshot(createa copy of a file or directory)/record append(多个client并发append同一个文件

)

 

 

架构：

Single master, multiple chunk servers.

Chunk: 基本分配单元，master会分配全局唯一64位 chunk handle

Chunk server将chunk存为linux file，指定chunk handle和byte range来read/write数据。每个chunk复制多份。

 

Master维护文件系统meta data。包括namespace, access control信息，文件-chunk的映射，chunk的位置，Chunk的管理。（chunk lease management, garbagecollection of orphaned chunks, and chunk migration between chunkservers）.master和chunk server之间heart beat传递指令、收集状态信息。

Meta data操作，Client需要和master通信，但数据操作直接通过chunk server(singlemaster可能成为瓶颈，所以需要尽量减少操作)。Client/chunkserver都不cache filedata.(使用场景是streamingthrough large files。对于chunk server来讲，chunk由local file实现，linux 文件系统会cache)，但client会cache metadata.

 

读的过程：

app/client library将filename,offset转换为该文件的chunk index（由于chunk固定大小），将<filename, chunk index>发送给master，master回复client <chunk handle，location of replicas>. Client将其cache。然后client发送请求<chunk handle， byte range>到某一replica。之后对该chunk的读就不再需要client-master通信，除非cache失效或文件重新打开。

 

Chunk size：64M。每个chunk存为一个Linux file.

Chunk过大，若有hotspot怎么办？多个client频繁读写一个小文件，可能只有一个chunk---不是google主要场景。

 

Metadata:

Fileand chunk namespace

Mappingfrom files to chunks

Thelocation of each chunk’s replicas

所有meta data保存在内存。前两者会记录operation log，写入master本地磁盘，并复制到其他机器（解决master crash问题）

Master不在本地存储chunk位置，在启动时或一个chunkserver加入时，会让chunkserver报告chunk信息。(避免了chunk server加入、退出cluster、失效、重启等的数据同步问题，而且chunk server对这个数据是最有话语权的)

 

Inmemory data structure:

后台周期性scan数据结构：chunk garbage collection，re-replicate when chunk serverfails，chunkmigration。

 

Operationlog：

Serve as a logical timeline which definethe order of concurrent operations

Client-master：若有更改，只有当flush log并发送到replica之后才会回应client。Flush时会合并日志记录以减少开销。

 

Master recovery依赖于replay log。为了减少replay时间，日志要尽量小。因此设置checkpoint，日志增大到一定尺寸就checkpoint its state。（checkpoint是B tree结构）

新checkpoint创建不会delay incoming改变。The master switch to a new logfile and create new checkpoint in a separate thread。

 

一致性模型：

File namespace操作比如file creation是原子的。

一个file region发生数据更改后的状态取决于更改类型，更改是否成功，是否有并发更改。

Region的状态：

consistent:

ifall client will always see the same data, regardless of which replica they readfrom.

defined:

afterfile data mutation if it is consistent and the clients will see what themutation writes in its entirety.

如果一个mutation没有concurrent writers。The region is defined—all clientswill always see the mutation

Concurrent successful mutation leave theregion undefined but consistent.—all clients see the same data, but itmay not reflect what anyone mutation has written.

 

A failed mutation makes regioninconsistent.---different cilents may see differentdata at different time

 

Data mutation类型：write, record append.

Write操作在应用指定的offset写入数据，

Record append: 以原子方式append至少一次，但是在GFS选择的offset。

 

Gfs对一个chunk的replic的更改采用相同顺序

每个Chunk有version number。---检测stale replica。Stale的replica不apply mutation

Client cache chunk location失效窗口：cache entries’s timeout或next open of file

 

实际上所有应用修改文件的方式都是append，而不是overwrite。

Application的checkpoint。每写一段就check一次？

 

 

实现流程：

使用lease保证在所有replica上使用一致的修改操作顺序。原则是尽量减少master端的管理开销。

Master将chunk lease授权给其中一个replica，称为primary。Primary负责制定lease内的修改操作顺序。

Lease初始超时60秒，但若chunk上更改一直在进行，primary可以无限申请延期。

Extension request和grant包括在master和chunk server间的heat beat信息里。

Master可能会在超时之前提前revoke一个lease。（比如master想disable一个正在rename的文件上的更改）。

即便master和primary失去通信，master可以在lease超时后grant给另外一个replica新lease.

 

 

1.    client->server：client请求，对于一个chunk，哪个chunk server拥有当前lease，以及其他replica的位置。如果lease不存在，那么master将其授权给一个他选择的replica。

2.    master回复primary标识和其他replica的location. Client将其cache。只有当primary无法联系或primary回复他不再拥有lease时，client才需要和master再次联系。

3.    client将data push到所有replica？每个chunk server在LRU buffer cache保存这些数据，直到数据被使用或aged out。这种方式解耦了数据流和控制流（section 3.2）

4.    当所有replica确认收到数据后，client发送写请求到priamry。请求identify了之前push过去的数据。Primary对收到的每一个更改（serialization，可能是多个client发过来的）赋值一个序列号。按顺序Apply更改到本地状态

5.    primary将写请求转发到其他replica，他们会按primary同样的顺序依次更改。

6.    secondary完成更改后会回复primary。

7.    primary回复client。若有任何replica出错，出错信息会返回给client。此时client请求会被认为失败，the modified region变为inconsistent状态。Client代码通过retry更改来处理这种错误。注意步骤3-7会尝试几次，若仍然失败则会触发retry逻辑重新做更改。

 

如果一次写操作较大跨越了多个chunk，则client代码将其分为多次写操作。因此有可能因并发操作导致被插入或覆盖，最终导致该文件region fragments from different clients，即所谓的undefined状态（consistent依然保证）

 

数据流：

控制流和数据流解耦策略。

控制流：client到primary，然后到其他secondary。

数据流：client将数据以管道模式在chunk server chain中传递（线性的链式传递，而不是其他拓扑结构比如tree），充分利用每个机器的outbound网络带宽来传输数据

为尽量避免网络瓶颈和highlatency链路，每个机器将数据传递到网络拓扑中离他最近的机器。

（通过网络中ip地址精确预估’distance’）

Chunkserver一旦收到一定量数据就开始转发，采用tcp链接。Pipeline机制对google尤其有效因为他们使用full-duplex链路的交换网络。（发送数据不会影响接收数据）

 

Atomicrecord append：

Record append操作只指定data，不指定fileoffset。Gfs保证会选择一个offset，将该数据原子地append至少一次，并将offset返回给client。（传统实现需要distributed lock manager？？）

这种文件可以当做multiple-producer/single-consumerqueue通信机制或多路归并结果文件。

 

Record append操作遵循section 3.1的流程，但在primary上多了一点额外的逻辑。

Client将数据push到所有replica，然后发送请求到primary。Primary检查将数据append到当前chunk是否会超过chunk最大size。如果是，则将chunk 填充到最大size，并告诉其他replica做同样事，然后回复client要在下一个chunk上重复该操作。如果要append的record在chunk size以内，则primary告诉replica在primary所在的offset写数据，最后返回成功给client。

 

如果append在某replica失败，client会retry更改。因此replica上的同一chunk可能包含不同数据，比如某个record的整个或部分duplicate。---GFS并不保证replica上字节相同，只保证数据以原子方式至少写了一次。即当client收到操作success时，数据必然已经在所有replica的某个chunk上的同一offset写入。操作完成后所有replica上至少同样长度。（问题：如何校验读到的数据是否正确呢？？）

 

从一致性模型来看，成功recordappend的region是defined状态，而intervening region是inconsistent。（应用层面可以处理inconsistent情况）

 

 

Snapshot：

快速的拷贝一个文件或目录树，对正在进行的更改影响最小化。

如AFS，使用copy-on-write技术来实现snapshot。

当master收到snapshot request，首先revoke 所要操作文件的chunk的outstanding leases（保证了之后对这些chunk的更改要重新和master通信得到lease holder，master也得到机会来创建新的chunk拷贝）

当lease被revoke（或timeout？）后，master首先记录日志，然后在内存中复制所要copy的文件或目录的meta data，新创建的snapshot文件指向源chunks。

Snapshot操作完成后，当client第一次要写入一个chunkC时，它会向master发送请求以得到当前lease holder。master会意识到该chunk reference count大于1，因此延迟回复client，先创建一个新的chunkhandler C’，然后告诉所有每个server，根据chunk C在本地来创建一个新的chunk C’，因此所有复制都是本地进行的，避免了网络开销。之后master 将lease grant给某一个C’的replica并返回给client。---client并不知道该chunk是刚刚建立的。

 

Master操作：

All namespace operations。

 

Namespacemanagement and locking

很多Master操作是很费时的。比如snapshot操作，master要revoke该snapshot所涉及到的所有chunk的lease。因此设计要考虑不能delay其他masteroperation。---master上允许有多个operation在运行，在namespace region上使用lock来保证同步。

 

与传统文件系统不同，GFS没有per-direction数据结构（列出该目录包含的文件），也不支持别名（hard link orsymbol link）。GFS的namespace是一个lookup table来影射full pathnames到metadata。采用prefix compression后，该lookup table可以保存在内存中。Namespace tree上的每一个节点有一个读写锁。

每个masteroperation运行之前要accquire一系列的锁。比如，如果路径是/d1/d2/.../dn/leaf，它需要在/d1，/d1/d2，...，/d1/.../dn上获得读锁，并在/d1/d2/.../dn/leaf上获得读锁或写锁。（leaf可以使文件也可以是目录）

比如，我们要snapshot/home/user到/save/user/，类似/home/user/foo这样的文件时不能被创建的。

因此snapshot在/home和/save上得到读锁，在/home/user和/save/user上得到写锁。而文件创建操作会在/home和/home/user上得到读锁，在/home/user/foo上得到写锁。因此两个操作可以被正确同步。注意文件创建并不在父目录得到写锁，因为没有类似inode这样的数据结构。

对目录名的读锁足以保证该目录不会被删除。

 

这种锁机制允许在同一个目录并发更改操作。比如并发在一个目录创建文件---对目录名获得读锁，对文件名获得写锁。对目录名的读锁足以保证该目录不会被删除、重命名或快照。

由于namespace下可能有很多node，每个node的读写锁延迟分配，使用完后立即释放。另外lock的获取采用一致的全序以避免死锁。比如先按namespace tree 的level的顺序，同一level上再按字典序。

 

Replicaplacement:

Chunk replica replacement策略的两个目标：

最大化datareliability和availability。最大化网络带宽使用率。因此简单的复制到不同机器是不够的，它只是解决了machine/diskfailure，最大化使用了该机器的网络带宽。还要在不同rack层面来复制，解决整个rack失效问题，

 

Creation,re-replication，rebanlancing

 

master创建chunk时，chunk server的选择取决于：

1）磁盘使用率低于平均水平

2）近期创建的chunk数不要太多

3）Spread chunks across racks

 

一旦chunk的现有replica数量低于用户设定值（比如chunk server失效，chunk server报告chunk corrupted，磁盘失效等），master会立即触发re-replica。

需要re-replicate的chunk优先级依赖于：距离设定的replication目标有多远。越远的优先级越高。为了减少对应用影响，对于阻塞应用的chunk提高其优先级。

Master选择最高优先级的chunk，然后选择某个chunkserver直接复制这个chunk。Chunk server的选择和创建chunk时的策略相同。为了防止clone产生的流量影响应用，master除了控制单个chunk server上的复制，还会控制整个cluster的复制数量。此外chunk server通过控制读请求来控制复制时使用的网络带宽。

 

Master定期rebanlance replicas：检查当前replica分布，将replica移动以得到更好地磁盘使用率和负载均衡。Master还决定删除哪个replica。

 

Garbagecollection

当文件删除后，GFS并不立刻回收空间，而是在垃圾回收时处理，file level和chunk level都是如此。这样系统简洁、稳定

 

机制：

应用删除一个文件时，master记录日志，然后将文件重命名为隐藏名字（包含删除时间戳）。

Master定期扫描整个文件系统namespace，删除超过3天（可配置）的隐藏名字文件。当隐藏文件删除后，其内存meta data也被释放。

Master还回定期扫描chunk namespace。标识孤儿chunk（不属于任何文件），删除对应的meta data。Chunk server在heartbeat中定期报告他所有的chunk，master则回复metadata中已经不存在的chunk标识。Chunk server根据此信息删除这些chunk。

 

Chunk标识：master的file->chunk映射中

Chunk replica标识：chunk server上的linux file

 

垃圾回收、扫描、心跳等都是后台执行。Master可以选择闲时执行。

 

用户可以对namespace不同部分采用不同的复制、回收策略。

 

Stalereplication detection:

Chunk server失效宕机，那么其后的更改他都会漏掉，导致stale replica

对于每一个chunk,master维护一个versionnumber来区分是否stale。当master grant一个新lease时，增加version number并通知replica。Master和replica都在磁盘保存version number。

Master回复Client哪个replica拥有lease时也会包含version number信息，复制时chunk server间也会传递该信息，因此client和chunk server都可以验证version

 

容错、问题诊断设计

 

Master, chunk server启动、恢复状态必须在数秒内

 

Master复制：

日志和检查点被复制到多个机器。如果master机器失效，gfs之外的监控设施会在其他机器上启动master进程。

 

Shadow master（从某个operation log复制读取日志记录并replay。启动时也会pollchuck server， heartbeat等）：当primary master宕机时可提供只读访问，但shadow数据可能比primary延迟数秒。实际上文件数据读自chunk server，因为不stale，stale的可能是master上的file metadata。

 

Dataintegrity:

Gfs的更改特别是record append操作允许各replica不完全一样。每个chunk server必须独立校验数据完整性（通过checksum）

每个chunk由数个64kb的block组成，每个block维护一个32位校验（checksum在内存中，并记入日志，）。chunk server读数据时计算checksum并和存储的checksum比较，若不匹配，向requester（可能是client或其他chunk server）返回错误，并报告master。Requester会从其他replica读取，master会从其他replica clone这个chunk。当new chunk完成后，master会命令chunk server删除旧chunk。