寻找云中的配给性能瓶颈

测试和分析您的云的配给性能

云配给 (provisioning) 就是指在云基础架构上部署和管理 IT 资源的过程。快速配给是云服务的一项关键性能需求,尤其是在有大量客户同时请求资源时;然而,确定是哪个因素或哪些因素导致配给性能下降非常困难,因为没有现成的工具和方法可以跟踪配给过程中的每个状态变化和执行步骤。本文作者详细介绍了一种配给性能测试方法,您可以使用它判断出现配给性能滞后的位置。

陈 湘文, 性能工程师, IBM

陈湘文是 IBM China Developer Lab 的一名性能工程师,拥有两年多的云项目经验,曾在 IBM 内部刊物和社区站点上发表过几篇关于云计算的论文。



2012 年 11 月 19 日

本文描述了一种配给性能测试方法,您可以使用它判断哪些位置出现云计算配给性能滞后。该配给性能测试的目的是:

  1. 从用户角度以端到端的方式测量总的配给时间。
  2. 当同时存在多个配给时,判断配给时间的趋势。
  3. 将整个配给时间分解为几个部分,从而判断哪些组件和步骤占用的性能开销最多。
  4. 当系统中有许多配给请求时,获得组件级别的排队信息,从而帮助找出瓶颈。

让我们了解一些云配给的基础知识。

云配给的基础知识

云配给是指在云基础架构上部署和管理 IT 资源的过程。它由三种类型的配给组成:

  • 虚拟机配给:包括实例化一个或多个满足应用程序软硬件需求的虚拟机。大多数云供应商都提供了一系列 VM 模板,这些模板具有通用的软件和硬件配给。例如,IBM® SmartCloud Enterprise 支持数百种使用不同处理器、内存和 I/O 性能选项的 VM 类型。
  • 资源配给:将 VM 映射到云中的物理服务器并进行调度。
  • 应用程序配给:在 VM 中部署专门的应用程序,并将最终用户的请求映射到应用程序实例。

客户还可以通过 Web 门户和 API 对自己的资产进行配给,这些资产包括虚拟服务器实例、映像或永久性存储单元。

本文将重点介绍虚拟机配给和资源配给,这是云的两个主要功能。让我们看看配给性能具有哪些挑战。


可以规避的配给性能问题

配给过程非常复杂,因为虚拟 IT 资源和网络元素具有不可预测性。客户经常遇到与配给性能有关的问题,但是很难确定是由哪个或哪些因素引起的。

云客户遇到的一些挑战包括:

  • 不同的云供应商使用不同的配给引擎。用户必须对配给引擎有一定的了解,从而能够有效地与云服务提供商就性能问题进行沟通,并确定问题的根源。
  • 在运行时,可能会出现意想不到的互操作性能问题,这些问题不利于实现顺利的配给。虽然可以对一些中间件组件进行性能测试,然后将它们集成到系统中,但是某些性能问题仅出现在与其他中间件交互之后,或为了满足业务需求而采用特定的配给后才出现的。
  • 在一个大型计算环境(如数据中心)中,IT 资源和网络的可用性、负载、吞吐量都会对性能产生影响。
  • 配给工作流可以变得很复杂并带来性能问题。例如,一个通用配给引擎提供的服务允许提供特定的中间件组件,如数据库或应用服务器。实际的底层配给操作是通过一个特定的引擎脚本或组件实现的。许多操作都包括配给服务,可以集成到不同的配给工作流中。

让我们看一下配给性能测试方法和分析。


配给测试方法和分析流程

我曾效力过的一个团队开发了一种测试方法,该测试方法首先描述一组状态和操作,以便可以独立于所用的特定配给引擎来定义整个配给流程。图 1 描述了这些状态。

图 1. 通过状态和操作而不是使用的引擎来定义配给流程
通过状态和操作而不是使用的引擎来定义配给流程

在提交期间 (Submission Period),用户提交一个请求并得到响应。如果成功调用了配给工作流,那么组件的状态将由 “accept” 变为 “submitted”。配给请求的状态变为 “New”。

在资源预留期间 (Resource Reservation Period),如果无法预留所有必需的组件,那么将无法配给完整的解决方案,并且配给流程将中止。要预留某个组件,该组件的状态将从 “Not Available” 变为 “Reserving”。如果预留成功,将返回一条预留消息,并且组件的状态更改为 “Reserved”。

在配给期间 (Provision Period),只要配给引擎已完成所有必要的步骤来设置组件,那么将发送一条配给信息,并且组件状态变为 “Provisioned”。一旦某个组件完成配给,它的所有属性都可以通过运行的自定义日志获得。

