AWS-用于在 AWS 上进行构建的工具

Google文件系统

1 简介

1. 组件失效被认为是常态事件，而不是意外事件。
2. 文件非常巨大
3. 绝大部分文件的修改是采用在文件尾部追加数据，而不覆盖原有数据的方式。
4. 应用程序和文件系统API的协同设计提高了整个系统的灵活性

   放松了对一致性模型的要求，引入了原子性的记录追加操作，从而保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性。

2 设计概述

2.1 设计预期

组件失效是一种常态，系统必须持续监控自身的状态，能够迅速地侦测、冗余并恢复失效的组件。

系统的工作负载主要有两种操作组成：大规模的流式读取和小规模的随机读取。

2.2 接口

快照和记录追加操作

2.3 架构

一个单独的master节点，多台chunk服务器，同时被多个客户端访问

用户级别进程

GFS存储的文件被分割成固定大小的chunk，在chunk创建时，master服务器会给每个chuhnk分配一个不变的、全球唯一的64位chunk标识。

默认，3个存储复制节点

master节点管理所有的文件系统元数据，包括名字空间、访问控制信息、文件和chunk的英社信息，以及当前chunk的位置信息

master视同心跳监测状态

客户端和master节点的通信知乎求偶元数据，所有的数据操作都是由客户端直接和chunk服务器进行交互

无论是客户端还是chunk都不需要缓存文件数据

2.4 单一master节点

2.5 chunk尺寸

默认 64MB

绝大多数是满的，最后一个需要填充

2.6 元数据

master服务器存储3中主要类型的元数据

1. 文件和chunk的命名空间

2. 文件和chunk的对应关系

3. 每个chunk副本的存放地点

存放在master服务器的内存中，前两种同时以日志方式存储

保存的文件名用前缀压缩算法压缩

master不保存持久化chunk信息，启动时轮询chunk服务器，皇后通过心跳监控状态

收集多个日志后批量处理

灾难恢复时，通过重演操作日志

2.7 一致性模型

尽量采用追加写入而不是覆盖

3 系统交互

3.1 租约和变更顺序

变更会改变chunk内容或者元数据，会在所有副本上执行

使用租约lease机制俩保持多个副本见变更顺序的一致性

主节点对chunk的一个副本建立一个租约，这个副本叫做主chunk，主chunk对chunk的所有更改操作进行序列化吗，所有副本遵从这个序列进行修改

主chunk把写请求传递到所有的二级副本，每个二级副本依照主chunk分配的序列号以相同的顺序执行这些操作 -> 素哟偶的耳机复本回复主chunk，他们已经完成了操作

3.2 数据流

通过IP地址计算出节点的“距离”，数据已管道的方式顺序的沿着chunk服务链进行推送

3.3 原子的记录追加

3.4 快照

几乎瞬间完成对一个文件或者目录树的拷贝

并且几乎不会对恒在进行的其他操作造成任何干扰

1. 收到快照请求，取消所有的chunk租约，保证后续对chunk的写操作都必须与master交互

2. 把操作写入日志，复制，新创建的快找文件，和源文件指向完全相同的chunk地址

3. 快照操作之后，第一次写数据时，创建一个新的chunk句柄C·，要求每个拥有chunk C的副本在本地创建C·

4. 通过在本地复制而不是通过网络复制

4 master节点的操作

文件的读取锁防止父目录被删除

/d1/d2/…/dx 获取d1,d2…的读取锁

4.3

master创建一个chunk时，考虑因素：

1、平均硬盘使用率低的服务器创建副本

2、限制在每个chunk服务器上“最近”的chunk创建操作的次数

3、chunk副本分布在多个机架之间

5 容错和诊断

TODO

6 度量

TODO

7 经验

XXX

8 相关工作

XXX

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com