【IT168 技术文档】

    本文提供了刀片体系结构的简要介绍和WebLogic服务器群集集群能力的概述，其中包括设置工作负载的群集集群实现涉及的一些步骤。接着介绍当群集集群大小由单结点增加到多结点时工作负载的性能和扩展（向外扩展）方面的特征。

    SPECjAppServer2002

    SPECjAppServer2002基准测量基于J2EE 的Java企业应用服务器的性能，并测量J2EE服务器和容器的扩展性。

    PECjAppServer2002强调企业级JavaBean (EJB)容器在处理内存管理复杂程度、连接池、钝化/激活、高速缓存等方面的能力。它以制造、供应链管理和定单/存货商业环境为模型。有4个定义的商业域：制造业、供应商、顾客和公司。该基准的性能结果主要受硬件配置、J2EE应用程序软件和数据库软件影响。安装包括驱动程序、供应商仿真程序、应用服务器和数据库服务器。运行规则要求在测量中，驱动程序和供应商仿真程序必须运行于系统之外。因此需要一个网络和至少两个系统。这个基准可以运行于集中式模式或分布式模式（参阅www.spec.org/jAppServer2002获取说明）。

    使用这种工作负荷的报告结果属于下面三个类别中的一个类别：

    l 单节点系统：带有相干存储系统的单节点同时运行应用服务器和数据库实例。

    l 双节点系统：带有相干存储系统的两个节点中的一个节点运行应用服务器，另一个节点运行数据库。

    l 多节点系统：包括三个或三个以上的节点（运行分布式操作系统集群的系统或非相干存储系统属于这个类别）

    主要的性能衡量标准是每秒总操作量（Total Operations Per Second，TOPS）。TOPS是客户订单事务数加上测量时间（单位秒）除制造工作订单数。在满足兼容运行的约束中有响应时间约束，它们影响所有类别的事务，并限制事务可以由驱动程序注入系统的最大速度，从而影响吞吐量。要获得这种工作负荷的非常好的结果，在满足运行规则和约束的同时，需要通过最大程度地利用应用服务器（用高CPU利用数表示）并调整不同的运行参数来增加吞吐量。

    SPECjAppServer2002 配置

    学习重点放在基准的集中模式，以及类别是一个多节点系统，它由驱动器、数据库服务器和应用服务器集群组成。然而，学习的目的不是报告某一类别的最高性能，而是要实现和学习集群的效果。而且，还有故障转移功能（后面解释），它提供了一个现实的集群场景，确实降低了性能，但并不是性能发布的先决条件。因此，从发布角度来看，报告的性能不是非常好的的。

    刀片体系结构

    刀片服务器构成了模块化计算范例的硬件基础。虽然支座、机架安装系统方法增加了复杂度，但模块化计算降低了复杂度。模块化计算支持更高的自动化和资源虚拟化，实质上创建了无单点故障的可靠系统，并且有助于在增加容量、功能、灵活性的同时降低IT成本。一个新兴的数据中心体系结构技术方法——模块化计算——集成了基于底盘的易删除和替换的模块化硬件资源。基于底盘的系统聚合了相互连接、电缆、交换、电源供应、冷却及其它资源，简化了基础结构和它的管理与服务。模块化计算让管理员能够在易于安装到底盘的服务器主机板上，用各种处理资源——单路、双路、32位和64位等——自定义计算资源，这非常像当前用在大型数据中心的基于底盘的继电器。模块化交换组件和管理组件也可以是底盘的一部分，二者都集成功能并抽象整个系统的监视和控制。

    底盘组件通过模块化底板（或中间板，取决于它们在底盘上的位置）通信，并可以设计成为高可用性和防止单点故障提供了完全冗余，以及允许易服务性。

    随着模块化计算的成熟，未来的虚拟存储能力将把资源视为池，而不管它们的位置怎样，这些池可以快速进行重配置来满足变化的业务需求。今天，管理组件可以自动化许多管理员手动完成的工作，让他们能够把更多时间重点放在其他关键任务和主动性。刀片服务器和模块化计算范例使数据中心资源非常灵活，而且简化了正确影响敏捷商务和操作成本的基础结构。

    刀片服务器集群配置

    所使用的刀片服务器集群可以扩展到14个刀片服务器底板。它包括一个集成的可热插拔Gigabit Ethernet继电器模块（可扩展到两个模块）。我们没有把外部磁盘系统用于集群，但是多达两个集成的热交换纤维通道继电器模块（Fibre Channel Switch Module）是可能的。每个刀片有两个以2.8GHz运行、缓存为512K的Intel Xeon处理器。每个刀片的前端总线运行速度为533MHz，并且每个刀片用2.5GB的DDR SDRAM进行了配置。这最大可以增加到8GB。

     使用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服务器集群支持减轻了工作负荷的配置，并提供了较好的性能。支持故障转移对性能的影响似乎处在合理限制之内。具有集群的性能扩展似乎是非常令人激动的，突出了集群方法的潜在有用性和实用性。