超级集群解决方案，第 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。
?
超级集群的本质就是：
将应用程序部署到多个集群中（即 “集群的集群”）。 使用合适的路由器分发客户机请求，这样，从客户机的角度来看，包含两层的分层集群看上去就像一个扁平结构的单层传统 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 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。
这里故意对所描述的样例拓扑结构进行了限制，但是本文介绍的技巧可以轻松地扩展到更大的拓扑结构中。使用 WebSphere DMZ Secure Proxy Server 配置超级集群拓扑结构的基本步骤包括：
许多步骤已经在第 1 部分中详述，因此这里不再重复，但是步骤 6 和 7 特定于 DMZ 安全代理服务器及其跨超级集群路由的能力。让我们详细讨论这些任务。
在集群元素中定义 targetTree.xml 文件中的每个服务器（包括非集群式应用服务器）。每个集群元素包含一个服务器部分，其中包含一个（或多个）链接元素，这些链接元素定义了集群的每个成员。
在启动后，安全代理内部的随需应变配置代码将读取静态路由文件并构建内存路由数据。当收到一个应用程序请求后，安全代理将使用这个内存路由信息来定位请求。路由器并不会检查目标服务器是否确实是已配置的 WebSphere 集群的一部分。在路由请求时，WebSphere DMZ Secure Proxy Server 将维护相应的会话亲缘性（affinity）。
编辑 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。
回页首
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 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 超级集群拓扑结构：
配置好 WebSphere Application Server 超级集群拓扑结构后，很可能需要创建一个简单的应用程序来配置和启动网格容器。要配置这个简单的 WebSphere eXtreme Scale 管理应用程序：
使用 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 网格
?
当然，也可以使用远程 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