分布式系统场景注入测试

转载自:http://bigdata.qq.com/article?id=2752

前言

大数据浪潮下，海量数据处理能力的提升是推动大数据不断前行的基础，海量数据处理的分布式系统应运而生，hdfs、hadoop、spark、storm、MQ等等。分布式系统运行的核心是集群化部署，分散化管理，任务均摊，平衡化运行。节点异常、机器异常、运营操作、策略变更都会打破原有的平衡状态进入一种不平衡状态，平台通过状态管理和协议交互逐步演进到另一种平衡状态，同时要保证这种演进过程中系统计算正确性。打破原有的平衡状态的场景非常多，复杂的平衡演进过程中又有很多的场景可能出现，这种交织的变化对分布式系统测试，特别是稳定性测试带来非常大的挑战。

本文将基于本部门内容分布式系统出发，重点介绍分布式系统稳定性测试中的一种应用方法——场景注入测试。

分布式系统测试

测试执行过程可以归纳为构建输入（包括数据和系统场景）、驱动输入、收集结果进行校验（包括系统状态、计算结果），如下图。除海量数据的涌入对系统的稳定性造成很多冲击外，复杂的场景变化也时刻敲打着系统的稳定性。以下将重点分享场景注入测试在分布式系统稳定性测试中的应用。

通过数据驱动分发到两套环境（一套稳定版本环境，一套被测系统环境），对被测系统测试版本环境注入各种场景，通过对比两套环境下的计算结果，挖掘测试版本的系统bug。

场景注入测试思考

数据平台部的TDW集群已达到了8800台规模，其他规模小一些的分布式集群也在几百台的规模。对于节点多、角色多、交互复杂的分布式系统来说，节点异常、机器异常、网络异常、运营操作、扩缩容等等场景不可避免，集群规模越大，场景的交叉出现概率倍数增加，时刻对平台的稳定性进行冲击。既然这些场景不可避免，通过人为地触发这些场景，能提前暴露系统的问题，是一种非常有效的预防措施。

分布式系统的特性是高可用、高容灾能力，那么，节点异常、机器异常、网络异常、运营操作、扩缩容等等场景的出现，都不能影响系统的稳定性运行和任务的正常处理。因此，把系统可能发生的场景进行分类并构建出来，注入到被测系统，并与其他测试手段结合使用，即可以提前暴露系统的问题。

基于以上思路，在数据平台部的很多系统上进行了应用，都取得了很好的效果。

场景注入测试平台架构

鉴于场景注入测试在分布式系统上应用的效果，以及具备场景可重复使用、公共场景可在不同系统上通用、与其他测试方法可相互独立无耦合等特性，着手建设了场景注入测试平台，在简单的后台系统、大规模的分布式系统上都能进行应用。资源异常、网络异常这样的功能异常都已经构建，可以应用到各种被测系统；测试同学可自行丰富被测系统的特性节点异常和运营操作等场景。

场景注入流程：原子操作与集群中的节点相结合组成一个场景；此场景被某个场景注入任务选取并被TriggerServer扫描得到，TriggerServer把此场景的原子操作ID发送给部署在各个节点上的场景执行CaseAgent，CaseAgent接收此消息后从原子操作服务器上把原子操作拉取到本地进行执行，实现场景的触发。

在分布式系统中，集群规模大，节点多，多个场景可能同时发生，例如，一个节点宕，同时网络异常，导致集群无法快速感知此节点状态；一个不平衡状态演进过程中发生其他场景等等，此类多场景同时触发的场景对系统的稳定性考验更大。在平台中通过构建一种多步骤场景来实现多场景同时触发的场景。

原子操作管理

原子操作分为公共原子操作和系统原子操作。公共原子操作由资源异常和网络异常组成，可以被所有系统所用；系统原子操作由节点异常和运营操作组成，可以被此系统所用测试环境中应用（功能测试环境、稳定性环境、准现网环境）。

一个原子操作由两部分组成，操作的发起action和操作的恢复recover。操作的发起action在某个节点上执行就产生某个场景，操作的恢复recover在此节点上执行则此场景恢复取消。

原子操作由单独的服务器管理，通过原子操作名进行区分，CaseAgent从服务器上拉起原子操作到执行节点上执行。

要求执行某个原子操作action，未被recover前，再此执行此原子操作action将失败。例如，原子操作action是让节点cpu消耗到90%的高负载下，如果再此执行action已无意义了。因此设计原子操作action时必须注意此要求。

要求可重复执行recover操作，但效果要相同。例如recover是启动某节点的进程，重复执行多次，节点的进程只能启动一次。要避免重复执行后，导致多个进程被重启。（当然不排除要启动多个进程的场景，希望通过其他方式实现。）

场景操作管理

场景：由原子操作与集群节点组成，相互独立管理。原子操作一旦建设，可以重复利用个，与被测集群节点组合成场景。

