设置 FMW 拉伸集群

本手册使用 Oracle Cloud Infrastructure (OCI) 作为部署 Oracle Fusion Middleware 拉伸集群的示例基础结构。

提供特定于 OCI 基础结构的步骤可以更好地反映 Oracle Fusion Middleware 延伸集群实施所需的配置和更改。然而，对于使用其他负载平衡器、网络、硬件和存储基础设施的内部部署系统，可以推断提供的所有注意事项和步骤。使用本书中提供的 OCI 示例作为参考，在每种情况下参考特定于供应商的详细信息。

设置区域

Oracle Fusion Middleware (FMW) 拉伸集群模型配置在两个独立的站点之间。

在 Oracle Cloud Infrastructure (OCI) 中，您可以在彼此之间延迟低的 OCI 区域中实施该解决方案。支持的最大区域间延迟为 10 毫秒往返时间 (Round-Trip Time，RTT)。您可以通过依次选择 Networking 、 Network Command Center 和 Inter-region latency 来检查 OCI Console 中区域之间的延迟。

考虑到延迟值，您可以在具有 6-7 毫秒 RTT 的法兰克福和阿姆斯特丹等区域之间部署此模型。但是，您无法在阿什本和菲尼克斯等地点之间部署此模型，因为这些区域之间的延迟超过了 50 毫秒 RTT。

区域间延迟低于 10 毫秒 RTT 的区域对示例：

  • 阿姆斯特丹 (AMS) - 巴黎 (CDG)

  • 阿姆斯特丹 (AMS) - 纽波特 (CWL)

  • 阿姆斯特丹 (AMS) - 法兰克福 (FRA)

  • 阿姆斯特丹 (AMS) —伦敦 (LHR)

  • 巴黎 (CDG) - 法兰克福 (FRA)

  • 巴黎 (CDG) - 伦敦 (LHR)

  • 巴黎 (CDG) - 纽波特 (CWL)

  • 马赛 (MRS) - 米兰 (LIN)

  • 苏黎世 (ZHR) - 法兰克福 (FRA)

  • 苏黎世 (ZHR) - 米兰 (LIN)

  • 大阪 (KIX) - 东京 (NRT)

  • 新加坡 (SIN) - 巴淡 (HSG)

  • 圣保罗 (GRU) - 维涅杜 (VCP)

  • 新加坡 (SIN) - 新加坡 2 (XSP)

  • 巴坦 (HSG) - 新加坡 2 (XSP)

  • 首尔 (ICN) - 春川 (YNY)

  • 多伦多 (YYZ) - 蒙特利尔 (YUL)

关于带宽，OCI 区域之间没有保证的带宽，OCI 不提供特定的 OCI 带宽测量工具。要进行精确的带宽测量，请使用 iPerf 等工具。法兰克福和阿姆斯特丹之间经过测试的带宽约为每秒 2-2.5 千兆位 (Gbps)。

您还可以在位于同一区域的可用性域 (Availability Domain，AD) 之间实施此模型。实际上，跨 AD 部署 Oracle WebLogic Server 服务器是平台即服务 (PaaS) 服务中的标准行为，例如 Oracle SOA Suite on Marketplace 和 Oracle WebLogic Server for OCI 堆栈。然而，跨 AD 而非跨区域实施此模型并非真正的灾难保护解决方案，因为它无法防范影响整个区域的事件。

提示：

要在每个站点中创建 FMW 部署所需的子网、规则、计算实例、共享存储和负载平衡器，可以使用 WLS-HYDR 框架（请参阅“创建基础结构”过程）。

设置网络

部署此拓扑的区域中的虚拟云网络 (Virtual Cloud Network，VCN) 必须互连，以允许集群中所有 WebLogic 服务器之间以及从 WebLogic 服务器到数据库的流量。

