内容


比较虚拟代理与真实代理的性能

在 VM 上运行 Rational Performance Tester 代理,以比较代理的性能等级

Comments
下载 IBM® Rational® Performance Tester 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

云计算的一个重要支柱是虚拟化。面向云的设计师、开发人员和管理员需要弄清楚的一个问题就是 “虚拟组件的性能水平与 ‘真实的’ 物理组件的性能水平相比如何?如果不及后者,该如何解决这个问题”?

本文将介绍对运行在虚拟机 (VM) 上的 IBM® Rational® Performance Tester 代理进行一系列实验的结果,并提供一些有关 “虚拟对真实” 的基本观点。

实验准备

我们介绍了一系列在虚拟机上运行 Rational Performance Tester 代理的实验,并比较了在非虚拟硬件上运行相同测试的结果。在讨论我们使用的虚拟化环境之前,先让我们来了解一下所使用的术语、方法和实验结果。

术语

您只需理解以下术语就可以顺利完成这些实验:

Rational Performance Tester 代理
一种软件,可模拟数千名用户向服务器发送请求的情形。
Vuser
虚拟用户。每个虚拟用户可在测试过程中模拟多个用户。运行中的 vuser 首先要通过一个惟一的用户 id 来执行脚本。在执行完脚本之后,vuser 需要选择另一个惟一的用户 id,并用这个新的身份再次执行脚本。只要 vuser 在运行,vuser 就会重复这个过程 — 选择新用户 id 并执行脚本。
真实代理
运行在非虚拟化硬件上的 RPT 代理。
VM
虚拟机。虚拟代理就是在 VM 上运行的 RPT 代理。
vMotion
当 VM 管理器将 VM 映像从一个物理机器移动到另一个物理机器时。
Plateau
表示一个时间段,在此期间相同数量的 vuser 在测试中处于活跃状态。
TPS
每秒处理的事务量。TPS 和 PPS(每秒页数)可以作为吞吐量的衡量指标而交替使用。
Paravirtualization
一种虚拟化技术,将软件接口呈现给虚拟机,软件接口与基础硬件的接口非常类似,但又不完全相同。

方法论

使用真实的 RPT 代理和虚拟 RPT 代理多次运行相同的性能测试。

性能基准包含许多由不同模拟用户执行的不同的 HTTP 请求。基准以及被测系统并不是本文的重点。本文主要关注生成模拟负载的 RPT 代理。

每个测试包含 3 个模拟 2000 个 vuser 的运行,每次运行的时间为 5 分钟,还包括 3 个模拟 2500 vuser 的运行,时间也为 5 分钟。每个测试分别使用真实代理和虚拟代理各运行两次。

在每个测试中,共有 5 个机器运行 RPT 代理。其中一个机器为真实的机器,只运行 100 个 vuser。该机器是一个比较基准,不会运行太多的负载而造成资源争用。然而,它将运行足够多的 vuser 来生成一个可用的样例大小。这允许我们比较一个轻负载的真实机器、重负载的虚拟机和真实机器。

将对为期 5 分钟的运行进行分析。这三次为期 5 分钟的运行还包含一个 15 分钟的稳定期 (plateau)。时间更长的运行可以为每次间隔提供更多的数据点。更多的数据点意味着平均值更稳定。

我们还做了一个实验,就是在负载测试期间将虚拟代理从一个物理机器上移动到另一个物理机器。我们将这一过程称为 vMotion。

完整结果摘要

在初始测试中,与真实代理相比,虚拟机的响应时间和吞吐量会发生更多的变化。对于基准测试,响应时间是一项衡量标准,这种变化会引起一个问题。后续的分析和实验可以得出一个 VM 网络调优设置,该设置能够减少这种响应时间变化。使用这种调优后,就可以将 VM 用作 RPT 代理。

在迁移虚拟代理 (vMotion) 的实验中,结果显示,在 VM 移动的过程中,响应时间会出现一个峰值。结论就是:不能经常出现 VM 迁移;分析师必须知道何时会发生迁移,因为它会影响测试结果。

现在让我们来看看虚拟环境中的情况。

虚拟环境描述

在 IT 领域,总是可以找到多种方法来解决某个特定问题。设计良好的虚拟化基础架构尤其如此,因为虚拟化环境可以实现无限的可能性。请注意,这里描述的基础架构设计并不是一种 “推荐的最佳实践” 或 “模板环境”,而是尝试创建一种用于所托管的实验室环境的解决方案。

