从 IBM WebSphere Application Server 到 IBM WebSphere Virtual Enterprise 的移植实践

核心提示：WVE 及中间件虚拟化方案简介WAS 是业界领先的 Java EE 中间件，已经广泛的应用于全球各行各业，从 IBM WebSphere Application Server 到 IBM WebSphere Virtual Enterprise 的移植实践，在 WAS 基础之上，IBM 推出了面向中间件虚拟化的新型中间

WVE 及中间件虚拟化方案简介

WAS 是业界领先的 Java EE 中间件，已经广泛的应用于全球各行各业。在 WAS 基础之上，IBM 推出了面向中间件虚拟化的新型中间件产品— WebSphere Virtual Enterprise （它之前是 WebSphere Extended Deployment 产品的一部分，简称 XD ）。WVE 提供了中间件虚拟化的能力，这使得中间件的工作负荷需求与可用资源能够实现最佳匹配，实现动态地管理工作负荷以及资源的能力，满足了对 IT 环境灵活性的需求，并确保将资源配置到最需要它们的地方。

通常，应用程序和 Java Enterprise Edition（ Java EE ）应用服务器分别以静态方式绑定至特定的服务器。某些应用程序会遇到周期性的短暂负荷峰值，为应对这类负荷，企业不得不采购大量的 IT 基础设施。然而，在一般负荷期间（大部分时间），有很大比重的计算能力未使用，因此将导致 IT 基础设施的利用率较低。WVE 通过基于 Java EE 应用服务器的资源虚拟化技术实现了虚拟化的、动态共享的运行环境。这里，资源虚拟化是指多个应用系统共享相互分离的计算资源以适应业务需求的峰值和谷值的能力。在 WVE 虚拟化的环境中，WVE 可实现自动执行管理服务和动态重新分配。本质上，WVE 的已虚拟化环境符合“以少做多”原理。与静态环境相比，在 IT 基础设施一定的情况下，WVE 虚拟化环境可以运行更多的应用程序，还可以动态地更改应用程序和配置。同时，WVE 还提供了服务级别管理的功能，通过预定义的策略，可以确保关键应用或重要客户的服务质量，实现面向业务需求的计算资源调度。此外，在共享的环境中，WVE 还可以实现自动化的异常处理，提升系统的可用性。

基于 WVE 构建中间件虚拟化方案以应用服务器动态集群（以下简称动态集群）为核心，为应用程序运行提供一个具备更高共享度和灵活性的运行环境。该解决方案应主要包括三部分：

动态应用服务器集群组：一组基于由多台物理服务器组成的计算资源池构建的、支持动态规模扩展，动态负载均衡以及动态请求路由的的服务器集群，是提供应用运行环境的主体，由多个 WVE 节点实现；

应用路由控制节点：作为客户端请求的统一接入层，实现对动态集群成员间的负载均衡和路由，由 WVE 的 On Demand Router（简称 ODR）实现；

管理控制节点：动态集群环境的管理和监控工具，通过该工具可定义和配置动态集群和应用路由控制节点的各种相关参数，包括运行时的动态集群需要遵循的各种策略，并可监控这个环境的运行状态，由 WVE 的 Deployment Manager（简称 Dmgr）实现。

图 1. WVE 系统典型拓扑图

基于 WVE，上述中间件虚拟化方案能够做到：

提供动态、共享的计算环境，提升计算资源的利用率；

支持应用服务级别的管理，实现面向业务需求的动态计算资源分配；

提供自动化的监控及异常处理能力，提升系统可用性，简化运维护工作。

实践项目背景及目标

在本项目中，客户 IT 环境如下：

应用系统：已有 4 个采用 Java EE 技术构建的应用系统。由于客观原因，本次只对其中两个应用系统进行移植。

中间件平台：WAS 6.0.2.11

硬件平台：IBM System P550 AIX 和 HP UX 11i 服务器

客户 IT 环境逻辑架构图如图 2：

图 2. 客户 IT 环境逻辑架构图

在以上环境下，客户面临的主要挑战如下：

如何基于现有计算资源更好地满足日益增长的业务工作负载需求？

IT 基础设施的利用率亟待提升。一方面，Unix 服务器的平均利用率较低，据客户统计，服务器 CPU 的平均利用率在 20% 左右。另一方面，随着业务量的增长，当某些系统的访问峰值到达时，IT 基础设施已经过载，然而其他系统的 IT 基础设施在此时的利用率却相对较低。客户并未找到一种共享空闲资源的有效方法。

如何提升业务系统的服务质量？

对于一些系统，当峰值访问到达时，已有的硬件系统已经难以支持，导致系统经常出现宕机。另一方面，某些系统由于存在内存泄露，但由于开发团队难以定位问题，而无法解决，在某些条件下，这些系统将出现挂起或宕机。以上问题都影响业务系统服务质量。

