Weblogic集群介绍 以及简单搭建

     在介绍weblogic集群之前，先看看传统的双机架构,

这种架构存在以下几点不足之处：

1）采用主机备机的方式，一般主机使用比较频繁，导致另外比较空闲，资源利用不均衡。

2）当一个Server发生故障的时候，必须通知用户使用另外一台的Server，管理和维护比较麻烦。

3） 用户切换应用的时候，需重新登录，有些延误时间。

 

群集的优点是什么

可伸缩性

可以动态增加部署在 WebLogic Server 群集中的应用程序的容量以满足需要。可以将服务器实例添加到群集中而不会中断服务，应用程序将继续运行而不会影响客户端和最终用户。

 高可用性

  在WebLogic Server 群集中，当服务器实例失败时应用程序可继续进行处理。可通过将应用程序组件部署到群集中的多个服务器实例，“群集”这些组件，这样，如果在其上运行某个组件的服务器实例失败，则将此组件部署到的其他服务器实例可以继续进行应用程序处理。

  群集WebLogic Server 实例的选择对于应用程序开发人员和客户端是透明的。但是，了解启用群集的技术基础结构将有助于编程人员和管理员最大化其应用程序的可伸缩性和可用性。

群集的关键功能是什么

应用程序故障转移

  简单的说，故障转移是当应用程序组件（在下列部分中通常称作“对象”）正在处理某个特定作业时 某些处理任务部分由于任何原因而变得不可用，已失败对象的副本将结束此作业。 WebLogic Server 支持自动或手动将群集服务器实例从一台计算机迁移到另一台计算机。可迁移的受管服务器被称作“可迁移服务器”。本功能适用于要求高可用性的环境。

负载平衡

  负载平衡是在环境中跨计算资源与网络资源平均分发作业和关联的通信。

哪种类型的对象可以群集

  群集的应用程序或应用程序组件在群集中的多个 WebLogic Server 实例上可用。如果已群集某个对象，则此对象的故障转移和负载平衡是可用的。将对象均匀部署到群集中的每个服务器实例，可以简化群集管理、维护和故障排除。

  Web 应用程序可由不同类型的对象组成，包括企业 Java Bean (EJB)，servlet 和 Java Server Pages (JSP)。每种对象类型都具有唯一的一组与控制、调用以及它如何在应用程序内起作用相关的行为。由于此原因，WebLogic Server 用于支持群集的方法，以及用于提供负载平衡和故障转移的方法，会因不同的类型对象而异。可在 WebLogic Server 部署对下列类型的对象进行群集：

1）Servlet

2）JSP

3）EJB

4）远程方法调用（Remote Method Invocation，简称 RMI）对象

5）Java 消息服务 (JMS) 目标

6）Java 数据库连接 (JDBC) 连接

什么类型的对象不可群集

以下 API 和外部服务不可在 WebLogic Server 内群集：

1）包含文件共享的文件服务

2）时间服务

  在群集的各个 WebLogic Server 实例中仍可使用这些服务。但是，这些服务不能使用负载平衡或故障转移功能。

集群有哪些限制

1）集群中的WebLogic主机必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器。

2）集群中的所有WebLogic服务器必须位于同一个局域网，并且必须是IP广播可到达的。

3）集群中的所有WebLogic服务器必须使用相同的版本。配置集群中的服务器，使它们支持所提供的服务。对于使用了JDBC连接的EJB，所有部署了某EJB的服务器必须具有相同的部署与持久化配置。也就是说所有服务器都应该有相同的JDBC配置。所有部署了servlet的主机必须维护一组具有相同ACL的servlet

 

 

0  引言

    互联网的出现使信息访问产生了质的飞跃，但随之而来的是Web流量的激增（高并发访问），由于涉及信息量十分庞大，用户访问的频率也高，许多基于Web的大型公共信息系统（如电子图书馆、BBS、搜索引擎和远程教育等）需要在实时性和吞吐量方面都具有较高性能的Web服务器支持。一些热门的Web站点由于负荷过重而变的反应迟缓。如何提高Web服务器的性能和效率成为一个亟待解决的问题。     实际上，服务器的处理能力和I/O已经成为提高Web服务的瓶颈。如果客户的增多导致通信量超出了服务器能承受的范围，那么其结果必然是服务质量下降。显然单台服务器有限的性能不可能解决这个问题，一台普通服务器的处理能力只能达到每秒几万个到几十万个请求，无法在一秒内处理上百万个甚至更多的请求。显然，采用高性能的主机系统（小型机或大型机）是可行的，但是除了价格十分昂贵外，这种高速、高性能的主机系统，很多情况下也不能解决同时处理几万个并发，因为，高速主机系统只是对于复杂的单一任务和有限的并发处理显得高性能，而Internet中的Web服务器大多数处理是“简单任务”、高强度并发处理，因此即便有大资金投入高性能、高价格的主机系统，也不能很好的满足Web应用的需要。这就是利用Web服务器集群实现负载均衡的最初基本设计思想^[1]。