此设置需要以下联网功能：

  • 每个区域中的 VCN 和分层子网。
  • VCN 之间具有动态路由网关 (dynamic routing gateways，DRG) 的远程对等连接。
  • 用于在站点之间路由流量的相应路由规则。在区域 1 中，路由表应包括通过动态路由网关到区域 2 VCN CIDR 的路由。同样，区域 2 路由表应包括通过动态路由网关到区域 1 VCN CIDR 的路由。
  • 用于允许对拉伸的群集进行以下通信的网络安全规则：
    • 在区域 1 和区域 2 的中间层子网之间打开 WebLogic Server 和节点管理器端口。如果使用 Coherence，则允许 Coherence 端口的 TCP 和 UDP 流量。
    • 允许从区域 1 和区域 2 的中间层子网传输到两个区域中的数据库监听程序和 Oracle Cloud Infrastructure Notifications (ONS) 端口的流量。
    • 默认情况下，OHS 和 WebLogic 服务器之间无需进行跨区域通信。中间层子网中的 WebLogic Server 端口只能从同一区域内的 OHS 服务器访问。但是，在特殊情况下可能需要跨区域通信，例如某个区域中的所有 Web 服务器均发生故障。在“管理故障”部分中提供了更多详细信息。
  • 系统使用的所有主机名（WebLogic 侦听地址以及主数据库和备用数据库 SCAN 和 VIP 地址）必须可以从两个站点进行解析。默认情况下，在 OCI 中，只能在每个 VCN 内解析主机名。要允许在区域 2 中解析区域 1 名称，请在区域 2 中为区域 1 域创建专用 DNS 视图，并添加相关名称和 IP 地址。在区域 1 中重复此过程以解析区域 2 中的名称。
  • 在每个站点上，系统的前端名称（例如 frontend.example.com）应指向本地负载平衡器的 IP 地址。要实现此目的，请将前端名称添加到每个区域中的专用 DNS 视图或中层主机的 /etc/hosts 文件。这可确保从 WebLogic 服务器到前端的任何回调都定向到本地区域。

为数据库设置

在区域 1 中设置 Oracle Real Application Clusters (Oracle RAC) 数据库系统，并在区域 2 中设置备用 RAC 数据库系统。

在每个区域内使用 RAC 非常重要，因为本地高可用性是一项关键要求。仅当在单个区域中已经具备针对本地故障的可靠保护时，配置跨可用性域 (AD) 或跨区域保护才有效。如果未实施本地高可用性（例如 RAC 提供的高可用性），则在多个 AD 或区域之间添加保护并不会解决本地环境中的故障风险。

要在 RAC 数据库节点或实例发生故障时保持应用程序连接并接收 Oracle Notification Service 通知，请确保您的应用程序使用集群就绪服务 (Cluster Ready Services，CRS) 数据库服务连接到可插入数据库 (pluggable database，PDB) 。主数据库和备用数据库必须存在相同的 CRS 服务。用于创建连接到 PDB 的服务的示例命令： 


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

设置共享存储

Oracle Cloud Infrastructure File Storage 是 OCI 提供的完全托管、可扩展且安全的文件系统服务。它旨在为需要共享和持久性文件系统的企业应用提供高性能文件存储。

多个计算实例可以同时通过网络文件系统 (Network File System，NFS) 协议挂载和访问同一文件系统。

OCI 中的 Oracle Fusion Middleware (FMW) 拉伸集群模型将每个区域中的 OCI File Storage 系统用于共享文件系统（例如，共享配置或共享运行时数据）。OCI 文件存储在该区域内提供高可用性：它在内部在一个可用性域内的多个容错域中使用冗余存储。但是，无法跨区域访问 OCI File Storage 。因此，共享存储是该区域的本地存储。

在区域之间使用本地备份和文件系统副本来提供对象的可恢复副本。

设置中间层

中间层计算节点分布在两个区域中。

中间层计算节点分布在两个区域中，其中一半节点位于区域 1 中，另一半位于区域 2 中。预配和安装过程与创建单个 WebLogic 域时相同。要实施高可用性功能（例如 Java Message Service (JMS) 和 Java 事务处理 API (JTA) 服务迁移、管理服务器故障转移、使用节点管理器自动检测崩溃等），请使用“浏览更多”部分中引用的 FMW Enterprise Deployment Guides 中建议的最佳实践。

您可以从一开始就创建域并使用所有托管服务器进行配置，也可以通过在另一个区域中添加节点来扩展在单个区域中运行的现有域。

注意：

