WebLogic集群体系架构(原创)

WebLogic Server集群概述

WebLogicServer群集由多个WebLogicServer服务器实例组成，这些服务器实例同时运行并一起工作以提高可缩放性和可靠性。对于客户端而言，群集是一个WebLogicServer实例。构成群集的服务器实例可以在同一台计算机上运行，也可以位于不同的计算机上。可以通过向现有计算机上的群集中添加更多的服务器实例来增加群集的容量，也可以向群集中添加计算机以承载递增的服务器实例。群集中的每个服务器实例必须运行同一版本的WebLogicServer。

群集与域

群集是特定WebLogicServer域的一部分。

域是作为单元进行管理的一组相关的WebLogicServer资源。一个域包含一个或多个WebLogicServer实例，这些实例可以是群集实例、非群集实例，或者是群集与非群集实例的组合。一个域可以包含多个群集。域还包含部署在域中的应用程序组件、此域中的这些应用程序组件和服务器实例所需的资源和服务。应用程序和服务器实例使用的资源和服务示例包括计算机定义、可选网络通道、连接器和启动类。

可以使用各种条件将WebLogicServer实例组织到域中。例如，可以选择根据承载的应用程序的逻辑分区、地理方面的考虑或管理的资源的数目或复杂性将资源分配到多个域中。

在每个域中，一个WebLogicServer实例可充当管理服务器-此服务器实例可配置、管理和监视域中所有其他服务器实例和资源。每个管理服务器只管理一个域。

注意:如果一个域中包含多个群集，则域中的每个群集都具有相同的管理服务器。

群集中的所有的服务器实例必须驻留在同一域中；不能将群集“拆分”到多个域中。同样，不能在域之间共享配置的资源或子系统。例如，如果在一个域中创建了JDBC连接缓冲池，则不能将其用于另一个域中的服务器实例或群集。而是必须在另一个域中创建类似的连接缓冲池。

群集的WebLogicServer实例除提供故障转移和负载平衡外，其他行为与非群集的实例相似。配置群集的WebLogicServer实例所使用的过程和工具与配置非群集的WebLogicServer实例所使用的过程和工具相同。但是，为了获得群集启用的负载平衡和故障转移优点，必须符合群集配置的某些准则。

群集的优点

可伸缩性

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

高可用性

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

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

群集的关键功能

应用程序故障转移

简单的说，故障转移是当应用程序组件（在下列部分中通常称作“对象”）正在处理某个特定作业时-某些处理任务部分由于任何原因而变得不可用，已失败对象的副本将结束此作业。

对于能够接管失败对象的新对象：

必须存在可接管作业的已失败对象的副本;

必须存在对于其他对象和管理故障转移的程序可用的信息，从而定义所有对象的位置和操作状态，以便在完成其作业之前确定第一个失败的对象;

必须存在对于其他对象和管理故障转移的程序可用的信息（关于正在进行中的作业的进度），以便接管中断作业的对象了解在第一个对象失败之前完成的作业量，例如，已更改的数据以及过程中已完成的步骤。

WebLogicServer使用基于标准的通信技术和工具-多播、IP套接口、以及Java命名和目录接口(JNDI)来共享和维护群集中有关对象可用性的信息。这些技术允许WebLogicServer确定某个对象在结束其作业之前已停止，以及用于完成已中断作业的对象副本的位置。

有关已对作业所进行的操作的信息被称作状态。WebLogicServer可使用称为“会话复制”和“可识别副本的存根控件”的技术来维护有关状态方面的信息。如果某个特定对象意外地停止进行其作业，复制技术将启用此对象的副本将拾取失败对象停止的位置，并完成作业。

WebLogicServer支持自动或手动将群集服务器实例从一台计算机迁移到另一台计算机。可迁移的受管服务器被称作“可迁移服务器”。本功能适用于要求高可用性的环境。服务器迁移功能对于以下方面非常有用

确保“单元集服务”的不中断可用性

当承载服务器实例失败时，在任何给定的时间，单元集服务必须仅在单个服务器实例上运行，例如 JMS 和 JTA 事务恢复系统。为自动迁移配置的受管服务器在失败时将被自动迁移到另一台计算机。简化重新定位受管服务器的过程以及其承载的所有服务是规划系统管理进程的一部分。管理员可以从管理控制台或命令行中启动受管服务器的迁移。

服务器迁移过程会将整个受管服务器（包括IP地址和承载的应用程序）重新定位到预先定义的可用主机集中的一个。

负载平衡

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

必须存在可以执行特定作业的对象的多个副本。

有关所有对象的位置和操作状态的信息必须可用。

对象与群集

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

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

Servlet

JSP

EJB

远程方法调用（RemoteMethodInvocation，简称RMI）对象

