OpenStack Swift 存储策略以及应用案例

　　OpenStack Object Storage(Swift)前身是 Rackspace Cloud Files 项目，在 2010 年贡献给 OpenStack 社区，它是 OpenStack 最早的两个项目之一。在比较便宜的通用硬件上Swift 也可构筑具有极强可扩展性与数据持久性的存储系统，支持多租户，通过 RESTful API 提供对容器(Container)与对象的 CRUD 操作。

　 　                                                        图1

　　一、OpenStack Swift 对象存储及其存储策略简介

　　Swift 2.0 于 2014 年 7 月 8 日发布，其中最重要的新特性就是存储策略(Storage Policy)，该特性改变了以往存储系统中存储策略由设计和实施方决定的做法，让用户能以 Container 为粒度，为不同需求的数据指定不同的副本数量、不同参数的纠删码、不同性能的存储介质、不同地理位置、不同的后端存储设备。其存储策略充分体现了 Swift"软件定义存储"(Software Defined Storage)的特点。

　　为了能实现存储策略，Swift 在原先三个环(Ring)的架构基础上进行了改进。Swift 为账户、容器与对象分别定义了的环，通过环将虚拟节点(分区)映射至一组物理存储设备上。在 Swift 2.0 中，每个存储策略分别对应一个 Object Ring。

　　二、Swift存储策略的配置与使用

　　1.配置存储策略

　　设置存储策略分为两步：第一步，编辑配置文件swift.conf文件，创建相应的ObjectRing。在配置文件中每个存储策略以[storage-policy:N]开头，其中N是策略的编号。对于该文件的解析遵循以下规则：

• 　　如果该文件中没有声明任何策略，Swift会自己创建一个;
• 　　策略编号应当位非负整数;
• 　　如果没有声明默认策略，Swift会把编号为0的策略设为默认策略;
• 　　策略编号必须唯一;
• 　　策略应当具有名字，策略命名区分大小且必须唯一;
• 　　策略名称只能包含字母、数字和连字符，"Policy-0"只能用于编号为0的策略;
• 　　定义策略之后，应当有一个且仅有一个策略被指定为默认策略;
• 　　"废弃"(Deprecated)策略不能同时为默认策略。

　　下面是一个swift.conf文件的示例：

　                                                 图2

　　完成swift.conf 文件的编辑后，下一步是为每个存储策略创建相应的Object Ring，方法与创建老版本 Object Ring类似，只是要在object 后面加上"-N"，这里的 N 是存储策略的编号。例如，为上述编号为 0和1的存储策略创建Object Ring：

　　图3

　　2.使用存储策略

　　存储策略的使用非常简单，仅需要在创建 container 是指定存储策略即可，下面以 SAIO 部署来说明：

                        　图4

                            图5

　　这说明 Storage Policy 已经成功发挥作用。

　　三、存储策略的应用模式

　　上面提到副本数量的改变，这只是存储策略的应用模式的一种，在实际应用中，可以有以下几种模式：

　　1. 缩减或者增加冗余

　　对于一些数据，它们不需要保证很高的数据持久性与可靠性，比较典型的是图像的缩略图，它们可以由原图降采样得到，这种情况下，可以对原图采用三副本方案，对缩略图采用双副本方案，降低存储系统的开销。

　　如图6所示为不同的 Container 指定不同的副本数量

                               图6

　　2. 性能分层

　　例如，一些数据用 HDD 保存，另一些用 SSD 保存。也可以应用于其他存储介质，甚至是不同的存储设备。

　　如图7所示为不同的 Container 指定不同的存储介质

                                                                图7

　　3. 地理位置约束

　　在某些场景下，因为公司或国家的政策的约束，某些数据必须存储在指定的地理位置，例如混合云场景。在有些场景下，用户希望指定数据存放在距离访问客户端比较近的地方。

　　如图8所示为不同的 Container 指定不同的存储位置

                                               图8

　　4. 应用纠删码(Erasure Codes)

　　对于那些性能要求不高的场合，应用纠删码。纠删码，又称为删除码，将对象分割为 m 个分片(fragments)，并通过编码生成 k 个校验分片， 最后将这 n=m+k 个分片放到 Swift 对象存储系统的不同位置(通常是 swift 的不同 zone 中)。对于将 m 个分片编码为 n 个分片的纠删码，记为EC(m, n)。

　　如图9所示纠删码示意图

                                 图9

　　纠删码在提高存储空间利用率的同时，保持或增加阿里云主机数据的持久性(durability)和可靠性。但是由于编码、解码和恢复数据往往需要较大的计算量，可能导致性能的降低，所以比较适用于对持久性和可靠性要求比较高，但是访问量并不大的数据存储。

　　如图10所示应用纠删码保护数据

                                                     　图10

　　四、某视频网站中的应用案例

　　在某视频网站中，采用 Swift 存储视频文件，并对其部分文件根据视频类型的不同应用不同的存储策略。

　　视频数据分为三类：1、源片;2、超清视频文件;3、其他不同清晰度的视频文件。源片体积较大，对持久性要求高，但对访问速度要求较低，并发访问数量和访问频率较低;清晰度较低的视频由超清视频转码得到，针对上述需求，设计存储策略如下：

• 　　源片采用纠删码策略，编码参数为EC(7, 4)，即把一个视频文件分割为 4 块，并生成 3 块校验块，存储效率约为 57%;
• 　　超清视频三副本策略，存储效率约为 33%;
• 　　清晰度较低的视频采用双副本策略，存储效率为 50%。

　　假设设备损坏的概率为 2%，以上三种存储策略的数据持久性分别为：99.9995%，99.9992%与 99.96%。

　　表 1为存储策略的应用

　　                                  表1

　　Swift 集群的总结点数量为 54 个节点，总容量约为 2.3PB，集群的部署架构如下图所示，其中 Proxy Server 的数量可根据需要增加或者减少。采用传统三副本方案，能够保存的视频总长度约为(同一段视频不同分辨率不进行重复统计)3.97×106 分钟。

　　采用上述存储策略后，保存的视频总长度为 5.89×106 分钟，存储效率提高了 48%。

　　图12所示为基于 Swift 的视频存储系统的部署架构

                                                    图12

　　五、结束语

　　在大数据时代，随着文件数量和阿里云数据体量的增加，文件系统与 NAS 的瓶颈越来越明显，基于 RESTful Web API 的对象存储逐渐受到人们的广泛接受。作为最具代表性，应用最广泛的开源对象存储方案，OpenStack Swift 自诞生以来一直保持着技术上领先的地位，在 Swift 2.0 中推出的存储策略功能，能够让管理员根据自己系统的特点制定不同的存储策略;用户或租户根据自己阿里云数据的特点和业务需要，以 Container 为粒度选择存储策略，从而实现成本、数据可靠性、性能等维度上的综合权衡和优化，体现了软件定义存储的特点。本文只是对存储策略做了一个简要的介绍，让读 者体会存储策略的用途，进一步深入探索可以查看参考资料了解有关 OpenStack Swift 的更多相关信息。