Oracle Fusion Middleware (FMW) 拉伸集群模型可以应用于使用平台即服务 (PaaS) 服务创建的域，例如 Oracle WebLogic Server for OCI 和 Oracle SOA Suite on Marketplace 堆栈。默认情况下，这些 PaaS 服务的预配和横向扩展功能仅支持单个区域；因此，您需要手动横向扩展集群以在另一个区域中添加节点。有关执行此操作所需的步骤，请参阅扩展 WLS 群集的过程。请注意，这些 PaaS 服务不包括 Web 层，并且不实施某些高可用性最佳做法，例如管理服务器故障转移。因此，本文档中的一些建议可能不适用于这些环境。

以下是在使用 FMW 拉伸群集模型时要在 WebLogic 配置中实施的最相关方面：

  • 使用数据库持久性存储

    Oracle 支持将数据库持久性存储用于 Oracle WebLogic Server 事务处理日志和 JMS 的拉伸集群。在数据库中存储事务处理日志和持久性数据可利用数据库的内置复制和高可用性功能，例如 Oracle Real Application Clusters (Oracle RAC) 和 Oracle Data Guard 。使用 JMS、事务处理日志 (TLOG) 和 Data Guard 保护数据库中的元数据，可以简化跨站点同步，并保证应用程序级别的一致性。这也意味着中间层不再需要这些构件的共享存储（尽管它仍然需要用于管理服务器故障转移，部署计划和一些适配器，如文件适配器）。

    但是，在数据库中使用 TLOG 和 JMS 会影响系统的性能。当中间层之一需要与另一站点上的数据库交叉通信时，会增加此处罚。从性能的角度来看，每个站点本地的共享存储将具有更好的性能，但这引入了复杂性和限制，以确保区域之间零数据丢失和应用程序一致性。

  • 每个区域的本地共享文件系统对象

    如 Oracle Fusion Middleware Enterprise Deployment Guides 中所示，管理服务器域目录 (ASERVER_HOME) 应位于与托管服务器的域文件夹 (MSERVER_HOME) 分隔的共享存储上。这与使用管理服务器监听地址的虚拟主机名一起，允许管理服务器故障转移到同一区域或不同区域中的另一台主机。

    驻留在共享文件系统中的其他对象包括 Oracle 主目录安装（二进制文件）、部署计划和文件适配器目录（运行时文件夹）。

    在 FMW 拉伸群集拓扑中，每个区域都使用自己的本地共享存储。因此，第二个区域维护自己的冗余二进制文件（确保每个站点至少安装两个二进制文件以实现高可用性）和共享配置、部署计划、运行时文件等的自己的共享目录。所有这些构件必须跨两个区域使用相同的路径，以确保一致性和无缝故障转移。

  • 对 WebLogic 集群使用基于关联性的算法
    要最大限度地减少跨站点流量，请使用本地关联来解析 Java Naming and Directory Interface (JNDI) 上下文工厂。要将 WebLogic 集群的默认加载算法设置为基于关联性的算法，请执行以下操作：
    1. 转到 WebLogic Remote Console 中的 Edit Tree 。
    2. 转到 Environment（环境），选择 Clusters（群集）并选择群集。
    3. 在常规选项卡中，将 WebLogic 集群的默认加载算法设置为循环关联（默认值为循环）或任何“基于关联”的算法。

    不需要使用群集中的所有服务器的显式列表设置 Cluster Address 。当为空时，将自动生成“群集地址”值。只需确保属性 Number of Servers in Cluster Address （限制自动生成群集地址时要列出的服务器数）的值足够高，可以包括群集中的所有服务器。

  • 使用自动服务迁移配置

    Oracle 建议为企业部署拓扑配置自动服务迁移以及 Java 数据库连接 (JDBC) 持久性存储。在 FMW 拉伸集群拓扑中，只要可从两个站点访问 JMS 和 TLOG 数据，就可以在区域内和跨区域进行自动服务迁移。使用 JDBC 持久性存储时，在拉伸集群中配置 ASM 不需要特殊注意事项。

    当站点之间存在高延迟时，从区域 1 到区域 2 的服务迁移操作所用的时间可能会增加。这种增加是由于在其他服务器中恢复消息所花费的时间，因为这些消息是从其他区域数据库中的持久性存储中读取的。此延迟随持久性存储中的暂挂消息数而增加。但是，只有在延迟很高或有大量待处理消息的情况下，处罚才会变得相关。有关预期行为的详细信息，请参阅“复核绩效数据”部分。

  • 前端主机名和解析

    为 WebLogic 群集配置前端主机时，请指定客户机用于访问系统的虚拟主机名，如同在任何标准部署中一样。客户机应将此虚拟主机名解析为在区域 1 和区域 2 中的 OCI Load Balancer 实例之间平衡的外部地址。请参见“关于全局负载平衡”。

    要确保每个区域中的 WebLogic 服务器仅将内部调用路由到其各自的本地 OCI Load Balancer ，请将服务器配置为将前端主机名解析为其区域内的 OCI Load Balancer 的 IP 地址。这可以通过将条目添加到每个 WebLogic 服务器主机上的 /etc/hosts 文件中或将条目添加到每个区域中的 DNS 专用视图来实现：

    对于区域 1 中的服务器：

    [IP address of Region 1 OCI Load Balancer] [frontend hostname]

    对于区域 2 中的服务器：

    [IP address of Region 2 OCI Load Balancer] [frontend hostname]

    此配置可确保来自 WebLogic 服务器的内部通信定向到相应的区域负载平衡器，从而优化路由和性能。

