数据中心APM最佳实施

《数据中心APM最佳实施》由会员分享，可在线阅读，更多相关《数据中心APM最佳实施（6页珍藏版）》请在金锄头文库上搜索。

1、数据中心 APM 最佳实施2014-08-10 14:41 佚名听云字号：T | T收赫E3我们介绍过应用性能管理从根本上可以看作是一套基础设施监测工具。因为清楚各项事务处 理任务通过系统时所走路线的状况，才能实现有价值的监测，所以集中精力监测对应用起支 持作用的基础设施组件的状态很重要。同样的，只有了解了最终用户的体验，才能知道应用 是否发挥了应有的作用，因此我们需要了解应用为用户提供的服务好不好。最后，只有将最 终用户体验与基础设施监测联系起来，做出的诊断才有意义，因此，当用户体验不好时，我 们无疑需要到基础设施中寻找根本原因。AD：应用性能管理（Application Performan

2、ce Management，简称APM）最初是一种控制大型机性能的方法， 它的应用贯穿整个系统开发生命周期（Systems Development Life Cycle，简称SDLC）。现在，由于最终 用户的业务处理是靠越来越复杂的应用进行的，因此应用性能管理变得越来越重要了。应用性能管理从大 型机环境进入基于 Web 的分布式环境以后，已经具备了实现端到端管理所必需的环境条件。因此可以全力 关注哪些问题影响了企业应用的性能和可用性，关注如何识别这些问题、如何确定它们的重要性以及如何 解决这些问题。我们介绍过应用性能管理从根本上可以看作是一套基础设施监测工具。因为清楚各项事务处理任务通过系统时

3、所走路线的状况，才能实现有价值的监测，所以集中精力监测对应用起支持作用的基础设施组件的状态很重要。同样的，只有了解了最终用户的体验，才能知道应用是否发挥了应有的作用，因此我们需要了 解应用为用户提供的服务好不好。最后，只有将最终用户体验与基础设施监测联系起来，做出的诊断才有 意义，因此，当用户体验不好时，我们无疑需要到基础设施中寻找根本原因。我们将探讨在数据中心运行中，应用性能管理怎样左右那些在大型机上使用的、一般而言更加结构化的工具和流程，以及应用性能管理如何受到这些工具和流程的左右。数据中心会牵涉到大型机、分布式系统和Web 系统的集成。资源性能管理几乎每一个运行z/OS （大型机）系统的

4、公司都实施了某种级别的性能管理，这些公司可选择的系统和资源监测工具有很多。一般而言，这些工具基于 SMF 数据进行监测、提供报警信号和实现自动化，以此实施系统资源管理。另外，各公司还可能用更加专门化的工具来监测和协调DB2、CICS、Websphere MQ、VSAM等环境。我们接下来马上探讨一套“组件”或平台工具，对一个整体但却很复杂的系统进行监测。一般而言，这些工具能够很好地完成高级资源监测任务，并能够对子系统进行力度更高和更详细的监测。 例如，这些工具能够就参数调整向DB2或CICS专业人员提供良好的反馈信息，从而在特定环境中发现提高 性能的机会。这套在大型机上使用的、相对成熟的工具已经

5、孕育了一种定义完备的资源监测方法。采取主 动性能管理方法（有时也称为MIPS管理）的企业已经获得了显著成果，由于无需为支持效率低下的应用而 升级CPU，因而大大降低了成本。尽管主要的推动力是通过减少指令数来降低成本和防止成本，但是也有 附加好处，如应用执行速度更快和代码质量的提高。尽管主要的关注点仍然是，无论在哪里，只要可能，都要减少指令，但是人们也越来越强调最终用户的感 知了,这是因为技术环境变得更加复杂了（例如：Web、SOA、EDI），企业也需要更好地实现IT与企业目 标的一致性。事务处理的响应时间不再与大型机子系统的性能直接相关；也不能仅因为DB2资源可用，就 认为使用DB2的应用运行

