关于分布式:MIT6824分布式系统课程-翻译学习笔记三GFS

阐明

本系列文章是对赫赫有名的 MIT6.824 分布式系统课程 的翻译补充和学习总结，算是本人一边学习一边记录了。

如有疏漏谬误，还请斧正：）

继续更新 ing。。。

翻译 & 补充

论文

The Google File System
Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
SOSP 2003

为什么咱们须要读这篇论文？

分布式存储是很重要的概念

• 接口 / 语义 应该是什么样子的？
• 外部是如何工作的？

GFS 论文笼罩了 6.824 中的很多主题：并行，容错，复制，一致性
良好的零碎论文——细节从利用始终到网络都笼罩到
胜利的理论利用的设计

为什么分布式存储很难？

高性能 –> 多台机器间数据分片
多台服务器 –> 常常出错
容错 –> 复制
复制 –> 不统一
更好地一致性 –> 低性能

对于一致性，应该怎么解决？

现实的模型：和一台服务器一样的行为表现
服务器应用硬盘存储
服务器在同一时刻只执行一条客户的操作（即使是并发的）
读之前所写，即使服务器解体或重启
因而：假如 C1 和 C2 并发地写，等到写操作结束，C3 和 C4 读。它们会取得什么？
C1: Wx1
C2: Wx2
C3: —- Rx?
C4: ——– Rx?
答复：1 或者 2，然而 C3 和 C4 会看到雷同的值。
这是一个“强”一致性的模型。
然而一台独自的服务器容错性很差。

为了容错的复制，很难实现强一致性

一个简略，但有问题的复制计划：

• 两个复制的服务器，S1 和 S2
• 多个客户端向两台服务器，并行发送写申请
• 多个客户端向其中一台，发送读申请

在咱们的示例中，C1 和 C2 的写申请可能会以不同的程序达到两台服务器

• 如果 C3 从 S1 读取，可能会看到 x =1
• 如果 C4 从 S2 读取，可能会看到 x =2

或者如果 S1 承受了一个读申请，然而在发送写申请到 S2 时，客户端解体了，会怎么样？
这不是强一致性！
更好的一致性通常须要通信，来保障复制集的统一 —— 会很慢！
性能和一致性之间须要衡量很多，当前会看到

GFS

内容：

很多谷歌的服务须要大型疾速的对立文件存储系统，比方：Mapreduce，爬虫 / 索引，日志存储 / 剖析，Youtube（？）
全局来看（对于一个独自的数据中心）：任何一个客户端能够读取任意文件，容许多个利用之间共享数据
在多个服务器 / 硬盘上自动化“切片”每个文件，晋升并行的性能，减少空间可用度
谬误的主动复原
每次部署只有一个数据中心
只有谷歌的利用和用户
旨在大文件的的程序操作；读或者追加。不是存储小数据的低提早 DB

在 2003 年有什么翻新点？他们是怎么被 SOSP 承受？

不是分布式、分区、容错这些根本的思维
大规模
在工业界的理论利用教训
弱一致性的胜利案例
独自 master 的胜利案例

架构总览

客户端（库，RPC —— 但不像 Unix 文件系统那样可见）
每个文件切分为独立的 64MB 的数据块
数据块服务器，每个数据块复制 3 份
每个文件的数据块们散布在多个数据块服务器上，用于并行读写（比方，MapReduce），并且容许大文件只有一个 master（！），master 也会复制
工作的划分：master 负责写名称，数据块服务器负责写数据

Master 的状态

在 RAM 中（速度，应该是有点小的）：

在硬盘上：

• 日志
• 检查点

为什么有日志和检查点？

为什么是大的数据块？

当客户端 C 想要读数据，是什么步骤？

1. C 发送文件名和偏移量到 master M（如果没有缓存的话）
2. M 找到这个偏移量的数据块 handle
3. M 回复最新版本的数据块服务器的列表
4. C 缓存 handle 和数据块服务器列表
5. C 发送申请到最近的数据块服务器，包含数据块 handle 和偏移量
6. 数据块服务器从硬盘上读取数据块文件，并返回

