超级集群解决方案，第 1 部分: 实现应用程序的最大可伸缩性的技巧

核心提示： 在上例中，默认的目标集群为 Cluster2，超级集群解决方案，第 1 部分: 实现应用程序的最大可伸缩性的技巧(10)，因此，Server 和 ServerName 元素被从 Cluster1 复制到 Cluster2 中，代理服务器让我们看看在使用 WebSphere Proxy Serve

在上例中，默认的目标集群为 Cluster2。因此，Server 和 ServerName 元素被从 Cluster1 复制到 Cluster2 中。由于修改后的 plugin-cfg.xml 文件被放在合适的位置，因此 HTTP 插件路由器将跨越超级集群的所有四个成员分发请求。

要在超级集群的所有成员之间实现均衡的负载平衡，可以修改 超级集群成员的 LoadBalanceWeight 属性。对于这个特定的例子 —— 假设所有超级集群成员都具有类似的容量 —— 您可以使用 1000、999、998 和 997 作为 LoadBalanceWeight 属性的值，从而实现循环（round robin）负载平衡。

限制

任何超级集群拓扑结构都具有局限性。在使用 HTTP 插件作为路由器时，您应当注意以下这些限制：

目前的 WebSphere Application Server 实现只支持对 HTTP 协议实现超级集群。

模式只提供了可伸缩性，而没有提供会话故障转移：

没有会话复制报告。

可以对会话故障转移使用 WebSphere eXtreme Scale 或会话持久性。

该技巧需要人为地管理 plugin-cfg.xml 文件：

必须手动地编辑 plugin-cfg.xml 文件。

必须禁用插件文件自动生成和传播功能。

必须手动地同步 plugin-cfg.xml 文件与拓扑结构变更。

下一节将继续讨论同一个样例场景，但是将使用 WebSphere Proxy Server 在超级集群间分发请求，而不是 HTTP 插件路由器。

代理服务器

让我们看看在使用 WebSphere Proxy Server 作为路由器时如何设置和配置超级集群，将继续使用上文中包含两个集群的样例，如图 14 所示。