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

在第1部分中，我们系统地介绍了OpenStack模块组成和架构，并详细讨论了如何基于OpenStack云计算性能测试来分析和收集需求，为下一步测试策略的分析和制定奠定了基础。因此，在本文的第2部分中，我们将讨论如何分析和制定OpenStack云计算性能测试策略，以及云计算性能测试的指标和流程，为第2部分云计算性能测试解决方案的实施做好准备。OpenStack云计算平台各组件性能测试场景的制定应主要考虑各组件在生产过程中日常所承受的负载压力以及极端条件下的负载能力。Rally是为OpenStack定制的开源工具。从前面OpenStack的模块组成和架构描述中我们知道，虚拟磁盘是由磁盘来管理的。

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

OpenStack云计算性能测试策略分析与制定

所谓测试策略描述了测试项目的总体方法和目标。 测试策略的分析和制定主要包括三个方面：（1）性能测试场景的分析和制定以及测试技术和工具的确定； (2)制定试验启动、竣工标准； （三）风险分析和应对计划。

OpenStack云计算的性能测试策略是根据OpenStack云计算平台的结构原理制定相应的测试策略。 通过上系列两节的分析，我们得出OpenStack云计算的性能测试需求由两部分组成： A. 云计算平台各组件的性能测试需求 B. 云计算的性能测试需求虚拟资源。 在（1）性能测试场景的分析和制定以及测试技术和工具的确定方面，这两部分测试需求各有不同的要求，因此分别进行描述。 （二）制定试验启动和完成标准； (3)风险分析和应对计划，这两部分测试需求有共性，因此将它们放在一起讨论。 接下来我们根据之前的性能测试需求分析，制定性能测试策略：

A、云计算平台各组件性能测试场景的分析和制定以及测试技术和工具的确定：

所谓性能测试场景（Scenario）是模拟并发负载操作，通过配置和执行场景对服务器产生负载压力，验证系统各项性能指标是否满足测试要求的技术手段。 性能测试中的场景制定是实施性能测试的基础。 只有正确设计测试场景，才能获得有价值的测试数据。 OpenStack云计算平台各组件性能测试场景的制定应主要考虑各组件在生产过程（产品环境）中日常所承受的负载压力以及极端条件下的负载能力。 因此，组件面临的不同并发用户数以及一定负载下长期运行的稳定性角度来考虑。 为此，我们将设置三组测试场景：

A。 正常压力测试场景：该场景是测试系统正式上线后，在日均负载压力下的性能表现。 场景的设定可以根据需求分析得到。 具体情况取决于系统工作的时间段和在线人数。 当然。 对于云计算，有公有云（Public Cloud）、私有云（Private Cloud）和混合云（Hybrid Cloud）等不同类型的云模型； 或者金融、电商、网络游戏等云系统上的应用业务可能会面临不同的负载压力。 因此，测试场景应根据云系统的预期用户数量和使用模式来确定。 对于OpenStack，可以考虑：建立多少个租户，每个租户下有多少用户，以及用户使用云的方式和频率。

b. Long Run Endurance压力测试场景：该场景是测试云计算系统在持续负载运行下的性能。 测试时间的长短可根据具体需要确定。 如果系统有7*24小时不间断运行的需要，这个场景的测试就显得尤为必要。

C。 系统容量（LoadCapacity）压力测试场景：该场景是评估云计算系统极限负载的测试。 在并发负载压力不会很快上升的情况下，找到系统能承受的最高负载以及出现性能瓶颈时的负载。 健康）状况。 因此，本次测试会面临系统在极限负载下崩溃的情况。

