使用WebLogic服务器的集群

    一个BEA WebLogic服务器集群由多个相互操作的WebLogic服务器实例构成，用以增加应用程序的扩展性和可靠性。这些组成集群的多个WebLogic服务器实例可以在相同的物理系统或者多个物理系统上运行，但是对于所有客户机请求，它们作为单一的协作整体出现。

    如前所述，集群的最大优势包括扩展性和可用性。为企业应用程序提供附加容量只需要在集群中支持更多的WebLogic服务器实例。

    在支持故障转移的集群中，应用程序组件被部署在多个集群实例上。如果一个节点或一个WebLogic服务器实例出现故障，集群中的其他服务器就在第一个服务器的断点处继续工作，从而维护了可用性和可靠性。

    可以使用WebLogic服务器集群的一些对象包括servlet、JSP和EJB。

    WebLogic服务器集群的体系结构

    集群应该是域的一部分。域可以由多个WebLogic服务器实例组成，其中一些实例可能是集群的，而其他的实例则不是。域逻辑上集群了基于某一标准的多个WebLogic服务器实例。

    每个域都需要单独的管理服务器，它负责配置和管理域中的其他WebLogic服务器实例。管理服务器用有关集群中其他实例的信息（它们的名称/IP地址/监听端口、队列大小和其他选项以及它们应该使用的集群多播地址/端口等）和准备部署在集群中的应用程序文件进行了配置。

    除了管理服务器外，群集也托管着其他的WebLogic服务器实例，它们是真正的“役马”。它们也称作“受管理服务器”，并且是用有关如何联系管理服务器的信息启动的。然后受管理服务器和管理服务器建立通信，并下载配置信息及要部署的应用程序。在从管理服务器检索这些数据后，它们与集群中其他受管理服务器同步。

    EJB集群

    SPECjAppServer2002是研究中使用的工作负荷，因为这个应用程序为它的商业逻辑广泛使用了EJB，加强了应用服务器的EJB基础结构。因此，对EJB集群的讨论是合适的。

    集群中的故障切换和负载均衡是通过复制感知存根（replica-aware stub RAS）取得的。当客户机最初与其中一个受管理服务器联系时，它返回一个RAS，这个存根包含关于客户机请求的特定对象的所有服务器实例的信息。然后客户机——使用存储在存根中的负载均衡算法信息及那个对象的所有主机的信息——把它的请求路由给适当的主机。

    三种主要类型的EJB都是用SPECjAppSever2002进行实现和使用的，它们包括无状态、有状态和实体EJB。

    在无状态EJB的情形中，RAS包含了关于托管 bean的所有WebLogic服务器实例的信息。

    然后客户机从这些实例中选择一个应该路由呼叫给它的实例。这种场景下的故障转移只是移动到托管那个bean的下一个WLS实例。

    有状态EJB需要维护事务的状态。最初根据客户机请求创建它的WebLogic服务器实例称为主服务器（PS）。PS在集群中选择另一个要在上面复制bean的状态的服务器，该选择服务器称为次服务器（SS）。发回到客户机的RAS包含关于PS和SS的信息，当发生PS故障时，客户机可以切换到SS。

    实体EJB的状态被存储在永久存储区中，就像在数据库中一样。保存实体EJB状态的数据存储区在集群中的所有服务器之间共享。如果只有一个实体EJB，RAS就包含关于托管实体bean的所有服务器的信息。如果其中一个服务器出现故障，就可以把请求转移到其他任何服务器（由RAS指出），然后它从数据存储区找出最后提交的bean状态。

    设置SPECjAppServer2002集群

    现在准备讨论使用集群的SPECjAppServer2002的实际实现。

