找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 6625|回复: 3
收起左侧

我的<读GFS论文总结>

[复制链接]

5

主题

2

精华

41

积分

新米人

Rank: 1

积分
41
发表于 3-24-2016 09:12 AM | 显示全部楼层 |阅读模式

亲!马上注册或者登录会查看更多内容!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
读GFS论文心得 - 杂记
1) 设计要点:RSA: scalability, reliability, availability and performance
1. 错误是常态。 component failures are the norm rather than the exception
2. Files are huge. Multi-GB are common
3. Files are mutated by appending rather than over-writing。
为什么 append 优于overwrite?
- 基于大文件访问的方式,append便于性能优化和原子操作
- 这样在client端caching data block就没有太大的意义
4. application and fs API 协同设计
        * 采用弱一致性(relaxed consistency)的设计来简化文件系统,比如文件的同步
        * atomic append operation. 多客户端可以并发atomic append, 不需要额外的同步设计。

2) GFS design overview
2.1 设计的假设前提:
        1. 采用廉价硬件
        2. 大量文件. a few million files each typical 100MB or larger. 支持小文件,但不对小文件额外优化
        3. read: large streaming reads - 大块顺序读
                 and small random reads. - 小块随机读
        4. write :sequential writes(append)  -
                                small write - not efficient
        5. multiple clients 并发写(append to the same file)
           - multiple producers and one consumer
        6. High sustained bandwidth is more important than low latency.
           大部分应用对latency要求不高,而是更加要求数据批量处理的能力
2.2 接口设计
  × 不支持POSIX,但支持常用的文件系统接口 create, delete, open, close, read, write
  × 支持snapshot
  * 支持record append. record append 支持multi-clients 对同一文件并发append, 每次append保证原子性

2.3 架构设计
一句话: single master + multiple chunk servers.
        文件分成若干fixed size(64M)的chunk, 每个chunk 用一个64bit的chunk handle 来标记。
        Master 包含 metadata
        检测each chunkserver的heartbeat
       
        client实现文件系统的API 接口,并和master和chunk server 通信, 但数据读写只和chunkserver打交道。Master像一个小秘书一样,为client提供数据传输必要的信息,比如file对应的chunk分布在哪里。
single master 的设计来简化系统设计的复杂性,
READ - 一个简单的读流程:
        a) 应用程序指定filename 和offset, client翻译成对应的chunk index
        b) client询问master,这个chunk index在哪里
        c) master 回应client the chunk handle 和对应副本(replica)的locations
        d) client发送请求到其中一个最近的replica, 每次请求指定chunk handle 和 byte range
       
Chunk size:
        * 64M per chunk. large chunk的好处是减少client和master的交互,同一个chunk内访问只需要一次master query
        * 1个chunk就是一个linux 文件

OVERWRITE       
        1) client向master询问拥有这个chunk的lease的primary replica,如果当前没有primary replica, master把lease给其中的replica
        2) master把primary replica的位置和其他的拥有这个chunk的replica的chunkserver(secondary replica)的位置返回, client缓存这个信息。
        3) client把数据以流水线的方式发送到所有的replica,流水线是一种最高效利用的带宽的方法, 每一个replica把数据用LRU buffer保存起来,并向client发送接受到的信息。
        4) client向primary replica发送write请求,primary replica根据请求的顺序赋予一个序列号
        5) primary replica根据序列号修改replica和请求其他的secondary replica修改replica, 这个统一的序列号保证了所有的replica都是按照统一的顺序来执行修改操作。
        6) 当所有的secondary replica修改完成之后,返回修改完成的信号给primary replica
        7) primary replica向client返回修改完成的信号,如果有任何的secondary replica修改失败, 信息也会被发给client,client然后重新尝试修改,重新执行步骤3-7。
如果一个修改很大或者到了chuck的边界,那么client会把它分成两个写操作, 这样就有可能发生在两个写操作之间有其他的写操作,所以这时会出现undefined的情况。

Snapshot

Snapshot是对文件或者一个目录的“快照”操作,快速地复制一个文件或者目录。 GFS使用Copy-on-Write实现snapshot,首先masterrevoke所有相关chunk的lease, 这样所有的修改文件的操作都需要和master联系, 然后复制相关的metadata,复制的文件跟原来的文件指向同样的chunck, 但是chuck的reference count大于1。

当有client需要写某个相关的chunck C时,master会发现它的reference count大于1, master推迟回复给client,先新建一个chunk handleC’, 然后让所有拥有C的replica的chunkserver在本地新建一个同样的C‘的replica, 然后赋予C’的一个replica一个lease,把C’返回给client用于修改。       
       

0

主题

0

精华

6

积分

新米人

Rank: 1

积分
6
发表于 3-24-2016 09:13 AM 来自美国米群网手机版 | 显示全部楼层
感谢Jerry_IVYL分享~~~
回复 支持 反对

使用道具 举报

0

主题

0

精华

12

积分

新米人

Rank: 1

积分
12
发表于 3-26-2016 08:43 AM 来自美国米群网手机版 | 显示全部楼层
感谢Jerry_IVYL分享~~~
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表