SwiftStack CEO 谈存储系统的演变与新存储方案的挑战

作为 OpenStack 项目在对象存储方面的核心项目，Swift 在这几年的发展十分迅速。SwfitStack 是一家提供 Swift 部署与管理服务的硅谷初创企业，在 OpenStack 开发者社区非常活跃。

在 2013 年 9 月的 Cloud Connect China 大会上，SwiftStack 的 CEO Joe Arnold 在现场跟同事一起主持了一场动手实验室，通过他们的在线服务快速搭建一个 Swift 环境。InfoQ 编辑在现场跟 Joe Arnold 进行了一些交流，聊了一些有关存储会如何演变、新存储方案的挑战等话题。

InfoQ：存储分为三种：块存储，对象存储，文件存储。你认为这种分类会发生变化吗？

Joe：对于我们来说，我们服务的是数据中心。想想我们服务的应用是什么样的，我们的客户是做什么的——比如刚刚加入的新客户迪士尼，他们是做什么的？游戏。他们构建应用。他们的数据不在笔记本电脑上也不在手机上，而是在云端，比如数据中心之类的地方。我们提供的存储平台主要用于在云端存放视频、照片、文档等类型的数据。

对于迪士尼而言，他们的游戏是用户产生内容的，我们就需要为很多用户提供数据存储和读取的服务。我们擅长的是在很大的数据中心处理非常多的数据，面向非常多的用户。因为这样的需求，才产生了新的存储系统。

你提到的三种存储类型，就我们的情况而言，文件存储基本上不太用。以前文件存储主要是要求高性能，因为数据库需要处理一些交易工作，它需要对文件上锁，然后去对数据库做更新。

我们现在需要另一种存储，针对非结构化的数据。在这种使用情景下，我们不需要像传统的文件系统那样去做文件锁什么的，你只要保存很多份就行了。数据保存了就永久在那儿了，不需要去删它或者改它，当然这意味着我们必须要把存储做的很便宜。所以在数据中心里面，文件存储逐渐在被替换掉。

InfoQ：像是 Swift、Ceph 和 Gluster 这样的云存储，跟传统的 POSIX 文件系统相比，最根本的区别在哪里？新的存储系统主要是为了解决什么问题？

Joe：正如上面所说，传统的模式面向单一应用、小数量用户的情景，比如企业架设一台邮件服务器或者内网统计系统，都是比较小规模的环境。新的用户案例是大型应用，这包括用户网络的应用，以及企业级的 SaaS。Web 应用和移动应用的用户量都非常大，在这种场景下，POSIX 系统不可能满足如此巨大的扩展需求，它们构建的系统只会变成一个一个数据孤岛：这里建一个存储系统，那里再建一个存储系统，不同地区的用户访问不同的系统——我们把这个策略叫做分片。建造系统不仅浪费时间，从运维管理的角度这也带来了太多复杂性。

所以，我们需要的下一代存储系统是一个统一的存储系统——无论有多少设备组成，它都是在一个存储系统下面。这样对应用开发者而言更容易开发，对运维而言更容易维护和扩容。添加节点，系统自动进行负载平衡，开发者也不需要变更任何代码，也不需要将新版本的应用手动推送给所有的用户，整个环境变得大大简单了。

InfoQ：也就是说，个人设备仍然会用老的 POSIX 文件系统，只不过数据中心需要新的方案。

Joe：没错。比较典型的大型用户场景有照片分享，游戏，通讯工具等。从公司业务的角度，我们看到游戏对于这种新型存储的需求非常大。另外还有企业文档共享的使用情景。还有视频音频。大家不再用磁带了。我们把数据丢到存储系统里，它们就可以通过 HTTP 被服务出去。

对于视频、图片、文档而言，通过 HTTP 传输的好处就是方便。你在你的移动设备或者浏览器上，你不是通过 POSIX 接口从互联网上拉数据下来的，也不是 ISCSI，不是光纤通道。你用 HTTP。在数据中心提供天然支持 HTTP 的对象存储，意味着应用可以立刻访问到这些数据。

InfoQ：Swift 采用 Ring 机制来记录每一块数据都保存在集群的什么地方。这种方案的运行状态如何？最近有哪些进展？

Joe：正好，我们最近刚刚对 Ring 引入了非常棒的一些新特性。

Ring 的工作原理是一个分布式哈希表，它做的是将一个存储 URL 对应到物理存储位置上。这是一个抽象映射，中间有一个环节叫做分区空间（partition space）。也就是说，Ring 是分区空间的哈希表。我们将所有的分区分散的分布到整个存储系统里面。

这种方式非常有效，查询的速度非常快，一致性强，每一个组件都是分布式系统中的一部分，没有单点。

这个用户体验是比较好的，我们有一个客户，做的是账务报告类的应用。比如你出去旅游，拿到票据，你就对票据拍照，将照片上传。这可以用于报税、补助之类的场景。他们做的就是建立了一个跨两个地区的集群。默认情况下，用户从离他最近的数据中心获取数据。如果其中一个地方出了问题，所有人会被路由到那个好的数据中心，访问不受到影响。

InfoQ：你提到跨两个地区的一个集群，而不是两个集群。这一个集群可以有多大？

Joe：可以到几百 PB。今天早上我刚听到一个说法：“我们建设的不是数据中心，而是数据城市”，因为数据中心实在太大了。

