关闭

从五篇paper入门大数据与Hadoop(二):GFS

标签: 大数据服务器GFSHadoop
122人阅读 评论(0) 收藏 举报
分类:

一.GFS设计概览

1.1目标预想

• 架设在多台便宜的的设备而不是大型服务器上,因此要强调容错性
• 兼容large streaming read和small random reads
• 主要支持大工作量按顺序的append写入操作,兼容随机小量写入但不保证效率
• 强调支持多人同时append与read同一文件的操作
• 持久性的高带宽比低反应延迟(low latency)更重要,GFS主要服务于需要高速处理大批量数据的操作而非需要低延迟的individual read or write

1.2接口

    GFS提供了一个通用的文件系统接口而不是具体实现的API。GFS除了提供 创删开关读写 操作外,还支持snapshot与record append操作。
    Snapshot 创建文件的copy或directory tree
    Record append 允许多用户同时append同一个文件而无需多余的locking

1.3架构

    一个master多个chunkservers来服务多个clients。

     每一个机器都是运行commodity Linux(非大型服务器级)的用户级别服务器。允许在同一台机器部署chunkserver和client。

    文件被分成固定大小的chunk,每一个chunk在创建时同时创建一个一个不可变的全局的唯一的64位的chunk handle进行标记。所有的chunk由chunkserver以Linux文件保存,指令通过chunk hundle和byte range对数据进行I/O操作。每个chunk默认三份备份,用户可以设置不同的重复等级和namespace标记不同位置的备份。

    Master保存和管理整个文件系统的metadata,包括namespacetree,access control 信息,chunk maping信息,以及chunk location信息等。Master也控制系统级别的操作如chunk的释放管理,垃圾处理,chunk转移等。Master会周期性的与所有Chunkservers进行交流,通过HeartBeat message传递指令与收集信息。

    每个GFS client通过代码具体实现API并关联到应用程序中,同时与master和chunkservers取得交流,实现应用程序中的读写操作。

这里写图片描述

具体流程如下:
    1. Client与Master取得联系发送file name与chunk index(通过filename与byte offset,即字节偏移量转换而成)

    2. Master通过元数据查找到chunk的信息并回复chunk handle与chunk locations

    3. Client接收到回复后,将chunk handle与chunk locations存入缓存并以对应file name与chunk index作为key。

    4. Client通过chunk location找到最近的拥有拷贝的chunkserver,发送带有chunk handle与byte range(类似修改指令)的请求给指定chunkserver

    5. Cunkserver对指定chunk进行读写操作。

    实际上在一个request中可以请求多个chunks,以减少损耗。
    在GFS中client与chunksever都不将文件(chunk)存入缓存,client会将metadata存入缓存。

1.4单独的Master

    单独的master简化设计,同时更利于master对chunk操作指令的控制。而同时在设计上必须最小化Master对读写操作的介入,以避免Master成为性能瓶颈。Client不从Master得到数据,而是通过master联系到chunkserver,Client将Mster提供的信息存于缓存保存一定的时间,并在期间直接与chunkservers进行操作。

1.5Chunk的大小

    Chunk的大小在GFS中默认为64MB。

Large chunk的好处:
    1. 减少client的请求数量,也让client能轻易缓存metadata
    2. Client能对单独的chunk做更多有效操作
    3. 有利于保持稳定的TCP协议,减少网络过载

Large chunk的坏处:
    一些小文件只包括少量chunk,在chunksevers中由于多个client同时请求,可能成为hot spots,导致某些chunksevers过载。

1.6Metadata

Master保存三种Metadata:
    1.namespaces(文件与chunk的命名空间)
    2.mapping from files to chunk(文件-chunk对应信息)
    3.the location information of each chunk‘s replicas(chunks与副本的位置信息)

    三种metadata都长期保存在master的memory中,前两种同时作为operation log保存在master的本地磁盘中,同时将被备份在别的机器中。Log的形式保证了master状态的更新且更为可靠。

    Chunk与备份的位置信息(第三种)不会持续保存在Master中,而是在master启动时或某个chunksever加入到系统中时询问chunksevers现实的状态。

内存中的元数据:
将元数据保存在内存中可以支持master更快的更简单的进行扫描,更新,垃圾处理,错误处理,chunk迁移等工作。唯一的顾虑在master的memory大小决定了整个系统的最大容量。这个可以直接通过增加memory解决,并不影响可靠用,十分灵活。

