面向云存储服务的分布式测试框架设计与实现

马振威,张海明,温亮明,黎建辉*

1.中国科学院计算机网络信息中心，北京 100190

2.中国科学院大学，北京 100049

引言

随着科学技术的发展，各类软件应运而生，数据传输无处不在，数据也变成现代企业的石油，保存有价值的数据，在需要时候方便快捷地查询数据已是当务之急。现阶段传统的关系型数据库和非关系型数据库已经无法满足日益增长的数据处理需求，在处理巨型文件时，面临超出本地服务器存储上限的瓶颈。此外，一味地增加服务器数量，也会产生巨大的经济成本，无法实现快速、统一的数据管理优化。此时，对象云存储服务应运而生，对象云存储服务是基于对象的海量云存储服务，为用户提供海量、安全、高可靠性、低廉成本的数据存储能力，可以快速地通过Web、API 接口等方式对云存储服务器进行创建目录、删除目录、修改目录、上传对象、下载对象、删除对象等。云端服务器由统一的存储引擎对数据进行专门管理，保证了存储的安全可靠。解除了客户对海量文件的存储难题，用户可以在任何时间、任何电脑、任何地点存储和访问任意类型的数据[1]。

在云存储系统进行测试阶段，现在主要有两大类方式，人工手动测试与自动化测试。手动测试大多依靠测试人员手工完成，由于人工不善于执行重复枯燥的工作，因此手工测试不仅速度缓慢、精确度低，而且出错概率较大，往往会将不准确的测试结果反馈给开发团队。自动化测试是将自动化工具与技术应用于软件测试，由相关程序和算法自动重复执行相同的测试操作，不仅测试结果精准，而且能将测试结果快速反馈给相关人员，有助于以更少的工作量构建质量更好的软件，但是在云存储测试时候也无法完全发挥优越性能。

随着数据规模不断扩大，功能更加复杂，网络带宽紧张，给传统的测试工具带来了巨大压力，以至于无法快速准确的进行测试。分布式测试框架可以根据不同的测试用例，通过中控系统统一指挥调度进行工作，达到完成不同测试用例的任务，分布式系统又可以并发执行，大大节省测试时间。因此分布式测试框架相较人工测试和单节点自动化测试有明显的时间和空间优越性。

1 研究现状分析

目前软件测试和静态分析是两种使用最为广泛的缺陷检测技术[2]，可以检测出系统运行时性能的优劣。软件测试主要是通过大量测试用例进行集中测试，需要提前准备充足的资源；静态分析能在程序较早阶段发现程序缺陷。但是在对云存储系统性能瓶颈检测时候，这两种手段往往达不到理想的效果。针对这一问题，学术界虽然进行了一些探讨，但研究结果相对匮乏：Ma Chunyan 等提出了Stream X-machine[3]模型，该模型能比较直观地观察服务器的测试结果；Ipate F 等提出了RFSM[4]测试模型。以上研究从不同方面解决了Web 服务器测试用例的自动化生成问题，但是并没有解决服务器的并发传输性能问题。鞠炜刚等提出了基于环境资源自动匹配的云测试框架[5]，解决了测试环境的合理利用，但是没有解决根本的高并发问题。众包测试[6]利用到了分布式的思想对软件进行测试，采用请求者与工人的模式进行分布式测试，但是对于云存储系统不能快速的启动工人测试。基于此，本文主要运用分布式测试，对系统传输功能不断增压，从而在系统结构和系统资源上进行优化。通过大量用户长时间同时向服务器传输数据，测试系统接收速率变化，监控和分析资源性能指标。

2 框架设计

本文设计的分布式测试框架整体采用管理-执行(Master-Task)形式。Master主机负责判断区分下传指令或者下传文件来进行算法选择，Task集群负责对实际命令的执行。图1为整个分布式测试框架的结构示意图，整体框架主要包含Master主机维护模块、待测试文件同步系统模块、下达系统命令模块。

图1 分布式测试框架Fig.1 Distributed testing framework

2.1 分布式Task集群部署方案

