OpenStack Object Storage（Swift）概述

概述

OpenStack Object Storage（Swift）是OpenStack开源云计算项目的子项目之一，被称为对象存储，提供了强大的扩展性、冗余和持久性。 Swift并非文件系统或者实时的数据存储系统，它称为对象存储，用于永久类型的静态数据的长期存储，这些数据能够检索、调整，必要时进行更新。最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份。由于没有中心单元或主控结点，Swift提供了更强的扩展性、冗余和持久性。Swift前身是Rackspace Cloud Files项目，随着Rackspace加入到OpenStack社区，于2010年7月贡献给OpenStack，做为该开源项目的一部分。

 

1、Swift管理的资源

swift管理的资源分三级：Account、Container、Object。一个Tenant拥有一个Account，Account下存放Container，Container下存储Object。

 

2、Swift架构概述

Swift主要有三个组成部分：Proxy Server、Storage Server和Consistency Server。其中Storage和Consistency服务均运行在Storage Node上。Auth认证服务目前已从Swift中剥离出来，使用OpenStack的认证服务Keystone，目的在于实现统一OpenStack各个项目间的认证管理。

一、Proxy Server

Proxy server 是负责将Swift架构其他的部分整合起来。对于每一个客户端的请求，它将在Ring中查询Account、Container或Object的位置，而且相应地路由请求。

Proxy提供了Rest-full API，而且符合标准的HTTP协议规范，这使得开发者能够快捷构建定制的Client与Swift交互。

二、Storage Server

Storage Server提供了磁盘设备上的存储服务。在Swift中有三类存储服务：Account、Container和Object。

1）、Object Server

Object Server 是一个很是简单的二进制对象存储服务器，能够用来存储、检索和删除存储在本地设备上的对象。对象以二进制文件的形式存储在文件系统上，元数据存储在文件的扩展属性中（xattrs）。这须要对象服务器的基本文件系统的选择支持xattrs。

2)、Container Server

Container Server最重要的工做就是处理对象列表。它不知道对象存储在哪里，只是知道什么对象在一个特殊的容器中。这个列表以sqlite数据库文件的形式存储，和对象同样在集群中进行相似的备份。跟踪统计包括对象的总数，容器的存储使用的状况。

3)、Account Server

Account Server 跟 Container Server很是的类似，只是它负责容器的列表，而不是对象。

三、Consistency Servers

在磁盘上存储数据并向外提供Rest-ful API并非难以解决的问题，最主要的问题在于故障处理。Swift的Consistency Servers的目的是查找并解决由数据损坏和硬件故障引发的错误。主要存在三个服务：Auditor、Updater和Replicator。

1)、Auditor

Auditor运行在每一个Swift服务器的后台，持续地扫描磁盘来检测Object、Container和Account的完整性。若是发现数据损坏，Auditor就会将该文件移动到隔离区域，而后由Replicator负责用一个无缺的拷贝来替代该数据。若是发现其余的错误，Auditor会把它们记录到日志中。

2)、Replicator

Replication被设计用来面对临时的网络停机或者驱动失败时，保持系统的一致性。

replication比较本地的数据（object，account和container）和每个远端副本，来确保它们全都包含最新的版本。

replication的操做包括update和remove。

3)、Updaters

有时当容器或者帐户数据不能被当即更新时，一般发生在故障的状况下或者高负载的时期。若是一次更新失败，此次更新将会被保存到本地文件系统上的队列里，而后Updater会执行失败的更新。

 

3、重要概念

一、Ring

Ring是Swift重要的组件，一个ring表明云存储中的实体（Account、Container、Object）到物理位置的映射。Account、Container、Object都有各自分离的ring。当其余的组件须要对Account、Container、Object执行某些操做时，它们都须要和对应的ring交互来肯定这些实体在集群中的位置。

Ring使用Zone、Device、Partition和Replica来维护这些映射信息。Ring中每一个Partition在集群中都（默认）有3个Replica。每一个Partition的位置由Ring来维护，并存储在映射中。

Ring文件在系统初始化时建立，以后每次增减存储节点时，须要从新平衡一下Ring文件中的项目，以保证增减节点时，系统所以而发生迁移的文件数量最少。

二、Zone

若是全部的Node都在一个机架或一个机房中，那么一旦发生断电、网络故障等，都将形成用户没法访问。所以须要一种机制对机器的物理位置进行隔离，以知足分区容忍性（CAP理论中的P）。所以，Ring中引入了Zone的概念，把集群的Node分配到每一个Zone中。其中同一个Partition的Replica不能同时放在同一个Node上或同一个Zone内。注意，Zone的大小能够根据业务需求和硬件条件自定义，能够是一块磁盘、一台存储服务器，也能够是一个机架甚至一个IDC。

zone ： a group of nodes that is as isolated as possible from other nodes (separate servers, network, power, even geography).The ring guarantees that every replica is stored in a separate zone.

三、Replica

若是集群中的数据在本地节点上只有一份，一旦发生故障就可能会形成数据的永久性丢失。所以，须要有冗余的副原本保证数据安全。Swift中引入了Replica的概念，其默认值为3，理论依据主要来源于NWR策略（也叫Quorum协议）。

NWR是一种在分布式存储系统中用于控制一致性级别的策略。在Amazon的Dynamo云存储系统中，使用了NWR来控制一致性。其中，N表明同一份数据的Replica的份数，W是更新一个数据对象时须要确保成功更新的份数；R表明读取一个数据须要读取的Replica的份数。 公式W+R>N，保证某个数据不被两个不一样的事务同时读和写；公式W>N/2保证两个事务不能并发写某一个数据。 在分布式系统中，数据的单点是不容许存在的。即线上正常存在的Replica数量为1的状况是很是危险的，由于一旦这个Replica再次出错，就可能发生数据的永久性错误。假如咱们把N设置成为2，那么只要有一个存储节点发生损坏，就会有单点的存在，因此N必须大于2。N越高，系统的维护成本和总体成本就越高。工业界一般把N设置为3。例如，对于MySQL主从结构，其NWR数值分别是N= 2, W = 1, R = 1，没有知足NWR策略。而Swift的N=3, W=2, R=2，彻底符合NWR策略，所以Swift系统是可靠的，没有单点故障。

四、Weight

Ring引入Weight的目的是解决将来添加存储能力更大的Node时，分配到更多的Partition。例如，2TB容量的Node的Partition数为1TB的两倍，那么就能够设置2TB的Weight为200，而1TB的为100。

 

4、原理

Swift利用一致性哈希算法构建了一个冗余的可扩展的分布式对象存储集群。Swift采用一致性哈希的主要目的是在改变集群的Node数量时，可以尽量少地改变已存在Key和Node的映射关系。

该算法的思路分为如下三个步骤。首先计算每一个节点的哈希值，并将其分配到一个0~232的圆环区间上。其次使用相同方法计算存储对象的哈希值，也将其分配到这个圆环上。随后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个节点上。若是超过232仍然找不到节点，就会保存到第一个节点上。 假设在这个环形哈希空间中存在4台Node，若增长一台Node5，根据算法得出Node5被映射在Node3和Node4之间，那么受影响的将仅是沿Node5逆时针遍历到Node3之间的对象（它们原本映射到Node4上）。其分布如图所示。

 

 

 

参考： http://www.programmer.com.cn/12403/