Chunk location:
Master不会保持chunk location信息不变,而是通过对chunksever的poll动作与Heart Beat操作间断性更新该信息。

Operation Log(操作日志):
    日志包含了元数据改变的历史记录,是GFS的核心。
    日志不仅作为元数据,还记录了GFS的逻辑时间线,,决定了操作的先后顺序。文件和chunk的版本和状态都唯一且完整的保存在日志中。
    由于日志文件的重要性,在保存上必须非常可靠。否则我们可能失去整个文件系统,即使所有数据没有丢失。
    因此,我们将日志文件备份在多个脱机的设备中,以保证他的安全。

    Master通过replay操作日志上的步奏对系统进行修复。
    为了最小化启动时间,必须缩小日志大小。Master利用checkpoint定期对现有有状态进行备份,且作为操作日志的起始。Checkpoint被保存在B-tree为结构的数据中。

1.7 一致性模型(有关record append)

    GFS拥有一个灵活而一致性的模型,可以很好的支持分布式应用程序而保持相对的简单与高效的实现。
    在文件空间中作出mutation,对于clients是否有一致性的结果见下表:

这里写图片描述

1. Guarantees by GFS:

Consistent:A file region is consistent if all clients will always see
the same data regardless of which replicas they read from.

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

    GFS的命名空间锁保证了原子性和正确定,GFS使用master的操作日志来确定全局的执行顺序。

    区别一般的写操作(write)与record append操作:
    Write操作修改的是应用程序指定的文件偏移量(而不是统一的决定的,可以理解为用户自认为合理的偏移量),因此当出现多个clients同时write操作时,会出现偏移量的设置有重复的情况,最终用户得到的数据将会是一团data fragment这样用户虽然得到的数据是一样的,但是无法确认修改具体的信息,因此说是consist但是undefined

【Concurrent successful mutations leave the region undefined but
consistent: all clients see the same data, but it may not reflect what
any one mutation has written. Typically, it consists of mingled
fragments from multiple mutations.】

    Record append操作是GFS为了确保修改的原子性,对操作进行序列化后,由GFS统一选择文件编辑辑,统一管理。进行append操作后由GFS的Master将文件的偏移量返回给clients。(从理解上来看,append操作实际就是有GFS统一管理的写操作,而clients值是知道对该文件的末尾进行了处理)

【In contrast, a “regular” append is merely a write at an offset that
the client believes to be the current end of file.】

    此外 GFS还会在返回给clients的文件偏移量信息和修改的信息的确切文件中位置,加入padding或record duplicates。以确保chunk的大小完整性,而这部分就是为什么说有少量的inconsistent

    GFS利用以下两个方法保证被读取的文件的defined状态且包括最的mutation内容:
    1. 把对chunk的操作按顺序对所有的replica都操作一遍。
    2. 用chunk version numbers 来检测是否有chunk因为chunksever的故障而过期(stale)
    过期的chunk将会被收集并处理(garbage collected)

2. Implication for Application。

    GFS应用程序通过几个简单的技术实现一致性,这些技术同时也为了满足其他的几个目的:使得程序依赖appends而不是overwrites,实现checkpoint,自我确认等功能。

    文件的每个checkpoint都包括应用级别的验证码(checksums),可以用于分辨不同的application,而读者(reader)只能核查和处理在文件空间(file region)中的最新的checkpoint,而这个文件checkpoint状态一定是defined的。

    这套机制有许多优点。先不论原子性和同步处理(concurrent issue)问题,这个机制可以让修改者(writerriter)渐进的(incrementally)去重启修改一个文件,而不让读者(reader)读取对 正在处理的,部分修改成功的,但是对于应用程序来说还未完成的半成品文件

【Checkpointing allows writers to restart incrementally and keeps
readers from processing successfully written file data that is still
incomplete from the application’s perspective.】

    而即使用append,也会出现merge的情况(比如多个client同时append同一个地方),导致inconsistent,这里GFS也可以用checksum和padding之类的方法鉴别。具体来说,每个append,或者说writer的output都会由于record append的append-at-least-once特性而被保存下来,并附带唯一的padding和duplicates。每个writer准备的record与其额外的信息都会提供给reader,又reader通过额外信息进行甄别。

    如果reader不希望手动甄别,可以通过额外信息分别出特定的writer而对其他record进行过滤。具体的方法Google提供了libaray 代码。

