WebLogic 群集中的负载平衡

文章参考https://docs.oracle.com/middleware/1221/wls/CLUST/load_balancing.htm#CLUST171

Servlet和JSP的负载平衡

使用代理插件进行负载平衡
WebLogic代理插件维护托管群集Servlet或JSP的WebLogic Server实例列表，并以循环方式将HTTP请求转发到这些实例。循环负载平衡中介绍了这种负载平衡方法。

如果WebLogic Server实例失败，该插件还提供了定位客户端HTTP会话状态的副本所必需的逻辑。
WebLogic Server支持以下Web服务器和关联的代理插件：
-WebLogic Server与 HttpClusterServlet
-带有Netscape（代理）插件的Netscape Enterprise Server
-带有Apache服务器（代理）插件的Apache
-带有Microsoft-IIS（代理）插件的Microsoft Internet信息服务器

使用外部负载均衡器进行负载均衡HTTP会话
采用硬件负载平衡解决方案的群集可以使用硬件支持的任何负载平衡算法。这些可以包括高级的基于负载的平衡策略，该策略可监视单个计算机的利用率。

除了分配HTTP流量外，外部负载平衡器还可以分配来自Java客户端的初始上下文请求t3以及默认通道。

负载均衡器配置要求
如果选择使用负载平衡硬件而不是代理插件，则它必须支持兼容的被动或主动cookie持久性机制以及SSL持久性。

-被动Cookie持久性
被动cookie持久性使WebLogic Server可以通过负载平衡器将包含会话参数信息的cookie写入客户端。

-主动Cookie持久性
您可以将某些活动的cookie持久性机制与WebLogic Server群集一起使用，只要负载均衡器不修改WebLogic Server cookie。WebLogic Server群集不支持覆盖或修改WebLogic HTTP会话cookie的活动cookie持久性机制。如果负载平衡器的活动cookie持久性机制通过将其自己的cookie添加到客户端会话来工作，则无需额外配置即可将负载平衡器与WebLogic Server群集一起使用。

-SSL持久性
使用SSL持久性时，负载平衡器将执行客户端和WebLogic Server群集之间的所有数据加密和解密。然后，负载平衡器使用WebLogic Server在客户端上插入的纯文本cookie来维护客户端与群集中特定服务器之间的关联。

负载平衡器和WebLogic会话Cookie
使用被动cookie持久性的负载平衡器可以在WebLogic会话cookie中使用字符串，以将客户端与托管其主要HTTP会话状态的服务器相关联。该字符串唯一地标识集群中的服务器实例。您必须使用字符串常量的偏移量和长度来配置负载均衡器。偏移量和长度的正确值取决于会话cookie的格式。

会话cookie的格式为：
sessionid!primary_server_id!secondary_server_id
sessionid是HTTP会话的随机生成的标识符。值的长度由weblogic.xml应用程序文件中元素中的IDLength参数配置。默认情况下，长度为52个字节。
primary_server_id并且secondary_server_id是用于会话的主要和次要主机的10个字符的标识符。

 

EJB和RMI对象的负载平衡

在为群集对象获取的副本感知存根中维护对象的负载平衡算法。

默认情况下，WebLogic Server群集使用循环负载平衡，如循环负载平衡中所述。您可以使用WebLogic Server管理控制台进行设置，从而为群集配置其他默认负载平衡方法weblogic.cluster.defaultLoadAlgorithm。

除了标准的负载平衡算法，WebLogic Server还支持基于自定义参数的路由。
而且，外部负载平衡器可以通过t3默认通道分配来自Java客户端的初始上下文请求。但是，由于EJB和RMI对象的WebLogic Server负载平衡是通过感知副本的存根控制的，包括采用服务器亲缘关系的情况，因此，您不应在初始上下文请求之后通过负载平衡器路由客户端请求。将t3协议与外部负载平衡器一起使用时，必须确保仅通过负载平衡器路由初始上下文请求，并确保使用WebLogic Server负载平衡路由和控制后续请求。

Oracle建议不要将t3s协议与外部负载平衡器一起使用。如果需要将t3 SSL和SSL与外部负载均衡器一起使用，则Oracle建议t3通过HTTPS 使用隧道。如果需要服务器关联，则必须将HTTP会话ID用于路由请求，并且必须在执行基于会话的路由的负载均衡器处终止SSL，以启用基于会话ID的请求的适当路由。

循环负载均衡
如果未指定算法，则WebLogic Server将循环算法用作群集对象存根的默认负载平衡策略。RMI对象和EJB支持此算法。这也是WebLogic代理插件使用的方法。