Task集群节点众多，并且根据测试任务的大小，单次上传的文件可能达到TB级别，所以对集群之间的数据快速备份要求极高，并要求得到快速反馈。因此，传统的单一数据传输和接收模式在效果和效率上显然难以满足需求，传统模式数据以线性的模式进行传输，时间效率为N，在面对庞大数据时候将面临灾难性的考验。本文借鉴Hadoop 生态环境中Spark[7]的管理模式，结合Linux 系统多进程服务，通过分布式部署客户主机，设计了一套基于二叉树递归的传输算法，并在实践中得到了良好的效果。

在实际部署环境中，管理(Master)主机需要将客户端主机上传的文件拷贝到执行(Task)集群上，然后通过集群进行压力测试。首先考虑到中控管理主机性能问题，因为测试环境并不是超级计算机，没有庞大的计算性能，所以同时开启的最高线程数设定为5个，可以并行将待测试文件上传到执行集群中，这是在传统的上传模式上通过Linux 多线程实现，但本质还是线性传输，速度只能提高5倍，在面临上千集群时显然不是理想的。因此，本文采取二叉树递归传输算法进行文件上传，不但降低了中控管理主机的传输压力和负载，而且大幅度缩短了传输时间。

二叉树递归传输算法是利用二叉树的树形结构，将Task集群以二叉树的形式进行逻辑排列，二叉树之间的传输通过Master主机分配任务进行2倍递增的速率，从而将Masker 对Task集群的控制时间从N 变为了log2n，大大缩短了集群启动时间，从而为传输减少了系统等待。先由Master主机向其子Task主机传递一份数据，然后Task主机再将数据下发给它的子节点，以此类推最终达到快速的文件传输，完成Task集群部署。

2.2 Master 中控架构

在自动化测试系统中，Master主机发挥重要作用，它主要负责所有Task主机的控制、文件下发、命令传达、帮助客户端主机管理Task集群等。由于客户端主机想要进行测试任务，首先要经过Master主机将需要的环境部署好，压力测试本身就是一种破坏性的性能测试，随时都有可能使待测试系统崩溃，因此本文设计的测试系统采取了聚合模式，每一个Task集群都可以和Master主机直接通信，保证单个节点的损坏情况能影响到测试的准确性。最后将每一台主机的测试日志整理反馈给Master主机以快速进行系统日志整理，以便检查工作情况。

Master主机具备良好的文件管理性能，其能将所有的文件拷贝到备用(Secondary)主机上，以防止单点故障引发的全系统崩溃，当中控主机发生故障时，Secondary 主机会自动代替中控主机的位置成为新的中控主机并操控Task集群。由于基于操控所下发的命令所占字节较小，因此测试实验中采用了并行传输策略。在进行中控时，Task集群的200个节点对于Master主机而言都是受信任状态并免密接受Master 控制，Master主机向Task集群下达工作指令，Task集群在收到指令后立刻向Master主机反馈成功接收指令并执行工作指令，整个过程的延迟只需要0.1秒。在后续Task集群工作环节，Master主机将每个Task集群的反馈情况记录到日志中，在8 核的Master主机下可以无影响的并发执行8个控制，将命令下达至整个集群耗时仅2.5s，取得了较好的部署效果。

节点修复问题在实际应用中也占据非常重要的地位，只有先确定哪个节点发生故障，才能据此实行解决方案。当收到节点反馈时，中控主机会自动识别未反馈的主机并标注，再次向未反馈主机发送执行命令，如此重复发送3次，如果始终得不到回复，则将未反馈节点列为损坏节点。一般情况下，中控主机无法对执行主机进行控制，主要原因是因为中控主机的权限较低，重新设置免密登陆即可解决。图2为单节点流程控制示意图。

图2 单节点流程控制Fig.2 Single node flow control

2.3 测试框架实现流程

2.3.1 Master主机维护模块实现

Master主机维护模块主要记录Task集群之间的信任关系和控制情况。在进行集群扩展时，只需要在本模块添加记录并更新即可达到快速扩展的目标。主机控制模式采用递归搜索二叉树方式进行遍历整个Task集群。中控主机维护列表如表1。

表1 信任关系Table1 Relationship of trust

每个Task主机都包含私有子节点，Task主机可以对子节点下达命令，私有子节点的地址由如下步骤计算得到。

Begin读取主机IP 地址；将IP 地址写入配置文件；for i = 1..n个节点{本机所控制主机为：主机地址+i*2 and主机地址+i*2+1}End

2.3.2 待测试文件同步系统模块实现