二.系统交互

    本节介绍GFS中client,master和chunkservers如何进行交互,并,完成data mutation操作,保证原子性的record append操作,与snapshot。

2.1关于leases(租约)和Mutation Order(修改顺序)

    首先定义mutation:mutation是修改chunks的内容或源文件的操作,如write或append操作。

【A mutation is an operation that changes the contents or metadata of a
chunksu such as a write or an append operation.】

    leases的作用:保证每个mutation的在每个replica上的顺序一致性。

    Master发放(grant)一个chunk leases给其中一个replicas,我们称这个chunk为primary。

    master首先决定全局的mutations操作的操作顺序(先对哪个chunks操作,再对哪个chunks操作),然后按照这个顺序决定发放lease的顺序.

【the global mutation order is defined first by the lease grant order chosen by the master.】

    然后,Primary 负责决定对于对应的chunk进行mutations操作的操作顺序(内部顺序),并推送给其他所有replicas。

    Primary在clients发送mutations request并验证身份信息完毕后,根据之前从clients推送过来的所有mutation数据(通过数据流)中附带的顺序信息决定mutation操作的操作顺序,然后所有的replicas都遵循这个顺序进行mutations,注意replicas之间没有顺序,是平行关系。

    这里值得注意的是,master并不知道clients要对chunks做的具体操作,master只负责统筹资源(收集chunksever的状态信息,管理metadata),统筹全局顺序(通过给primary发放lease),并且提供位置信息和验证信息给clients,clients自己与对应的chunksever联系(详细见下面的图)

    Leases机制被设计是为了最小化master的管理负担。每个leases的起始期限有60s,然而,直到chunks与所有replica完成mutation操作之前,primary可以请求与收到leases的无限期延续。这个交互会通过Master和chunkservers之间的HeartBeat 信息中传递。同样的,Master有时也会在过期(expires)之前收回lease。下图展示了整个leases交互过程:

这里写图片描述

步奏:
    1. Client询问master哪个chunkerver有所需要的chunk的当前的lease 以及其他replicas的地点。如果还没分配lease,则Mater马上分配一个(这个操作图上没说)

    2. Master回复primary的身份信息以及其他的replicas所在的地址。Client对这个数据进行缓存以留作后续mutation使用。到此为止,只有当primary无法联系上(runreachable)或回复自己已经没有lease时,client才会再次联系master。

    3. Client将mutation数据以任意的顺序推送给每一个replicas(通过数据流,这里包括该client的所有mutation的数据),每个chunkserver将缓存这些数据,直到被使用或过期。【通过数据流与控制流的解耦,通过网络拓扑合理安排昂贵的数据流资源而不考虑client是否是primary,可以很好的提高效能。】

    4. 一旦所有的replicas都示意成功接收到client的mutation数据后,client将发送wirte request给primary。这个request确认了通过数据流推送给所有replicas的数据。(其实这里可以看成一个分段,primary在不断的处理接收到的,来自许多clients的request,并对这些之前收到的混杂的mutation数据进行分类排序的操作。)primary开始根据所有收到的request所对的应mutation数据(注意,这里可能会来自不同的clients,包含必须的顺序信息)给mutation操作分配操作顺序,然后按照这个顺序先对本地chunk执行mutation。

    5. Primary转送write request给所有的下属replicas,每个replicas以一样的顺序执行mutation。

    6. 所有下属回复primary,操作依据成功完成。

    7. Priamry回复client。所有replicas的操作错误都会报告给client。如果在第4步的primary上就出错,则说明本次client request失败,修改位置状态为inconsistent。Client会从新尝试几次第3步到第7步的过程,若仍然不成功,则会回到初始状态。

    最后,如果write by the application(注意这里是write不是append)非常大或者跨越了chunk的边界, GFS client会吧代码且分成很多份,其控制流与上述的过程一样。但是由于write操作的特性,当出现concurrent operations时,在同一个文件空间将会出现被交织(interleaved)甚至被覆盖的情况。虽然可以保证每个replicas完全相同,因为都按照相同的步奏进行mutation,但是由于会出现多个修改片段同时出现的情况

【file region may end up containing fragments from different clients.】

    则这个文件空间处于consistent but undefined的状态。(如1.7所述)

