云计算的关键基础是虚拟化。 面向云的设计人员，开发人员和管理员需要问自己的一个问题是：“虚拟化组件的性能水平如何与其“真实”物理对应物相提并论？” “如果存在负面差距，我该如何克服呢？”
本文介绍了在虚拟机（VM）上运行的IBM®Rational®Performance Tester代理上进行的一系列实验的结果，并提供了有关虚拟与“真实”参数的一些基本见解。
我们解释了一系列实验，其中Rational Performance Tester代理在虚拟机上运行，并将这些结果与在非虚拟化硬件上运行相同的测试进行比较。 在检查我们使用的虚拟化环境之前，让我们从使用的术语，使用的方法和结果摘要开始。
简而言之，您将可以通过了解以下术语来进行实验：
Rational Performance Tester代理 模拟成千上万向服务器发出请求的用户的软件。 Vuser 虚拟用户。 每个虚拟用户在测试过程中会模拟许多用户。 正在运行的vuser首先以具有唯一用户身份的脚本执行。 脚本完成后，vuser将选择另一个唯一的用户标识，并作为该新的唯一用户标识再次执行脚本。 只要vuser正在运行，vuser就会重复此过程，以选择新的用户身份并执行脚本。 真正的代理商 在非虚拟硬件上运行的RPT代理。 虚拟机 虚拟机。 虚拟代理是在VM上运行的RPT代理。 vMotion VM管理器将VM映像从一台物理机移动到另一台物理机时。 高原 表示测试期间处于活动状态的相同数量的vuser的时间段。 TPS 每秒事务数。 TPS和PPS（每秒页面数）可互换使用，以衡量吞吐量。 半虚拟化 一种虚拟化技术，向虚拟机提供软件接口，该软件接口与基础硬件的接口相似但不相同。使用真实的RPT代理和虚拟的RPT代理多次运行相同的性能测试。
性能基准涉及由不同的模拟用户执行的许多不同的HTTP请求。 基准测试和测试中的系统不是本文的重点。 本文的重点是生成模拟负载的RPT代理。
每个测试包含三个模拟2,000个vuser的5分钟运行和三个模拟2,500个vuser的5分钟运行。 每个测试使用真实代理运行两次，使用虚拟代理运行两次。
在每个测试中，有五台运行RPT代理的计算机。 其中一台机器是一台真正的机器，仅运行100个vuser。 那台机器被用作比较点。 它永远不会承受足以导致其资源争用的负载。 但是，它确实运行了足够多的vuser来生成可用的样本量。 这使我们能够将轻负载的真实计算机与重负载的VM和真实计算机进行比较。
在5分钟的运行中进行分析。 3次5分钟的跑步也与15分钟的平稳期相结合。 较长的运行可为每个间隔提供更多的数据点。 数据点越多，平均值的稳定性越高。
我们还进行了一项实验，其中在负载测试期间将虚拟代理从一台物理机移动到另一台物理机。 我们称该过程为vMotion。
在最初的一组测试中，虚拟代理报告的响应时间和吞吐量比真实代理报告的响应时间变化更大。 对于具有响应时间标准的基准，这种差异会引起问题。 随后的分析和实验导致VM网络优化设置减少了响应时间的变化。 进行适当的调整后，VM可以充当RPT代理。
迁移虚拟代理（vMotion）的实验显示，在VM移动过程中，报告的响应时间达到峰值。 结论是，VM迁移一定是罕见的。 分析人员必须知道它何时发生，因为它可能会影响测试结果。
现在让我们看一下虚拟化环境。
在IT领域，解决给定问题总是有不止一种方法。 在设计良好的虚拟化基础架构领域中，尤其是其中的可能性几乎是无限的。 重要的是要了解，此处描述的基础结构设计不是“推荐的最佳实践”或“模型环境”，而是试图创建一种适用于为其提供托管的实验室环境的解决方案的尝试。
任何虚拟化基础架构都包含三个主要部分：服务器，存储和网络。 这些测试所使用的环境：
服务器。 这些服务器由IBM System x3850 X5组成。 这些服务器均装有四个Intel Xeon X7560 CPU和512GB RAM。 服务器在物理上和逻辑上都分为八台计算机的群集。 稍后将详细介绍这种机器集群。 存储基础架构。 这些服务器的存储由冗余光纤通道SAN结构组成。 通过服务器上的双端口主机总线适配器和冗余的机架顶SAN交换机，可以使光纤网冗余。 然后，将这些交换机连接到一个较大的结构中，该结构由到多个IBM DS5300存储连接网络（SAN）的多个上行链路组成。 每套八个服务器放置在一个主机组中，该主机组只能访问SAN上的某些逻辑单元号（LUN）。 主机组中的每个主机只能看到该主机组可用的存储。 网络基础设施。 这些服务器的网络由一个100MB管理链路和四个1GB链路组成，每个服务器总共有五个以太网连接。 100MB管理链接用于与板载集成管理模块进行通信，该模块可实现对服务器的远程控制台访问以及监视硬件状态的能力。 四个1GB链接分为两组，每组两个连接： 第一组用于虚拟机的数据通信。 第二组用于管理到主机服务器的通信。管理流量保持与私有内部网络隔离，而数据流量则允许进入更大的公共网络。 这样做是为了减少数据网络上的通信量，并确保管理通信的安全性。 每组链接进一步分为活动链接和备用链接。 活动和备用链接的这种组合可确保冗余。
为了能够连接多个专用和公用网络，使用了VLAN标记。 从任何给定虚拟机离开的每个数据包都标记有适当的VLAN号。 这样可以访问整个环境中的大量子网。 它还使虚拟机通过称为迁移的过程从一个计算机群集迁移到另一个群集。
图1描绘了虚拟化环境。
真正的代理在具有两个2.8GHz处理器和2GB RAM的Intel®Xeon®计算机上运行。 这些机器有1GB以太网卡。
虚拟代理运行RedHatLinux®。 真正的代理运行Windows®Server2003。如果虚拟代理和真正的代理在相同的硬件和软件上运行会更好，但这不是一个选择。 我们确实还有其他证据表明，运行在Linux上的真实代理在两次运行之间的吞吐量变化小于1％。 这与我们在真实的Windows代理中看到的相似。
我们用作控制真实计算机的计算机是运行Windows Server 2003的Intel Xeon。它具有两个3.2GHz处理器。 启用了超线程。 有3.5GB的RAM。 它有一个100MB的以太网卡。 它仅运行100个vuser。 它不需要像其他代理一样强大。
现在，我们将向您展示一些图表，这些图表说明了我们得出的结论背后的数字。 我们将向您显示在应用网络调整之前和之后的吞吐量和响应时间。
第一张图（图2）显示了在应用网络调整之前虚拟化代理报告的吞吐量和响应时间。 可以将其与第二张图（图3）进行比较，第二张图显示了与真实代理相同的信息。 这些图来自2,500个vuser工作量平稳期。
这些图说明，虚拟代理的响应时间和吞吐量报告比实际代理变化更大：
虚拟代理报告的响应时间从188.6ms到104.5ms不等。 那是48.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。 再次，这说明虚拟代理在其报告的数据中显示出比真实代理更高的方差。
在第一组测试显示虚拟代理报告的响应时间有很大差异之后，我们更改了计算机使用的虚拟网络适配器的类型。
您可以将其视为关闭物理系统的以太网适配器。
最初，虚拟机被配置为使用“灵活”适配器，这基本上是VMware允许根据系统需求选择适配器的方式。 这些适配器在理论上非常有效，而在实践中却不太理想。 VMware放弃了它们，而使用VMXNet3或VMXNet2适配器。 还可以选择使用E1000虚拟网络适配器，该适配器基本上是模拟的E1000英特尔网卡。
我们切换了灵活适配器，转而使用VMXNet3适配器。 这为系统的所有网络流量提供了性能提升。 从技术上说，VMXNet3适配器是半虚拟网络适配器。 准虚拟硬件基于将任务从主机CPU卸载到系统物理资源的想法。 对于这些半虚拟以太网适配器，工作负载是由主机而不是主机CPU上的实际Intel和Broadcom物理以太网适配器处理的。 这导致改善的响应时间和吞吐量。
除了对硬件进行此更改之外，还对来宾操作系统及其用于与适配器进行通信的驱动程序进行了更改。 这类似于在安装新的网络适配器之后在物理计算机上安装新的驱动程序。 在虚拟机上必须执行相同的操作。
图4显示，在应用VMXNet3适配器后，响应时间比以前要短。 实际上，使用VMXNet3适配器的结果低于所有其他测试。 报告的PPS也略高。
此图表中未显示的是，使用VMXNet3适配器报告的响应时间变化也较小。 这对于能够一次又一次地再现结果非常重要。
结论是，通过正确的网络设置，虚拟化代理程序可以像真实代理程序一样可靠地报告响应时间和吞吐量。
vMotion是VMware技术，使虚拟机可以在服务器之间实时迁移。 通常出于负载平衡的原因进行此操作。 在我们的实验中，我们在5分钟的平稳期之一内强制迁移其中一个VM。 我们这样做是为了确定将对虚拟化代理报告的数据产生的影响。
每个服务器群集具有一些特征。 八个服务器的每个组共享相同的硬件类型。 集群中每台计算机上的CPU，内存，磁盘和适配器都相同。 这种共同性是vMotioning正常运行的关键。
机器集群还共享配置特征，例如高可用性和动态资源调度：
高可用性是虚拟机保持运行以最大程度地减少发生硬件故障时的停机时间的过程。 如果群集中的一台服务器发生故障，则该服务器中的虚拟机将立即在该群集中的另一台服务器上恢复联机。 这样可以最大程度地减少由于服务中断而导致的停机时间。 动态资源调度是一个过程，通过该过程，虚拟机将根据虚拟机的资源需求和可供其使用的资源可用性在集群中的服务器之间动态移动。 如果虚拟机在可用资源很少的主机上需要CPU资源，则该虚拟机将迁移到具有可用CPU资源的其他主机上。 或者，通常会将资源较少的虚拟机迁移出去，以便为需要消耗更多资源的虚拟机腾出空间。vMotioning的过程通过将处于当前运行状态的虚拟机从群集中的一台主机迁移到另一台主机来工作。 在此过程进行期间，虚拟机将保持运行，因此，虚拟机几乎不会受到干扰。
在我们的测试中，我们观察到最终用户在最坏的情况下会经历短暂的挂断，这与网络传输故障丢失一两个数据包没有什么不同。 对于执行集成，可用性，功能和其他类型的测试，这是可以接受的中断，但对于单个丢弃的数据包可能使结果失真的性能测试，则不是可接受的中断。 在具有严格服务级别协议的生产环境中，频繁的vMotion也可能是一个问题。
动态资源调度和高可用性都可以使用vMotion进程将一台主机上运行的虚拟机迁移到另一台主机上，以提供故障保护或满足虚拟机的即时资源需求。 图5显示了正在进行vMotion迁移的虚拟化环境。
在正常情况下，vMotion不会经常发生。 我们认为一个现实的实验是迁移测试中使用的四个VM之一。 我们还拥有第五个运行100个vuser的真实代理。 我们使用该代理作为控件，以了解某个代理报告的响应时间，该响应时间应不受vMotion的影响。
VM迁移的效果显而易见。 效果持续了大约一分钟。 以下几张图说明了这一点。
图6显示了迁移期间来自一个VM代理的报告。 这是在2,000个vuser高原上进行的。
发生vMotion的响应时间峰值明显。 在性能测试运行期间，由虚拟化基础结构引起的这种峰值是不可接受的。
接下来，将vMotion分析为15分钟的平稳期（图7）。
较长的平稳期提供了更稳定的平均值，并使VM迁移的影响最小化。 但是，您仍然可以看到vMotion导致在虚拟代理上报告的响应时间更长。 该图报告了总体平均响应时间与一个运行100个vuser的真实代理的响应时间相比。
图7图显示了一个VM迁移对报告的平均响应时间有影响。 即使四个VM中的三个未迁移，迁移的VM报告的较高响应时间也导致平均响应时间高于对照组实际代理报告的平均响应时间。
在图7中看不到，迁移VM的影响确实影响了所有代理报告的响应时间。 大概是由于被测服务器的瓶颈导致无法完成由迁移的VM发起的请求，直到该VM完成迁移为止。
通常，最好在虚拟代理上禁用vMotion。 在运行性能测试时，任何不受控制的方差来源都是一个问题。
如果您不能禁用它，那么确定测试期间是否已发生vMotion非常重要。 虚拟化基础架构确实提供了可以检查以确定已发生迁移的日志。 屏幕快照（图8）是从虚拟基础架构客户端软件内部的视图执行的，其中该任务和事件是在其中执行迁移过程的VM的任务和事件。 日志清楚地表明，已执行迁移任务以及发起任务的人员以及任务的完成时间。
（ 查看图8的大图。 ）
如果系统已根据负载动态移动虚拟机，则该任务将由系统而不是用户（在本例中为VISRTP / marshall）启动。 还可以使用VMware的API和脚本实用程序以编程方式收集或检查此日志信息。
重要的是要注意，可以在给定的环境中为某些虚拟机禁用动态资源调度。 这确实增加了基于主机中断而影响虚拟机正常运行时间的风险，但是对于性能团队而言，保持稳定的性能比中断的可能性更为重要。
虚拟化Rational Performance Tester代理是可行的配置。 但是，确保正确调整虚拟化环境非常重要。 在我们的环境中，网卡的设置至关重要。
为了进行比较评估，最好让非虚拟化代理运行与虚拟化代理等效的硬件和操作系统。 但是，对于问题确定而言，优良作法是拥有一组真实的代理，最好运行与虚拟化的代理不同的操作系统。 当出现问题或瓶颈时，我们发现真正的代理商是一个有用的对照组。 通过对真实代理进行测试，我们可以排除VM是造成问题的原因。
如果在测试过程中发生了VM迁移，那么分析师必须意识到这一点很重要。 最好对VM进行自动监视。 最好的选择是在托管RPT代理的服务器上禁用vMotion。
翻译自: https://www.ibm.com/developerworks/cloud/library/cl-agentperformance/index.html