性能测试工具的选择：在前面的需求分析中，我们了解到OpenStack云计算平台的主要组件有Nova、Cinder、Glance、Neutron和Keypair（如果对象存储也是测试对象，也会考虑Swift） ，本文暂未涉及）。 这五个部分的性能测试主要关注组件管理工作的效率，即各个组件负责的虚拟资源生成、查询、删除等执行工作的效率。 一般这些组件的管理都是通过Horizo​​n在客户端进行的，即Web页面的操作。 但对于性能测试来说，不仅需要模拟各个组件的执行过程，还需要模拟多用户并发情况的执行。 这种执行方式只能通过脚本来完成。 虽然我们可以使用RPT、LoadRunner等性能测试工具通过Web页面的方式来操作执行，但这种方式不仅存在测试工具的瓶颈，而且对脚本定制的灵活性也有很多限制。 因此，我们一般可以使用RestAPI的访问方式来实现这一点。 这种方法不仅摆脱了性能测试工具的一些局限性的束缚，而且在脚本语言的选择上也更加灵活。 如果我们想定制场景，可以选择Java、LinuxShell、Python、Ruby等语言进行编辑，在纯脚本环境下也摆脱了性能测试工具本身的性能瓶颈问题。 如果您想选择现有的基于Openstack的工程场景，建议使用Rally作为测试工具。 Rally是为OpenStack定制的开源工具。 开发语言为Python。 它包括OpenStack各个组件的RestAPI操作的测试场景（如下图所示）。

图1. 拉力测试流程图

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

从上一节的性能测试需求分析中我们知道，云计算虚拟资源的性能测试重点关注云计算平台上生成的虚拟资源的工作效率，涉及到虚拟机、虚拟存储、虚拟资源的协同工作。网络。 ，因为如果只独立考虑虚拟机等单一资源的性能，并不是针对云计算中的分布式概念。 这就像测试生产的汽车的性能一样。 我们无法单独测试车轮、底盘、制动器和油门。 相反，我们必须将它们组装起来并测试它们的综合性能。 因此，我们这部分的测试对象将是一个结合了虚拟机、虚拟存储、虚拟网络虚拟资源的虚拟系统。 因此，我们的测试场景应该是：对于分布在虚拟网络中并且已经配备了虚拟存储的多个虚拟机。 对于系统的测试，我们重点关注并发压力负载下的虚拟网络性能和虚拟存储I/O性能。 如果存储还包含Swift部分，我们还应该将对象存储视为测试部分。

A。 虚拟网络性能：通过前面OpenStack的模块组成和架构描述，我们知道OpenStack云环境中虚拟机所涉及的网络链路包括以下几个部分：

同一KVM（Kernel-based Virtual Machine）内的VM（虚拟机）之间的网络通信，即VM与同一KVM内生成的虚拟机之间通过LinuxBridge进行通信（假设虚拟机的操作系统为Linux） ）。

跨KVM的虚拟机之间的网络通信，即一个KVM中生成的虚拟机与其他KVM上的虚拟机之间的通信。

同一VLAN（虚拟网段）内的VM之间的通信。

跨 VLAN 的虚拟机之间的通信。

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 以客户端/服务器模式工作。 服务器端是Netserver，用于监听客户端的连接，客户端是Netperf，用于向服务器发起网络测试。 Client和Server之间首先建立控制连接，传输测试配置和测试结果信息； 控制连接建立并传输测试配置信息后，客户端和服务器之间建立来回测试连接。 通过特殊的流量模式来测试网络性能。

系统虚拟磁盘存储I/O性能有多种工具可供选择，例如fio、iozone等，本文将使用fio作为测试工具。 fio也是一个开源的测试工具，fio是一个非常灵活的io测试工具。 它可以通过多线程或多进程模拟各种io操作，用于对硬件进行压力测试和验证。 它支持不同的I/O引擎。 包括：sync、mmap、libaio、posixaio等。

(2)制定测试开始和完成标准：

A。 测试启动条件应包括：测试环境已到位； 功能测试已结束，不存在妨碍性能测试执行的故障问题； 性能测试用例（TestCase）已经完全覆盖了性能测试需求。

b. 测试完成标准应包括：所有或高优先级的性能测试用例均已执行； 性能测试中发现的所有不符合要求的问题或故障错误（Defector Bug）均已记录； 所有已修复的问题或故障均已重新测试并通过。

（三）风险分析及应对方案：

性能测试过程中将面临的风险和应对计划应包括： 测试环境的故障或不稳定，导致测试延迟； 因未能记录问题或故障错误记录而造成的测试延误需要及时修复； 上述问题的解决方法是联系或通知相应的环境部署团队（DevOpsTeam）或开发团队（Develop Team）进行沟通解决。

云计算性能测试指标

基于以上性能测试的策略分析和制定，如果我们想要达到相应的测试目的，首先要明确性能测试过程中需要收集和监控哪些关键指标。 通常，性能测试关注的指标主要分为：资源指标和系统指标。 如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与测试场景和需求直接相关。

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