设置 WebLogic 数据源

在所有 WebLogic 数据源（对于 Oracle Fusion Middleware (FMW) 元数据、数据库持久性存储、租赁表、数据库适配器等）中使用具有双连接字符串的 GridLink 数据源来自动执行数据库故障转移。当 Oracle Real Application Clusters (Oracle RAC) 的其中一个节点出现故障或关闭时，以及数据库完全切换到其他区域时，它们应自动重新连接。为此，请应用以下建议：

  • 使用 GridLink 数据源

    GridLink 数据源利用 Oracle Notification Service (ONS) 快速检测和响应数据库节点故障或网络中断，从而提高应用可用性和弹性。它们会根据实时工作负载信息自动分配数据库连接，从而在所有 RAC 节点中优化性能和资源使用情况。数据库拓扑中的更改（例如添加或删除 RAC 节点）会自动识别和处理，从而减少管理开销并减少停机时间。

    您无需在 GridLink 数据源配置中手动指定 ONS 主机和端口。ONS 列表由数据库自动提供给驱动程序，驱动程序会检索主数据库和备用数据库的 ONS 信息，从而促进与两者的连接。

  • 使用 TNS 别名

    在数据源的连接字符串中，使用指向 tnsnames.ora 文件中的条目的 TNS 别名，该别名包括主 SCAN 地址和备用 SCAN 地址。建议的连接字符串格式如下所示，其中包含一个说明和两个地址列表，每个 RAC 数据库一个： 

    PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)

    有关如何在数据源和 FMW 配置文件中配置 TNS 别名的更多详细信息，请参阅 Enterprise Deployment Guide for Oracle SOA Suite 中的 Using TNS Alias in Connect Strings 。

  • 使用 Test Connections on Reserve（保留时测试连接）选项

    确保为所有数据源启用了保留时测试连接选项。这对于用于访问持久性存储的数据源尤为重要，因为持久性存储对于 WebLogic 服务器的整体状态至关重要。此标志允许 WebLogic 服务器在将连接提供给应用程序之前对其进行测试。

    对于测试表名，请使用默认值 SQL ISVALID 。这是一个快速高效的测试，因为它执行轻量级验证来确定数据库连接是否仍处于活动状态，而无需访问特定的物理表。

  • 优化初始容量

    当 WebLogic 服务器启动时，将花费大量时间专门为数据源池创建初始连接。根据数据源中的初始容量设置，预计会出现不同的延迟。默认情况下，大多数 FMW 数据源对其连接池使用零初始容量。但是，为了在正常运行时操作期间缩短系统的响应时间，可能会增加初始池容量。

    由于初始容量是在数据源（连接池）级别配置的，因此这些设置会影响集群内所有服务器（数据库本地服务器和远程服务器）的启动时间。在 FMW 拉伸集群中，那些从数据库远程驻留的服务器在启动时会显示延迟增加，因为使用了更高的初始池容量（请参见“查看启动时间”）。因此，需要在正常运行期间优化响应时间和最小化开始时间以确定理想的初始容量设置之间做出平衡的决定。
  • 优化最大容量

    活动数据源连接数随数据库延迟增加而增加。在执行的测试中，远程区域中的服务器显示的活动连接数多于与数据库关联的服务器（请参见“查看压力测试”）。2x 监视应用程序中的使用情况，并考虑正确调整 WebLogic 数据源和数据库会话的大小。