如何降低 IT 基础设施的投资和运维成本，简化运维工作？

客户的机房已经饱和，无法在提供更多的空间和电力。如果客户采购更多的服务器，他们将不得不做更大的投资来扩展机房。然而已有预算无法支持此项投资。同时，客户运维团队的人力资源也非常有限，他们非常需要自动化的管理方式和监控工具来提升日常的工作效率。

基于对上述需求的理解，IBM 推荐并成功实施了基于 WVE 的中间件虚拟化方案，并实现以下三个主要目标：

通过构建动态集群，实现基于业务需求动态资源分配；

基于 WVE 实现服务级别的定制及有效管理；

实现自动化的监控与异常处理。

下图是本项目的目标部署逻辑架构图，其中客户为新环境增加了一台闲置的 AIX 服务器 P2 Server：

图 3. 客户 IT 环境目标部署逻辑架构图

查看原图（大图）

两个 WVE 的动态集群运行在初始状态。Inactive WAS Instance 表示初始时不启动，当请求压力增大时需要增加资源时才会被 WVE 自动启动。

移植方案

移植方案中包括移植计划和详细移植步骤。

移植计划

在进行移植前，制定一个完善的计划对移植的成功非常关键。计划的制定和具体的移植需求及内容有关，有以下两点要仔细考虑：

（1）、移植时的系统可用性。如果允许应用系统停止运行一段时间专门进行移植和测试，则可以采用离线方式，这也是最安全简单的一种方式；如果移植时要求系统继续提供服务，则可以采用渐进式，逐个机器停止运行 - 移植 - 开始运行的方式。第二种方式的适用对象是水平集群或者水平 + 垂直集群的方式，不适合完全的垂直集群。

（2）、移植时的风险控制。要充分考虑移植的风险，确保安全实施。对于 WAS 到 WVE 环境的移植，最安全的做法保留原有 WAS 环境不动，重新安装 WAS，再安装 WVE，然后创建概要文件，但这种方法工作量最大；比较安全又节省工作量的做法是在原有 WAS 环境中保留原来的概要文件不变，通过创建新的 WVE 的概要文件搭建新的环境，这样即使移植后系统出现问题仍可以通过启用原来的概要文件恢复原系统；最节省工作量但不能回退的方法是直接扩展 WAS 原来的概要文件。最后这种方法适合移植工作相对简单的场景，比如升级一些小补丁。

在本次移植中由于涉及到比较大的改造，为了安全起见，我们选择离线移植方式，采用比较安全又节省工作量的做法，用新创建的 WVE 概要文件搭建新环境。

前面提到，客户新增加了一台闲置的服务器 P2，因此我们首先在此服务器上安装 WAS 6.0.2，然后对所有服务器升级 WAS 补丁到 6.0.2.29，以及安装并升级 WVE 到 6.0.2.5；其次，配置 WVE 环境，包括创建随需应变路由器 ODR、节点组和动态集群，然后安装应用，配置服务策略（Service Policy）以及健康策略（Health Policy）；最后进行测试及运行时系统监控，以保证移植的正确性。大致的移植步骤如表 1 所示：

表 1. 移植步骤

#	内容
1. 安装
（a）	在新增服务器上安装 WAS。
（b）	在所有服务器上升级 WAS 补丁。
（c）	在所有服务器的 WAS 之上安装 WVE 并升级补丁。
（d）	创建 WVE 的概要文件并联合成单元。
2. 配置
（e）	创建随需应变路由器 ODR。
（f）	创建动态集群。
（g）	安装应用。
（h）	配置服务策略。
（i）	配置健康策略。
3. 测试及监控
（j）	测试及运行时监控。

下面介绍详细的移植步骤。

详细移植步骤

对于在新服务器上安装 WAS 这里不再叙述。下面介绍 WAS 升级时的注意点。

1）升级 WAS 补丁到 6.0.2.29

WXD6.0.2.5 版本需要的最低 WAS 版本是 6.0.2.29，客户环境中的 WAS 版本是 6.0.2.11。因此需要首先升级 WAS 到 6.0.2.29。升级安装 WAS 补丁时注意需要使用 Update Installer 6.1.0.19，如图 4 所示：

图 4. 升级 WAS 6.0.2.29 补丁

2）安装 WVE 产品和升级 WVE 到 6.0.2.5

WVE 产品的安装过程与 WAS ND 产品的安装过程类似。6.0.2 版本 （6.0.2 时产品的名字是 XD）与 WVE 6.1 的安装步骤有些不同，我们这里说明安装 6.0.2 时的注意事项，关于 WVE6.1 的安装请参考 WVE6.1 的 Information Center: http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1/index.jsp。

在安装过程中，有一个步骤是根据安装的目标选择界面上的不同选项。如图 5 所示：