2.2数据流

    解耦数据流和控制流能更有效率的的利用网络。当控制流从primary传送到所有secondaries时,mutation数据会通过仔细选择的chunksevers链路,线性的(linearly)被推送到管线上的chunksevers上。

    选择线性而不是别的网络拓扑,比如树(tree)的原因是最求最大程度的利用每个机器的网络带宽,而避免网络瓶颈和高延迟链接。

    具体来说,每个机器将data推送至离自己最近的,还没收到data的chunksever(这里应该是该data对应的replicas的chunksevers上,不是所有chunksevers)上,机器之间的距离通过IP地址可以计算得出。

    最后,为了最小化延迟,我们使用管线的方式通过TCP协议进行数据的传输。当一个chunksever收到数据后,将马上开始向前推送。由于使用交换网络(只有交换机的网络),发送data将不会降低接受data的速度。

2.3原子性的Record Appends操作

    GFS提供了一个具有原子性的添加操作,称之为record append. 
    传统的write操作有用户决定文件偏移量,因此,在出现同时对相同文件区域进行写操作的时候,区域里会散乱着来自不同client的data fragment。而record append中,client只提供data,由GFS选择与返回偏移量给client。Clients需要实现附加而昂贵的同步性,比如通过一个分布式锁的管理,如果选择使用传统的write操作。

    而record append只需要在primary上添加少量额外的逻辑实现,如2.1所讲的。
     primary会检查需要append进某chunk的的record是否会导致这个chunk超过最大体积(64MB)。如果超过,则将现在的chunk直接填满(pad),并把record的内容记录到另外一个chunk中,然后告诉client需要从新对下一个chunk进行修改操作。

    GFS不保证所有的replicas的每个bety都相同,因为当操作失败,client将会retry操作,则data可能包括了不同的duplicates。GFS是保证data都是原子性的被写入至少一次,并且data在每个replicas的文件偏移量都是相同的。另外,每个replicas至少和一个record的结束一样长(???)。通过这套机制,保证了GFS的一致性,并且通过应用程序可以解决中间的少量非一致性(在2.7.2说明)

【Furthermore,after this, all replicas are at least as long as the end of record】

2.4 Snapshot

    Snapshot操作可以使拷贝文件或directory tree(目录树)在几乎一瞬间完成,同时最小化正在进行的mutation而产生的interruption。用户经常用它来在实验性操作之前快速创建超大文件的分支拷贝或创建checkpoint。

    当client发送snapshot请求时,Master首先将对应的primary上现有的leases撤回,保证接下来的write请求都要向Master询问primary位置,这可以给master一个机会去进行复制操作。

    撤销leases后,master将会将snapshot operations记录到本地磁盘上,然后在in-memory的状态通过复写源文件的metadata的方式,执行日志上的操作。(相当于,把这次snapshot操作日志保存在磁盘,然后将其导入内存以便执行,执行的过程是:在内存中复制一份对应的metadata)。新创建的snapshot文件(应该是复制后新得到的metadata)也指向相同的chunks。(相当于这里还没有创建chunk的copy,只创建了一个新的一套metadata指向原来的chunk)

    在snapshot操作以后,client第一次对这个chunk(加入是chunk C)请求写操作(这里可以理解为client希望进行一个实验)。Master会发现参考到的可作为primary的chunk C不止一个(因为有两个metadata指向相同的一个chunks)。则Master会推迟client的请求并马上选择一个新的chunk hendle C‘返回给clients,然后询问每个现在拥有C的replicas的chunksever创建一个名 为C’的chunk。(则!!!!!Client的操作实际上是对C’进行操作,而不是之前要求的C,但是client并不知道,而之前在master上两份指向C的metadata可以理解为只是为了对现在chunk C的状态做标记)

    以上机制的优点在于,不是通过网络,而是通过本地磁盘进行复制操作,延迟更低快速。

三. Master的操作

    Master执行者所有关于namespace的操作。凌海好负责管理chunk replicas:位置决定,创建chunks和reolicas,协调系统级操作,保证chunk被完整的replicated,平衡chunksevers的工作量,回收不用的内存资源。

3.1Namespace管理与锁

    GFS允许master operation的并行操作,并使用在namespace上的lock机制确保合理的一致性。
    GFS和传统文件系统不同,不通过目录结构保持文件列表,也不支持文件的别名(aliases)或directory。GFS通过一张查找表(lookup table)记录文件的pathnames和metadata,并通过前缀压缩(prefic compression),这张表格可以很轻易的在内存中存储并表达。每个在namespae tree上的节点都关联了读写锁(read-write look)

