超级集群解决方案，第 2 部分: 使用 WebSphere DMZ Secure Proxy Server、ODR 和 WebSphere eXtreme Sc

由于应用程序可伸缩性对于大多数企业软件拓扑结构是一项重要的服务品质，因此在 IBM® WebSphere® Application Server Network Deployment 集群中通常部署并执行具有企业级质量的 Java™ EE 应用程序。虽然集群的实际大小也会受到限制，但解决这种限制的一种有用技巧就是实现尽可能大的应用程序可伸缩性，我们称之为 “超级集群”。这个共两部分的系列文章的 第 1 部分 给出了超级集群的定义，并解释了如何将它用于 HTTP 插件和代理服务器。在本系列的第 2 部分中，讨论进一步延伸到 IBM WebSphere DMZ Secure Proxy Server V7 和 IBM WebSphere Virtual Enterprise 中的随需应变路由器（ODR）以及 IBM WebSphere eXtreme Scale。

来自 IBM WebSphere Developer Technical Journal。

 

简介

在 第 1 部分 的讨论中，我们得出的结论是大部分应用程序可伸缩性问题都可以通过使用 IBM WebSphere Application Server 集群解决。尽管应用程序的可伸缩性需求很少会超出单一 WebSphere Application Server 集群的处理能力，但是这种情况确实会发生。对于这些情况，可以用来克服这种潜在的集群大小限制的技巧就是定义一个具有层次结构的集群，即 “超级集群”，如图 1 所示。

图 1. 具有层次结构的超级集群

超级集群的本质就是：

• 将应用程序部署到多个集群中（即 “集群的集群”）。
• 使用合适的路由器分发客户机请求，这样，从客户机的角度来看，包含两层的分层集群看上去就像一个扁平结构的单层传统 WebSphere Application Server 集群。

用于分发客户机请求的路由器的类型直接影响超级集群的应用和相关限制。第 1 部分讨论了如何在超级集群拓扑结构中使用 HTTP 插件或 WebSphere Proxy Server（或结合使用两者）。第 2 部分继续该讨论并进行了拓展，将讨论 IBM WebSphere DMZ Secure Proxy Server V7 和 IBM WebSphere Virtual Enterprise 中的随需应变路由器（ODR）和 IBM WebSphere eXtreme Scale。

使用 WebSphere DMZ Secure Proxy Server

出于安全考虑，您可能不希望将代理服务器放到非保护区（demilitarized zone，DMZ）以外。第 1 部分讨论了一种解决方法，那就是利用 HTTP Plug-in（在 DMZ 中）和 WebSphere Proxy Server（位于协议防火墙内部）来执行路由，如图 2 所示。

图 2. DMZ 中路由到代理服务器的 Web 服务器

另一种方法是利用 WebSphere DMZ Secure Proxy Server V7，如图 3 所示。

图 3. WebSphere DMZ Secure Proxy Server

WebSphere DMZ Secure Proxy Server V7 被作为 WebSphere Application Server Network Deployment 的一部分包含。WebSphere DMZ Secure Proxy Server 是独立安装的，因此提供了一种方法使您能够在 DMZ 中安装和运行代理服务器。

将 WebSphere DMZ Secure Proxy Server 安装到 DMZ 中的一台机器后，创建一个安全的代理配置文件。生成的拓扑结构将是一个新 cell，不同于包含应用服务器集群的后端 cell。由于安全代理服务器并不包含一个 Web 容器，因此无法托管管理控制台。因此，当您需要在 WebSphere DMZ Secure Proxy Server 上配置或执行管理任务时，您可以使用以下选项之一：

• 脚本化（无 GUI）：可以在命令行通过脚本管理服务器。
• 管理代理：创建一个将在 DMZ 上运行的管理代理配置文件，并将安全代理注册到管理代理中。
• 只包含配置的安全代理服务器配置文件：在后端 WebSphere Application Server Network Deployment cell 中，创建一个只包含配置的安全代理服务器配置文件，以定制配置。

对于后一种方法，您将从只包含配置的安全代理配置文件中导出配置，然后将配置导入 DMZ 中的安全代理配置文件。

有关安全代理服务器管理的更详细内容超出了本文的讨论范围。有关更多信息，请参考 WebSphere Application Server Information Center。

路由

安全代理服务器可以根据静态或动态信息路由请求。用于获得路由信息的方法取决于安全代理服务器配置中指定使用的安全模式。

• 低级安全模式

  这类代理配置在 第 1 部分 中进行了讨论。在这种模式下，不存在独立的安装或单独的 cell 等等。相反，您仅仅使用一个常规代理服务器（在与应用服务器相同的 cell 中定义）并根据动态信息执行路由。这种模式需要在代理服务器和应用服务器之间进行充分地通信，并且通常不适合在 DMZ 中使用。