图 5. 选择安装类型

因为我们的应用服务器环境是 WAS ND，因此选择界面上的“WebSphere Extended Deployment Version 6.0.2”选项。如果要安装的环境只是用于管理其他的应用服务器的 XD Agent，如 WEBLOGIC、JBOSS、TOMCAT 等，则需要选择下面的“WebSphere Extended Deployment for mixed server environment version 6.0.2”选项。

当到达下图的扩展概要文件的界面时，如果此服务器上已经创建了概要文件，则可以选择是否进行扩展。我们制定的移植计划中要求保留原有的 WAS 概要文件环境，因此采用的是不扩展的方式。在界面上取消扩展任何概要文件，而在安装完成后创建新的 WVE 概要文件，如图 6 所示：

图 6. 不扩展已有的概要文件

安装 WVE 产品补丁时使用的 Update Installer 与前面升级 WAS 的一样。WVE 6.0.2 产品补丁的下载地址为：http://www-01.ibm.com/support/docview.wss?rs=3023& uid=swg27011999

我们此次升级到了 WVE 6.0.2 的补丁 6.0.2.5。

3）创建或增大概要文件

WVE 产品是对 WAS ND 产品功能的扩展，因此我们需要创建新的概要文件或增大原来 WAS 的概要文件来执行相应的管理和运行工作。首先需要创建部署管理器概要文件 Dmgr，然后再创建两个以上的定制节点概要文件，其中一个用于 ODR 进程，其他的用于 Server 进程。

创建概要文件的操作请参考 Information Center:

http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/install/tinstallprofile.html

至此，安装部分已经完成，下面配置 WVE 环境。

4）配置随需应变路由器（On Demand Router，以下简称 ODR）

ODR 在本质上是一个代理服务器，可以对 HTTP 协议或 SIP 协议的请求进行负载均衡的分发。ODR 可以自动识别后端的动态集群配置，并根据负载情况自动智能地把请求分发到后端的 Server 上。进入管理控制台里的服务器 - 〉 On Demand 路由器，然后选择“新建”创建新的 ODR 服务器，如图 7 所示。

图 7. 新建 ODR

由于客户的环境相对简单，本次移植配置一个 ODR 已足够使用。在大规模系统中，管理员可以根据需要配置多个 ODR 以保证大量请求的顺利转发及消除单点故障，同时可以在 ODR 层之前配置类似于 IBM HTTP Server 的负载分发器，把请求分发给各个 ODR。

5）配置节点组和动态集群

在 WVE 环境中，节点组是虚拟化的资源池。多个动态集群可以共享一个节点组里的服务器资源。配置节点组可以通过进入管理控制台内的系统管理 - 〉节点组，然后输入新增节点组的名称后，选择节点组成员，以增加成员节点。如图 8 所示。

图 8. 新建节点组

在完成节点组的创建后，便可以在节点组上创建动态集群，可以通过管理控制台的服务器 - 〉动态集群—〉新建。动态集群的管理方式默认是手工方式。在开始测试时要把管理方式改成自动模式，使得 WVE 可以根据流量情况自动启动或停止集群内的实例。在输入新增动态集群的名称后选择希望映射的节点组，如图 9 所示。

图 9. 新建动态集群

然后进行动态集群属性的初始配置。

在图 10 的页面上可以定义动态集群的最大实例数和最小实例数。对于“垂直堆放节点上的实例”这一属性，则是可以定义在节点组内每个节点上的最大实例数。如果需要定义单独节点上的实例数，则需要在动态集群内设置定制属性。此部分设置可以参考如下链接进行。

http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todstackhomog.html

图 10. 动态集群的属性

此后，便是逐渐把其余的服务器节点加入到节点组内。而动态集群则无需修改。如果在安装应用后加入新的服务器节点，WVE 的管理控制台可以自动把应用程序包分发到新增的服务器节点上，不需管理员做任何工作。在此次移植过程中，我们也测试了由 AIX 服务器向 HP 服务器的分发过程，结果除了应用中的字符集需要修改外，其他的均没有发现什么问题。

6）安装应用（离线方式需要）

应用在新环境下的安装方法和在原来 WAS ND 环境的安装是一样的，只是在映射目标服务器时要把应用模块映射到上步创建好的动态集群上，如图 11。

图 11. 安装应用程序

7）配置服务策略（Service Policy）

服务策略的功能是通过定义应用的服务性能指标，来实现资源管理的虚拟化策略。服务策略配置的内容主要包含性能指标和重要性。性能指标主要指平均响应时间等，重要性是相对值，包含最低、低、中、高到最高等。

