转载

针对 OpenStack 企业级云计算性能测试标准和解决方案，第 2 部分

第 1 部分中我们系统地介绍了 OpenStack 模块组成和架构，并详细论述了如何根据基于 OpenStack 云计算性能测试的需求分析和收集，这为下一步测试策略的分析和制定打下了基础。所以在本文第 2 部分中我们将论述如何进行针对 OpenStack 云计算性能测试策略的分析和制定，以及云计算性能测试的指标和流程，为之后第 3 部分云计算性能测试解决方案的实施做好准备。

针对 OpenStack 云计算性能测试策略的分析和制定

所谓测试策略就是描述测试工程的总体方法和目标，测试策略的分析和制定主要包含三个方面的内容：（1）性能测试场景的分析与制定和确定测试技术及工具；（2）制定测试启动、完成标准；（3）风险分析和应对方案。

而针对 OpenStack 云计算的性能测试策略就是根据对 OpenStack 云计算平台的结构原理制定相应的测试策略。通过上个系列两节的分析我们已得出针对 OpenStack 云计算的性能测试需求有两大部分组成：A. 云计算平台各组件性能测试需求 B. 云计算虚拟资源的性能测试需求。在（1）性能测试场景的分析与制定和确定测试技术及工具方面，测试需求的两大部分各有不同的要求，所以分别叙述。而（2）制定测试启动、完成标准；和（3）风险分析和应对方案，测试需求的两大部分有共性，所以将合在一起讲述。下面我们就根据之前的性能测试需求分析制定性能测试策略：

A. 针对云计算平台各组件性能测试场景的分析与制定和确定测试技术及工具:

所谓性能测试场景（Scenario）就是模拟并发负载操作的技术手段，通过配置和执行场景向服务器产生负载压力，验证系统的各项性能指标是否达到测试需求。性能测试中的场景制定是实施性能测试的基础，只有合理的设计测试场景才能获得有价值的测试数据。针对 OpenStack 云计算平台各组件性能测试的场景的制定主要应考虑各组件在生产环节（Product Environment）中将要承受的日常负载压力和极限情况下的负荷容量，所以应从组件面对的不同并发用户数及在一定负载下长时间运行的稳定性的角度去考虑。对此我们将设定三组测试场景：

a. 常规（Normal）压力测试场景：该场景是测试系统在正式上线后日常平均负载压力下的性能，场景的设定可根据需求分析得出，具体的要根据系统工作的时段和上线人数来确定。对于云计算来说，不同种类的云模式比如公有云（Public Cloud）与私有云（Private Cloud）还有混合云（Hybrid Cloud）；或在云系统上的应用业务比如金融、电商、网游有可能将会面对不同的负载压力。所以应根据预计的云系统使用人数和使用方式来确定测试场景。针对 OpenStack 可以考虑：将会具体建立多少个租户（tenant)，以及每个租户下有多少用户（User），用户使用云的方式与频率。

b. 长时间耐力（Long Run Endurance）压力测试场景：该场景是测试云计算系统在连续负荷运转下的性能表现，测试时间的长短可根据具体需求来定，如果系统是有 7*24 小时不间断运行的需要，那这个场景的测试就尤为必要。

c. 系统容量（Load Capacity）压力测试场景：该场景是评估云计算系统的极限负荷的测试，在并发负载压力不短上升的条件下，找到系统所能承受的最高负载和性能瓶颈发生时的负载条件。所以该项测试将会面对系统在承受极限负载时宕机的情况。