读写锁的工作原理与实例:
    假如需要对d1/d2/d3/…/dn/leaf进行写操作,则master operation需要获得d1;d1/d2;d1/d2/d3;…;d1/d2/d3/…/dn的read lock以及d1/d2/d3/…/dn/leaf的write lock才能进行操作。要注意的是leaf可能是一个文件也有可能是一个目录。

    现在我们通过实例来演示这套lock机制如何在/home/user在被进行snapshot到/save/user时,防止/home/user/foo的创建。

进行snapshot时需要得到:
    /home和/save 的 read lock
    /home/user和/save/user 的 write lock
    进行创建/home/user/foo时需要得到的:
    /home 的 read lock
    /home/user 的 read lock
    /home/user/foo 的 wirte lock

    则对于目录/home/user,两个操作获取的lock的种类不一样,则需要按照顺序依次进行操作。
    则这里可以得到一个理解:GFS的锁机制支持多个master operation同时操作文件,但必须保证该操作的锁与其他同时进行的操作所获取的锁相同,当对于某个目录或文件的锁的需求种类不同时,不能同时进行操作。

    比如,GFS允许在同一个目录下同时创建文件,同时进行mutation操作,而在mutation操作时,操作时的的read lock可以防止正在操作文件的上级目录同时的删除,重命名,或snapshot操作。
    另外,在文件名上的wirte locks将按顺序的分配 多次创建同名文件的请求。

3.2 replica的位置分配(placement)

    一个GFS的集群是一个高度分布的系统。这些chunksevers可能包括上百个clients,来自相同或不同的机架(相当于一个机器集群)。另外,在一个架子内外机器的带宽可能比在架子中的所有机器带宽的总和更小。(这里可能是说在一个rack中的机器之间相互通信会更快,拥有更大的带宽)多层结构的分布架构让对分布式数据的scalability,reliability and availability 都存在挑战。

    The chunk replica placement policy 旨在完成两个具体目的:
(1)maximize data reliability and availability
(2)maximize network bandwidth utilization

    为了完成这两个目的,把replica简单的分散到不同的机器上是不够的。为了保证reliability,我们需要保证一些replica分散在不同的racks上,来防止整个rack的瘫痪或脱机的情况(比如链接这个rack的swicher脱机等情况)。因此,ranks之间的带宽也可以得到利用和开发。


    Master在创建chunk时决定创建其空的replicas的位置所考虑的因素有三个:
    1. 选择一个次磁盘使用率比平均使用率低的chunksever
    2. 尽量减少每个chunksever现在的creation操作
    3. 我们希望把replicas散布到不同的racks上

    当replicas的数量低于于用户需求的数量时,Master将会进行re-replicate操作。原因有很多,比如:一个chunksever宕机了,或者replicas的需求增加等。

    对于需要进行re-replicate的chunk的优先度基于几个因素,比如:丢失两个replicas的chunks优先度大于丢失了一个的chunk。此外,我们更加重视活跃的文件。最后,我们将给予那些丢失便会阻碍client程序运行的chunk极大的优先度。

    为了避免colne所使用的traffic过度占用client traffic,Master会限制clone操作的数量。此外,chunksever也会通过压制源chunsever的read request(因为要把replicas复制到现在的选定的chunksever上,源chunksever必须对选定chunksever发送read request)限制colone操作所使用的带宽。

    最后,master会用周期性的对replicas进行rebalace操作:master检测现在的replicas分布并移动部分replica,让系统处于一个更好的磁盘空间和工作量平衡。Master通过这样一个方法让一个chunsever慢慢的填满而不是瞬间被大量新的chunk挤爆,然后承受非常大的工作量。另外,master还会选择一些replicas进行删除。一般情况下会选择空闲率在平均以下的chunksever上的replica。

3.4 垃圾收集

    文件删除以后,GFS不会马上重置可用的物理存储空间。GFS只会懒惰的(lazily)在常规的chunk级别的垃圾收集时候进行重置物理空间。这会让整个系统更加简单和可靠。

