/ 中存储网

开源对象存储Swift——概念、架构与规模部署

2015-12-06 09:33:06 来源:中存储网

开源的最大魅力,是能够满足人们的探索欲和求知欲,让我们可以很深入地了解一个系统,如果我们发现它的设计或者实现中有任何不合理的或者错误的地方,我们可以提出自己的想法并且实现它,亲手来完善一个大家都在关注的事物,让无数人受益其中。今天我们就来聊一聊一个开源对象存储系统——OpenStack Swift。

1.Swift概述

Swift是一个提供RESTful HTTP接口的对象存储系统,最初起源于Rackspace的Cloud Files,目的是为了提供一个和AWS S3竞争的服务。

Swift于2010年开源,是OpenStack最初的两个项目之一。然而,在国内OpenStack圈里,不太能够听到关于Swift的声音,究其原因正如本系列的第一篇《文件系统vs对象存储——选型和趋势》中所说的,RESTful HTTP接口的对象存储,主要为互联网应用服务,而OpenStack厂商最关心的传统行业的用户目前能够应用这种存储模式的还不多。

但实际上,Swift在一些本土互联网公司确实是有一些成功的应用,包括新浪、美团、爱奇艺、凤凰网等。国外的应用更为广泛,早在2010年,Swift就迎来了第一个Rackspace之外的商用案例——韩国电信,大家很熟悉的维基百科、ebay等也是Swift的用户。相信随着互联网技术的应用架构逐渐被传统行业接受,对象存储和Swift将受到越来越广泛的关注。

从OpenStack Kilo版本的数据来看,Swift社区呈现出多元化的特点而且正在健康的发展。

开源对象存储Swift——概念、架构与规模部署

本文和本系列接下来的两篇,将介绍Swift的架构并给出规模部署的例子,从硬件配置开始一步步搭建一个Swift集群,总结Swift的特点并提出Swift面临的挑战和发展趋势。

2.Swift的数据组织结构

开源对象存储Swift——概念、架构与规模部署

Swift将整个存储分为三个层次:Account、Container 和 Object。

这里的Account本身只是一个存储区域,并不代表认证系统里的“账号”,但是通常会让每个Account对应一个租户。这就是为什么我们作为一个OpenStack用户在使用Swift时,只能看到Container和Object,而看不到Account的原因,如果这个用户切换到另一个租户下,他将看到属于另一个租户也是是另一个Account下的Container和Object。

3Swift集群的架构

相对于OpenStack中的其他项目来说,Swift比较独立,用户可以选择将其单独部署,当然也可以与OpenSatck其他项目集成,甚至与Cloudfoundry和Docker集成。一般来说,Swift集群由两类节点组成:Proxy节点和Storage节点。一个简单的Swift集群如下图所示:

开源对象存储Swift——概念、架构与规模部署

Proxy节点上主要运行Proxy Server服务进程,负责接收和响应用户的HTTP请求,Proxy Server是一个无状态的服务,可以很容易地进行横向扩展。由于Swift自身的认证服务只是一个测试用的TempAuth,所以通常需要使用一个外部的认证服务,或者在Proxy节点上安装额外的认证服务。如果我们有一个OpenStack环境,我们可以直接使用该环境中的Keystone,如果不需要和OpenStack的其他部分集成,也可以在Proxy节点上安装一个独立的Keystone来提供认证服务。

开源对象存储Swift——概念、架构与规模部署

Storage节点上主要运行三类存储服务进程:Account Server、Container Server 和 Object Server,分别负责Account、Container、Object数据的存储,所以,在一些文献中又把存储节点称作ACO节点。

Proxy Server通过一种叫做Ring数据结构来确定数据存放在哪个存储节点上,Ring是一种经过改进的一致性哈希实现,可以将一份数据映射到多个设备,具体映射到几个设备上,取决于创建Ring时设定的副本数量。Swift 2.0版发布以后,用户可以利用存储策略(Storage Policy)功能给各个Container指定不同的副本数量,或者使用纠删码(Erasure Code),关于Swift中的存储策略请参考《OpenStack Swift 存储策略》( http://www.ibm.com/developerworks/cn/cloud/library/1411_limy_openstackswift/ )

在Swift中,每个Account和每个Container的信息分别存储在一个个独立的sqlite数据库里,也就是说,虽然在逻辑上来说,整个存储空间是分为Account、Container和Object三个层次,但是实际上每个Account、Container和每个Object一样,都对应到Storage节点上的一个文件。所以,Swift的整个存储空间是一个Flat Namespace,可以看做是一个K/V存储。

这也就不难理解为什么说Swift是全对等架构,因为这里面没有管理职能的元数据服务器,Account和Container的存储方式和Object并无本质区别,每个存储服务在集群里的地位都是等同的。Proxy Server根据REST请求中的URI的结构来确定用户请求的是一个Account、一个Container还是一个Object。

开源对象存储Swift——概念、架构与规模部署

在一些文献中或者有些人在交流的时候,会把Account和Container信息称作Swift中的“元数据”,我不赞同这种说法,我也没有在Swift官方文档中的任何地方看到将这两类信息称为“元数据”的说法,它们和文件系统的元数据有本质的区别。事实上,在Swift中,元数据(metadata)指的是对象的属性(attribute),它是对象的描述信息,Swift借助xfs等底层机制的特性和将对象的属性/元数据和对象的数据放在一起存储。

如果我们希望扩展Swift的功能,比如在用户上传对象的时候进行查毒、数据压缩或者黄色图片等非法信息扫描,可以通过在Proxy Server上增加Middleware来实现,这里的Middleware(中间件)是Python WSGI框架中的一个概念,每个HTTP请求,都通过一层层中间件处理后传递给最核心的Proxy Server;Proxy Server产生的响应,也通过一层层中间件的处理最后返回给用户。事实上,Swift对Keystone的调用正是通过middleware来实现的。

4一个中等规模Swift部署实例

Swift集群的架构让我们可以很容易地扩展Proxy节点和存储节点的数量。一个中等规模Swift部署的例子如图所示:

开源对象存储Swift——概念、架构与规模部署

该案例中,Proxy节点使用Lenovo System X 3650服务器,计算能力较强,能够应对较高的并发访问,并方便以后在Swift上部署新的middleware以扩展其功能。

Storage节点使用存储密度较高的超云R6440-G9服务器(该服务器的具体情况和技术剖析请参考文章《旁观高密存储服务器(1):不择手段混合型》)6个满配的4U笼子共24个Storage节点,每节点12块希捷的3.5寸4T硬盘,能够提供约1.2 PB的物理存储空间,采用三副本策略,共提供384TB的存储容量。

Swift将存储节点分为多个zone,将副本保存到不同的zone中,一般来说,zone的数量应当大于或等于副本数量。

zone的划分原则为物理故障隔离,例如,我们可以按机柜来划分zone,也可以像图中那样把一个四节点笼子里的四台服务器划分到同一个zone里,分属不同笼子的节点划分到不同的zone。如果节点数量较少,也可以将每台服务器划分为一个zone。实验、开发、测试环境中也可以按照磁盘来划分zone,比如将一个服务器中的12块盘分到不同的zone中。