• 中级安全模式

  当配置为中级安全模式，安全代理服务器将获得并使用动态路由信息。然而，由于安全代理服务器和后端应用服务器是完全不同的 cell，动态路由信息将通过一个特殊的核心组桥接 HTTP 通道连接发送给安全代理服务器。实际上，您使用 HTTP 端口创建了一个跨 cell 核心组桥接。因此，路由信息（以及应用程序通信量）在后端应用服务器 cell 和安全代理服务器 cell 之间交换。

  对于低级和中级安全模式，路由信息将由代理服务器动态获取，因此利用超级集群的步骤在本质上与第 1 部分中用于 WebSphere Proxy Server 的步骤相同。

• 高级安全模式

  当配置为高级安全模式时，安全代理服务器将根据静态路由信息路由应用程序请求。这是 WebSphere DMZ Secure Proxy Server 的默认模式，本文后面将详细讨论这种模式。从理论上看，这类似于 HTTP 插件执行路由的方式：您必须生成包含路由信息的平面（flat）文件，编辑该文件以创建超级集群，将文件复制到位于 DMZ 中的安全代理服务器。默认情况下，您生成的路由文件将使用名称 targetTree.xml。

WebSphere DMZ Secure Proxy Server 和超级集群

要理解如何使用安全代理在超级集群之间路由请求，最好的办法是查看一个简单的示例。让我们看一看将安全代理服务器配置为在一个包含两个集群的拓扑结构中进行路由所需的步骤，如图 4 所示。

图 4. 使用 DMZ 安全代理服务器的超级集群

这里故意对所描述的样例拓扑结构进行了限制，但是本文介绍的技巧可以轻松地扩展到更大的拓扑结构中。

使用 WebSphere DMZ Secure Proxy Server 配置超级集群拓扑结构的基本步骤包括：

1. 创建一个 WebSphere Application Server 集群。
2. 将应用程序安装到集群中。
3. 测试和检验应用程序。
4. 创建额外的 WebSphere Application Server 集群。
5. 将应用程序模块映射到每个 WebSphere Application Server 集群。
6. 生成安全代理静态路由文件（targetTree.xml）。
7. 编辑 targetTree.xml 文件，跨多个集群路由请求。
8. 将修改后的 targetTree.xml 文件复制到安全代理服务器 staticRoutes 目录。

许多步骤已经在第 1 部分中详述，因此这里不再重复，但是步骤 6 和 7 特定于 DMZ 安全代理服务器及其跨超级集群路由的能力。让我们详细讨论这些任务。

生成 targetTree.xml 文件

对 DMZ 安全代理服务器使用高级安全模式（默认设置），您需要为安全代理服务器提供一个包含静态路由信息的文件。该文件必须由托管应用程序的后端 cell 生成。为此，对运行在 Dmgr 进程中的 TargetTreeMbean 使用 exportTargetTree命令。例如，通过使用清单 1 所示的 Jython 命令，可以通过脚本生成静态路由文件。

清单 1. 生成 targetTree.xml 文件的脚本命令

// Query for the TargetTreeMbean MBean mbean=AdminControl.queryNames('*:*,type=TargetTreeMbean,process=dmgr') // Invoke exportTargetTree method on the TargetTree MBean AdminControl.invoke(mbean, 'exportTargetTree', C:/WebSphere/AppServer/targetTree.xml')

对于非超级集群拓扑结构，生成的 XML 文件可以简单地从部署管理器传递到安全代理服务器的 <profile root>/staticRoutes 目录。安全代理服务器将使用这个静态路由信息来确定应用程序请求。在超级集群拓扑结构中，必须编辑这个静态路由信息来生成一个单一的扁平式集群，其中包含超级集群的所有成员。

编辑 targetTree.xml 文件

标记 targetTree.xml 和 plugin-cfg.xml 路由文件以生成超级集群的基本理念是相同的：希望为路由器提供有关两层分层集群的扁平视图。

假设您将应用程序模块映射到多个集群并生成了静态路由文件，那么下一步就是编辑该文件。图 5 解释了根据这个简单示例拓扑结构生成的 targetTree.xml 文件的相关代码部分：配置了两个集群（Cluster1 和 Cluster2），并为每个集群定义了两个成员。

图 5. targetTree.xml —— 集群定义

在集群元素中定义 targetTree.xml 文件中的每个服务器（包括非集群式应用服务器）。每个集群元素包含一个服务器部分，其中包含一个（或多个）链接元素，这些链接元素定义了集群的每个成员。

