谷歌Colossus文件系统的设计经验

Colossus，巨人，谷歌第二代GFS文件系统。与GFS相比，Colossus相关的文章和信息却零星稀少。

2017年，谷歌首席工程师 Denis Serenyi 在 PDSW 2017 （第二届国际并行数据系统研讨会）上分享 《From GFS to Colossus : Cluster-Level Storage @ Google》，透露了Colossus设计的深层思考。

以下是我的翻译和解读。

从 GFS 到 Colossus：谷歌的集群存储，如何使用Colossus提高存储效率。

Colossus汲取了GFS的经验教训，正如在《Storage Architecture and Challenge》中所提及的GFS的不足。

基础知识:

• 谷歌的第一个集群级文件系统（2001）
• 为具有大文件的批处理应用程序设计
• 同时管理metadata和chunk的单一主程序
• 为了可靠性，chunk通常被复制3份

GFS教训:

• 扩展到大约50M文件，10个P
• 大量大文件增加了上游应用程序的复杂性
• 不适用于对延迟敏感的应用程序
• 扩展限制增加了管理开销

而Colossus则专注于存储效率的提升以及各种扩展功能。

谷歌数据中心内部示意图。

你怎么使用PB级的空闲磁盘空间?

你怎么使用PB级的空闲磁盘空间?

在紧急磁盘空间不足的情况下

典型的集群:

• 成千上万的机器
• PB级别分布式HDD
• 可选的TB级本地SSD
• 10 GB/S的对分带宽

第1部分：从GFS到Colossus的迁移

GFS架构问题

GFS master

• master节点机器不够大，不能容纳更大的文件系统
• metadata操作的单一瓶颈节点
• 可以容错，但不是高可用

可预测的性能

• 没有延迟保证

GFSv2的一些明显目标

• 更大!
• 更快!
• 可预测的尾部延迟
• 用Colossus取代GFS master节点
• 用D服务器取代GFS 的chunk server

注意：D（Disk的缩写）服务器，它相当于在Borg上运行的GFS Chunkserver。D构成了最低的存储层，并被设计为惟一可以直接读写存储在物理磁盘上的文件的应用程序，物理磁盘被连接到D所运行的机器上。在GFS中， master节点记录文件系统元数据，Chunkserver管理原始数据chunk的读写。与此类似，D服务器管理对原始数据的访问，而Colossus服务器管理哪些数据被映射到哪个D服务器上。Colossus客户端与Colossus对话，以确定从哪个D服务器读取/写入数据，然后直接与D服务器对话，以执行读取/写入操作。如下图所示。

一个简单的问题

Bigtable的“文件系统”

• 追加写
• 单一写（多个读）
• 没有快照和重命名
• 不需要目录

元数据放在哪里?

当时的存储选项

GFS

分片MySQL（本地磁盘和复制）

• 广告数据库

带有Paxos复制的本地键值存储

• Chubby

Bigtable （GFS上的键值排序存储）

当时的存储选项

GFS←缺少有用的数据库特性

MySQL分区←负载平衡差，复杂

本地键值存储←无法伸缩

Bigtable←hmmmmmm .... 见下一节

为什么选择Bigtable ?

Bigtable解决了许多难题：

• 在tablets之间自动分割数据
• 通过查询元数据定位tablets
• 易于使用的语义
• 高效的单点查找和扫描

文件系统元数据保存在内存本地组中。

元数据在Bigtable 中！？！？

GFS master -> CFS

CFS“curators”运行在Bigtable tablet服务

Bigtable的一行对应于一个文件

Stripes是一组复制集合：打开、关闭、结束

Colossus 存储元数据？

• 元数据大约是数据大小的1/10000
• 所以如果我们在Colossus上建造一个Colossus…
• 100PB数据→10TB元数据
• 10TB元数据→1GB元元数据
• 1GB元元数据→100KB元…

现在我们可以把它放进Chubby中!

第2部分：Colossus和高效存储

主题

• Colossus可以进行伸缩和集群划分
• 应用互补→更便宜的存储
• 数据放置，IO平衡是困难的

集群是什么样子的？

让我们来谈谈钱

• 总拥有成本（Total Cost of Ownership，TCO）
• TCO包含的远不止一块磁盘的零售价
• 一个密度更大的磁盘可能会以$/GB的溢价出售，但仍然比部署成本低（电源、连接开销、维修）

存储TCO的成分

• 最重要的是，我们关心的是存储TCO，而不是磁盘TCO。存储TCO是数据持久性和可用性的成本，以及提供数据服务的成本。
• 如果我们保持磁盘繁忙，就会最小化总存储TCO。

我应该买什么磁盘？

• 我应该买哪些磁盘?
• 我们会有一个组合，因为我们一直在成长
• 我们有一个IOPS和容量的总体目标
• 我们选择磁盘使集群和机群更接近我们的整体组合

我们想要什么

• 相同数量的热数据（盘轴繁忙）
• 用冷数据填满磁盘的剩余部分（填满磁盘）