3.4.1垃圾收集机制

    当文件在GFS被删除,GFS会将文件rename成一个隐藏名(hidden name),并打上删除时间戳(deletion timestamp)。在系统的常规扫描时,系统将会重置删除时间戳超过三天的文件。(间隔时间可设置)在此之前,被删除的文件都可以通过重命名和删除时间戳的方式恢复。另外,文件被彻底删除,它的命名空间和metadata将会从master的内存中删除。

    Master在常规的命名空间扫描(通过chunk-to-file mapping的扫描)时就能发现哪些孤儿chunk(orphaned chunk)【这里指那些,其中没有可以获得的file的chunk,没有用的chunk】,并删除他的命名空间和metadata。在heartbeat信息中,chunksever会报告给master自己现在拥有哪些chunks,master在回复中会告诉chunsevers已经不存在的chunk,chunksever可以随意删除这replicas和chunks。

3.4.2 discussion(garbage collection机制的优势与不足)

优势:
        1. 在组件错误频繁的大型分布式系统中简单且值得信赖。可以有效解决创建chunk错误时产生的未知replicas。
        2. 将存储空间重置的任务和master的常规性动作结合,可以分流该动作的工作量,也可以在master空闲时完成。
        3. 提供了一个稳定的意外删除解决网络。

    不足:有时候由于存储空间紧张导致的延迟会阻碍用户微调操作。对于需要频繁创建和删除文件的应用,可能无法对存储空间进行马上重用。导致存储空间的浪费

    解决方案:可以加速确认删除的动作,另外用户可以自定义在某个命名空间下的chunk可以立即删除(不留hidden file)等方式。

3.5过期replica的删除

    当replica错过mutations操作时,则可能成为过期(stale)的replicas。GFS利用chunk version number来标志和发现过期的replica。

    当master授权给一个新lease给chunk,master会同时附加一个新的chunk version number 同时通知所有up-to-date的replicas。这个操作会安排在所有client的写操作前。当有一个replicas因为某种原因无法获取,则他的version number是过期的。Master会在这个chunksever重启后检测到这个过期的replica并用垃圾收集机制删除。此外,安全起见,在master在要求chunksever在clone动作中read另外一个chunksever时,也会更新version number。

四. 容错性(Fault Tolerance)和诊断(Diagnosis)

4.1High avaliabilty

    在GFS里成百上千的服务器中,必行有一些会因为某些原因在需要的时候无法获取(unavailable)。GFS利用两个简单而高效的方法保证系统的可读取性:快速恢复(fast recovery)和副本(replication)

4.1.1快速修复

    Master和chunkserver都被设计成能在开机后几秒内恢复自己的状态,无论是怎样被关闭的。实际上,GFS在被设计时没有考虑是正常关闭还是非正常关闭。

4.1.2chunk replication

    就像之前提到的chunk replication,这个机制很好的完善了系统的可获取新和容错性。此外,系统中还添加了部一些保证性的代码,来完善日益提高的read-only存储需求。

4.1.3master replication

    Master的操作日志和checkpoints被复制在多台电脑机器上。一个mutation操作只有在所有包括本的的replicas都被修改后,才被认为是已提交(committed)。
    简单性起见,一个master进程负责维持的操作,包括所有mutation,后台操作,比如垃圾收集等改变系统内在环境的操作,在master出现错误后,可以几乎马上从新启动。如果是因为机器或磁盘的损坏导致的失败,设置在GFS外的检测设备(monitoring infrastructure)会从通过作为副本的operation log新启动一个新的master进程,这时的Client只能通过临时的Master名字(如,master-test),从DNS服务器中获取临时Master的地址。

    此外,”shadow“ Master(真正的master宕机后,系统外设备启动的临时master只作为应急使用,而非代替,姑且称之为”shadow“)使用时,系统处于read-only的状态。而由于Master只是shadow状态而非mirror,则浏览到的版本可能不是最新的版本(几秒钟前的)。

    而实际上,由于文件是在chunksever上被读取,实际上用户读取到的文件内容并非过时的,过时的是文件对应的metadata,比如目录内容或控制信息等。