在启动后，安全代理内部的随需应变配置代码将读取静态路由文件并构建内存路由数据。当收到一个应用程序请求后，安全代理将使用这个内存路由信息来定位请求。路由器并不会检查目标服务器是否确实是已配置的 WebSphere 集群的一部分。在路由请求时，WebSphere DMZ Secure Proxy Server 将维护相应的会话亲缘性（affinity）。

编辑 targetTree.xml 文件的主要目的是让安全代理服务器认为分层（超级）集群的所有成员都属于传统的（扁平式）集群。因此，编辑该文件意味着您必须：

1. 确定将哪个集群用作应用程序请求的默认集群。
2. 将另一个集群的成员（从服务器部分中的链接元素）移动到 targetTree.xml 文件中的集群，后一个集群在默认情况下处理客户机请求。

判断将哪一个集群作为默认目标的最简单方法就是使用未经修改的 targetTree.xml 文件测试您的应用程序。即使应用程序模块被映射到多个集群，默认情况下，只有其中的一个集群将被实际用于处理应用程序请求。通常情况下，targetTree.xml 文件中定义的第一个集群将能够服务特定的请求。一旦确定了可用作默认目标的集群，将另一个集群中的成员从它的服务器部分移动到默认集群。从所有其他集群元素的服务器部分，将链接元素剪切并粘贴到默认目标集群的集群元素中的对应服务器部分。

图 6 展示了修改后的 targetTree.xml 文件的一部分，显示将 Cluster1 和 Cluster2 成员合并在一起来创建超级集群。

图 6. targetTree.xml 超级集群：Cluster1

在上面的示例中，默认目标集群为 Cluster1。因此 <!-- server section --> 中的链接元素会从 Cluster2 移动到 Cluster1。将修改后的 targetTree.xml 文件放到 Secure Proxy <profile home>/staticRoutes 目录后，WebSphere DMZ Secure Proxy Server 将在超级集群中的所有 4 个成员之间分发请求。

注意，您一定要实际地移动链接元素；如果只进行复制的话，它们仍然存在于两个位置，那么路由将无法按照预期工作。与编辑 HTTP 插件路由文件不同的是（将保留未使用的集群定义），安全代理对待静态路由文件的格式和内容更加严格。如果 targetTree.xml 中的服务器被错误地移动，客户机（浏览器）请求会遇到 503 – Service Unavailable error 错误，因为路由器可能无法找到目标集群中的合适成员。

其他注意事项

在使用安全代理实现跨超级集群路由时，需要考虑下面几个其他事项。

• 静态路由 XML 文件可以使用任何名称。例如：targetTree.xml 或 <any name>.xml
• 将静态路由 XML 文件放到安全代理服务器的 <profile home>/staticRoutes 目录。
• 可以将多个静态路由文件（比如 xxx.xml）放到安全代理服务器的 <profile home>/staticRoutes 目录中。它们将自动被合并在一起来生成一个单一的内存路由表。您可以避免这种自动合并，方法就是创建一个子目录（例如 <profile home>/staticRoutes/saved）来单独存放静态路由文件的较早版本。
• 不会自动重新加载对静态路由文件作出的修改（比如 xxx.xml）。要获得这些修改，并且停止并重新启动安全代理服务器。
• 在启用后，静态路由文件将始终覆盖动态路由。安全代理配置将在服务器范围内被保存到名为 proxy-settings.xml 的文件中。这个配置文件包含属性 enableStaticRouting="true"，该属性将实施静态路由。

限制

如第 1 部分所述，任何超级集群拓扑结构都存在限制和局限性。在使用 WebSphere DMZ Secure Proxy Server 作为路由器时，要注意以下限制：

• 安全代理只能够支持超级集群的路由 HTTP 协议。
• 模式没有提供会话故障转移和会话复制支持。可以使用 WebSphere eXtreme Scale 或会话持久性执行会话故障转移。
• 该技巧需要手动地管理静态路由文件。因此，必须手动执行以下操作：
  • 生成静态路由文件。
  • 编辑静态路由文件。
  • 传播静态路由文件。
  • 使静态路由文件与拓扑结构修改保持同步。
• 该技巧可能需要核心组桥接服务（CGBS）配置：
  • 如果集群（应用程序部署目标）位于不同核心组的话，那么就需要在后端 cell 中使用 CGBS。
  • 如果为了动态获得路由信息而在中级安全模式下运行安全代理服务器，那么需要使用 CGBS。

下一小节将查看相同的示例场景，但是将使用 WebSphere Virtual Enterprise 随需应变路由器（代理服务器）在超级集群之间分发请求，而不是使用 WebSphere DMZ Secure Proxy Server。

使用 WebSphere Virtual Enterprise