master 怎么晓得数据块服务器含有一个指定的数据块？

当 C 想要在记录后追加，是什么步骤？

论文的图 2

1. C 询问 M 文件的最初一个数据块
2. 如果 M 发现数据块没有主记录（或者租约过期）
   2a. 如果没有写数据块服务器的最新版本，谬误
   2b. 从最新的版本中抉择主节点和备份节点
   2c. 版本号减少，写到硬盘的日志上
   2d. 通知主记录和备份的记录他们是谁，以及新版本
   2e. 在硬盘上复制地写入新版本
3. M 通知 C 主记录和备份记录
4. C 向全副发送数据（只是临时的。。。），并期待
5. C 通知 P 须要追加
6. P 查看租约是否过期，数据块是否有空间
7. P 确定偏移量（数据块的完结）
8. P 写数据块文件（一个 Linux 文件）
9. P 通知所有备份节点偏移量，通知它们须要追加到数据块文件
10. P 期待所有备份节点的回复，超时则为谬误，例如：硬盘空间有余
11. P 通知 C ok 或谬误
12. 如果出错，C 从头重试

GFS 提供给客户端的是什么样的一致性保障

须要通知利用以某种模式应用 GFS。

这是一种可能性：

如果主节点通知客户端一条记录胜利追加，则所有的读者随后关上这个文件，都能够看到追加的记录。
（然而并非失败的追加就不可见，或者说，所有的读者都会看到雷同的文件内容，雷同程序的记录）

咱们怎么晓得 GFS 是否实现了这些保障？

看它对不同种谬误的解决形式：解体，解体 + 重启，解体 + 代替，信息失落，分区。
请想一想 GFS 是怎么保障要害个性的。

* 一个追加的客户端在不适合的时刻失败了，怎么办？

有没有不适合的时刻存在？

* 一个追加客户端缓存了一个过期的（谬误的）主节点，怎么办？

* 一个读的客户端缓存了一个过期的备份节点列表，怎么办？

* 一个主节点解体 + 重启，会导致文件的失落吗？

或者遗记哪些数据块服务器存储指定的数据块？

* 两个客户端在同一时间进行记录追加。

他们会笼罩彼此的记录吗？

* 主节点在向所有备份节点发送追加申请时，主节点解体，会怎么样？

如果一个备份节点没有看到追加申请，会被选为新的主节点吗？

* 数据块服务器 S4 存储旧的过期的数据块备份，是离线的。

主节点和其余存活的备份节点都解体。
S4 复活（在主节点和备份节点之前）。
master 会抉择 S4（蕴含过期数据块）作为主节点吗？
是抉择含有过期数据的节点作为左节点适合，还是抉择没有备份的节点？

* 如果备份节点总是写入失败，主节点应该怎么做？

比方，死机，硬盘空间有余，或硬盘故障。
主节点应该从备份节点列表中抛弃该节点吗？
而后向追加记录的客户端返回胜利？
或者主节点始终发送申请，认为申请都失败，
给客户端的每个写入申请都返回失败？

* 如果主节点 S1 是沉闷的，服务于客户端的申请，然而 master 和 S1 之间的网络不通？

“网络分区”。
master 会抉择一个新的主节点吗？
这时候会存在两个主节点吗？
如果追加申请发送给一个主节点，读申请发送给另一个，是否突破了一致性的保障呢？
“脑裂”

* 如果有一个分区的主节点在解决服务端的追加申请，然而它的租约到期了，master 抉择了一个新的主节点，这个新的主节点会有之前主节点解决的最新的数据吗？

* 如果 master 失败会怎么样？

替换后的 master 晓得之前 master 的所有信息吗？
比方，每个数据块的版本号？主节点？租约过期工夫？

* 谁判断 master 是否死机且须要被替换？

master 的备份会 ping master 吗？如果没有回应则接替它？

* 如果整个环境断电了，会怎么样？

如果电力复原，所有的机器会重启，会怎么？

* 假如 master 想要创立一个新的数据块备份。

可能因为备份太少了。
如果它是文件的最初一个数据块，正在被追加。
新的备份怎么保障没有谬误追加？毕竟它还不是一个备份节点。