设置 Web 服务器

如果系统在 Oracle HTTP Server 实例中使用 Web 层，则每个区域必须至少具有两台服务器才能在该区域内提供高可用性。

要减少跨区域的流量，请勿使用 Oracle WebLogic Server 路由部分中的动态服务器列表配置。而是配置服务器的静态列表，将参数 DynamicServerList 设置为 OFF。这有一个更慢的故障检测警告：当 WebLogic 服务器崩溃时，HTTP 服务器需要比动态列表更长时间来检测故障。此外，如果添加了新服务器，则需要在配置中更新。但是，它确实提高了系统的性能。

Oracle HTTP Server 中 mod_wl_ohs.conf 文件的以下摘录提供了路由到 soa-infra Web 应用程序所需的配置示例。

在区域 1 中：

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

在区域 2：

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

设置负载均衡器

每个区域都必须有自己的负载平衡器，才能在该站点内的服务器之间分配请求。

在两个区域中为每个负载平衡器配置具有相同 SSL 证书的监听程序。设置后端服务器，以便区域 1 中的负载平衡器包括区域 1 中的 Oracle HTTP Server (OHS) 实例（如果系统不使用 Web 服务器，则支持的服务器为 WebLogic）区域 1 中的服务器和区域 2 中的负载平衡器包括区域 2 中的 OHS 服务器（如果系统不使用 Web 服务器，则后端服务器是区域 2 中的 WebLogic 服务器）。

使用准确反映应用程序状态的 URL 配置运行状况检查以确定后端服务器的可用性。这可防止流量路由到运行 Oracle WebLogic Server 但应用程序本身不可用（如果运行状况检查仅以根上下文 (/) 为目标）的服务器。但是，请避免使用资源密集型运行状况检查，因为频繁的重检查可能会使支持的服务器超载。例如，对于 Oracle SOA ，建议的健康检查 URL 为 /soa-infra/services/isSoaServerReady 。

关于全局负载平衡

Oracle Fusion Middleware (FMW) 拉伸集群模型需要在每个数据中心的负载平衡器上有一个元素，以便在两个区域之间平衡客户端的请求。

在内部部署实施中，传统上使用全局负载平衡器来实现这一点，该平衡器负责智能路由，通常基于源的 IP 地址。此全局负载平衡器通常位于其中一个站点中，在另一个站点中有一个备份用于故障转移。

在 Oracle Cloud Infrastructure (OCI) 中，没有专用的全局负载均衡器服务。但是，您可以使用流量管理策略来实现全局负载平衡功能。

将 OCI 流量管理引导策略用作全局负载平衡器

使用 Oracle Cloud Infrastructure (OCI) 流量管理引导策略在两个站点之间对客户端流量进行负载平衡。

流量管理引导策略为域名系统 (Domain Name System，DNS) 查询提供智能响应，这意味着可能会根据策略中定义的逻辑为查询提供不同的答案。有多种策略类型：

  • 负载平衡器策略

    负载平衡器策略会在许多端点之间分配流量。可以为端点分配相等的权重以在端点之间平均分配流量，也可以为比率负载平衡分配定制权重。利用 Oracle Cloud Infrastructure Health Checks 监视器和按需探测器来评估端点的运行状况。如果端点不健康，则 DNS 流量会自动分布到其他端点。

  • 故障转移策略

    通过故障转移策略，您可以按策略（例如，主策略和辅助策略）中提供答案的顺序进行优先级排序。利用 OCI Health Checks 监视器和按需探测器来评估策略中答案的运行状况。如果主应答不健康，DNS 流量将自动引导至辅助应答。

  • 地理位置引导策略

    地理定位引导策略根据最终用户的位置将 DNS 流量分配给不同的端点。客户可以定义由原始大陆、国家/地区或州/省（北美）组成的地理地区，并为每个区域定义一个单独的端点或一组端点。

  • ASN 引导策略

    利用 ASN 引导策略，您可以基于自治系统编号 (ASN) 来引导 DNS 流量。DNS queries originating from a specific ASN or set of ASNs can be steered to a specified endpoint.

  • IP 前缀定向策略

    使用 IP 前端引导策略，客户可根据原始查询的 IP 前端引导 DNS 流量。