作为添加到 WebSphere Application Server Network Deployment 中的一项附件，IBM WebSphere Virtual Enterprise 可以用于虚拟化底层 WebSphere Application Server 基础设施。基于用户指定的 Service Level Agreement (SLA) 进行动态操作、健康状况管理、操作监视和应用程序编辑，这些都是 WebSphere Virtual Enterprise（以前称为 WebSphere Extended Deployment Operations Optimization）提供的重要而有用的特性。

随需应变路由器

WebSphere Virtual Enterprise 包含了一个随需应变路由器（ODR）组件，该组件在生成应用程序请求通信量、成功运行应用程序和其他重要功能方面扮演着关键角色。因此，在 WebSphere Virtual Enterprise 拓扑结构中，HTTP 通信将通过 ODR 路由。

从配置和拓扑结构的角度来看，ODR 类似于典型的 WebSphere Application Server Network Deployment 代理服务器。在可伸缩性和高可用性方面，ODR 应当是集群式的。一个典型的 ODR 集群将包含至少两个成员，每个成员应当驻留在单独的机器中。在目前的 WebSphere Virtual Enterprise 实现中，一个 ODR 集群仅仅是一个 ODR 集合。因此，ODR 集群并不是从管理控制台或通过脚本显式创建或管理的：您将创建并管理单独的 ODR。

ODR 和超级集群

和典型的代理服务器一样，ODR 也可以用于将通信路由到超级集群。实现步骤基本上与第 1 部分中用于代理服务器的步骤相同：

1. 创建一个 WebSphere Application Server 集群。
2. 将应用程序安装到集群中。
3. 测试和检验应用程序。
4. 创建额外的 WebSphere Application Server 集群。
5. 将应用程序模块映射到每个 WebSphere Application Server 集群。
6. 将所有包含集群的核心组与包含 ODR 的核心组桥接起来。

和典型的代理服务器一样，不需要手动地编辑任何静态路由文件。ODR 将动态获得路由信息。要使动态路由能够正确地工作，必须使用 CGBS 将包含 ODR 的核心组和包含目标集群成员的核心组桥接起来。

回页首

ODR 超级集群拓扑结构

考虑到安全性，ODR 通常不会被放到 DMZ 中。相反，位于 DMZ 中的 Web 服务器（带有插件）将把 HTTP 请求路由到防火墙内部的 ODR 集群的成员中，如图 7 所示。注意这个拓扑结构与第 1 部分描述的拓扑结构的相似性，后者对超级集群同时使用了 HTTP 插件和代理服务器。

图 7. ODR 代理

ODR 的路由功能类似于典型代理服务器的路由功能。ODR 将以 “应用程序为作用域” 把传入的 HTTP 请求路由到任何能够处理请求的目标服务器中。在 WebSphere Application Server cell 中，ODR 将分发 HTTP 请求，同时维护与 WebSphere 集群成员以及非集群 WebSphere Application Server 实例（其中部署了相关应用程序）的会话亲缘性。在内部，多集群路由组件将非集群式应用服务器作为独立 WebSphere Application Server 集群对待，将应用服务器作为孤立成员。

如图 7 所示，Web 服务器和插件路由器组合将使用严格的轮循（round-robin）方式把 HTTP 请求转发给所有 ODR 集群成员。不需要在插件路由器级别维护会话亲缘性，因为当请求被转发给应用服务器时，会话亲缘性将由 ODR 负责。

正如第 1 部分所示的 HTTP 插件和代理服务器拓扑结构所示，需要用一个特殊的静态路由文件来启用 HTTP 插件组件，使它能够将请求转发给 ODR 集群。ODR 提供了自动生成必需的 plugin-cfg.xml 文件的机制，该文件位于 ODR 的 <profile-home>/etc 目录中。可以使用几个选项来指定生成的插件数据的范围。在 WebSphere Virtual Enterprise 中，这个范围设置帮助插件路由器间接确定了哪些 ODR 属于 ODR 集群。可以配置脚本来将 ODR 生成的插件文件自动复制到 Web 服务器机器上的相应位置。当出现任何相关的配置修改（比如应用程序添加、删除、修改、ODR 数量改变、插件生成范围改变等等）时，将自动生成一个新的插件文件。有关从 ODR 中生成插件路由文件的详细信息，请参考本系列第 1 部分的 图 18 和 19，以及 IBM Redbook Optimizing Operations with WebSphere Extended Deployment V6.1。

其他注意事项

当使用 WebSphere Virtual Enterprise ODR 跨超级集群路由请求时，需要考虑以下事项：

