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的不足。
基础知识:
GFS教训:
而Colossus则专注于存储效率的提升以及各种扩展功能。
谷歌数据中心内部示意图。
你怎么使用PB级的空闲磁盘空间?
你怎么使用PB级的空闲磁盘空间?
在紧急磁盘空间不足的情况下
典型的集群:
第1部分:从GFS到Colossus的迁移
GFS架构问题
GFS master
可预测的性能
GFSv2的一些明显目标
注意:D(Disk的缩写)服务器,它相当于在Borg上运行的GFS Chunkserver。D构成了最低的存储层,并被设计为惟一可以直接读写存储在物理磁盘上的文件的应用程序,物理磁盘被连接到D所运行的机器上。在GFS中, master节点记录文件系统元数据,Chunkserver管理原始数据chunk的读写。与此类似,D服务器管理对原始数据的访问,而Colossus服务器管理哪些数据被映射到哪个D服务器上。Colossus客户端与Colossus对话,以确定从哪个D服务器读取/写入数据,然后直接与D服务器对话,以执行读取/写入操作。如下图所示。
一个简单的问题
Bigtable的“文件系统”
元数据放在哪里?
当时的存储选项
GFS
分片MySQL(本地磁盘和复制)
带有Paxos复制的本地键值存储
Bigtable (GFS上的键值排序存储)
当时的存储选项
GFS←缺少有用的数据库特性
MySQL分区←负载平衡差,复杂
本地键值存储←无法伸缩
Bigtable←hmmmmmm .... 见下一节
为什么选择Bigtable ?
Bigtable解决了许多难题:
文件系统元数据保存在内存本地组中。
元数据在Bigtable 中!?!?
GFS master -> CFS
CFS“curators”运行在Bigtable tablet服务
Bigtable的一行对应于一个文件
Stripes是一组复制集合:打开、关闭、结束
Colossus 存储元数据?
现在我们可以把它放进Chubby中!
第2部分:Colossus和高效存储
主题
集群是什么样子的?
让我们来谈谈钱
存储TCO的成分
我应该买什么磁盘?
我们想要什么
如何实现?
当事情进展顺利时
粗略的模式
填充磁盘是困难的
应用程序必须改变
结论
Colossus对于优化我们的存储效率非常有用。
存储效率
展望未来,I/O成本趋势将要求应用程序和存储系统同时发展。
谢谢!
Colossus简史