摘 要： 随着云计算的不断发展，基于OpenStack的开源云得到了国内外IT厂商的广泛关注。从服务响应时间和服务吞吐量两个维度来对比万兆网卡和千兆网卡对OpenStackSwift对象存储方案性能的影响。在此基础上，模拟Swift采用万兆网卡适配器后在各种场景下的性能表现。进一步，采用固态硬盘检验其对Swift存储性能的影响。最后进行代理节点和存储节点的配比实验，挖掘云存储技术的价值，设计更加符合最终用户需要的云存储解决方案。
关键词： 云计算；OpenStack；对象存储；Swift；性能实验
0 引言
近些年来，诸如微博、在线游戏、在线视频、企业私有云等应用一直保持爆发式的增长，这些应用产生了海量非结构化数据，这些数据以读取请求为主，更新和删除的频率较低，这为传统的纵向扩展存储解决方案在容量扩展、数据使用性能等方面提出了越来越严峻的挑战；而可横向扩展的对象存储解决方案越来越受到市场的青睐。
1 Swift项目背景
OpenStack Object Storage（Swift）是OpenStack开源云计算的子项目之一。Swift并非传统的File System或者Raw Block，而是通过标准硬件构建冗余的、可扩展的、支持多租户的分布式对象存储系统，通过REST API操作对象文件，适合存储媒体库（音频、视频等）、压缩日志文件的存档、备份存档、镜像文件等[1]。
2 实验
2.1 实验目的
验证及优化OpenStack Swift对象存储方案在不同应用环境下的最佳性能、配置及拓扑结构。
2.2 实验内容
（1）在千兆和万兆网络环境分别实验OpenStack Swift存储方案，评估万兆网络环境对OpenStack Swift在各方面的提升情况，包括：系统能支持的并发数量、数据吞吐量的变化情况、系统的稳定性以及系统资源的使用情况。
（2）将万兆网络环境应用于各个场景，检验其性能。
（3）测试固态硬盘存放账户和容器等元数据信息，评估对OpenStack Swift提升情况。
（4）测试代理节点和存储节点的配比，力图找到最佳配置。
2.3 实验环境
本次实验的方案架构如图1[2]所示。
如图1所示，服务端由1台负载均衡服务器、2台代理服务器、8个存储节点服务器组成。客户端由1台收集实验数据服务器和5台压力测试服务器组成。硬件配置如表1所示，软件环境如表2所示。
3 千兆、万兆网络环境对比实验
3.1 实验场景
（1）文件大小：50 KB~200 KB。
（2）操作场景：模拟万维网使用场景，PUT、GET和DELETE操作的比例分别为：5%、90%、5%，持续运行30 min。
（3）网络环境：采用2.3节的实验环境，千兆、万兆测试负载均衡设备分别采用1 GbE网卡、10 GbE网卡。
3.2 实验结果
3.2.1 千兆网实验结果及分析
如图2所示，在千兆网环境下，随着并发数的增加，服务响应时间增长。
如图3所示，在千兆网环境下，随着并发数量的上升，服务吞吐量并无明显变化。
实验结果：（1）负载均衡服务器带宽使用量：在100并发连接情况下，负载均衡服务器带宽使用量为817 Mb/s，理论带宽基本用完；（2）对象存储系统吞吐量：在100、500、 2 000并发连接情况下，整个系统的服务吞吐量在830 op/s左右，并无明显变化；（3）服务响应时间：在100、500、2 000并发连接情况下，呈明显上升趋势，在500并发连接时，数据平均响应时间达500 ms，2 000并发连接时，数据平均响应时间2 s以上。但是所有存储节点服务器的处理器、内存、网络使用率都很低。
实验结论：负载均衡服务器网卡的数据吞吐能力是存储节点利用率的瓶颈。
3.2.2 万兆网实验结果及分析
如图4所示，在万兆网环境下，随着并发数的增加，服务响应时间线性增长。
如图5所示，在万兆网环境下，随着并发数量的上升，服务吞吐量先增加后趋于稳定。
实验结果：（1）负载均衡服务器带宽使用量：在300并发连接情况下，5台压力测试客户端实际使用带宽为4.2 Gb/s，已经接近理论最大输出带宽，而且此时8台存储节点的网卡流量持续在600 Mb/s左右，但是负载均衡和代理服务器的带宽使用率仅在25%左右；（2）对象存储系统吞吐量：持续增加并发连接数量到2 000个，整个系统的服务吞吐量维持在4 500 op/s左右；（3）服务响应时间方面：在2 000并发连接时，数据读操作的平均响应时间在500 ms以下。
实验结论：在超高并发连接时，存储节点的带宽基本用完，而负载均衡节点和代理节点的带宽还有富余，可以通过增加存储节点来应对请求数量的继续增长。
3.2.3 千兆、万兆网络环境实验结果对比
如图6所示，在千兆网环境下，随着并发数的增加，服务响应时间高速增长；而万兆网一直稳定在500 ms以下。
如图7所示，在千兆网环境下，服务吞吐量比较稳定；而在万兆网环境下，随着并发数的增加，服务吞吐量先增加后趋于稳定。
实验结果说明：（1）单纯依靠将负载均衡和代理服务器节点的以太网服务器适配器由千兆更换为万兆，可带来5倍以上的服务吞吐量。按照500 ms的平均响应时间计算，支持的并发连接数为4倍以上。（2）千兆环境的系统吞吐量出现瓶颈，无法满足万维网这样要求大并发的应用场景，需要通过额外手段增加带宽，以增加服务吞吐量。
实验结论：使用万兆网络环境，是提升对象存储性能的一个有效手段。
4 其他场景在万兆环境下的实验
为了充分认证在各种应用场景下的性能，继续在同样的配置下模拟在线游戏、在线视频两个常见应用场景。
4.1 在线游戏托管
4.1.1 实验场景
（1）文件大小：50 KB~200 KB。
（2）操作场景：本场景用来模拟在线游戏托管服务的文件服务，PUT、GET和DELETE操作的比例分别为：90%、5%、5%，持续运行30 min。
4.1.2 实验结果及分析
如图8和图9所示，从实测数据看，系统的平均响应时间随并发数量增加而增长，系统的吞吐量随并发数量增加而增长。
4.2 在线视频分享
4.2.1 实验场景
（1）文件大小：10 MB~100 MB。
（2）操作场景：本场景模拟在线视频分享服务，PUT、GET和DELETE操作的比例分别为：5%、90%、5%，持续运行30 min。
4.2.2 实验结果及分析
如图10和图11所示，实测并发到100后，再增加并发数量，系统的吞吐量并不明显。
5 万兆环境下SSD实验
5.1 实验环境
在基于OpenStack Swift的对象存储解决方案中，当一个容器内对象文件数量很多，由于需要耗费更多时间用于元数据信息的更新，再向该容器内写入新的文件时，系统的整体性能会受到影响，因此，本实验采取了机械硬盘、SSD硬盘两种介质存储元数据来评估SSD给系统性能带来的提升率[1]。
工作负载说明如表3所示。
实验环境：拓扑类似于2.3节，服务端由1台代理服务和8台存储服务构成，客户端由2台机器作为打压服务器。
5.2 实验结果及分析
结果说明：在使用传统机械硬盘时，系统的服务吞吐量在3 500 op/s左右，数据平均响应时间在580 ms左右。采用一块英特尔320系列固态硬盘，用于存储元数据（账户信息和容器信息）后，系统的服务吞吐量增长到4 200 op/s左右，数据平均响应时间缩短到480 ms。
实验表明：使用SSD存储元数据能为OpenStack Swift的对象存储解决方案带来20%的整体性能提升。
6 代理节点和存储节点配比实验
通过以上实验，可以看到实验中配比各角色服务器的CPU、内存、带宽等没有得到充分利用，如何得到最佳的配置，需要进行代理节点和存储节点的配比实验。
6.1 实验环境
文件大小：1 MB。
操作场景：使用6台COSBench打压服务器，持续运行10 min，实验代理节点和存储节点最佳性能、最佳配置和最佳拓扑结构。
网络环境：打压服务器使用Intel X520 10 GbE万兆网卡，存储节点配置8个 7200 RPM HDD。
6.2 实验结果及分析
实验结果如表4所示。
实验结论：（1）1个代理节点时，上传代理节点成为瓶颈，导致存储节点压力小；（2）2个代理节点时，输入和输出总量基本一致，磁盘负载较大；（3）4个代理节点时，输入和输出总量基本一致，磁盘负载较大，吞吐量较2PN场景并无明显提升，此时磁盘为瓶颈，需增加磁盘数量或改变磁盘类型；（4）6个代理节点时，输入和输出总量基本一致，磁盘负载较大，吞吐量较2PN场景并无明显提升，此时磁盘为瓶颈，需增加磁盘数量或磁盘类型。
合理的配置能提升系统的效率，也是整体方案重要的评价指标。
7 结论
制定对象存储方案前，需清晰认识每个版本的特征；根据具体项目定义工作负载、成功率、响应时间等关键指标落实配置及拓扑，获取最佳性能及效率。随着OpenStack Swift的不断完善及发展，相信其会在更多场合得到广泛应用。
参考文献
[1] OpenStack Swift架构[EB/OL].[2014-05-20].https：//swiftstack.com/openstack-swift/architecture/.
[2] Swift官方开发指南[EB/OL].[2014-05-20].http：//docs.openstack.org/developer/swift/index.html.