性能测试工具的选择：之前的需求分析里我们已得知，OpenStack 云计算平台的主要组件是 Nova、Cinder、Glance、Neutron 和 Keypair（如果对象存储也是测试对象，那 Swift 也将被考虑进去，本文暂且不涉及）。而对这五部分的性能测试主要关注的就是组件管理工作的效率，即各组件所负责的虚拟资源生成、查询、删除等执行工作的效率。一般这些组件的管理工作在客户端是通过 Horizon 即 Web 页面的操作来执行的。但对于性能测试而言，不仅要模拟各组件的执行过程，而且要模拟多用户并发条件的执行，这种方式的执行只能通过脚本方式来完成。虽然通过 Web 页面方式我们可以使用 RPT、LoadRunner 等性能测试工具来操作执行，但该方式不仅存在测试工具的瓶颈，而且对于脚本定制的灵活性也有很多限制。所以我们一般可以采用 Rest API 访问的方式来实现，该方式不仅脱离了性能测试工具一些局限性的束缚，而且在脚本语言的选择上也更加灵活，如果想要自定义场景我们可以选择 Java、Linux Shell、Python、Ruby 等语言来编辑，并且在纯脚本环境下也摆脱了性能测试工具本身的性能瓶颈问题。如果想要选择现有的基于 Openstack 工程场景则推荐使用 Rally 作为测试工具，Rally 是专为 OpenStack 定制的开源工具，开发语言为 Python，其包含了针对 OpenStack 各组件 Rest API 运行的测试场景（如下图所示）。

图 1. Rally 测试流程图

B. 针对云计算虚拟资源的性能测试场景的分析与制定和确定测试技术及工具：

我们从上一节性能测试需求分析中得知，云计算虚拟资源的性能测试是关注在云计算平台上生成的虚拟资源的工作效率，这涉及到虚拟机、虚拟存储、虚拟网络各个部分协同工作，因为如果只独立考虑单项资源比如虚拟机的性能，那就不是针对云计算中的分布式概念了。这就好比测试生产出的汽车的性能，我们不能把轮子、底盘、刹车、油门单独地去测，而是要组装好后测试其综合性能。所以我们这部分的测试对象将是虚拟机、虚拟存储、虚拟网络几部分虚拟资源相结合的虚拟系统，所以我们的测试场景应是：面向分布在虚拟网络中已经附带了虚拟存储的若干虚拟机组成系统的测试，该系统我们重点考量的是面对并发压力负载下，虚拟网络性能、虚拟存储 I/O 性能两大部分。如果存储中还包含了 Swift 部分，我们则也要把对象存储视为一个测试部分。

a. 虚拟网络性能：通过之前 OpenStack 的模块组成和架构描述我们得知，在 OpenStack 云环境中虚拟机所涉及的网络环节包括以下几个部分：

同一 KVM（Kernel-based Virtual Machine）内 VM (虚拟机) 之间的网络通信，即 VM 通过 Linux Bridge（这里假设虚拟机的操作系统为 Linux）与在同一个 KVM 内生成的虚拟机之间的通信。
跨 KVM 的虚拟机之间的网络通信，即在一个 KVM 中生成的虚拟机与在其他 KVM 上虚拟机之间的通信。
同一 VlAN（虚拟网段）内 VM 之间的通信。
跨 VlAN 的 VM 之间的通信。
VM 通过 GW（虚拟网关）与外网之间的通信。

图 2. OpenStack 虚拟网络结构图

以上的场景中测试条件的实现都是通过测试 VM 之间的通信情况来获得的，即每个测试单元都要有若干 VM 对，每对 VM 要分出发送测试数据方（Client）和接收测试数据方（Server），测试的过程中还要在网络数据经过节点进行性能监控数据的收集。

b. 虚拟存储 I/O 性能：虚拟存储 I/O 性能决定了在虚拟机上操作过程中文件处理的性能，我们在之前的 OpenStack 的模块组成和架构描述中知道，虚拟磁盘是是由磁盘管理系统来管理的，磁盘管理系统负责从物理磁盘划分和管理虚拟磁盘。目前面向云计算及分布式存储管理系统主要有小型的 MooseFS（MFS），中型的 Ceph 和 GlusterFS 以及大型的 Lustre，不同的磁盘管理系统有不同的工作机制，比如在文件保存上有的支持多副本，而有的是支持镜像；有的支持小文件分片，有的支持大文件分片。所以不同的存储管理系统也要有相对的性能测试场景。我们在这里将以 Ceph 作为测试对象，这一部分主要是测试在数据传输过程中的磁盘的读写性能，在磁盘读写方式上一般分为 4 种模式，即只读、只写、随机读、随机写。

