OpenStack开源虚拟化平台（二）

---

三、对象存储服务Swift

  比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为Web应用创建基于云的弹性存储。

（一）Swift特性

1. 高数据持久性

  数据的可靠性，是指数据存储到系统中后，到某一天数据丢失的可能性。

2. 完全对称的系统架构

  “对称”意味着Swift中各节点可以完全对等，能极大地降低系统维护成本。

3. 无限的可扩展性

  一是数据存储容量无限可扩展，二是Swift性能（如QPS、吞吐量等）可线性提升。

4. 无单点故障

  整个Swift集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。

5. 简单、可依赖

  简单体现在实现易懂、架构优美、代码整洁；可依赖是指Swift经测试、分析之后，可以放心大胆地将Swift用于最核心的存储业务上。

（二）应用场景

  Swift主要有三个组成部分：Proxy Server、Storage Server和Consistency Server。其中Storage和Consistency服务均允许在Storage Node上。使用OpenStack的认证服务Keystone，目的在于实现统一OpenStack各个项目间的认证管理。

（三）Swift主要组件

  Swift主要组件如下。
  （1）代理服务（Proxy Server）：对外提供对象服务API，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务；由于采用无状态的REST请求协议，可以进行横向扩展来均衡负载。
  （2）认证服务（Authentication Server）：验证访问用户的身份信息，并获得一个对象访问令牌（Token），在一定的时间内会一直有效:验证访问令牌的有效性并缓存下来直至过期时间。
  （3）缓存服务（Cache Server）：缓存的内容包括对象服务令牌、账户和容器的存在信息，但不会缓存对象本身的数据；缓存服务可采用Memcached集群，Swift会使用一致性散列算法来分配缓存地址。
  （4）账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个SQLite数据库中。
  （5）容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务，每个容器的信息也存储在一个SOLite数据库中。
  （6）对象服务（Object Server）：提供对象元数据和内容服务，每个对象的内容会以文件的形式存储在文件系统中，元数据会作为文件属性来存储，建议采用支持扩展属性的XFS文件系统。
  （7）复制服务（Replicator）：会检测本地分区副本和远程副本是否一致，具体是通过对比散列文件和高级水印来完成，发现不一致时会采用推式（Push）更新远程副本， 例如对象复制服务会使用远程文件复制工具rsync来同步；另外一个任务是确保被标记删除的对象从文件系统中移除。
  （8）更新服务（Updater）：当对象由于高负载的原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中， 更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。
  （9）审计服务（Auditor）：检查对象、容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误会被记录到日志中。
  （10）账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象。

1. Ring

  Ring是Swift最重要的组件，用于记录存储对象与物理位置间的映射关系。在涉及查询Account（账户）、Container（容器）、Object（对象）信息时，就需要查询集群的Ring信息。Ring使用Zone、Device、Partition和Replica来维护这些映射信息。Ring中每个Partition在集群中都（默认）有3个Replica。每个Partition的位置由Ring来维护，并存储在映射中。每次增减存储节点时，需要重新平衡一下Ring文件中的项目。

2. Proxy Server

  Proxy Server是提供Swift API的服务器进程，负责Swift其余组件间的相互通信。Proxy提供了Rest-full API，并且符合标准的HTTP协议规范，这使得开发者可以快捷构建定制的Client与Swift交互。

3. Storage Server

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

4. Consistency Servers

  目的是查找并解决由数据损坏和硬件故障引起的错误。主要存在三个Server：Auditor、Updater和Replicator。

（四）Swift基本原理

  Swift 的算法和存储理论并不复杂。主要有以下几个概念。

1. 数据一致性模型（Consistency Model）

  为了实现这一目标，Swift采用Quorum仲裁协议：
  （1）定义N为数据的副本总数，W为写操作被确认接受的副本数量，R为读操作的副本数量。
  （2）强一致性：R+W >N，以保证对副本的读写操作会产生交集，从而保证可以读取到最新版本。
  （3）弱一致性：R+W<=N，如果读写操作的副本集合不产生交集，就可能会读到脏数据。
  Swift针对的是读写都比较频繁的场景，所以采用了比较折中的策略，即写操作需要满足至少一半以上成功W>N2，再保证读操作与写操作的副本集合至少产生一个交集，即R+W>N。Swift默认配置是N=3，W=2>N/2，R=1或2，即每个对象会存在3个副本，这些副本会尽量被存储在不同区域的节点上；W=2表示至少需要更新两个副本才算写成功；当R=1时意味着某一个读操作成功便立刻返回，此种情况下可能会读取到旧版本（弱一致性模型）；当R=2时，需要通过在读操作请求头中增加x-newest=true参数来同时读取两个副本的元数据信息，然后比较时间戳来确定哪个是最新版本（强一致性模型）；如果数据出现了不一致，后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性，如下图所示。

