在 Power System 上优化 WebSphere Application Server，第 1 部分: 入门以及优化策略

核心提示：本书提供了整体系统观点，重点关注在 Power System 和 AIX 上运行 WebSphere Application Server 负载的环境的端到端系统部署、调优和管理方法，在 Power System 上优化 WebSphere Application Server，第 1 部分: 入门以及优化策略，因而，

本书提供了整体系统观点，重点关注在 Power System 和 AIX 上运行 WebSphere Application Server 负载的环境的端到端系统部署、调优和管理方法。因而，本书为两类截然不同的技术读者架起了一座桥梁，也就是硬件和操作系统管理员与 WebSphere Application Server 应用软件工程师。我们都了解，在典型的企业环境中，这两类技术读者需要密切合作，但仍然有着不同的视角和职责。然而，对于企业来说，在度量 Power System 和 AIX 上运行的 WebSphere Application Server 投资的成败时，最终要取决于所有系统架构师能否很好地理解如何同心协力地利用每种产品的特有优势。因而，我们首先要做的是澄清各种观点。

整体系统观点：WebSphere、JVM、AIX 和 Power System

表 1 列举了共同构成基于 Web 的系统的软件和硬件的抽象级别

表1. 整体系统视图中的分层

企业 Java 代码

WebSphere Application Server

Java 虚拟机

AIX 操作系统

逻辑分区

VIO Server

固件

Power System 硬件

观点

参见表 1，硬盘的固件由 VIO Server 调用，从硬盘的视角来看，这就是调用固件的应用程序。固件开发人员会为其应用程序提供应用编程接口，但不会关注该设备在插好之后是由 VIO Server 访问还是 RAID 控制器、SAN 之类的设备访问。只要应用程序使用正确的编程接口与固件通信，就一切正常。

同样，从操作系统的视角来看，运行在操作系统上的 “应用程序” 是 Java 虚拟机（JVM）。操作系统并不在意，JVM 运行的是庞大复杂的 Java 应用程序（WebSphere Application Server），还是在 Java 应用程序内部的 JEE 容器中运行的 Java 代码。

从 Java 虚拟机的视角来看，其 “应用程序” 是 WebSphere Application Server。从 WebSphere Application Server 的视角来看，其 “应用程序” 是 servlet 或部署在其中的其他 JEE 构造。依此类推。可以看到，“应用程序” 的定义取决于视角。

全面的系统方法

如上所述，“应用程序” 的定义取决于视角。而相反，所有独立组件和所有独立 “应用程序” 都是互相依赖的。因而，为了优化 WebSphere 应用程序，单纯地调优 JVM 或操作系统或者修改 Java 代码并不够。您需要的是开发出一种全面的视图，检查整个应用程序组合，确定依赖性在何处。若未理解对系统其余部分的影响，不应独立调优任何部分。

类似地，在对 WebSphere 应用程序进行故障排除时，应着眼于整个应用程序组合，因为在一个层面上修复一个问题只是解决了问题的一部分。在出现问题时，客户往往归咎于组合中的某一个部分，而实际上问题在于一个截然不同的位置。

系统分层和观点

要在 Power System 上运行的 WebSphere Application Server 中成功运行应用程序，您需要考虑上述所有视角。通常，企业中有着不同的专家团队，提供以下领域中的一组技能：AIX 操作系统管理、Power System 硬件配置与调优、Java 和 WebSphere 应用程序工程。

关注各技能集的专家以整体系统观点内的不同视角工作，如表 2 所示。因而，在尝试将这些观点整合为单一、完整的系统优化战略时，很有可能对术语和交叠的功能产生混淆。

专家倾向于在一个层面上工作，例如，UNIX 系统管理员倾向于从操作系统的观点观察事物，Java 开发人员倾向于从应用程序编程人员的观点观察事物、表 2 列举了 WebSphere Application Server 和系统管理观点可能出现整合的系统特性和交互点。

表 2. 系统观点和整合

	AIX	Java
动态提供	操作系统镜像、NIM Server、自动生成	静默安装脚本 Installation Factory 恢复备份
动态资源分配	微分区权限（服务水平协议）工作负载管理优先级/权重	将新服务器配置到网络部署单元中 WebSphere eXtended Deployment
调优格式	操作系统调优提升运行时（负载测试的一部分，属于一项长期操作）	JVM 调优特定于操作系统的 WebSphere Application Server 参数

观点和术语

表 3 列举了相似但有着不同用法的术语，如从 “systems” 的观点来看或从 “WebSphere” 的观点来看。

表 3. 观点和系统术语

术语	Systems 含义	WebSphere 含义
集群	在 AIX 和 POWER5 术语中，集群这个术语表示一组机器，但它们不一定运行相同的应用程序。	在 WebSphere 术语中，集群表示一组应用服务器克隆，所有都运行相同的 Java 应用程序，共享负载。
wlm	在 AIX 世界中，WLM 表示 Workload Manager，是一种 AIX 工作负载管理产品，允许为进程动态提供资源（CPU、内存和 I/O）。	在 WebSphere 世界中，WLM 表示 WebSphere 的工作负载管理，在集群成员之间分散负载。
xd	XD 在 HACMP 中表示 Extended Distance。	XD 还表示 WebSphere eXtended Deployment。
节点	节点是一个通用术语，表示一台机器或一个逻辑分区。	节点表示一组应用服务器进程，由一个节点代理控制，通常部署为每台机器或每个逻辑分区一个节点。
服务器	服务器是一个通用术语，表示物理机器，有时也表示逻辑分区。	服务器通常表示一个 Application Server 实例，是 Java 虚拟机的一种具体配置，客户 Java 代码将在其上运行。
dmgr/drmgr	drmgr 是动态资源管理器配置命令，这是一条 AIX 命令，用于安装和配置动态逻辑分区（dlpar 脚本）。	dmgr 是 Deployment Manager 的缩写，这是一种特殊的 Java 进程，控制给定 WebSphere 单元内的资源配置。

Power System 和 AIX 5 上的 WebSphere 战略

对于大多数组织的电子商务解决方案来说，高可用性和可伸缩性是两大关键基础设施适应性要求。利用 IBM WebSphere Application Server Network Deployment V6 的高级特性和功能（如工作负载管理和集群）、IBM POWER 硬件（以及微分区、DLPAR、分区移动性等高级特性）和 AIX 操作系统可满足这些需求。

在考虑 WebSphere 部署所用的恰当拓扑时存在多种因素，本章介绍了其中的主要考虑事项。探讨了可伸缩性、可用性、会话管理和可维护性等主题。

关于拓扑的详细信息，包括对优势和劣势、必要软件和拓扑选择标准的讨论，请参阅《WebSphere Application Server V6 Planning and Design WebSphere Handbook Series，SG24-6446》。

备注：本文所讨论的考虑是想也可作为其他分布式平台的基础。但本文的目标在于利用 POWER5 提供的高级虚拟化特性和功能。

可伸缩性考虑事项

随需应变计算要求具备根据当前需求伸缩应用程序的能力。因而，可伸缩性对于提高效率、降低成本有着十分重要的意义。这一节将讨论使用 WebSphere Application Server 的可伸缩性战略，它将帮助您确保高可用性、负载均衡，并消除瓶颈问题。

构成 WebSphere 应用程序的基本基础设施组件包括：

Web 服务器和 Web 服务器插件

Web 容器

EJB 容器

数据库

WebSphere Application Server 在各应用服务器中实现 Web 容器和 EJB 容器。每个应用服务器都在其自己的 Java 虚拟机（JVM）中运行。如果所有组件都位于同一个 LPAR 上，就可能要争用 LPAR 资源，因而影响彼此的行为，或者对战略资源产生未经授权的访问。

为了避免出现这些问题，可采用这样一种战略：将一组应用服务器集群化，使之共同接受管理并参与工作负载管理。参与集群的应用服务器可部署在同一个节点上，也可部署在不同的节点上。

其他可伸缩性战略包括：

使用速度更快的机器

创建 LPAR 集群

使用设备服务器

划分工作负载

批量请求

聚合

管理连接

缓存

如需了解这些战略的更多详情，请参阅《WebSphere Application Server V6 Performance and Scalability Handbook，SG24-6392》的第 2 章。

集群

集群就是一组共同接受管理并参与工作负载管理的应用服务器。参与集群的应用服务器可位于同一个节点上，也可位于不同的节点上。一个网络部署单元可能不包含集群，也可能包含多个集群，具体取决于该单元的管理需求。集群是应用服务器的逻辑表达。它不一定与任何节点相关联，不对应于在任何节点上运行的实际服务器进程。一个集群仅包含应用服务器，以及与这些服务器相关的加权工作负载容量。

为何使用集群

集群的使用解决了两大问题，也就是高负载性能降级和宕机时间（系统托管应用服务器）。可伸缩性能通过负载均衡补救高负载性能降级问题。高可用性可通过故障转移补救宕机时间问题。

队列和集群考虑事项

在配置高度可伸缩的生产环境时，特别是在应用程序遭遇瓶颈问题而无法充分利用对称多处理（SMP）服务器的 CPU 时，克隆应用服务器创建集群将成为一项宝贵的资产。

在集群化配置中调整 WebSphere Application Server 系统队列时，应切记，将服务器添加到集群时，服务器下游将接收到两倍的负载，如图 1 所示。

图 1.集群和队列

servlet 引擎是 Web 容器内的关键处理元素，支持 servlet 并使之能够响应请求。

Web 服务器和一个数据源之间有两个 servlet 引擎。假设 Web 服务器、servlet 引擎和数据源（但不包含数据库）都运行在一个 SMP 服务器上。给定这些限制，必须考虑以下队列设置：

将 Web 服务器队列设置翻倍，确保为各 Web 容器分发足够的工作。

缩小 Web 容器线程池，避免使系统资源饱和，如 CPU 或 servlet 使用的其他资源。

缩小数据源连接池的大小，避免使数据库服务器饱和。

缩小应用服务器各实例的 Java 堆参数。对于随 WebSphere Application Server 提供的 Java 虚拟机（JVM）版本，必须保证来自所有 JVM 的堆都保留在物理存储器中。举例来说，如果一个包含 4 个 JVM 的集群运行在一个系统上，全部 4 个堆必须有足够的物理存储器可用。

重点：创建集群时，可选择现有应用服务器作为集群模板，而无须将该应用服务器添加到新集群中（选定的应用服务器仅用作模板，而不会受到集群创建的任何影响）。其他所有集群成员都将根据第一个集群成员的配置创建。

在集群创建过程中或创建之后，可通过多种方式为一个集群添加集群成员。在集群创建过程中，可向集群添加一个现有应用服务器，也可创建一个或多个新应用服务器并将其添加到集群中。此外，还可为已有集群添加额外的成员。根据系统的容量，您可以为各集群成员定义不同的权重。

集群成员必须具有同样的应用程序组件，但其权重、堆大小和其他环境因素可以各不相同。这样的概念允许集群跨异构环境，包括多个 LPAR。（但不要做出任何可能导致各集群成员出现不同应用程序行为的更改）。

启动或停止集群将自动启动或停止所有集群成员，应用程序的更改将传播到集群中的所有应用服务器。

图 2-2 显示了一种包含服务器集群的可行配置的示例。服务器集群 1 仅在节点 B 上拥有两个集群成员。服务器集群 2 与服务器集群 1 完全独立，它在节点 A 上拥有两个集群成员，在节点 B 上拥有三个集群成员。最后，节点 A 包含一个独立的应用服务器，不是任何集群的成员。

图 2. 服务器集群与集群成员

图片看不清楚？请点击这里查看原图（大图）。

对于计划将有高工作负载环境的客户，有必要计划集群在正常条件下和故障条件下的工作方式。

建议：高可用管理器（HAManager）监控众多集群级的资源。总体而言，这会降低一定的性能。如果集群成员正在分页或者进行其他操作，使 HAManager 的功能无法有效运行，HA 管理的事件将启动，表明发现集群成员异常。

因而，我们建议您在正常情况下不要将应用服务器置于高负载下，以便在出现挑战时更好地处理峰值。除此之外，尽可能地减少虚拟存储器分页也会带来更可靠的集群操作环境。

在为 LPAR 执行容量规划时，应考虑应用程序的内存和 CPU 需求。例如，对于 CPU 密集型的应用程序，LPAR 提供应能够支持大量处理器单元，以便满足其峰值需求。

为可伸缩性和故障转移而实现集群

集群是执行应用服务器的垂直和水平伸缩的一种有效方法。

可伸缩性表示系统随时调整以适应更高或更低的使用密度、容量或需求的能力。例如，可伸缩的系统能有效调整为使用规模更大或更小的网络，执行各种复杂性的任务。理想情况下，假设增加的所有机器都能处理自己的那份客户请求，则能通过添加更多服务器和机器处理任意给定负载。每台机器都应按照机器的处理能力比例处理总系统负载重的一部分。

使用集群成员可提升服务器的性能，简化其管理，并支持工作负载管理。

垂直伸缩（上扩拓扑）

在图 2-3 所示的垂直伸缩中，一个应用服务器的多个集群成员是在同一个 LPAR 或节点上定义的，这可更有效地分配 LPAR 的处理能力。

图 3. 垂直伸缩

即便一个 JVM 能充分利用机器的处理能力，出于其他一些原因，您可能也希望机器上具有一个以上的集群成员，如为进程可用性使用垂直集群。如果 JVM 达到内存限制（或存在类似的问题），那么另外一个进程的出现可提供故障转移。

如果您在一个 LPAR 上安装了多个应用服务器实例（假设 LPAR 具有足够的资源，如 CPU 等），创建垂直集群，那么应用程序的吞吐量也会增加。

在操作系统因其他原因制约了进程的可用资源时，垂直集群能帮助更好地利用 LPAR。例如，如果一个 JVM 进程锁定了对称多处理器（SMP）计算机的一个处理器，引入额外的应用服务器实例将允许此进程利用同一台计算机上的其他 CPU（假定它们会被指派给其他处理器）。又如，若操作系统限制可为一个进程形成的连接数量，那么可通过增加应用服务器实例的数量来增加计算机的有效连接数。

尽管垂直伸缩可通过创建多个 JVM 进程来提高可用性，但 LPAR 本身依然是单一故障点。因而，垂直集群的使用不应视为实现高可用性的手段。

在实现垂直集群之前，应确定您的应用程序是否受制于 CPU、I/O 或是网络问题，在确定给定机器的集群成员数量时，应避免使用经验方法。要确定对您的环境和应用程序来说什么才是最合理的，唯一的方法就是优化一个应用服务器的一个实例的吞吐量和性能，随后将其添加到集群，依此增量式地添加集群成员。在将各成员添加到集群中时，应确保对性能和吞吐量进行测试。在配置垂直伸缩拓扑时，应始终监控内存的使用情况，不要超出机器上可用的物理存储器。

总体而言，在大型服务器上，若 CPU 利用率为 85%（或更高），则表示添加额外的集群成员能带来的性能收益微乎其微。

备注：如果应用程序未利用到资源，您可随时将该资源从 LPAR 中移除。如果需要，资源可动态移动到其他 LPAR。

水平伸缩（外扩拓扑）

在水平伸缩中，如图 2-4 所示，集群成员是在多台物理机器（或 LPAR）上创建的 。这允许一个 WebSphere 应用程序在多台机器上运行，同时依然表现为一个系统镜像，最有效地利用分布式计算环境的资源。

在包含众多中小规模的 LPAR 的环境中，水平伸缩尤为有效，涌入一个 LPAR 的大量客户端请求可分发给系统中的多个 LPAR。

图 4. 水平伸缩

图片看不清楚？请点击这里查看原图（大图）。

故障转移是水平伸缩的另一项重要获益。如果一台机器不可用，其工作负载可转给包含集群成员的其他机器。

水平扩展可处理应用服务器进程故障和硬件故障（或维护），而不会使客户端服务出现显著的中断。通常会使用类似的及其托管一个集群中的成员。这使您能以线性的方式轻松规划未来容量。

您还可以使用 WebSphere Application Server Edge 组件来实现水平伸缩，如 Caching Proxy Edge 组件和 Load Balancer 组件包（其中包含 Dispatcher 组件）。

整合垂直伸缩与水平伸缩

WebSphere 应用程序可整合垂直和水平伸缩，以获得两种伸缩技术的收益，如图 2-5 所示。

图 5. 垂直和水平集群

根据实际应用程序的经验之谈，应首先使用垂直伸缩提高性能，谨慎监控服务器与 CPU 的比率和服务器与内存的比率。优化性能之后，首先使用水平伸缩提供故障转移和冗余支持，在保证目标性能的前提下提供 24x7 的正常运行时间。

工作负载管理

工作负载管理是在 WebSphere Application Server Network Deployment V6 中使用应用服务器集群和集群成员实现的。这些集群成员可位于同一个节点上（LPAR），也为分布在多个节点上（LPAR）。

在使用集群化的 WebSphere Application Servers 时，若集群应用服务器出现故障，您的客户端将可自动或手动重定向（根据故障的特点）到另外一个健康的服务器。工作负载管理是在 WebSphere 集群环境中的应用服务器间提供负载均衡和关联的 WebSphere 工具。它能优化 WebSphere Application Server 环境中处理任务的分发，传入的工作请求将分发给能最有效地处理请求的应用服务器。

工作负载管理也是一个提升应用程序性能、可伸缩性和可靠性的过程。它能在服务器不可用时提供故障转移。WebSphere 使用工作负载管理向集群的备选成员发送请求。WebSphere 还会将来自用户的并发请求以 EJB 调用的形式发送到处理第一条请求的应用服务器，会话状态将保存在此应用服务器的内存中。

在部署拓扑包含多个 LPAR 上的应用服务器时，工作负载管理最有效，这是因为此类拓扑提供了故障转移和更高的可伸缩性。它还可提高一个系统包含一台大容量机器上的多个服务器的拓扑结构的可伸缩性。无论是那种情况，它都使系统能够最高效地利用可用计算资源。

IBM WebSphere Application Server Network Deployment V6 可管理两类请求的工作负载，即 HTTP 请求和 EJB 请求：

HTTP 请求可跨多个 Web 容器分发。

在 HTTP 请求抵达 Web 服务器时，必须做出决策。某些对静态内容的请求可由 Web 服务器处理。对动态内容或某些静态内容的请求将传递给在应用服务器内运行的 Web 容器。请求是被直接处理还是传递给 WebSphere 是由 WebSphere Web 服务器插件决定的，此插件在 Web 服务器的进程内运行。下文将此插件称为 WLM 插件。对于这些 WebSphere 请求，Web 容器的高可用性是故障转移解决方案的要素之一。

EJB 请求可跨多个 EJB 容器分发。

当 EJB 客户端从 Web 容器、客户端容器或外部发出调用时，请求将由集群化应用服务器中一个应用服务器内的 EJB 容器处理。如果该服务器发生故障，客户端请求将重定向到另一台可用服务器，我们将此称之为 EJS WLM。

部署到集群的应用程序将并发在所有集群成员上运行。工作负载根据为各集群成员指定的权重分发。因而，处理能力越高的 LPAR 得到的请求越多。在确定拓扑时，如果 LPAR 各有不同，有必要为各 LPAR 指定恰当的权重。此外，也可使用具有相近容量的类似 LPAR。

工作负载管理还关注在出现故障时将现有客户请求转移到其他可用的应用服务器，若集群中的某个应用服务器将要发生故障，它会保证仅将新请求发送至可用进程。此外，工作负载管理使服务器的维护和升级透明化，使用户依然能够使用应用程序。若现有环境无法再处理工作负载，您可在任何时候向集群添加额外的集群成员，提供可伸缩性和性能。

分发工作负载

将请求发送给一组集群化应用服务器中任意服务器的能力使服务器能够共享工作，并提高客户端请求的吞吐量。请求可平均地分布到服务器上，避免出现工作负载不均衡 —— 一个或多个服务器处于空闲或低活动状态，而其他服务器承担过多的负载。负载均衡是工作负载管理的一大优点。

因而，提议的配置应确保配置过程中的各 LPAR 或服务器均分由系统整体处理的总客户端负载。换句话说，一个 LPAR 过载，而另一个 LPAR 几乎空闲，这时的效率是十分低下的。如果所有 LPAR 的容量都大致相同（例如，CPU 功率），那么每个 LPAR 都应处理大致相等的一份负载。如果不是这样，就可能需要通过提供，根据各 LPAR 可用的处理能力按比例分发工作负载。

使用集群成员的权重定义允许具有不同硬件资源的节点（或 LPAR）组成一个集群。具有较高权重的应用服务器能更快地处理请求，因而工作负载管理将向该节点发送更多请求。

由于有多个集群成员可用于处理请求，因而故障对吞吐量和可靠性产生负面影响的可能性不大。集群成员分布在多个节点上，因而即便一台机器发生故障，应用程序也不会停工。如果一个节点发生故障，请求可发送至其他节点。集群也允许在不停止应用程序功能的前提下维护节点。

若要阅读工作负载管理策略的详细说明、了解请求如何分布在可用服务器之上，请参阅《WebSphere Application Server V6 Scalability and Performance Handbook，SG24-6392》的第 6 章和第 7 章。

会话持久性考虑事项

除非您只有一个应用服务器，或者您的应用程序完全无状态，否则维护 HTTP 客户端请求之间的状态也是确定拓扑结构时的考虑因素之一。然而，使用会话信息会在开发人员的便利与系统的性能和可伸缩性造成少许分歧。完全消除会话数据是不可能的，但应尽量将所传递的会话数据的数量减至最少。持久性机制会减少整个系统的容量，也可能会招致增加容量甚至增加服务器数量的额外成本。因而，在涉及 WebSphere 环境时，应尽早考虑会话。

如果应用程序维护 HTTP 请求之间的状态，您使用垂直或水平伸缩，那么就必须考虑使用恰当的会话管理战略。每个应用服务器都在自己的 JVM 进程中运行。为了实现在不丢失状态的前提下从一个应用服务器到另一个应用服务器的故障转移，您需要在多个进程间共享会话数据。

要在 WebSphere Application Server Network Deployment 中实现上述战略，有两种方法：

内存间会话复制

这种方法利用 “数据复制服务”（DRS）在不同应用服务器 JVM 的进程内存之间复制会话数据。DRS 包含在 WebSphere Application Server 之中，在集群成员启动时自动启动。

不需要使用独立数据库存储持久化状态，若数据库本身未使用集群软件提高可用性，这种方法还能避免会话数据库中出现单一故障点。

数据库持久性

利用这种方法，会话数据将存储在所有应用服务器共享的一个数据库中。需要使用外部集群软件保证其具有高可用性。

默认的最大池大小为 10，在为数据库持久性定义连接池大小时，这是一个非常有用的起点。如果您的会话对象较大，或者要处理数以千计的并发用户，那么可能要选择一个更大的值。

关于大会话对象：通过增加页面大小可提高性能，这会将会话对象置于单独一个数据库页面中。例如，在 IBM DB2 中，页面大小可从默认值 4 KB 调整到 8 KB、16 KB 和 32 KB。

使用多行模式选项也可提高性能。

对于较大的会话，会话复制的开销也会随之增加。数据库复制的整体吞吐量低于内存间复制，这是由于数据库 I/O 的限制（数据库成为了瓶颈）。然而，尽管会话较大时的数据库复制较为缓慢，但所占用的 CPU 功率也低于内存间复制，未被占用的处理器能力可供系统中的其他任务使用。

同样，在持久数据库中存储会话状态或使用内存间复制可为系统提供一定程度的容错能力。如果应用服务崩溃或停止，它所处理的所有会话状态都将保持可用 —— 在后台数据库或在正在运行的应用服务器的内存中，因而，其他应用服务器可接管并继续处理与此会话相关的后续客户端请求。

任何一种机制都不能百分之百地保证在服务器崩溃时保留会话状态。但这种情况非常少见，在生产系统整个生命周期中发生的事件中只占很小的比例。

复制会话信息的开销可能极高，具体取决于集群中的应用服务器数量和会话的大小。在这些情况下，数据库持久性可能是内存有限的环境中的最佳选择。

问题在于，如何判断应该选择哪种选项。对于需要跨单元会话故障转移（cross-cell session failover）的配置来说，数据库持久性是最好的选择。在级联故障中，数据库可能会幸免于难，但内存间复制可能不会。类似地，对于内存间复制，所有单元可能只有一个通用的复制器，这可能会导致单点故障（SPOF）。

切记，复制成本主要源于会话对象的串行化和反串行化，在两种情况下都是如此。同样，在两种情况下，随着会话对象大小的增加，性能都会降低。

最终，无论是数据库还是内存间，您的决策要取决于应用程序的可用性需求、应用程序所需的服务质量以及您的技术偏好。

文件存储考虑事项

WebSphere Application Server 事务管理器负责以持久化的形式存储关于完成事务的状态信息，该信息将在事务恢复过程中使用。这种持久化形式称为事务恢复日志，用于在服务器发生故障后完成准备就绪的事务。这项操作也称为事务恢复处理。

除了完成未完成的事务之外，此处理还能确保相关资源管理器之间存在的锁被释放。在 WebSphere Application Server V6 之前，必须重启发生故障的服务器，之后才能执行恢复处理。6.0 版本为对等服务器（另外一个集群成员）引入了处理故障服务器的回复日志的能力，同时继续管理自己的事务工作负载。

这样的能力也称为对等恢复处理，支持解决存在疑问的事务，而无须等待发生故障的服务器重启。这种便捷的功能也是 WebSphere Application Server 高可用性（HA）战略的一部分。

事务恢复的基本需求要求在高可用文件存储中保存事务恢复日志。文件存储基本上就是它所在的文件系统。推荐使用基于硬件或基于软件的工具，最大化文件系统本身的可用性，如使用存储区域网络（SAN）。WebSphere Application Server V6.1 支持集群管理或联网的文件系统。

集群管理的文件系统使用集群和共享磁盘的故障转移确保文件和目录的高可用性。

联网文件系统使用远程服务器存储和访问文件 —— 就像这些文件存储在本地服务器上一样。确保所用文件系统支持访问锁，使用互斥锁确保文件存储组件的完整性（特别是日志文件的完整性）。建议使用 NFS V4。

如需了解更多信息，请参阅《WebSphere Application Server V6 中事务的高可用性和部署考虑事项》，地址为：

http://www.ibm.com/developerworks/cn/websphere/techjournal/0504_beaven/0504_beaven.html

安装自动化考虑事项

安装和配置 WebSphere 软件产品通常需要完成以下这些步骤：

1. 安装所提供的产品版本。

2. 安装最新更新包。

3. 安装最新修订包。

4. 安装 Java 2 Software Development Kit (SDK) 修订包。

5. 按需安装一个或多个中间修订。

6. 创建并配置应用服务器和其他工件。

7. 部署应用程序。

WebSphere Application Server 通常是使用安装向导图形化用户界面（GUI）安装的。但企业往往会自动化安装过程，以便进行重复性的安装和快速部署。WebSphere Application Server 安装可使用两种不同的支持选项实现自动化，即静默安装或 Installation Factory，下面将加以介绍。

静默安装

静默安装使用安装向导，以静默模式安装产品，无需图形化用户界面。静默安装不会显示向导界面，而是由安装程序从您提供的文件中读取所有响应。

必须首先在相应文件中定义安装选项，之后才能发出安装命令。请注意，静默安装模式不接受交互安装选项。请参阅附录 A “样本文件” 第 424 页中的 “WebSphere: responsefile.nd.txt”，查看一个响应文件样本。

了解要安装哪些组件、采用怎样的安装顺序是十分重要的。您必须考虑网络部署的通用安装场景，以确定如何安装您的应用程序服务环境。

WebSphere Application Server Network Deployment 的安装通常涉及两个任务。首先，安装向导安装一组共享的核心产品文件。接下来，安装向导可选择创建一个配置文件。配置文件就是一个独立的数据分区，包含为应用服务器进程定义运行时环境的文件，如部署管理器或应用服务器。

安装向导具有执行新产品安装、向现有安装添加新特性的增量式安装、将安装更新到新服务水平的现有安装更新等功能。

Installation Factory

Installation Factory 可根据您的特定需求量身定制 “即用” 安装包，用于以可靠、可重复的方式安装 WebSphere Application Server。WebSphere Application Server 的安装和配置只需要一个步骤：安装 Installation Factory 创建的定制安装包（CIP）。其他步骤将由您创建的 CIP 自动完成。Installation Factory 将 WebSphere 软件产品的一个版本或发布版的安装镜像与可选资产相结合，创建 CIP。

可选资产可包括以下组件：

1. 适用的维护包。

2. 要在安装和卸载、配置文件创建和删除过程中运行的脚本或 Java 类。

3. 您计划部署的应用程序的企业应用程序存档（EAR）文件，并在单独的应用服务器配置文件中提供默认部署选项。

4. 配置存档（CAR）文件，用于从之前已经安装和定制的独立应用服务器中克隆独立应用服务器配置文件。

5. 其他文件，如您希望使用自己编写的脚本部署的、带有定制选项的 EAR 文件。

唯一必需的资产就是 WebSphere Application Server 安装镜像，可通过产品光盘获得，也可直接下载镜像。

Installation Factory 包含图形化用户界面（GUI）工具（bin 目录中的 ifgui 命令）和命令行界面工具（ifcli 命令）。

在创建 CIP 之前，首先必须为 CIP 创建生成定义。生成定义就是一个 XML 文档，定义 Installation Factory 如何定制 WebSphere Application Server 产品。

使用 Installation Factory GUI 创建生成定义文件，这是一个 XML 文档，指定如何生成 CIP（例如，在哪里找到计划使用的更新包）。您可以直接在 GUI 内生成 CIP，也可以选择保存生成定义文件，随后使用所提供的命令行界面工具在 GUI 之外生成 CIP。

您所创建的 CIP 将包含一个安装程序，可用于以交互方式、安装向导或静默模式安装 CIP。此外，CIP 可执行应用服务器的全新安装，也可应用于应用服务器的现有安装之上。无论是哪种情况，所得到的安装都处于您所要求的维护水平、按照需求配置，您提供的所有应用程序都会被部署。这就是自动化 WebSphere 安装的推荐过程。

JVM 调优

在 AIX 上调优 Java 时，有两个主要领域需要考虑：内存管理和 CPU 性能。这一节简要讨论了这两个领域。

内存管理

在优化 Java 运行时性能时，最优先考虑的就是调优内存管理。在这种上下文内，内存管理是指对象在堆内的分配和取消分配。内存管理是在运行时执行的，而不是在应用程序代码中执行，这是与供应商 JVM 之间的主要差别。IBM 投入了大笔资金，研究 JVM 内的堆管理和垃圾收集。IBM JVM 提供了多种垃圾收集算法或策略，每一种策略都为一种具体的用途量身打造。这些策略可进一步调优以优化性能。

如果一个应用程序需要大量内存，AIX 将提供使用更大的页面大小的机会。使用更大的页面大小将减少与分页相关的开销，从而提高性能。

如果 JVM 的多个实例要在同一台机器或同一个分区内运行，那么可通过使用共享类缓存来减少内存占用、缩短启动时间。

CPU 性能

CPU 性能定义为处理器资源的有效利用率。为 Java 优化处理器利用率的大多数改进都来自创建运行时编译系统。包含 “即时（JIT）” 或 “hotcode” 编译器可大幅度提升 Java 运行时性能。所有 IBM JVM 中都包含 IBM 的 JIT，但也可以为特定应用程序调优 JIT。

AIX 上的 IBM JVX 的一个与众不同的特性就是内置的微分区和动态逻辑分区（DLPAR）功能。如果 JVM 将在一个 LPAR 上运行，而这个 LPAR 是微分区，是其他分区共享的资源，那么应保持谨慎，确保 JVM 始终有足够的内存可用。

除了这些考虑事项之外，还有其他 AIX 操作系统参数可用于进一步优化 Java 运行时性能。第 127 页的第 4 章 “AIX configuration” 介绍了这些可调优的参数。

使用默认 Java 运行时参数运行 WebSphere Application Server 很可能不会获得最佳结果。默认值的配置是为了满足所有类型的应用程序。但每一种应用程序都是独一无二的，因而，最好能确定哪种调优参数能够给特定应用程序带来好处。第 303 页第 6 章 “Tuning the IBM Java Virtual Machine” 中的指导原则可帮助您找到利用 AIX 功能和特性并提供最优结果的调优参数。

备注：IBM WebSphere Application Server 6 和 WebSphere Application Server 6.1 使用 Java 运行时的 Java 5 实现。Java 5 使用 MXBeans，在 javax.management 包中提供新的动态监控功能。

developerWorks 的一篇文章介绍了一种方法，帮助您为运行时监控利用这种 API，请访问以下地址：

http://www.ibm.com/developerworks/cn/java/j-mxbeans/