任何虚拟化基础架构都包含三个主要部分:服务器、存储和网络。该环境适用于以下测试:

  • 服务器。服务器由 IBM System x3850 X5s 组成。每个服务器都加载了 4 个 Intel Xeon X7560 CPU 和 512GB RAM。服务器通过物理和逻辑方式划分到不同的集群,每个集群包含 8 个机器。这种机器集群稍后会进行详细介绍。
  • 存储基础架构。这些服务器的存储器包括冗余的光纤通道 SAN 网络结构。这种结构在服务器上使用了双端口主机总线适配器和冗余的机顶式 SAN 交换机,因此具有冗余性。这些交换机随后被连接到一个更大的网络结构,其中包括与多个 IBM DS5300 存储连接网络 (SAN) 相连的上行链路。每 8 个服务器放在一个主机组中,该主机组只能达到 SAN 上的特定逻辑单元数 (LUN)。主机组中的每个主机都只能看到对该组可用的存储器。
  • 网络基础架构。这些服务器的网络包含一个 100MB 管理链路和 4 个 1GB 链路,总共有 5 个以太网连接与每个服务器相连。
    • 100MB 管理链路用于与板载 Integrated Management Module 通信,后者支持对服务器进行远程控制它访问,并能够监视硬件的状态。
    • 4 个 1GB 链路被分为两组,每组两个连接:
      • 第一个分组用于传输虚拟机的数据流量。
      • 第二个分组用于主机服务器的管理流量。

管理流量单独放置在一个私有的内部网络中,而数据流量可以进入更大的公共网络。这样做的目的是为了减少数据网络中的流量,确保管理流量的安全性。每个链接分组都被进一步拆分为一个活动链路和一个备用链路。这种活动链路和备用链路的组合可以确保实现冗余。

要将大量私有和公共网络连接起来,可以使用 VLAN 标记。每个来自给定虚拟机的数据包都将使用相应的 VLAN 号码进行标记。这将能够跨环境实现对大量子网的访问。同时还使虚拟机能够通过迁移过程从一个集群移动到另一个集群。

图 1 显示了虚拟化环境。

图 1. 虚拟化环境
虚拟化环境
虚拟化环境

真实代理运行在具有两个 2.8GHz Intel® Xeon® 处理器和 2GB RAM 的机器上。这些机器有一个 1GB 的以太网卡。

虚拟代理运行了 RedHat Linux®。真实代理运行了 Windows® Server 2003。本来虚拟代理和真实代理运行在相同硬件和软件上会更好一些,但是我们有证据显示,真实代理运行在 Linux 上的吞吐量在不同运行之间会出现低于 1% 的变化。这类似于我们在真实 Windows 代理中看到的情况。

我们用作主控机器的计算机使用了 Intel Xeon,并运行了 Windows Server 2003。它有两个 3.2GHz 处理器,启用了超线程功能,并使用了 3.5GB 的 RAM。它有一个 100MB 的以太网卡,仅运行 100 个 vuser,不需要像其他代理那样具有强大的配置。

结果说明

现在我们将展示一些图片,解释所得结论背后的一些数据;我们还将展示应用网络调优之前和之后的吞吐量和响应时间的变化。

未调优网络的吞吐量和响应时间

第一张图片(图 2)展示了在运行网络调优之前虚拟代理的吞吐量和响应时间。与之形成对比的是第二张图片(图 3),该图为真实代理显示了相同的信息。这些图片来自于 2500 个 vuser 的工作负载稳定期。

图 2. 虚拟代理,未调优网络,2500 个 vuser
虚拟代理,未调优网络,2500 个 vuser
虚拟代理,未调优网络,2500 个 vuser
图 3. 真实代理,未调优网络,2500 个 vuser
真实代理,未调优网络,2500 个 vuser
真实代理,未调优网络,2500 个 vuser

这些图片显示,虚拟代理的响应时间和吞吐量与真实代理相比变化较多:

  • 虚拟代理的响应时间的变化范围为 188.6ms 到 104.5ms;相差 84.1 毫秒。
  • 真实代理的响应时间的变化范围为 148.4ms 到 120.6ms;相差 27.8 毫秒。

VM 代理报告的页面命中率范围在 215.9 PPS 到 219 PPS 之间,相差 3.1 PPS。真实代理的报告范围在 218.5 PPS 和 219.3 PPS 之间,相差 0.8 PPS。这表明,与真实代理相比,虚拟代理变化较大。

