J2EE clustering 1 (转)[@more@]w3c//DTD HTML 4.0 Transitional//EN">
概述
如果想要建立一个可伸缩的高可靠性的网站,就需要了解集群技术(clustering).本文中,Abraham Kang介绍了J2EE集群,怎样实现集群, 并列出Bluestone Total-e-server, Sybase Enterprise Application Server, SilverStream Application Server 和webLOGIC Application Server在集群技术上有什么区别.基于这些知识,你就能够设计自己有效且高效的J2EE applications.
Abraham Kang
企业越来越多地选择Java 2, Enterprise Edition (J2EE)来开发它们基于任务的网上应用.在J2EE framework中, 集群技术能保证最少的downtime,最大的伸缩性.一个集群就是一组application servers透明地运行J2EE应用服务,就好像它们是一个整体. 在集群中必须提供额外的机器.若要将服务是健降至最短,其中的每个组件都必须是冗余的.
在本文中,我们将获得关于集群的基本知识和集群的方法,以及重要的集群服务.由于业内集群技术差别很大,我们将比较每种技术的优劣.更进一步的,我们将讨论与集群有关的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 各是怎样实现集群的.
本文的第二部分中,我们的讨论将涉及集群的编程和差错恢复策略,并测试我们所提到的4种application server产品是怎样伸缩规模和进行差错恢复的.
除了机器方面的集成,集群还包含冗余和出错恢复:
无论怎样实现,集群都提供两大主要功能:可伸缩性和高可靠性(HA).
集群仅在application server层提供高可靠性. 对一个网络系统来说,要表现真正的HA,必须像诺亚方舟(Noah's ark)一样每种东西提供两件,包括Web servers,网关路由器,交换结构等.
相反,共享存储集群公用一个存储设备,每个application servers从那里获得运行的application.更新只在一个文件系统中进行,所有机器能访问到这些变化.直到现在,单点失败(single-point of failure)仍是它的弱点.然而,SAN提供一个到冗余存储介质的单一的逻辑接口,以便进行出错恢复, 出错回退和可伸缩性.(欲详细了解SAN, 参见Storage Infrastructure.)
比较J2EE application server的集群技术实现,最重要的是考虑一下因素:
以后我们将在不同的方面比较四个流行的application server的集群技术,但首先,我们先仔细探讨一下各要素.
独立JNDI tree集群的一个优点是: 集群集中度(convergence)更短,伸缩简便.集群集中度衡量的是集群完全感知所有成员和其上的对象的时间指标.然而,集中度在独立JNDI tree集群并不是问题,一旦两台机器启动起来,集群就能获知集中度. 另一个优点是: 可伸缩性只要额外的机器参与就行.
但是,也存在着缺点.首先,出错恢复通常是开发者的责任.故,由于每种application server的JNDI tree是独立的,通过JNDI查询得到的remote Proxy被绑定到查询发生时的那台server上,这样,如果EJB的这次调用失败了,开发者需要写额外的代码连接dispatcher,获取另一台有效的server的地址,再进行一次JNDI查询,重新调用刚才失败的方法.Bluestone实现了一种更为复杂的形式,每个请求都通过一个EJB proxy服务,称作Proxy LBB (Load Balance Broker).EJB proxy服务保证每个请求都发往活动的UBS实例.这样引入了额外的延迟,但是自动执行了出错恢复.
这种模式下获得EJB的引用分两个步骤.首先,用户从name server查询home object, 前者返回一个可互作用的对象引用(interoperable object reference IOR). IOR指向几个活动的含有该home object的server. 然后,用户用第一个server获得home和remote.如果EJB方法调用中出现错误,CORBA stub负责实现获得另一台机器(列于IOR中)上的逻辑.
name server本身是这种方式下的一个弱点.举例来说,如果一个集群中有50台机器,其中5台为name server. 如果每个name server都不可用的话,集群就没用了.实际上,另45台机器都是好的,但整个集群将不处理任何EJB 请求.
当集群中所有的name server都崩溃了,就需要另一台机器马上扮演name server的角色,由此产生了另一个问题.这种情况下,新的name server要求集群中所有活动的机器把自己的对象bind到其上的JNDI tree.尽管bind 过程中接受请求未尝不可,但建议不要这样.binding过程延长了集群的恢复时间.而且,每个JNDI查询实际上代表两个网络调用,一个从name server获取IOR,而第二个从IOR指定的server获取object.
最后,当集中式JNDI tree集群扩大规模时,它的集中度时间也越来越长.扩大规模时,必须增加越来越多的name server. 记住name server和整个集群机器的一般可接受比例是1:10, 且至少有两台name server.因此,如果你的集群有10台机器,两台为name server,总共就有20个bind. 40台机器的集群,有4台name server, 就有160个bind. 每个bind代表一台成员server把它上面所有对象bind到name server的JNDI tree上的一个过程.这样,集中式JNDI tree集群的集中度在所有实现中是最差的.
最后, BEA WebLogic实现的是全局共享式JNDI tree. 这种方式下,当集群中的一台机器启动时,它通过IP组播宣布它的存在和它的JNDI tree.每台server把对象bind到自己本地的JNDI tree的同时,还bind到一个共享的全局JNDI tree.
把JNDI tree分为全局的和本地的,生成的home和remote stub就能出错恢复,并提供快捷的过程中(in-process)JNDI查询.全局JNDI tree在每个成员中共享,每个成员都能知道集群中每个对象的确切地址.如果哪个对象在两台以上的机器上,一个特殊的home object被bind到全局JNDI tree上.这个home知道它关联的所有 EJB object的位置,生成的remote object也同样知道所有的位置.
全局共享的主要缺陷在于:网络流量在server启动初始化时非常大,集群集中度也很大.相反,在独立的JNDI tree集群中,这并不是问题,因为没有JNDI信息共享.而全局共享式或集中式集群在简历共享或集中式JNDI tree时要花费时间.实际上,由于全局共享集群采用组播传递JNDI信息,建立全局JNDI tree的时间是随server线性增长的.
全局共享式较集中式JNDI tree而言,主要的优势在于:集群实现主要致力于伸缩的易实现性和更高的可靠性. 通过全局共享,你不必改动name server的cpu和RAM,或者调节集群中的name server数量.想扩展应用规模,增加server就行.而且,如果哪台崩溃了,集群仍能很好地工作.最后,每个远程查询只要一个网络调用就完成了,相比集中式的两个而言就省多了.
由于JSP,servlet,EJB和JavaBean最好能同时驻扎在一台application server上, 它们总是使用进程中JNDI查询.记住如果你仅仅运行服务器端的应用,三种方式没什么区别. 事实上,每个HTTP请求在application server中做进程中JNDI查询,返回应用中调用的对象.
接着,我们将注意力集中到J2EE application server的第二大考虑因素:集群和出错恢复服务.
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
