J2EE clustering 2
集群和出错恢复服务
在一台server上提供J2EE服务相比在整个集群中提供来说是微不足道的.鉴于集群技术的复杂性,每个application server 有自己独到的实现方式.你应该向供应商了解他们怎么实现集群和entity bean, stateless session bean, stateful session bean以及JMS的出错恢复.许多供应商宣称自己支持集群化组件,但他们对此的定义经常牵涉到集群中的组件.例如,BEA WebLogic Server 5.1支持集群化的stateful session bean,但如果server本身崩溃了,其上所有状态也丢失了.客户只得重新创建stateful session bean,使得原来的在集群中就不可用了. 直到BEA WebLogic 6.0发布,stateful session bean才实现内存复制来集群化和出错恢复.
所有application servers支持EJB clustering,但对可以配置的自动出错恢复的支持有很大的不同. 事实上.有些application servers并不支持EJB client的自动出错恢复.例如, Sybase Enterprise Application Server支持stateful session bean出错恢复, 前提是你从数据库或通过序列化load bean的状态.如前面所提到的,BEA WebLogic 6.0通过内存复制bean的状态来支持 stateful session bean的差错恢复.大多数application server可以在集群中运行JMS,但对个人命名的 Topics和Queues不提供负载均衡和出错恢复.这样,你可能就需要购买可集群的JMS产品,如SonicMQ,来获得Topics和Queues 的负载均衡.
另一个很重要的考虑因素,我们现在要提到的是:HttpSession出错恢复.
HttpSession出错恢复
当原先为用户创建session的服务器崩溃了,HttpSession出错恢复允许用户无缝地从另一台server上获得session信息. BEA WebLogic Server实现了session信息内存复制,而HP Bluestone Total-e-Server采用集中式 session server,它带有HA的备份. SilverStream Application Server和 Sybase Enterprise Application Server采用集中式数据库或文件系统,每个application servers都从中读写.
用数据库/文件系统实现的session持久性的主要缺点在于:当存储大的或很多对象在session中时有限的伸缩性.用户每次向 HttpSession增加一个对象,session中所有的对象都要序列化并写入数据库或共享的文件系统.大多数用数据库实现session持久化的 application server都主张尽量少用session存储object, 但这会限制Web application的结构和设计,特别是用HttpSession存储用户数据时.
基于内存的session持久性把内存中的session信息写到一个备份服务器上,有两种做法.第一种把HttpSession信息写到一个集中式状态服务器(centralized state server). 集群中的所有机器都把HttpSession objects写到这台 server上. 第二种方法,集群中每个节点任意地选择一个节点存储内存中的session信息.每个用户向HttpSession增加object, 该object被单独序列化在写入那台backup server.
上面两种方法中,如果集群中的机器数较少,用专门的state server比任意指定backup server要好,这样可以节省CPU来处理transaction和动态网页的生成.
另一方面,当集群的机器数很大时,专门的state server就成为瓶颈,而向任意指定的backup server复制内存的消耗将随着机器数的增长而线性增长.当增加机器时,用专门的state server,你需要为它加上更多的RAM和CPU.用任意指定的 backup server, 你仅仅增加机器而已,session会平均地分布在所有机器之间.基于内存的持久化提供了灵活的 Web application设计,规模和高可靠性.
现在我们将检查一下单一点失败.
单一点失败
未提供备份的集群服务会造成单一点失败,他们会造成整个集群或部分应用崩溃.例如,WebLogic JMS在集群中仅能有一个Topic运行在一台机器上.如果那台机器碰巧崩溃了,那应用中依赖JMS Topics的部分就不能工作,直到另一个WebLogic instance启动起来(注意只有durable message才能在新的server instance启动时被发送.)
检查一下你的集群是否存在单一点失败.如果有,你得估计一下这样是否能满足应用需求.
下面提及伸缩拓扑.
灵活的伸缩拓扑
集群还需要灵活的拓扑布局.大多数application server还可以充当HTTP server,见图1.
图1. 多合一拓扑
当你的website大多数是动态网页时,这种结构不错.然而,当大多数是静态页面时,要扩展网站的代价就非常昂贵了,因为你要增加 application server用于静态HTML页面请求.所以,适当的做法是:要扩展静态部分,增加Web server, 要扩展动态部分,增加application server,如图2.
图2. 分隔的拓扑
上图的结构主要的缺陷在于:增加了动态页面请求延迟.但是相比灵活的独立扩展而言,微不足道.
最后,对application server的讨论终止于维护性.
维护性
集群中大量机器总避免不了维护问题:维持集群运行,通知应用的改变.Application servers应该提供agent来感知主要服务的崩溃,然后重新启动它们.或者激活backup server. 更进一步,application server应该提供一个简便的方法来更新和同步集群中所有的server.
Sybase Enterprise Application Server和HP Bluestone Total-e-Server提供文件和配置同步服务. Sybase Enterprise Application Server在主机, 组和集群level上提供这些服务. Bluestone则仅提供主机level的. 如果要deploy大的application或很多application, 就要花很长的时间. BEA WebLogic Server 仅提供配置同步. 这两者中,配置同步加上storage area network更能较好地工作,因为可以把变化写入一个逻辑存储介质, 这样所有的机器就能接收到application file的变化. 每台机器只需要从一台集中式 configuration server上接收配置变化就可以了. SilverStream Application server用 dynamic class loader从数据库中载入application files和 configuration. dynamic class loader使得运行中的application server接收变化更方便.
我们已经讨论了application server需要考虑的重要特征.下面就根据我们的准则比较一下4个流行的application server.
Application Server比较
既然我们学习了关于集群的一般知识,让我们把注意力集中在各个application server上,把所学的和现实世界联系起来.我们要比较的是:
HP Bluestone Total-e-Server 7.2.1
Sybase Enterprise Application Server 3.6
SilverStream Application Server 3.7
BEA WebLogic Server 6.0
每个application server的讨论都包含一张HA结构图,接着是它的重要特征的小结.
HP Bluestone Total-e-Server 7.2.1
图3. HP Bluestone 7.2.1拓扑
集群一般特性小结:
Bluestone实现的是独立的JNDI tree集群.作为plug-in运行在Web server中的LBB,提供HTTP请求的负载平衡和出错恢复服务.LBB知道哪台UBS(universal business server)上运行着什么application,可以正确地定向流量.通过EJB Proxy Service和Proxy LBB支持对stateful,stateless session bean和 entity bean的方法间出错恢复. EJB Proxy Service的主要缺点在于增加了每个EJB请求的延迟,而且它同UBS运行在同一机器上.EJB Proxy Service和UBS stub支持UBS崩溃的情况下的出错恢复,但是不支持硬件崩溃的出错恢复.后者出现的情况下,出错恢复是通过客户端配置apserver.txt或Proxy LBB对apserver.txt配置.客户端的apserver.txt里面列出了集群中所有的组件.当有新的组件加入时,所有客户需要用BAM (Bluestone Application Manager)更新该文件或手工逐个主机地更新.在Proxy LBB处配置apserver.txt将用户和集群中的变化隔离,但为EJB请求引入了新的延迟.HP Bluestone是唯一的一个提供集群化和负载均衡JMS的application server.
集群集中时间:
相对集中式和全局共享式JNDI tree而言,最少.
HttpSession出错恢复:
集中式state server和backup state server或数据库,内存复制.
单一点失败:
无
灵活的集群拓扑:
支持所有集群拓扑.
维护:
Bluestone在维护方面胜过其它server.Bluestone提供一个动态应用加载器 (dynamic application launcher DAL), 供LBB在应用程序或机器崩溃时调用. DAL能够在主机或备份机上重启应用程序.另外,Bluestone还提供一个配置和发布工具,叫Bluestone Application Manager (BAM), 用来 deploy application package和它们的相关文件.这个工具唯一的缺点是一次只能配置一台机器--对大型集群用起来就不方便了.
Sybase Enterprise Application Server 3.6
图4 Sybase Enterprise Application Server 3.6 拓扑
集群一般特性小结:
Enterprise Application Server实现的是集中式JNDI tree集群,用硬件负载平衡器来完成HTTP请求的负载均衡和出错恢复.一个集群中的两台name servers各自可以单独处理HTTP request,但是为性能考虑,最好还是专门处理 JNDI request.
Enterprise Application Server 3.6没有Web server plug-in,但到二月的 3.6.1 EBF (Error and Bug Fixes)版就会有了.它支持stateful, stateless session bean 和entity bean的方法间出错恢复.记住Enterprise Application Server病危提供任何监视代理或动态应用程序加载器,你需要为单一点失败或自动server重启购买第三方产品,如 Veritas Cluster Server.Enterprise Application Server不支持JMS.
集群集中时间:
集中时间取决于name server的数量和成员server的数量.在三种集群实现方式中,集中式JNDI tree集群的集中度是最差的. 尽管集中时间指标很重要,server可以在把对象bind到name server的同时就开始接收请求(当然,推荐最好不要这样做).
HttpSession出错恢复:
HttpSession出错恢复用集中式数据库实现,不支持内存复制.
单一点失败
如果运行多台name server，则没有单一点失败.
灵活的集群拓扑:
拓扑结构受限于没有Web server plug-in.
维护：
Sybase使用文件和配置同步,为application deployment提供了最好的选择.它可以在component, package, servlet,application,甚至Web application level上同步.你还可以选择同步整个集群,一组机器或单个主机. 很棒的功能!但是如果集群中的机器太多,同步就要持续相当长一段时间.它的一个弱点是没有动态应用程序加载服务, 这意味着你必须购买第三方产品,如Veritas Cluster Server.
SilverStream Application Server 3.7
图5. SilverStream Application Server
dispatcher 拓扑.
图6. SilverStream Application Server
WSI拓扑
集群一般特性小结:
当设置SilverStream集群时,有两种配置方案:基于dispatcher的和基于Web server集成模块 (Web server integration-module WSI)的.在基于dispatcher的集群中,用户连接dispatcher或基于硬件的dispatcher -- 例如Alteon 180e,然后dispatcher将HTTP重定向到及群众的一台机器上.从那个时刻起,用户与那台server就在物理上绑定了.故这种方式下,一个集群和一台server没有区别.主要的缺点在于:静态部分和动态部分不能独立地扩展.
在基于WSI的集群中,用户先连接dispatcher,后者控制web server的负载平衡和HTTP请求差错恢复. 每个 Web server有一个plug-in指向一个位于集群前端的负载平衡器.WSI集群不使用重定向,每个HTTP请求可以在任何一台机器上被平衡负载.副负载平衡器仅当application server层崩溃时用. A WSI结构优于dispatcher结构:能独立扩展静态和动态部分.但是,主要缺点是需要ArgoPersistenceManager作HttpSession出错恢复.在任何一种方式中,用户都不能得到方法间的差错恢复.EJB出错恢复完全成为程序员的责任.最后,SilverStream不支持集群化JMS.
HttpSession出错恢复:
SilverStream用集中式的数据库和ArgoPersistenceManager提供HTTPSession出错恢复.不幸的是,这个解决方案具有所有权问题.不使用常规的把session信息存入数据库的方法,而使用一个产品的 ArgoPersistenceManager class -- 一大缺憾.
集群集中时间:
相对集中式和全局共享式JNDI tree集群,最少.
单一点失败:
以上结构皆没有.
灵活的集群拓扑:
支持所有集群拓扑.
维护:
缓存管理器和动态class-loader为deploy和更新运行着的应用程序提供了方便的途径,基本不打扰当前活动的client. 当集群中的一台server上的应用更新时,更新的部分写入数据库,然后缓存管理器把所有机器上的缓存设为无效,强迫它们下次重新获取新的 application.只有一个缺点,就是要花时间把应用从数据库中取出,调入内存中.
BEA WebLogic Server 6.0
图7. BEA WebLogic Server 6.0
集群一般特性小结:
WebLogic Server实现的是全局共享式的JNDI tree集群.这种工作方式下，当一台server启动时，把自己的JNDI
tree写入全局共享的JNDI tree.然后server用这个全局的tree的备份来提供服务,使用户能感知集群中的所有对象.用户用的 stub能感知整个集群,意味着它们向原定的server请求,但同时拥有其它application server上复制品的信息. 正是由于这点, stub可以透明地进行差错恢复.WebLogic Server的一个独一无二的特性就是stateful session bean的内存复制和可配置的EJB remote objects自动出错恢复. WebLogic把clusterable定义为一个在集群中的服务.JMS就是这样一个服务,但是每个Topic or Queue仅在一台server上运行,所以不能负载均衡和出错恢复-- WebLogic JMS实现的一大缺点.
HttpSession出错恢复:
WebLogic Server通过向任意指定的backup server或database server复制内存中状态来实现 HttpSession出错恢复.集群中地每台机器挑选一台不同的机器.如果主server崩溃了,backup server变成主server,再重新挑选一台backup server. WebLogic有一个唯一的特性：cookie的独立性. HP Bluestone和 Enterprise Application Server都需要cookie 才能进行HttpSession出错恢复,但是WebLogic可以使用URL中加密的信息,把用户定向到backup server上.
单一点失败:
JMS和Administration server.
灵活的集群拓扑:
支持所有集群拓扑.
维护:
WebLogic的弱势在于维护.尽管BEA已经在配置同步方面采取了积极的措施,WebLogic Server还是没有任何监视代理,动态应用加载器,或文件同步服务.所以你需要为单一点失败或HA购买第三方方案.如果你采用了SAN,你就不必文件同步服务了,但大多数开发者才刚刚开始认识到 SAN的好处.
分析
总体来说BEA WebLogic Server 6.0最为强壮,集群实现得最彻底.HP Bluestone Total-e- Server 2.7.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 依次排列.
选择正确的application server需要权衡折衷.如果你的应用中有EJB clients (applet和 applications), Web clients, 对HttpSession大量使用(为了caching), 要求扩展简易和出错恢复,你需要 BEA WebLogic 6.0.如果你的application需要大量使用JMS,绝大多数client是Web client, Bluestone可能更好一些.从集群地角度说,Sybase Enterprise Application Server 3.7缺少重要的集群特性,例如JMS,HttpSession内存复制,Web server plug-in等. 但是, Sybase Enterprise Application Server 3.7的确带来了文件和配置同步服务.如果你使用SAN,这些有点就微不足道了.SilverStream Application Server的集群实现得最不彻底, 缺少集群化的 JMS,HttpSession内存复制和出错恢复等.
结论
在本文中你获得了集群的一般认识,集群的方法和重要的集群服务.我们审视了每个application server的优缺点,讨论了和集群有关的特性.有了这些知识以后,你就懂得如何建立高可靠性和伸缩性的集群.但这仅仅是学习的开始,到外面找一些 evaluation clustering license, 和application server,验证一下.
第二部分中,我们要开始写代码,验证application server供应商的承诺.我们还将用J2EE Java Pet Store例程做负载和集群集中度测试.
集群和出错恢复服务
在一台server上提供J2EE服务相比在整个集群中提供来说是微不足道的.鉴于集群技术的复杂性,每个application server 有自己独到的实现方式.你应该向供应商了解他们怎么实现集群和entity bean, stateless session bean, stateful session bean以及JMS的出错恢复.许多供应商宣称自己支持集群化组件,但他们对此的定义经常牵涉到集群中的组件.例如,BEA WebLogic Server 5.1支持集群化的stateful session bean,但如果server本身崩溃了,其上所有状态也丢失了.客户只得重新创建stateful session bean,使得原来的在集群中就不可用了. 直到BEA WebLogic 6.0发布,stateful session bean才实现内存复制来集群化和出错恢复.
所有application servers支持EJB clustering,但对可以配置的自动出错恢复的支持有很大的不同. 事实上.有些application servers并不支持EJB client的自动出错恢复.例如, Sybase Enterprise Application Server支持stateful session bean出错恢复, 前提是你从数据库或通过序列化load bean的状态.如前面所提到的,BEA WebLogic 6.0通过内存复制bean的状态来支持 stateful session bean的差错恢复.大多数application server可以在集群中运行JMS,但对个人命名的 Topics和Queues不提供负载均衡和出错恢复.这样,你可能就需要购买可集群的JMS产品,如SonicMQ,来获得Topics和Queues 的负载均衡.
另一个很重要的考虑因素,我们现在要提到的是:HttpSession出错恢复.
HttpSession出错恢复
当原先为用户创建session的服务器崩溃了,HttpSession出错恢复允许用户无缝地从另一台server上获得session信息. BEA WebLogic Server实现了session信息内存复制,而HP Bluestone Total-e-Server采用集中式 session server,它带有HA的备份. SilverStream Application Server和 Sybase Enterprise Application Server采用集中式数据库或文件系统,每个application servers都从中读写.
用数据库/文件系统实现的session持久性的主要缺点在于:当存储大的或很多对象在session中时有限的伸缩性.用户每次向 HttpSession增加一个对象,session中所有的对象都要序列化并写入数据库或共享的文件系统.大多数用数据库实现session持久化的 application server都主张尽量少用session存储object, 但这会限制Web application的结构和设计,特别是用HttpSession存储用户数据时.
基于内存的session持久性把内存中的session信息写到一个备份服务器上,有两种做法.第一种把HttpSession信息写到一个集中式状态服务器(centralized state server). 集群中的所有机器都把HttpSession objects写到这台 server上. 第二种方法,集群中每个节点任意地选择一个节点存储内存中的session信息.每个用户向HttpSession增加object, 该object被单独序列化在写入那台backup server.
上面两种方法中,如果集群中的机器数较少,用专门的state server比任意指定backup server要好,这样可以节省CPU来处理transaction和动态网页的生成.
另一方面,当集群的机器数很大时,专门的state server就成为瓶颈,而向任意指定的backup server复制内存的消耗将随着机器数的增长而线性增长.当增加机器时,用专门的state server,你需要为它加上更多的RAM和CPU.用任意指定的 backup server, 你仅仅增加机器而已,session会平均地分布在所有机器之间.基于内存的持久化提供了灵活的 Web application设计,规模和高可靠性.
现在我们将检查一下单一点失败.
单一点失败
未提供备份的集群服务会造成单一点失败,他们会造成整个集群或部分应用崩溃.例如,WebLogic JMS在集群中仅能有一个Topic运行在一台机器上.如果那台机器碰巧崩溃了,那应用中依赖JMS Topics的部分就不能工作,直到另一个WebLogic instance启动起来(注意只有durable message才能在新的server instance启动时被发送.)
检查一下你的集群是否存在单一点失败.如果有,你得估计一下这样是否能满足应用需求.
下面提及伸缩拓扑.
灵活的伸缩拓扑
集群还需要灵活的拓扑布局.大多数application server还可以充当HTTP server,见图1.
图1. 多合一拓扑
当你的website大多数是动态网页时,这种结构不错.然而,当大多数是静态页面时,要扩展网站的代价就非常昂贵了,因为你要增加 application server用于静态HTML页面请求.所以,适当的做法是:要扩展静态部分,增加Web server, 要扩展动态部分,增加application server,如图2.
图2. 分隔的拓扑
上图的结构主要的缺陷在于:增加了动态页面请求延迟.但是相比灵活的独立扩展而言,微不足道.
最后,对application server的讨论终止于维护性.
维护性
集群中大量机器总避免不了维护问题:维持集群运行,通知应用的改变.Application servers应该提供agent来感知主要服务的崩溃,然后重新启动它们.或者激活backup server. 更进一步,application server应该提供一个简便的方法来更新和同步集群中所有的server.
Sybase Enterprise Application Server和HP Bluestone Total-e-Server提供文件和配置同步服务. Sybase Enterprise Application Server在主机, 组和集群level上提供这些服务. Bluestone则仅提供主机level的. 如果要deploy大的application或很多application, 就要花很长的时间. BEA WebLogic Server 仅提供配置同步. 这两者中,配置同步加上storage area network更能较好地工作,因为可以把变化写入一个逻辑存储介质, 这样所有的机器就能接收到application file的变化. 每台机器只需要从一台集中式 configuration server上接收配置变化就可以了. SilverStream Application server用 dynamic class loader从数据库中载入application files和 configuration. dynamic class loader使得运行中的application server接收变化更方便.
我们已经讨论了application server需要考虑的重要特征.下面就根据我们的准则比较一下4个流行的application server.
Application Server比较
既然我们学习了关于集群的一般知识,让我们把注意力集中在各个application server上,把所学的和现实世界联系起来.我们要比较的是:
HP Bluestone Total-e-Server 7.2.1
Sybase Enterprise Application Server 3.6
SilverStream Application Server 3.7
BEA WebLogic Server 6.0
每个application server的讨论都包含一张HA结构图,接着是它的重要特征的小结.
HP Bluestone Total-e-Server 7.2.1
图3. HP Bluestone 7.2.1拓扑
集群一般特性小结:
Bluestone实现的是独立的JNDI tree集群.作为plug-in运行在Web server中的LBB,提供HTTP请求的负载平衡和出错恢复服务.LBB知道哪台UBS(universal business server)上运行着什么application,可以正确地定向流量.通过EJB Proxy Service和Proxy LBB支持对stateful,stateless session bean和 entity bean的方法间出错恢复. EJB Proxy Service的主要缺点在于增加了每个EJB请求的延迟,而且它同UBS运行在同一机器上.EJB Proxy Service和UBS stub支持UBS崩溃的情况下的出错恢复,但是不支持硬件崩溃的出错恢复.后者出现的情况下,出错恢复是通过客户端配置apserver.txt或Proxy LBB对apserver.txt配置.客户端的apserver.txt里面列出了集群中所有的组件.当有新的组件加入时,所有客户需要用BAM (Bluestone Application Manager)更新该文件或手工逐个主机地更新.在Proxy LBB处配置apserver.txt将用户和集群中的变化隔离,但为EJB请求引入了新的延迟.HP Bluestone是唯一的一个提供集群化和负载均衡JMS的application server.
集群集中时间:
相对集中式和全局共享式JNDI tree而言,最少.
HttpSession出错恢复:
集中式state server和backup state server或数据库,内存复制.
单一点失败:
无
灵活的集群拓扑:
支持所有集群拓扑.
维护:
Bluestone在维护方面胜过其它server.Bluestone提供一个动态应用加载器 (dynamic application launcher DAL), 供LBB在应用程序或机器崩溃时调用. DAL能够在主机或备份机上重启应用程序.另外,Bluestone还提供一个配置和发布工具,叫Bluestone Application Manager (BAM), 用来 deploy application package和它们的相关文件.这个工具唯一的缺点是一次只能配置一台机器--对大型集群用起来就不方便了.
Sybase Enterprise Application Server 3.6
图4 Sybase Enterprise Application Server 3.6 拓扑
集群一般特性小结:
Enterprise Application Server实现的是集中式JNDI tree集群,用硬件负载平衡器来完成HTTP请求的负载均衡和出错恢复.一个集群中的两台name servers各自可以单独处理HTTP request,但是为性能考虑,最好还是专门处理 JNDI request.
Enterprise Application Server 3.6没有Web server plug-in,但到二月的 3.6.1 EBF (Error and Bug Fixes)版就会有了.它支持stateful, stateless session bean 和entity bean的方法间出错恢复.记住Enterprise Application Server病危提供任何监视代理或动态应用程序加载器,你需要为单一点失败或自动server重启购买第三方产品,如 Veritas Cluster Server.Enterprise Application Server不支持JMS.
集群集中时间:
集中时间取决于name server的数量和成员server的数量.在三种集群实现方式中,集中式JNDI tree集群的集中度是最差的. 尽管集中时间指标很重要,server可以在把对象bind到name server的同时就开始接收请求(当然,推荐最好不要这样做).
HttpSession出错恢复:
HttpSession出错恢复用集中式数据库实现,不支持内存复制.
单一点失败
如果运行多台name server，则没有单一点失败.
灵活的集群拓扑:
拓扑结构受限于没有Web server plug-in.
维护：
Sybase使用文件和配置同步,为application deployment提供了最好的选择.它可以在component, package, servlet,application,甚至Web application level上同步.你还可以选择同步整个集群,一组机器或单个主机. 很棒的功能!但是如果集群中的机器太多,同步就要持续相当长一段时间.它的一个弱点是没有动态应用程序加载服务, 这意味着你必须购买第三方产品,如Veritas Cluster Server.
SilverStream Application Server 3.7
图5. SilverStream Application Server
dispatcher 拓扑.
图6. SilverStream Application Server
WSI拓扑
集群一般特性小结:
当设置SilverStream集群时,有两种配置方案:基于dispatcher的和基于Web server集成模块 (Web server integration-module WSI)的.在基于dispatcher的集群中,用户连接dispatcher或基于硬件的dispatcher -- 例如Alteon 180e,然后dispatcher将HTTP重定向到及群众的一台机器上.从那个时刻起,用户与那台server就在物理上绑定了.故这种方式下,一个集群和一台server没有区别.主要的缺点在于:静态部分和动态部分不能独立地扩展.
在基于WSI的集群中,用户先连接dispatcher,后者控制web server的负载平衡和HTTP请求差错恢复. 每个 Web server有一个plug-in指向一个位于集群前端的负载平衡器.WSI集群不使用重定向,每个HTTP请求可以在任何一台机器上被平衡负载.副负载平衡器仅当application server层崩溃时用. A WSI结构优于dispatcher结构:能独立扩展静态和动态部分.但是,主要缺点是需要ArgoPersistenceManager作HttpSession出错恢复.在任何一种方式中,用户都不能得到方法间的差错恢复.EJB出错恢复完全成为程序员的责任.最后,SilverStream不支持集群化JMS.
HttpSession出错恢复:
SilverStream用集中式的数据库和ArgoPersistenceManager提供HTTPSession出错恢复.不幸的是,这个解决方案具有所有权问题.不使用常规的把session信息存入数据库的方法,而使用一个产品的 ArgoPersistenceManager class -- 一大缺憾.
集群集中时间:
相对集中式和全局共享式JNDI tree集群,最少.
单一点失败:
以上结构皆没有.
灵活的集群拓扑:
支持所有集群拓扑.
维护:
缓存管理器和动态class-loader为deploy和更新运行着的应用程序提供了方便的途径,基本不打扰当前活动的client. 当集群中的一台server上的应用更新时,更新的部分写入数据库,然后缓存管理器把所有机器上的缓存设为无效,强迫它们下次重新获取新的 application.只有一个缺点,就是要花时间把应用从数据库中取出,调入内存中.
BEA WebLogic Server 6.0
图7. BEA WebLogic Server 6.0
集群一般特性小结:
WebLogic Server实现的是全局共享式的JNDI tree集群.这种工作方式下，当一台server启动时，把自己的JNDI
tree写入全局共享的JNDI tree.然后server用这个全局的tree的备份来提供服务,使用户能感知集群中的所有对象.用户用的 stub能感知整个集群,意味着它们向原定的server请求,但同时拥有其它application server上复制品的信息. 正是由于这点, stub可以透明地进行差错恢复.WebLogic Server的一个独一无二的特性就是stateful session bean的内存复制和可配置的EJB remote objects自动出错恢复. WebLogic把clusterable定义为一个在集群中的服务.JMS就是这样一个服务,但是每个Topic or Queue仅在一台server上运行,所以不能负载均衡和出错恢复-- WebLogic JMS实现的一大缺点.
HttpSession出错恢复:
WebLogic Server通过向任意指定的backup server或database server复制内存中状态来实现 HttpSession出错恢复.集群中地每台机器挑选一台不同的机器.如果主server崩溃了,backup server变成主server,再重新挑选一台backup server. WebLogic有一个唯一的特性：cookie的独立性. HP Bluestone和 Enterprise Application Server都需要cookie 才能进行HttpSession出错恢复,但是WebLogic可以使用URL中加密的信息,把用户定向到backup server上.
单一点失败:
JMS和Administration server.
灵活的集群拓扑:
支持所有集群拓扑.
维护:
WebLogic的弱势在于维护.尽管BEA已经在配置同步方面采取了积极的措施,WebLogic Server还是没有任何监视代理,动态应用加载器,或文件同步服务.所以你需要为单一点失败或HA购买第三方方案.如果你采用了SAN,你就不必文件同步服务了,但大多数开发者才刚刚开始认识到 SAN的好处.
分析
总体来说BEA WebLogic Server 6.0最为强壮,集群实现得最彻底.HP Bluestone Total-e- Server 2.7.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 依次排列.
选择正确的application server需要权衡折衷.如果你的应用中有EJB clients (applet和 applications), Web clients, 对HttpSession大量使用(为了caching), 要求扩展简易和出错恢复,你需要 BEA WebLogic 6.0.如果你的application需要大量使用JMS,绝大多数client是Web client, Bluestone可能更好一些.从集群地角度说,Sybase Enterprise Application Server 3.7缺少重要的集群特性,例如JMS,HttpSession内存复制,Web server plug-in等. 但是, Sybase Enterprise Application Server 3.7的确带来了文件和配置同步服务.如果你使用SAN,这些有点就微不足道了.SilverStream Application Server的集群实现得最不彻底, 缺少集群化的 JMS,HttpSession内存复制和出错恢复等.
结论
在本文中你获得了集群的一般认识,集群的方法和重要的集群服务.我们审视了每个application server的优缺点,讨论了和集群有关的特性.有了这些知识以后,你就懂得如何建立高可靠性和伸缩性的集群.但这仅仅是学习的开始,到外面找一些 evaluation clustering license, 和application server,验证一下.
第二部分中,我们要开始写代码,验证application server供应商的承诺.我们还将用J2EE Java Pet Store例程做负载和集群集中度测试.