简介对于大多数企业软件拓扑结构，应用程序可伸缩性是一项重要的服务品质。

为了实现可伸缩性，企业级Java™ EE 应用程序通常被部署到 IBM WebSphere Application Server Network Deployment 集群中，并在其中执行。

然而，集群的实际大小是有限制的。

如果集群的规模还不足以处理所需的应用程序负载，该怎么办？这个共分 2 部分的系列文章介绍了一种有用的技巧，可以在 WebSphere Application Server 中实现最大程度的应用程序可伸缩性，我们将之称为超级集群。

本系列的第一部分介绍了将应用于 HTTP 插件和 WebSphere Proxy Server 的“超级集群” 技巧。

第 2 部分将讨论 DMZ Secure Proxy Server for WebSphere Application Server、IBM WebSphere Virtual Enterprise 随需应变路由器（ODR），以及 IBM WebSphere eXtreme Scale。

集群为了实现可伸缩性，企业级 Java EE 应用程序通常被部署到 WebSphere Application Server Network Deployment（此后简称为 Network Deployment）集群，并在其中执行。

客户机请求跨越集群进行路由，因此将在所有应用服务器进程之间分配工作负载。

图 1. 分布在集群成员之间的客户机请求您可以点击如下链接，马上下载 WebSphere Application Server 软件 v7 版本，体验其为您带来的新特性及新功能。

WebSphere Application Server for Developers v7（完全免费）WebSphere Application Server v7 试用版WebSphere Application Server Express v7 试用版WebSphere Application Server Hypervisor Edition 试用版（虚拟映像）更多关于 WebSphere Application Server 的技术资源，请参考：WebSphere Application Server 产品专题：为您提供了 WebSphere Application Server 相关的文章、教程、多媒体课堂等最新技术资源。

WebSphere Application Server V7 专题：为您总结了与 WAS V7 相关最新的内容和资源，其中包括入门介绍及开发技巧、配置与管理、迁移、监控与测试等。

亲缘性（affinity）如果应用程序使用无状态的方式进行设计，那么请求将被路由到包含已部署应用程序的任意Network Depoloyment 集群成员中（无请求亲缘性）。

然而，根据协议和应用程序设计，客户机请求可以与特定的 Network Deployment 集群成员具有一种亲缘性。

例如，一个 HTTP 会话可能会在处理第一个请求的集群成员中创建，因此该客户机的所有后续请求应当发送到相同的集群成员。

亲缘性例子包括 HTTP 会话与 HTTP 协议的亲缘性、SIP 会话与 SIP 协议的亲缘性、IIOP 的事务亲缘性，等等。

大多数路由器组件在向集群成员（应用服务器）转发请求时都可以维护相应的亲缘性。

故障转移除可伸缩性以外，将应用程序部署到 Network Deployment 集群可以提供高可用性。

如果其中一个集群成员失败，那么路由器可以将客户机请求传递到其他集群成员上的应用程序中。

使用会话故障转移机制将在出现 HTTP 或 SIP 会话时提供透明的故障转移机制。

管理尽管理论上可以使用非集群式的 Network Deployment 实例在上文提到的模式中获得可伸缩性，但是使用 Network Deployment 集群将提供巨大的管理优势。

与部署在非集群式Network Deployment 实例中的应用程序相比，集群式 Network Deployment 实例中的应用程序在启动、停止、安装、卸载或更新方面得到了简化。

事实上，部署在非集群式 Network Deployment 实例中的应用程序的管理是一个容易出错的过程。

集群规模限制IBM WebSphere Application Server V6.0 引入了一个称为高可用性管理器（HAM）的组件。

该组件同时提供了称为核心组（core group）的新配置属性。

虽然对高可用性管理器和所有相关功能的讨论超出了本文的范围，但是核心组构建规则会对集群规模的限制产生影响，因此需要对核心组有一个基本的了解：核心组核心组指一个静态的高可用性域，其中包含一组紧密耦合的 WebSphere Application Server 进程。

WebSphere Application Server cell 中的每个进程都是核心组的一员。

核心组进程建立通向彼此的网络连接，并使用这些连接监视和判断某个进程是否正在运行，或者发生故障。

核心组的所有成员以网状拓扑结构彼此连接，如图 2 所示。

图 2. 核心组中的 WebSphere Application Server 进程JVM 之间的紧密耦合提供了较低的消息延迟（任何成员之间只有一个网络跳转）和快速的故障检测。

然而，充分互联的拓扑结构也较大地限制了核心组的可伸缩性。

因此，核心组不能像 cell 那样进行同等程度的伸缩，并且较大的 cell 需要划分为多个核心组。

