评论专栏: Jason McGee：动态中间件和虚拟化应用程序服务环境的六种属性

引言

我们面对的现实是：管理生产应用服务器环境非常困难。现代环境常常由分布于一系列计算机上的许多应用程序组成。这些应用程序必须处理不可预测的负载，它们需要始终可用，而且处于不断更改之中。而且，为做到这一点，还时常存在如何使用较少的人力和财力方面的压力。那么您如何管理这种复杂性呢？管理这种复杂性的解决方案有多种，但较有前途的一种方法是通过使用虚拟化和自动化。如果中间件有足够的智能，能够理解您的意图，那么系统管理成本将大大减少，而且管理起来也容易得多。

目前有许多产品和技术都声称能够提供这些好处。但怎样才能知道哪些产品或技术比较好呢？下面列出了六种属性，我认为一个解决方案只有具备这六种属性才能真正解决现代应用服务器环境的复杂性。所有这些属性在 IBM 的 WebSphere® Extended Deployment 产品中都得到了体现，本文将使用该产品作为示例。

回页首

1. 对环境的感知性

虚拟化环境必须具备的第一要件就是对环境的感知性。为了管理应用服务器，虚拟化系统必须理解三种关键元素：

• 拓扑包括有关服务器和应用程序的信息。对于服务器，系统需要知道所有应用服务器、它们当前的状态（开始或停止）及其通信端口（主机和端口号）。对于应用程序，系统需要知道安装了哪些应用程序，它们处于哪个或哪些服务器，应用程序当前是否运行，以及它们公开的终端有哪些。终端可能是 URL、IIOP 上的远程对象或消息驱动的 Bean。而且，拓扑信息是活动的（即它随着系统的更改而更新）也非常重要。更改可能是管理操作（如安装新应用程序）或某些故障（如死机）。一个良好的虚拟化系统本身将尽可能多地了解此拓扑，而无需要求管理员分别定义和维护此信息。在 WebSphere Extended Deployment 中，称为按需配置 (ODC) 的子系统负责发现、维护并在系统中分发此拓扑信息。ODC 是一个活动的状态模型，显示当前运行系统的拓扑。

• 负载和容量涉及虚拟化系统了解正在管理的计算机集群中可用的计算能力有多少，以及在任何时刻有多少计算功能正在使用中。此信息对虚拟化系统以后做出决策非常重要。一个良好的虚拟化系统必须能够计算异类计算机集合（Intel 与 Power5 和 UltraSparc 等的混合）的计算能力。该系统还必须能够确定在任何时刻正在使用的计算能力的当前百分比，而且能够不停地分发这些信息。在 WebSphere Extended Deployment 中，NodeDetect 子系统负责确定和分发负载和容量信息。NodeDetect 计算每台计算机的节点速率，具体方法是通过查看 CPU 的数量、CPU 的速度 (Mhz) 以及 CPU 的体系结构，并应用换算系数来规范不同的 CPU 体系结构。NodeDetect 还监视正在使用的 CPU 负载、内存使用情况和其他度量标准，以帮助确定在某个瞬时快照中有多少计算机正在使用中。

• 需求是虚拟化系统必须感知的最后一个元素。需求是对系统上被请求负载的度量。它度量正在有多少通信量发送到系统。虚拟化系统至少须知道有多少请求正在发送到系统。假设所有请求造成服务器上相等的负载，则此传入速率可让系统计算处理需求所需的计算能力。当然，在现实世界中，并非所有的请求都是相等的。某些请求的计算开销很大，而有些请求的计算开销较少。因此，一个好的虚拟化系统应能够根据处理请求所需的计算能力来度量每个不同请求类型的成本。在 WebSphere Extended Deployment 中，稍后要谈到的按需路由器 (ODR) 可以根据到达速率来跟踪传入需求。WebSphere Extended Deployment 还有一个称为 Work Profiler 的子系统，它负责自动分析应用程序，确定系统中不同类型请求的平均每请求的计算成本。这可让 WebSphere Extended Deployment 非常准确地了解系统上的需求。

拓扑、负载/容量和需求为 WebSphere Extended Deployment 之类的虚拟化系统提供了计算机集群中所发生情况的清晰完整的画面。不过，在虚拟化系统有效地使用这些信息之前，该系统还需要理解管理员想如何管理系统。