1、资源指标：

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

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

磁盘I/O：磁盘主要用于访问数据，所以说到IO操作，有两种对应的操作。 存储数据时对应的是写IO操作，取数据时对应的是读IO操作。 一般用%Disk Time（磁盘进行读写操作所花费的时间百分比）来衡量磁盘读写性能。

网络带宽：一般用吞吐量Bytes Total/sec来衡量，BytesTotal/sec表示为发送和接收字节（包括帧字符）的速率。 要确定网络连接速度是否是瓶颈，您可以将此计数器的值与当前网络带宽进行比较。

2、系统指标：

并发用户数：在某个物理时间向系统提交请求的用户数。

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

超时错误率：这是基于系统事务响应时间的超时错误统计。 即在执行性能测试过程中，检测到客户端向服务器发送请求，且该请求的响应时间超过预设时间，判断为超时错误。 。

不同类型的指标以不同的方式捕获和收集。 例如，通过服务器上的监控工具获取资源指标，如基于Linux Server的top、sar、iostat等； 而系统指标则由测试工具在测试执行过程中收集。 如何具体收集和分析这两个测试指标，将在第三系列解决方案的实施中详细讨论。

云计算性能测试流程

性能测试过程应该包括两个层面，一是测试工作流程，二是测试执行过程。 工作流程侧重于测试执行的规划，执行过程侧重于技术方案的解决和实施。 首先看一下工作流程：

图 5. 性能测试工作流程

从图中我们可以看出，性能测试工作流程包括我们之前讲过的性能需求分析、性能测试计划制定和工具选择。 这些部分以及后续的测试工具选择、测试执行、测试结果分析一般都是由人员独立完成。 测试环境的搭建可以由DevOps团队成员协助，而软硬件配置的调整和优化可能需要引入架构师和开发人员。

对于测试执行过程来说，性能测试一般是基于脚本运行和并发自动化测试。 试验过程中的操作和监控应尽量减少人为干扰。 因此，在设计OpenStack云计算性能测试的自动化脚本运行流程时，需要注意以下几个方面：

1、OpenStack虚拟运行组件的准备：包括相关的VM（虚拟机）、VLAN（虚拟网络）、VDISK（虚拟存储磁盘），以及Tenant、Keypair、SecurityGroup等与用户访问权限相关的资源的准备。

2、测试指标数据收集：在测试执行过程中，使用监控工具对测试线程和被测服务器进行跟踪监控，收集上述资源指标和系统指标。 该步骤根据测试场景和测试工具选择来处理。 有些可以合并到测试运行脚本中，而另一些则需要在测试执行过程中并行执行。

3、测试报告的生成：测试脚本中一般都会有测试报告整理和生成部分，生成的测试报告的文件名会标注时间和测试场景，大大增强了测试的自动化和管理效果性能测试。 。

概括

本文主要阐述3个部分，分别是：

OpenStack云计算性能测试策略分析与制定

云计算性能测试指标

计算性能测试流程

从OpenStack云计算平台性能测试的技术角度出发，详细分析了平台上各工作模块的组成和运行流程，并进一步分析了OpenStack逻辑架构和物理架构。 基于以上分析，有针对性地收集了系统的性能测试需求，为后续云计算平台性能测试的设计和执行奠定了基础。

在本系列的第3篇中，我们将通过一个基于OpenStack云环境的实际案例来详细阐述云计算性能测试的解决方案，包括测试工具的具体应用、测试脚本的分析与架构以及测试执行结果。 分析和部分调整方法。

前言

公司当前网络存在滞后、断线、无法上网、网速慢等问题，导致办公、联络服务响应速度慢。 鉴于目前网络状况对工作的影响，现对计算机网络进行升级。 让日常工作快速顺利进行，不会给日常生产带来不便。

1、需求分析

1.1 公司网络状况

公司网络状况：

1、核心网机房1座，核心交换机1台，接入交换机1台，品牌均为Mercury。

2、一层办公网络涉及的物理线路及20个左右信息点。

3、员工电脑：电脑数量较多，大部分电脑需要定期进行安全检查和性能优化，以发现隐藏的病毒、木马。 当前，随着网络、软件、硬件的快速发展，各种系统软件和安全漏洞的不断出现，静态的网络管理已经不能满足系统稳定性的需要。

