基于WebLogic的负载均衡集群系统六

1、基于WebLogic的负载均衡集群系统六 基于WebLogic的负载均衡集群系统摘 要 为了提高Web访问的实时性和吞吐量本文提出了一种基于WebLogic的负载均衡集群系统的构建方案。应用于我们的Internet络服务器上将负载分给多个服务器分担能够解决Internet服务器面临的大量并发访问造成的CU或I/O的高负载问题。本文对系统进行了压力测试实验结果表明该系统能够适应大型商业站的需求。关键词 负载均衡；集群；可伸缩性；可用性 0 引言互联的出现使信息访问产生了质的飞跃但随之而来的是Web流量的激增（高并发访问）由于涉及信息量十分庞大用户访问的频率也高许多基于Web的大型公共信息系统（如

2、电子图书馆、BBS、搜索引擎和远程教育等）需要在实时性和吞吐量方面都具有较高性能的Web服务器支持。一些热门的Web站点由于负荷过重而变的反应迟缓。如何提高Web服务器的性能和效率成为一个亟待解决的问题。 实际上服务器的处理能力和I/O已经成为提高Web服务的瓶颈。如果客户的增多导致通信量超出了服务器能承受的范围那么其结果必然是服务质量下降。显然单台服务器有限的性能不可能解决这个问题一台普通服务器的处理能力只能达到每秒几万个到几十万个请求无法在一秒内处理上百万个甚至更多的请求。显然采用高性能的主机系统（小型机或大型机）是可行的但是除了十分昂贵外这种高速、高性能的主机系统很多情况下也不能解决同时

3、处理几万个并发因为高速主机系统只是对于复杂的单一任务和有限的并发处理显得高性能而Internet中的Web服务器大多数处理是“简单任务”、高强度并发处理因此即便有大资金投入高性能、高的主机系统也不能很好的满足Web应用的需要。这就是利用Web服务器集群实现负载均衡的最初基本设计思想1。1 负载均衡集群高扩展型集群即负载均衡集群技术2就是带均衡策略（算法）的服务器集群。负载均衡集群在多节点之间按照一定的策略（算法）分发络或计算处理负载。负载均衡建立在现有络结构之上它提了一种廉价有效的方法来扩展服务器带宽增加吞吐量提高数据处理能力同时又可以避免单点故障3。 以Web访问为例后台的多个Web服务器上

4、面有相同的Web内容Internet客户端的访问请求首先进入一台服务器由它根据负载均衡策略（算法）合理地分配给某个服务器4。1.1 基于WebLogic的负载均衡集群WebLogic支持集群技术即让一组Server指向同一域名一起工作从而提一个更强大、更可靠的应用平台。对于客户端而言无论Cluster中有几 个Server在工作看上去都是一个5。集群技术有两个最明显的特色： (1)可伸缩性：Cluster对加入其中的Server在性能上没有限制（如普通的C机）为了提高性能当客户端的请求大幅增加时可以动态地向Cluster中添加Server。并且配置Cluster当一台机器的资源没有被完全利用时

5、可以在同一机器上启动多个Server但要求每一个Server使用不同的I而不能用同一I的不同端口。 (2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中因此相同的请求可以有多个Server提并且Server间还可以复制状态信息。这样当其中某一Server宕机或无法响应请求时其它的Server会立即接管它的任务从而把应用和客户端完全隔离开来。1.2 WebLogic 集群的工作机制每一个Clustered service,在每一个server上都会有一个instance即一个relica这些relicas集合在一起形成一个relica-aw

6、are stub。这些stubs负责客户端与相关的服务器段对象的通信当客户端请求该service时实际上是向stub发出请求stub根据不同的算法调用集合中某一relica如果调用失败stub会检测到错误并重新调用其它的relica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(arameter-based routing)。 WebLogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。6 为了提高Cluster的可伸缩性必须保证充分利用每一个Server。WebLogic可以在

7、不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡从而使每一个Server都得到充分的利用。 为了使Cluster具有高可用性必须具备故障恢复的能力这一点可以通过relica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)容错功能自动实现。而有些情况下重新调用可能会导致某一service被请求了多次的错误结果。例如：客户端C请求Clustered购物车服务中的add

8、item()方法relica-aware stub接收到请求根据算法调用Server1上的service,Server1响应请求并返回结果但在结果成功到达客户端之前Server1出现错误。此时stub接收到错误信息因此重新调用Server2上的这一方法但实际上Server1已经将item加入购物车这样就造成重复。为了解决这种问题可以为服务添加一个唯一标识如上述的additem()方法中可添加一个参数序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。2 构建WebLogic集群2.1 Domai n和ServerDomain是WebLogic Se

9、rver实例的基本管理单。所谓Domain就是由配置为Administrator Server的WebLogic Server实例管理的逻辑单这个单是有所有相关资源的集合。 Server是一个相对独立的为实现某些特定功能而结合在一起的单。7 一个Domain 可以包含一个或多个WebLogic Server实例甚至是Server集群。一个Domain中有一个且只能有一个Server 担任管理Server的功能其它的Server具体实现一个特定的逻辑功能。2.2 系统实现方案在此操作系统平台使用Windows 2000软件使用Bea WebLogic Server 8.1 S2程序基于J2EE架

