超级集群解决方案，第 1 部分: 实现应用程序的最大可伸缩性的技巧
如果您的应用程序的客户机负载压力非常大，该怎么办？面对大量的客户机或客户机请求，需要使用大量的应用服务器来处理负载。这类问题的常见解决方案就是利用 IBM? WebSphere? Application Server Network Deployment 集群，但是，如果普通规模的集群仍然无法处理所需的应用程序负载，那又该怎么办？
来自 IBM WebSphere Developer Technical Journal。
?
您可以点击如下链接，马上下载 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 实例中的应用程序的管理是一个容易出错的过程。
JVM 之间的紧密耦合提供了较低的消息延迟（任何成员之间只有一个网络跳转）和快速的故障检测。然而，充分互联的拓扑结构也较大地限制了核心组的可伸缩性。因此，核心组不能像 cell 那样进行同等程度的伸缩，并且较大的 cell 需要划分为多个核心组。根据特定 WebSphere Application Server 环境在核心组之间的通信需求，各个核心组需要使用 核心组桥接服务（core group bridge service，CGBS）连接在一起。
良好构建的核心组应当遵循核心组构建规则进行创建，如 WebSphere Application Server Information Center（参考 参考资料）中所述。其中一条构建规则表明，一个 WebSphere Application Server 集群不能超出一个核心组。换言之，集群中的所有成员必须是同一核心组中的成员。这条规则意味着 WebSphere Application Server 集群的最大大小潜在地受到核心组最大大小的限制。
如果包含有过多成员的话，核心组可能无法正常工作。核心组成员的精确数量限制取决于多个因素，包括可用的 CPU 资源、内存资源、网络带宽、应用程序数量、应用程序类型，等等。因此，无法定义一个精确的限制。然而，如果要制定计划，IBM 提供了以下指导原则：
WebSphere Application Server V6.0.2：当接近 50 个成员时，考虑使用多个核心组。 WebSphere Application Server V6.1 或 V7.0：当接近 100 个成员时，考虑使用多个核心组。注意，以上仅仅是一些指导原则，并且只有对您自己的拓扑结构进行了测试才能确定具体的限制。但是，这些指导原则表示一个 Network Deployment 集群的最大大小应当被限制为 50 到 100 个成员之间。
对于具有某种抽象程度的集群式拓扑结构，某些类型的路由器组件将把客户机请求转发给部署在集群中的应用程序。考虑将应用程序部署到多个集群中，这样每个集群将具备以下特征：
每个集群都属于它自身的核心组。包含数量适中的成员。如果路由器可被配置为将客户机请求转发给每个集群中的成员，那么就可以有效地解决集群大小受限的问题。理想情况下，您希望路由器执行一个合理的负载平衡策略，同时维护必要的服务器亲缘性。因此，典型的超级集群将执行如下操作：
将一个应用程序部署到多个集群（或集群式集群）。使用相应的路由器分发客户机请求，这样，从客户机的角度来看，具有两层结构的集群看上去就像是一个扁平结构的单层传统 WebSphere Application Server 集群。正如您所料，超级集群受到以下几个限制：
目前，超级集群化技术只能应用于 HTTP 协议，而对于 IIOP 或 SIP 等其他协议是无效的。对于 HTTP 协议，某些路由器将自动把请求转发给部署在多个集群的应用程序，而其他路由器则需要手动修改路由数据，才能够将客户机请求分发到部署在多个集群中的应用程序。与传统集群中的应用程序部署不同，超级集群中的应用程序部署并不是一个单步过程，而是涉及到多个步骤。为了演示超级集群的使用，现在假设一个应用程序需要运行在包含 120 个成员的集群中，从而满足客户机负载需求。对于这个例子，可以创建三个新的核心组，在每个核心组中创建一个包含 40 个成员的集群，然后将应用程序部署到这三个集群中。假设使用的是熟悉的 HTTP 插件路由器，生成的超级集群拓扑结构类似于图 6。
如前所述，在超级集群拓扑结构中可以使用各种各样的路由器。下一小节将具体介绍如何配置和使用各种不同的路由器，以及它们的限制和局限性。所有示例都基于 WebSphere Application Server V7。
为了将样例数据保持在一个合理的范围内，对样例拓扑结构故意施加了限制。然而，这里介绍的技巧可以很容易进行扩展，从而能够应用到更大型的拓扑结构中。
配置使用 HTTP 插件路由器的超级集群拓扑结构的基本步骤包括：
这些步骤中的大部分都属于标准 WebSphere Application Server 管理任务（创建集群、安装应用程序、生成插件等等），并且执行这些任务的说明已经被很好地归档到 WebSphereApplication Server Information Center 中。然而，其中两个步骤 —— 即步骤 5 和步骤 7 —— 需要进行一些解释。让我们仔细查看这些 “有些陌生” 的步骤，看看这个简单示例涉及了哪些内容。
“Ping”（图 9）是一个简单的 Java EE 应用程序，它被部署到 Cluster1 中。
图 9. Ping 应用程序
这里的目的是从 Ping 应用程序中将应用程序模块映射到 Cluster1 和 Cluster2。具体做法是通过使用管理控制台访问 Ping 应用程序的配置页面。要管理应用程序模块，从 Ping 应用程序配置页面（图 10）中选择 Manage Modules 链接。
图 10. Ping 应用程序配置
从 Manage Modules 配置模板（图 11）中，您应当能够将应用程序模块映射到部分或所有已配置的集群和服务器。要将应用程序模块映射到多个目标：
注意，除了这两个集群外，应用程序的 Web 模块也被映射到一个 Web 服务器。这是因为在这个例子中，Web 服务器被配置为一个未管理的节点，并且 WebSphere Application Server 被用于管理 Web 服务器。 图 11 描述了 Ping 应用程序的模块被映射到全部两个已配置集群 Cluster1 和 Cluster2。应用程序模块被映射到多个集群后，可以继续生成并编辑 plugin-cfg.xml 文件，下面将进行介绍。
HTTP 插件路由器将根据客户机请求（URL）和 plugin-cfg.xml 文件中包含的信息作出路由决策。客户机请求为 HTTP 插件路由器提供以下信息：
主机名端口URIHTTP 插件实现将解析 plugin-cfg.xml 文件的内容，查看可以适当处理客户机请求的相应目标。HTTP 路由器将请求发送给它所找到的第一个匹配目标。对于集群，HTTP 路由器将客户机请求发送给 ServerCluster 元素中内嵌的所有 Server 因素。路由器并不会检查 Server(s) 是否确实来自于已配置的 WebSphere Application Server 集群。在路由请求时，HTT 路由器将对负载分配使用指定的 LoadBalance 策略，同时维护会话亲缘性。
编辑 plugin-cfg.xml 文件的主要目的是使 HTTP 插件路由器相信，分层（超级）集群中的所有成员都属于一个传统的（扁平式）集群。因此，编辑过程包含以下步骤：
判断目标集群的最简单方法就是对应用程序进行测试。即使您的应用程序模块被映射到多个集群，默认情况下只有一个集群被用来处理应用程序请求。通常情况下，这个集群是 plugin-cfg.xml 文件中最后定义的集群。一旦确定了默认的目标集群，您需要将另一个集群中的服务器条目复制到默认集群中。
图 13 展示了更新后的 plugin-cfg.xml 文件中的有关部分，它将来自 Cluster1 和 Cluster2 的成员合并在一起来创建一个超级集群。
在上例中，默认的目标集群为 Cluster2。因此，Server 和 ServerName 元素被从 Cluster1 复制到 Cluster2 中。由于修改后的 plugin-cfg.xml 文件被放在合适的位置，因此 HTTP 插件路由器将跨越超级集群的所有四个成员分发请求。
要在超级集群的所有成员之间实现均衡的负载平衡，可以修改 超级集群成员的 LoadBalanceWeight属性。对于这个特定的例子 —— 假设所有超级集群成员都具有类似的容量 —— 您可以使用 1000、999、998 和 997 作为 LoadBalanceWeight 属性的值，从而实现循环（round robin）负载平衡。
除了其他重要的功能外，代理服务器还可以将 HTTP 或 SIP 请求转发给 WebSphere Application Servers。代理服务器只不过是众多服务器类型中的一种，可以使用 WebSphere Application Server 管理控制台创建。
要配置使用 WebSphere Proxy Server 的超级集群拓扑结构，执行以下步骤：
您将注意到这些步骤中并没有提及生成或手动编辑任何类型的路由器配置文件。这是因为代理服务器的路由信息是动态获得并更新的。对于超级集群，与使用 HTTP 插件路由器相比，使用代理服务器的优势在于不需要手动编辑任何静态路由信息。权衡点在于所有包含代理服务器的核心组和任何接收请求的集群必须被连接起来。
通过使用这种配置，DMZ 中的 Web 服务器将使用传统的 HTTP 插件路由器把请求转发给代理集群成员。默认情况下，发往代理服务器的请求分发严格遵守循环规则，并且 Web 服务器不会考虑 HTTP 会话亲缘性。代理集群的成员将把请求转发给超级集群的成员。代理服务器在需要时维护 HTTP 会话亲缘性。这里涉及了一个额外的网络跳转（从 Web 服务器跳转到代理服务器），但是大部分情况下，这算不上严重的问题。然而，对于这种拓扑结构需要特别注意 HTTP 插件配置文件的创建。
这里显示的 Proxy settings 链接用于单一的代理服务器配置。如果您的代理集群中包含多个代理服务器，您将需要转到代理集群配置页面来查找相同的 Proxy settings 链接。
对于本文而言，您需要考虑用来处理插件配置文件的生成和传播的设置。对于这些选项，向下翻滚代理服务器设置页面，知道发现名为 Proxy Plugin Configuration Policy 的区段（如图 18 所示）。您将在这里找到两个用于处理 HTTP 插件配置文件的设置：
Generate Plugin Configuration该值将控制您是否希望让代理服务器生成一个 plugin-cfg.xml 文件以及文件生成的范围。
对于插件配置的生成范围，可以指定为 none、All、Cell、Node 和 Server。可以在 <profile home>/etc 目录中找到生成的插件配置文件。
Plugin config change script在 Plugin config change script 字段中，可以输入您希望在完成生成后运行的脚本文件的名称。您可以使用这个选项自动将插件文件传播到所需的 Web 服务器。图 19 展示了代理设置面板中的相同区段，该字段显示的文本为 fly over help。
本节的关键在于，要将 Web 服务器配置为通过 HTTP 插件向代理服务器路由请求，必须将代理服务器配置为生成插件配置文件。
其他注意事项
目前，生成的 plugin-cfg.xml 仅包含在生成文件时启动并运行的代理服务器。如果对代理服务器进行了配置，但未运行，那么它们将不会出现在生成的 plugin-cfg.xml 文件内。因此，您需要确保使用的是在所有代理服务器启动后生成的文件。
在使用代理服务器生成插件配置文件时，如果对环境做出任何将影响文件内容的修改，那么将自动重新生成 plugin-cfg.xml 文件。这类修改的例子包括：
启动新的代理服务器。安装或卸载应用程序。修改虚拟主机定义。修改上下文根。如果要在生成插件路由文件期间执行恢复或类似操作，可能会在 <profile home>/etc 目录中观察到两个不同版本的路由文件：plugin-cfg.xml 和 plugin-cfg-<member name>.xml。后者是一个临时文件，通常不应用于实际的路由。如果发现多个版本的插件路由文件，那么可以在删除 plugin-cfg-<member name>.xml 文件后重新生成插件路由文件。
代理集群
如果需要使用多个代理服务器实现高可用性和可伸缩性，建议创建一个代理集群。代理集群最初被用来简化配置：创建一个包含所有必需工件（比如重定向规则等等）的代理服务器，然后从模板中创建额外的代理服务器（集群成员）。这使您避免了在多个代理服务器中重新配置相同的规则以及其他内容。
结束语
在这个共分两部分的系列文章的第一部分中，我们描述了在将 Java EE 应用程序部署到大型集群以进行扩展时遇到的挑战。同时讨论了超级集群（一个分为两层的 WebSphere Application Server 集群）的一般法则，如何将一些用于 HTTP 客户机的应用程序部署到超级集群中，从而实现最大程度的应用程序可伸缩性。
超级集群的原理主要依赖于拓扑结构中涉及的各种路由器的请求转发能力。本文使用涉及传统 Web Server 插件、WebSphere Application Server 典型代理服务器的拓扑结构以及同时使用这两种路由器的拓扑结构作为示例。某些情况下，必须手动修改自动生成的静态路由信息。本文还解释了在多个集群中部署应用程序的技巧。
对超级集群的需求并不会出现在日常的实践中，但是它会出现在 HTTP 客户机中，这种需求可以得到满足。所有超级集群选项都存在某些限制，但是对于给定的场景，这些限制可能是必要的。
对于以下情况，可以考虑使用超级集群：
您当前需要超过 100 个成员集群，或者您的部署架构需要足够灵活，从而可以在未来的集群中容纳超过 100 个应用服务器。尽管在理论上并没有限制超级集群可以容纳的 WebSphere Application Server 实例的数量，但是不应该将超级集群视为实现可伸缩性的万能解决方案。特定 Java EE 应用程序使用的资源会对这些应用程序的可伸缩性施加限制。例如，对于与数据库有关的应用程序，底层数据库服务器可以承受的数据库连接的最大数量会限制 WebSphere Application Server 实例的数量，而在 WebSphere Application Server 实例中可以同步部署应用程序，因而最终会影响应用程序的可伸缩性。
本系列第 2 部分将继续探讨超级集群技巧，我们将介绍 DMZ Secure Proxy Server for WebSphere Application Server、WebSphere Virtual Enterprise 随需应变路由器和 WebSphere eXtreme Scale 产品。
?
原文：http://www.ibm.com/developerworks/cn/websphere/techjournal/0906_banerjee/0906_banerjee.html