• 与 WebSphere Application Server Network Deployment 相比较，WebSphere Virtual Enterprise 可能会大量使用高可用性管理器公告栏（bulletin board）服务。鉴于这个原因，当使用 WebSphere Virtual Enterprise 时，您应当 将核心组大小限制为 50（作为一项比较保守的举措）。
• 对于典型的代理服务器，您可以在集群的级别配置插件路由文件的生成和分发设置。对于 ODR，这些设置只能在单一的 ODR 级别进行指定。
• 您可以调整 Web 服务器在 ODR 集群成员之间分发请求的方式，方法就是修改默认的轮循加载分发算法的 LoadBalanceWeight 属性的值，该算法位于 ODR 生成的 plugin-cfg.xml 文件中。例如，如果 ODR 集群成员没有托管在具有类似容量的机器中，那么就必须进行调整。
• 目前，生成的插件路由文件只包含在生成后配置并运行的 ODR。
• WebSphere Virtual Enterprise 提供了 创建动态集群 的选项。ODR 的多集群路由能力在传统 WebSphere Application Server 静态集群和特定于 WebSphere Virtual Enterprise 的动态集群之间没有差别。因此，图 7 中的部分或所有集群都可以具有动态多样性。

限制

在使用 WebSphere Virtual Enterprise ODR 作为路由器时，存在以下限制：

• ODR 只能对超级集群使用路由 HTTP 协议。
• 模式没有提供会话故障转移和会话复制支持。您可以使用 WebSphere eXtreme Scale 或会话持久性来实现会话故障转移。
• 如果 ODR 和集群（应用程序部署目标）位于不同的核心组，那么需要用到 CGBS 配置。

下一节将讨论如何将超级集群的概念与 IBM WebSphere eXtreme Scale 联系起来。

使用 WebSphere eXtreme Scale

WebSphere eXtreme Scale 提供了极其强大的一致性分布式缓存。WebSphere eXtreme Scale 在一个托管 Java Virtual Machines (JVMs) 的堆空间中的虚拟化空间缓存数据。WebSphere eXtreme Scale 提供了线性可伸缩性，具有可以预测的吞吐量。它可以用于创建一个弹性网格，该网格有可能存储巨大数量的分区数据。通过使用复制，WebSphere eXtreme Scale 提供了对内置高可用性的支持。它提供了一些用户可配置的插件，用于改变网格的行为。

部署环境

WebSphere eXtreme Scale 在自身的操作中不需要使用 WebSphere Application Server 产品。同样，WebSphere eXtreme Scale 也不需要用到 Java EE JVM。它可以被部署到一个非 WebSphere 的 Java Standard Edition (Java SE) JVM 中。WebSphere eXtreme Scale 可以被部署到 32 位（更普遍的环境）或 64 位 JVM 中。

WebSphere eXtreme Scale 和 WebSphere Application Server

虽然 WebSphere eXtreme Scale 可以用于标准 Java SE 环境中，结合使用 WebSphere eXtreme Scale 和 WebSphere Application Server 可以提供增强的管理功能，同时改善测试、调试、问题诊断等等。

如果您已经熟悉并运行了 WebSphere Application Server Network Deployment，那么会发现在这个环境中部署 WebSphere eXtreme Scale 具有充足的理由。WebSphere Application Server Network Deployment 为管理、部署和配置 WebSphere eXtreme Scale 网格和相关程序提供了一个中心位置。可以使用 Performance Monitoring Infrastructure (PMI) 服务从一个中心位置可视化并监视各种与 WebSphere eXtreme Scale 有关的统计数据。

尽管 WebSphere eXtreme Scale 可以部署到一个单个 JVM 中，但是这类部署不会提供高可用性。此外，单个 JVM 无法缓存大量数据（比如，32 位 JVM 只能提供 2 GB 的可用堆空间）。因此，要缓存大量的高可用性分区数据，需要将 WebSphere eXtreme Scale 部署到多个 JVM 中。在简单的 Java SE 环境中，WebSphere eXtreme Scale 部署通过该产品提供的脚本完成。相同的脚本可以用于在非集群式 WebSphere Application Server 实例中部署 WebSphere eXtreme Scale。然而，使用 WebSphere Application Server Network Deployment 集群可以提供增强的的管理和更简单的 WebSphere eXtreme Scale 部署。

注意，WebSphere Application Server Network Deployment 运行时会消耗一些堆空间来完成执行。因此，在 Network Deployment 环境中部署 WebSphere eXtreme Scale 只会留下少量堆空间来供网格缓存实际的对象；需要对这个特性和增强的管理功能之间进行权衡。

目录服务

WebSphere eXtreme Scale 的设计规定，在启动网格之前需要先给出目录服务。WebSphere eXtreme Scale 目录服务器用于提供布局、位置和管理服务。在非 WebSphere Application Server 环境中，您将特殊 JVM 指定为目录服务器，然后在启动网格之前启动这些 JVM。