10、构有以下两种方案： a单层混合型的集群架构（Cluster） 这种架构将所有的Web应用以及相关的服务应用全部置于集群中的单一WLS实例中这种架构的优势在于： 易于管理； 灵活的负载平衡机制； 更强的安全控制； b多层结构的集群架构（Cluster） 这种架构使用两个WLS集群一个放置表静态内容和集群Servlet另一个放置集群EJB。一般应用于下面这些情况： (1)在负载平衡机制需要调用集群EJB中的方法时； (2)在提内容与提对象的服务之间需要更大的机动性时； (3)在需要更高的系统稳定性时；2.3 集群应用的必要条件集群中的所有Server必须位于同一段并且必须是I广播(UD)可到达的。

11、8 集群中的所有Server必须使用相同的版本,包括Service ack。 集群中的Server必须使用永久的静态I。动态I分配不能用于集群环境。如果服务器位于防火墙后面而客户机位于防火墙外面那么服务器必须有公共的静态I只有这样客户端才能访问服务器。 要以Cluster方式运行必须有包含Cluster许可的License。3 系统实现及压力测试在配置集群应用前要对集群的配置信息有一个良好的设计下面就是我们配置的集群信息。如图1： 图1 集群配置信息机器类型 操作系统 硬件配置 角色 DELL C Windows 2000 I:10.16.92.7 ORT:7080 Administrat o

12、r Server DELL C Windows 2000 I:10.16.92.7 ORT:8080 roxy Server DELL C Windows 2000 I:10.16.92.7 ORT:7082 Managed Server DELL C Windows 2000 I:10.16.92.31 ORT:7084 Managed Server DELL C Windows 2000 I:10.16.92.32 ORT:7086 Managed Server DELL C Windows 2000 I:10.16.92.33 ORT:7088 Managed Server我们使用了四台

13、DELL-C机器其中每个机器都作Managed Server而选择其中一台机器兼作Administrator Server和roxy Server。 管理服务器（Administration Server）是一个WebLogic 服务器实例它负责配置与管理同一个域里的其它WebLogic Server 实例。管理服务器实例的意外中止对整个域的运行没有什么影响。当一个管理服务停止了它 所管理的其它服务实例(集群的或未集群的)都能正常运行。如果在这个域里存在有集群集群提的Failover和负载均衡服务也能够继续而不受影响。9 代理服务器（roxy Server）是整个站系统的总入口（和站的域名对应

14、）它接受web server上所有请求并转给集群中的某一个Managed Server。roxy对cluster的所有请求进行负载均衡并且当请求失败时会进行恢复处理。roxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时roxy按照负载均衡算法选择一台Server保存session此后所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时无法保存客户端状态信息所以session会被复制下来并且session的所有变化都会在备份中进行及时更新这样当原有Server在响应请求过程中失败时roxy

15、会立即获取session的备份并由此继续响应客户端请求同时做新的复制。 Managed Server上部署了站的应用程序用于执行roxy Server分发过来的用户请求。 我们对以上的集群系统进行了测试编写了一个简单的WEB应用它会在控制台和浏览器上同时打印出“OK”字样然后将这个WEB应用部署到集群中所有Managed Server上面。在这里我们将通过Aache中所带的ab包来进行并发访问的模拟测试使用如下的命令进行压力测试。 ab -n 100 -c 10 htt:/10.16.92.7:8080/index.js ab是测试程序的名称 参数n代表请求的总数量 参数c代表并发的请求数 u

16、rl为要测试压力的页面 使用这个命令时一定要在系统径中能够找到该程序否则不能执行。我们取请求的总数量n等于100压力测试完成后我们从Managed Server的控制台上可以看到nodeAnodeBnodeCnodeD（即四个Managed Server）分别打印出了27、23、24、26个“OK”字样这说明在并发请求的情况下集群能够将请求进行分发达到了负载平衡的目的。 另外我们编写了一个简单的购物车程序该系统能够在某一台机器宕机后把seesion转交给其他机器达到了故障接管的目的增加了Web系统的高可用性。4 系统故障分析我们经常会遇到HTT 请求在 WebLogic 集群节点之间的负载平衡

17、不均即集群中一个或多个节点接收和执行的 HTT 请求比同一集群中的其它节点多。 发生这种情况的原因是由于 HTT 会话分配不均。代理将不包含会话 cookie 的请求转发到基于 round-robin 负载平衡模式的集群节点并在该节点上创建新会话。8理想状态下所有集群节点应当接收等量的 HTT 会话。如果没有出现这种情况则由于负载平衡策略的“粘性”特点接收较多会话的节点将得到比 其它节点数量更多的请求。最终结果是造成集群节点之间负载分配不均。遇到这种问题可以查看代理插件的有关信息是否正常。 另一个经常遇到的问题是会话复制失败。会话复制失败通常是因为络组播问题引起的。有时候配置问题也会导致失败。

18、此外确保输入到会话中的数据必须是可序列化的否则复制可能会失败。编码的时候也应该注意比如不要使用 htt 会话的 utValue 和removeValue 方法因为它们不受支持并且当您在应用程序中使用这些方法时可能会出现会话数据复制问题。相反仅使用 HttSession 的setAttribute和removeAttribute 方法。10 此外还需要注意静态变量的使用缓存同步EJB、Servlet、JS同步等在单机环境下不会发生变化的值在集群环境下有可能会发生变化。5 结束语本文提出了一种基于WebLogic的集群Web服务器的设计方案通过压力测试系统能够达到负载均衡的目的该方案已经在某个大型商业站中使用并取得了很好的效果。参考1 Li Chuan Chen, Hyeon Ah Choi. Aroximation algorit