[转帖]weblogic群集

weblogic从5.1的版本起就支持集群技术.从网上down的版本是没有集群支持的。license key中有控制。 [@more@] weblogic从5.1的版本起就支持集群技术.从网上down的版本是没有集群支持的。license key中有控制。

关于wls 的集群原理,附上一个哥们写的东西,供大家参考。
(是写在wls5.1应用的时候,2000年,不过原理是一样的。)

CLUSTER概要
一、 Cluster的概念及优势

Weblogic支持集群技术,即让一组Server指向同一域名一起工作从而提供一个更强大、更可****的应用平台。对于客户端而言,无论Cluster中有几个Server在工作,看上去都是一个。集群技术有两个最明显的特色:

(1)可伸缩性:Cluster对加入其中的Server在性能上没有限制,为了提高性能,当客户端的请求大幅增加时,可以动态地向Cluster中添加Server。并且,配置Cluster当一台机器的资源没有被完全利用时,可以在同一机器上启动多个Server,但要求每一个Server使用不同的IP,而不能用同一IP的不同端口。

(2)高可用性:由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中,因此相同的请求可以有多个Server提供,并且Server间还可以复制状态信息。这样,当其中某一Server宕机或无法响应请求时,其它的Server会立即接管它的任务,从而把应用和客户端完全隔离开来。

二、Cluster的工作机制
每一个Clustered service,在每一个server上都会有一个instance,即一个replica,这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信,当客户端请求该service时,实际上是向stub发出请求,stub根据不同的算法调用集合中某一replica,如果调用失败,stub会检测到错误并重新调用其它的replica。Cluster支持多种算法:随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。
Weblogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。

为了提高Cluster的可伸缩性,必须保证充分利用每一个Server。Weblogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡,从而使每一个Server都得到充分的利用。

为了使Cluster具有高可用性,必须具备故障恢复的能力,这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求),容错功能自动实现。而有些情况下,重新调用可能会导致某一service被请求了多次的错误结果。例如:客户端C请求Clustered购物车服务中的additem()方法,replica-aware stub接收到请求,根据算法调用Server1上的service,Server1响应请求并返回结果,但在结果成功到达客户端之前,Server1出现错误。此时stub接收到错误信息,因此重新调用Server2上的这一方法,但实际上Server1已经将item加入购物车,这样就造成重复。为了解决这种问题,可以为服务添加一个唯一标识,如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。

三、 Cluster的命名服务

在Weblogic Server中使用命名服务时,客户端通过JNDI存取service,JNDI tree上绑定了Server提供的所有的公共服务。Server提供一个新的service时,是将service以某一名称绑定到JNDI tree上,客户端和Server建立连接并按照名称获取相应的stub。
Custer扩展了Server的这种命名服务机制,它不仅包含了每一个Server上的非Clustered的stub,而且包含了多个Server间的Clustered 的replica-aware stub。

四、 Cluster的服务类型

在Weblogic中,有多种服务可以进行cluster,如:RMI对象、EJB、Servlets、Jsp、Web Application。

(1)RMI和EJB Clustering
RMI和EJB对象在Cluster过程中使用JNDI命名服务机制。RMI和EJB对象发送remote stubs到客户端,客户端获取的这些stubs可以是已经clustered的,也可以是没有clustered的。对于Clustered的服务,Stubs根据负载均衡和容错的不同需求调用Cluster中合适的Server;而对没有Clustered的服务,所有对此stub的调用只能由提供此服务的Server来处理。

有些有状态的RMI和EJB对象是不可以进行clustered的,因为客户端必须总是和同一个Server上的对象实例相联系。所有的EJB都是clusterable,虽然EJB也有有状态的,但是EJB home interface 都是无状态的,可以进行clustered,这样就可以从JNDI tree上获取 Clusterable EJB 的home stub 对象。然后通过home stub的方法创建或检索相应的EJB bean,若为stateful session bean 或entity bean,那么此时得到的stub就是不可clusterable。为了使有状态的对象可以更好的cluster,可以将一些操作作为一个事务来执行,如果工作中的Server出现意外,可以重新获取此对象并进行事务操作。

RMI和EJB不同,RMI没有定义有状态和无状态分类,因此必须特意绑定一个有状态的RMI对象到Server上。可以仿效EJB home interface的方式即客户端从JNDI tree上获取一个clusterable factory method,然后factory method 可以调用集群中的任意一台Server,但是被调用的Server上必须有由此factory调用的对象。

(2)Clustered Servlets
Servlets也是可以进行Cluster的。对于Servlets,它用replica-aware proxy替代了replica-aware。这个proxy接受web server上所有请求,并转给集群中的某一Server。Proxy对cluster的所有请求进行负载均衡,并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时,proxy按照负载均衡算法选择一台Server保存session,此后,所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时,无法保存客户端状态信息,所以session会被复制下来,并且session的所有变化都会在备份中进行及时更新,这样,当原有Server在响应请求过程中失败时,proxy会立即获取session的备份,并由此继续响应客户端请求,同时做新的复制。

(3)JDBC clustering
为了利用Weblogic Server cluster的负载均衡和容错的性能,Weblogic JDBC连接池也可以在replicated naming tree上注册。通常情况下,cluster中的每一个Server都进行连接池属性配置来访问同一个后端的DBMS实例,即对相同数据库的访问,每一个Server都有一个连接池。然后通过在配置文件中定义一个DataSource属性来在naming tree 上注册连接池。客户端使用Weblogic JDBC/RMI JDBC 驱动程序从cluster中获取数据库连接,即客户端按照DataSource name获取连接池,然后按照负载均衡的算法选择相应的Weblogic Server来响应请求。

http://chinaunix.net/jh/28/125193.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/509190/viewspace-819125/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/509190/viewspace-819125/

你可能感兴趣的:([转帖]weblogic群集)