在 WebSphere Application Server Network Deployment 环境中，目录服务在默认情况下会在部署管理器进程中启动。然而，可以通过使用以 cell 为作用域的定制属性修改这个默认行为，将一个或多个应用服务器指定为托管目录服务。

部署到 WebSphere Application Server 集群中

WebSphere eXtreme Scale 网格由 WebSphere eXtreme Scale 容器托管。在 WebSphere Application Server 环境中，任何已部署的应用程序的两个配置文件 —— META-INF 目录下的 objectGrid.xml 和 objectGridDeployment.xml（entity.xml 也可能出现在 META-INF 目录中，取决于用于访问缓存的编程模型） —— 都将触发 WebSphere eXtreme Scale 启动容器服务，从而启动网格。

本地或远程网格

WebSphere eXtreme Scale 网格以及使用它的应用程序可以放到同一个 JVM 中，或者应用程序可以运行在一个 JVM 中，并访问位于另一个 JVM 中的网格容器（客户机-服务器远程模式）。如您所料，每种拓扑结构都存在不同的权衡。

在图 8 所示的示例拓扑结构中，WebSphere eXtreme Scale 网格和使用它的应用程序位于相同的 JVM 中。这样在访问网格时会显示出一个性能优势：应用程序在访问缓存数据时不需要网络跃点（network hop）。

图 8. 本地 WebSphere eXtreme Scale 网格

在这个本地网格配置中，前面提到的 WebSphere eXtreme Scale XML 网格配置文件可以被打包到应用程序的 META-INF 目录中。然后可以部署应用程序并从管理控制台中启动它（或通过 wsadmin 脚本）。WebSphere eXtreme Scale 容器和网格将随应用程序一起自动启动（当然，这里假设 WebSphere eXtreme Scale 目录服务已经启动并运行）。

在客户机-服务器远程模式中，WebSphere eXtreme Scale 网格托管在一个 WebSphere 集群中，该集群与托管应用程序的集群是分开的，如图 9 所示。

图 9. 远程 WebSphere eXtreme Scale 网格

这个远程网格配置需要一个网络跃点才能访问网格数据。然而，这种拓扑结构的优点在于提供了隔离，并且能够独立于应用程序的可伸缩性来对网格进行伸缩（比如，WebSphere eXtreme Scale 网格集群中的 JVM 的数量可以不同于应用程序集群中的 JVM 的数量）此外，这种拓扑结构还支持多个不同的应用程序（位于各自的集群中）共享一个数据网格。另一个潜在的优势在于这个拓扑结构使应用程序集群和 WebSphere eXtreme Scale 网格集群能够托管在不同版本的 WebSphere Application Server 中。

如果网格只用于缓存由 Java 原语类型描述的数据，那么可以使用一个简单的应用程序来管理 WebSphere eXtreme Scale 容器。这个简单的应用程序可以部署到网格集群中，并且它可以在自己的 META-INF 目录中包含两个配置文件。因此，启动这个简单的应用程序将自动启动网格容器。

如果非原语数据对象被缓存在网格中，那么这个简单应用程序必须也包含将存储到网格中的对象的类定义，并在 META-INF 目录中保存配置文件。

将这个简单应用程序部署到网格集群中并不是为了执行任何计算工作，而是为 WebSphere eXtreme Scale 运行时提供下面的内容：

• 网格配置参数。
• 类定义，用于对存储在网格中的对象执行序列化和反序列化。

超级集群中的 WebSphere eXtreme Scale 网格

如第 1 部分所述，核心组存在可伸缩性限制，这直接影响 WebSphere Application Server 集群的最大大小。对于 WebSphere Application Server V6.1 和更高版本，通常建议将您的核心组（以及集群大小）限制为最多 100 左右的成员（取决于可用资源、应用程序数量、网络带宽等因素，具体的限制可能不同）。

回忆一下，WebSphere eXtreme Scale 网格的最大大小指所有网格集群成员中空闲堆空间的总和。因此，如果所需的网格/缓存大小要求 WebSphere Application Server 集群超出建议的最大大小，那么应该遵循何种 WebSphere eXtreme Scale 部署策略呢？答案同样是将网格托管在 WebSphere Application Server 超级集群中。这将允许您使用超级集群中所有 JVM 的堆空间来形成一个庞大的网格空间。

为了方便说明，WebSphere eXtreme Scale 没有依赖于核心组或集群；有关集群大小的考虑会影响 WebSphere eXtreme Scale 在 WebSphere Application Server Network Deployment 中的部署。

图 10 展示了一个客户机-服务器风格的 WebSphere eXtreme Scale 网格环境，其中的应用程序被部署到传统的 WebSphere 集群，并且将访问被部署到超级集群中的 WebSphere eXtreme Scale 网格。