根据特定WebSphere Application Server 环境在核心组之间的通信需求，各个核心组需要使用核心组桥接服务（core group bridge service，CGBS）连接在一起。

图 3. 大型 WebSphere cell 中的多个核心组核心组构建规则良好构建的核心组应当遵循核心组构建规则进行创建，如 WebSphere Application Server Information Center（参考参考资料）中所述。

其中一条构建规则表明，一个 WebSphere Application Server 集群不能超出一个核心组。

换言之，集群中的所有成员必须是同一核心组中的成员。

这条规则意味着 WebSphere Application Server 集群的最大大小潜在地受到核心组最大大小的限制。

图 4. 集群必须是核心组的子集核心组大小限制如果包含有过多成员的话，核心组可能无法正常工作。

核心组成员的精确数量限制取决于多个因素，包括可用的 CPU 资源、内存资源、网络带宽、应用程序数量、应用程序类型，等等。

因此，无法定义一个精确的限制。

然而，如果要制定计划，IBM 提供了以下指导原则：WebSphere Application Server V6.0.2：当接近 50 个成员时，考虑使用多个核心组。

WebSphere Application Server V6.1 或 V7.0：当接近 100 个成员时，考虑使用多个核心组。

注意，以上仅仅是一些指导原则，并且只有对您自己的拓扑结构进行了测试才能确定具体的限制。

但是，这些指导原则表示一个 Network Deployment 集群的最大大小应当被限制为 50 到 100 个成员之间。

挑战您已经看到，Network Deployment 集群的最大大小受到核心组的最大大小的限制，这意味着集群的最大大小被限制为 50 到 100 个成员之间，具体取决于硬件、拓扑结构、应用程序等因素。

这是一个可伸缩的数量，可为大多数应用程序提供足够的伸缩性。

然而，如果应用程序需要极端的可伸缩性，该怎么办？如果应用程序的可伸缩性需求要求部署到超过隐含限制的集群中，又该怎么办？如何将应用程序部署到大量 Network Deployment 实例中，同时又能尽量保留单一集群部署的管理优势？答案就是超级集群。

回页首超级集群虽然应用程序的可伸缩性需求很少会超过单个 WebSphere Application Server 集群的处理能力，但是确实存在这样的情况。

对于这些场景，可以使用一种技巧来解决这种隐含的集群大小限制，那就是定义一个超级集群或“集群式集群” 的拓扑结构。

超级集群就是指一种具有层次结构的集群，您可以将其看作是典型 WebSphere Application Server 集群的一般化。

图 5. 具有层次结构的超级集群对于具有某种抽象程度的集群式拓扑结构，某些类型的路由器组件将把客户机请求转发给部署在集群中的应用程序。

考虑将应用程序部署到多个集群中，这样每个集群将具备以下特征：每个集群都属于它自身的核心组。

包含数量适中的成员。

如果路由器可被配置为将客户机请求转发给每个集群中的成员，那么就可以有效地解决集群大小受限的问题。

理想情况下，您希望路由器执行一个合理的负载平衡策略，同时维护必要的服务器亲缘性。

因此，典型的超级集群将执行如下操作：将一个应用程序部署到多个集群（或集群式集群）。

使用相应的路由器分发客户机请求，这样，从客户机的角度来看，具有两层结构的集群看上去就像是一个扁平结构的单层传统WebSphere Application Server 集群。

正如您所料，超级集群受到以下几个限制：目前，超级集群化技术只能应用于 HTTP 协议，而对于 IIOP 或 SIP 等其他协议是无效的。

对于 HTTP 协议，某些路由器将自动把请求转发给部署在多个集群的应用程序，而其他路由器则需要手动修改路由数据，才能够将客户机请求分发到部署在多个集群中的应用程序。

与传统集群中的应用程序部署不同，超级集群中的应用程序部署并不是一个单步过程，而是涉及到多个步骤。

为了演示超级集群的使用，现在假设一个应用程序需要运行在包含 120 个成员的集群中，从而满足客户机负载需求。

对于这个例子，可以创建三个新的核心组，在每个核心组中创建一个包含 40 个成员的集群，然后将应用程序部署到这三个集群中。

假设使用的是熟悉的HTTP 插件路由器，生成的超级集群拓扑结构类似于图 6。

图 6. 包含 120 个成员的超级集群如前所述，在超级集群拓扑结构中可以使用各种各样的路由器。

下一小节将具体介绍如何配置和使用各种不同的路由器，以及它们的限制和局限性。

所有示例都基于 WebSphere Application Server V7。

回页首HTTP 插件本节介绍了如何设置和配置超级集群，使用的路由器为 WebSphere Application Server HTTP 插件。

考虑到本文的目的，请参考图 7 所示的包含两个集群的示例。