OpenStack Object Storage（Swift）概述

962148150

概述

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

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

　　

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


1、Proxy Server
　　Proxy server 是负责将Swift架构其余的部分整合起来。对于每个客户端的请求，它将在Ring中查询Account、Container或Object的位置，并且相应地路由请求。
　　Proxy提供了Rest-full API，并且符合标准的HTTP协议规范，这使得开发者可以快捷构建定制的Client与Swift交互。

2、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非常的相似，只是它负责容器的列表，而不是对象。

3、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会执行失败的更新。
　　

三、重要概念
1、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文件中的项目，以保证增减节点时，系统因此而发生迁移的文件数量最少。
2、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.

3、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系统是可靠的，没有单点故障。

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

Swift利用一致性哈希算法构建了一个冗余的可扩展的分布式对象存储集群。Swift采用一致性哈希的主要目的是在改变集群的Node数量时，能够尽可能少地改变已存在Key和Node的映射关系。
该算法的思路分为以下三个步骤。首先计算每个节点的哈希值，并将其分配到一个0~232的圆环区间上。其次使用相同方法计算存储对象的哈希值，也将其分配到这个圆环上。随后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个节点上。如果超过232仍然找不到节点，就会保存到第一个节点上。 假设在这个环形哈希空间中存在4台Node，若增加一台Node5，根据算法得出Node5被映射在Node3和Node4之间，那么受影响的将仅是沿Node5逆时针遍历到Node3之间的对象（它们本来映射到Node4上）。其分布如图所示。




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