待测试文件同步系统的主要功就是将被测试的文件高效地传输到整个Task集群，以通过集群去完成对象云存储系统的测试分析。在进行文件同步时，用到了上文所描述的Task集群部署方案中的二叉树递归传输算法，可以达到快速部署的目标，具体实现细节如下。

Begin读取子节点IP 地址；scp 传输待测试文件给子节点and scp 传输子节点需要执行的命令}End

2.3.3 下达系统命令模块实现

本模块主要是中控主机对每个集群节点的下达命令传输，通过主机控制执行节点进行工作的命令仅占据KB级别的内存。如果使用递归算法，则时间耗费较大，因此本文采用并行传输方式，由于Master主机对整个Task集群具有控制权限，其会快速地将指令下达给Task集群，每一个正常的Task节点都会收到来自Master主机发送的执行命令，Task节点收到命令后会向Master主机确认接收，Task节点根据接收到的命令执行测试任务，任务执行完毕之后将执行结果等信息一并发送给Master主机，生成完整的日志文件。如果某些Task节点没有执行测试任务，则会被Master主机标记并再次下达命令，3次无法启动将会重启免密登陆服务，然后再次下达命令，如果仍然无法得到反馈结果，该节点则会被记录到日志文件，交由人工判断处理。

3 测试环境

3.1 分布式测试系统环境

本文工作主要通过自行研发的分布式测试框架对系统性能进行测试、分析，框架主要思想也是通过压力测试[8]进行实现。压力测试主要通过对系统加压，让它在极限工作环境下工作，观察运行情况，发现性能缺陷，进而对系统结构进行优化调整。由于响应时间、最大并发用户数、吞吐量和资源利用率可以分别用来衡量软件的及时性、扩充能力和容量、处理能力、运行状态，且系统处理速率越快、吞吐量越大、并发数越多说明系统性能越好，反之越差[9]。因此本文选择并发用户数、持续运行时间、传输数据量三个角度进行测试分析。用户可以通过中控系统的中控主机将要测试的文件以二叉树递归传输算法发送到每个执行节点上进行工作，用户只需要在Master 下达命令即可完成所有Task 测试工作，无需关心每一个Task的运行情况。表2为整个测试系统所用到的主机的详细信息。

表2 测试环境系统信息Table2 Test environment system information

3.2 对象云存储系统架构

实验涉及的对象云存储系统主体架构通过Django 开发框架完成，虽然Django 框架无法满足高可用性，但是结合Nginx 进行负载均衡，对外透明对内平均分配资源，从而达到高可用性。

由于数据的安全性和隐私性问题日益突出[10-11]，为了解决此问题，我们的底层存储采用的是优化的Ceph[12]存储系统。Ceph 集群作为高可用、高扩展、高性能、低成本的分布式存储系统代表，具备很多优越的性能，如其开源特性以及提供块存储、对象存储和文件系统的统一存储能力已在越来越多的企业中得到应用[13]。图3为整个系统的实验环境结构。

图3 实验环境结构Fig.3 Experimental environment

4 测试结果

在对象云存储系统上线之前需要进行大规模测试，对性能进行分析、度量、优化，保证系统上线之后的稳定运行。本文基于上述章节所述的分布式测试框架，通过不同时间段的上传，统计分析出网络高峰期对系统的影响。压力测试作为测量系统瓶颈的主要方式，要求其具备大规模、持续性、并发性等特点。

分布式框架主要目的是快速、便捷、并发的执行任务，快速和便捷在于通过中控系统短时间启动上百个节点工作，并发在于每个节点互不影响、相互独立的进行工作。下面将针对这些特性展开相关测试工作。

4.1 并发测试

分布式测试框架的快速部署源于中控系统通过二叉树递归算法对系统的启动。图4为通过传统模式传输待测试文件和通过二叉树递归传输算法进行待测试文件传输的对比图。

图4 传输算法对比图Fig.4 Transmission algorithm comparison chart