单步骤场景操作(单时间内单场景)：仅由单个原子操作与某个节点组合而成，执行过程为先执行action，再执行recover。

多步骤场景操作(单时间内多场景)：由多个场景组合而成，执行过程为先执行所有步骤的action，再执行所有的recover。先执行所有步骤的action是保障多个场景能同时触发。

TriggerServer的任务调度：

选取要执行的场景操作，提交一个场景注入任务，还包含场景执行的用户、任务执行重复次数、场景触发方式等信息

场景执行的用户：场景在某个节点上触发时是以什么用户执行。除网络异常由root来执行tc netem和iptables命令外，其他场景都可以有用户自己指定要执行的用户。

任务执行重复次数：用户可以指定此任务的所有场景的执行重复次数，对于分布式系统来说，很多异常是偶现的，需要多次执行某些场景下才可能偶然出现一次。

场景触发方式：支持两种方式，时间间隔触发和定时触发。时间间隔触发，指定场景之间的执行时间间隔。定时触发，指定场景是按某种定时规则触发，与crontab配置方式一致（当前仅支持分钟和小时）， 帮助系统某种整点时刻下特性与场景的组合触发。

Action和recover间隔：可配置action与recover的执行时间间隔，适应action与recover快速执行、action执行后一段时间再执行recover等场景。

由于系统原子操作与具体的系统耦合性太高，以下仅以公共原子操作为例进行实例说明。

当前机器资源异常，CPU消耗高负载通过无限循环的加乘进程实现；内存不足通过申请指定内存大小，循环执行memset保障其在物理内存中实现；文件/目录不可读通过修改其读写权限实现。网络异常，通过tc netem（tlinux2.0已开启）和iptables两种命令实现。

以CPU消耗高负载为例说明原子操作构建方式：

Cpu_load_make是此原子操作名，对应原子操作目录，包含action.sh和recover.sh，其他几个脚本为action.sh和recover.sh执行服务。

action.sh中要记录action.sh执行的状态（写入runFlag.txt），如果已经执行过，就不能再次执行。

recover.sh执行后把执行状态修改掉，以便下次action.sh能顺利执行。

场景自动生成

除手工构建场景外，平台还提供了自动生成场景的功能，解决大集群情况下重复的配置场景，同时通过自动生成场景提升场景的覆盖度。

场景分为单步骤场景和多步骤场景，场景的自动生成也分单步骤场景的自动生成和多步骤场景的自动生成。

单步骤场景的自动生成：

选取要生成场景的操作原子和操作节点，生成一个自动生成任务。由TriggerServer根据任务的操作原子和操作节点进行差乘生成场景。

多步骤场景的自动生成：

选取已有的场景，生成一个自动生成任务。由TriggerServer根据任务的场景和场景进行差乘生成新的场景。

选取的场景还可以是多步骤场景与多步骤场景进行自动生成场景。随着节点数、原子场景的增加，多步骤场景生成的场景数非常庞大，执行周期非常长；随着步骤的增加，对应场景在现实情况下被触发的可能性也大大降低；建议测试过程中可逐级生成场景进行测试，扫清一级，再生成另外一级的场景。

场景注入实例（tube测试）

在数据平台部，有个分布式tube系统，是个生产消费模式的MQ系统，提供存储外部生产的数据，可被消费者进行消费这些数据，生产和消费的数据在系统稳定情况下保持一致，在异常场景下不保证高一致性，允许少量数据丢失。

这个项目质量保障的重点是无异常情况下生产和消费高一致，有异常情况下数据只允许少量丢失，场景注入是非常有效的测试手段。

对于此系统的重要观察点就是生成数据的一致性，校验分作两种类型，

有损校验（异常场景）和无损校验（无异常场景）。为了方便生产和消费数据校验，把系统运行状态分成稳定运行常态和异常触发状态；场景的触发为定时触发方式，每10分钟触发一次，action与recover时间间隔2分钟，因此稳定运行常态和异常触发状态按5分钟单位交替出现； 5分钟时间内生产的数据打上此5分钟时间戳印记，消费端就可以通过时间戳统计此5分钟消费多少条进行校验了。

在此版本测试中，仅场景注入测试发现bug 19个（严重10个）。

结语

大数据分布式系统的存储与计算集群规模和复杂度在不断增加，带来的稳定性风险也在快速增加，场景注入测试框架可以说是随着互联网的发展应运而生的。在数据为王的未来，系统的可用性需要达到一个更高的层次，场景注入测试将成为了系统测试中不可或缺的一环。数据平台部场景注入测试平台场景可以不断完善支持更多的场景，与其他测试方法独立，又可以相互结合，具有良好的可拓展性和易用性，能够满足的各类软件的测试需求。希望大数据的浪潮下，测试也能一起弄潮前行。