4.2数据完整性

    每个chunksever会利用验证码来检测文件的破损。利用对比replica的方法进行错误侦测是不明智的。另外,哪怕出现背趋的(divergent)replicas也可能是合法的。因为mutation操作语义上的原子性会让某些replica更加早的被修改。因此每个chunkserver一定要能独立的完成对自身检测文件的完整性。

    每个64MB的chunk都有一个与之对应的32bit每次验证码。验证码都存放在memory中。没一次read操作,chunksever都会对请求范围内的chunks进行验证。如果chunks中出现错误,则先回复请求放请求错误,然后给master报告错误的信息。这时请求方会请求另外的replica,master会从别的replica克隆一份chunk。当新的正确的chunk到位后,master会要求报告错误信息的chunksever删除那个错误的replicas。

    上面的机制可以最大程度减少错误对read操作的影响,另外client代码尽可能的减少集中的验证,而只对read操作边缘的chunk进行验证。此外,该套机制的另一优点在于整个验证过程不产生I/O操作。

    对于write操作,append record的模式大大的优化了数据完整性在write操作上实现的(而不是overwrite模式)。 GFS只会增量的去对最新被append的部分chunk进行更新,然后计算新的checksum。即使最新的checksum部分的数据已经损坏而GFS又没有马上检测出来,新的checksum值与现在的内容不匹配,也会在下一次read操作中被检测到。(在write操之前应该也要对最新的chunk进行检测,在做append操作)

    在空闲的时间,chunkserver可以扫描和检测那些不活跃的chunks,这样可以保证我们检测出那些很少被读取的chunks。这可以防止不活跃但损坏的chunks导致master误判系统中还拥有足够正的replicas的现象。

4.3 诊断工具

    附加的详细诊断日志是强有力的错误诊断,修复以及行为分析工具,这只需要使用极少的资源。GFS用诊断日志记录下许多重要的事件(比如chunksever的宕机与启动修复等)以及所有的RPC请求和回复。

诊断日志可以随意删除,但是为了安全起见,我们尽可能的将其备份到约远越好的空间。

    RPC日志除了读写要求外,还包括详细的请求和回复。通过核对不同机器间的回复请求与RPC记录,我们可以重构整个交互流程并诊断错误。日志也作为线索用于承载测试(loading test)或行为分析(performance analysis)。

    日志的记录对其他操作的影响是很小的(远小于其带来的好处),因为记录日志是时段性的的和异步的。最当前的任务仍然保持在内存中,并持续的检测。

五. 宏观的基准

5.1实验基准

谷歌提供的测试环境和设备:
16台chunksevers
16个clients
1个master2个master replicas
主机配置:
双核1.4GHz PIII处理器
2GB内存
2*80G5400rpm硬盘
网络与设备:
100Mbps 以太网连接
HP 2524 switch
19台sever连接在一台switch
另外16台client连载另一台switch
两个switch为1Gbps的连接

5.1.1 read

    N个client同时随机从指定320G的文件集合中选择4MB的区域并重复256次。所有的chunksevers一共只有32G内存。因此整个访问过程的内存hit rate(就是访问的内容正好在内存里)最多10%。结果呈现更倾向于冷缓存(cold cache)情况下
结果如下:
    设备支持的最高总速度:
    两台switch之间125MB/s(100Mbps)
    每个client 12.5MB/s(100Mbps)

    实际观测速度:
    当只有一个lient进行读取时,平均10MB/s(80%)
    总速度94MB/s(125MB/s的75%)
    从80%掉刀75%的原因是多个clients可能会从同一个chunksever同时读取。

5.1.2 write

    N个clients通过一系列1MB的写入,每个client写1GB的内容
    极限平台(limit plateaus)为67MB/s( 理论最大速度)
    速度慢的原因:因为每个byte需要写三次(写到不同的chunksever),而chunksever之间只有100Mpbs的以太网连接。
    每一个clients的最大速度为6.3MB/s,约顶峰(网络最大速度)的一半。
    最大的阻碍是用于将chunks复制出replicas的管线的安排(pipelining scheme)从一个sever到另一个sever的replicas传播所产生的延迟成为了最大的速度阻碍。此外,写操作对比读操作更有可能多个client在同时操作同一个chunksever的文件

    实际的总速度35MB/s(16个clients,每个client2.2MB/s),总速度的一半。而实际上,即使每个client的潜伏阻碍更大,总的写操作带宽是不变的,在保持每个用户的写速度的同时可以支持更的用户。

5.1.3 append record

    性能限制主要来自那些存放着最新的chunk文件的chunksevers的带宽,而不是取决于clients的数量。
    一个client速度达6MB/s,而16个client下降到4.8MB/s,主要由于网络传输的复杂情况和拥挤。而这不是很严重的问题,clients可以通过优化程序使得当一个chunksever忙碌时写另外一个文件。

    其他仿真实验的各项结果和工作量承情况就不进行记录。
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:4260次
    • 积分:84
    • 等级:
    • 排名:千里之外
    • 原创:3篇
    • 转载:5篇
    • 译文:0篇
    • 评论:0条
    文章分类