如何进行 OpenStack 的性能测试及平台功能性测试_百度知道温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
网易杭州 QA Team
务实 专注 分享 做有态度的QA
LOFTER精选
网易考拉推荐
Mirantis对OpenStack的性能测试：高并发创建75000台虚拟机&&
20:12:08|&&分类：
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
5000VMs，100并发
Success Rate %
90 percentile
95 percentile
已有25000虚拟机，250个并发请求（创建虚拟机）。&&
25000VMs，250并发
Success Rate %
90 percentile
95 percentile
测试中出现了瓶颈，通过调整sqlalchemy及haproxy的连接池参数后瓶颈消失。其中，sqlaclchemy的连接数从5调整到100，haproxy从4000调整到16000。
测试中出现了haproxy的失败率上升的现象，这是由于haproxy连接池的连接被用尽导致Pacemaker将虚拟IP地址转移到了另一个controller的节点上。当失败发生后，负载均衡器失去响应。这个问题通过提高haproxy的连接限制而得以解决。
上述准备工作完成后，开始向100,000台虚拟机的目标进发。虚拟机数量逐渐递增：从10,000、25,000、40,000、50,000、75,000到100,000。测试结果显示250个并发请求是系统能维持稳定的最高值。在此基础上追加了150个物理节点，即共有350台物理机，外加3台测试机（controller
server）。
根据前面的测试结果，修正了测试目标，从100,000下降到75,000台。最后，创建75,000台虚拟机共花费了8个小时的时间，下图显示了创建时间（boot time）与正在运行虚拟机个数（the
number of running VMs）间的关系：
已有75000台虚拟机，500并发请求（创建虚拟机）。&&
75000VMs，500并发
Success Rate %
90 percentile
95 percentile
结果中可以看出，500并发请求时，平均时间为197.6秒。
OpenStack可以容纳500个并发请求，并维持在250个并发请求在单个集群中创建75000台虚拟机。
本章中提到的一个重要的成功因素是，测试采用了IBM
SoftLayer的硬件和网络架构，因而很方便的管理了网络连接，也能够很容易的扩展成多个OpenStack集群。
Mirantis下一步打算测试虚拟机中运行的基准测试，针对硬盘和网络IO进行测试。
阅读(2422)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Mirantis对OpenStack的性能测试：高并发创建75000台虚拟机',
blogAbstract:'硅谷创业公司Mirantis不久前进行了一项基准测试，测试在OpenStack \nHavana版本上创建75000台虚拟机的性能数据。就启动时间和成功率而言，当应用250个并发部署75000台虚拟机是最好结果。而测试过程中最高并发请求可达到500个。\n以下内容对该测试的信息进行一些整理，并给出测试结果，供大家了解参考。\n内容整理自：&
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}IBM Bluemix
点击按钮，开始云上的开发！
developerWorks 社区
本文主要描述针对 OpenStack 云计算项目的企业级性能测试标准和性能测试实施的解决方案。这套标准和解决方案为 Openstack 云计算项目开发和部署的性能评估提供参考，为云系统的性能瓶颈排查和调优提供有效的依据。同时该标准和解决方案不仅适用于云计算环境，而且也适用于软件工程领域里分布式或架构庞杂的项目。所以无论您的工作涉及 Openstack 云计算技术还是企业级分布式系统，阅读本文将会对您的工作有所帮助。
, 高级软件工程师,
沃高全现为 IBM 公司 CDL 部门的高级软件工程师，目前在 IBM 云计算项目组从事性能测试和自动化环境部署工作。之前有超过 8 年的软件工作经验，其中包括 3 年的 Java 开发和 5 年的自动化及性能测试工作。曾在复旦大学读研期间发表研究生论文《基于实时可视化数据挖掘的高并发性能监测系统设计与实现》
中我们系统地介绍了 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 等；而系统指标则是在测试执行过程中由测试工具收集而来。两种测试指标如何具体收集和分析，我们将在第三系列解决方案的实施中详细论述。云计算性能测试的流程性能测试的流程应包含两个层面，一个是测试工作流程，一个是测试执行流程。工作流程侧重于测试执行的规划，执行流程侧重于技术方案的解决与实现。首先看工作流程：图 5.
性能测试工作流程从图中我们可以看到，性能测试工作流程包含了我们前面已讲过的性能需求分析、性能测试计划的制定和工具的选择。这几部分和后面的测试工具选择、测试执行、测试结果分析一般由人员独立完成。测试环境搭建可由 DevOps 团队成员协助完成，而软硬件配置调整与优化可能需要引入架构人员和开发人员共同来完成。对于测试执行流程而言，性能测试一般是基于脚本运行、并发的自动化测试，在测试过程中运行与监控应尽量减少人为的干扰。所以在对 OpenStack 云计算性能测试自动化脚本运行流程的设计中，应注意以下几个方面：1.
OpenStack 虚拟运行组件的准备：包括了相关的 VM（虚拟机）、VLAN（虚拟网络）、VDISK（虚拟存储磁盘），还有和用户访问权限相关的 Tenant、Keypair、Security
Group 等资源的准备。2.
测试指标数据的收集：是在测试执行过程中，通过监控工具对测试线程和被测服务器进行跟踪监测和收集上文所提到的资源指标及系统指标。此步骤根据测试场景及测试工具的选择来处理，有的可以合并在测试运行脚本中，有的则需在测试执行时，另行并行执行。3.
测试报告的生成：一般在测试脚本中会有测试报告的整理和生成部分，并且生成的测试报告的文件名会以时间和测试场景标注，这大大增强的了性能测试的自动化和管理效果。小结本文主要阐述了 3 节内容，分别是：针对 OpenStack 云计算性能测试策略的分析和制定云计算性能测试的指标计算性能测试的流程从 OpenStack 云计算平台的性能测试的技术角度，详细解析了在该平台上各个工作模块的组成和运作流程，并进一步分析 OpenStack 逻辑架构和物理架构。根据上述分析，有针对性的对该系统进行性能测试需求的收集，为之后对该云计算平台性能测试的设计与执行打下基础。在本系列第 3 部分中我们将以一个基于 OpenStack 云环境的实践案例为基础，具体阐述云计算性能测试的解决方案，其中包括了测试工具的具体应用、测试脚本的分析与架构、测试执行结果的分析与部分调优方法。
参考资料 ，快速接触 OpenStack 的平台。，具体阐述了性能测试流程。Rally GitHub 上
developerWorks 中国：。
提供了有关云计算的更新资源，包括 云计算 。更新的 ，让您的开发变得轻松，
帮助您成为高效的云开发人员。连接转为云计算设计的 。关于
的活动聚合。加入 ，您可以在这里提问、解答并获取更多有关 Bluemix 的技术问题。加入 ，查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
为灾难恢复构建应用，赢取现金大奖。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Cloud computing, Open sourceArticleID=1030045ArticleTitle=针对 OpenStack 企业级云计算性能测试标准和解决方案，第 2 部分publish-date=966,690 八月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
基于OpenStack的云测试平台
基于OpenStack的云测试平台
相关厂商内容
相关赞助商
1. 云测试平台软硬件环境
1） 硬件设备
考虑到云测试平台一期的服务容量，硬件设备如下表1所示
DL580 G8服务器，每台CPU:4*15C；内存：512G、硬盘：5*900G。
1）CPU必须支持VT技术。
2）为了提高系统的稳定性，我们用4块硬盘做了raid
48口千兆三层交换机
提供内外网连接
吞吐量2048Mbps,4个千兆端口
隔离内外网设备，负责与其他网络互联
表1 云测试平台硬件
2） 软件系统
云测试平台是一套全开源系统架构，我们所用到的框架全部采用开源软件。如表2所示。
为云测试平台提供基础设施服务。
目前社区最新版本为M版，我们决定落后社区一个版本，以保证稳定性。
为云测试平台提供系统级监控。
弥补OpenStack Celimeter不能对硬件资源进行监控。
日志分析平台
ELK由ElasticSearch、Logstash、Kibana以及Nigix组成，分布式日志收集平台。
表2 云测试平台软件系统
2. 云测试平台部署方案
云测试平台一期主要采用两节点部署方案。其中一个节点将担任管理、网络、计算和存储的功能。另外一个节点将充当网络双活以及计算和存储的功能。主要部署结构见图1所示。
(点击放大图像)
图1 云测试平台双节点部署方案
3. 云测试平台逻辑架构
由于OpenStack在云测试平台中将提供基础设施服务。其本身由多个组件构成，企业在实施OpenStack的过程中可以根据自身业务需求选择相应的组件。图2为云测试平台的逻辑架构图。
在IaaS层，我们主要选择了NOVA作为计算资源管理功能、Neutron用于网络虚拟化功能、Cinder用于块存储功能。通过这3个核心组件将硬件的计算资源、网络资源以及存储资源池化。
在PaaS层，OpenStack的Celimeter组件提供VMM级别的资源监控，为了弥补其无法监控底层硬件资源，我们利用Zabbix作为企业级系统资源监控。同时在OpenStack组件升级、通知服务等方面我们也做了一些二次开发。
在TaaS层，主要提供测试服务，我们通过OpenStack的Heat组件，调用其API将日常用到的测试工具与其集成，如测试管理工具TestLink、CI工具Jenkins、以及自动化测试工具Fitnesse。
用户在使用云测试平台的时候可以通过三种方式，访问OpenStack的Horizon组件提供的Dashboard、命令行以及API的方式。二期我们也会定制开发自己的portal界面以提高用户体验和易用性。
(点击放大图像)
图2 云测试平台逻辑架构
4. 云测试平台网络实现方案
网络实现方案是云测试平台的核心技术也是难点之一，在这里简单介绍一下云测试平台的网络实现方式。OpenStack支持4种网络虚拟化实现方案，分别为FlatDHCP、GRE、VLAN、VXLAN。云测试平台主要采用了OVS的VXLAN协议。
VXLAN是将以太网报文封装在UDP传输层上的一种隧道转发模式，它采用24位比特标识二层网络分段。使用VXLAN可以克服VLAN只有4000个可用的VLAN ID的局限。当然对于小型企业私有云VLAN也能满足网络需求。
云测试平台的网络实现方式主要如图3所示。其主要描述了计算节点的上的虚拟机是如何与外网完成通信的。计算节点上主要包括两个网桥：集成网桥br-int和隧道网桥br-tun。其中集成网桥br-int规则比较简单，作为一个正常的二层交换机使用。br-tun作为虚拟网桥，规则稍微复杂。要将内部网包进行合理甄别，将内部带着对应vlan tag网包，从正确的tunnel扔出去；将外部带着正确tunnel号过来的网包改为对应的内部vlan tag。
网络节点负责网络服务的任务，包括DHCP、路由和高级网络服务等。一般包括三个网桥：br-tun、br-int和br-ex。其中br-int和br-tun与计算节点上的两个网桥功能类似。br-ex主要有两个核心接口，一个是挂载的物理接口，如eth0，网包将从这个接口发送到外部网络上。另外是qg-xxx这样的接口，是连接到router服务的网络名字空间，里面绑定一个路由器的外部IP,作为NAT时候的地址，另外，网络中的floatingIP也放在这个网络名字空间中。
(点击放大图像)
图3 云测试平台网络实现方式
2、云测试平台应用
目前云测试平台已经在公司内部上线，目前我们主要为测试中心以及公司其他部门提供以下服务。
(1)& 测试虚拟机申请
云测试平台提供基于kvm的测试虚拟机，同时我们制作做了符合公司软件系统的模板镜像。如测试人员需要一台部署交易系统的服务器，只需要在平台上选择含有交易系统的镜像以及相应配置即可完成测试环境申请。见图4。
(点击放大图像)
图4 测试虚拟机申请
同时由于云平台做到了网络虚拟化，每个测试项目都可以拥有自己的私有网络可避免网络冲突，见图5。
(点击放大图像)
图5 隔离的私有网络拓扑
(2)& 分布式自动化测试
随着自动化测试用例数不断增加，回归测试的执行时间也不断拉长。目前我司交易系统自动化测试用例数已达到8000多个，而且这个数字还在不断增加。
在单台服务器上执行8000个用例需要5到6个小时，这对于被测系统、测试平台以及服务器都产生了交大的压力，测试执行过程往往会发生一些无法预估的异常，如网络丢包、响应超时等情况。同时由于执行时间太长，无法快速反馈测试结果，降低了自动化测试的时效性。为了改变这些问题，我们利用云测试平台实现了分布式自动化测试。
通过将测试用例拆分成不同的模块，将用例分布到不同的云主机上运行，最后通过测试平台将用例执行结果统一收回。分布式自动化测试中我们通过Jenkins实现统一调度。见图6所示。
(点击放大图像)
图6 交易系统用例分布式执行
3、云测试平台监控
（1）运维监控
对于虚拟机的监控，云平台通过OpenStack的Celiometer组件监控虚拟机CPU，内存，I/0指标。但是对于运维级别的监控，OpenStack本身没有提供可监控的组件。针对OpenStack云组件及其整个运行环境得监控，我们采用了开源企业级监控解决方案Zabbix。其负责监控云测试平台各个组件、VMM、OS、网络交换机等云基础资源和服务的运行状态，并且根据需要定制大量的触发器。在故障发生时触发报警机制，通过SMS或者EMAIL等方式通知相关人员。如图7所示是对云平台数据库的监控。
(点击放大图像)
图7 Zabbix对云平台数据库组件监控信息
（2）日志监控
由于云测试平台涉及的组件非常多，每个组件都有自己的日志信息，为了能够方便的查看日志，需要一个中央平台将各个节点上的日志信息收集并解析展现。在云平台的实施过程中，我们采用了业界应用最广的分布式日志框架ELK。其主要由三个开源框架组成，分别为开源搜索引擎ElasticSearch、日志解析组件Logstash、日志展示组件Kibana。此外日志平台还可以运用到如交易系统日志收集以及其他业务系统日志收集。平台架构如图8所示。
(点击放大图像)
图8 分布式日志收集平台
云测试平台是我司测试中心一个重要的基础设施平台，未来我们将在云平台上开展更多的应用，如众测平台、接口适应性测试、全交易链条测试等服务。同时云测试平台也是企业去IOE的一项实施，平台全部采用开源框架设计。2016年我们即将开始云测试平台二期研发项目，届时将有更多的测试服务移植到云平台上，也希望能够为行业提供更多的测试服务。
[1]yeasy.深入理解Neutron & OpenStack网络实现［］
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?