回页首

2. 面向目标

虚拟化应用服务器环境中必须提供的第二个属性是某些面向目标的意图。利用虚拟化的一个主要好处是，虚拟化系统能够自动进行一些更改，以便管理员能够响应当前的条件。但是，要实现这一点，系统必须具有据此做出决策的某些标准。在一个良好的虚拟化系统中，这些标准表示为策略。策略功能差别很大，具体需根据虚拟化系统的功能而定。在 WebSphere Extended Deployment 中存在两种主要的策略类型：

• 第一种是称为服务策略的性能管理策略，该策略是一种服务水平协议 (SLA)。服务策略由一组分类规则、一个性能目标和一个重要性级别构成。分类规则是一些谓词语句，这些语句基于传入请求的元素，如 URL、标头、cookie、客户端 IP 等。性能目标通常是诸如符合分类规则的所有请求的平均响应时间目标。重要性级别在不同的工作负载中有相应的等级。如果所有工作负载都能够满足它们定义的性能目标，则重要性级别将无效。但是，当需求超出容量时，将使用重要性级别进行权衡。

• 第二个策略类型是运行状态策略。运行状态策略定义管理员需要处理的常见问题。这将在稍后的部分中对这一主题进行更为详细的讨论。

对面向目标属性的最后一点重要说明是，一个良好的虚拟化系统应能够根据最终用户的特性来定义目标。例如，定义 Web 应用程序策略时最好是根据对最终用户的响应时间，而不是最大的 CPU 使用阈值。WebSphere Extended Deployment 之类的系统可提供最终用户目标。

回页首

3. 管理需求与容量

具备环境感知性和一组据此管理的目标之后，就可以开始进行虚拟化的实际工作（和价值）了。虚拟化系统的目的是在面对当前现实世界中的条件时能够满足目标。为了实现这一目标，系统首先必须能够执行控制。在虚拟化系统中有许多不同的控制点，从控制通信流量到控制集群大小和计算机分配，再到控制分配到进程的 CPU 和内存。它们都有各自的位置，而且应用的速度通常也各不相同。在 WebSphere Extended Deployment 中，两个主要控制点是通信量控制和集群大小控制：

• 通信量控制由按需路由器 (ODR) 提供。ODR 是一种基于 Java™ 的代理服务器。它位于应用服务器前面，负责将所有通信量路由到一组应用服务器。在网络中的这个重要位置中，ODR 能够控制资源在后端服务器上的使用方式。为满足定义的目标，ODR 提供了两个关键功能：

  • 动态负载管理 (DWLM) 能够使用负载感知信息在服务器集群中路由和平衡通信量。此感知性使得 DWLM 能够以最有效的方式平衡加载，从而实现更优化的吞吐量和响应时间。

  • 自动请求流管理器 (ARFM) 提供对传入工作负载的流控制。这可让 ODR 区分工作负载，以便能够满足定义的目标。因此，如果重要性低的工作负载占用的资源太多，ARFM 可以减慢（排队）重要性低的工作，并加快重要性较高的工作，以更改后端应用服务器上工作负载的混合。

  这些通信量控制能力提供了一种满足目标的方式，可快速响应，迅速适应具体环境中的更改。

• 但是，仅使用通信量控制是不够的。如果为指定的应用程序分配的 CPU 不足，则管理传入通信量将无法让您满足分配的目标。为处理这种情况，WebSphere Extended Deployment 提供了一种称为应用程序布置控制器 (APC) 的功能。APC 的工作是基于对系统的需求控制承载指定应用程序的集群大小。因此，在需求增加时，分配给指定应用程序的 CPU 数量可以增加，反之亦然。不过，APC 并不孤立地处理应用程序。对于在同一计算机集合上运行的所有应用程序，APC 必须确定如何以最佳方法在所有应用程序之间分配池中的资源，以便这些程序都能满足它们的目标。这是非常关键的。因为 APC 关注的是全局问题，因此它可能让硬件池承载比一般应用程序集更大的应用程序集，原因是每个应用程序可以根据实际需求来请求大部分池。