选择最符合您需求的策略。对于拉伸集群部署，最适合的选项是地理位置引导策略和 IP 前缀引导策略。故障转移策略适用于仅在一个站点（例如 WebLogic Remote Console ）中运行的服务。

无论策略的类型如何，都必须定义 OCI 健康检查以验证站点的可用性。这样可以避免流量到达服务器停止或应用程序不可用的位置。确保允许从执行运行状况检查的观察点到要检查的 OCI 负载平衡器端口的传入流量。

下图显示了使用 OCI 流量管理引导策略的全局负载平衡。


后面是 global-load-balancer-steering-policies.png 的说明
插图 global-load-balancer-steering-policies.png 的说明

全局负载平衡器引导策略 -oracle.zip

使用 OCI 流量管理引导策略来模拟全局负载平衡器时：

  • 故障转移反应时间

    站点故障的响应时间取决于运行状况检查间隔（确定站点被标记为不可用的时间）和 DNS 记录的生存时间值 (TTL)。即使将站点标记为不可用并且流量定向到其他位置后，客户机也不会收到更新的 IP 地址，直到以前的 DNS TTL 在其本地高速缓存中到期。为了最大限度地减少故障转移延迟，建议设置低策略 TTL 值。

  • 会话持久性限制

    由于与这些策略的负载平衡依赖于 DNS 响应值，因此没有内置的会话持久性机制。因此，当使用随机或简单的负载平衡器策略时，提供给客户机的 DNS 答案可能会随时更改，这可能会影响需要持久性的应用会话。如果应用需要持久性会话，请确保在基于地理位置的规则中显式定义所有可能的客户端位置，并避免使用随机或负载平衡器引导算法。

以下是部署在法兰克福和阿姆斯特丹区域的 Oracle Fusion Middleware (FMW) 拉伸集群系统的 OCI 流量管理引导策略的示例配置，前端有三个：一个用于 Oracle SOA ，一个用于 OSB，另一个用于 WebLogic Remote Console 。法兰克福负载平衡器 (LBR) 的 IP 为 111.111.111.111，阿姆斯特丹的 LBR 的 IP 为 222.222.222.222。在此示例中，引导策略定义以下规则：

  • 对于 SOA 和 OSB 前端，来自德国、欧洲、亚洲和南美地区的客户将从 DNS 获取法兰克福负载平衡器的 IP 作为主要答案。

  • 对于 SOA 和 OSB 前端，来自荷兰、非洲、大洋洲和北美位置的客户将从 DNS 获取阿姆斯特丹负载平衡器的 IP 作为主要答案。

  • 对于任何其他客户机（由于地理定位规则中包括了所有区域，因此不需要这些客户机），DNS 将返回默认答案，以便将它们重定向到法兰克福。

  • OCI 运行状况检查是为每个前端定义的，因此，如果主数据库标记为不可用，则流量将引导至备用 IP 记录。

  • WebLogic Remote Console 前端使用故障转移模型。DNS 为所有客户端返回法兰克福负载平衡器的 IP。当法兰克福的健康检查失败时，DNS 将返回阿姆斯特丹负载平衡器的 IP。