循环算法按顺序循环浏览WebLogic Server实例列表。对于群集对象，服务器列表由承载群集对象的WebLogic Server实例组成。对于代理插件，该列表由承载群集servlet或JSP的所有WebLogic Server实例组成。

循环算法的优点是它简单，便宜且非常可预测。主要的缺点是有一定的护航的机会。当一台服务器的速度明显慢于其他服务器时，就会发生同步迁移。由于可识别副本的存根或代理插件以相同的顺序访问服务器，因此速度较慢的服务器可能导致请求在服务器上“同步”，然后跟随其他服务器以便将来发出请求。

基于权重的负载平衡
该算法仅适用于EJB和RMI对象集群。

通过考虑为每个服务器预先分配的权重，基于权重的负载平衡改进了循环算法。您可以使用WebLogic Server管理控制台中的“ 服务器” >“ 配置” >“ 群集”页面在群集中为群集中的每个服务器分配1到100之间的数字权重。Cluster Weight领域。该值确定服务器相对于其他服务器将承担的负载比例。如果所有服务器的权重相同，则它们各自将承担相等比例的负载。如果一台服务器的权重为50，而其他所有服务器的权重为100，则50权重的服务器将承担任何其他服务器的一半的重量。该算法可以将循环算法的优势应用于不均一的聚类。
如果使用基于权重的算法，请仔细确定要分配给每个服务器实例的相对权重。要考虑的因素包括：
服务器硬件相对于其他服务器的处理能力（例如，WebLogic Server专用的CPU的数量和性能）。
每个服务器托管的非群集（“固定”）对象的数量。

随机负载平衡
负载平衡的随机方法仅适用于EJB和RMI对象集群。

在随机负载平衡中，请求被随机路由到服务器。仅对于均质集群部署建议使用随机负载平衡，在均质集群部署中，每个服务器实例都在配置类似的计算机上运行。请求的随机分配不允许服务器实例在其上运行的机器之间的处理能力差异。如果托管群集中服务器的计算机的处理能力明显低于群集中其他计算机，则随机负载平衡将为功能较弱的计算机提供与功能更强大的计算机一样多的请求。
随机负载平衡会在集群中的服务器实例之间平均分配请求，并且随着请求的累积数量的增加而越来越多。在少量请求中，负载可能无法完全均匀地平衡。
随机负载平衡的缺点包括为每个请求生成一个随机数而导致的处理开销很小，以及在少量请求上负载无法均衡平衡的可能性。

服务器相似性负载平衡算法
WebLogic Server为RMI对象提供了三种负载平衡算法，这些算法提供服务器相似性。服务器关联性会关闭外部客户端连接的负载平衡；相反，客户端在选择访问对象的服务器实例时会考虑其与WebLogic Server实例的现有连接。如果将对象配置为具有服务器亲缘关系，则客户端存根将尝试选择该对象已连接到的服务器实例，并继续使用同一服务器实例进行方法调用。该客户端上的所有存根都尝试使用该服务器实例。如果服务器实例不可用，则存根（如果可能）故障转移到客户端已连接到的服务器实例。

服务器相似性的目的是最大程度地减少在集群中外部Java客户端和服务器实例之间打开的IP套接字的数量。WebLogic Server通过使对象上的方法调用“粘贴”到现有连接上，而不是在可用服务器实例之间实现负载平衡来实现此目的。使用服务器亲缘关系算法，仍然可以根据配置的负载平衡算法对成本较低的服务器到服务器的连接进行负载平衡-仅针对外部客户端连接禁用负载平衡。

服务器相似性与以下标准负载平衡方法之一结合使用：循环，基于权重或随机：

round-robin-affinity-服务器相似性控制外部Java客户端与服务器实例之间的连接；循环负载平衡用于服务器实例之间的连接。
基于权重的加权-服务器相似性控制外部Java客户端和服务器实例之间的连接；基于权重的负载平衡用于服务器实例之间的连接。
random-affinity-服务器相似性控制外部Java客户端与服务器实例之间的连接；随机负载平衡用于服务器实例之间的连接。

服务器亲和力和初始上下文
客户端可以从群集中的特定服务器实例，或者通过在URL中指定群集地址，从群集请求初始上下文。连接过程根据获取上下文的方式而有所不同：

如果从特定的受管服务器请求了初始上下文，则使用与指定服务器实例的新连接来获取上下文。