2. 一致性散列（Consistent Hashing）

  面对海量级别的对象，需要存放在成千上万台服务器和硬盘设备上，首先要解决寻址问题，即如何将对象分布到这些设备地址上。Swift基于一致性散列技术，通过计算可将对象均匀分布到虚拟空间的虚拟节点上，在增加或删除节点时可大大减少需要移动的数据量；虚拟空间大小通常采用2的n次幂，便于进行高效的移位操作；然后通过独特的数据结构Ring（环）再将虚拟节点映射到实际的物理存储设备上，完成寻址过程之间的对象（它们本来映射到Node4上）。

  将散列结果右移m位，可产生 $2^{32-m}$ 个虚拟节点，例如 $m=29$ 时可产生8个虚拟节点。

3. 数据模型

  共设有三层逻辑模型。Account（账户）：租户，用来做顶层的隔离机制；Container（容器）：代表封装一组对象，类似文件夹或目录；Object（对象）：由元数据和内容两部分组成。

4. 环的数据结构

  环是为了将虚拟节点（分区）映射到一组物理存储设备上，并提供一定的冗余度而设计的，其数据结构由以下信息组成。
  （1）存储设备列表、设备信息，包括唯一标识号（id）、区域号（zone）、权重（weight）、IP地址（ip）、端口（port）、设备名称（device）、元数据（metadata）。
  （2）分区到设备映射关系（replica2part2dev_id数组）。
  （3）计算分区号的位移（part_shift整数）。

5. Replica

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

  NWR是一种在分布式存储系统中用于控制一致性级别的策略。在Amazon的Dynamo云存储系统中，使用了NWR来控制一致性。N代表同一份数据的Replica的份数，W更新一个数据对象时需要确保成功更新的份数，R代表读取一个数据需要读取的Replica的份数。
  公式W+R>N，保证某个数据不被两个不同的事务同时读和写，公式W>N/2保证两个事务不能并发写某一个数据。

  Swift的N=3、W=2、R=2，完全符合NWR策略， Swift系统是可靠的，没有单点故障。

6. Zone

  如果所有的节点都在一个机架或一个机房中，那么一旦发生断电、网络故障等事故，都将导致用户无法访问。需要一种机制对机器的物理位置进行隔离，以满足分区容忍性。Ring中引入了Zone的概念，把集群的节点分配到每个Zone中，其中，同一个Partition的Replica不能同时放在同一个节点上或同一个Zone内。

7. Weight权重

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

8. 系统架构

  Swift采用完全对称、面向资源的分布式系统架构设计，组件可扩展，通信方式采用非阻塞式I/O模式，提高系统吞吐和响应能力。

（五）实例分析

  下图是新浪SAE在测试环境中部署的Swif集群，集群中又分为4个Zone，每个Zone是一台存储服务器，每台服务器上由12块2TB 的SATA磁盘组成，只有操作系统安装盘需要RAID，其他盘作为存储节点，不需要RAID。
  前面提到过，Swift采用完全对称的系统架构，在这个部署案例中得到了很好的体现。下图中每个存储服务器的角色是完全对等的，系统配置完全一样，均安装了所有Swift服务软件包，如 Proxy Server、Container Server和Account Server等。上面的负载均衡（Load Balancer）并不属于Swift 的软件包，出于安全和性能的考虑，一般会在业务之前挡一层负载均衡设备。当然可以去掉这层代理，让Proxy Server直接接收用户的请求，但这可能不太适合在生产环境中使用。
  下图中分别表示了上传文件PUT和下载文件GET请求的数据流，两个请求操作的是同一个对象。上传文件时，PUT请求通过负载均衡随机挑选一台Proxy Server，将请求转发到后者，后者通过查询本地的Ring文件，选择3个不同Zone中的后端来存储这个文件，然后同时将该文件向这三个存储节点发送文件。这个过程需要满足NWR策略（QuorumProtocol），即3份存储，写成功的份数必须大于2/3，即必须保证至少两份数据写成功，再给用户返回文件写成功的消息。下载文件时，GET请求也通过负载均衡随机挑选一台Proxy Server，后者上的Ring文件能查询到这个文件存储在哪三个节点中，然后同时去向后端查询，至少有两个存储节点“表示”可以提供该文件，然后Proxy Server中选择一个节点下载文件。

四、镜像服务Glance

  Glance提供了一个虚拟磁盘镜像的目录和存储仓库，并且可以提供对虚拟机镜像的存储和检索。这些磁盘镜像常常广泛应用于OpenStack Compute组件之中。以三种形式加以配置：利用OpenStack对象存储机制来存储镜像，利用Amazon的简单存储解决方案（简称S3）直接存储信息，将S3存储与对象存储结合起来，作为S3访问的连接器。

（一）Glance的作用

  Glance作为OpenStack的虚拟机的Image（镜像）服务，提供了一系列的REST API，用来管理、查询虚拟机的镜像，它支持多种后端存储介质。

  可以看出，通过Glance，Opentack的3个模块被链接成了一个整体，Glance为Nova提供镜像的查找操作，而Swift又为Glance提供实际的存储服务，Swift可以看成Glacne存储接口的一个具体实现。

（二）Glance的组成部分

  OpenStack Image Service支持的后端仓库如下。
  （1）OpenStack Object Storage（Swift）：它是OpenStack中高可用的对象存储项目。
  （2）FileSystem：OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。
  （3）S3：该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。
  （4）HTTP：OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。