管理需求的能力使虚拟化系统省去了许多需要由管理员执行的复杂任务。容量计划变得不再重要了。虚拟化系统可以确定应用程序应在何处运行，集群应是多大以及如何路由到这些应用程序。随着情况的变化，虚拟化系统可以自动地适应。所有这些问题都不必再由管理员手动进行处理。

回页首

4. 处理失败

当然，任何系统和应用程序都不是十全十美的，都会出现问题。应用程序有内存泄漏问题。服务器可能会挂起。一个良好的虚拟化系统应能够预料到这些问题，并适当地对它们进行处理。一个良好的虚拟化系统在生产系统中还应能够减轻这些问题的影响。减轻的意思是指最终用户不会觉察到发生的问题，这为管理员解决问题提供了更多的时间。在 WebSphere Extended Deployment 中，存在一个称为 HMM 的运行状态管理系统。HMM 可让管理员定义运行状态策略，以便监视常见问题，并在发生这些问题时采取一些缓解措施。HMM 系统可以监视是否发生以下情况：Java 虚拟机 (JVM) 中的内存泄漏、服务器挂起或不可响应、过时的请求、快速消耗、过分违反服务策略和其他一些条件。在检测到这些条件之一时，HMM 可以通知管理员，捕获一些诊断信息以便日后调试（如 JVM 堆转储或线程转储），并重新启动服务器，从生产环境中移除故障服务器。该服务器重新启动是智能式的，确保了应用程序始终不会离线，由于提前重新启动和预报了故障，因此在请求开始产生错误之前就能够触发重新启动。

当与性能管理策略结合使用时，该运行状态管理系统可以实现一个非常强健的环境，在同时面对实际需求和故障时都可以继续满足管理员的目标，而且所有这一切都不用手动干预。这是一种双赢情形：既提供了更好的复原能力又减少了工作量。

回页首

5. 计划更改

在系统进入生产环境并顺利运行后，处理不断变化的负载并从故障中进行恢复总比仅听之任之要强得多。但这是不现实的。更改是不断进行的。应用程序需要升级，必须应用软件维护。一个良好的虚拟化系统还可以帮助管理这些情况。

软件维护包括升级指定计算机上的操作系统和应用服务器软件。作为管理员，应该能够将某个指定计算机从生产中干净地分离出来，以便对其应用这些更改。然后，还应该能够将计算机放回服务中。虚拟化系统应为您安排这种情况。WebSphere Extended Deployment 通过称为“节点维护模式”功能实现了这一点。当您将某个节点（或计算机）置于维护模式时，WebSphere Extended Deployment 将干净地排除该计算机上的所有工作，允许执行中的请求完成执行，并阻止所有新请求使用该计算机。WebSphere Extended Deployment 还可以确保分配到该计算机的所有服务器都移动到其他计算机，确保指定应用程序的目标在目前较小的硬件资源组上继续得到满足。这可能涉及复杂的工作负载重新平衡，但它能够自动处理这些事情。在计算机从生产中移除之后，管理员可以应用维护。在维护完成之后，可以将计算机从维护模式中移除，再次将其投入资源池中使用。WebSphere Extended Deployment 然后可以根据需要将应用程序和工作负载重新移动到该计算机。此系统的优点在于管理员不必移动应用程序，更改路由表、停止工作负载或执行任何手动操作。管理员只需声明不能继续使用指定的计算机，WebSphere Extended Deployment 虚拟化系统会自动适应这一声明。

应用程序代码升级稍微复杂一些。难点在于要求这些升级对最终用户而言是透明的。必须通过认真编程并协调一致地对应用程序的设计进行升级来解决这些难点。一个良好的虚拟化系统应能够帮助您解决这些难点的其他部分，将新应用程序的代码部署到生产中。在 WebSphere Extended Deployment 中，支持两种主要的应用程序版本更改：

• 快速替换。快速替换的目的是在尽可能短的时间内将应用程序的一个版本替换为另一个版本，同时保持应用程序继续可用。在 WebSphere Extended Deployment 中，这通过自动协调应用程序代码的推出与来自 ODR 层的通信流来完成。通过协调这两个活动，WebSphere Extended Deployment 可以确保一次一台计算机地替换代码，同时能够在更改计算机时路由通信。