调整 VM 上的网络适配器

在第一组测试显示虚拟机的响应时间存在较大的变化后,我们对机器所使用的虚拟网络适配器类型进行了调整:

您可以将它看成是切断物理系统的以太网适配器。

最初,虚拟机被配置为使用一个 “灵活的” 适配器,实际上就是 VMware 允许根据系统需求来选择适配器。这些适配器在理论上是可行的,但在实践中表现并不好。VMware 弃用了这些适配器,而采用了称为 VMXNet3 或 VMXNet2 的适配器。还有一个选择是使用 E1000 虚拟网络适配器,它实际上就是模拟的 E1000 Intel Network 卡。

我们将灵活的适配器替换为 VMXNet3 适配器。这为系统中的所有网络流量带来了性能提升。VMXNet3 适配器从理论上讲是一种泛虚拟化 (paravirtual) 网络适配器。泛虚拟化硬件的原理是将主机 CPU 的任务分流到系统的物理资源中。对于这些泛虚拟化以太网适配器,工作负载将由主机上的 Intel 和 Broadcom 物理以太网适配器进行处理,而不是由主机 CPU 进行处理。这将改善响应时间和吞吐量。

除了对硬件进行修改之外,我们还对客户机操作系统和用来与适配器通信的驱动继续进行了修改。这类似于在安装了新网络适配器后在物理机器上安装新的驱动。对虚拟机也必须执行相同的操作。

图 4 显示,在应用了 VMXNet3 适配器后,响应时间比之前更低。事实上,使用 VMXNet3 适配器之后的测试结果要比其他所有测试的结果都低。报告的 PPS 也有轻微的提高。

图 4. 比较在采用和未采用 VMXNet3 情况下的真实代理和 VM
比较在采用和未采用 VMXNet3 情况下的真实代理和 VM
比较在采用和未采用 VMXNet3 情况下的真实代理和 VM

图片中未显示的信息是:在使用 VMXNet3 适配器后,响应时间的变体也出现了降低。这对于重现每次运行的结果非常重要。

我们得出的结论是,在使用正确的网络设置后,虚拟代理在报告响应时间和吞吐量方面和真实代理一样可靠。

集群和 vMotion

vMotion 是一种 VMware 技术,使虚拟机能够从一台服务器实时迁移到另一台服务器。这样做的目的通常是为了实现负载平衡。在我们的实验中,我们需要在其中一个 5 分钟的稳定期中对一个 VM 进行迁移。我们执行了此迁移,以确定它对虚拟代理报告的数据产生的影响。

每个服务器集群都有一些相同点。每个服务器分组(8 个服务器)都使用相同的硬件类型。集群中的所有机器都使用相同的 CPU、内存、磁盘和适配器。这些共同点对于顺利执行 vMotioning 非常关键。

机器集群还共享相同的配置,比如高可用性和动态资源调度:

  • 高可用性是指虚拟机保持持续运行,避免在出现硬件故障时宕机。如果集群内的某个服务器出现故障,那么该服务器的虚拟机会立即在该集群中的另一台服务器上恢复联机状态。这会最大程度地减少服务中断引起的宕机。
  • 动态资源调度是指虚拟机根据所需资源和资源的可用性在集群内的不同服务器之间动态移动。如果虚拟机需要使用某个主机的 CPU 资源,而该主机的可用资源很少,那么就会将该虚拟机迁移到拥有可用 CPU 资源的其他主机上。或者,通常将所需资源较少的虚拟机迁移走,为资源需求较大的虚拟机腾出空间。

vMotioning 的工作过程是在当前运行状态将虚拟机从一个主机迁移到集群中的另一个主机。虚拟机在这个过程中将保持运行,因此,虚拟机基本上不会体验到中断现象。

在我们的测试中,我们观察到最终用户遇到的最糟糕的体验就是短时间挂起,这与网络传输故障引起的一两个数据包丢失没什么不同。对于实现集成、可用性、功能和其他类型测试,这是一种可以接受的行为,但是对于性能测试,这是一种不可接受的行为,因为某个丢弃的数据包可能会影响测试结果。在使用严格的服务水平协议的生产环境中,频繁地使用 vMotion 也会造成问题。

动态资源调度和高可用性都可以使用 vMotion 过程在不同主机之间迁移运行中的虚拟机,从而提供故障保护或满足虚拟机急迫的资源需求。图 5 显示了正在执行 vMotion 迁移的虚拟环境。