* 存不存在一个场景，会突破 GFS 的保障？

例如，追加胜利，然而随后的读者没有看到这条记录。
所有 master 的备份永恒地失落状态信息（永恒硬盘谬误）。可能更早：后果会是没有答复，而不是谬误的数据。“故障 - 进行”
某个数据块的所有数据块服务器失落硬盘文件。又是，“故障 - 进行”；并不是最坏的后果
CPU，RAM，网络或硬盘呈现一个谬误值。校验和会查看出一些状况，但不是全副
时钟没有正确地同步，所以租约没有失常工作。所以，会存在多个主节点，可能写申请在一个节点上，读申请在另一个节点上。

GFS 容许哪些利用的不标准行为？

所有的客户端都会看到一样的文件内容吗？会不会一个客户端能够看见一条记录，然而其余客户端看不见？一个客户端读取文件两次是看见雷同的内容吗？
所有的客户端都能够看到雷同程序的追加记录吗？

这些不标准行为会为利用带来麻烦吗？

比方 MapReduce？

怎么样能力没有异样 —— 强一致性？

例如，所有的客户端看到雷同的文件内容。
很难给出一个实在的解答，不过有一些注意事项。

• 主节点该当检测反复的客户端写申请。或者客户端不该当发送这种申请。
• 所有的备份节点应该实现每个写操作，或者全副不实现。或者先暂定写入，直到所有节点确定再实现写入。只有所有节点批准实现才进行写入操作！
• 如果主节点解体，一些备份节点会谬误最初一部分操作。新的主节点会和所有的备份节点通信，找出最近的所有操作，并同步给其余备份节点。
• 防止客户端从过期的前备份节点读取，或者所有的节点必须与主节点通信，或者所有的备份节点该当也有租约。

你们会在试验 3 和 4 看到这些内容！

性能（图表 3）

读的大量聚合吞吐（3 个复制集，拆开）

• 16 个数据服务器，总共 94MB/s 或者每个数据块服务器 6MB/s，这样不错吧？一个硬盘的程序吞吐量大概为 30MB/s，一个网卡的大概在 10MB/s
• 靠近网络饱和（交换机链路）
• 所以：独自服务器的性能是低的，然而扩展性不错。那一个更重要？
• 表格 3 展现了 GFS 产品 500MB/s，是很高的

不同文件的写是比可能的最大值要低，作者认为是网络的影响（然而没有具体阐明）
单个文件的并发追加，受限于存储最初一个数据块的服务器
15 年后难以预料，例如，硬盘的速度有多快？

一些须要思考的问题

怎么样可能良好地反对小文件？
怎么样能良好地反对千万级别的文件？
GFS 能够成为宽泛应用的文件系统吗？在不同的城市有备份？在同一个数据中心有多个备份，容错性不高！
GFS 从谬误复原须要多久？一个主节点 / 备份节点的谬误须要多久？master 的谬误呢？
GFS 怎么应答迟缓的数据块服务器？

与 GFS 工程师的回顾性对话：

文件数目是最大的问题

• 最终的数目是图表 2 的 1000 倍
• 在 master 的内存中存储不下
• master 垃圾回收时，扫描所有的文件和数据块，很慢

千级别的客户数量会给 master 的 CPU 带来很大的压力
利用须要以合乎 GFS 语义和限度的形式进行设计
master 的故障复原最后是齐全人工实现，须要 10 分钟左右
BigTable 是多个小文件的解决方案，Colossus 能够在多台 master 上分片 master 数据

总结

性能，容错，一致性的案例钻研，为 MapReduce 利用定制
好的想法：

• 全局的文件集群零碎作为一个基础设施
• 将命名（master）和存储（数据块服务器）拆散
• 并行吞吐的分片
• 大的文件 / 数据块，升高开销
• 主节点用于程序写
• 租约，为了避免数据块服务器的主节点脑裂

有余的中央：
单个 master 的性能，耗尽内存和 CPU
数据块服务器对于小文件并不高效
master 没有主动的故障切换
或者一致性还是比拟弱