下面是定义的 OCI 流量管理引导策略：

  • 用于访问 SOA 前端的地理位置引导策略。

    配置项目 示例值

    策略名称

    strecthed_cluster_steering_policy-SOA

    模板

    地理位置引导

    策略 TTL

    60s

    答案 Pool1 (Frankfurt_Pool)

    产品名称：Frankfurt_LBR_IP

    键入：A

    RDATA:111.111.111.111

    答案池 2 (Amsterdam_Pool)

    产品名称：Amsterdam_LBR_IP

    键入：A

    RDATA:222.222.222.222

    地理位置引导规则 1

    地理位置：德国、欧洲、亚洲、南美洲

    池优先级 1：Frankfurt_Pool

    池优先级 2：Amsterdam_Pool

    地理位置引导规则 2

    地理位置：荷兰，非洲，大洋洲，北美

    池优先级 1：Amsterdam_Pool

    池优先级 2：Frankfurt_Pool

    全局通配规则

    答案 Pool1 (Frankfurt_Pool)

    附加健康检查

    请求类型：HTTP

    健康检查：SOA_IS_ALIVE (HTTPS)

    附加域

    soafrontend.example.com

  • 用于访问 OSB 前端的地理位置引导策略。

    配置项目 示例值

    策略名称

    strecthed_cluster_steering_policy-OSB

    模板

    地理位置引导

    策略 TTL

    60s

    答案池 1(Frankfurt_Pool)

    产品名称：Frankfurt_LBR_IP

    键入：A

    RDATA:111.111.111.111

    答案池 2 (Amsterdam_Pool)

    产品名称：Amsterdam_LBR_IP

    键入：A

    RDATA:222.222.222.222

    地理位置引导规则 1

    地理位置：德国、欧洲、亚洲、南美洲

    池优先级 1：Frankfurt_Pool

    池优先级 2：Amsterdam_Pool

    地理位置引导规则 2

    地理位置：荷兰，非洲，大洋洲，北美

    池优先级 1：Amsterdam_Pool

    池优先级 2：Frankfurt_Pool

    全局通配规则

    答案 Pool1 (Frankfurt_Pool)

    附加健康检查

    请求类型：HTTP

    健康检查：OSB_IS_ALIVE (HTTPS)

    附加域

    osbfrontend.example.com

  • 故障转移策略用于访问 WebLogic Remote Console 。在正常操作期间，管理服务器只在其中一个站点（本例中为法兰克福）中运行。仅当站点发生故障时，它才会在其他站点中启动。因此，对 WebLogic Remote Console 和 EM 的访问由故障转移策略控制。

    配置项目 示例值

    策略名称

    strecthed_cluster_steering_policy- 管理

    模板

    故障转移

    策略 TTL

    60s

    答案 Pool1 (Frankfurt_Pool)

    产品名称：Frankfurt_LBR_IP

    键入：A

    RDATA:111.111.111.111

    答案池 2 (Amsterdam_Pool)

    产品名称：Amsterdam_LBR_IP

    键入：A

    RDATA:222.222.222.222

    池优先级 1

    Frankfurt_Pool

    池优先级 2

    Amsterdam_Pool

    附加健康检查

    请求类型：HTTP

    健康检查：EM_IS_ALIVE (HTTPS)

    附加域

    admin.example.com