6、良好。而且，今天的企业为达到目标，与重视成本控制一样，非常重视最终用户 体验到的性能。这是大多数大型机性能管理解决方案力不从心的地方，因为这类解决方案主要关注资源监 测、资源协调和纠错。这种局限与我们在分布式环境中所看到的情形相似一一一套工具常常无法识别最终 用户察觉到的应用性能问题。从应用性能管理的角度来看，让最终用户体验也成为进行调整的依据之一，或者进行调整时重视最终用户 体验，我们就可以扩大这些大型机工具的适用范围。这从某种程度上翻转了原来的因果关系。通过管理和 调整由最终用户响应时间衡量的应用性能，我们可以减少被调整应用和事务处理的总体资源需求。不过， 以最终用户为导向的应用性能管理的

7、主要目标不是基于MIPS降低成本，而是实现卓越的用户体验。Apdex： 开始就要明确目标任何项目一开始就确定具体的目标，成功的可能性就会极大地提高，应用性能管理也不例外。就大型机而 言，MIPS管理最佳实施常常以定义非常完备的目标开始，如“降低前10个作业步的CPU使用率”，或“降 低 CICS Region CICSPROD 中事务处理的响应时间”。这些降低成本/防止成本的目标是通过减少资源消耗 实现的，是最基本的管理，企业在考虑基于最终用户感知的应用性能管理之前，要先处理这些问题。应用性能管理的目标也许更难以阐明，然而却同等重要。实际上，人们常常认为应用性能管理目标升级或 发生了转变，因为

8、这些目标随着时间的推移会变得更宏伟。在实现这些目标的过程中，当然需要衡量所取 得的进步，同时还要确保这种衡量对业务是有意义的，例如，可以选择用Apdex性能指数，它实质上是用 从 0（不可接受）到 1（极好）的标度以数字来表示用户满意度。如需更多信息，请登录： www.apdex.org。因此，就可接受的最终用户性能而言，一般的业务要求可以转化成如下的应用性能管理目标： 以Apdex指数来计算，最终用户对在线银行应用的体验将在6个月内达到0.85分（在Apdex体系中，代表“良好”），在18个月之后达到0.94分（在Apdex体系中，代表“极好”）的目标。您最好还是确定实现目标的步骤或检查点，

9、因为我们可以假定，目前的体验没到可接受的程度，或者至少 是不知道到什么程度，而实现这一目标将需要反复改进服务。从这种比较通用的做法开始，我们可以看到，我们需要衡量最终用户的体验，因为这是衡量业务成效的标 准，我们是否取得成功将靠这个标准来衡量。我们还需要衡量支持应用的系统组件的性能，以确定在达到 峰值使用率时可能出现的资源瓶颈，并调整系统，以提高性能。因此，我们需要了解应用在系统中运行所 走过的路线，以及在这条路线上存在的各种相互依赖的关系。根据当前的监测记录和分析，我们可以了解 对这条路线的监测是否全面。我们还要能够将监测结果与最终用户的体验联系起来，及时说明在这条存在 各种依赖关系的路线上

10、，用户体验与监测结果的关系。将应用性能管理作为一个流程来实施和改进接下来，我们考虑面向流程的应用性能管理方法。将六西格玛DMAIC （定义、衡量、分析、改进和控制） 模型作为一种结构化方法，用来实施和改进应用性能管理解决方案，因为在我们向着“极好”的Apdex分 数这个最终目标前进的过程中，需要反复改进这个流程的各个组成部分。在我们检查DMAIC流程时，请记住以下两个最重要的问题，这对有效的端到端应用性能管理解决方案很重要：与业务的一致性一一这是从零开始的、从一开始就考虑业务成果的设计的主要目标。对企业来说，重 要的是以性能和可用性来衡量用户体验。相关性与故障隔离 将基础设施监测上升到应用性能

11、监测的关键是，能够透视根本原因和影响，从而真正了解基础设施衡量标准如何影响最终用户的响应时间，以及因此了解企业的生产率。定义首先，将目标转化为对问题的定义：衡量最终用户感知，让应用用户依据设定的Apdex目标判断最终用户的满意度。这可以通过取样和推断完成，利用综合性或机器人式代理定期执行预定义的、代表典型用户/应用互动的脚本。如果选择了这种方法，那么就应该确保对问题的定义，本质上也就是服务级别协议，能 够清楚地解释这些样本，使这些样本成为可以接受的衡量最终用户体验的指标。对很多环境来说，用一种“无代理”式数据中心专用设备衡量全部应用用户的响应时间，可以覆盖多得多的真实用户，从而能迅速 洞察甚至