我们在 Ring 上做的另一个酷功能是创建存储策略的特性。存储策略可以用来指定地域，比如客户可以选择离他们的客户近的几个地方的数据中心。存储策略还可以用于区分重要的数据和不重要的数据，比如有些数据我们把它放在比较快的硬盘上，有些数据放在慢一点的硬盘上也无妨。

我想说的最后一点是抹除码（ erasure coding ）。抹除码是相对于复制而言的。使用复制的情况，我们对一个文件做几个副本，放在不同的地方，再去管理它们。

抹除码的思路，简单来说，是将文件转换成一个碎片集合，每一个碎片很小，碎片被打散分布到一组服务器资源池里。只要存留的碎片数量足够，就可以合成为原本的文件。这可以在保持原本的数据健壮性的基础上大大减少需要的存储空间。我们希望能在下一个四月大版本上引入这一批特性。

InfoQ：之前，你提到 SwiftStack 带来了更多的便捷性、可控性和成本降低。你提到了部署、运维、扩容操作的简化。能否举例说明部署这样一个存储集群到底如何方便吗？

Joe：SwiftStack 是 Swift 项目的头号贡献者之一，这个项目的首席技术和很多核心贡献者都来自我们团队。当然，上述提到的特性并不是我们自己在做的，也有其他公司的贡献，包括 Intel 等。

大型分布式系统的部署、管理、运维、扩容都是非常复杂的，我们希望通过软件降低这个复杂性。所以我们将扩容做了自动化，我们为不同的环境提供了集成方案，以便于快速建立一个集群。

举个例子吧。我们有个客户是做体育节目直播的。部署的时候，我们派了五个运维过去给他们做培训。所有的服务器、布线都弄好了，培训也做好了之后，安装只用了一天时间。

正常你要自己部署一套 Swift 环境，用三个月做评估和测试是很正常的，因为安装过程中的可选项太多了。开源提供自由选择，但是自由过了头，你面对成千上万个选项，很容易在里面浪费很多时间。

InfoQ：这个意思是说，原本我部署一套 Swift 需要评估上千个属性怎么设置，但是使用 SwiftStack 安装的话，可能就三五个选项？

Joe：差不多，我们将整个部署过程简化为一个安装流程，跑完这个流程是很快的。当然，我们也给客户做培训，教他们自己调优一些配置。事实上，我们专门写了一本书介绍如何进行配置调优。只不过，很多人做了这些练习，了解到这些配置之后，最终还是决定不要自己折腾，交给我们提供服务更加简单一些。

我们的服务模式是，提供一个管理控制器的在线服务，而客户的数据还是保存在自己的数据中心里面，我们通过管理控制器帮他们做管理。我们在美国的管理控制器负责支持美国的客户。对中国客户，我们在上海建立了一个新的管理控制器，可能几个月之后就会开始正式面向中国客户运营。到时候大家可以通过我们的合作伙伴 99Cloud 获取这个服务。

InfoQ：对于存储服务而言，降低成本的常用方式是什么？各个方案的成熟度如何？

Joe：最常用的方式自然是用便宜的硬件。我们更关注机箱里面的组件，而不关注整机品牌。我们有一些推荐的组件品牌，比如 LSI、希捷、Intel 等。不同组件的配置比例则取决于用户的场景，我们自己采用了 Open Compute 建议的配置比例。此外，Quanta、Supermicro 和 Dell 也有跟我们兼容的设备。服务器就是 IBM 和 HP。

客户自己选择硬件，而且经常选择不同的品牌混在一起用。可能这六个月用这家的，后面六个月用另一家的，不同品牌的组件可以放在一起组成一个系统。我们希望将存储从底层硬件当中抽象出来，这样我们对设备类型的依赖会更小，成本就会下来。

抹除码可以减少储存文件副本需要的存储空间。复制的方式很适合需要快速读取数据的情景，比如文件共享类应用，一个用户刚刚上传一个文件，这时候很多其他的用户会需要去获取这个文件，这种情况比较适合复制的方式。

如果你有一些老数据要做备份，基本没什么人要去访问它们了，这时候你可以采用抹除码的方式对它们进行存储。用户访问的速度可能慢了个半秒钟或者一秒钟，但数据的健壮性是不受影响的。对于这种情况，抹除码意味着可以节省一些硬件费用。

InfoQ：是的，我看你之前说能够节省到 50% 的成本。

Joe：这是有可能的，但这数字不是绝对。从数据足迹的角度，数据足迹是降低了 50%，不过因为你需要另外购买强大的硬件来实现抹除码的操作，成本的降低并不一定有这么多。

InfoQ：使用抹除码会造成更多 CPU 和网络的消耗，更多电力消耗，这个平衡要如何实现？

Joe：这个问题很好，因为它没有明确的答案。

你去对数据做抹除码的时候，往往是在一个数据中心内做，而不会跨数据中心做，因为跨数据中心的网络延时和成本太高。在一个数据中心内，数据转移的成本是相对更低的，10Gb 以太网也不会特别贵。

抹除码主要牺牲的是请求延时，因为你需要从多个服务器获取碎片，每台服务器都需要到硬盘上找到你要的那一块，然后把它们组合成原本的文件，这个过程又需要比较多的 CPU。所以你需要做的是权衡，你的应用和用户是否能够接受这个条件。

嘉宾简介：

Joe Arnold，SwiftStack CEO，创始人。Swift 是第一个由 Rackspace 之外发起的 OpenStack 子项目。目前，Joe 的工作重心在于开发用于部署和管理 OpenStack Swift 的工具上。

注：本采访由 InfoQ 编辑跟 CSDN 编辑一起进行，采访内容双方共享。