杨锦涛：主流开源存储方案孰优孰劣

个人简介 杨锦涛（Osier Yang），青云QingCloud系统工程师，libvirt committer，多个其他虚拟化相关开源项目的committer/contributor，QingCloud对象存储系统的核心设计者与开发者。对Open Source、Linux Kernel、虚拟化、分布式存储、云计算等领域有深入研究和理解。9年多职业生涯没有离开过Linux领域，曾在Red Hat度过6年职业生涯，原Red Hat Cloud BU开发者，主要方向为虚拟化。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 大家好，我在ArchSummit深圳大会现场，今天很高兴邀请到青云的系统工程师Osier来接受我们的采访，Osier现在是在做对象存储，大概介绍一下去年做了些什么工作？

杨锦涛：我们是在去年的7月23号开始立项的，到9月底差不多两个月的时间里，我们做了调研，收集以及写文档的工作。我们最开始的想法是想去看一看开源界的存储方案有没有适合我们的，这样的话，从前期的人力成本上来说，能节省很多的事情，当然在后期的研发，提高，或者进一步的运维，并不一定会比自己去开发花更少的精力，但是前期如果说有比较合适的系统，还是会节省很多的人力。当时我们调研了很多的主流开源存储方案，包括像Ceph，GlusterFS，还有Sheepdog，他们三个的共同特点就是无中心的分布式存储，也就是说他们没有在外围存储索引的Server。除了这三个以外，我们当时还调研了一些其他的开源的分布式文件系统的方案，像HDFS，Facebook的HayStack，还有淘宝的TFS。我们看过一些论文以及他们的架构，最终还是决定自己做。为什么要做这个决策呢？就是我们发现没有适合我们的，像Ceph还有Sheepdog，他们做的事情是比较极端一些，任何进来的数据都去做切割，然后把切割后的这些块，分布到任何地方去。然后GlusterFS是走了另外一个极端，存进来的文件就是原生的，集群里面可能有很多个节点，但是每个节点上面都跑到的是本地文件系统，传一个比如说是文件A，那就把这个文件A按照调度算法调度到某一个节点上去，它在那个本地文件系统没有做任何的处理。像Ceph还有Sheepdog这种做法，我个人认为是比较理想化，在性能方面当集群变得很大的时候会出现一些问题；然后像Gluster这种它有另外一个问题，就是它不能解决，比如说集群现在每一台节点上都剩一百G的空间，那要存两百G的文件的时候怎么办？其他的分布式文件系统，我们的调研结果就是，像Facebook的HayStack，还有淘宝的TFS，这些都是在某一些特定的场景下做出来的东西，无论是facebook，还是淘宝，都知道要存储的数据的类型是什么样的（大多数都是图片），存储的数据的大小也是可期的，因为这些东西都是经过他们处理的。在这种前提之下，整个的存储系统就比较定制化，大家如果去看Haystack或者TFS的论文就会发现这一点。还有像HDFS，它也是在特定场景下，它比较适合读特别多，写少的场景。而对于我们来说，我们要做一个对象存储的Service，我们不知道我们的用户是什么类型，它的业务类型是什么，要存什么样类型的数据，数据的大小又是什么样的，所以说我们的需求是我们首先要做一个general的平台，这个困难就要更大一些。在这些原因之下，我们决定还是最终自己来做这整个系统。

   

2. 那是9月份做出的决定？

杨锦涛：没错，是9月份，确切的来说是9月23号我们做出的决定，然后那时候开始编码阶段。

   

3. 刚才介绍的很详尽了，你自己对技术这方面偏爱哪种风格，像你刚才提到，淘宝或者Facebook那种情况确实是属于业务场景的需求，它比较有特殊性。但是像Ceph，Gluster，还有sheepdog，它们之间的区别更有点像是一种思路不同，它们都是general purpose，都是为了通用的一个方案，你刚才说了它们的不同，但是它有没有优劣，或者对你们的场景来说有哪些地方，你觉得这个比较好，那个不太好？