1. 创建可集群的EAR文件

    用户的两个主要WebLogic服务器并发选项是：

    l 乐观并发：应用服务器乐观地处理事务，而不用锁住数据库中的记录或者在需要时回滚它们。

    l 悲观并发：每一个事务都涉及在数据库中锁住记录。

    在集群的WebLogic服务器环境中，SPECjAppServer2002用悲观并发模型展示了比乐观并发模型更好的性能。因此在创建SPECjAppServer.ear文件中支持群集和悲观并发模型。

    WebLogic服务器中的有状态会话bean（stateful session bean，SFSB）通过“内存内复制”（in memory replication，IMR）支持故障转移，因为这些对象在主服务器和次服务器的内存中进行复制。SPECjAppServer2002有两个SFSB——“CartSes”和“BuyerSes”。通过在部署描述符中添加清单1所示的变化，可以支持这些bean的IMR。

    一旦在这些更改之后进行编译和创建，就可以取得specjappserver.ear文件，该文件可以部署在集群的故障转移环境中。

    2. 创建集群

    BEA WebLogic服务器提供了一个称为“BEA WebLogic配置向导”（通过运行script /bea/weblogic81/common/bin/config.sh激活）的直观的基于GUI的向导，它会指导您通过下面的配置过程：配置集群、配置集群中的管理服务器和受管理服务器实例、配置集群中的物理系统、把实例与集群和物理系统关联，以及最后与集群域关联。

    在创建的域目录的位置中，用户会找到用于运行WebLogic服务器实例的脚本startAdminServer.sh 和startManagedServer.sh。在这些脚本中，确定选项DWeblogic.ProductionModeEnabled =true。

    配置了域后，会把前一节创建的EAR文件传输到应用程序子目录，并且在config.xml中，用户把要部署的应用程序指向到这个ear文件。

    为了创建集群，要启动管理服务器。一旦管理员服务器启动并运行，就启动了集群中的其他托管服务器，然后仿真程序（托管servlet的供应商仿真程序）连同不同节点上的驱动程序（它生成到应用服务器的请求）一起启动。

    集群性能：单一节点上的集群开销

    一旦集群配置完成并且具有了功能，就可以运行工作负荷并测量集群性能。如前面所讨论，在WebLogic服务器中支持集群包括三个主要配置变化：（1）更改到集群EAR文件；（2）数据库访问从乐观并发模型转换到悲观并发模型；（3）支持故障转移。单节点应用服务器配置中的这些改变对性能的影响看起来处在合理的限制之内。注意，尽管从乐观并发转到悲观并发在性能上会有所降低，但应用服务器上的CPU利用基本上保持不变。在WebLogic服务器上支持集群对应用服务器的CPU利用或吞吐量（TOPS）似乎没有太大影响，这说明开销还是低的。性能上的其他下降来自支持故障转移。

    集群性能：多节点

    下一阶段是扩展集群大小并测量性能上的扩展。

    可以看到，在集群上增加一个节点中，单节点性能就有约94％的稳定性能增加（例如，2个节点＝1.94×1个节点，而三个节点＝2.88×一个节点）。在“无故障转移”配置中，不能进一步扩展集群，因为高CPU利用率导致了数据库在这个点上成为性能瓶颈。在1-3节点中每增加一个节点，支持故障转移的集群性能扩展都稍低于单节点性能的80％。除了每个节点上必要的与故障转移有关的附加处理外，故障转移通信现在必须经过集群中的节点，从而增加了开销。如果支持故障转移，因为在数据库CPU容量有可用的Headroom，所以还可以增加第4个节点。但要注意，因为在那个点受已达极限的数据库CPU利用的约束不是特别强烈，所以第4个节点的性能并不真正代表工作负荷扩展。集群中每个应用服务器的CPU利用在1-3节点时都特别稳定在80～81％之间。对于4节点集群，数据库局限性防止了应用服务器中CPU利用超过～61％。在所有讨论的配置中，WebLogic服务器通过集群获取了非常平衡的负载，并且整个网络流量对于Gb集群底板是足够低的，因此不会成为性能问题。 

    结束语

    讨论了在使用WebLogic服务器集群支持的基于Intel体系结构的企业刀片服务器上的SPECjAppServer2002的集群实现。刀片服务器群集是一个强大、方便和可靠的平台，有助于减轻复杂实现涉及的工作。在1-3个节点范围，WebLogic服务器集群支持减轻了工作负荷的配置，并提供了较好的性能。支持故障转移对性能的影响似乎处在合理限制之内。具有集群的性能扩展似乎是非常令人激动的，突出了集群方法的潜在有用性和实用性。