关于管理故障
Oracle Fusion Middleware (FMW) 拉伸集群拓扑可恢复为任何单个组件中的故障。
每个站点遵循 Oracle FMW Enterprise Deployment 拓扑中概述的高可用性优秀实践，确保本地冗余能够防止组件级别（例如负载平衡器、Oracle HTTP Server 实例、Oracle WebLogic Server 或数据库实例）发生中断。
以下各节讨论了解决场景（如站点内的完整层故障或站点完全故障）的注意事项。
管理一个站点上所有 Web 服务器的故障
所有客户机请求（无论其站点首选项如何）都将路由到其他站点。
因此，具有失败 Web 服务器的站点的 Oracle WebLogic 服务器将不会收到新请求。他们可以继续执行某些处理（例如，处理 Oracle SOA 组合和 java 消息服务 (JMS) 消息）。但是，从这些服务器内部生成的任何 HTTP 回调都将失败，因为它们指向自己的站点，其 Web 服务器已失败。
下图显示一个站点上所有 Web 服务器的故障
从故障中恢复
得益于 Oracle Cloud Infrastructure (OCI) 流量管理引导策略或全局负载平衡器 (GLBR)，客户机将自动重定向到其他站点。
如果在短期内无法恢复丢失的 Web 服务器实例，则可以执行以下操作以将站点的 WebLogic 服务器与失败的 Web 层一起使用：
- 配置另一个站点的 Oracle HTTP Server (OHS) 实例，以将请求路由到失败站点上的 Oracle WebLogic Server 实例。
- 更新 OHS 配置并将
DynamicServerList参数设置为ON。 - 通过滚动重新启动 OHS 以避免停机来应用此更改。
- 此外，确保允许跨区域通信从 Web 服务器到其他站点的 WebLogic 服务器。
- 更新 OHS 配置并将
- 为了防止超文本传输协议 (HTTP) 回调失败，这些回调源自具有不可用 OHS 服务器的站点，请更新 WebLogic 服务器主机的
/etc/hosts文件或专用域名系统 (DNS) 中前端名称的条目，以指向其他站点的负载平衡器。
- 在失败的站点中启动 OHS 进程。
Oracle Cloud Infrastructure Health Checks 再次正常运行后，流量管理引导策略将根据定义的规则在两个站点之间对客户端请求进行负载平衡。
- 在其他站点中再次将
DynamicServerList设置为OFF。 - 恢复 WebLogic 服务器的
/etc/hosts文件（或专用 DNS）中的任何更改，以便它们再次指向自己的站点负载平衡器。
下图显示了在一个站点上所有 Web 服务器发生故障时 Java Message Service (JMS) 队列消息和客户机失败的请求：
预期恢复时间对象
DNS 更新会影响其引导策略首选项设置为故障区域的客户机。TTL 值确定这些客户机在更新旧条目以指向健康站点之前继续使用旧条目的时间。额外的时间（约 1 分钟）取决于 OCI 引导策略中配置的健康检查频率和超时（在上面的测试中使用了 30 秒进行健康检查间隔和 10 秒超时）。
使用全局负载平衡器 (Global Load Balancer，GLBR) 时，中断时间取决于 GLBR 中配置的运行状况检查的频率。当 GLBR 将池标记为不健康时，传入请求将重定向到其他站点。对于 GLBR，没有 DNS 更新，因此前端条目的 TTL 值无关紧要。
管理一个站点上所有 Oracle WebLogic 服务器的故障
失败站点的负载平衡器将返回失败的响应，因此基于 Oracle Cloud Infrastructure (OCI) 流量引导策略和运行状况检查的前端全局平衡功能应将站点标记为不健康。所有客户机请求（无论其首选项如何）都将路由到其他站点。
使用自动服务迁移以及 Java 数据库连接 (JDBC) 持久性存储时，WebLogic Java Message Service (JMS) 和 Java 事务处理 API (JTA) 服务将自动迁移到其他站点中的服务器。
在 Oracle Fusion Middleware (FMW) SOA 案例中，如果自动恢复集群主服务器托管在失败的服务器中，则可用站点中将出现新的集群主服务器。此服务器将自动恢复在其他站点上启动的 SOA 实例。
下图显示了一个站点上所有 WebLogic 服务器的故障：
failures-all-weblogic-servers-one-site-oracle.zip
下图显示了当站点上的所有 WebLogic 服务器都失败时，每个服务器的客户机失败请求和 JMS 消息。
在 JMS 消息图表中，有四行，每行表示服务器的 JMS 队列。绿色和蓝色线（几乎重叠）对应于被杀死的服务器。这些队列的 JMS 消息数在中断开始后不会增加。
红色和黄色线表示区域 2 中保留的服务器。当所有请求都重定向到此区域时，其余每台服务器接收总负载的 50%。但是，消息在其队列中累积的速率不同。这是因为失败服务器的 JMS 服务器已迁移到剩余服务器之一，因此该服务器中的消息现在由三个队列进行处理。因此，该斜率在黄色斜率中较低（请注意，监视工具不显示已迁移队列的消息计数）。
从故障中恢复
发生故障的服务器再次可用后：
- 在发生故障的站点中启动托管服务器。
- 只要 Oracle Cloud Infrastructure Health Checks 恢复运行，流量管理引导策略就会根据定义的规则在两个站点之间对客户端请求进行负载平衡。
预期恢复时间对象
这类似于一个站点上所有 Web 服务器出现故障的情况，
DNS 更新会影响其引导策略首选项设置为故障区域的客户机。TTL 值确定这些客户机在更新旧条目以指向健康站点之前继续使用旧条目的时间。额外的时间（约 1 分钟）取决于 OCI 流量管理引导策略中配置的健康检查频率和超时（在运行状况检查间隔的测试中使用了 30 秒，超时为 10 秒）。
使用全局负载平衡器 (Global Load Balancer，GLBR) 时，中断时间取决于 GLBR 中配置的运行状况检查的频率。当 GLBR 将池标记为不健康时，传入请求将重定向到其他站点。对于 GLBR，没有 DNS 更新，因此前端条目的 TTL 值无关紧要。
管理数据库中的故障：Data Guard 切换和故障转移
以前在“设置 WebLogic 数据源”中提供的 Java 数据库连接 (JDBC) URL 字符串和 Oracle 通知服务 (ONS) 配置可确保新主数据库自动重新连接。对于这些精确的测试（使用 Oracle Fusion Middleware (FMW) SOA FOD，即使工作负载高达 160 个并发调用），数据库切换或故障转移也需要不到几分钟的时间。这一次可能会因系统配置和环境而异。在经过优化的系统中，1-5 分钟的切换时间很常见，但系统大小、资源、工作量、重做日志同步和网络性能等因素可能会影响总持续时间。有关指向 Oracle Data Guard 文档和其他资源的链接，请参阅“浏览更多”部分。
在数据库切换或故障转移期间，将出现应用程序错误。此外，如果节点管理器无法更新其租赁表，则使用服务迁移的 WebLogic 服务器可以关闭并自动重新启动。默认租赁参数的预期行为是：
- 如果数据库停机时间很短（不到 1-2 分钟），则不需要 WebLogic 服务器自动重新启动。
- 如果数据库停机时间较长（2-10 分钟），则 WebLogic 服务器可能会由于数据库再次启动时“丢失租约”而自动重新启动。
可以通过优化 WebLogic 的数据库租赁重试次数来提高下限，如前面的“配置优化 WebLogic 数据库租赁”中所述。
- 如果数据库停机时间较长（>10 分钟），则 WebLogic 服务器可能会由于其他故障而自动重新启动，例如丢失对关键 JDBC 存储的访问（“JTA 的 JDBC 存储不可用”）。
下图显示了 FMW 拉伸集群拓扑中的数据库切换
拉伸群集 -db-switchover-oracle.zip
下图显示了在 FMW 拉伸集群中的数据库切换期间，客户机请求性能和每个服务器队列的 Java Message Service (JMS) 消息。
预期恢复时间对象
对于执行的测试，切换时间不到 2 分钟。
对于计划外切换或故障转移，总停机时间取决于数据库关闭的时间：
- 如果几乎立即执行数据库故障转移或切换，则恢复的总时间很短。这取决于数据库切换或故障转移所需的时间。对于执行的测试，切换时间不到 2 分钟，因此预期恢复时间目标 (RTO) 为：
RTO = DB DOWNTIME + SHORT TIME (1-2 min) - 如果数据库停机时间较长，可能会出现增加 RTO 的其他错误，例如 Oracle WebLogic Server 自动重新启动。在这种情况下，期望的 RTO 为：
RTO = DB DOWNTIME + WEBLOGIC START TIME
管理 WebLogic 管理服务器中的故障
节点管理器将自动就地重新启动发生故障的服务器。
但是，如果中断完全影响运行管理服务器的主机，则需要将管理服务器故障转移到其他节点。
从本质上讲，这包括在不同的节点中重新启动管理服务器，确保它指向包含管理服务器域目录的位置，并且它使用映射到相应虚拟 IP (virtual IP，VIP) 的监听地址。
此管理服务器域目录可以是同一区域中的不同节点可用的共享存储位置，也可以是从对不同区域中的节点可用的备份或文件系统复制进行恢复。
注意：
无论集群配置如何，您都应该为 Oracle WebLogic 域设置适当的备份过程。因此，在 Oracle Fusion Middleware (FMW) 拉伸集群拓扑中，将管理服务器迁移到其他区域中的节点时，要考虑不同的注意事项，而不是将管理服务器迁移到同一区域中的节点。
下图显示了管理服务器故障转移到 FMW 拉伸群集中的其他站点
故障转移到其他区域
通过访问 WebLogic Remote Console 和 Oracle Enterprise Manager Fusion Middleware Control 来验证管理服务器是否正常工作。
故障转移到同一区域
因此，故障转移过程与 Enterprise Deployment Guide for the Administration Server in Verifying Manual Failover of the Administration Server 中所述的过程相同。
要管理 Oracle Cloud Infrastructure (OCI) 系统中的管理服务器虚拟 IP (VIP)，可以使用博客 Using a Virtual IP (VIP) in Oracle Cloud Infrastructure 中介绍的步骤
管理托管主数据库的整个区域的故障
如果剩余站点中的 Oracle WebLogic Server 实例使用上一节中所述的建议配置，则它们将自动重新连接到新的主数据库。
失败站点的负载平衡器将返回失败的响应，因此前端全局平衡功能应将站点标记为不健康。所有客户机请求（无论其首选项如何）都将路由到其他站点。
使用自动服务迁移以及 JDBC 持久性存储时，WebLogic JMS 和 JTA 服务将自动迁移到其他站点中的服务器。在 Oracle Fusion Middleware (FMW) Oracle SOA Suite 的情况下，如果自动恢复集群主服务器托管在失败的服务器中，则可用站点中将出现新的集群主服务器。新集群管理器将自动恢复在其他站点上启动的 SOA 实例。
下图显示了 FMW 拉伸群集拓扑中整个区域 1 的故障：
从故障中恢复
恢复失败的站点并再次可用后：
- 在失败的主机中重新启动进程：Oracle HTTP 服务器、WebLogic 管理服务器和托管服务器。
确保已设置管理服务器虚拟 IP (virtual IP，VIP)，并且不存在阻止启动的孤立文件。
- 如果执行了数据库故障转移，请恢复失败的数据库。
如果您执行了切换，则不需要执行此操作。
- 执行数据库切换到原始站点。
预期恢复时间对象
剩余站点中的服务器可以在数据库再次运行后立即继续处理请求，因此停机时间取决于切换数据库之前所用的时间。
- 如果几乎立即执行数据库故障转移或切换，则恢复的总时间很短。这取决于数据库切换或故障转移所需的时间。对于执行的测试，切换时间不到 2 分钟，因此预期的 RTO 为：
RTO = DB DOWNTIME + SHORT TIME (1-2 min). - 如果数据库停机时间较长，可能会出现增加 RTO 的其他错误，例如 Oracle WebLogic Server 自动重新启动。预期的 RTO 为：
RTO = DB DOWNTIME + WEBLOGIC START TIME
管理托管备用数据库的整个区域的故障
所有客户机请求（无论其站点首选项如何）都将路由到区域 1，该区域继续处理请求。使用自动服务迁移以及 JDBC 持久性存储时，WebLogic JMS 和 JTA 服务将自动迁移到站点 1 中的服务器。
在 Oracle Fusion Middleware (FMW) 与 Oracle SOA Suite 的情况下，如果自动恢复集群主服务器托管在失败的服务器中，则可用站点中将出现新的集群主服务器。此服务器将自动恢复在其他站点上启动的 SOA 实例。
无需执行数据库切换，因为中断不会影响主数据库。
下图显示了 FMW 拉伸群集拓扑中整个区域 2 的故障。
从故障中恢复
在故障站点再次可用后，重新启动 Oracle HTTP 服务器和 WebLogic 受管服务器发生故障的主机中的进程。
确保不存在阻止 WebLogic 启动的孤立文件。
得益于全局负载平衡器功能（Oracle Cloud Infrastructure 流量管理引导策略或全局负载平衡器），客户端的请求将再次在 2 个站点之间重新平衡。
预期恢复时间对象
域名系统 (Domain Name System，DNS) 更新会影响在地理位置引导策略中将区域 2 设置为其首选项的客户机。DNS 更新会影响其引导策略首选项设置为故障区域的客户机。TTL 值确定这些客户机在更新旧条目以指向健康站点之前继续使用旧条目的时间。额外的时间（约 1 分钟）取决于 OCI 流量管理引导策略中配置的健康检查的频率和超时（在上面的测试中使用了 30 秒的健康检查间隔和 10 秒的超时）。
使用全局负载平衡器 (Global Load Balancer，GLBR) 时，中断时间取决于 GLBR 中配置的运行状况检查的频率。当 GLBR 将池标记为不健康时，传入请求将重定向到其他站点。对于 GLBR，没有 DNS 更新，因此前端条目的 TTL 值无关紧要。