如何实现？

• Colossus重新平衡旧数据和冷数据
• …并将新写的数据均匀地分布在磁盘上

当事情进展顺利时

• 每个方格即是一个D服务器
• 方格大小显示磁盘容量
• 方格颜色显示盘轴利用率

粗略的模式

• 购买flash作为缓存，在磁盘范围内考虑IOPS/GB
• 购买磁盘作为容量，填满磁盘
• 希望磁盘永远是繁忙的：否则我们买了太多的flash，但却不够忙…
• 如果我们购买用于IOPS的磁盘，字节级别的改进就没有帮助
• 如果冷字节无限增长，我们就有大量的IO容量

填充磁盘是困难的

• 文件系统在磁盘100%满时不能正常工作
• 没有空间就不能删除容量进行升级和维修
• 个别磁盘组不希望达到接近100%的配额
• 管理员对统计上的过度使用感到不舒服
• 供应链不确定性

应用程序必须改变

• 几乎与我们数据中心的任何其他东西不同，磁盘I/O成本正在上升
• 想要比HDD提供更多访问的应用程序可能需要考虑让热数据更热（因此flash工作得很好），让冷数据更冷
• 一个写于X年前的应用程序可能会导致我们购买更小的磁盘，从而增加存储成本

结论

Colossus对于优化我们的存储效率非常有用。

存储效率

• 元数据伸缩允许对资源进行划分
• 组合不同大小和不同类型工作负载的磁盘的能力非常强大

展望未来，I/O成本趋势将要求应用程序和存储系统同时发展。

谢谢！

Colossus简史

• 2001年，谷歌设计第一个集群文件系统——GFS。GFS支持P级的数据存储，以及数千客户机与数千服务器的交互。
• 2006年，谷歌完成了Colossus的初步实现，最初的目的不是用来替代GFS，而是为BigTable的后端而设计的。
• 2007年，Colossus开始在一些集群中替换GFS作为BigTable的后端。
• 2008年1月，Colossus的开发者搭建了第一个产品级Colossus 单元部署。2个月后，视频数据开始使用Colossus。
• 每一年，谷歌的用户基础和服务都在增加，而GFS再也不能支持这个不断发展的生态系统了。谷歌需要将系统迁移到集群级的文件系统，该文件系统具有容错能力，设计用于大规模扩展，能够更有效地使用机器资源，并且对面向用户的服务提供最小的干扰。
• 2009年，美国计算机学会通信采访谷歌的Kirk McKusick 和 Sean Quinlan ——《GFS: Evolution on Fast-forward》，谈及GFS的不足和未来发展。
• 2010年，谷歌公司的高级存储SRE领导团队启动了Moonshot 项目（登月计划），决定把公司所有的系统从GFS迁移到Colossus上。在那个时候，Colossus依然是一个原型系统。
• 2010年，谷歌首席工程师Andrew Fikes在学院峰会上分享《Storage Architecture and Challenge》，首次对外提及Colossus。
• Moonshot 项目是谷歌历史上最大的数据迁移项目。当时的内部邮件这样写道：假如我们在2010年完成所有数据迁移——这听起来是一个非常激进的计划，那么，是的！是否会出现诸如小故障之类的问题？这是可能的。然而，存储团队和我们的高级VPs认为，这样的努力和偶尔的小问题是值得的，而且对于早期采用者有很多激励措施，包括降低配额成本、更好的性能和大量友好的SRE支持。
• 最初，许多工程师对“Colossus”的迁移犹豫不决，有些人对“上级的命令”感到不满，觉得自己“别无选择”。“这让我们非常头疼，”一个人在接受采访时说。然而，其他工程师则更为乐观。正如工程副总裁Ben Treynor所指出的，“登月计划对谷歌来说是一个极其重要的举措。为了取得必要的快速进展，我们愿意冒更大的风险来实现它的目标，这是非常重要的——甚至达到停机的程度，只要我们不丢失客户数据。” 另一位工程师总结道：“这很疯狂，但可能行得通。”
• Video和Bigtable是Colossus的第一批客户，因为GFS的限制给了他们繁重的压力，他们正在积极寻找一个替代的存储系统。
• 后来，谷歌设立了两个季度的试点阶段，一些较小的服务(如分析，谷歌建议，和Orkut)选择迁移到Colossus上。
• 事实上，谷歌用了整整两年时间完成数据迁移任务。
• Moonshot项目还暴露了系统资源使用的问题，从而激发了“streamroller”项目，该项目旨在重新组织整个谷歌生产系统的机器级资源分配方式。
• 2012年，谷歌发表论文《Spanner: Google's Globally-Distributed Database》再次对外提及Colossus。
• 2012年，无线杂志发表文章《Google Remakes Online Empire With 'Colossus'》。
• 2017年，谷歌首席工程师 Denis Serenyi 在 PDSW 2017 第二届国际并行数据系统研讨会上分享 《From GFS to Colossus: Cluster-Level Storage @ Google》，透露了Colossus设计的深层思考。