如果从群集请求初始上下文，则默认情况下，上下文请求将在群集服务器实例之间以循环方式进行负载平衡。要重用特定JVM与集群之间的现有连接，请在获取上下文时在指定ENABLE_SERVER_AFFINITY的weblogic.jndi.WLContext属性的哈希表中将其设置为true 。（如果连接不可用，则会创建一个新的连接。）ENABLE_SERVER_AFFINITY仅当从群集地址请求上下文时才受支持。

循环亲和力，基于权重的亲和力和随机亲和力
WebLogic Server具有三种负载平衡算法，可以提供服务器关联性：

循环亲和力
基于权重的亲和力
随机亲和力

所有类型的RMI对象（包括JMS对象，所有EJB本地接口和无状态EJB远程接口）都支持服务器相似性。
服务器相似性算法考虑了外部Java客户端与服务器实例之间的现有连接，以平衡WebLogic Server实例之间的客户端负载。服务器关联性：

关闭外部Java客户端和服务器实例之间的负载平衡
假定外部连接支持必要的协议和QOS，则导致来自外部Java客户端的方法调用坚持到该客户端具有打开连接的服务器实例
在发生故障的情况下，假设连接支持必要的协议和QOS，则导致客户端故障转移到其具有打开的连接的服务器实例
不影响服务器到服务器连接执行的负载平衡。

服务器关联性示例
以下示例说明了在各种情况下服务器相似性的影响。在每个示例中，将部署的对象配置为循环关联。

示例1-来自集群的上下文
在图所示的示例中，客户端从群集获取上下文。在上下文和对象调用上的查找停留在单个连接上。对新的初始上下文的请求将按循环负载平衡。

1. 客户端从群集（Provider_URL=clusteraddress）请求一个新的初始上下文，并从MS1获得该上下文。
2. 客户端对对象A的上下文进行查找。查找转到MS1。
3. 客户端发出对对象A的调用。该调用转到客户端已连接到的MS1。对对象A的其他方法调用将坚持MS1。
4. 客户端从群集（Provider_URL=clusteraddress）请求一个新的初始上下文，并从MS2获取该上下文。
5. 客户端在对象B的上下文中进行查找。调用转到客户端已连接到的MS2。对对象B的其他方法调用将保留在MS2中。

示例2 —服务器关联性和故障转移
在所示的例子中图示出了服务器的亲和力对对象故障转移的影响。当受管服务器发生故障时，客户端将故障转移到与其连接的另一台受管服务器。

1. 客户端从MS1请求新的初始上下文。
2. 客户端对对象A的上下文进行查找。查找转到MS1。
3. 客户端调用对象A。该调用转到客户端已连接到的MS1。对对象A的其他调用将保留到MS1。
4. 客户端将获得对象C的存根，该存根被固定到MS3。客户端打开与MS3的连接。
5. MS1失败。
6. 客户端调用对象A。客户端不再具有与MS1的连接。因为客户端连接到MS3，所以它将故障转移到MS3上的对象A的副本。

示例3 —服务器关联性和服务器到服务器的连接
在所示的例子中图示出了一个事实，即服务器亲和力不会影响服务器实例之间的连接。

1. MS4上的JSP获得对象B的存根。
2. JSP选择MS1上的副本。对于每个方法调用，JSP以循环方式在对象B可用的受管服务器之间循环。

集群对象的基于参数的路由
基于参数的路由使您可以在较低级别上控制负载平衡行为。可以为任何群集对象分配一个CallRouter。这是一个在每次调用之前使用调用参数调用的类。该CallRouter免费检查参数和返回名称服务器了呼叫应被路由。

优化并置对象
WebLogic Server并不总是负载均衡对象的方法调用。在大多数情况下，使用与存根本身并置的副本比使用驻留在远程服务器上的副本更为有效。

在此示例中，客户端连接到群集中第一个WebLogic Server实例托管的servlet。响应客户端活动，该servlet获取对象A的副本感知存根。由于对象A的副本也可在同一服务器实例上使用，因此该对象与客户端存根并置。

WebLogic Server始终使用对象A的本地并置副本，而不是将客户端的调用分发到群集中对象A的其他副本。使用本地副本效率更高，因为这样做避免了建立与群集中其他服务器的对等连接的网络开销。

在规划WebLogic Server群集时，常常忽略了这种优化。对于希望或需要在每个方法调用上实现负载平衡的管理员或开发人员，并置优化也经常使他们感到困惑。如果将Web应用程序部署到单个群集，则并置优化将覆盖副本感知存根中固有的任何负载平衡逻辑。

交易搭配
作为基本并置策略的扩展，WebLogic Server尝试使用被并置为同一事务一部分的并置群集对象。客户端创建UserTransaction对象时，WebLogic Server尝试使用与事务并置的对象副本。下图的示例描述了这种优化。

