weblogic集群 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 实例的选择对于应用程序开发人员和客户端是透明的。但是，了解启用群集的技术基础结构将有助于编程人员和管理员最大化其应用程序的可伸缩性和可用性。
群集的关键功能
本部分采用非技术术语定义了启用可伸缩性和高可用性的关键群集功能。
可以群集对象的类型
群集的应用程序或应用程序组件在群集中的多个 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) 连接
不同对象类型可以具有某些共同的行为。如果是这样的话，则这些类似对象类型的群集支持和实现注意事项可能是相同的。在以下部分中，以下对象类型的解释和说明通常组合为：
- Servlet 和 JSP
- EJB 和 RMI 对象
下列部分简述了 WebLogic Server 为不同类型的对象提供的群集、故障转移和负载平衡支持。
Servlet 和 JSP
WebLogic Server 通过复制访问群集 servlet 和 JSP 的客户端的 HTTP 会话状态，为 servlet 和 JSP 提供了群集支持。WebLogic Server 可在内存、文件系统或数据库中维护 HTTP 会话状态。
要启用 servlet 和 JSP 的自动故障转移，会话状态必须持久保存在内存中。有关 servlet 和 JSP 的故障转移的工作方式信息，以及相关要求和编程注意事项。
可使用 WebLogic Server 代理插件或外部负载平衡硬件在群集中平衡 servlet 和 JSP 的负载。WebLogic Server 代理插件可执行循环法负载平衡。外部负载平衡器通常支持各种会话负载平衡机制。
EJB 和 RMI 对象
可使用“可识别副本的存根控件”（可在群集中定位对象实例）
处理 EJB 和 RMI 对象的负载平衡和故障转移。为 EJB 和 RMI 对象创建可识别副本的存根控件是对象编译过程所产生的结果。会将 EJB 和 RMI 对象均匀部署到群集中的所有服务器实例。
可使用对象的可识别副本的存根控件完成 EJB 和 RMI 对象的故障转移。当客户端通过可识别副本的存根控件向失败的服务做出调用时，该存根控件可检测故障并在另一副本上重试此调用。
WebLogic Server 群集支持多种负载平衡群集 EJB 和 RMI 对象的算法：round-robin、weight-based、random、round-robin-affinity、weight-based-affinity 和 random-affinity。默认情况下，WebLogic Server 群集将使用 round-robin 方法。可使用管理控制台配置群集以使用其他方法之一。选择的方法将保留在为群集对象获取的可识别副本的存根控件中。有关详细信息。
JDBC 连接
WebLogic Server 允许您群集 JDBC 对象（包括数据源和多数据源），以提高群集承载应用程序的可用性。为群集配置的每个 JDBC 对象必须存在于群集中的每个受管服务器上 - 当配置 JDBC 对象时，会将其定位到群集。
- 数据源 - 在群集中，外部客户端必须通过 JNDI 树上的 JDBC 数据源获得连接。数据源使用 WebLogic Server RMI 驱动程序来获取连接。如果承载先前连接的服务器实例失败，那么外部客户端应用程序中的 WebLogic 数据源的群集识别特性将请求另一个连接。尽管不是严格要求，BEA 还是建议服务器端的客户也应通过 JNDI 树中的数据源获得连接。
- 多数据源 - 多数据源是一组数据源的提取，可提供与此多数据源相关联的各数据源之间的负载平衡或故障转移处理。就像数据源会绑定到 JNDI 树一样，多数据源会绑定到 JNDI 树或本地应用程序上下文。就像在 JNDI 树上查找数据源一样，应用程序将在 JNDI 树上查找多数据源，然后请求数据库连接。多数据源会根据在多数据源配置中选择的算法（负载平衡或故障转移）确定要使用哪一个数据源来满足该请求。
使用群集的 JDBC 获取连接
要确保任何 JDBC 请求可由任何群集成员等同处理，群集中的每个受管服务器必须具有相似命名/定义的数据源或多数据源（如果适用）。要达到此效果，应将数据源和多数据源定位到群集中，以便它们可识别群集，如果将其用于外部客户端，它们将可连接到任何群集成员。
- 外部客户端连接 - 要求数据库连接执行 JNDI 查找，并获取数据源的可识别副本的存根控件的外部客户端。数据源存根控件包括承载数据源的服务器实例列表 - 服务器实例应该是群集中的所有受管服务器。可识别副本的存根控件包括负载平衡逻辑，用于在主机服务器实例中分发负载。
- 服务器端客户端连接 - 对于服务器端使用，将由数据源或多数据源的本地实例处理连接请求。服务器端数据源不会由于其 JDBC 连接而转至其他群集成员。在数据库事务的持续时间内，并且只要应用程序代码保留连接（除非连接关闭），连接将被固定到本地服务器实例。
JDBC 连接的故障转移和负载平衡
群集 JDBC 对象不会启用连接的故障转移，但在连接失败时，它将简化重新连接的过程。在复制的数据库环境中，可以群集多数据源以支持数据库故障转移和连接的负载平衡（可选）。有关详细信息，请参阅下列主题：
JMS和群集
通过支持在群集范围内透明访问群集中任何 WebLogic Server 服务器实例中目标，WebLogic Java 消息传递服务 (JMS) 体系结构可实现多个 JMS 服务器的群集。尽管 WebLogic Server 支持通过群集分发 JMS 目标和连接工厂，但是同一 JMS 主题和队列仍由群集中的每个 WebLogic Server 实例独立管理。
JMS 支持负载平衡。要启用负载平衡，必须为 JMS 服务器配置目标。
不可群集类型的对象
以下 API 和外部服务不可在 WebLogic Server 内群集：
在群集的各个 WebLogic Server 实例中仍可使用这些服务。但是，这些服务不能使用负载平衡或故障转移功能。
jwebee
我的个人网站
posted on 2007-06-11 11:39
周行 阅读(3769)
编辑
收藏 所属分类:
IT技术 、
weblogic
// Sys.WebForms.PageRequestManager._initialize('AjaxHolder$scriptmanager1', document.getElementById('Form1')); Sys.WebForms.PageRequestManager.getInstance()._updateControls(['tAjaxHolder$UpdatePanel1'], [], [], 90); //
FeedBack:
#re: weblogic集群
2007-08-14 10:52 |
gong1
实现应用程序文件同步
在企业应用程序的生命周期中，通常可以通过应用修复程序、添加新的 Web 内容或更新应用程序行为来对已部署的应用程序进行更新。一般来说，应用程序提供了允许用户上传在服务器端更改或创建的文件的用户界面。
将下面的场景作为一个示例：用户希望更新 Web 站点徽标图像文件，并且将原始文件作为 .war 文件应用程序的一部分进行存档。该应用程序提供了相关的功能和用户界面，以便用户完成这项任务。然后，用户选择一个新的图像作为 Web 站点的新徽标，并且上传该文件。系统使用新的文件替换原始的文件，并且当用户再次访问他的 Web 站点时，可以看到相应的更改。在单节点环境的应用服务器中，所有这些工作都可以顺利进行。然而，在集群环境中却存在一些问题。
这意味着，当应用程序运行于 WebSphere Application Server 时，需要在集群成员之间同步配置文件、二进制文件和资源文件。有一种机制可以处理上述问题。解决方案是使用共享的文件系统（例如，NFS）或共享的数据库。在这个解决方案中，所有经过更改或更新的文件都位于同一个共享文件系统或同一数据库中。对于共享的文件系统，所有应用程序都使用相同的位置，因此对于这些应用程序来说，任何文件更改都是可见的。对于共享的数据库，应用程序可以从数据库中获得相应的更改。
上述解决方案的缺点包括：
共享的文件系统和数据库导致一个新的单点故障。
它增加了编程和配置工作的复杂性。
它引入了一个新的性能瓶颈。
另一个解决方案是使用细粒度 WebSphere Application Server 应用程序管理 API，在集群的各个成员之间实现文件同步。WebSphere 6.0 中提供了这一特性。WebSphere 6.0 中包��许多改进，从而使得应用程序的部署更加容易并且更加高效。有关详细信息，请参见 WebSphere Application Server 信息中心。其中一个重要的改进是允许向系统提供部分经过更改的应用程序代码。不需要停止当前正在运行的应用程序。
WebSphere 6.0 还提供了灵活的应用程序文件管理。它允许应用程序通过以下方式进行更新：
替换整个应用程序（例如，整个 .ear 文件）。
替换、添加或删除应用程序中的单个模块（例如，.war、EJB.jar 或 .rar 文件）。
替换、添加或删除单个文件。
替换、添加或删除多个文件。
在对集群中的某个成员上的应用程序文件进行更新之后，将使用另一个新的特性 Rollout Update 对集群中各个成员的文件进行同步。它通过以下方式对应用程序进行更新：
保存更新的应用程序配置。
停止给定节点上所有的集群成员。
通过同步配置和重新启动该节点上停止的集群成员来更新该节点上的应用程序。
让我们回到前面关于 Web 站点徽标更新的示例。在这个场景中，徽标的更新和同步对于用户来说应该是透明的，无需 WebSphere 管理员进行人工干预。这就意味着，应用程序必须控制应用程序的更新，如替换存档于 ear 文件中的原始文件，并在集群的成员之间执行文件同步。您可以通过调用 WebSphere 提供的 Java Management Extensions (JMX) 接口来完成这项任务。JMX 是一项 Java 应用程序资源管理标准。有关 JMX 的详细信息，请参见 JMX Web 站点。图 3 显示了使用细粒度更新特性进行文件更新和同步的流程。
图 3. 使用细粒度特性更新和同步文件
应用程序在接收到用户上传的文件之后，它将调用 File Updater 以构造增量 EAR 文件。这个增量 EAR 文件是一个存档文件，它具有与完整的应用程序 ear 文件相同的结构。增量 EAR 文件和完整的应用程序 EAR 文件之间的区别在于，该增量 EAR 文件仅包含要进行更新的文件。File Updater 将构建这个增量 EAR。它可以是封装了增量 EAR 生成逻辑的简单 Java 类，或者是添加了验证逻辑和生成文件的相关复杂组件。
在集群环境中，如图 2 所示，WebSphere Application Network Deployment 服务器中的 Deployment Manager 将接收到用户的上传请求，然后该请求被发送到 Node A。Node A 将执行相应的业务逻辑并使用本地文件系统中的新图像文件替换原始图像文件。然而该集群中其他的成员并不清楚这项更改，其本地副本并没有得到更新。因此，该集群中各个成员之间的这个图像文件就出现了不一致的情况。如果 Node A 因为致命错误而停机，而 Node B 接收到了该请求，那么仍将使用原始的 Web 站点徽标。看上去客户似乎丢失了他所做的更改。
当前位置：
论坛首页 »
自由讨论区 »
Tomcat, WebLogic及J2EE讨论区
»
技术讨论
发起投票
2012-2-17 10:29:54 |
赞(
操作
