Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lec3:GFS #6

Open
chaozh opened this issue Apr 17, 2017 · 3 comments
Open

Lec3:GFS #6

chaozh opened this issue Apr 17, 2017 · 3 comments
Labels

Comments

@chaozh
Copy link
Owner

chaozh commented Apr 17, 2017

课前阅读论文:GFS(2003)
讲义:英文
FAQ:英文

参考:

  1. GFS演化
  2. GFS2.0版本

本期问题(请大家在本issue中直接回答):请描述客户端从GFS读数据的大致流程?

@chaozh
Copy link
Owner Author

chaozh commented Apr 18, 2017

GFS是Google在2003年发出的经典论文,其作为分布式文件系统实际应用在Google的MapReduce框架实现中作为原始数据和最终结果存储的基础服务,同时为其他上层基础系统比如BigTable提供服务。Hadoop中的HDFS就是其开源实现。这篇文章讨论了诸如一致性、容错、网络性能等分布式系统工程中的经典问题,启发了后续很多分布式文件系统的发展。

一致性是分布式系统中最关键的问题,基本所有分布式系统都必须讨论这个问题。强一致性可以保证读到最新的写信息,但是对性能肯定会造成影响,好的系统设计就是在这两点中进行平衡。分布式文件系统需要达成的“理想的“一致性就是多节点上面操作文件表现跟本地文件系统一样。特别是应用通过不同机器上文件系统的客户端访问同一个磁盘或文件。这就需要解决三个问题:并发访问、机器节点失效、网络故障,特别是网络通信的不可靠会让完整的协议特别复杂,同时节点间通信也会让性能受损。比如GFS中机器损坏节点失效就是常见的(每天1000台机器中至少3台失效),而且经常会并发进行读写操作,因此系统设计必须考虑解决这三个重点问题。

GFS为应用提供了读写接口(仅支持追加写操作,且仅提供API并未实现文件系统底层POSIX接口),也提供了目录和文件的分层结构。数据存储在超过100台的数据节点上,文件按64MB进行分块,每个数据块都有三个备份分布在不同数据节点上,提高容错性的同时,加速并行写,并增加提供读服务能力的节点。master节点负责维护文件的层级结构(包括目录中有哪些文件,文件里哪些块在哪个数据节点上),这些数据都存在内存中并使用私有数据库组织,保证掉电后可以快速恢复。会有一个冷备份的master节点随时准备顶替提供服务。

@chaozh
Copy link
Owner Author

chaozh commented Apr 21, 2017

具体流程这边就不详述,基本就是先联系master活动获得文件分布信息,再联系相应数据节点进行操作。客户端会缓存文件分布信息(但是不会缓存文件数据,MapReduce没有必要缓存,BigTable则自己内部实现一套缓存)和对应文件版本ver.(和租约机制及垃圾回收配合,保证错误处理)。另外一个优化是追加写操作时客户端会跟主数据节点通信,写过程也是流水线化的。

对于“理想”一致性维护,目录级别是可以实现的,但是文件操作就不一定了,需要实现原子性的追加写操作(GFS支持多客户端并发追加,更加复杂),涉及到网络造成的重复指令(使用UID即可防止)、节点操作变更失败(租约机制,允许部分读成功即可防止)等。

GFS经典的设计在于:

  1. 文件元数据与数据流的分离;
  2. 数据流的并行与流水化;
  3. 数据的备份与容错;
  4. 考虑数据分布的负载均衡;
  5. 简化一致性模型;(没有实现原子性追加写,也是缺陷!)

工程实现方面的优点:

  1. 租约方式,将修改授权从master下放到数据节点;
  2. 支持写时复制的元数据管理,支持快照操作(B树实现);
  3. 实现数据的垃圾回收机制;

缺陷在于:

  1. master节点仍然单点不能多活;
  2. 小文件的处理;
  3. 客户端读取数据可能小错误;

@chaozh
Copy link
Owner Author

chaozh commented Apr 22, 2017

如果可以回答下列问题,则说明基本理解本文章

1)为什么存储三个副本?而不是两个或者四个?

2)Chunk的大小为何选择64MB?这个选择主要基于哪些考虑?

3)GFS主要支持追加(append)、改写(overwrite)操作比较少。为什么这样设计?如何基于一个仅支持追加操作的文件系统构建分布式表格系统Bigtable?

4)为什么要将数据流和控制流分开?如果不分开,如何实现追加流程?

5)GFS有时会出现重复记录或者补零记录(padding),为什么?

6)租约(Lease)是什么?在GFS起什么作用?它与心跳(heartbeat)有何区别?

7)GFS追加操作过程中如果备副本(Secondary)出现故障,如何处理?如果主副本(Primary)出现故障,如何处理?

8)GFS Master需要存储哪些信息?Master数据结构如何设计?

9)假设服务一千万个文件,每个文件1GB,Master中存储的元数据大概占用多少内存?

10)Master如何实现高可用性?

11)负载的影响因素有哪些?如何计算一台机器的负载值?

12)Master新建chunk时如何选择ChunkServer?如果新机器上线,负载值特别低,如何避免其他ChunkServer同时往这台机器迁移chunk?

13)如果某台ChunkServer报废,GFS如何处理?

14)如果ChunkServer下线后过一会重新上线,GFS如何处理?

15)如何实现分布式文件系统的快照操作?

16)ChunkServer数据结构如何设计?

17)磁盘可能出现“位翻转”错误,ChunkServer如何应对?

18)ChunkServer重启后可能有一些过期的chunk,Master如何能够发现?

来自《大规模分布式存储系统》

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant