test

Sun Java System Application Server 9.1 部署规划指南

第 2 章 部署规划

在部署 Application Server 之前，请先确定性能和可用性目标，然后再相应地确定硬件、网络和存储要求。

本章包括以下几个部分：

设定性能目标

简单地说，高性能是指最大限度地增加吞吐量并缩短响应时间。除了这些基本目标外，还可以通过确定以下内容来设定特定目标：

可以使用远程浏览器仿真器 (Remote Browser Emulator, RBE) 工具或 Web 站点性能和基准软件（用于模拟预期的应用程序活动）来计算其中的某些度量。通常，RBE 和基准产品将生成并发的 HTTP 请求，然后报告每分钟处理给定请求数的响应时间。然后，您可以使用这些数据来计算服务器的活动。

本章介绍的计算结果并不是一成不变的。在微调 Application Server 和应用程序的性能时，请将这些结果作为工作的参考点。

本节包括以下主题：

估算吞吐量

从广义而言，吞吐量测量的是 Application Server 完成的工作量。对于 Application Server，可以将吞吐量定义为每个服务器实例每分钟处理的请求数。高可用性应用程序还会对 HADB 的吞吐量有要求，因为它们会定期保存会话状态数据。对于 HADB，可以将其吞吐量定义为每分钟存储的会话数据量，它是每分钟的 HADB 请求数与每个请求的平均会话大小的乘积。

如下一节所述，Application Server 吞吐量是多种因素的作用结果，其中包括用户请求的特性和大小、用户数以及 Application Server 实例和后端数据库的性能。可以使用模拟的工作负载作为基准来估算单个计算机上的吞吐量。

高可用性应用程序会产生额外的开销，因为它们会定期将数据保存到 HADB 中。开销量取决于数据量、数据的更改频率和数据的保存频率。前两种因素取决于所使用的应用程序；其中后一种还受服务器设置的影响。

可以将 HADB 吞吐量定义为每分钟的 HADB 请求数与每个请求的平均数据量的乘积。较大的 HADB 吞吐量意味着，需要更多的 HADB 节点以及更大的存储大小。

估算 Application Server 实例上的负载

应考虑以下因素来估算 Application Server 实例上的负载：

最大并发用户数

用户通过客户机（如 Web 浏览器或 Java 程序）与应用程序进行交互。根据用户的操作，客户机会定期向 Application Server 发送请求。只要用户会话既未到期也没有终止，系统就认为用户处于活动状态。在估算并发用户数时，应将所有活动用户包括在内。

下图对每分钟处理的请求数（吞吐量）与用户数之间的典型关系进行了图形说明。最初，随着用户数的增加，吞吐量也会随之增加。不过，随着并发请求数的增加，服务器性能开始趋于饱和，并且吞吐量开始下降。

请确定一个临界点，当超过此限制后，您再添加并发用户时，每分钟可处理的请求数将会下降。该点表示此时已达到最佳的性能，之后吞吐量将开始下降。一般来说，应尽可能地使系统在最佳吞吐量下运行。您可能需要增加处理能力以处理额外的负载并提高吞吐量。

延迟时间

用户并不是连续地提交请求。当用户提交请求后，服务器将接收并处理该请求，然后返回结果，此时，用户需要等待一段时间，然后再提交新请求。两个请求的间隔时间称为延迟时间。

延迟时间取决于用户类型。例如，用于 Web 服务的计算机间交互的延迟时间通常比用户交互的延迟时间短。您可能需要综合考虑计算机和用户交互的情况来估算延迟时间。

确定平均延迟时间是至关重要的。可以使用此时段来计算每分钟需要完成的请求数以及系统可支持的并发用户数。

平均响应时间

响应时间是指 Application Server 为用户返回请求结果所花的时间。响应时间受很多因素的影响，例如，网络带宽、用户数、提交的请求数和类型以及平均延迟时间。

在本节中，响应时间是指平均响应时间。每种类型的请求都具有其自己的最小响应时间。不过，在评估系统性能时，请根据所有请求的平均响应时间进行分析。

响应时间越快， 每分钟处理的请求就会越多。不过，随着系统上的用户数的增加，即使每分钟的请求数有所下降，响应时间也会开始增加，如下图所示：

抱歉：此版本的手册未提供相关图形。

与此图形类似的系统性能图形表明，达到某个临界点后，每分钟的请求数与响应时间将成反比。每分钟的请求数下降得越快，响应时间 （由虚线箭头表示）就会增加得越多。

在该图中，峰值负载点为每分钟的请求数开始下降的点。在该点之前，响应时间的计算并不一定准确，因为在其公式计算中不使用峰值数字。在该点之后（由于每分钟的请求数与响应时间成反比关系），管理员可以使用每分钟的最大用户数和请求数更准确地计算响应时间。

请使用以下公式来确定 Tresponse 的值，即峰值负载时的响应时间 （以秒为单位）：

Tresponse = n/r - Tthink

其中

示例 2–1 计算响应时间

如果以下条件成立：

平均延迟时间 Tthink 为每个请求 3 秒。

因此，响应时间的计算公式为：

Tresponse = n/r - Tthink = (5000/ 1000) - 3 秒= 5 - 3 秒

因此，响应时间为 2 秒。

在计算出系统的响应时间后（尤其是峰值负载时的响应时间），请将其与应用程序可接受的响应时间进行比较。响应时间以及吞吐量是两个影响 Application Server 性能的主要因素。

每分钟的请求数

如果知道任意给定时间的并发用户数、用户请求的响应时间以及平均用户延迟时间， 则可以计算出每分钟的请求数。通常，是从估算系统上的并发用户数开始的。

例如，在运行 Web 站点性能软件后，管理员可推断出在联机银行的 Web 站点上提交请求的平均并发用户数为 3,000 个。此数字取决于已注册成为联机银行会员的用户数、其银行交易行为以及他们选择提交请求的日期或星期的时间等。

因此，如果知道了这些信息，则可以使用本节中介绍的每分钟的请求数公式，计算出系统每分钟可为此用户群处理的请求数。由于峰值负载时的每分钟请求数与响应时间成反比，因此，您可以决定选择每分钟较少的请求数来换取较快的响应时间，或者选择较慢的响应时间来换取每分钟较多的请求数。

微调系统性能首先要对不同的每分钟请求数和响应时间阈值进行试验以选出最佳的值。此后，将确定需要调整的系统区域。

计算上一节的等式中的 r 可得出：

r = n/(Tresponse + Tthink)

示例 2–2 计算每秒的请求数

对于以下值：

每秒请求数的计算结果为：

r = 2800 / (1+3) = 700

因此，每秒的请求数为 700 个，每分钟的请求数为 42000 个。

估算 HADB 上的负载

要计算 HADB 上的负载，请考虑以下因素：

有关配置会话持久性的说明，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 9  章 “配置高可用性会话持久性和故障转移”。

HTTP 会话持久性频率

HADB 每分钟收到的请求数取决于持久性频率。持久性频率决定了 Application Server 将 HTTP 会话数据保存到 HADB 中的频率。

持久性频率选项为：

下表简要说明了持久性频率选项的优缺点。

表 2–1 持久性频率选项的比较

持久性频率选项 

优点 

缺点 

web-method 

确保提供最新的会话信息。 

可能会增加响应时间并降低吞吐量。 

time-based 

响应时间较短，并且可能会提高吞吐量。 

不能完全确保在应用服务器实例出现故障后提供最新的会话信息。 

HTTP 会话大小和范围

每个请求的会话大小取决于会话中存储的会话信息量。

提示 –

要提高整体性能，应尽可能减少会话中的信息量。

可通过持久性范围设置微调每个请求的会话大小。请从以下 HTTP 会话持久性范围选项中进行选择：

要使用此选项，应用程序必须：

表 2–2 持久性范围选项的比较

持久性范围选项 

优点 

缺点 

modified-session 

为没有修改会话状态的请求提供改进的响应时间。 

在执行 Web 方法（通常为 doGet() 或 doPost()）期间， 应用程序必须调用一种会话方法：

  • 如果更改了属性，则调用 setAttribute()。

  • 如果删除了属性，则调用 removeAttribute()。

session 

对应用程序没有限制。 

与 modified-session 和 modified-attribute 选项相比，可能具有更差的吞吐量和响应时间。

modified-attribute 

如果为请求修改的会话状态百分比较低，则请求具有更佳的吞吐量和响应时间。 

当为给定请求修改的会话状态百分比接近 60% 时，吞吐量将会下降，响应时间将会延长。在这种情况下，其性能比使用其他选项的性能要低，因为将属性分隔为各个记录会产生一些开销。 

有状态会话 Bean 检查点

对于 SFSB 会话持久性，HADB 上的负载取决于以下内容：

通常在完成任何涉及 SFSB 的事务之后（即使该事务回滚）执行检查点操作。

为了获得最佳性能，请为检查点指定较少的一组方法。所检查的数据大小以及检查频率决定了在给定客户机交互的响应时间方面产生的额外开销。

网络配置规划

在规划如何将 Application Server 集成到网络中时，请估算带宽要求并使用某种方法规划网络以使其满足用户的性能要求。

本节包括以下主题：

估算带宽要求

要确定所需的网络大小和带宽，请先确定网络通信量和峰值。检查是否在特定时间、星期或日期出现总体流量峰值，然后确定该峰值的持续时间。

在峰值负载期间，网络中的数据包数达到最大级别。通常，如果根据峰值负载进行设计，则需要扩展系统以实现处理 100% 的峰值流量目标。但要记住，任何网络都具有一些无法预测的行为，即便进行了扩展，也并非始终能够处理 100% 的峰值流量。

例如，假定在出现峰值负载时，有 5% 的用户在访问 Application Server 中部署的应用程序时，偶尔会出现无法立即访问网络的情况。在这 5% 的用户中，请估算一下有多少个用户在第一次访问尝试后会再次尝试进行访问。此外，不是所有的用户都能够进行访问，而未能成功访问的用户中，又会有一部分用户再次尝试进行访问。因此，峰值会持续较长的时间，因为在用户继续尝试访问时，峰值情况也会持续下去。

计算所需的带宽

根据设定性能目标中的计算结果，确定在您的站点中部署 Application Server 所需的额外带宽。

根据访问方法（T-1 线路、ADSL 和电缆调制解调器等）， 计算需要增加多少带宽就可以处理估算的负载。例如，假定您的站点使用 T-1 或高速 T-3 线路。在给定带宽的情况下，请根据您所在站点每秒平均生成的请求数以及最大峰值负载来估算网络上所需的线路数。请使用 Web 站点分析和监视工具来计算这些数字。

示例 2–3 计算所需的带宽

一条 T-1 线路可以处理 1.544 Mbps 的数据。因此，由 4 条 T-1 线路组成的网络可以处理大约 6 Mbps 的数据。假定发回到客户机的平均 HTML 页大小为 30 KB，则由 4 条 T-1 线路组成的网络每秒可以处理的通信量如下所示：

6,176,000 位/8 位 = 每秒 772,000 字节

每秒 772,000 字节/30 KB = 每秒大约 25 个并发响应页。

对于每秒 25 页的通信量，此系统每小时可处理 90,000 页（25 x 60 秒 x 60 分钟），因此，每天最多可处理 2,160,000 页（假定全天各时段的负载是均等的）。如果最大峰值负载大于此数值，请相应地增加带宽。

估算峰值负载

全天各时段具有均等的负载可能不太现实。您需要确定峰值负载的出现时间、持续时间以及峰值负载占总负载的百分比。

示例 2–4 计算峰值负载

如果峰值负载占总负载 2,160,000 页的 30% 且持续时间为两小时，这意味着必须在当天的两小时内通过 T-1 线路传输 648,000 页。

因此，为了在这两个小时内处理峰值负载，请根据以下计算结果增加 T-1 线路：

648,000 页/120 分钟 = 每分钟 5,400 页

每分钟/60 秒 5,400 页 = 每秒 90 页

如果 4 条线路每秒可处理 25 页，则大约 4 倍的页数需要 4 倍的线路数，此处为 16 条线路。这 16 条线路用于处理实际上最大为 30% 的峰值负载。显而易见，另外的 70% 负载可在当天的其余时间通过这些线路进行处理。

配置子网

如果使用分层拓扑（应用服务器实例和 HADB 节点位于不同的主机上），可通过将所有 HADB 节点放在单独的子网上来提高性能。这是因为 HADB 使用用户数据报协议 (User Datagram Protocol, UDP)。使用单独的子网可降低该子网外部的计算机上的 UDP 通信量。但请注意，所有 HADB 节点必须位于同一个子网上。

您仍然可以从其他子网中运行管理客户机，但前提是所有节点和管理代理位于同一个子网上。应该可以在所有节点代理内访问任何主机和端口，并且防火墙以及 UDP 阻塞等都不能阻止节点访问。

HADB 使用 UDP 多址广播，因此，必须为包含 HADB 节点的任何子网配置多址广播。

选择网卡

为获得更大的带宽和最佳的网络性能，请至少使用 100 Mbps 的以太网卡，或者最好在承载 Application Server 和 HADB 节点的服务器之间使用 1 Gbps 的以太网卡。

HADB 的网络设置

注 –

HADB 使用 UDP 多址广播，因此，必须在系统路由器和主机网络接口卡上启用多址广播。如果 HADB 跨多个子网，还必须在子网之间的路由器上启用多址广播。为获得最佳结果，请将 HADB 节点全部放在同一个网络中。Application Server 实例可以位于不同的子网上。

如果采用以下建议，可使 HADB 在网络中以最佳方式进行工作：

可用性规划

本节包括以下主题：

设置最佳的可用性

要规划系统和应用程序的可用性，请评估访问不同应用程序的用户组的可用性需求。例如，外部付费用户和业务合作伙伴要求的服务质量 (Quality Of Service, QoS) 通常比内部用户高。因此，与外部付费客户相比，内部用户更容易接受应用程序功能、应用程序或服务器不可用的事实。

下图展示了在事件的发生概率不断下降时，防范这些事件的成本和复杂性却不断增加的情况。在图的一端，简单的负载平衡群集可实现本地化应用程序、中间件以及硬件的容错能力。在图的另一端，位于不同地理位置的群集可以防范影响整个数据中心的重大灾难。

要实现较好的投资回报，确定应用程序中的功能可用性要求通常是非常有必要的。例如， 保险报价系统不可用（可能会丢失新业务）是不可接受的，而帐户管理功能（现有客户可查看其当前的保险项目）暂时不可用，则不太可能使现有客户流失。

使用群集提高可用性

在最基本的情况下，群集是一组应用服务器实例（通常位于多个物理服务器上），对于客户机而言，这些实例显示为单个实例。这可提供水平伸缩性以及比单个计算机上的单个实例更高的可用性。这种基本级别的群集与 Application Server 的 HTTP 负载平衡器插件结合使用，它接受 HTTP 和 HTTPS 请求，并将其转发到群集中的某个应用服务器实例。ORB 和集成的 JMS 代理也会为应用服务器群集执行负载平衡。如果某个实例出现故障、变得不可用（由于网络故障）或无法作出响应，则会将请求仅重定向到现有的可用计算机中。负载平衡器还可以识别有故障的实例何时得到恢复并相应地重新分配负载的情况。

HTTP 负载平衡器还提供一个运行状况检查器程序，它可以监视服务器和特定 URL 以确定它们是否可用。必须小心地控制运行状况检查的开销，以免其本身成为较大的处理负载。

对于无状态应用程序或仅包含较小值的简单用户事务的应用程序，通常只需要使用简单的负载平衡群集。对于有状态的重要应用程序，请考虑使用 HADB 保存会话持久性。有关 HADB 的概述，请参见 Application Server 管理指南第 1 章，产品概念中的高可用性数据库。

要联机执行应用程序的升级，最好将应用服务器实例划分到多个群集中。Application Server 可以将应用程序和实例设置为休眠状态。休眠是指以可控制的方式将实例（或实例组）或特定应用程序设置为脱机状态，而不会影响用户当前使用实例或应用程序。将某个实例设置为休眠状态后，新用户将使用另一个实例上已升级的应用程序。这种类型的应用程序升级称为滚动升级。有关升级实时应用程序的更多信息，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的“升级应用程序而不使可用性受到损失”。

在系统中添加冗余功能

一种实现高可用性的方法是，在系统中添加硬件和软件冗余功能。当一个单元出现故障时，冗余单元将接管该单元。这也称为容错。通常，要最大限度提高可用性，请确定并消除系统中每个可能的故障点。

确定故障类

冗余级别是由系统需要容错的故障类（故障类型）确定的。下面是一些故障类示例：

重复的系统进程可实现单个系统进程和单个计算机的容错能力。通过将重复的镜像（成对）计算机连接到不同的电源，可以实现单个电源的容错能力。通过在不同的建筑物中配置镜像计算机，可以实现单个建筑物火灾的容错能力。通过在不同的地理位置配置这些计算机，可以实现自然灾害（如地震）的容错能力。

使用 HADB 冗余单元提高可用性

为提高可用性，应始终在数据冗余单元 (Data Redundancy Unit, DRU) 中使用 HADB 节点，如设定性能目标中所述。

使用 HADB 备用节点提高容错能力

使用备用节点可提高容错能力。虽然并不强制要求使用备用节点，但它们可提供最大限度的可用性。

故障转移容量规划

故障转移容量规划是指，确定需要在 Application Server 部署中添加多少个额外的服务器和进程，以便在出现服务器或进程故障时，系统可以无缝地恢复数据并继续进行处理。如果系统出现过载，则可能导致进程或服务器出现故障，从而使响应时间变慢，甚至造成服务全部中断。为此类情况做好准备对成功部署至关重要。

要保持容量（尤其是峰值负载时），请在现有部署中添加运行 Application Server 实例的备用计算机。

例如，请考虑一个包含两台计算机的系统，每台计算机运行一个 Application Server 实例。这两台计算机共同处理每秒 300 个请求的峰值负载。如果其中的一台计算机变得不可用，则系统只能处理 150 个请求，假定负载是在两台计算机之间均等分配的。因此，有一半的请求在峰值负载期间无法处理。

设计决策

设计决策包括是根据峰值负载还是稳定状态负载来设计系统的，并确定具有不同角色和大小容量的计算机数量。

根据峰值负载或稳定状态负载进行设计

在典型部署中，稳定状态和峰值工作负载是有差别的：

估计系统处理峰值负载的频率，将决定您要根据峰值负载还是稳定状态负载进行设计。

如果经常出现峰值负载（比如，每天出现多次），则需要扩充容量来处理峰值负载。如果系统在 90% 的时间内都是平稳运行的，而仅有 10% 的时间在峰值状态下运行，则最好部署一个根据稳定状态负载设计的系统。这意味着，仅在 10% 的时间里，系统的响应时间才会变慢。确定系统在峰值状态下运行的频率或持续时间，可以判断是否有必要在系统中添加资源。

设定系统规模

根据应用服务器实例上的负载、HADB 上的负载以及故障转移要求，您可以确定：

Application Server 实例数

要确定所需的应用服务器实例（主机）数，请根据估算 Application Server 实例上的负载中介绍的各种因素评估每个应用服务器实例的环境，即使每个实例可以使用多个中央处理单元 (Central Processing Unit, CPU) 也要进行评估。

HADB 节点数

作为一般准则，计划为系统中的每个 CPU 分配一个 HADB 节点。例如，包含两个 CPU 的计算机使用两个 HADB 节点。

注 –

如果每台计算机（例如，如果使用较大的计算机）有多个 HADB 节点，则必须确保计算机上有足够的冗余和可伸缩性；例如，配备了多个不间断电源和独立磁盘控制器。

或者，使用以下步骤。

Procedure确定所需的 HADB 节点数

  1. 确定以下参数：

    • 最大并发用户数 n users。

    • 平均 BLOB 大小 s。

    • 每个用户的最大事务率，称为 NTPS。

  2. 确定最大主数据量的大小 V data（以千兆字节为单位）。

    请使用下面的公式：

    V data = nusers .s

  3. 确定最大 HADB 数据传输速率 R dt。

    这反映了从应用程序端传入 HADB 的数据量。请使用下面的公式：

    Rdt = nusers .s .NTPS

  4. 确定节点数 N NODES。

    请使用下面的公式：

    NNODES = V data /5GB

    将该值舍入为偶数值，因为节点是成对使用的。

HADB 主机数

根据数据传输要求确定 HADB 主机数。此计算假定所有主机具有类似的硬件配置和操作系统，并且为它们运行的节点分配了所需的资源。

Procedure计算主机数

  1. 确定最大主机数据传输速率 R max.。

    根据经验确定该值，因为它是由网络和主机硬件决定的。请注意，它与上一节中确定的最大 HADB 数据传输速率 R dt 是不同的。

  2. 确定包含此数据所需的主机数

    更新一些主机 (N HOSTS) 上分配的数据量 V 可使每个主机接收大约 4V/N HOSTS 的数据。请使用以下公式确定包含此数据量所需的主机数：

    NHOSTS = 4 .Rdt / Rmax

    将该值舍入为最接近的偶数值，以使每个 DRU 具有相同数量的主机。

  3. 在每个 DRU 上添加一个主机作为备用节点。

    如果其他的每个主机运行 N 个数据节点，则允许此主机运行 N 个备用节点。这可防范单个计算机出现故障而将 N 个数据节点关闭的情况。

    每个主机需要运行至少一个节点，因此，如果节点数小于主机数 (NNODES < NHOSTS)，则调整 NNODES 以使其等于 NHOSTS。如果节点数大于主机数 (NNODES > NHOSTS)，则可以在同一个主机上运行多个节点。

HADB 存储容量

HADB 容量随节点数的增加呈近乎线性增长，直至超过网络容量为止。必须在一个或多个专用磁盘上为每个节点配置存储设备。必须在存储设备上为所有节点分配相同的容量空间。请确保在本地磁盘上分配存储设备。

假定预期大小的会话数据为 x MB。HADB 需将数据复制在镜像节点上，因此，它需要 2x MB 的存储容量。此外，HADB 使用索引来实现对数据的快速访问。两个节点需要额外的 2x MB 以用于索引，所需的总存储容量为 4x。因此，HADB 的预期存储容量要求是预期数据量的 4 倍。

考虑到以后要进行扩容以防止数据从 HADB 中丢失，您必须提供额外的存储容量以便联机进行升级， 因为您可能需要在添加新节点后对数据进行重新分段。在这种情况下，数据设备上需要类似数量 (4x) 的额外空间。因此，预期的存储容量为预期数据量的 8 倍。

此外，HADB 将磁盘空间用作以下空间：

下表简要说明了 x MB 会话数据的 HADB 存储空间要求。

表 2–3 会话大小为 X MB 的 HADB 存储空间要求

条件 

需要的 HADB 存储空间 

在不需要联机的情况下添加或删除 HADB 节点。

4x MB +（4*日志缓冲区大小）+ 设备大小的 1%

在需要联机的情况下添加或删除 HADB 节点。 

8x MB +（4*日志缓冲区大小）+ 设备大小的 1%

如果 HADB 使用的设备空间不足，它不会接受客户机的插入或更新数据请求。不过，它将接受删除操作。如果 HADB 使用的设备空间不足，它将返回错误代码 4593 或 4592，并在历史记录文件中写入相应的错误消息。有关这些消息的更多信息，请参见《Sun Java System Application Server 9.1 Error Message Reference》中的第 14  章 “HADB Error Messages”。

Message Queue 代理部署规划

Java 消息服务 (Java Message Service, JMS) API 是一种消息传送标准，它允许 J2EE 应用程序和组件创建、发送、接收和读取消息。并启用了松散耦合的可靠异步分布式通信。Sun Java System Message Queue（用于实现 JMS）与 Application Server 相集成，使您可以创建消息驱动 Bean (Message-Driven Bean, MDB) 之类的组件。

Sun Java System Message Queue (MQ) 使用连接器模块（也称为资源适配器）与 Application Server 集成在一起，此模块是由 J2EE 连接器体系结构规范 (J2EE Connector Architecture, JCA) 1.5 定义的。连接器模块是一种在 Application Server 中添加功能的标准方法。部署到 Application Server 上的 J2EE 组件使用通过连接器模块集成的 JMS 提供者交换 JMS 消息。默认情况下，JMS 提供者是 Sun Java System Message Queue，但如果愿意，您也可以使用不同的 JMS 提供者，只要它可以实现 JCA 1.5。

在 Application Server 中创建 JMS 资源将会在后台创建连接器资源。因此，每个 JMS 操作将调用连接器运行时并在后台使用 MQ 资源适配器。

除了使用资源适配器 API 以外，Application Server 还使用其他 MQ API 以提供与 MQ 更好的集成。这种紧密集成实现了如下功能：连接器故障转移、传出连接的负载平衡以及传入到 MDB 中的消息的负载平衡。这些功能可实现消息传送通信容错能力和高可用性。

多代理群集

MQ Enterprise Edition 支持使用多个互连的代理实例（称为代理群集）。使用代理群集的情况下，客户机连接将分布在群集的所有代理中。群集可以提供水平可伸缩性并提高可用性。

单个消息代理可扩展到大约 8 个 CPU，并为典型的应用程序提供足够的吞吐量。如果代理进程失败，将会自动重新启动该进程。但是，随着连接到代理的客户机数以及传送的消息数的增加，代理最终将超过诸如文件描述符数量和内存容量之类的限制。

通过在群集中设置多个代理而不是一个代理，您可以：

不过，具有多个代理并不能确保正在处理事务的代理发生故障时，可以在备用代理上继续处理这些事务。虽然 MQ 将与群集中的其他代理重新恢复连接，但会中断事务消息传送并回滚正在进行的事务。这不会影响用户应用程序，但会影响无法完成的事务。由于可以继续使用这些连接，因此可确保服务的故障转移。

因此，MQ 在群集中不支持高可用性持久性消息传送。如果在出现故障后重新启动代理，它将自动恢复并完成持久性消息的传送。持久性消息可以存储在数据库或文件系统中。不过，如果承载代理的计算机不能从硬盘故障中恢复，则可能会丢失消息。

具有 Sun Cluster Data Service for Sun Message Queue 的 Solaris 平台支持透明的持久性消息故障转移。此配置利用 Sun Cluster 的全局文件系统和 IP 故障转移功能提供真正的高可用性，此配置包含在 Java Enterprise System 中。

主代理和客户机同步

在多代理配置中，将在群集的所有代理上复制每个目的地。每个代理知道为所有其他代理上的目的地注册的消息使用方。因此，每个代理可以将消息从其自己直接连接的消息生成方路由到远程消息使用方，然后将消息从远程生成方传送到其自己直接连接的使用方。

在群集配置中， 每个消息生成方直接连接的代理将路由该生成方发送给它的消息。因此，持久性消息是由消息的主代理存储和路由的。

每当管理员在代理上创建或销毁目的地时，此信息将会自动传播到群集中的所有其他代理。同样，每当在主代理中注册消息使用方时，或者使用方与其主代理断开连接时（显式断开、由于客户机或网络故障或其主代理出现故障），就会在整个群集中传播该使用方的相关信息。还会以类似方式将持久订阅的相关信息传播到群集中的所有代理。

配置 Application Server 以使用 Message Queue 代理

Application Server 的 Java 消息服务表示的是 Message Queue 的连接器模块（资源适配器）。您可以通过管理控制台或 asadmin 命令行实用程序管理 Java 消息服务。

MQ 代理（JMS 主机）在 Application Server 进程的单独 JVM 中运行。这允许多个 Application Server 实例或群集共享一组相同的 MQ 代理。

在 Application Server 中，JMS 主机指的是 MQ 代理。Application Server 的 Java 消息服务配置包含了一个 JMS 主机列表（也称为 AddressList），其中列出了将使用的所有 JMS 主机。

使用管理控制台管理 JMS

在管理控制台中，可以使用 Java 消息服务节点为特定配置设置 JMS 属性。您可以设置诸如“重新连接时间间隔”和“重新连接尝试”之类的属性。有关更多信息，请参见《Sun Java System Application Server 9.1 管理指南》中的第 4  章 “配置 Java 消息服务资源”。

Java 消息服务节点下的 JMS 主机节点中包含 JMS 主机列表。可以在该列表中添加和删除主机。对于每个主机，您可以设置主机名、端口号以及管理用户名和密码。默认情况下，JMS 主机列表中包含一个名为 "default_JMS_host" 的 MQ 代理，它表示的是与 Application Server 集成的本地 MQ 代理。

可以配置 JMS 主机列表以包含群集中的所有 MQ 代理。例如，要建立一个包含 3 个 MQ 代理的群集，请在 Java 消息服务中为每个代理添加一个 JMS 主机。Message Queue 客户机使用 Java 消息服务中的配置信息与 MQ 代理进行通信。

使用 asadmin 管理 JMS

除了管理控制台以外，您还可以使用 asadmin 命令行实用程序来管理 Java 消息服务和 JMS 主机。请使用以下 asadmin 命令：

Java 消息服务类型

Application Server 与 MQ 代理之间共有两种类型的集成：本地和远程。您可以在管理控制台的 Java 消息服务页中设置此类属性。

本地 Java 消息服务

如果 Type 属性为 LOCAL，Application Server 将启动和停止 MQ 代理。当 Application Server 启动时，它将启动指定为默认 JMS 主机的 MQ 代理。同样，在关闭 Application Server 实例时，它将关闭 MQ 代理。LOCAL 类型是适用于独立 Application Server 实例的最佳类型。

在类型为 LOCAL 的情况下，请使用“启动参数”属性指定 MQ 代理的启动参数。

远程 Java 消息服务

如果 Type 属性为 REMOTE，Application Server 将使用在外部配置的代理或代理群集。在这种情况下，您必须在 Application Server 之外启动和停止 MQ 代理，并使用 MQ 工具来配置和调整代理或代理群集。REMOTE 类型是适用于 Application Server 群集的最佳类型。

在类型为 REMOTE 的情况下，您必须使用 MQ 工具指定 MQ 代理启动参数。忽略“启动参数”属性。

缺省 JMS 主机

可以在管理控制台的 Java 消息服务页中指定默认 JMS 主机。如果 Java 消息服务类型为 LOCAL，则在 Application Server 实例启动时，Application Server 将启动默认 JMS 主机。

要使用 MQ 代理群集，请删除默认 JMS 主机，然后将群集中的所有 MQ 代理添加为 JMS 主机。在这种情况下，默认 JMS 主机将变为 JMS 主机列表中的第一个 JMS 主机。

也可以显式地将默认 JMS 主机设置为某个 JMS 主机。当 Application Server 使用 Message Queue 群集时，默认 JMS 主机将执行特定于 MQ 的命令。例如，为 MQ 代理群集创建物理目的地时，默认 JMS 主机将执行该命令来创建物理目的地，但群集中的所有代理将使用该物理目的地。

示例部署方案

为满足消息传送需求，请根据您的部署、性能和可用性需求修改 Java 消息服务和 JMS 主机列表。以下各节介绍了一些典型方案。

为获得最佳可用性，如果 Application Server 无法满足消息传送需求，请将 MQ 代理和 Application Server 部署到不同的计算机上。另一种方法是，在每台计算机上运行 Application Server 实例和 MQ 代理实例，直至有足够的消息传送能力。

默认部署

在安装 Application Server 时，将会自动创建域管理服务器 (Domain Administration Server, DAS)。默认情况下，DAS 的 Java 消息服务类型为 LOCAL。因此，在启动 DAS 时，还会启动其默认 MQ 代理。

在创建新的域时，还会创建新的代理。默认情况下，在域中添加独立服务器实例或群集时，会将其 Java 消息服务配置为 REMOTE， 并且其默认 JMS 主机是由 DAS 启动的代理。

默认部署列举了一个 Application Server 群集中包含 3 个实例的默认部署示例 。

将 MQ 代理群集与 Application Server 群集结合使用

要配置 Application Server 群集以使用 MQ 代理群集，请在 Application Server 的 Java 消息服务中将所有 MQ 代理添加为 JMS 主机。然后，创建的任何 JMS 连接工厂和部署的 MDB 将使用指定的 JMS 配置。

下图展示了一个部署示例，其中代理群集中包含 3 个 MQ 代理， 某一群集中包含 3 个 Application Server 实例。

指定特定于应用程序的 MQ 代理群集

在某些情况下，应用程序可能需要使用一个不同于 Application Server 群集所使用的 MQ 代理群集。指定特定于应用程序的 MQ 代理群集说明了这样一个示例方案。为此，请使用 JMS 连接工厂的 AddressList 属性或 MDB 部署描述符中的 activation-config 元素指定 MQ 代理群集。

有关配置连接工厂的更多信息，请参见《Sun Java System Application Server 9.1 管理指南》中的“JMS 连接工厂”。有关 MDB 的更多信息，请参见《Sun Java System Application Server 9.1 Developer’s Guide》中的“Using Message-Driven Beans”。

应用程序客户机

在应用程序客户机或独立应用程序首次访问 JMS 管理对象时，客户机 JVM 将从服务器中检索 Java 消息服务配置。只有重新启动客户机 JVM 后，客户机 JVM 才能获取有关 JMS 服务的其他更改。