在此示例中，客户端将附加到群集中的第一个WebLogic Server实例并获得一个UserTransaction对象。开始新事务后，客户端将查找对象A和B来完成事务工作。在这种情况下UserTransaction，无论A和B存根中的负载平衡策略如何，WebLogic Server始终尝试使用与对象驻留在同一服务器上的A和B的副本。

这种事务配置策略比“优化并置对象”中描述的基本优化更为重要。如果使用A和B的远程副本，则在事务期间将增加网络开销，因为A和B的对等连接将被锁定，直到事务提交为止。WebLogicServer。通过在事务期间使用并置群集对象，WebLogic Server减少了访问单个对象的网络负载。

XA交易群集关联
XA事务集群相似性允许参与全局事务的服务器实例为相关请求提供服务，而不是将这些请求负载平衡到其他成员服务器。当为时Enable Transaction Affinity=true，集群吞吐量通过以下方式增加：

减少服务器间事务协调流量
提高资源利用率，例如减少JDBC连接
简化事务的异步处理

如果群集没有成员参与事务，则请求将负载平衡到可用的群集成员。如果选定的群集成员失败，则可以使用配置JTA事务恢复服务的自动迁移路线图来迁移JTA事务恢复服务。

JMS的负载平衡
WebLogic Server JMS支持对分布式JMS目标和客户端连接的服务器关联。
默认情况下，WebLogic Server群集使用轮询方法来负载均衡对象。要使用为JMS对象提供服务器关联性的负载平衡算法，必须为整个集群配置所需的方法。您可以使用WebLogic Server管理控制台进行设置来配置负载平衡算法weblogic.cluster.defaultLoadAlgorithm。

分布式JMS目标的服务器相似性
使用分布式目标功能的JMS应用程序支持服务器关联。独立目标不支持此功能。如果为JMS连接工厂配置服务器亲缘关系，则在分布式目标的多个成员之间对使用方或生产方进行负载平衡的服务器实例将首先尝试在同一服务器实例上运行的所有目标成员之间进行负载平衡。

客户端连接的初始上下文关联和服务器关联
系统管理员可以通过配置多个JMS服务器并将目标分配给已定义的WebLogic Server，从而在群集中的多个服务器之间建立JMS目标的负载平衡。每个JMS服务器都恰好部署在一个WebLogic Server上，并处理对一组目标的请求。在配置阶段，系统管理员通过为JMS服务器指定目标来启用负载平衡。有关设置目标的说明，请参阅为固定服务配置可迁移目标。有关将JMS服务器部署到可迁移目标的说明，请参阅部署，**和迁移可迁移服务。

系统管理员可以通过配置多个连接工厂并使用目标将它们分配给WebLogic Server，从而从集群中的任何服务器建立对集群范围内的目标的透明访问。每个连接工厂都可以部署在多个WebLogic Server上。在为Oracle WebLogic Server开发JMS应用程序中的“ ConnectionFactory”中更详细地描述了连接工厂。

该应用程序使用Java命名和目录接口（JNDI）查找连接工厂并创建连接以建立与JMS服务器的通信。每个JMS服务器都处理对一组目标的请求。JMS服务器未处理的目的地请求将转发到适当的服务器。

WebLogic Server为客户端连接提供服务器关联。如果应用程序具有到给定服务器实例的连接，则JMS将尝试建立到同一服务器实例的新JMS连接。

创建连接时，JMS将首先尝试实现初始上下文关联。假定已为该连接工厂配置了服务器实例，它将尝试连接到客户端为其初始上下文连接的同一台服务器。例如，如果为服务器A和B配置了连接工厂，但是客户端在服务器C上具有InitialContext，则连接工厂将不会与A建立新连接，而是在服务器B和C之间进行选择。

如果连接工厂无法实现初始上下文关联，它将尝试向客户端已连接到的服务器提供关联。例如，假设客户端在服务器A上具有InitialContext，并且具有与服务器B的其他某种类型的连接。如果客户端随后使用为服务器B和C配置的连接工厂，则它将无法实现初始上下文关联。相反，连接工厂将通过尝试创建与服务器B的连接来实现服务器亲缘关系，该服务器已经与其建立了连接，而不是服务器C。

如果连接工厂无法提供初始上下文相似性或服务器相似性，则连接工厂可以自由地建立连接。例如，假设客户端在服务器A上具有初始上下文，没有其他连接，并且为服务器B和C配置了连接工厂。连接工厂无法提供任何亲缘关系，可以自由尝试与服务器B或C建立新连接。