12、最深入细致的综合性方法也可能错过的问题。理想情况下，两种方法相结合，可同时获得综合性 衡量方法的受控性和主动性益处以及对真实用户进行被动式衡量的好处。通过监测最终用户感知，可以了解IT对业务目标的支持作用有多大，用户不满意是否频繁出现，以及用户 受挫的程度（如果采用无代理方法）。简言之，这为确定Apdex分数提供了信息。我们还需要支持组件级 性能衡量标准，这既需要了解经过系统的路线，又需要了解一些“正常”行为的基础定义。我们可能想监 测每个服务器的性能状况、每条网络连接的状态以及支持应用的每个流程、程序、区域、数据库等等的状 况。这需要了解应用在满足用户请求时走过的物理和逻辑路线，这条路线也许

13、非常简单，可以在白板上简 要叙述出来，也可能十分复杂，需要详细了解应用的互动过程，也许还要借助反映相互依赖关系的实用工 具。最后，我们要能够展示衡量结果与事件之间的相关性。相关性意味着一种实时关系，例如，在用户体验到 不可接受的延迟时，衡量磁盘队列深度。相关性还意味着对正常行为的了解，即能够比较正常磁盘队列深 度与用户体验到性能问题时测量到的磁盘队列深度。根据这种相关性，就有可能设定一个警报，当然，是 假定这个测量值在引起性能问题上起了作用。从相关性中还可以确定受影响的用户数量或类型，或者也许是对业务流程的影响，因此从相关性中还可以 获得一些业务影响产生的环境信息，并因此知道这种业务影响的代价

14、。有关业务环境的信息有助于 IT 部门 恰当地确定，先对哪些问题做出反应，而且业务环境也被看作是业务服务管理（Business Service Management，简称BSM）不可或缺的组成部分。在流程断成熟的过程中，也许会重新定义问题。也许对问题的定义所涉及的范围变得越来越窄了。例如， 可能有一套特定的事务处理程序对支持业务流程至关重要，那么也许会改进原来的定义，以强调这些特定 的事务处理程序。也许，会针对特定的事务处理程序调整对可接受的响应时间的定义。另一方面，原来的定义所涉及的范围 也许扩大到包括更新的应用组成部分，或原来未考虑的其他有关应用。请记住，您不可能监测所有任务和所有组件的所

15、有可能监测的细节。如果您试图这么做，那么您很快就会 被太多的数据压垮，而且很多数据是无关紧要的。从完备定义的目标开始，就有机会获得可量度的成功、 逐步的改进和适当的扩展。始终将业务目标摆在第一位，然后再将业务目标转化成合适的、对应用起支持 作用的技术应该达到的目标。衡量 我们衡量最终用户的体验，因为用这个衡量标准，我们能够建立 IT 服务器质量与业务目标的联系。我们还 需要衡量基础设施的一些重要的方面。您也许已经有了特定于平台的工具，而且这些工具已经完成了一些 或大多数衡量最终用户体验的任务。您将这些工具组装到一个应用性能管理解决方案中的时候，也是评估 这些工具是否足够灵活、能够满足您的需求的

16、好机会。这些工具监测的衡量标准恰当吗？门限、时间间隔 和警报能恰当地调节吗？这些工具怎样报告信息？这些信息能恰当地集成和展现相关性吗？这些工具为方 便诊断提供了合适的深入研究空间吗？这些工具抓取了适合您的诊断信息吗？在采用更大型的应用性能管 理解决方案的情况下，这些问题是需要各领域专家重新考虑的。几乎与您监测的东西同样重要的是，您不监测的东西。很多系统监测工具和特定于子系统的工具提供成百 上千种衡量标准，但是要确定性能问题，常常仅需要其中的几种衡量标准就可以提供足够的信息。分析通过回顾可用的应用性能报告，详细了解一个应用的时间是怎样用的、用在了哪里，性能分析师可以发现 改进的机会。某些（更加普遍的）性能问题会在大型机系统监控器中相当清楚地显示出来。这些资源限制 可以用各种不同的方式来减轻，如工作量管理器（Workload Manager）定义、作业分类、负载均衡和工作 调度。其他性能