在本文中,我将进行两个测试:基准测试和负载测试。

基准测量对于实现有效的测试非常必要。我建议测试一些具有不同类型和大小的映像。在基准测试中,将记录这三个阶段的总配给时间的划分,并对每个状态变化使用时间戳。通过按请求计算周期持续时间,您就能够大概了解哪个部分占用的时间最长。还会收集虚拟机的计算能力数据和操作系统版本数据,以便检测特定映像配给的配给问题。

负载测试模拟了多个配给,可能引起更长的配给时间。在运行负载测试时,您将监视组件活动来寻找系统瓶颈。每个组件状态更改的时间戳会得到记录。使用相同类型的映像作为配给目标可以实现更清晰的比较,并展示时间趋势。观察配给持续时间随并发配给的变化,这会帮助您监视组件级的事务行为。

团队根据用户的端到端工作流程开发了测试脚本。该脚本发送一个配给请求,并一直跟踪配给状态,以便确定配给是成功、失败还是超时。性能测试工具,如 Rational® Performance Tester,可用于触发配给工作负载并捕捉用户端数据,比如请求级别上的映像配给和配给周期。大多数配给和管理引擎及工具都提供了资源和组件操作的本机方法。

因此,在使用此类工具时,客户可以记录对哪些引擎执行了哪些操作,以及调用了哪些服务/端点,然后会根据这些数据计算每个组件级别的配给周期。使用 Python 和 VBscript 进行日志分析和报告生成。


监视工作流组件的行为

下一节将介绍一些使用 SmartCloud 来测试云配给性能的用例。但是首先让我们看一下图 2,它包括配给工作流中的关键组件以及用于监视这些组件行为的界面。

图 2. 配给工作流中的关键组件
配给工作流中的关键组件

配给提交期主要发生在 WebSphere® Application Server 中。团队使用日志和请求指标来跟踪各个事务,记录每个主要 WebSphere Application Server 组件的处理时间。

您可以使用 Web 控制台、API 和查询数据库来收集配给项目和预留工作流的响应时间。IBM Tivoli® Service Automation Manager/IBM Tivoli Provisioning Manager (TSAM/TPM) 服务器允许用户请求、创建、删除、修改和管理虚拟资源。资源预留将出现在 TSAM/TPM Server 中。

配给周期将出现在 Provisioning Manager Deployment Engine 中。Tivoli Provisioning Manager 将收集 “调试” 信息,其中包括每个工作流调用另一个工作流的时间。Tivoli Provisioning Manager 上的工作流状态屏幕允许您访问运行时配给文件/调试数据,后者提供了有关工作流的详细信息,例如工作流的流向以及时间花在了哪些环节。如果应用程序中存在瓶颈,您可以分析这些数据,了解这些瓶颈具体存在于哪些组件中。此外,您可以设置 IBM Tivoli Monitoring 服务器来控制和配给资源、可用性和性能。


用例结果

让我们看一下对三个用例使用这种测试方法的结果:

  • 单个 VM 配给
  • 在 WebSphere Application Server 上提交多个配给请求
  • 多个配给引起总配给时间的增加

单个 VM 配给

问题:在基准测试中,某种映像配给在配给期间会花费很长的时间。

细节:配给周期主要包括 Tivoli Provisioning Manager Deployment Engine 和虚拟机管理程序中的处理时间。您可以利用 Tivoli Provisioning Manager 工作流日志来查看每个处理步骤。

步骤:

  1. 使用 API 获得配给请求的请求 ID。
  2. 获得服务请求,该请求是根据您的请求在 Tivoli Service Automation Manager viewer JINSIGHT 上创建的。
  3. 寻找工作流中占用时间百分比最高的步骤(参见图 3)。
图 3. 使用 JINSIGHT 形象地展示部署流程
使用 JINSIGHT 形象地展示部署流程

在图 3 中可以看到,在该工作流中,复制克隆映像的时间百分比为 24.7,配给磁盘的时间百分比为 22.5。在配给磁盘的过程中,最耗费时间的步骤是检查启动状态。

在 WebSphere Application Server 上提交多个配给请求

问题:当同时提交多个配给时,提交响应时间会显著增加。

细节:提交周期主要包括在 WebSphere Application Server 上的处理时间。您可以收集并分析跟踪日志,从而了解每一个处理步骤。

步骤

  1. 将相关的类设置为 detail log 级别。
  2. 获得每个配给的提交周期持续时间。
  3. 记录第一次提交和最后一次提交的时间戳。收集这两个时间戳之间的跟踪日志。
  4. 在每个配给处理流程中,分析每个处理步骤开始和结束时的记录。
  5. 寻找更耗费时间的步骤,并通过画图反映响应时间趋势。比较这些图表,寻找使总体提交时间增加的步骤(参见图 4)。