图 5. 虚拟化环境中的 vMotion 迁移
虚拟化环境中的 vMotion 迁移
虚拟化环境中的 vMotion 迁移

在普通环境中,vMotion 不会频繁发生。我们认为比较符合实际情况的实验是对测试期间使用的四个 VM 中的其中一个进行迁移。我们还有第 5 个真实代理,它运行了 100 个 vuser。我们使用该代理作为主控代理,获得不应受 vMotion 影响的某个代理报告的响应时间。

VM 迁移产生的影响非常明显,时间大概持续一分钟。下面的图片演示了这一点。

图 6 显示了迁移期间来自某个 VM 代理的报告。该报告是从拥有 2000 个 vuser 的稳定期获得的。

图 6. 迁移期间的页面响应时间;峰值响应时间非常差
迁移期间的页面响应时间;峰值响应时间非常差
迁移期间的页面响应时间;峰值响应时间非常差

出现 vMotion 时的峰值响应时间非常明显。这一峰值由虚拟基础架构引起,在性能测试中是无法接受的。

接下来,让我们看一下在 15 分钟的稳定期内发生的 vMotion(参见图 7)。

图 7. 稳定期越长,平均测试结果越稳定
稳定期越长,平均测试结果越稳定
稳定期越长,平均测试结果越稳定

稳定期越长,平均测试结果越稳定,并且 VM 迁移产生的影响也越小。然而,仍然可以看到 vMotion 造成虚拟代理产生了更高的响应时间。这一图片显示了整体的平均响应时间,而不是运行 100 vuser 的真实代理的响应时间。

图 7 显示,VM 迁移对报告的平均响应时间有一定的影响。即使四个 VM 中有三个 VM 未发生迁移,发生迁移的 VM 报告的响应时间仍然会很高,使得平均响应时间要高于控制组中真实代理报告的响应时间。

图 7 中未显示的内容是:VM 迁移对所有代理报告的响应时间都有影响。据推测,主要是因为被测服务器无法完成迁移 VM 发出的请求,除非该 VM 已经完成迁移。

总而言之,最好的办法是在虚拟代理上禁用 vMotion。在运行性能测试时,任何无法控制的变化都会引起问题。

如果无法禁用 vMotion,那么一定要能够判断出是否会在测试期间发生 vMotion。虚拟化基础架构提供了日志,可以通过检查日志来判断是否发生了迁移。屏幕截图(图 8)来自 Tasks and Events 的虚拟基础架构客户端软件的内部视图,该图显示了发生迁移过程时的一个 VM。日志清楚地显示一个迁移任务,以及是谁发起该任务,该任务在什么时间完成。

图 8. 使用日志判断是否发生 vMotion(如果您无法禁用 vMotion 的话)
使用日志判断是否发生 vMotion(如果您无法禁用 vMotion 的话)
使用日志判断是否发生 vMotion(如果您无法禁用 vMotion 的话)

图 8 的大图)。

如果系统根据负载动态移动虚拟机,那么该任务将由系统而不是某个用户发起(在本例中为 VISRTP/marshall)。该日志信息还可以通过编程方式,使用 VMware 的 API 和脚本工具进行收集或查看。

需要注意的是,在给定环境中,可以对某些虚拟机禁用动态资源调度。这会增加虚拟机运行受主机宕机影响的风险,不过,对于性能团队,维持稳定的性能要比防止宕机更重要。

结束语

实现虚拟的 Rational Performance Tester 代理是一种可行的配置;然而,需要确保对虚拟化环境进行了相应的调优。网络卡设置对于我们的环境至关重要。

要进行比较评估,最好使用非虚拟化代理进行比较评估,运行与虚拟代理等效的硬件和操作系统。要进行问题确定,最好的做法是提供一组真实代理,最好是运行与虚拟代理不同的操作系统。我们发现,在出现问题或瓶颈时,真实代理可以作为非常有用的控制组。通过对真实代理进行测试,我们就能够找出引起问题的 VM。

如果在测试期间发生 VM 迁移,那么一定要引起分析师的警惕。自动监视 VM 是一种比较好的做法。另一种好的做法是在托管 RPT 代理的服务器上禁用 vMotion。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing, Rational
ArticleID=835488
ArticleTitle=比较虚拟代理与真实代理的性能
publish-date=09172012