WebSphere Virtual Enterprise 和服务水平区分

本文讨论 WebSphere Virtual Enterprise 在服务水平区分方面的行为以及如何创建适当的配置。

Benjamin Parees, 软件工程师, WSO2 Inc

Ben PareesBen Parees 当前是 IBM 的顾问软件工程师。过去六年他作为软件工程师在 IBM 工作。前两年参与 WebSphere Business Monitor 产品的数据库体系结构设计,其中大量采用了维建模技术。



2010 年 2 月 11 日

WebSphere Virtual Enterprise 中的服务水平区分

服务水平区分(Service level differentiation) 是指某些请求的优先级应该比其他请求高,从而保证更重要的应用程序的可用性,或者为更重要的用户请求提供更短的响应时间。WebSphere Virtual Enterprise 有许多相互协作的组件,让管理员可以在自己的应用程序环境中使用服务水平区分,可以根据管理员提供的优先级和系统的动态状态管理可用的服务器处理能力。本文讨论 Autonomic Request Flow Manager,它可以在资源有限的情况下限制低优先级的请求流。


Autonomic Request Flow Manager 简介

Autonomic Request Flow Manager (ARFM) 是 WebSphere Virtual Enterprise 的核心组件之一,它决定优先处理哪些请求以及何时处理,从而提供服务水平区分功能。这些决策基于对到达的请求流、可用服务器处理能力和用户定义的服务目标的动态分析。

注意,在提到服务器处理能力时,ARFM 考虑能够为请求服务的整个应用服务器集(即集群),而不是单一服务器(除非只有一台服务器能够为涉及的请求服务)。

图 1 说明处理请求的过程。当请求进入 On Demand Router 时,ARFM 把它们放在队列中并决定什么时候把它们分派给后端应用服务器。如果现有的资源不足以同时处理所有请求,这个排队过程会根据管理员定义的优先级,让高优先级的请求优先得到服务。排队的请求的响应时间会增加,因为在得到服务之前它们会在队列中花费一段时间。

ARFM 根据与请求相关联的服务策略从队列中取出请求。服务策略(service policy) 由请求模式和与此模式匹配的请求的期望响应时间目标组成。服务策略还包含一个重要性值,它直接转换为将分配给与此服务策略相关联的请求的优先级。

ARFM 对可用的后端资源和队列中等待的请求进行对比。

它根据可用的资源选择要分派的请求(如果有的话)。另外,如果 ARFM 认为增加处理能力可以降低排队的请求数量,它可以请求更多服务器进入在线状态。下一节详细讨论这个功能。

关于这种行为的更多信息参见后面的 “参考资料”。以后的一篇文章将详细讨论 Application Placement Controller 组件,它负责根据 ARFM 报告的负载需求启动和停止服务器。

图 1. On Demand Router 请求流
图 1. On Demand Router 请求流

ARFM 如何管理处理能力

对于每个控制周期(默认周期为一分钟),ARFM 会分析系统当前的状态,包括检查可用的服务器处理能力、当前的请求流需求、此请求流的处理能力需求以及此请求流的期望响应时间。它根据这些信息计算每个服务策略的 “分配”,服务策略的设计目标是在有足够的服务器处理能力的情况下确保满足服务目标。

这些分配采用的形式是,对于每个服务策略,每次可以同时发送给应用服务器的请求数量。对于某个服务策略,如果到达的请求数量超过了并发分配允许的数量,那么为了不超过并发限制,多余的请求会留在队列中,直到现有的请求完成,而不是马上从队列中分派出去。

在为服务策略决定分配时,ARFM 首先判断应用服务器上有多少处理能力可用,以及各个服务策略产生的预期 CPU 需求(根据历史数据预测属于某一服务策略的请求的请求速率和 CPU 需求)。

然后,ARFM 尝试优化每个服务策略的分配。它根据(基于历史观察)预期的请求流需求以及为此类请求服务所需的时间,预测对于这个服务策略会发生多少次排队。预期的服务时间(在正常负载条件下为请求服务通常花费的时间)和为此类请求流定义的服务目标之间的差,就是 ARFM 可以让请求排队而不会违反服务目标的时间量。也就是说,如果有足够的处理能力,在队列中的时间加上在应用服务器上实际为请求服务的时间应该小于配置的服务目标。在为每个服务策略计算并发分配时,ARFM 会尽可能减小排队对系统总体响应性的影响,避免违反服务目标。(如果没有足够的处理能力,ARFM 会做折中的决策,考虑违反哪些服务目标,争取获得比较好的效果。)

在分析请求流时,ARFM 假设在后端服务器未过载时记录的服务时间代表最佳预期服务时间。它不考虑相同或不同服务策略的服务之间的争用,也不考虑对数据库等后端资源的争用。