图4中蓝色虚线表示二叉树递归传输算法，红色虚线表示传统线性传输算法。试验中待测试文件的体量为5GB，测试框架之间主机配置和主机之间的连接完全相同，两个主机之间传输文件平均耗时1分钟。中控主机打开5 线程传输时可以同时传输数据给5个执行主机，用时1分钟，但此时中控主机已经要达到饱和状态。通过10分钟部署环境测试，很容易发现二叉树递归传输算法比传统的线性传输算法性能优越，虽然最初2分钟内线性传输算法启动比二叉树递归算法快，但是随着规模增加，尤其是达到10分钟时，线性传输算法只能部署50台Task主机，而二叉树递归传输算法则可以达到1000台Task主机。实验表明二叉树递归传输算法在部署Task主机时候有高效性、合理性。

4.2 单桶测试

对象云存储系统是对象的存储，将对象放到设定的测试桶中，由系统对桶进行管理维护。每个桶的容量以及查询、写入速率是考察对象云存储系统的重要指标。

本次通过模拟200个用户进行传输测试，每个用户单次上传大小为1MB的文件，重复进行1000次传输，预计单桶总文件量达到200000个。测试初期打开查询桶中记录的耗时在1秒之内，基本可以达到用户对系统测试时间的要求。但随着桶中文件数量的增加，查询速率会变得越来越慢，甚至达到了4秒左右，严重影响了用户体验，测试结果如图5所示。

图5 效果对比图Fig.5 Comparison chart of effect

通过测试发现，数据库的选用是影响性能的主要因素，发现的系统瓶颈，为后续工作中调整优化系统结构提供了方向。

4.3 吞吐量测试

由于系统可能遇到大规模用户同时上传数据的问题，因此服务器处理并发数据流的能力是评价系统优劣的重要指标。本节将发挥测试框架分布式的优势，测试系统接收用户数据的性能，通过分布式测试框架模拟200个用户同时向对象云存储系统分别持续传输1MB、100MB、1GB、10GB、100GB 大小的文件，统计所用时间然后进行分析。以1MB 小文件上传为例，其单用户速率可达到4个/每秒左右，每秒钟上传文件数量所占比例如图6所示。

图6 每秒钟上传文件数量所占比例图Fig.6 The proportion of the number of uploaded files per second

在进行1GB、10GB 大文件并行传输测试时，服务器需要持续接收并处理所有用户的数据，此时我们使用团队搭建的大规模监控框架[14]——Zabbix进行观察。在进行长达两个小时的测试中，发现单节点上传速率可以达到0.9Gbps。

本次测试还从不同时间段角度分析系统性能，分别选用周六20:20、周一20:20、周二20:20、周三20:20 通过外网对1MB 大小待测试文件进行上传。外网主机正常传输速率为10MB/s，测试结果如图7所示。

图7 累计用时Fig.7 Cumulative time

通过对比用户在实际网络中的文件传输速率，我们发现在不同时间段内文件传输结果有所差异，其中周六网络高峰期传输速率明显比工作日缓慢，据此可以推断外部环境因素是影响用户体验的重要原因之一。

实验整体表明，本文所设计的大规模分布式测试框架可以高效地对不同大小、不同格式的文件进行同步上传测试，系统整体具有较高的灵活性；可以快速递归启动Task 进行压力测试，节省大量时间；可以在不同时间段进行分布式测试，排查各种影响性能的因素。从而实现分布式测试框架便捷、快速、并发的目标。

5 结语

本文通过自行设计的分布式测试框架从多个角度对云存储系统进行测试，在实际应用中达到了一定的测试效果，对云存储平台的优化具有一定实践指导意义。虽然分布式测试框架前期的搭建需要投入一定的精力，但是这些投入可以得到长期回报，可以减少工作量，保证系统的稳定运行，提高准确性，最终节省成本和时间。

本分布式测试框架在硬件测试上也能发挥稳定的性能优势，如进行硬盘读写速率测试和网卡性能测试时，传统的单物理机测试可能无法达到高性能硬件的峰值，从而产生错误的数据，而分布式测试框架则可以通过多节点同时工作轻松达到硬件峰值，从而快速测出硬件性能。

虽然分布式测试框架在云存储系统和硬盘、网卡等性能测试上体现出较好的效果，但是在对mysql、redis 等数据库进行性能测试时候效果不甚理想，原因在于通过外部环境对数据库注入数据本身有延迟，会干扰到数值的准确性。未来，将继续探索干扰数据传输的外部影响因素，依托机器学习相关算法进一步优化系统响应时间。

利益冲突声明

所有作者声明不存在利益冲突关系。