图 4. 总的提交响应时间
总的提交响应时间

对这 13 个请求分析跟踪日志后,您会发现最耗费时间的步骤是执行 OSS 调用,该调用用于与 Tivoli Service Automation Manager 服务器交互。因此我为这个步骤画了一条线:

  • 红线表示每个配给的总提交响应时间。它在 7 次提交后显著增加。
  • 蓝线表示发出 OSS 调用的响应时间,它非常稳定,这意味着它与总体响应时间的增加没有关系。

接下来,发现第二个最耗费时间的步骤,然后绘出时间趋势表来进行比较。

多个配给引起总体配给时间增加

问题:当系统中存在多个配给时,总的配给时间将会增加。您可能希望了解哪些周期最耗费时间,以及哪个组件会造成瓶颈。

细节:您可以使用配给负载测试报告,该报告显示了三个周期的持续时间的变化,以便找出最耗费时间的周期。使用名为 “Provision a virtual machine component level workflow” 的图表来找出可疑的组件。使用现有的监视工具(比如 Tivoli Service Automation Manager 控制台、Tivoli Provisioning Manager 控制台和 Tivoli Provisioning Manager DB)来获得每个配给的等待时间和服务时间。构建一个队列模型来找出瓶颈。

步骤

  1. 使用基准测试工具启动多个配给。
  2. 从门户数据库为这些配给获得 Tivoli Service Automation Manager 后端 ID。
  3. 将后端 ID 传递给 SQL 脚本,查询 Tivoli Provisioning Manager 数据库,以便随时收集信息。
  4. 根据 Tivoli Provisioning Manager 数据库的数据计算每个组件的实时请求服务的数量、工作流数量、平均服务时间和等待时间。
  5. 构建一个队列模型和流程来发现瓶颈。

在图 5 中,您会发现同时发送的 20 个配给存在较大的响应时间差异,即使它们请求的是相同的映像类型和大小。

图 5. 总的配给时间
总的配给时间

在图 6 中,您会看到预留周期内的响应时间显著增加了,这会造成总体配给时间的增加。

图 6. 三个配给的响应时间
三个配给的响应时间

提交周期和配给周期的响应时间较稳定,在这种情况下,您应该继续将第二个周期映射到组件级工作流来找出性能瓶颈。

第二个周期主要包括 TSAM/TPM 服务器上的处理时间。您可以使用 Tivoli Service Automation Manager 控制台来查找服务请求,并使用 Tivoli Provisioning Manager 控制台来查看部署流程。对于多个配给,使用 SQL 脚本直接访问 Tivoli Provisioning Manager DB 是最便捷的解决方案。

您可以绘制一个流程图(参见图 7),其中每个组件的队列大小基于分析数据库中原始数据后计算得出的数值。

图 7. 流程图显示了每个组件的相对队列大小
流程图显示了每个组件的相对队列大小

在流程图中,您看到预留组件可能有多个等待请求。Tivoli Provisioning Manager Deployment Engine 只能同时配给 5 个虚拟机,这样才能确保管理程序的性能。即使您试图改进 TSAM/TPM 的容量,也只有 5 个配给可以进入管理程序;更多的配给会被阻塞到第二个周期。


结束语

我的团队提出的测试方法基于通用的配给框架,可以结合不同云供应商的现有监视解决方案,帮助用户找出配给性能问题,无需依靠配给引擎提供的详细信息。

有了配给工作流和组件之间的映射关系,用户就可以告诉供应商哪个组件有可能出现性能问题。

通过使用本地的监视工具和接口,云供应商可以快速确定哪些端点上的哪些配给步骤以及哪些配给服务会对整个配给过程产生了影响。

在这个配给测试方法中,仍然有几个需要改进的地方:

  • 应当收集更多的性能指标和数据,并按照时间、位置和关系自动对它们进行分类;这使用户对问题有了更加清楚的了解。
  • 应当为不同的云供应商集成更多的本地监视工具和方法。在设置特定的配给引擎后,会自动创建前端用户数据与后端组件数据之间的映射关系。
  • 该测试应当涵盖更多的配给行为,比如动态配给、解除配给和应用程序配给。

参考资料

学习

获得产品和技术

讨论

  • 加入 developerWorks 中文社区。浏览开发人员推动的博客、论坛、组和维基,并与其他 developerWorks 用户进行交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing, Tivoli, WebSphere
ArticleID=846365
ArticleTitle=寻找云中的配给性能瓶颈
publish-date=11192012