1.2 网络对企业的重要性

1.2.1 网络流畅运行的重要性

对于企业来说，计算机的使用率极高，比如汇报工作、下发文件、审批报告、在线学习等，但所有这些工作活动都离不开优质的网络服务和硬件服务。

1、互联网可​​以简化工作步骤。

2.网络可以提高工作效率。

3.互联网可以丰富工作环境。

1.2.2 网络安全的重要性

网络安全是指网络系统的硬件、软件以及系统中的数据不因意外或者恶意原因而遭到破坏、篡改或者泄露，系统持续、可靠、正常运行，网络服务不被破坏。打断了。 具体来说，网络安全要求：保护个人隐私； 控制对网络资源的访问； 确保通过网络传输的商业秘密的机密性、完整性、真实性和不可否认性。

1.2.3 长期维护的必要性

计算机本身和计算机网络的稳定性可以直接影响日常办公工作。 严重的计算机网络故障将直接中断日常业务、搁置待办事项、滞后工作进度，造成不可估量的损失。 如何避免不必要的麻烦和损失？

1、获得网络工程师及时有效的现场支持。

2、对计算机网络进行日常监控和测试，可以有效预防网络故障。

3、定期维护网络设备可以保护公司员工免受网络故障的影响。 针对以上问题，长期的计算机网络维护服务就显示出了其内在的价值。 使用我们的服务将为您的单位带来长期、健康、稳定的计算机环境，强大的专业、全面、系统的支持，以及安全、舒适、安心的办公心情。

2、维护目的

1、保证公司内部计算机网络系统整体顺畅、高效运行。

2、满足全体员工日常工作的网络需求。

3、优化网络资源，合理利用网络信息流量，保障关键业务数据的顺畅运行。

3、维修范围

1、公司网络机房（交换机1台、网络线）

2. LAN线路、接口等。

3.网络健康状况监控与维护。

4. 维修表格

鉴于公司办公室在地理位置上距离网机房较近（约100米），工程师不需要现场不间断支持。

1、如出现网络故障，请贵公司负责人立即联系我们。 工程师将在我公司待命。 接到报修电话后，他们将立即前往现场进行网络维护，直至故障得到有效控制或解决。

2、定期巡检：以月为周期，网络工程师每个周期都会进行一次巡检。 检查内容包括：网络状况测试； 交换机运行状态及日志检查； 收集过去一个月的用户网络使用情况。

5、维修服务内容

5.1 网络维护

5.1.1 LAN状态检测

1、定期检查开关状态（指示灯状态、声音、发热状态）。

2. 提取交换机操作日志，根据记录分析设备运行情况。

3.计算机网络病毒监控。

5.1.2 局域网线路维护

线路是局域网连接的重要组成部分。 线路的连续性直接影响用户对本地网络的使用。 因此，线路维护也非常关键。 线路故障主要有：

1、水晶头与开关的连接状态。

2、水晶头与信息点接口的连接状态。

3、模块接口连接是否良好。

4、双绞线断线。

5、水晶头制作接触不良。

5.1.3 局域网测试

通过测试，可以更加准确、公平、合理地对整个网络进行评估。 检查整个网络的运行状态。

评估整个网络中使用的设备的可靠性、稳定性、稳健性和质量性能。 评估整个网络和系统的参数设置和优化的合理性。 评估整个网络和系统的连通性、稳定性、可用性、安全性等。

5.2 网机房维护

5.2.1 交换机维护

交换机是局域网的重要组成部分。 它可以根据单个用户的要求连接用户线路、通信电路或其他需要互连的功能单元。 它是网络中的关键设备。 交换机的性能决定了网络运行的质量。 交换机的定期维护也是一项必不可少的工作。

密切关注交换机本身的运行状态。 CPU和内存的使用情况是判断交换机状态的重要依据。

定期监控各端口工作状态，确保各端口顺利运行。

5.2.2 机房线路维护

机房是整个办公网络的核心。 机房内的各种线路集中分布在机柜内和地板下。 电缆分为低压电和弱电。 因此，线路的维护和布置也非常重要，科学、整齐。 线路走向将为日常维护工作带来很多便利。

目前需要更新更换的网络产品如下：

网络产品安装总价：7390元

监控维护报价