我们来考虑一个场景,其中有两类请求流,gold 和 bronze。在这个场景中,gold 请求流比 bronze 请求流更重要,这两类请求会在同一个后端数据库上产生负载。现在考虑一下,如果后端数据库过载,而应用服务器仍然有可用的处理能力,这时候会发生什么情况?gold 请求流的响应时间会由于数据库过载而增加,可以通过限制 bronze 请求流来改善,但是 bronze 请求流并不会排队以缓解数据库争用,这会导致 gold 请求流的响应时间增加。这是因为应用服务器(即 ARFM 管理的资源层)并没有过载。ARFM 分析 gold 请求流,由于它现在看到的实际服务时间增加了,它会提高预期服务时间。从 ARFM 的角度来看,应用服务器没有过载,所以在 gold 请求流中看到的服务时间增加现象是由于为 gold 请求流服务所需的时间发生了根本变化。这常常给用户带来困惑,他们认为在这种情况下 bronze 请求流应该排队,但是 ARFM 无法判断 bronze 请求流增加和 gold 服务时间增加之间是有联系的。ARFM 只管理第一层的处理能力,而纠正这种情况需要了解更深层上的资源利用率。如果 gold 和 bronze 请求争夺应用层上有限的 CPU 周期(即应用服务器的 CPU 利用率超过 90%),那么 ARFM 会像用户预期那样让 bronze 请求流排队。

实际上,ARFM 只会通过两种措施防止违反服务目标。第一种是,对于某一服务策略的请求,减少请求在队列中停留的时间(从而减少总响应时间)。但是,这种措施只能用于 ARFM 正在让此服务策略的请求流排队的情况,而前面的示例不是这种情况。另一个措施是建议 Application Placement Controller 在动态集群中启动更多服务器,从而提供更多处理能力。但是同样,只在请求当前正在排队的情况下,如果 ARFM 认为有更多的处理能力就可以避免排队,从而减少请求的响应时间(省去了以前花在队列中的时间),有希望以这种方式防止违反服务目标,ARFM 才会做出这一决策。

在 ARFM 没有把请求流排队,应用服务器有可用的 CPU 处理能力的情况下,ARFM 不会采取措施来满足服务目标,因为从它的角度来看已经尽可能快地为请求服务了。也就是说,请求的响应时间并没有由于排队或应用服务器处理能力不足而增加(在上面的示例中,响应时间增加是由于数据库处理能力不足),所以排队/阻塞其他请求流或增加更多处理能力并不会改善状况,现有的处理能力还未完全使用。

关于 ARFM 的行为还有一点要注意:ARFM 以 CPU Overload Protection 值作为阈值,超过这个值它就认为处理能力不足以为所有请求服务,一部分请求应该排队(见图 2)。在默认情况下,这个值设置为 90%,这意味着在应用服务器 CPU 利用率即将超过 90% 之前 ARFM 不会让任何请求流排队。降低这个值会降低 ARFM 允许发送给后端的请求流量。实际上,这会导致 ARFM 让更多请求排队,因为它实际可用的后端处理能力少了。这在某些情况下是有用的,例如如果知道当应用服务器的利用率达到 50% 时数据库资源就会过载。可以把过载保护值设置为 50%,从而有效地防止数据库过载。这是一种使用 ARFM 间接地管理更深层资源的方法。注意,ARFM 根据允许穿过系统的请求的预期特征来估计当前的 CPU 利用率。如果这些预测不正确,那么实际的后端服务器利用率可能略微超过或达不到目标值。另外,正如前面提到的,ARFM 把一组功能相当的应用服务器当作单一资源来管理,而且假设负载会在这些服务器之间适当地分布。这意味着,在某些情况下,某些服务器可能处于更高或更低的负载水平。以后的一篇文章在概述 Dynamic Work Load Manager (DWLM) 组件的过程中将进一步讨论这个问题。

图 2. 配置 ARFM CPU 过载保护阈值
图 2. 配置 ARFM CPU 过载保护阈值

定义服务策略

在 WebSphere Virtual Enterprise 中,服务策略为 ARFM 分析和优化请求流提供基础。ARFM 根据对每个服务策略中的请求流的观察进行预测和计算。在一个服务策略中,所有请求都被认为是相当的。这意味着,ARFM 假设属于同一服务策略的任意两个请求具有相似的响应时间和 CPU 需求。