这是每个 DNS 引导策略使用的 OCI 健康检查配置：

  • SOA 前端的运行状况检查。SOA 提供了一个简单的页面来验证路径 /soa-infra/services/isSoaServerReady 中的 SOA 状态。因此，此健康检查对该路径执行具有 HTTPS 的 HEAD 请求，以验证 SOA 应用程序是否可用。在 Web 服务器和负载平衡器上使用指定的虚拟主机时，需要使用 host 标头来指定要测试的前端名称（在本示例中为 soafrontend.example.com）。

    配置项目 示例值

    健康检查名称

    SOA_IS_ALIVE

    目标

    111.111.111.111（法兰克福 LBR IP）

    222.222.222.222（阿姆斯特丹 LBR IP）

    观察点

    Microsoft Azure 北欧

    Google 美国东部

    类型

    HTTP

    协议

    HTTPS

    端口

    443

    路径

    /soa-infra/services/isSoaServerReady

    标头

    主机：soafrontend.example.com：443

    方法

    HEAD

    间隔

    30 秒

    超时

    10 秒

  • OSB 前端的健康检查。OSB 没有为其服务实施运行状况 URL。某些通常用于验证 OSB 状态（例如 /sbinspection.wsil）的 URL 需要验证，而 OCI Health Checks 不支持 authorization 头。因此，要验证 OSB 的状态，请部署简单的定制 REST 代理服务。此 OCI 健康检查通过 HTTPS 对此类端点执行 HEAD 请求。在 Web 服务器和负载平衡器上使用指定的虚拟主机时，需要使用 host 标头来指定要测试的前端名称（在本示例中为 osbfrontend.example.com）。

    配置项目 示例值

    健康检查名称

    OSB_IS_ALIVE

    目标

    111.111.111.111（法兰克福 LBR IP）

    222.222.222.222（阿姆斯特丹 LBR IP）

    观察点

    Microsoft Azure 北欧

    Google 美国东部

    类型

    HTTP

    协议

    HTTPS

    端口

    443

    路径

    /default/isOSBReadySample

    标头

    主机：osbfrontend.example.com：443

    方法

    HEAD

    间隔

    30 秒

    超时

    10 秒

  • WebLogic Remote Console 前端 EM_IS_ALIVE 的运行状况检查。

    OCI Health Checks 使用 HTTPS 到路径 /em/faces/targetauth/emasLogin 的 HEAD 请求来验证 FMW Control Console 的状态。

    配置项目 示例值

    健康检查名称

    SOA_IS_ALIVE

    目标

    111.111.111.111（法兰克福 LBR IP）

    222.222.222.222（阿姆斯特丹 LBR IP）

    观察点

    Microsoft Azure 北欧

    Google 美国东部

    类型

    HTTP

    协议

    HTTPS

    端口

    443

    路径

    /em/faces/targetauth/emasLogin

    标头

    主机：admin.example.com：445

    方法

    HEAD

    间隔

    30 秒

    超时

    10 秒

使用第三方全局负载平衡器

作为 Oracle Cloud Infrastructure (OCI) 流量管理引导策略的替代方案，您可以使用第三方全局负载平衡器 (GLBR)。

它将负责在本地负载平衡器之间执行请求的智能路由。

GLBR 是一个负载平衡器，配置为可由所有站点和外部位置的用户作为地址访问。该设备提供了一个虚拟服务器，该服务器映射到可供任何客户机访问的域名系统 (Domain Name System，DNS) 名称，而不管它们将连接到哪个站点。

GLBR 根据配置的标准和规则将流量定向到任一站点。例如，这些条件可以基于客户机的 IP。这应用于创建持久性配置文件，以允许 GLBR 在初始和后续请求时将用户映射到同一站点。GLBR 维护的池由所有本地负载平衡器的地址组成。如果其中一个站点发生故障，将自动将用户重定向到未发生故障的活动站点。

在每个站点中，本地负载平衡器从 GLBR 接收请求，并将请求定向到相应的 HTTP 服务器。为了消除不需要的路由，GLBR 还配置了特定规则，这些规则仅将回调路由到生成它们的服务器本地的 LBR。例如，这对于 Oracle SOA 服务的内部使用者非常有用。这些 GLBR 规则可以按如下方式汇总：

  • 如果请求来自 site1（例如，请求来自站点 1 中的 WebLogic 服务器），则 GLBR 将路由到 site1 中的 LBR。

  • 如果请求来自 site2（例如，请求来自站点 2 中的 WebLogic 服务器），则 GLBR 将路由到 site2 中的 LBR。

  • 如果请求来自任何其他地址（客户机调用），则 GLBR 装入将平衡与两个 LBR 的连接。

  • 可在 GLBR 中定义其他路由规则，以将特定客户机路由到特定站点（例如，两个站点可能根据每种情况下的硬件资源提供不同的响应时间）。

设置其他资源

这两个区域可以使用外部资源，例如 LDAP、身份存储库、策略存储、外部 java 消息服务 (JMS) 目标、外部 Web 服务、Oracle Cloud Infrastructure Object Storage 等。

这些外部资源的配置详细信息不在本文档的范围内。但是，这两个区域都需要这些资源保持一致，以提供统一的行为。

例如，在 Oracle SOA 中，异步回调可能会冻结在不同区域中启动的实例。同样，在自动恢复的情况下，任何 Oracle WebLogic Server 都可以承担集群主服务器的角色并在任一区域中执行恢复操作。为了确保这些流程无缝工作并提供一致的行为，必须可以从两个区域访问相同的外部资源。