Java消息服务(JMS)目标

    Java 数据库连接 (JDBC) 连接

不支持群集的对象类型

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

包含文件共享的文件服务

时间服务

关于此部分的详细信息可以参考

http://edocs.weblogicfans.net/wls/docs92/cluster/overview.html

群集中的通信

群集中的WebLogicServer实例使用两种基本网络技术互相通信：

IP多播，服务器实例使用该技术来广播服务和心跳（表明持续的可用性）的可用性。

IP套接口，这是群集服务器实例之间进行端到端通信的管道。

WebLogicServer使用IP多播和套接口通信的方式会影响群集的配置方式。

使用IP多播的一对多通信

IP多播是一种简单的广播技术，使多个应用程序能够“订阅”某个给定的IP地址和端口号，并监听消息。多播地址是一个介于224.0.0.0到239.255.255.255之间的IP地址。

注意:WebLogicServer使用的默认多播值为239.192.0.0。不应使用x.0.0.1范围内的多播地址。

IP多播向应用程序广播消息，但是不能保证这些消息真正被接收到。如果应用程序的本地多播缓冲区已满，则新的多播消息则无法写入该缓冲区，当消息被“丢弃”时，也不会通知该应用程序。因为此限制，所以WebLogicServer实例允许存在偶尔丢失通过IP多播广播的消息的可能性。

WebLogicServer对于群集中服务器实例之间的所有一对多通信均使用IP多播。此类通信包括：

群集范围的JNDI更新-群集中的每个WebLogicServer实例均使用多播来公告本地部署或本地删除的群集对象的可用性。群集中的每个服务器实例都监视这些公告，并更新其本地JNDI树以反映群集对象的当前部署。

群集心跳-群集中的每个WebLogicServer实例均使用多播来广播通告其可用性的规律的“心跳”信号。群集中的服务器实例通过监视心跳信号来确定某个服务器实例的失效时间。（群集服务器实例也会监视IP套接口，以此作为确定服务器实例失败时间的一种更为即时的方法。）

使用IP套接口的端到端通信

IP套接口提供了一种用于在两个应用程序之间传输消息和数据的简单的、高性能的机制。群集WebLogicServer实例将IP套接口用于下列用途：

访问部署到其他计算机上的另一个群集服务器实例的非群集对象。

在主服务器实例和次级服务器实例之间复制HTTP会话状态和有状态会话EJB状态。

访问位于远程服务器实例上的群集对象。（这种情况通常只在多层群集架构中发生，如推荐的多层体系结构中所述的架构。）

注意：WebLogicServer中IP套接口的使用会扩展到群集场景之外-所有RMI通信都通过使用套接口进行，例如当某个远程Java客户端应用程序访问某个远程对象时。

正确的套接口配置对于WebLogicServer群集的性能而言至关重要。两个因素决定着WebLogicServer中套接口通信的效率：

服务器实例的主机系统使用本地套接口读取器实现还是纯Java套接口读取器实现。

对于使用纯 Java 套接口读取器的系统，服务器实例是否经过配置，从而可以使用足够的套接口读取器线程。

群集体系结构术语

Web层

“Web层”为Web应用程序的客户端提供静态内容（例如，HTML网页）。Web层通常是外部客户端与Web应用程序之间的第一个联系点。一个简单的Web应用程序可以有一个Web层，该层由一台或多台运行WebLogicExpress、Apache、NetscapeEnterpriseServer或MicrosoftInternetInformationServer的计算机组成。

表示层

“表示层”为Web应用程序的客户端提供动态内容（例如，Servlet或JavaServerPage）。承载Servlet和/或JSP的WebLogicServer实例群集组成Web应用程序的表示层。如果该群集也为应用程序提供静态HTML网页，则该群集既是Web层又是表示层。

对象层

“对象层”提供Java对象（例如，EnterpriseJavaBean或RMI类）及其与Web应用程序相关的业务逻辑。承载EJB的WebLogicServer群集提供对象层。

De-Militarized区域(De-MilitarizedZone，简称DMZ)

“De-Militarized区域(DMZ)”是硬件和服务的逻辑集合，用于外部的、不可信的资源。在多数Web应用程序中，DMZ中有一系列Web服务器，这使基于浏览器的客户端可以访问静态HTML内容。

DMZ可以提供安全保护，能够防止来自外部的针对硬件和软件的攻击。不过，DMZ可用于不可信的资源，因此其安全性低于内部系统。例如，内部系统可以用拒绝所有外部访问的防火墙进行保护。通过使用防火墙“隐藏”对各个主机、应用程序或端口号的访问，可以保护DMZ，但将仍然允许从不可信的客户端访问那些服务。

负载平衡器