图 3. 基于 Ceph 的 OpenStack 虚拟存储架构图

性能测试工具的选择：

针对系统虚拟网络性能部分我们可采用多种工具，比如 Netperf、Iperf 等，这里将采用 Netperf 为网络性能测试工具。Netperf 是一款开源的网络性能测试工具，主要针对 TCP 和 UDP 传输进行测试。Netperf 以 Client/Server 方式工作。Server 端是 Netserver，用来侦听来自 client 端的连接，Client 端是 Netperf，用来向 Server 发起网络测试。在 Client 与 Server 之间，首先建立一个控制连接，传递有关测试配置的信息，以及测试的结果；在控制连接建立并传递了测试配置信息以后，Client 与 Server 之间会再建立一个测试连接，来回传递特殊的流量模式，用来测试网络的性能。
针对系统虚拟磁盘存储 I/O 性能部分也有几种工具选择，比如 fio，iozone 等，本文将采用 fio 作为测试工具。fio 也是一款开源测试工具，而且 fio 是一个非常灵活的 io 测试工具，它可以通过多线程或进程模拟各种 io 操作，用来对硬件进行压力测试和验证，支持不同的 I/O 引擎，包括:sync,mmap, libaio, posixaio 等。

（2）制定测试启动、完成标准：

a. 测试启动标准应包括：测试环境就位；功能测试已经结束，没有妨碍性能测试执行的故障性问题；性能测试案例（Test Case) 已经全覆盖性能测试需求。

b. 测试完成标准应包括：全部或优先级高的性能测试案例已被执行完毕；所有在性能测试过程中发现的有悖需求的问题或故障错误（Defect or Bug) 都已记录在案；所有已修复的在案问题或故障已被复测并通过。

（3）风险分析和应对方案：

性能测试中将要面对的风险和应对方案应包括：测试环境的失效或不稳定，导致测试的延期；在案的问题或故障错误记录没有及时被修复而导致的测试延期；以上问题解决方案是联系或通报对应的环境部署团队 (DevOps Team) 或开发团队 (Develop Team）予以沟通解决。

云计算性能测试的指标

针对以上性能测试的策略分析和制定，如要达到相对应的测试目的，就必须首先要明确执行性能测试过程中需要收集、监控哪些关键指标。通常情况下，性能测试关注的指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与测试场景及需求直接相关。

图 4. 性能测试监控关键指标说明

1. 资源指标：

CPU 使用率：指用户进程与系统进程消耗的 CPU 时间百分比，长时间情况下，一般可接受上限不超过 85%。

内存利用率：内存利用率=(1-空闲内存/总内存大小)*100%，一般至少有 10%可用内存，内存使用率可接受上限为 85%。

磁盘 I/O: 磁盘主要用于存取数据，因此当说到 IO 操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写 IO 操作，取数据的时候对应的是是读 IO 操作，一般使用% Disk Time(磁盘用于读写操作所占用的时间百分比) 度量磁盘读写性能。

网络带宽：一般使用吞吐量 Bytes Total/sec 来度量，Bytes Total/sec 表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。

2. 系统指标：

并发用户数：某一物理时刻同时向系统提交请求的用户数。

平均响应时间：这是分析被测系统性能的一项重要指标，即系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如通过 RESTAPI 执行虚拟机的生成、查询、删除，或对虚拟磁盘的读写，均可定义为事务。

超时错误率：这是根据系统处理事务响应时间，出现超时错误的统计，即性能测试执行中，检测到客户端向服务器发出请求，请求的响应时间超出了预设的时间并被判定为超时错误。

不同种类的指标捕获收集的方式也不同，比如资源指标要通过服务器上监控工具获得，基于 Linux Server 的比如 top、sar、iostat 等；而系统指标则是在测试执行过程中由测试工具收集而来。两种测试指标如何具体收集和分析，我们将在第三系列解决方案的实施中详细论述。