|
|
本部分描述 WebLogic Server 群集为不同类型的对象提供的负载平衡支持，并为架构师和管理员提供了相关的计划和配置注意事项。它包含下列信息：
有关群集中复制和故障转移的信息，请参阅群集中的故障转移和复制。
Servlet 和 JSP 的负载平衡可以通过 WebLogic 代理插件的内置负载平衡功能或者单独的负载平衡硬件实现。
| 注意： | 除了分发 HTTP 流量之外，外部负载平衡器还可以通过 t3 和默认通道分发来自 Java 客户端的初始上下文请求。有关 WebLogic Server 中对象级负载平衡的讨论，请参阅 EJB 和 RMI 对象的负载平衡。 |
WebLogic 代理插件维护一个 WebLogic Server 实例列表（这些实例承载着群集 Servlet 或 JSP），并以循环法为基础向这些实例转发 HTTP 请求。这种负载平衡方法在循环法负载平衡中进行了描述。
该插件还提供在某个 WebLogic Server 实例失败时查找客户端 HTTP 会话状态副本所需的逻辑。
WebLogic Server 支持下列 Web 服务器和相关联的代理插件：
有关设置代理插件的说明，请参阅配置代理插件。
有关使用代理插件时群集中 HTTP 会话的连接和故障转移的描述，请参阅使用代理访问群集的 Servlet 和 JSP。
使用硬件负载平衡解决方案的群集可以使用该硬件支持的任何负载平衡算法。其中可能包括监视每个计算机使用情况的基于负载的高级平衡策略。
如果选择使用负载平衡硬件而不是代理插件，则该硬件必须支持兼容的被动或主动 Cookie 持久性机制和 SSL 持久性。
被动 Cookie 持久性使得 WebLogic Server 能够将包含会话参数信息的 Cookie 通过负载平衡器写入客户端。有关会话 Cookie 以及负载平衡器如何使用会话参数数据来维护客户端与承载 HTTP 会话状态的主 WebLogic Server 之间关系的信息，请参阅负载平衡器和 WebLogic 会话 Cookie。
某些主动 Cookie 持久性机制可用于 WebLogic Server 群集，前提是负载平衡器不修改 WebLogic Server Cookie。WebLogic Server 群集不支持覆盖或修改 WebLogic HTTP 会话 Cookie 的主动 Cookie 持久性机制。如果负载平衡器的主动 Cookie 持久性机制通过向客户端会话添加其自己 Cookie 的方式运行，则将该负载平衡器用于 WebLogic Server 群集时不需要任何附加配置。
使用 SSL 持久性时，负载平衡器执行客户端和 WebLogic Server 群集之间数据的所有加密和解密操作。然后负载平衡器使用 WebLogic Server 插入客户端的纯文本 Cookie 来维护客户端和群集中特定服务器之间的关联。
使用被动 Cookie 持久性的负载平衡器可以使用 WebLogic 会话 Cookie 中的字符串将客户端与承载其主 HTTP 会话状态的服务器相关联。该字符串可唯一标识群集中的服务器实例。您必须使用该字符串常量的偏移和长度配置负载平衡器。偏移和长度的正确值取决于会话 Cookie 的格式。
sessionid!primary_server_id!secondary_server_id
| 注意： | 对于使用非复制内存、Cookie、JDBC 或基于文件的会话持久性的会话，不存在 secondary_server_id。对于使用内存中复制的会话，如果不存在次级会话，则 secondary_server_id 为“NONE”。 |
有关配置负载平衡器的常规说明，请参阅配置支持被动 Cookie 持久性的负载平衡器。有关配置 BIG-IP 的说明，请参阅为群集配置 BIG-IP™ 硬件。
有关群集 Servlet 和 JSP 的编程约束和建议，请参阅群集 Servlet 和 JSP 的编程注意事项。
有关使用负载平衡硬件时群集中 HTTP 会话的连接和故障转移描述，请参阅使用负载平衡硬件访问群集的 Servlet 和 JSP。
本部分描述 EJB 和 RMI 对象的 WebLogic Server 负载平衡算法。
对象的负载平衡算法在为群集对象获得的副本感知存根控件中维护。
默认情况下，WebLogic Server 群集使用循环法负载平衡，如循环法负载平衡中所述。您可以通过使用管理控制台来设置 weblogic.cluster.defaultLoadAlgorithm，从而为群集配置不同的默认负载平衡方法。有关说明，请参阅为 EJB 和 RMI 配置负载平衡。您还可以使用 rmic 中的 -loadAlgorithm 选项，或使用 EJB 部署描述符中的 home-load-algorithm 或 stateless-bean-load-algorithm 为特定 RMI 对象指定负载平衡算法。为对象配置的负载平衡算法会替换群集的默认负载平衡算法。
除了标准负载平衡算法之外，WebLogic Server 还支持自定义的基于参数的路由。有关详细信息，请参阅群集对象基于参数的路由。
WebLogic Server 使用循环法算法作为没有指定算法时群集对象存根控件的默认负载平衡策略。就 RMI 对象和 EJB 来说，均支持此算法。它还是 WebLogic 代理插件使用的方法。
循环法算法对 WebLogic Server 实例列表按顺序进行循环。对于群集对象，该服务器列表由承载该群集对象的 WebLogic Server 实例组成。对于代理插件，该列表则由承载群集 Servlet 或 JSP 的所有 WebLogic Server 实例组成。
循环法算法的优点在于它简单、使用资源少而且极具预见性。主要缺点在于可能会发生“护航”。当一个服务器的速度明显慢于其他服务器时会发生护航。因为副本感知存根控件或代理插件以同一顺序访问服务器，所以速度较慢的服务器可以导致针对该服务器请求“同步”，然后将该服务器排在其他服务器的后面以应对未来的请求。
| 注意： | WebLogic Server 并不总是对对象的方法调用进行负载平衡。有关详细信息，请参阅共存对象的优化。 |
基于权数的负载平衡通过考虑为每个服务器预先分配的权数，在循环法算法基础上进行了改善。您可以使用管理控制台中的“服务器 -> 配置 -> 群集”选项卡，在“群集权数”字段中为群集中的每个服务器分配一个介于 1 和 100 之间的数字权数。此值决定了服务器相对于其他服务器要承担的负载比例。如果所有服务器的权数相同，它们每个则会承担相同比例的负载。如果一个服务器的权数为 50 而所有其他服务器的权数都是 100，则这个权数为 50 的服务器承担的负载为所有其他服务器的一半。此算法使得对于不均匀群集应用循环法算法的优点成为了可能。
如果您使用基于权数的算法，则请仔细确定分配给每个服务器实例的相对权数。要考虑的因素包括：
如果更改为服务器指定的权数然后重新引导该服务器，则新的权数信息会通过副本感知存根控件传播到整个群集。有关信息，请参阅群集范围的 JNDI 命名服务。
| 注意： | WebLogic Server 并不总是对对象的方法调用进行负载平衡。有关详细信息，请参阅共存对象的优化。 |
| 注意： | 在本版本的 WebLogic Server 中，对于使用 RMI/IIOP 协议进行通信的对象，不支持基于权数的负载平衡。 |
在随机负载平衡中，请求是随机路由到服务器的。建议只对于每个服务器实例在配置相似的计算机上运行的均匀群集部署才使用随机负载平衡。请求的随机分配不允许服务器实例运行所在的计算机之间存在处理能力差异。如果群集中承载服务器的某个计算机的处理能力比群集内的其他计算机差很多，随机负载平衡仍然会为处理能力较差的计算机提供与处理能力较强的计算机同样多的请求。
随机平衡负载在群集的服务器实例之间均匀分布请求，并且会随着请求累积数量的增加而增加。对于较少数量的请求，该负载可能无法精确均匀平衡。
随机负载平衡的缺点包括生成每个请求的随机数量所产生的微小处理开销，以及对于较小数量的请求负载可能无法均匀平衡。
| 注意： | WebLogic Server 并不总是对对象的方法调用进行负载平衡。有关详细信息，请参阅共存对象的优化。 |
WebLogic Server 为提供服务器关系的 RMI 对象提供了三种负载平衡算法。服务器关系对于外部客户端连接会关闭负载平衡：而客户端在选择要在其中访问对象的服务器实例时会考虑其与 WebLogic 服务器实例的现有连接。如果某个对象针对服务器关系进行了配置，客户端存根控件则会尝试选择它已经连接的服务器实例，并继续将同一服务器实例用于方法调用。该客户端上的所有存根控件都会尝试使用该服务器实例。如果该服务器实例不可用，存根控件则会在可能的情况下故障转移到客户端已经连接的服务器实例。
服务器关系的目的是为了尽可能减少外部 Java 客户端和群集中的服务器实例之间打开的 IP 套接口数。WebLogic Server 通过使得针对对象的方法调用“粘连”到现有连接的方式实现上述目的，而不在可用服务器实例之间对这些方法调用进行负载平衡。使用服务器关系算法时，使用资源较少的服务器到服务器的连接仍然根据配置的负载平衡算法进行负载平衡 – 仅对于外部客户端连接才禁用负载平衡。
服务器关系与其中一个标准负载平衡方法（循环法、基于权数或者随机）组合使用：
客户端可以从群集中的特定服务器实例请求初始上下文，还可以通过在 URL 中指定群集地址从群集请求初始上下文。根据上下文获取方式的不同，连接的处理方式也有所不同：
如果您使用 WebLogic Server 的 Common Secure Interoperability (CSIv2) 功能支持与 WebLogic Server 的 J2EE 应用程序客户端（“瘦客户端”）之间的有状态交互，则必须使用基于关系的负载平衡算法来确保方法调用粘连到服务器实例。否则，所有远程调用都将进行身份验证。要防止有状态 CSIv2 客户端的冗余身份验证，请使用循环法关系、基于权数关系和随机关系中描述的其中一个负载平衡方法。
WebLogic Server 具有三种提供服务器关系的负载平衡算法：
对于所有类型的 RMI 对象（包括 JMS 对象）、所有 EJB Home 接口和无状态 EJB 远程接口均支持服务器关系。
服务器关系算法在 WebLogic 服务器实例之间平衡客户端负载时会考虑外部 Java 客户端和服务器实例之间的现有连接。服务器关系：
下列示例演示了服务器关系在各种情况下的影响结果。在每个示例中，部署的对象都针对循环法关系进行了配置。
在此示例中，客户端从群集获取上下文。在上下文中的查找以及对象调用粘连到一个连接。对新初始上下文的请求基于循环法进行负载平衡。
此示例演示了服务器关系对对象故障转移的影响结果。当受管服务器关闭时，客户端会故障转移到它具有连接的另一个受管服务器。
此示例说明了服务器关系对服务器实例之间的连接不会产生影响的事实。
基于参数的路由使您能够在更低级别对负载平衡行为进行控制。对于任何群集对象都可分配 CallRouter。这是在每次使用调用参数进行调用之前调用的类。CallRouter 不用检查这些参数，它会返回调用应路由到的服务器的名称。有关创建自定义 CallRouter 类的信息，请参阅“WebLogic RMI 编程”中的群集对象的基于参数的路由。
WebLogic Server 并不总是对对象的方法调用进行负载平衡。在大多数情况下，使用与存根控件本身共存的副本效率更高，而不要使用位于远程服务器上的副本。下图说明了这种情况。
在此示例中，客户端连接群集中的第一个 WebLogic Server 示例承载的 Servlet。为了响应客户端活动，该 Servlet 获取了对象 A 的副本感知存根控件。因为对象 A 的副本在同一服务器实例上也可用，所以我们说该对象与该客户端的存根控件是共存的。
WebLogic Server 总是使用对象 A 的本地共存副本，而不是将客户端的调用分布到群集中对象 A 的其他副本。使用本地副本的效率更高，因为使用本地副本可避免与群集的其他服务器之间建立对等连接的网络开销。
这种优化在计划 WebLogic Server 群集时经常被忽略。共存优化通常也会为希望或要求对每个方法调用进行负载平衡的管理员或开发人员带来困惑。如果您的 Web 应用程序部署到一个群集中，共存优化则会替换副本感知存根控件中固有的任何负载平衡逻辑。
如果要求对群集对象的每个方法调用都进行负载平衡，则请参阅推荐的多层体系结构了解有关如何对 WebLogic Server 群集进行相应计划的信息。
作为基本共存策略的扩展，WebLogic Server 会尝试使用作为同一事务的一部分列出的共存群集对象。当客户端创建 UserTransaction 对象时，WebLogic Server 会尝试使用与该事务共存的对象副本。这种优化在下图中进行了描述。
在此示例中，客户端连接群集中的第一个 WebLogic Server 实例，并获取 UserTransaction 对象。开始新事务之后，该客户端查找对象 A 和 B 以执行该事务的工作。在这种情况下，WebLogic Server 总是尝试使用与 UserTransaction 对象位于同一个服务器上的 A 和 B 的副本，而不管 A 和 B 的存根控件中负载平衡策略如何。
这种事务共存策略甚至比共存对象的优化中描述的基本优化更为重要。如果使用的是 A 和 B 的远程副本，则在事务持续时间内会发生增加的网络开销，因为在提交该事务之前 A 和 B 的对等连接一直处于锁定状态。另外，WebLogic Server 需要采用多层 JDBC 连接来提交该事务，从而又产生了附加的网络开销。
通过在事务期间使用共存群集对象，WebLogic Server 会减少访问单个对象的网络负载。服务器还可以使用单层 JDBC 连接来代替多层连接，以执行事务的工作。
WebLogic Server JMS 支持分布式 JMS 目标和客户端连接的服务器关系。
默认情况下，WebLogic Server 群集使用循环法对对象进行负载平衡。要使用为 JMS 对象提供服务器关系的负载平衡方法，必须将群集作为整体为其配置所需的方法。您可以通过使用管理控制台设置 weblogic.cluster.defaultLoadAlgorithm 来配置负载平衡算法。有关说明，请参阅为 EJB 和 RMI 配置负载平衡。
| 注意： | 要为 JMS 和 JTA 固定服务的故障转移提供持久性存储，您可以考虑使用如 VERITAS™ Cluster Server 这样的高可用性群集软件，这些软件会为基于 BEA WebLogic Server 的应用程序提供集成的现成解决方案。推荐的某些其他高可用性软件解决方案包括 SunCluster、IBM HACMP 或同类软件。 |
对于使用分布式目标功能的 JMS 应用程序，将支持服务器关系；此功能对于独立目标则不受支持。如果为 JMS 连接工厂配置服务器关系，则在分布式目标的多个成员间对使用者或生成者进行负载平衡的服务器实例将首先尝试在同时运行于同一个服务器实例的任何目标成员之间进行负载平衡。
有关 JMS 连接工厂的“已启用服务器关系”选项如何影响分布式目标成员的负载平衡首选项的详细信息，请参阅“WebLogic JMS 编程”中的使用“已启用服务器关系”特性时如何影响分布式目标负载平衡。
系统管理员可以配置多个 JMS 服务器并使用目标将它们分配到定义的 WebLogic Server，从而在群集中的多个服务器之间建立 JMS 目标的负载平衡。每个 JMS 服务器仅部署于一个 WebLogic Server 上，并处理一组目标的请求。在配置阶段中，系统管理员通过为 JMS 服务器指定目标来启用负载平衡。有关设置目标的说明，请参阅为固定服务配置可迁移目标。有关将 JMS 服务器部署到可迁移目标的说明，请参阅部署、激活和迁移可迁移服务。
系统管理员通过配置多个连接工厂然后使用目标将它们分配到 WebLogic Server，可以建立从群集中的任何服务器到目标的群集范围的透明访问。每个连接工厂都可以部署到多个 WebLogic Server 上。有关连接工厂的更多详细描述，请参阅“WebLogic JMS 编程”中的连接工厂。
应用程序使用 Java 命名和目录接口（Java Naming and Directory Interface，简称 JNDI）查找连接工厂，并创建连接以建立与 JMS 服务器的通信。每个 JMS 服务器都处理一组目标的请求。不由 JMS 服务器处理的目标请求则转发给适当的服务器。
WebLogic Server 为客户端连接提供了服务器关系。如果应用程序具有到给定服务器实例的连接，JMS 则会尝试建立到同一个服务器实例的新 JMS 连接。
创建连接时，JMS 会首先尝试获得初始上下文关系。它将尝试连接到客户端已为其初始上下文连接的同一个或多个服务器（假设为该连接工厂配置了服务器实例）。例如，如果为服务器 A 和 B 配置了连接工厂，但是客户端在服务器 C 上具有初始上下文，则该连接工厂不会建立与 A 的新连接，而会在服务器 B 和 C 之间选择。
如果连接工厂无法获得初始上下文关系，它则尝试为客户端已经连接的服务器提供关系。例如，假设客户端在服务器 A 上具有初始上下文，并且具有到服务器 B 的某些其他类型的连接。然后如果客户端使用为服务器 B 和 C 配置的连接工厂，则它不会获得初始上下文关系。而连接工厂会尝试创建到服务器 B（连接工厂已经与之具有连接）的连接，而不会创建到服务器 C 的连接，来获得服务器关系。
如果连接工厂不能提供初始上下文关系也不能提供服务器关系，该连接工厂则不用在任何可能的位置创建连接。例如，假设客户端在服务器 A 上具有初始上下文，没有任何其他连接，还具有为服务器 B 和 C 配置的连接工厂。该连接工厂无法提供任何关系，并且不用尝试创建到服务器 B 或 C 的新连接。
| 注意： | 在最后一种情况下，如果客户端尝试使用同一个连接工厂创建第二个连接，则它会转至第一次创建连接时的同一个服务器。即，如果它对于第一个连接选择了服务器 B，则在创建第二个连接时，该客户端将具有到服务器 B 的连接，并且会强制使用服务器关系规则。 |
JDBC 连接的负载平衡需要使用为负载平衡配置的多数据源。负载平衡支持是配置多数据源时可以选择的选项。
负载平衡多数据源提供了故障转移和 JDBC 连接中描述的高可用性行为，另外，还会在该多数据源中的多个数据源之间平衡负载。多数据源具有它所包含的数据源的顺序列表。如果未配置用于负载平衡的多数据源，它则总是尝试从列表中的第一个数据源获取连接。在负载平衡多数据源中，将使用循环法方案访问它所包含的数据源。在多数据源连接的每个后续客户端请求中，该列表都会旋转，以便第一个共享池会接触该列表中的循环。
有关群集 JDBC 对象的说明，请参阅配置群集的 JDBC。
  
|
