针对cluster负载均衡的方方面面

集群技术是负载均衡的发展根本。那么对于理解cluster也是学习负载均衡很重要的一部分。那么我们现在就来从集群的角度来认识负载均衡吧。这样我们通过多方位的交叉学习，就能夯实这方面的基础了，为以后的软硬件配置做好铺垫。

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来响应请求｡