图 10. 部署到超级集群中的 WebSphere eXtreme Scale

要创建一个 WebSphere eXtreme Scale 超级集群拓扑结构：

1. 对于 WebSphere eXtreme Scale 网格的预期大小，确定将构成超级集群的 WebSphere Application Server 集群的数量 n（n >= 1）。
2. 创建核心组的数量 n（n >= 1）
3. 现在您拥有包括 DefaultCoregroup 核心组在内的（n >= 1）核心组，对于所有这些核心组：
   • 遵循标准的核心组构成原则。
   • 最佳实践是将每个核心组配置为具有两个首选的协调服务器，最好位于非集群式服务器和不同的物理服务器上。
   • 将每个核心组配置为运行最新版本的核心组协议。
4. 在 DefaultCoregroup 中为包含三个成员的 WebSphere eXtreme Scale 目录服务创建一个水平结构的 WebSphere Application Server 集群（比如，CatalogCluster）：
   • 使用 CatalogCluster 可以确保所有目录服务器都属于同一个核心组，这是 WebSphere eXtreme Scale 部署的要求。
   • 将每个目录服务器放到不同物理机器中，这将提供具有高可用性的目录服务。
   • 使用数量合理的目录服务器（本例中为 3 个）将有助于实现高可用性的目录服务。
   • CatalogCluster WebSphere Application Server 集群将不会成为托管 WebSphere eXtreme Scale 网格的 WebSphere Application Server 超级集群的一部分。
5. 通过正确地定义以 cell 为作用域的 catalog.services.cluster 定制属性，可以将 CatalogCluster 成员指定为 WebSphere eXtreme Scale 目录服务，catalog.services.cluster 属性将列出 CatalogCluster 中的每个成员的主机和端口。
6. 在所有（n >= 1）核心组中创建所需的 WebSphere Application Server 集群，每个集群具有相应数量的集群成员。

配置好 WebSphere Application Server 超级集群拓扑结构后，很可能需要创建一个简单的应用程序来配置和启动网格容器。要配置这个简单的 WebSphere eXtreme Scale 管理应用程序：

1. 创建一个虚拟的应用程序（比如 GridApp），其中必需的类定义和 WebSphere eXtreme Scale 配置文件位于其 META-INF 目录中。
2. 将 GridApp 部署到任意一个准备纳入到超级集群的 WebSphere Application Server 集群中。
3. 将 GridApp 模块映射到所有构成超级集群的 WebSphere Application Server 集群中。使用第一部分中用于 将模块映射到多个集群 的技巧（应用程序不应当映射到 CatalogCluster，因为 CatalogCluster 集群将不会通过托管 WebSphere eXtreme Scale 容器来提供缓存空间）。
4. 确保 CatalogCluster 集群正在运行。
5. 在每个集群中启动虚拟应用程序将自动地启动相关的网格容器。

使用 WebSphere Application Server 集群以及这类简单应用程序将简化 WebSphere eXtreme Scale 管理。通过在所有相关的集群中启用或停止虚拟应用程序，网格容器可以轻松地启动或停止。由于对网格配置文件进行任何修改都需要重启网格，因此本文描述的技巧提供了一种简单、直观的方法来管理包含数百个 JVM 的大型网格。因此，结合使用超级集群和 WebSphere eXtreme Scale 就可以简化从一个中心位置对网格的管理和监视（比如，WebSphere Application Server 部署管理器）。

其他注意事项

在结合使用 WebSphere eXtreme Scale 和超级集群拓扑结构时需要考虑的其他事项包括：

• 一个远程企业级 WebSphere eXtreme Scale 网格不应该和其他用户应用程序位于同一个位置。
• 对于运行在超级集群中的纯 WebSphere eXtreme Scale 网格，不需要桥接任何包含目录服务器集群或网格托管集群的核心组。
• 如果在 Network Deployment 环境中使用非集群式 WebSphere Application Server 实例来托管 WebSphere eXtreme Scale 容器，那么对核心组大小的限制仍然存在。每个进程（不管是否是集群式）都是核心组的一员，并且如果包含分集群式服务器的核心组过于庞大，那么您将会遇到问题。

应用程序和 WebSphere eXtreme Scale 位于一个超级集群中

可以将应用程序和 WebSphere eXtreme Scale 网格同时部署到超级集群中，如图 11 所示（在本例中使用的是客户机-服务器配置）。这个场景使用了两个超级集群，一个用于实现应用程序可伸缩性，另一个用于实现网格可伸缩性，这两个超级集群都可以独立进行伸缩。

图 11. 超级集群中的应用程序和 WebSphere eXtreme Scale 网格

 

HTTP 会话故障转移