• 共存。这里，共存的目的是让应用程序的两个版本长时间地并行运行。这在运行试用版本时较为有用。为使之能够工作，传入的工作负载必须以某种方式分离到两个目的地。在 WebSphere Extended Deployment 中，这一点通过 ODR 上的路由策略完成。此路由策略可让管理员定义路由通信的方式以及将通信发送到哪个应用程序版本。例如，管理员可以根据客户端的 IP 地址路由通信，让一个位置的用户转到应用程序的 1.0 版，让所有其他用户转到该应用程序的 2.0 版。此路由控制为管理员更改基础结构提供了巨大的灵活性，使这种更改不会显示给最终用户。

回页首

6. 人员：信任、证明和资金

一个良好的虚拟化系统的最后属性是承认人员在这些系统的成功方面扮演着关键角色。虚拟化系统直接解决此角色。与使用这些系统的人员相关的关键问题主要有三个：信任、证明和资金。

1. 让我们面对这样一个事实：几乎没有人信任软件能够执行它所标明的功能。这就是人们对什么东西都进行测试的原因。因此，也就无怪乎人们最初会对新的、别出心裁的虚拟化系统可以自动做出决策并且帮助管理员执行更改（而且功能强大）等功能产生不信任的观念。这种虚拟化系统有必要取得人们的信任。在 WebSphere Extended Deployment 中，该问题通过一种操作模式（称为监控模式）得到了解决。在监控模式中，在为响应不断更改的输入条件而对系统执行任何更改之前，WebSphere Extended Deployment 都会通知管理员有关待定的更改，描述更改背后的原因，详细描述它要执行哪些更改，然后请求批准。如果得到批准，则会执行更改。否则，它们会被取消。此系统可以建立这种信任。管理员可以看到进行的所有更改，可以控制是否执行这些更改，而且可以看到更改背后的原因。随着时间的推移，管理员会认识到 WebSphere Extended Deployment 始终如一地提出一些合理化建议，在获得管理员的信任后，管理员就会将系统移动到更期望的自动化模式。

2. 与信任密切相关的是证明。一个良好的虚拟化系统必须证明它是在做正确的决策，即使这些决策是自动做出和执行的也如此。它必须对其执行的更改提供审核跟踪，而且必须能够证明符合定义的目标。在 WebSphere Extended Deployment 中，这通过一个审核和性能数据日志记录基础结构来完成，该基础结构可让系统记录它执行的所有更改，并能够记录系统状态随时间的变化。此信息为管理员了解系统随时间推移的行为变化以及为何做出这些决策提供了很大的价值。

3. 最后，所有这一切都归结到资金上。运行系统的开销是否减少了？管理是否更容易了，需要的人员是否更少了？复原能力是否更强，成本损失的机会是否更小？如何将这些成本传递到应用程序所有者？这些问题很重要。有些内容是在系统的日常操作中提供的。但是一个较大的变化是最后一个问题：如何传递成本？许多 IT 部门对承载应用程序的成本向应用程序所有者执行内部收费。目前通常是按固定单元执行的。在一个良好的虚拟化系统中，可以通过更为细粒度的方式（按实际使用的资源）计费。这一点尤其重要，因为大多数虚拟化系统（包括 WebSphere Extended Deployment）都构建在共享资源的概念之上，这使得按固定单元收费不够准确。在 WebSphere Extended Deployment 中，我们根据应用程序或服务器策略，通过捕获对系统使用情况的细粒度度量标准解决了这个问题。我们还能够将这些度量标准的消耗量记入正式的计费和测量系统，如 IBM Tivoli® Usage and Accounting Manager。这一基本功能实现了 IT 部门如何从应用程序所有者补偿成本的完整转换。

回页首

结束语

正如您所看到的，提供一个虚拟化基础结构是非常复杂的。需要考虑到方方面面的问题。在一个指定产品中，虚拟化基础结构只能解决这些需求的某一部分，但这样做之后，管理员只需要弥补不足之处。在评估应用服务器环境的虚拟化时，了解用于实现您的 IT 未来环境的技术和产品十分重要。IBM WebSphere Extended Deployment 就是一个这样的系统。