这个假设决定了 ARFM 的一个关键行为特征,这也是一个潜在的缺陷:ARFM 对穿过系统的请求流进行建模,从而预测一组请求可能需要的响应时间。这种预测基于属于同一服务策略的以前的请求的服务时间。这意味着,它假设应用服务器每秒可以处理特定数量的某一类型的请求,它使用这个假设决定应该允许的并发请求数量。如果 ARFM 预测在不会引起请求阻塞或系统过载的情况下,(对于某类请求流)它可以允许每秒两个请求,那么如果其中一个请求花费的时间大大超过预测值,就会出现意外的排队。在一段时间内,可用并发数量实际上降到了 1(ARFM 预测会快速返回但实际上耗时很长的那个请求会占用另一个并发 “位置”)。这可能导致其他请求排队,直到那个长时间请求返回,让出并发位置。

为了避免这个问题,在定义服务策略时,应该把典型响应时间相似的所有请求流归入一个服务策略。在某些情况下,这可能意味着有多个 “gold” 服务策略,甚至对于由同一应用程序提供服务(但是典型响应时间不同)的请求也可能如此。

分两步配置服务策略。首先,把相关联的请求 URI 分组在一个事务类中(见图 3)。配置方法是,在 Administrative Console 中,选择 Enterprise Applications-><Application Name>->Service Policies。接下来,通过选择 Operational Policies->Service Policies->new 创建一个服务策略。创建新策略之后,可以编辑它(也通过 Operational Policies->Service Policies 面板),让事务类与服务策略定义相关联(见图 4)。服务策略定义还包含目标和重要性,这些设置将应用于与它相关联的事务类(和 URI)(见图 5)。通过 Administrative Console 中的 Operational Policies->Service Policies 定义服务策略。关于创建服务策略的更多信息,请参见本文末尾的 “参考资料”。

图 3. 把请求 URI 分组为事务类
图 3. 把请求 URI 分组为事务类
图 4. 把事务类与服务策略关联起来
图 4. 把事务类与服务策略关联起来

在最初配置策略时,用户可能根据直觉按应用程序的重要性只为给定的应用程序定义一个服务策略。但是,如果两个服务的响应时间差异非常大,就应该为它们定义不同的服务策略。例如,如果一个应用程序同时提供搜索服务和时间戳服务,就应该为它定义两个服务策略,因为搜索请求花费的时间很可能比简单的时间戳请求长。定义两个服务策略让 ARFM 可以独立地分析这两类请求流(时间戳请求和搜索请求)。这会提高 ARFM 预测服务时间的准确性,进而改进它的请求流调整决策。

与之相似,因为 ARFM 假设同一服务策略中的任意两个请求在应用服务器上的 CPU 需求是相似的,不符合这一假设的请求流模式会破坏正常的流控制。例如,假设 ARFM 计算出它可以允许后端服务器上同时处理 10 个请求,这应该会产生 90% 的 CPU 利用率(每个请求 9%),但是其中一个请求实际上占用 27% 的 CPU,后端服务器就会过载,达到 108%。如果 ARFM 试图在两个服务策略之间分配 CPU 资源,预期每个策略占用 45% 的 CPU,那么以上场景对于实施服务策略甚至更有害。在这种情况下,一个服务策略中的请求需要过多 CPU 资源,这会导致过载,进而导致另一个策略或这两个策略的服务目标被破坏。

仍然以搜索请求和时间戳请求为例,搜索请求消耗的 CPU 资源很可能比时间戳请求多。如果把它们分组在同一个服务类中,ARFM 就很难对 CPU 需求做出准确的预测,根据特定时刻流经系统的搜索和时间戳请求的比例不同,应用服务器会过载或负载不足。

为了便于说明问题,前面的示例有点儿夸大了。在实践中,ARFM 会预料到并容忍请求之间存在一定程度的不一致。但是,如果明确地知道某些请求类型之间的差异,就应该把这些请求分组到单独的服务策略中,让 ARFM 可以有效地管理它们。

除了请求流的分类和服务类的目标之外,服务策略还有相关联的重要性设置。这实际上是一个乘数因子,使用它判断实现的响应时间与服务目标相比是好是坏。也就是说,对于特定的分配,ARFM 将预测的响应时间(无论是否满足目标)乘以目标的重要性权值。它尝试跨服务策略优化分配,尽可能减小总值。(对于这个计算,低于服务目标的期望响应时间作为负数计算。)在评估一组分配的相对优劣性时,不考虑重要性级别为 “discretionary” 的服务目标,这意味着 ARFM 不会采取措施来避免此服务类中的请求流排队,如果排队有助于提高其他服务策略的总响应时间(排队时间加上服务时间),这些请求就会排队。

