谷歌Colossus文件系统的设计经验
基础知识:
谷歌的第一个集群级文件系统（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设计的深层思考。
”