杨锦涛：他们的目的的确是要做一个general的存储方案，尤其是像Ceph，Ceph从最开始，它自称为是Object Storage，在这个之上去区别，现在比较流行的大家用它的方式是以块设备的方式，也就是block storage，它同时又有一个项目叫做Ceph FS，就是它要在这个之上构建一个文件系统层次的service，同时又做了RADOS Gateway，它是一个处理HTTP请求的东西，我们当时调研Ceph的时候，主要调研了这个RADOS Gateway，发现RADOS Gateway有一个非常严重的缺陷，我们把每一个用户的存储空间称为bucket的话，那么它给每一个bucket有一个单独的索引文件，而在Ceph这种比较极端的分布式的情况下，它经常会出现re-balance，recovery，或者backfilling等等这样的操作，比如说你加一台节点的时候，down一台节点的时候，或者说Ceph本身对整个系统的数据进行校验的时候，都有可能引起，我们假设索引建完后正好被待操作了，这个时候这个索引文件是被锁住的，而所有关于这个bucket的写操作，都会pending在那里，如果对这个索引锁的时候比较长，因为系统自身修复，或者re-balance等等这些操作的原因，要把它锁的时间比较长的时候，用户看到的，就是这个服务不可用，所以它这一点是非常糟糕的地方。社区上也有人尝试去改变这个问题，但是改变的方式也是治标不治本，以前一个存储空间有单个的索引文件，现在对这个索引文件做partition，比如说把它搞成1024，但是这治标不治本，也就是说它从根本上有一定的缺陷。还有一种思路，就是抛弃Radosgw，底层的存储系统还是用Ceph，在上面自己搞一个类似于gateway的东西去处理Web请求，这样可以避免radosgw的比较根本性的索引设计上面的缺陷，但是我刚才提到，就是Ceph本身也不太适合我们的应用场景。我不是说Ceph这个系统是不好的，它事实上也是挺好的，也有很多的组织，公司，企业包括公有云平台也在用Ceph，只是说它不适合我们的这个场景而已。另外一个是Gluster，用它来做对象存储，底层是用Gluster存储数据，在上面建立结构层等等，但是它有一个比较麻烦的问题，就是Gluster本身没有对文件做处理，它还是依赖于传统的本地文件系统去存储数据，那么传统文件系统的那些limitation还在，比如说传统的文件系统里面有Ext4，Ext4还好一点，它在存储小文件的时候有一些优化，但是当存的小文件数目很多的时候，就会造成问题，比如说List的速度非常慢，而且这些小文件本身数据量没有太多，但它的索引反倒占了很多的空间。另外存储这种大量小文件的时候，可能会造成本地文件系统的目录数过剩，过大等等这样的问题，导致整个文件系统的索引性能下降。一般情况下，本地文件系统索引的时候都会有一个目录项缓存，就是在这条路径上面所有涉及到的目录项，都会在一个地方缓存，增加索引性能或者读取性能等等，但是当目录数变得很大的时候，索引在缓存里面miss的可能性就会比较大，这也会造成性能方面有一些下降。Sheepdog我们做的调研相对来说少一点，其中一个原因就是Sheepdog的社区是非常的不活跃的，Sheepdog是由日本人发行的项目，目前来说它在社区里基本上还是那么几个人在维护，这对于我们的选型来说是不大可取的，虽然假设我们走Sheepdog这条路，我们可以把项目take over，或者参与去做，但是成本也是很大的，另外一个问题就是即使我们参与进去，能不能把community给建立起来，也需要大量的精力，因为把一个开源项目的community给Setup起来，然后把它拉起来，也是需要大量的人力和物力的花费在里面。

   

4. 假设你有大把的时间，可以自己做一个项目，做一个没有他们这些缺点，一个你心目中理想的分布式对象存储的一个项目，你会怎么设计这个架构？

杨锦涛：总体来说，我觉得我们目前设计上面的一些思路，即使在那种情况下，也是适用的。我们现在整个系统的设计思路里面有一个比较重要的思想成分就是折中，就是说我们很多的设计决策里面，不会走比较极端的路线，我们会选择一个折中点，折中的意思不是这个端点是A，那个端点是B，然后你去中间那个端点叫C，不是那么简单，很多时候是涉及到一些思维上面的东西。

   

5. 能举个具体的例子吗？

杨锦涛：我可以举一个例子，比如说，一般在这种分布式的存储系统里面，大家为了解决海量的小文件带来的困扰，一般会做文件的合并，比如说像facebook的haystack，淘宝的TFS，都有自己的合并文件的策略，我们也是做了这个事情的。但是这个事情我们做得没有那么死，为什么呢？因为我们不知道用户要被合并的文件的特征，这里最重要的特征就是它的大小，像Facebok的haystack，还有淘宝的TFS，它的文件大小是可期的，而对于我们来说不是，那么我们怎么样去做这个事情呢？我们还是合并文件，但是合并文件的大小不是那么固定，它可以在一个range，一个范围之内。这个就是其中的一个例子。

InfoQ：那就差不多了，十分感谢您今天接受我们采访。