当前页面: 开发资料首页 → J2EE 专题 → J2EE clustering part 1
J2EE clustering part 1
摘要:
群集还需要一个可伸缩拓扑的柔性布局.大多数应用服务器能承担一个即是HTTP服务器又是一个应用服务器的责任.如图1所示.
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale1.gif[/IMG]
Figure 1. All-in-one topology
如果你的网站为动态内容服务,图1所示的架构是不错的.然而,如果你的站点部分为静态内容服务,那么伸缩站点可能是一个昂贵的建议,因为你宁愿增加更多个应用服务器来为静态的HTML页面请求服务.记住,靠增加Web服务器来伸缩你的网站静态部分;靠增加应用服务器伸缩你的站点的动态部分,如图2所示.
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale2.gif[/IMG]
Figure 2. Partitioned topology
图2里所示架构的主要缺点:动态页面处理增加了反应时间.然而,为了站点独立的伸缩静态和动态部分,它提供了一套柔性的方法.
最后,不注意维护性的应用服务器论述完成什么了??
维护性
对于在集群里的大量机器,维护性考虑保持集群运行和突出应用变更的范围.应用服务器应该提供代理来觉察关键性的服务在什么时候失败,然后在备份服务器上重新开始或者激活他们.更进一步地,当变更或者更新出现时,应用服务器应该提供一种容易的方法更新和同步集群里的所有服务器.
Sybase Enterprise Application Server和HP Bluestone Total-e-Server为集群提供file和configuration同步服务. Sybase Enterprise Application Server在主机,分组或者集群的层次上提供file和configuration同步服务.Bluestone只在主机层次上提供file和configuration同步服务.如果大的应用有许多的变更需要部署,这个过程将花费很长的时间, BEA WebLogic Server只提供configuration同步.对比这两个, 带有一个存储区域网络的configuration同步工作的更好,因为变更可以被放到单独的一个逻辑存储体里,集群里的所有机器将收到应用程序文件的变更,接着每台机器必须从一个中央集中的配置服务器收到结构配置变更. SilverStream 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
就象在这篇文章出现的那样,每个应用服务器项都提供了一个HA架构的图片,紧接着就是重要特点的一个概要.
HP Bluestone Total-e-Server 7.2.1
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale3.gif[/IMG]
Figure 3. HP Bluestone 7.2.1 topology
集群概要:
Bluestone实现了独立JNDI树的群集.在一个在Web server里做为插件运行的LBB,提供了Http请求的负载均衡和失败转移.LBBs知道哪个应用正运行在哪个UBS(universal business server)实例上,并且能适当的传输. 通过EJB代理服务和代理LBB在方法调用之间支持stateful和stateless session和entity beans的失败转移.EJB代理服务的主要缺点是对每个EJB请求增加了反应时间,并且它和UBS实例运行在相同的机器上.万一UBS实例失败,EJB代理服务和UBS stubs允许失败转移,但是万一硬件失败,不允许失败转移.通过apserver.txt客户端的配置或者apserver.txt的代理LBB配置支持硬件失败转移. 客户端apserver.txt列出了集群里所有的组件. 通过BAM (Bluestone Application Manager)或者手工主机互连 (host-by-host basis), 当增加额外的组件到集群里时,需要更新所有的客户端 .在代理LBB上配制apserver.txt隔离客户端和集群的变更.但是对于每个EJB调用又增加了额外的反应时间. HP Bluestone是唯一提供群集和负载均衡JMS的应用服务器.
集群收敛时间（Convergence time）:
同中央集中和全局共享JNDI树的集群对比. Least
HttpSession失败转移
在内存里中央集中的状态服务器和备份状态服务器或者数据库.
单点失败
None
柔性集群拓扑
支持所有的群集拓扑.
维护性
Bluestone在维护性方面胜于其他的应用服务器. Bluestone提供了一个动态应用分发器(DAL),当一个应用或者机器down掉时,LBB调用它.另外, Bluestone提供了一个称做Bluestone Application Manager (BAM)的配置和部署工具.BAM可以部署应用包和它们相关联的配置文件,这个工具的不利条件就是你一次只能配置一个主机---这对大的集群来说会有问题.
Sybase Enterprise Application Server 3.6
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale4.gif[/IMG]
Figure 4.Sybase Enterprise Application Server 3.6 topology
集群概要:
Enterprise Application Server实现了中央集中JNDI树的群集,硬件负载均衡器提供了HTTP请求的负载均衡和失败转移.每个集群的两个命名服务器可以处理HTTP请求,但是对于性能考虑,他们的一个特色就是独自专门处理JNDI请求.
Enterprise Application Server3.6不具备Web服务器插件; 可是,他们将和2月份3.6.1版本的EBF(Error and Bug Fixes) 一起可用.这个应用在方法调用之间支持stateful和stateless session和entity bean失败转移.紧记Enterprise Application Server不提供任何监控代理或者动态应用分发器,要求你买第三方的解决方案象防止单点失败或者服务器自动重启的Veritas集群服务器. Enterprise Application Server不支持JMS.
集群收敛时间（Convergence time）:
收敛时间依靠命名服务器和集群里成员服务器的数量.三种集群实现中,中央集中JNDI树的集群产生最差的收敛时间（Convergence time）.虽然收敛时间（Convergence time）是重要的,但是成员机器在绑定对象到被EJB客户端使用的命名服务器之后,可以开始收到请求.(不推荐)
HttpSession失败转移
HttpSession失败转移随着一个中央集中的数据库出现.没有内存复制的选项.
单点失败
如果运行多个命名服务器,不存在单点失败.
柔性集群拓扑
由于Web服务器插件的缺点,柔性集群拓扑是受限制的
维护性
Sybase通过一个文件和配置同步为应用部署提供了最好的选项.可以在组件,包,servlet,application,或者Web应用层次同步集群.你也可以选择同步一个集群,机器组,或者单个主机---一个可怕的特点如果在集群里有许多机器除了它会花费一段时间外还有许多文件要增加和更新.一个弱点是缺乏动态应用发送服务,意思是你必须购买第三方解决方案例如Veritas集群服务器.
SilverStream Application Server 3.7
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale5.gif[/IMG]
Figure 5. SilverStream Application Server dispatcher topology
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale5.gif[/IMG]
Figure 6. SilverStream Application Server Web server
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale6.gif[/IMG]
integration module topology.
集群概要:
当设立SilverStream集群时,要挑选两个配置:基于分发器或者基于Web服务器整合模块(WSI).在基于分发器的集群里,用户连接到分发器或者基于硬件的分发器---例如,Alteon 180e.然后分发器发送一个HTTP重定向把客户端和集群里的机器连在一起. 就象指出的那样,客户端被物理绑定到单一的服务器.在分发器配置里,单机和集群之见没有什么差异,因为涉及到客户端,集群成为了一个单机.主要缺点:你不能伸缩与站点动态部分相独立的静态部分.
在基于WSI的集群里,用户连接到分发器,分发器把HTTP请求负载均衡和失败转移到Web服务器.每个Web服务器都有个指向SilverStream集群前一个负载均衡器的插件.WSI集群不使用重定向,所以每个HTTP请求都被负载均衡通过任何Web服务器.第二个负载均衡器确保在应用服务器层次上的失败转移.建立在分发器架构上的WSI架构的一个优点:具有独立伸缩站点静态和动态部分的能力.主要的不利方面, ArgoPersistenceManager是HttpSession失败转移所必需的.在任一个架构里,EJB客户端仍然不能在方法调用之间失败转移.EJB失败转移完全是开发者的责任.最后, SilverStream不支持群集的JMS.
HttpSession失败转移
SilverStream依靠中央集中的数据库和ArgoPersistenceManager提供HttpSession失败转移. 不幸的,这种解决方案是有所有权的.为了代替使用标准HttpSession存储session信息到数据库,你必须使用这个产品的ArgoPersistenceManager类---这是一个缺点.
集群收敛时间（Convergence time）:
同中央集中和全局共享JNDI树的集群相比. Least.
单点失败:
在上面的架构里不存在.
柔性集群拓扑
支持所有的群集拓扑.
维护性:
缓存管理器和动态类装载器提供一种容易的方式---使用无中断激活客户端来部署和更新运行的应用.当更新集群里的一个服务器上的应用时,更新写到数据库同时缓存管理器使所有其他机器上的缓存无效,强制他们下次访问重新取得应用的更新部分.这种方式唯一的不利方面是初始化访问期间,数据库外装载应用和进入到活动内存所需要的时间.
BEA WebLogic Server 6.0
IMG http://www.devworld.com/microsites/javaworld/legacy/jw-02-2001/images/jw-0223-extremescale7.gif[/IMG]
Figure 7. BEA WebLogic Server 6.0 topology.
集群概要:
WebLogic Server通过全局共享JNDI集群树实现群集.通过设置,当单个服务器启动时,它把JNDI树放到全局共享JNDI树.然后服务器使用树的拷贝为请求服务,允许单个服务器知道集群里所有对象的精确位置.客户端使用的Stubs是有意识集群,意思就是说在他们的原始服务器上优化他们,但是也了解运行在不同应用服务器里的所有其他复制品对象的情况.因为可群集的stubs了解集群里所有复制品,它们在集群里可以明显的失败转移到其他的复制品对象. WebLogic Server的一个特点是stateful session beans和EJB remotes对象可配置的自动失败转移都是内存复制.Weblogic定义clusterable作为能运行在集群里的一个服务.JMS是clusterable但是每个Topic或者Queue都只运行在集群里单独服务器上.你不能在集群里负载均衡或者失败转移JMS Topics或者Queues---这是Weblogic的JMS实现的一个主要弱点.
HttpSession失败转移
WebLogic Server依靠明显的内存状态复制到一个任意的备份服务器或者数据库服务器,来提供HttpSession失败转移.集群里的每台机器都挑选一台不同的备份机器.如果首要的服务器失败,备份成为首要的机器,同时这个首要的机器挑选新的备份服务器.Weblogic的一个特点是独立的cookie. HP Bluestone和Enterprise Application Server两者为了HttpSession失败转移都需要cookies.如果发生失败,Weblogic能使用加密信息在URL里直接把客户端定位到备份服务器.
单点失败:
JMS和Administration server.
柔性集群拓扑
支持所有的群集拓扑.
维护性:
WebLogic的弱点是维护性.虽然BEA已经关于配置同步采取了积极的措施.Weblogic服务器不提供监控代理,动态应用分发器,或者文件同步服务.这些不足需要你买第三方关于解决单点失败或者实现潜在HA的解决方案,所有的Weblogic管理员必须穿上Nike Air Streak Vapor IV racing shoes.如果一台服务器down掉了,他们必须跑到机器前检修出现的问题.然而,如果你使用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通常是下一个选择.
挑选合适的应用服务器需要权衡.如果你正在写一个应用,在这个应用里你将有EJB clients(applets和applications), Web clients, HttpSession (for caching)的扩展使用,容易伸缩和失败转移.你将会采用BEA WebLogic 6.0.如果你的应用需要大量使用JMS并且你的客户端多数是Web客户端, Bluestone可能会是一个更好的选择.从群集的观点来说, Sybase Enterprise Application Server 3.7缺乏重要的群集特点,例如JMS,内存HttpSession复制,基于session的服务器亲合力(server affinity),和通过Web服务器插件的分割.然而, Sybase Enterprise Application Server 3.7 带来了table file和结构配置同步服务.但是如果你使用SAN,好处是最小化的. SilverStream Application Server有最弱的群集实现,缺乏群集的JMS,没有内存HttpSession复制和失败转移.
结论
在这篇文章里你已经对群集,群集方法和重要集群服务有了基本理解.我们已经研究了每种应用服务器的好处和缺点,同时讨论了在一个应用服务器里寻找与集群相关的重要的特点.说完这些知识,现在你理解如何设置高可用性和伸缩性的集群.可是,这些描述只是你旅途的开始,出去获得一些群集licenses的评估, Control-C一些应用服务器.
在Part2里我们将开始写代码,测试应用服务器提供商所声称的情况,并且对于每个不同的应用服务器都提供了失败转移和集群策略.对于负载测试和集群收敛基准,我们将更进一步的使用J2EE的java PetStore.
关于作者
Abraham Kang是Infogain's Delivery Operations Group的伸缩性和高可用性架构师.他有一年半的J2EE应用服务器群集经验. 此外,他还是Sun认证的程序员和开发者, Oracle 8i专业认证DBA,CCNA,和CCDA. Abraham想要感谢他的经理, Jessie Spencer-Cooke, 给他提供一个极好的环境,并且支持他努力写完这篇文章.
-------------------------------------------------------------------------------
HA材料清单
网络基础设施
在一个HA的内网,你应该具备下面所有的内容:
· 有冗余和失败转移能力的防火墙
· 运行在热备份路由协议(HSRP)上的冗余网关路由器
· 冗余连接到不同的ISPs, 运行边界网关协议(BGP)的这些ISPs拥有不同Internet链路中心(例如AT&T和Sprint)
· 冗余SAN 交换基础设施
· 有冗余和失败转移能力的的负载均衡器/分发器
· 运行生成树协议(STP)代替共享媒介网络的冗余交换网络.
· 在双重循环磁盘数组里冗余SAN双重交换连接到使用XOR Logic (RAID5)的dual ported磁盘驱动.
数据库基础设施
在一个HA的数据库环境下,你应该有个热备份数据库.
存储基础设施
存储区域网络(SANs)表示近年来显现出来的高速连接服务器和存储器(磁盘)的一种网络技术. SANs使用大容量存储基础设施连接LAN网络模型来提供失败转移,失败返回和伸缩性.把SAN看做是逻辑驱动的客户端,通过SAN交换器读写数据到网络. SAN交换器具有管理实际数据要写到哪个存储媒介的作用.对于失败转移,HA SAN被连接到镜象磁盘数组.如果一个磁盘数组down掉了,备份立刻接管而不影响客户端. SANs依靠发送一个置换磁盘控制器提供失败返回,合并新磁盘控制器进入到SAN,所以它能出来I/O.另外, SANs允许你在SAN上靠增加数据的多个复制显式伸缩你的存储器需要,消除一些瓶颈.
bill-转自:csdn
↑返回目录
前一篇: Enterprise JavaBeans Distilled
后一篇: J2EE clustering part 1