本文共 7328 字,大约阅读时间需要 24 分钟。
WebLogic Server集群概述 WebLogic Server 群集由多个 WebLogic Server 服务器实例组成,这些服务器实例同时运行并一起工作以提高可缩放性和可靠性。对于客户端而言,群集是一个WebLogic Server 实例。构成群集的服务器实例可以在同一台计算机上运行,也可以位于不同的计算机上。可以通过向现有计算机上的群集中添加更多的服务器实例来增加群集的容量,也可以向群集中添加计算机以承载递增的服务器实例。群集中的每个服务器实例必须运行同一版本的 WebLogic Server。群集与域 群集是特定WebLogic Server域的一部分。 域是作为单元进行管理的一组相关的WebLogic Server 资源。一个域包含一个或多个WebLogic Server实例,这些实例可以是群集实例、非群集实例,或者是群集与非群集实例的组合。一个域可以包含多个群集。域还包含部署在域中的应用程序组件、此域中的这些应用程序组件和服务器实例所需的资源和服务。应用程序和服务器实例使用的资源和服务示例包括计算机定义、可选网络通道、连接器和启动类。 可以使用各种条件将WebLogic Server 实例组织到域中。例如,可以选择根据承载的应用程序的逻辑分区、地理方面的考虑或管理的资源的数目或复杂性将资源分配到多个域中。 在每个域中,一个 WebLogic Server 实例可充当管理服务器 - 此服务器实例可配置、管理和监视域中所有其他服务器实例和资源。每个管理服务器只管理一个域。 注意:如果一个域中包含多个群集,则域中的每个群集都具有相同的管理服务器。 群集中的所有的服务器实例必须驻留在同一域中;不能将群集“拆分”到多个域中。同样,不能在域之间共享配置的资源或子系统。例如,如果在一个域中创建了 JDBC 连接缓冲池,则不能将其用于另一个域中的服务器实例或群集。而是必须在另一个域中创建类似的连接缓冲池。 群集的 WebLogic Server 实例除提供故障转移和负载平衡外,其他行为与非群集的实例相似。配置群集的WebLogic Server实例所使用的过程和工具与配置非群集的WebLogic Server实例所使用的过程和工具相同。但是,为了获得群集启用的负载平衡和故障转移优点,必须符合群集配置的某些准则。群集的优点 可伸缩性 可以动态增加部署在 WebLogic Server 群集中的应用程序的容量以满足需要。可以将服务器实例添加到群集中而不会中断服务 - 应用程序将继续运行而不会影响客户端和最终用户。
高可用性 在 WebLogic Server 群集中,当服务器实例失败时应用程序可继续进行处理。可通过将应用程序组件部署到群集中的多个服务器实例“群集”这些组件 - 这样,如果在其上运行某个组件的服务器实例失败,则将此组件部署到的其他服务器实例可以继续进行应用程序处理。 群集 WebLogic Server 实例的选择对于应用程序开发人员和客户端是透明的。但是,了解启用群集的技术基础结构将有助于编程人员和管理员最大化其应用程序的可伸缩性和可用性。群集的关键功能 应用程序故障转移 简单的说,故障转移是当应用程序组件(在下列部分中通常称作“对象”)正在处理某个特定作业时 - 某些处理任务部分由于任何原因而变得不可用,已失败对象的副本将结束此作业。 对于能够接管失败对象的新对象: 必须存在可接管作业的已失败对象的副本; 必须存在对于其他对象和管理故障转移的程序可用的信息,从而定义所有对象的位置和操作状态,以便在完成其作业之前确定第一个失败的对象; 必须存在对于其他对象和管理故障转移的程序可用的信息(关于正在进行中的作业的进度),以便接管中断作业的对象了解在第一个对象失败之前完成的作业量,例如,已更改的数据以及过程中已完成的步骤。 WebLogic Server 使用基于标准的通信技术和工具 - 多播、IP 套接口、以及 命名和目录接口 (JNDI) 来共享和维护群集中有关对象可用性的信息。这些技术允许 WebLogic Server 确定某个对象在结束其作业之前已停止,以及用于完成已中断作业的对象副本的位置。 有关已对作业所进行的操作的信息被称作状态。WebLogic Server 可使用称为“会话复制”和“可识别副本的存根控件”的技术来维护有关状态方面的信息。如果某个特定对象意外地停止进行其作业,复制技术将启用此对象的副本将拾取失败对象停止的位置,并完成作业。 WebLogic Server 支持自动或手动将群集服务器实例从一台计算机迁移到另一台计算机。可迁移的受管服务器被称作“可迁移服务器”。本功能适用于要求高可用性的环境。服务器迁移功能对于以下方面非常有用确保“单元集服务”的不中断可用性
当承载服务器实例失败时,在任何给定的时间,单元集服务必须仅在单个服务器实例上运行,例如 JMS 和 JTA 事务恢复系统。为自动迁移配置的受管服务器在失败时将被自动迁移到另一台计算机。简化重新定位受管服务器的过程以及其承载的所有服务是规划系统管理进程的一部分。管理员可以从管理控制台或命令行中启动受管服务器的迁移。 服务器迁移过程会将整个受管服务器(包括 IP 地址和承载的应用程序)重新定位到预先定义的可用主机集中的一个。负载平衡 负载平衡是在环境中跨计算资源与网络资源平均分发作业和关联的通信。对于即将发生的负载平衡: 必须存在可以执行特定作业的对象的多个副本。 有关所有对象的位置和操作状态的信息必须可用。对象与群集 群集的应用程序或应用程序组件在群集中的多个 WebLogic Server 实例上可用。如果已群集某个对象,则此对象的故障转移和负载平衡是可用的。将对象均匀部署到群集中的每个服务器实例,可以简化群集管理、维护和故障排除。 Web 应用程序可由不同类型的对象组成,包括企业 Java Bean (EJB),servlet 和 Java Server Pages (JSP)。每种对象类型都具有唯一的一组与控制、调用以及它如何在应用程序内起作用相关的行为。由于此原因,WebLogic Server 用于支持群集的方法,以及用于提供负载平衡和故障转移的方法,会因不同的类型对象而异。可在 WebLogic Server 部署对下列类型的对象进行群集: Servlet JSP EJB 远程方法调用(Remote Method Invocation,简称 RMI)对象 Java 消息服务 (JMS) 目标 Java 连接 (JDBC) 连接
不支持群集的对象类型 以下 API 和外部服务不可在 WebLogic Server 内群集: 包含文件共享的文件服务 时间服务 关于此部分的详细信息可以参考 http://edocs.weblogicfans.net/wls/docs92/cluster/overview.html群集中的通信 群集中的 WebLogic Server 实例使用两种基本网络技术互相通信: IP 多播,服务器实例使用该技术来广播服务和心跳(表明持续的可用性)的可用性。 IP 套接口,这是群集服务器实例之间进行端到端通信的管道。 WebLogic Server 使用 IP多播和套接口通信的方式会影响群集的配置方式。使用IP多播的一对多通信 IP 多播是一种简单的广播技术,使多个应用程序能够“订阅”某个给定的 IP 地址和端口号,并监听消息。多播地址是一个介于 224.0.0.0 到 239.255.255.255 之间的 IP 地址。注意:WebLogic Server 使用的默认多播值为 239.192.0.0。不应使用 x.0.0.1 范围内的多播地址。 IP 多播向应用程序广播消息,但是不能保证这些消息真正被接收到。如果应用程序的本地多播缓冲区已满,则新的多播消息则无法写入该缓冲区,当消息被“丢弃”时,也不会通知该应用程序。因为此限制,所以 WebLogic Server 实例允许存在偶尔丢失通过 IP 多播广播的消息的可能性。 WebLogic Server 对于群集中服务器实例之间的所有一对多通信均使用 IP 多播。此类通信包括: 群集范围的 JNDI 更新 - 群集中的每个 WebLogic Server 实例均使用多播来公告本地部署或本地删除的群集对象的可用性。群集中的每个服务器实例都监视这些公告,并更新其本地 JNDI 树以反映群集对象的当前部署。 群集心跳 - 群集中的每个 WebLogic Server 实例均使用多播来广播通告其可用性的规律的“心跳”信号。群集中的服务器实例通过监视心跳信号来确定某个服务器实例的失效时间。(群集服务器实例也会监视 IP 套接口,以此作为确定服务器实例失败时间的一种更为即时的方法。)使用 IP 套接口的端到端通信IP 套接口提供了一种用于在两个应用程序之间传输消息和数据的简单的、高性能的机制。群集 WebLogic Server 实例将 IP 套接口用于下列用途: 访问部署到其他计算机上的另一个群集服务器实例的非群集对象。 在主服务器实例和次级服务器实例之间复制 HTTP 会话状态和有状态会话EJB状态。 访问位于远程服务器实例上的群集对象。(这种情况通常只在多层群集中发生,如推荐的多层体系结构中所述的架构。) 注意:WebLogic Server 中 IP 套接口的使用会扩展到群集场景之外 - 所有 RMI 通信都通过使用套接口进行,例如当某个远程 Java 客户端应用程序访问某个远程对象时。 正确的套接口配置对于 WebLogic Server 群集的性能而言至关重要。两个因素决定着 WebLogic Server 中套接口通信的效率: 服务器实例的主机系统使用本地套接口读取器实现还是纯 Java 套接口读取器实现。 对于使用纯 Java 套接口读取器的系统,服务器实例是否经过配置,从而可以使用足够的套接口读取器线程。
群集体系结构术语 Web 层 “Web 层”为Web 应用程序的客户端提供静态内容(例如,HTML 网页)。Web 层通常是外部客户端与Web 应用程序之间的第一个联系点。一个简单的 Web 应用程序可以有一个 Web 层,该层由一台或多台运行 WebLogic Express、Apache、Netscape Enterprise Server 或 Microsoft Internet Information Server 的计算机组成。表示层 “表示层”为Web 应用程序的客户端提供动态内容(例如,Servlet 或 Java Server Page)。承载 Servlet 和/或 JSP 的 WebLogic Server 实例群集组成 Web 应用程序的表示层。如果该群集也为应用程序提供静态 HTML 网页,则该群集既是 Web 层又是表示层。对象层 “对象层”提供 Java 对象(例如,Enterprise JavaBean或 RMI 类)及其与Web应用程序相关的业务逻辑。承载 EJB 的WebLogic Server群集提供对象层。De-Militarized 区域 (De-Militarized Zone,简称 DMZ) “De-Militarized 区域 (DMZ)”是硬件和服务的逻辑集合,用于外部的、不可信的资源。在多数 Web 应用程序中,DMZ 中有一系列Web服务器,这使基于浏览器的客户端可以访问静态HTML内容。 DMZ 可以提供安全保护,能够防止来自外部的针对硬件和软件的攻击。不过,DMZ 可用于不可信的资源,因此其安全性低于内部系统。例如,内部系统可以用拒绝所有外部访问的防火墙进行保护。通过使用防火墙“隐藏”对各个主机、应用程序或端口号的访问,可以保护 DMZ,但将仍然允许从不可信的客户端访问那些服务。负载平衡器 在本文中,术语“负载平衡器”用来描述将客户端连接请求分发到一个或多个 IP 地址的任何技术。例如,简单 Web 应用程序可以使用 DNS 循环作为负载平衡器。较大的应用程序通常使用基于硬件的负载平衡解决方案(例如,那些来自 Alteon WebSystems 的解决方案),这些解决方案也可以提供类似防火墙的安全功能。 负载平衡器提供将客户端连接与群集中的特定服务器相关联的功能,对客户端会话信息进行内存中复制时会使用该功能。使用负载平衡产品,必须配置 cookie 持久性机制,以免覆盖 WebLogic Server cookie,WebLogic Server cookie 跟踪用于内存中复制的主、辅服务器。代理插件 “代理插件”是 WebLogic Server 对 HTTP 服务器(例如,Apache、Netscape Enterprise Server、或 Microsoft Internet Information Server)的扩展,它可以访问 WebLogic Server 群集提供的群集 Servlet。代理插件包含用于访问 WebLogic Server 群集中的 Servlet 和 JSP 的负载平衡逻辑。如果承载会话状态的主 WebLogic Server 失败,则代理插件还包含用于访问客户端会话状态副本的逻辑。
群集体系结构
基本体系结构
推荐的基本体系结构具有以下优点:
易于管理 单个的群集承载静态 HTTP 网页、Servlet 和 EJB,因此可以配置整个 Web 应用程序并用 WebLogic Server控制台部署/取消部署对象。要充分利用群集 Servlet,不需要另外维护一系列Web服务器(以及配置 WebLogic Server代理插件)。 灵活的负载平衡 在 WebLogic Server 群集前面直接使用负载平衡硬件,以便访问 HTML 和 Servlet 内容时都可以使用高级负载平衡策略。例如,可以配置负载平衡,以检测到正确的当前服务器负载和直接客户端请求。 可靠的安全性 在负载平衡硬件的前面放置防火墙,以便使用最基本的防火墙策略为 Web 应用程序设置De-Militarized区域 (DMZ)。 最佳性能 如果应用程序表示层中的多数或全部 Servlets 或 JSP 经常会访问对象层中的对象(例如,EJB 或 JDBC对象),则综合层体系结构可为该应用程序提供最佳性能。 注意:使用带有内存中会话复制功能的第三方负载平衡器时,必须确保负载平衡器与承载其主会话状态的WebLogic Server 实例(点访问服务器)保持客户端连接。
多层体系结构
多层体系结构有以下优点: 负载平衡 EJB 方法 在不同的群集分别承载 Servlet 和 EJB,EJB 的 Servlet 方法调用可以在多台服务器间实现负载平衡。 改进的服务器负载平衡 将表示层和对象层放在不同的群集上为分散 Web 应用程序负载提供了更多的选项。例如,如果应用程序访问 HTTP 和 Servlet 内容比访问 EJB 内容更加频繁,可以在表示层群集中使用大量的 WebLogic Server 实例,以将访问集中在少量承载 EJB 的服务器中。 更高的可用性 利用其他 WebLogic Server 实例,多层体系结构的单点故障会比基本群集体系结构的单点故障更少。例如,如果一个承载 EJB 的 WebLogic Server 失败,则 Web 应用程序的HTTP 和 Servlet 承载能力不会受影响。 改进的安全选项 将表示层和对象层放在不同的群集上,可以使用只在 DMZ 中放置 Servlet/JSP 群集的防火墙策略。通过拒绝来自不可信客户端的直接访问,承载群集对象的服务器可以得到进一步的保护。
代理体系架构
代理体系架构可以将 WebLogic Server 群集配置为与现有 Web 服务器一起运行。在此体系结构中,一系列 Web 服务器使用 WebLogic 代理插件或 HttpClusterServlet 将 Servlet 和 JSP 请求直接定向到群集,为 Web 应用程序提供静态 HTTP 内容。
代理体系结构的优点 使用独立的 Web 服务器和代理插件有以下优势: 利用现有硬件 如果已有向客户端提供静态 HTTP 内容的 Web 应用程序体系结构,则可以轻松地将现有 Web 服务器与一个或多个 WebLogic Server 群集集成,以提供动态 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 本文原创,转载请注明出处、作者 如有错误,欢迎指出 邮箱:czmcj@163.com