1 负载均衡集群

    高扩展型集群，即负载均衡集群技术^[2]，就是带均衡策略（算法）的服务器集群。负载均衡集群在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障^[3]。     以Web访问为例，后台的多个Web服务器上面有相同的Web内容，Internet客户端的访问请求首先进入一台服务器，由它根据负载均衡策略（算法）合理地分配给某个服务器^[4]。

1.1 基于WebLogic的负载均衡集群

    WebLogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可靠的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个^[5]。集群技术有两个最明显的特色：     (1)可伸缩性：Cluster对加入其中的Server在性能上没有限制（如普通的PC机），为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。     (2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。

1.2  WebLogic 集群的工作机制

    每一个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通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。^[6] 为了提高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不能被重复添加。

2 构建WebLogic集群

2.1  Domain和Server

    Domain是WebLogic Server实例的基本管理单元。所谓Domain就是，由配置为Administrator Server的WebLogic Server实例管理的逻辑单元，这个单元是有所有相关资源的集合。     Server是一个相对独立的，为实现某些特定功能而结合在一起的单元。^[7]     一个Domain 可以包含一个或多个WebLogic Server实例，甚至是Server集群。一个Domain中有一个且只能有一个Server 担任管理Server的功能，其它的Server具体实现一个特定的逻辑功能。

2.2  系统实现方案

    在此，操作系统平台使用Windows 2000，软件使用Bea WebLogic Server 8.1 SP2，程序基于J2EE架构，有以下两种方案：     a．单层混合型的集群架构（Cluster）     这种架构将所有的Web应用以及相关的服务应用全部置于集群中的单一WLS实例中，这种架构的优势在于：　　     易于管理；     灵活的负载平衡机制；     更强的安全控制；     b．多层结构的集群架构（Cluster）     这种架构使用两个WLS集群，一个放置表静态内容和集群Servlet，另一个放置集群EJB。一般应用于下面这些情况：　　(1)在负载平衡机制需要调用集群EJB中的方法时；　　(2)在提供内容与提供对象的服务之间需要更大的机动性时；　　(3)在需要更高的系统稳定性时；

2.3 集群应用的必要条件

    集群中的所有Server必须位于同一网段，并且必须是IP广播(UDP)可到达的。^[8]     集群中的所有Server必须使用相同的版本,包括Service Pack。     集群中的Server必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器。  要以Cluster方式运行，必须有包含Cluster许可的License。

3 系统实现及压力测试

    在配置集群应用前要对集群的配置信息有一个良好的设计，下面就是我们配置的集群信息。如图1：图1 集群配置信息

机器类型 操作系统 硬件配置 角色 DELL PC Windows 2000 IP:10.16.92.7 PORT:7080 Administrat or Server DELL PC Windows 2000 IP:10.16.92.7 PORT:8080 Proxy Server DELL PC Windows 2000 IP:10.16.92.7 PORT:7082 Managed Server DELL PC Windows 2000 IP:10.16.92.31 PORT:7084 Managed Server DELL PC Windows 2000 IP:10.16.92.32 PORT:7086 Managed Server DELL PC Windows 2000 IP:10.16.92.33 PORT:7088 Managed Server

    我们使用了四台DELL-PC机器，其中每个机器都作Managed Server，而选择其中一台机器兼作Administrator Server和Proxy Server。     管理服务器（Administration Server）是一个WebLogic 服务器实例，它负责配置与管理同一个域里的其它WebLogic Server 实例。管理服务器实例的意外中止对整个域的运行没有什么影响。当一个管理服务停止了，它所管理的其它服务实例(集群的或未集群的)都能正常运行。如果在这个域里存在有集群，集群提供的Failover和负载均衡服务也能够继续而不受影响。^[9]     代理服务器（Proxy Server）是整个网站系统的总入口（和网站的域名对应），它接受web server上所有请求，并转给集群中的某一个Managed Server。Proxy对cluster的所有请求进行负载均衡，并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时，proxy按照负载均衡算法选择一台Server保存session，此后，所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时，无法保存客户端状态信息，所以session会被复制下来，并且session的所有变化都会在备份中进行及时更新，这样，当原有Server在响应请求过程中失败时，proxy会立即获取session的备份，并由此继续响应客户端请求，同时做新的复制。     Managed Server上部署了网站的应用程序，用于执行Proxy Server分发过来的用户请求。我们对以上的集群系统进行了测试，编写了一个简单的WEB应用，它会在控制台和浏览器上同时打印出“OK”字样，然后将这个WEB应用部署到集群中所有Managed Server上面。在这里我们将通过Apache中所带的ab包来进行并发访问的模拟测试，使用如下的命令进行压力测试。 ab -n 100 -c 10 http://10.16.92.7:8080/index.jsp     ab是测试程序的名称     参数n代表请求的总数量     参数c代表并发的请求数     url为要测试压力的页面     使用这个命令时，一定要在系统路径中能够找到该程序，否则不能执行。我们取请求的总数量n等于100，压力测试完成后，我们从Managed Server的控制台上可以看到，nodeA，nodeB，nodeC，nodeD（即四个Managed Server）分别打印出了27、23、24、26个“OK”字样，这说明，在并发请求的情况下，集群能够将请求进行分发，达到了负载平衡的目的。     另外，我们编写了一个简单的购物车程序，该系统能够在某一台机器宕机后把seesion转交给其他机器，达到了故障接管的目的，增加了Web系统的高可用性。

4 系统故障分析

    我们经常会遇到HTTP 请求在 WebLogic 集群节点之间的负载平衡不均，即，集群中一个或多个节点接收和执行的 HTTP 请求比同一集群中的其它节点多。     发生这种情况的原因是由于 HTTP 会话分配不均。代理将不包含会话 cookie 的请求转发到基于 round-robin 负载平衡模式的集群节点，并在该节点上创建新会话。^[8]理想状态下，所有集群节点应当接收等量的 HTTP 会话。如果没有出现这种情况，则由于负载平衡策略的“粘性”特点，接收较多会话的节点将得到比其它节点数量更多的请求。最终结果是造成集群节点之间负载分配不均。遇到这种问题，可以查看代理插件的有关信息是否正常。     另一个经常遇到的问题是会话复制失败。会话复制失败通常是因为网络组播问题引起的。有时候，配置问题也会导致失败。此外，确保输入到会话中的数据必须是可序列化的，否则复制可能会失败。编码的时候也应该注意，比如不要使用 http 会话的 putValue 和removeValue 方法，因为它们不受支持，并且当您在应用程序中使用这些方法时，可能会出现会话数据复制问题。相反，仅使用 HttpSession 的setAttribute和removeAttribute 方法。^[10]     此外，还需要注意静态变量的使用，缓存同步，EJB、Servlet、JSP同步等，在单机环境下不会发生变化的值在集群环境下有可能会发生变化。

5 结束语

    本文提出了一种基于WebLogic的集群Web服务器的设计方案，通过压力测试，系统能够达到负载均衡的目的，该方案已经在某个大型商业网站中使用并取得了很好的效果。

参考文献

[1] Li Chuan Chen, Hyeon Ah Choi. Approximation algorithms for data distribution with load balancing of Web servers[J]. In: Proceedings of IEEE International Conference on Cluster Computing, 2001,274-281 [2] Mark Artiges（美），袁毅, 谈莉娅, 宋燕红译.《BEA WebLogic Server 8.1大全》[M]；机械工业出版社,2005 [3] 黄铠，徐志伟.《可扩展并行计算技术、结构与编程》[M]；机械工业出版社,2000 [4] 李双庆，古平，程代杰.Web系统负载均衡策略分析与研究 [J].计算机工程与应用.2002,（19）：40-43（in Chinese） [5] 柏海寰, 基于分散式查找的Web服务器集群 [J] 计算机工程.2006；32:96-116 [6] 李定锁,Web服务器集群中的文件优化分配 [J] 计算机工程与应用。2004；16:79-81 [7] Joel Millecan (美),Internet信息服务器技术 [M].北京；清华大学出版社,1998.209 [8] 小泉修(日),Web技术:HTTP到服务器端王浩译 [M] 北京:科学出版社,2004 [9] 刘刚常,基于集群分配器的Web服务器集群系统的Web QoS研究 [O],硕士,湖南大学 2006 [10] 刘博,嵌入式Web服务器的设计与实现 [O],硕士,西安电子科技大学,2006