假设一个系统定义了三个服务策略:gold、silver 和 bronze。gold 具有非常高的重要性,silver 具有中等的重要性,bronze 的重要性定义为 discretionary。在出现一组无法马上得到服务的请求(由于服务器处理能力不足)时,ARFM 会首先让与 bronze 策略相关联的请求排队,因为它的重要性是 discretionary,所以这些服务的响应时间增加并不影响对系统优劣性的计算结果。对于 silver 和 gold 请求,ARFM 会根据它们的重要性在它们之间分配必需的排队。这意味着,这两类请求都会在队列中花费一段时间,但是 gold 请求排队的时间比例比较小。如果把高重要性设置为数字值 100,中等重要性为 50,那么 ARFM 在安排排队时会尝试达到 100*(gold 请求排队时间)==50*(silver 请求排队时间)。换句话说,在资源不足以马上处理请求时,silver 请求的平均排队时间是 gold 请求的两倍。

图 5. 服务策略目标配置
图 5. 服务策略目标配置

最后,正如前面提到的,ARFM 的主要处理能力管理机制是,对那些可以推迟同时仍然满足其服务目标的请求进行排队。这意味着,ARFM 要求请求流的典型服务时间与预期服务目标之间存在一些余量。这让它可以考虑可以给哪些请求设置比较低的分配(因此更可能排队)。如果配置的服务目标非常接近应用程序的典型服务时间,ARFM 就很难对哪些请求流要排队做出适当的决策,因为任何排队都很可能违反服务目标。要想创建有意义的服务区分,服务策略的配置应该足够宽松,让 ARFM 能够在不违反服务目标(包括必需的后端服务时间)的情况下对请求进行排队。创建多个服务策略有助于满足这一要求,这么做就可以为每类请求设置适当的目标,而不是为应用程序的所有请求设置单一目标。


何时使用 ARFM

既然了解了 ARFM 评估请求流模式和执行处理能力管理的方式,您现在应该会看出,适当配置的请求流分类、定义良好的服务策略和适当的服务目标是成功实现服务水平区分的关键。如果没有定义正确的服务策略,ARFM 就会对正在处理的请求流的性质以及请求流在应用服务器上的需求做出错误的假设,这会导致应用服务器过载或负载不足。

如果还没有为系统配置适当的服务策略定义,应该考虑禁用 ARFM 的请求排队功能。禁用它的方法是,使用 disableARFM.py wsadmin 脚本(在 <WAS_HOME>/bin 目录中)把单元级定制属性 arfmManageCpu 设置为 false。还有一个作用相反的 enableARFM.py 脚本。注意,disableARFM.py 隐式地禁用 CPU 过载保护,因为 ARFM 在任何情况下都不会进行请求流排队。但是,如果有可用的服务器,Application Placement Controller 仍然会根据需要让更多处理能力在线。


结束语

对于实现服务水平区分,Autonomic Request Flow Manager 是一个极其强大的工具。但是,它做出的决策不一定符合系统管理员的直觉。另外,必须正确地配置,ARFM 才能实现期望的结果。在通过配置 Autonomic Request Flow Manager 实现服务水平区分时,应该记住的要点如下:

在 ARFM 功能方面:

  • 并不管理策略之间的非 CPU 应用服务器资源争用(例如应用服务器文件系统争用)
  • 并不管理策略之间的后端(例如数据库)资源争用

在 ARFM 配置方面:

  • 要避免同一策略中的请求的服务时间差异过大
  • 要避免同一策略中的请求的 CPU 使用量差异过大

记住这些规则并掌握 ARFM 做出资源决策所用的算法,就能够配置执行服务水平区分的 WebSphere Virtual Enterprise,不会对它做出的优先次序决策感到吃惊。


术语

服务时间(Service Time) – 在应用服务器上处理请求所需的时间。这段时间从请求到达应用服务器开始,直到生成响应时为止。它不包括在 On Demand Router 上的队列中花费的时间。

响应时间(Response Time) – 从请求提交给 On Demand Router 直到返回响应的总时间。这包括在 On Demand Router 上的队列中花费的时间,针对服务策略目标度量这个值。

工作类(Work Class) – 与每个应用程序相关联的配置,它们根据 URI 把请求分类到特定的事务类中。

事务类(Transaction Class) – 这种对象用于把一组工作类分组在一起,然后把它们与一个服务策略关联起来。

服务策略(Service Policy) – 与一个服务目标相关联的一组事务类。一个服务策略中的所有事务类应该具有相似的响应时间和 CPU 消耗量模式。

服务目标(Service Goal) – 对于与特定服务策略相关联的事务类,ARFM 尝试满足的响应时间目标。


参考资料

条评论

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=WebSphere
ArticleID=467840
ArticleTitle=WebSphere Virtual Enterprise 和服务水平区分
publish-date=02112010