j2eeJ2EE clustering 1
概述
如果想要建立一个可伸缩的高可靠性的网站,就需要了解集群技术(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产品是怎样伸缩规模和进行差错恢复的.

集群的定义
<div>J2EE application server的供应商把集群定义为一组计算机一起工作，提供透明的企业级服务(支持 JNDI, EJB, JSP, HttpSession,组件差错恢复等).他们故意定义得很模糊,因为他们对它的实现各不相同.一部分开发商在一组互相独立的机器前端放置一个dispatcher,dispatcher接受用户的请求,然后用HTTP redirect header将请求转到集群中一台特定的server上.另一部分开发商则实现了一个紧密集成在一起的机器联合,每台机器能完全感知它周围其它机器的存在,连同驻在它们之上的对象.

除了机器方面的集成,集群还包含冗余和出错恢复:

负载平衡器:进入集群的单一的入口点,站点或application server的流量指示器
网关路由器:内部网络的出口点
多层交换器:包过滤或帧过滤,确保每台机器仅收到和自己相关的信息
防火墙:端口级别过滤,防止hacker进入集群或内部网络
SAN (Storage Area Networking)控制器:把application servers, Web servers和databases连接到后端存储介质,管理数据该写到哪个硬盘;以及出错备份
数据库
无论怎样实现,集群都提供两大主要功能:可伸缩性和高可靠性(HA).

可伸缩性
可伸缩性是指一个应用程序能支持不断增长的用户数量的能力.集群通过增加server来提供额外的工作能力,从而保证了可伸缩性.
高可靠性
HA可用一个词概括:冗余(redundancy).一个集群用很多机器服务请求, 因此,即使一台机器崩溃了,其它机器也可透明地接过任务.
集群仅在application server层提供高可靠性. 对一个网络系统来说,要表现真正的HA,必须像诺亚方舟(Noah's ark)一样每种东西提供两件,包括Web servers,网关路由器,交换结构等.

集群种类
J2EE集群通常采取两种方法: 不共享集群(shared-nothing cluster),和共享存储集群.在不共享集群中,每个 application server有自己的文件系统和在集群中运行的应用的copy.应用程序的升级需要更新集群中的每个节点.这种设置对大的集群而言,维护就像一场噩梦,尤其是当代码需要更新时.
相反,共享存储集群公用一个存储设备,每个application servers从那里获得运行的application.更新只在一个文件系统中进行,所有机器能访问到这些变化.直到现在,单点失败(single-point of failure)仍是它的弱点.然而,SAN提供一个到冗余存储介质的单一的逻辑接口,以便进行出错恢复, 出错回退和可伸缩性.(欲详细了解SAN, 参见Storage Infrastructure.)

比较J2EE application server的集群技术实现,最重要的是考虑一下因素:

集群的实现
集群和组件的出错恢复
HttpSession的出错恢复
集群拓扑的单点失败
可变的拓扑结构
维护
以后我们将在不同的方面比较四个流行的application server的集群技术,但首先,我们先仔细探讨一下各要素.

集群的实现
J2EE application server在实现JNDI(Java Naming and Directory Interface)的基础上实现集群.尽管JNDI是J2EE应用程序依赖的核心,在集群中却很难实现,因为不能把多个对象bind到一个JNDI名字上.依据不同 application server JNDI的实现,有三种集群的方法:
独立的(Independent)
集中的(Centralized)
全局共享(Shared global)
独立的JNDI tree
HP Bluestone Total-e-Server和SilverStream Application Server在每个 application server中使用独立的JNDI tree.JNDI tree的server成员并不知道和关心集群中其它server的存在.因此,差错恢复要么不支持,要么通过一个重定向HTTP或EJB request的中间服务支持.这些中间服务经过配置可知道每个组件在集群中的位置,并知道万一出现错误哪里有替代品.
独立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实例.这样引入了额外的延迟,但是自动执行了出错恢复.

集中式JNDI tree
Sybase Enterprise Application Server实现的就是集中的JNDI tree集群.集中的JNDI tree 集群对JNDI采用CORBA的CosNaming服务.Name server中驻有集中式JNDI tree,跟踪哪个server启动了.每个 server在启动时,把object bind到自己的JNDI tree中,同时也bind到所有的name server中的 JNDI tree.
这种模式下获得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集群的集中度在所有实现中是最差的.

全局共享式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的第二大考虑因素:集群和出错恢复服务.