在介绍超级集群技术与应用程序可伸缩性和路由器的关系时，我们曾经提到过，HTTP 会话复制不受支持。这是因为 WebSphere Application Server 中的复制服务目前被限制到一个单一核心组中。然而，我们也提到过，可以使用一个 WebSphere eXtreme Scale 网格来在超级集群间提供 HTTP 会话复制，从而支持 HTTP 会话故障转移。

WebSphere eXtreme Scale 包含了一个 HTTP servlet 过滤器，用它来提供 HTTP 会话管理。WebSphere eXtreme Scale 提供了一款实用工具，可以正确地将过滤器插入到应用程序，从而能够存储 HTTP 会话数据并在超级集群间进行复制。对 HTTP 会话数据使用 WebSphere eXtreme Scale 网格将能够在核心组、超级集群甚至是 WebSphere Application Server cell 之间存储和复制 HTTP 会话。

对于 HTTP 会话管理，网格容器常常与应用程序位于相同的 JVM 中。图 12 展示了这样一个拓扑结构。

图 12. 使用 WebSphere eXtreme Scale 为超级集群实现 HTTP 会话管理

当然，也可以使用远程 WebSphere eXtreme Scale 网格实现 HTTP 会话管理，如果需要的话。这样，您就可以将应用程序和网格放到一个标准集群中（图 8），将应用程序和 WebSphere eXtreme Scale 网格放到一个超级集群中（图 12），或者可以在一个远程网格拓扑结构中，将托管集群的应用程序或 WebSphere eXtreme Scale 网格（或同时使用两者）配置为超级集群。需要在以下场景中使用远程网格实现 HTTP 会话管理：多个应用程序计划使用相同的 WebSphere eXtreme Scale 网格存储它们的会话数据，或者 HTTP 会话状态在不同应用程序之间共享。

结束语

本系列的第 2 部分继续展开有关超级集群的讨论，包括 IBM WebSphere DMZ Secure Proxy Server V7 和 IBM WebSphere Virtual Enterprise 的随需应变路由器以及 IBM WebSphere eXtreme Scale。本文描述了手动编辑静态路由所需的策略，这样就可以在 DMZ 安全代理服务器中将两层分层集群表示为一个传统的扁平式集群，并解释了如何结合使用超级集群和随需应变路由器。

超级集群技巧还有一个很有趣的应用，可以将 WebSphere eXtreme Scale 与 WebSphere Application Server Network Deployment 集群结合使用。在这种情况下，如果 WebSphere eXtreme Scale 网格的预期大小超出了单个 WebSphere Application Server 集群提供的堆空间总和，那么可以使用超级集群技巧创建一个超大型网格。事实上，通过增加集群的数量（每个集群具有合理的成员数量），您可以组建能够存储大量数据的 WebSphere eXtreme Scale 网格。本文描述了此类网格的部署拓扑结构、配置和管理。对于将 Java EE 应用程序部署到超级集群的拓扑结构，我们还讨论了使用 WebSphere eXtreme Scale 网格支持 HTTP 会话故障转移的应用。

日常实践用不到超级集群，但是，对于 HTTP 客户机或大型 WebSphere eXtreme Scale 网格，确实存在这方面的需求，您可以使用多种方法来解决这个问题。所有超级集群都存在某种限制，但是根据具体的场景，某些限制可能是非常有必要的。

如果您将来需要使用一个包含 100 多个成员的集群（其中有 50 个成员用于 WebSphere Virtual Enterprise），或者您的部署架构需要足够灵活来容纳超过 100 个应用服务器（其中有 50 个服务器用于 WebSphere Virtual Enterprise）时，那么可以考虑使用超级集群。

从理论上讲，超级集群可以包含的 WebSphere Application Server 实例的数量没有限制，但是超级集群技巧不应该作为实现可伸缩性的万能解决方案。特定 Java EE 应用程序使用的资源也会限制这些应用程序的可伸缩性。例如，对于与数据库有关的应用程序，底层数据库服务器可以承受的数据库连接的最大数量会限制 WebSphere Application Server 实例的数量，而在 WebSphere Application Server 实例中可以同步部署应用程序，因而最终会影响应用程序的可伸缩性。

总的来说，超级可伸缩性是一个极具挑战性的主题。在某些情况下，可能需要转变传统的数据模型和编程原理。这些主题超过了本系列的讨论范围，但是如果您感兴趣的话，可以阅读 Billy Newport 在 WebSphere eXtreme Scale 上的博客，其中提供了有关 eXtreme Transaction Processing (XTP) 的出色概述和更多其它资源。

 

 原文：http://www.ibm.com/developerworks/cn/websphere/techjournal/0907_banerjee/0907_banerjee.html