在本文中，术语“负载平衡器”用来描述将客户端连接请求分发到一个或多个IP地址的任何技术。例如，简单Web应用程序可以使用DNS循环算法作为负载平衡器。较大的应用程序通常使用基于硬件的负载平衡解决方案（例如，那些来自AlteonWebSystems的解决方案），这些解决方案也可以提供类似防火墙的安全功能。

负载平衡器提供将客户端连接与群集中的特定服务器相关联的功能，对客户端会话信息进行内存中复制时会使用该功能。使用负载平衡产品，必须配置cookie持久性机制，以免覆盖WebLogicServercookie，WebLogicServercookie跟踪用于内存中复制的主、辅服务器。

代理插件

“代理插件”是 WebLogic Server 对 HTTP 服务器（例如，Apache、Netscape Enterprise Server、或 Microsoft Internet Information Server）的扩展，它可以访问 WebLogic Server 群集提供的群集 Servlet。代理插件包含用于访问 WebLogic Server 群集中的 Servlet 和 JSP 的负载平衡逻辑。如果承载会话状态的主 WebLogic Server 失败，则代理插件还包含用于访问客户端会话状态副本的逻辑。

群集体系结构

基本体系结构

推荐的基本体系结构具有以下优点：

易于管理

单个的群集承载静态HTTP网页、Servlet和EJB，因此可以配置整个Web应用程序并用WebLogicServer控制台部署/取消部署对象。要充分利用群集Servlet，不需要另外维护一系列Web服务器（以及配置WebLogicServer代理插件）。

灵活的负载平衡

在WebLogicServer群集前面直接使用负载平衡硬件，以便访问HTML和Servlet内容时都可以使用高级负载平衡策略。例如，可以配置负载平衡，以检测到正确的当前服务器负载和直接客户端请求。

可靠的安全性

在负载平衡硬件的前面放置防火墙，以便使用最基本的防火墙策略为Web应用程序设置De-Militarized区域(DMZ)。

最佳性能

如果应用程序表示层中的多数或全部Servlets或JSP经常会访问对象层中的对象（例如，EJB或JDBC对象），则综合层体系结构可为该应用程序提供最佳性能。

注意:使用带有内存中会话复制功能的第三方负载平衡器时，必须确保负载平衡器与承载其主会话状态的WebLogic Server 实例（点访问服务器）保持客户端连接。

多层体系结构

多层体系结构有以下优点：

负载平衡EJB方法

在不同的群集分别承载Servlet和EJB，EJB的Servlet方法调用可以在多台服务器间实现负载平衡。

改进的服务器负载平衡

将表示层和对象层放在不同的群集上为分散Web应用程序负载提供了更多的选项。例如，如果应用程序访问HTTP和Servlet内容比访问EJB内容更加频繁，可以在表示层群集中使用大量的WebLogicServer实例，以将访问集中在少量承载EJB的服务器中。

更高的可用性

利用其他WebLogicServer实例，多层体系结构的单点故障会比基本群集体系结构的单点故障更少。例如，如果一个承载EJB的WebLogicServer失败，则Web应用程序的HTTP和Servlet承载能力不会受影响。

改进的安全选项

将表示层和对象层放在不同的群集上，可以使用只在 DMZ 中放置 Servlet/JSP 群集的防火墙策略。通过拒绝来自不可信客户端的直接访问，承载群集对象的服务器可以得到进一步的保护。

代理体系架构

代理体系架构可以将 WebLogic Server 群集配置为与现有 Web 服务器一起运行。在此体系结构中，一系列 Web 服务器使用 WebLogic 代理插件或 HttpClusterServlet 将 Servlet 和 JSP 请求直接定向到群集，为 Web 应用程序提供静态 HTTP 内容。

代理体系结构的优点

使用独立的Web服务器和代理插件有以下优势：

利用现有硬件

如果已有向客户端提供静态HTTP内容的Web应用程序体系结构，则可以轻松地将现有Web服务器与一个或多个WebLogicServer群集集成，以提供动态HTTP和群集对象。

熟悉的防火墙策略

在Web应用程序前端使用Web服务器协议，可以使用熟悉的防火墙策略来定义DMZ。通常，当不允许直接连接体系结构中其余WebLogic Server 群集时，还可以继续在 DMZ 中放置Web 服务器。

关于更多的体系结构信息可参考

http://edocs.weblogicfans.net/wls/docs92/cluster/planning.html

参考至:《叱咤风云：WebLogic企业级运维实战》戴冠平著

http://edocs.weblogicfans.net/wls/docs92/cluster/planning.html

http://edocs.weblogicfans.net/wls/docs92/cluster/load_balancing.html#wp1031590

http://edocs.weblogicfans.net/wls/docs92/cluster/features.html

本文原创，转载请注明出处、作者

如有错误，欢迎指出

邮箱:[email protected]