服务策略配置的步骤主要包含了定义服务策略、定义交易类（Transaction Classes）、定义工作类（Work Classes）。一个服务策略可以对应一到多个交易类。但每个交易类则只能属于一个服务策略。服务策略创建服务目标，而交易类和工作类则用于 URI 到该目标上。交易类的作用在于把相应的请求可以定向到相应的服务策略。工作类的作用则与应用程序相关，通过工作类的定义可以区分出不同 URI 请求，然后在应用程序的服务策略里配置使用的交易类，从而实现不同应用不同服务策略的功能，也能实现同一应用不同模块不同服务策略的功能。

在如何定义服务策略这一问题上，红皮书《 Best Practices for Implementing WebSphere Extended Deployment 》提供了定义服务策略的最佳实践。如果提供最佳实践所需要的数据和环境比较困难，则可以根据经验估计出一个平均响应时间的上限数据，然后再通过运行时监控来调整该指标值。图 12 是服务策略列表。

图 12. 服务策略

8）配置健康策略（Health Policy）

健康策略可以减少管理人员的工作量，通过配置健康策略，可以达到预警处理的功能，比如当系统内存出现泄漏或者过度使用（如达到 90% 以上超过 15 分钟）时，健康策略可以自动检查应用服务器实例的状态是否处于正常的状态，否则可以通过配置健康策略对应的措施（Action），如重启或生成线程堆栈日志等，这样也就实现了预警管理的目标。

健康策略的内容主要包含了内存过度使用、内存泄漏、过多的请求超时率、响应超时等。 WVE 有一系列默认的健康策略，这些默认策略的条件比较宽松，一般在系统运行情况很糟糕的时候才能违反，我们要根据系统的实际运行情况制定新的适合系统的策略，而把默认的策略留作补充策略。

制定健康策略首先需要考虑目前系统存在哪些不良运行状况，比如，应用正常运行时，平均响应时间一般在 5 秒左右，最长的响应时间也不会超过 10 秒，则可以制定一个条件为过多的响应时间的健康策略，指定响应时间为 12 秒，措施为收集 heap dump 和 thread dump 信息，目标机器为该应用所在的动态集群，如图 13、图 14 所示：

图 13. 健康策略的条件和响应配置


图 14. 健康策略响应的对象

其次，要经过测试和实际运行情况验证健康条件是否合适，并适时作出调整。

再次，健康策略的响应模式（Reaction Mode）有两种：监督模式（supervise）和自动模式（automatic）。在监督模式下，当健康条件被触发后，系统只会在 System Administration -> Task Management -> Runtime Tasks 中添加一个任务，由管理员来决定是否接受这个任务并让 WVE 按照健康策略里制定好的响应继续操作，如图 15 所示。如果管理员拒绝这个任务，则 WVE 不会做任何操作。而在自动模式下，虽然 Runtime Tasks 下也会添加一个任务，但管理员不能控制是否执行响应，WVE 都会自动继续完成响应。因此，当我们制定好健康策略，在系统初期运行时，为了安全起见，可以先选择监督模式一段时间，让管理员参与系统的健康活动并对策略进行必要的调整，然后再改成自动模式。

图 15. 任务列表中的任务

查看原图（大图）

至此 WVE 环境的配置基本完成，下面要通过测试及运行时的监控进行局部调整。

9）应用测试及系统运行时监控

WVE 提供了一系列的视图帮助管理员更好地理解整个运行环境。在管理控制台上可以看到，在 Server，Cluster，applications 和服务策略级别的视图中，除了有详细视图之外，还有操作视图和报告视图，操作标签视图显示资源的稳定性，资源的动态管理状况，如权值、CPU 使用率等。报告视图以可定制的图表的形式显示运行环境的性能，如 Server 的平均响应时间线状图等。

开始测试时，可以考虑定制一些视图来有针对性地监控环境。比如，当在一个应用上施加压力请求后，可以定制如图 16 所示的包含动态集群各 Server 实例的平均响应时间，并发请求数以及服务策略的视图。

图 16. 定制的监控视图

结束语

本文以一个实际项目为基础，介绍了如何从 WAS 环境搭建出中间件虚拟化的 WVE 平台，通过这个项目，客户实现了移植目标。

1. 在 WVE 的虚拟化环境中，随需应变路由器 ODR 是请求的入口点，通过智能的请求分类、流量控制以及动态负载均衡工作，实现了基于业务需求的动态资源分配。本次移植后客户环境 CPU 资源利用率提高了 50% 以上。

2. 根据应用的特点为其设置恰当的服务策略，实现了基于服务级别的管理。本次移植为最重要的应用系统配置了最高的优先级及合适的平均响应时间服务测略，WVE 基于目标的虚拟化管理确保了这个系统的服务质量。

3. WVE 提供的多样化的监控图表让管理员轻松地了解系统的运行情况。自动的感知 / 响应式健康管理提高了系统的高可用性，实现了自动化的监控与异常处理。本次移植后客户的反馈是“极大减少了 IT 管理人员的工作量”。