was超大集群
WAS集群部署方案及安装配置手册
WAS集群部署⽅案及安装配置⼿册1.部署⽅案参考如上图所⽰，中间件平台主要包括两⼤部分：●负载分发层包括两台服务器，通过Heartbeat实现HA，提供浮动IP给客户端，保证了系统不存在单点故障问题负载分发软件采⽤IBM HTTP Server实现通过IBM HTTP Server配置虚拟主机，实现对不同应⽤的请求进⾏分发到不同的后台W AS中间件集群。
●WAS中间件集群包括两台4CPU(每CPU 4Core)服务，每个服务器上通过⽔平扩展可以启动多个W AS服务器。
基于应⽤部署要求，为每个应⽤建⽴⼀个集群，逻辑上实现应⽤之间的隔离。
每个集群可以根据应⽤的负载，动态分配WAS服务器实例数。
如HR应⽤访问量较⼤则分配4个WAS实例。
但最⼩要保证⼀个集群⾄少包括2个W AS实现，并且这两个实例分别在不同的物理服务器上，这样才能保证不出现单点故障。
部署管理器，部署在WAS Server1上。
2.WebSphere 7安装及配置此安装配置说明仅供参考，还需要根据现场实现情况进⾏调整。
2.1.WAS安装⼀、四台服务器拓朴结构其中DM控制台管理⽤户admin,⼝令两个web服务器的管理⽤户也是admin,⼝令⼆、安装后验收可打开应⽤服务器主机的控制管理台，管理⽤户admin,⼝令******服务器－＞集群下建有应⽤集群服务器－＞应⽤服务器下建有两个WEB服务节点共有五个，分别是⼀个控制节点(⼀个dmgr节点)，两个受控节点(两个app节点)，两个⾮受控节点(两个web节点)集群下各受控节点已同步，并启动服务；两个WEB服务已⽣成插件、传播插件并启动。
在DMGR控制管理台可直接控制两个WEB的启动与停⽌。
三、安装前系统检查群集安装时，确认所有机⼦的⽇期要⼀致确认磁盘空间⾜够两个应⽤服务器的安装⽂件放在/was_install两个WEB服务器的安装⽂件放在/http_install安装⽬录都是安装于默认的/opt⽬录下两个应⽤服务器安装后⽣成⽬录/opt/IBM/WebServer/AppServer两个WEB服务器安装后⽣成⽬录/opt/IBM/HTTPServer两个WEB服务器的⽬录/opt/IBM/HTTPServer/plugins放有插件确认管理域之内的所有的机器主机名和ip地址相互能够ping通在安装前，要确保四台机的/etc/hosts⽂件⾥⾯增加四台机的ip与主机名，修改如下**.**.**.1 app1**.**.**.2 app2**.**.**.3 web1**.**.**.4 web2(对于初次安装系统后的主机，因为没有在HOSTS⽂件中增加此类记录，会导致安装失败，现象是安装后⽣成的profiles不完整，并且执⾏失败，启动不了管理服务。
was使用及参数设置
比如TPS下降等，如果WebContainer设置较大时（200-2000），占
用资源。因此根据观察的性能情况和应用情况输入合适的最小、 最大参数值，设置方法如下图所示：
WAS—参数设置
WAS—参数设置
3.监视：执行场景时，可以通过WebSphere Application Server >性
能监视和调整>性能查看>当前活动>启动监视>WebContainer，可以
当然以上说的是在有权限的情况，没权限什么也不用说了。
WAS—参数设置
应用程序已部署为了合理应用资源需要对WAS参数，也是确保能为
最广泛的应用程序提供开箱即用的性能改善，设置WAS参数，那么我们 了解一些参数意思如下： 线程池：线程池是一种多线程处理形式，处理过程中将任务添加到 队列，然后在创建线程后自动启动这些任务。WAS线程池使服务器组件 能够复用线程而不是在运行时创建新线程。创建新线程通常是很耗费时间 和资源的操作。 连接池：连接池是创建和管理一个物理连接的缓冲池，其中会保留一 定数量创建的物理连接不关闭，当有客户端请求时，调用连接池，可以有 效减少物理连接的创建次数，降低直连所带来的系统开销，缓解应用服务 器压力，提高程序性能。
WAS—参数设置
在图中设置512-1分析内存使用情况，如图可以勾选择 “详细垃圾回收”
XXXWAS集群安装部署报告
XX系统WAS集群安装部署报告目前XX系统应用程序部署在XX服务器，单个服务器运行，为提高系统运行效率，增加同时在线人数，现部署为WAS集群。
一、WAS集群拓扑图略（图1）图1是WAS的集群环境，包含两个节点，分布在两台机器上，一台用于Web服务器，用于接收用户请求，并通过plugin配置文件将负载均衡到WAS集群成员上，部署Deployement Manager，作为集中管理接口，管理WAS集群成员；两台作为WAS集群成员，具体处理业务逻辑，一台作为数据库节点，存储业务数据。
DM、Web服务器节点、应用节点是64位Window2003操作系统，数据库服务器为HP-Unix操作系统。
二、应用服务器清单三、搭建WAS ND集群环境首先搭建集群环境，然后在cluster上部署应用程序。
以下是详细操作步骤，最后通过部署应用来检验。
1、准备WAS 配置管理节点（1）在服务器1上安装WAS6 ND 版本(安装结束后不要立即创建profile)，注意安装最新的补丁（此次安装，使用的版本为6.0.2.23）。
最后(安装结束后不要立即创建profile)，注意安装最新的补丁（此次安装，使用的版本为6.0.2.23）1升级6.0-WS-WAS-WinX64-RP0000002.zip，把updateinstaller文件复制到：E:\IBM\WebSphere\AppServer，执行其中的update.exe；2．updi.6000.windows.amd64.zip，把updateinstaller文件复制到：E:\IBM\ WebSphere\AppServer3.把.6.0.2-WS-WAS-WinX64-FP00000023.pak文件复制到。
E:\IBM\WebSp here\AppServer\updateinstaller\maintenance中。
执行E:\IBM\WebSphere\App Server\updateinstaller下面的update.exe完成升级。
WAS集群配置联调
实验6－WAS集群配置联调实验目的：本实验会引导学生完成W AS8的集群配置，之后会安装IHS和Plugins插件，配置集群中的应用使用Web server来进行访问。
实验前提：W AS8.0已经正确安装完毕，同时已经存在一个独立服务器的概要表，概要表中有一个服务器，一般服务器名称是server1。
一、生成部署管理器的概要表1、启动概要表管理工具应用程序，此程序在目录C:\IBM\WebSphere\AppServer\bin\ProfileManagement中，在DOS命令行中启动pmt.bat。
如果是windows操作系统，也可以通过开始菜单来启动W AS服务器，寻找启动W AS 服务器命令顺序是“开始”－》“所有程序”－》“IBM WebSphere”－》“IBM WebSphere Application Server Network Deployment V8.0”－》“工具”－》“概要表管理工具”。
2、在概要表管理工具界面，单击“创建”按钮。
3、在概要表类型中选中“管理”，单击“下一步”按钮。
4、选择“Deployment Manager”单选框，单击“下一步”按钮。
5、选择“典型概要表文件创建”单选按钮，单击“下一步”按钮。
6、取消“启用管理安全性”复选框，单击“下一步”按钮。
７、在概要文件创建总结中界面中，单击“创建”按钮。
8、部署管理器的概要表建立后，如下图，选中“启动第一步控制台”复选框，单击“完成”按钮。
９、第一步的界面如下，单击“安装验证”链接。
10、系统会自动启动DM，从弹出的界面直到看到“安装验证完成”字样后，说明DM已经正常启动安装。
关闭这个界面。
11、进入部署管理器DM的管理控制台，可以从“第一步”中单击“管理控制台”进入，也可以在浏览器中输入下面URL：http://localhost:9061/ibm/admin由于在本机器上已经有一个服务器的概要表，其管理控制台端口是9060，因此在后来建立的DM的概要表会自动使用9061作为DM的管理控制台端口。
WAS70集群配置
WAS7.0集群配置1.任务说明在给定的两台主机上搭建was集群，要求主机一上建立一个管理节点和一个服务节点主机二上建立一个服务节点，并使这两个节点在一个集群下运行。
2.前题需求两台主机操作系统字符集一致两台主机已经安装相同版本的WAS3.测试环境说明操作系统版本：SuseLinux11Sp3 X86-64位操作系统字符集：zh_CN.gb18030WAS版本：7.0.0.27主机一名称/IP：wasdmgr/1.1.1.10主机二名称/IP：wasnode2/1.1.1.11管理单元名称：AmfeDmgrCell01管理节点名称：AmfeDmgr节点一名称：AmfeNode01节点二名称：AmfeNode02集群名称：AmfeClus4.详细步骤4.1.检查两台主机已经安装的概要文件，并删除他们。
4.1.1.root用户登录“wasdmgr”主机、执行下面操作。
显示概要文件并删除现有概要文件4.1.2.root用户登录“wasnode2”主机、执行下面操作。
显示概要文件并删除现有概要文件4.1.3.修改管理节点所在主机”wasdmgr”上的hosts文件如下图4.1.4.修改服务节点二所在的主机”wasnode2”上hosts文件如下图4.2.root用户操作“wasdmgr”主机创建管理节点及服务节点，并将服务节点添加到管理节点上。
4.2.1.创建管理节点：AmfeDmgr创建命令：./manageprofiles.sh -create -templatePath/opt/IBM/WebSphere/AppServer/profileTemplates/dmgr -cellName AmfeDmgrCell01 -profileName AmfeDmgr -profilePath /opt/IBM/WebSphere/AppServer/profiles/AmfeDmgr4.2.2.创建服务节点一：AmfeNode01创建命令：./manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/managed -nodeName AmfeNode01 -profileName AmfeNode01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/AmfeNode014.2.3.将AmfeNode01节点加入管理节点AmfeDmgr节点进行管理添加命令：./addNode.sh wasdmgr 8879注意事项：wasdmgr 是管理节点的主机名4.3.root用户操作“wasnode2”主机创建服务节点，并将服务节点添加到”AmfeDmgr”管理节点上。
用友NC系统WAS集群模式下建测试账套、增打补丁后部署操作手册(修改版)
WAS集群模式下，NC新建账套、增打补丁重新部署操作手册----胡泽栋一．新建测试账套1.1在ufsoft\nchome\bin路径下，打开wasSysConfig.bat。
1.2增加数据源后，点击保存。
（此处保存需要一到两分钟）1.3打开浏览器输入：主应用服务器IP:9060/ibm/console，登录标识随意输入一个，点登录。
如下图。
(linux服务器可以用本机浏览器远程登录)1.4停止所有server。
点击“服务器”-“应用程序服务器”，先勾选master,点击停止，等master停止后，再将其它server停止。
1.5停止群集管理器。
进入如下路径：IBM\WebSphere\AppServer\profiles\Dmgr01\bin，执行stopManager.bat， Linux环境下执行stopManager.sh。
1.6启动群集管理器。
进入如下路径：IBM\WebSphere\AppServer\profiles\Dmgr01\bin，执行startManager.bat， Linux环境下执行startManager.sh。
1.7打开浏览器输入：主应用服务器IP:9060/ibm/console，登录标识随意输入一个，点登录。
(linux服务器可以用本机浏览器远程登录)1.8启动所有server。
点击服务器-应用程序服务器。
1.9用root登录NC系统，选择数据源。
建立账套。
二．增加补丁后部署步骤。
2.1 备份相应补丁处文件，将补丁打入NC路径2.1.1 除补丁需要替换的文件外，请不要往ufsoft\nchome\modules路径下新增任务文件夹2.1.2 备份IBM\HTTPServer\Plugins\config\webserver1下的plugin-cfg.xml文件2.2.1 windows环境，停止apache服务.2.2.2 linux环境登录主应用服务器IP:9060/ibm/console，停止如下图服务2.3打开浏览器输入：主应用服务器IP:9060/ibm/console，登录标识随意输入一个，点登录。
was8.5集群安装部署全攻略
本文为个人学习was8.5集群的学习总结，内容包括：集群的安装和配置、应用的发布、多版本部署等。
仅供参考。
1、准备三台机器，A、B、C，A作为dmgr1，主节点，B、C作为副节点，IHS、ODR服务器。
在三台机上安装websphere相关软件，具体步骤参见“/archives/508”但是这个文档是在一台机上安装和配置集群，和我们下面要做的不一样，所以接下来我们从定制概要表开始做。
2、补充一点安装文档没提到的，要在所有的机器的hosts文件里面加上IP和服务器名，否则可能会出现一些节点不同步的奇怪问题。
修改hosts文件不需要重启的方法是：可以打开命令提示符窗口执行以下命令：ipconfig /displaydns//显示DNS缓存内容ipconfig /flushdns//删除DNS缓存内容这样，系统就会清空本机的DNS缓存，从而不必重启，就能使Hosts文件生效。
3、创建定制概要表要将服务器B的节点加到服务器A上，必须在B上创建一个定制概要表。
定制概要文件是一个空节点，必须将它联合到DM单元中才能运行（也就是说以后祥谦虚拟机上安装的webshpere都要手工去创建一个定制概要表）。
与独立服务器概要文件比较起来，定制概要文件的节点上没有缺省服务器。
定制节点上也没有任何缺省应用程序。
通过联合定制概要文件，就会将它变成受管节点。
在联合之后，定制概要文件将具有节点代理程序进程，但是没有服务器进程。
必须使用DM的管理控制台来定制空节点以用于生产或者其他用途。
在启动节点代理程序之后，它就会对从DM 中发出的命令作出响应。
创建定制概要表的步骤如下：在概要管理工具中点击创建选择定制概要文件选高级概要文件创建起个名字，注意红线这句话，就是说本机上不能有叫这个名字的节点。
选择稍后联合此节点（试了三次在这个地方联合节点都失败，不知道为什么）默认还是默认点击创建（设置密码的时候要注意，不要用！@#￥%……这样的密码，在命令行输入时会有问题）创建成功之后，再联合节点。
WAS中间件服务器介绍
WAS中间件服务器介绍WAS中间件服务器介绍1. 介绍WAS（WebSphere Application Server）是一种中间件服务器，用于构建、部署和管理企业级应用程序。
它提供了一个可靠、安全和可扩展的平台，用于在分布式环境中运行大型应用程序。
本文将详细介绍WAS中间件服务器的各个方面和功能。
2. 架构2.1 组件架构WAS中间件服务器由多个组件构成，包括应用服务器、管理工具、数据源、线程池等。
每个组件都有特定的功能，并相互协作以提供完整的应用程序环境。
2.2 集群架构WAS支持集群架构，可以将多个服务器组成一个集群，提供负载均衡和高可用性功能。
集群架构可以提高应用程序的性能和可靠性。
3. 安全性WAS提供了多种安全功能，包括身份验证、授权、数据加密等。
它还支持各种安全协议和标准，如SSL、TLS、Kerberos等，以保护应用程序和用户数据的安全性。
4. 部署和管理4.1 应用程序部署WAS支持多种方式的应用程序部署，包括本地部署、远程部署、自动部署等。
它还提供了灵活的部署工具和界面，方便开发人员和管理员进行应用程序的部署和管理。
4.2 配置管理WAS提供了丰富的配置管理功能，包括服务器配置、数据源配置、JNDI配置等。
管理员可以通过配置管理工具进行配置的修改和管理。
5. 监控和故障排查WAS提供了强大的监控和故障排查功能，包括性能监控、错误日志分析、线程跟踪等。
管理员可以实时监控应用程序的运行情况，并及时发现和解决问题。
6. 扩展性和性能优化WAS具有良好的扩展性和性能优化能力。
它支持多种插件和扩展模块，可以根据应用程序的需求和规模进行灵活的扩展和优化。
附件：本文档不涉及附件。
法律名词及注释：1. 中间件：指在计算机系统中，处于操作系统和应用程序之间的软件组件，它们用于支持应用程序的运行和通信。
2. WAS（WebSphere Application Server）：是由IBM开发的一种中间件服务器，用于构建、部署和管理企业级应用程序。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
简介对于大多数企业软件拓扑结构，应用程序可伸缩性是一项重要的服务品质。
为了实现可伸缩性，企业级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 所示的包含两个集群的示例。