教程：将 Oracle WebLogic Server 迁移到具有高可用性和灾难恢复的 Azure 虚拟机

项目
09/01/2024

本教程介绍如何在 Azure 虚拟机 (VM) 上使用 Oracle WebLogic Server (WLS) 实现 Java 的高可用性和灾难恢复 (HA/DR)。该解决方案介绍如何使用在 WLS 上运行的简单数据库驱动的 Jakarta EE 应用程序实现低恢复时间目标 (RTO) 和恢复点目标 (RPO)。 HA/DR 是一个复杂的主题，其中包含许多可能的解决方案。最佳解决方案取决于你的独特要求。有关实现 HA/DR 的其他方法，请参阅本文末尾的资源。

本教程介绍如何执行下列操作：

使用 Azure 优化的最佳做法来实现高可用性和灾难恢复。
在配对区域中设置 Microsoft Azure SQL 数据库故障转移组。
在 Azure VM 上设置配对的 WLS 群集。
设置 Azure 流量管理器。
配置 WLS 群集以实现高可用性和灾难恢复。
测试从主服务器故障转移到辅助服务器。

下图说明了你构建的体系结构：

Azure 流量管理器检查所在区域的运行状况，并相应地将流量路由到应用程序层。主要区域和次要区域都已完全部署 WLS 群集。但是，只有主要区域正在积极为来自用户的网络请求提供服务。次要区域处于被动状态，只有当主要区域出现服务中断时，它才会被激活以接收流量。 Azure 流量管理器使用 Azure 应用程序网关的运行状况检查功能来实现此条件路由。主 WLS 群集正在运行，辅助群集已关闭。应用层的异地故障转移 RTO 取决于启动 VM 和运行辅助 WLS 群集的时间。 RPO 依赖于 Azure SQL 数据库，因为数据在 Azure SQL 数据库故障转移组中持久保存和复制。

数据库层由具有主服务器和辅助服务器的 Azure SQL 数据库故障转移组组成。主服务器处于活动读写模式，并连接到主 WLS 群集。辅助服务器处于仅被动就绪模式，并连接到辅助 WLS 群集。异地故障转移都会将组中所有的辅助数据库切换为主角色。有关 Azure SQL 数据库的异地故障转移 RPO 和 RTO，请参阅业务连续性概述。

本文是使用 Azure SQL 数据库服务编写的，因为本文依赖于该服务的高可用性 (HA) 功能。其他数据库选择也是可能的，但必须考虑所选任何数据库的 HA 功能。有关详细信息，包括有关如何优化数据源的配置以供复制的信息，请参阅为 Oracle Fusion 中间件主动-被动部署配置数据源。

先决条件

Azure 订阅。如果还没有 Azure 订阅，可以在开始前创建一个免费帐户。
确保你在订阅中拥有 Owner 角色或 Contributor 和 User Access Administrator 角色。可以使用使用 Azure 门户列出 Azure 角色分配中的步骤来验证分配。
准备安装了 Windows、Linux 或 macOS 的本地计算机。
安装并设置 Git。
安装版本为 17 或更高的 Java SE 实现（例如，OpenJDK 的 Microsoft 版本）。
安装 Maven 3.9.3 版或更高版本。

在配对区域中设置 Azure SQL 数据库故障转移组

在本节中，你将在配对区域中创建一个 Azure SQL 数据库故障转移组，以供 WLS 群集和应用程序使用。在后面的节中，将 WLS 配置为将其会话数据和事务日志 (TLOG) 数据存储到此数据库。这种做法与 Oracle 的最大可用性体系结构 (MAA) 保持一致。本指南提供适用于 MAA 的 Azure 适应。有关 MAA 的详细信息，请参阅 Oracle 最大可用性体系结构。

首先，按照快速入门：创建单一数据库 - Azure SQL 数据库中的 Azure 门户步骤，创建主 Azure SQL 数据库。按照“清理资源”部分的步骤进行操作，但不包括该部分。阅读本文时请遵循以下说明，然后在创建并配置 Azure SQL 数据库后返回本文：

到达创建单一数据库部分时，请使用以下步骤：
1. 在创建新资源组的步骤 4 中，请保存资源组名称值，例如 myResourceGroup。
2. 在步骤 5 中，保存数据库名称值 - 例如 mySampleDatabase。
3. 在创建服务器的步骤 6 中，使用以下步骤：
  1. 请保存唯一的服务器名称 - 例如 sqlserverprimary-ejb120623。
  2. 对于“位置”，请选择“(美国)美国东部”。
  3. 对于身份验证方法，选择使用 SQL 身份验证。
  4. 保存服务器管理员登录值 - 例如 azureuser。
  5. 保存密码值。
4. 在步骤 8 中，对于工作负载环境，请选择开发。查看说明，并考虑工作负载的其他选项。
5. 在步骤 11 中，对于备份存储冗余，选择本地冗余备份存储。请考虑备份的其他选项。有关详细信息，请参阅 Azure SQL 数据库中的自动备份的备份存储冗余部分。
6. 在步骤 14 中，在防火墙规则配置中，对于允许 Azure 服务和资源访问此服务器，请选择是。
到达查询数据库部分时，请使用以下步骤：
1. 在步骤 3 中，输入 SQL 身份验证服务器管理员登录信息以登录。
  
  注意
  
  如果登录失败，出现类似于不允许 IP 地址为“xx.xx.xx.xx”的客户端访问该服务器的错误消息，请在错误消息末尾选择 Allowlist IP xx.xx.xx.xx on server <your-sqlserver-name>。等待服务器防火墙规则完成更新，然后再次选择确定。
2. 在步骤 5 中运行示例查询后，清除编辑器并创建表。

输入以下查询为 TLOG 创建架构。

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

成功运行后，应该会看到消息“查询成功: 受影响的行: 0”。

这些数据库表用于存储 WLS 群集和应用的事务日志 (TLOG) 和会话数据。有关详细信息，请参阅使用 JDBC TLOG 存储和使用数据库进行持久存储（JDBC 持久性）。

接下来，按照为 Azure SQL 数据库配置故障转移组中的 Azure 门户步骤，创建 Azure SQL 数据库故障转移组。只需以下部分：创建故障转移组和测试计划的故障转移。阅读本文时请使用以下步骤，然后在创建并配置 Azure SQL 数据库故障转移组后返回本文。

到达创建故障转移组部分时，请使用以下步骤：
1. 在创建故障转移组的步骤 5 中，选择用于创建新的辅助服务器的选项，然后使用以下步骤：
  1. 输入并保存故障转移组名称 - 例如 failovergroupname-ejb120623。
  2. 输入并保存唯一的服务器名称 - 例如 sqlserversecondary-ejb120623。
  3. 输入与主服务器相同的服务器管理员和密码。
  4. 对于位置，请选择与用于主数据库的区域不同的区域。
  5. 请确保已选中允许 Azure 服务访问服务器。
2. 在步骤 5 中，若要配置组中的数据库，请选择在主服务器中创建的数据库，例如 mySampleDatabase。
完成测试计划的故障转移部分中的所有步骤后，保持故障转移组页面打开，稍后将其用于 WLS 群集的故障转移测试。

在 Azure VM 上设置配对的 WLS 群集

在本节中，将使用 Azure VM 上的 Oracle WebLogic Server 群集产品/服务在 Azure VM 上创建两个 WLS 群集。美国东部的群集是主要群集，稍后配置为活动群集。美国西部的群集是辅助群集，稍后配置为被动群集。

设置主 WLS 群集

首先，在浏览器中打开 Azure VM 上的 Oracle WebLogic Server 群集产品/服务，然后选择创建。应会看到产品/服务的基本信息窗格。

使用以下步骤填写基本信息窗格：

确保为订阅显示的值与“先决条件”部分中列出的角色的值相同。
必须在空资源组中部署产品/服务。在资源组字段中，选择新建，并填写资源组的唯一值 - 例如，wls-cluster-eastus-ejb120623。
在实例详细信息下，选择区域，选择美国东部。
在虚拟机和 WebLogic 的凭据下，分别为 VM 的管理员帐户和 WebLogic 管理员提供密码。为 WebLogic 管理员保存用户名和密码。
其他字段保留默认值。
选择下一步转到 TLS/SSL 配置窗格。

在 TLS/SSL 配置窗格中保留默认值，选择下一步转到 Azure 应用程序网关窗格，然后使用以下步骤。

对于连接到 Azure 应用程序网关?，选择是。
对于选择所需的 TLS/SSL 证书选项，请选择生成自签名证书。
选择下一步，转到网络窗格。

应该在网络窗格中看到所有字段都预先填充了默认值。使用以下步骤保存网络配置：

选择编辑虚拟网络。请保留虚拟网络的地址空间，例如 10.1.4.0/23。
选择 wls-subnet 以编辑子网。在子网详细信息下，保存起始地址和子网大小，例如 10.1.5.0 和 /28。
如果进行了任何修改，请保存更改。
返回到网络窗格。
选择下一步，转到数据库窗格。

以下步骤演示如何填写数据库窗格：

对于连接到数据库？，请选择是。
对于选择数据库类型，请选择 Microsoft SQL Server（支持无密码连接）。
对于 JNDI 名称，请输入 jdbc/WebLogicCafeDB。
对于数据源连接字符串，请将占位符替换为你在上一节中为主 SQL 数据库保存的值 - 例如 jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433;database=mySampleDatabase。
对于全局事务协议，请选择无。
对于数据库用户名，请将占位符替换为你在上一节中为主 SQL 数据库保存的值，例如 azureuser@sqlserverprimary-ejb120623。
输入以前为数据库密码保存的服务器管理员登录密码。为确认密码输入相同的值。
其他字段保留默认值。
选择“查看 + 创建”。
等待正在运行最终验证... 成功完成，然后选择创建。

过了一会儿，应会看到部署页，其中显示了部署正在进行中。

注意

如果在正在运行最终验证... 期间看到任何问题，请修复这些问题，然后重试。

根据所选地区的网络状况和其他活动，部署可能需要 50 分钟才能完成。之后，你应当会看到部署页上显示文本“你的部署已完成”。

同时，可以并行设置辅助 WLS 群集。

设置辅助 WLS 群集

按照与在设置主 WLS 群集部分相同的步骤，在“美国西部”区域设置辅助 WLS 群集，但存在以下差异：

在基本信息窗格中，使用以下步骤：
1. 在资源组字段中，选择新建，并为资源组填写其他唯一值 - 例如，wls-cluster-westtus-ejb120623。
2. 在实例详细信息下，选择区域，选择美国西部。
在网络窗格中，使用以下步骤：
1. 对于编辑虚拟网络，请输入与主 WLS 群集相同的虚拟网络地址空间，例如 10.1.4.0/23。
  
  注意
  
  你应该看到一条类似于以下内容的警告消息：地址空间'10.1.4.0/23 (10.1.4.0 - 10.1.5.255)'与虚拟网络'wls-vnet'的地址空间'10.1.4.0/23 (10.1.4.0 - 10.1.5.255)'重叠。无法对等互连地址空间重叠的虚拟网络。如果要对等互连这些虚拟网络，请更改地址空间'10.1.4.0/23 (10.1.4.0 - 10.1.5.255)'。可以忽略此消息，因为需要两个具有相同网络配置的 WLS 群集。
2. 对于 wls-subnet，请输入与主 WLS 群集相同的起始地址和子网大小，例如 10.1.5.0 和 /28。
在数据库窗格中，使用以下步骤：
1. 对于数据源连接字符串，请将占位符替换为你在上一节中为辅助 SQL 数据库保存的值 - 例如 jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433;database=mySampleDatabase。
2. 对于数据库用户名，请将占位符替换为你在上一节中为辅助 SQL 数据库保存的值，例如 azureuser@sqlserversecondary-ejb120623。

镜像两个群集的网络设置

在故障转移后恢复辅助 WLS 群集中挂起的事务的阶段，WLS 会检查 TLOG 存储的所有权。若要成功通过检查，辅助群集中的所有托管服务器必须与主群集具有相同的专用 IP 地址。

本节介绍如何将网络设置从主群集镜像到辅助群集。

首先，在主群集部署完成后，使用以下步骤配置其网络设置：

在部署页面的概述窗格中，选择转到资源组。
选择网络接口 adminVM_NIC_with_pub_ip。
1. 在“设置”下选择“IP 配置”。
2. 选择 ipconfig1。
3. 在专用 IP 地址设置下，为分配选择静态。保存专用 IP 地址。
4. 选择“保存”。
返回到主 WLS 群集的资源组，然后对网络接口 mspVM1_NIC_with_pub_ip、mspVM2_NIC_with_pub_ip 和 mspVM3_NIC_with_pub_ip 重复步骤 3。
等待所有更新完成。可以选择 Azure 门户中的通知图标，以打开通知窗格进行状态监视。
返回到主 WLS 群集的资源组，然后复制类型为专用终结点的资源的名称，例如 7e8c8bsaep。使用该名称查找剩余网络接口 - 例如 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a。选择它并按照上述步骤获取其专用 IP 地址。

然后，在辅助群集部署完成后，使用以下步骤配置辅助群集的网络设置：

在部署页面的概述窗格中，选择转到资源组。
对于网络接口 adminVM_NIC_with_pub_ip、mspVM1_NIC_with_pub_ip、mspVM2_NIC_with_pub_ip 和 mspVM3_NIC_with_pub_ip，请按照前面的步骤将专用 IP 地址分配更新为静态。
等待所有更新完成。
对于网络接口 mspVM1_NIC_with_pub_ip、mspVM2_NIC_with_pub_ip 和 mspVM3_NIC_with_pub_ip，请执行前面的步骤，但将专用 IP 地址更新为与主群集一起使用的相同值。等待网络接口的当前更新完成，然后再进行下一次更新。

注意

无法更改作为专用终结点一部分的网络接口的专用 IP 地址。若要轻松镜像托管服务器的网络接口的专用 IP 地址，请考虑将 adminVM_NIC_with_pub_ip 的专用 IP 地址更新为不使用的 IP 地址。根据两个群集中专用 IP 地址的分配，可能需要更新主群集中的专用 IP 地址。

下表显示了镜像两个群集的网络设置的示例：

Cluster	Linux	专用 IP 地址（之前）	专用 IP 地址（之后）	更新序列
主	`7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a`	`10.1.5.4`	`10.1.5.4`
主	`adminVM_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.7`
主	`mspVM1_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.5`
主要	`mspVM2_NIC_with_pub_ip`	`10.1.5.8`	`10.1.5.9`	1
主	`mspVM3_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.6`
次要	`1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1`	`10.1.5.8`	`10.1.5.8`
次要	`adminVM_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.4`	4
次要	`mspVM1_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.5`	5
次要	`mspVM2_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.9`	2
次要	`mspVM3_NIC_with_pub_ip`	`10.1.5.4`	`10.1.5.6`	3

检查所有托管服务器的专用 IP 地址集，其中包括在每个群集中部署 Azure 应用程序网关的后端池。如果已更新，请使用以下步骤相应地更新 Azure 应用程序网关后端池：

打开群集的资源组。
找到类型为应用程序网关的资源 myAppGateway。选择它以将其打开。
在设置部分中，选择后端池，然后选择 myGatewayBackendPool。
使用更新的专用 IP 地址或地址更改后端目标值，然后选择保存。等待它完成。
在设置部分中，选择运行状况探测，然后选择 HTTPhealthProbe。
请确保选中我想要在添加运行状况探测之前测试后端运行状况，然后选择测试。应会看到后端池 myGatewayBackendPool 的状态值标记为正常。如果不是，请检查专用 IP 地址是否按预期更新，并且 VM 正在运行，然后再次测试运行状况探测。必须先排除故障并解决问题，然后才能继续。

在以下示例中，每个群集的 Azure 应用程序网关后端池都会更新：

Cluster	Azure 应用程序网关后端池	后端目标（之前）	后端目标（之后）
主	`myGatewayBackendPool`	(`10.1.5.5`, `10.1.5.8`, `10.1.5.6`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)
次要	`myGatewayBackendPool`	(`10.1.5.7`, `10.1.5.6`, `10.1.5.4`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)

若要自动执行网络设置镜像，请考虑使用 Azure CLI。有关详细信息，请参阅 Azure CLI 入门。

验证群集的部署

你在每个群集中部署了 Azure 应用程序网关和 WLS 管理服务器。 Azure 应用程序网关充当群集中所有托管服务器的负载均衡器。 WLS 管理服务器为群集配置提供了一个 Web 控制台。

在进入下一步之前，请使用以下步骤验证每个群集中的 Azure 应用程序网关和 WLS 管理控制台是否正常工作：

返回到部署页，然后选择输出。
复制属性 appGatewayURL 的值。附加字符串 Weblogic/ready，然后在新的浏览器选项卡中打开该 URL。应看到一个没有任何错误消息的空页面。如果没看到，则必须先排除故障并解决问题，然后才能继续。
复制并保存属性 adminConsole 的值。在新浏览器选项卡中打开它。应会看到 WebLogic Server 管理控制台的登录页面。使用之前保存的 WebLogic 管理员的用户名和密码登录到控制台。如果你无法登录，则必须先排除故障并解决问题，然后才能继续。

使用以下步骤获取每个群集的 Azure 应用程序网关的 IP 地址。稍后设置 Azure 流量管理器时使用这些值。

打开部署群集的资源组 - 例如，选择概述以切换回部署页的“概述”窗格。然后，选择转到资源组。
找到类型为公共 IP 地址的资源 gwip，然后选择它将其打开。查找 IP 地址字段并保存其值。

设置 Azure 流量管理器

在本节中，将创建一个 Azure 流量管理器，用于将流量分发到全球 Azure 区域中面向公众的应用程序。主终结点指向主 WLS 群集中的 Azure 应用程序网关，辅助终结点指向辅助 WLS 群集中的 Azure 应用程序网关。

按照快速入门：使用 Azure 门户创建流量管理器配置文件中的说明，创建 Azure 流量管理器配置文件。跳过先决条件部分。只需以下部分：创建流量管理器配置文件、添加流量管理器终结点和测试流量管理器配置文件。在浏览这些部分时，请使用以下步骤，然后在创建和配置 Azure 流量管理器后返回本文。

到达创建流量管理器配置文件部分时，请使用以下步骤：
1. 在步骤 2 创建流量管理器配置文件中，使用以下步骤：
  1. 为名称保存唯一流量管理器配置文件名称 - 例如 tmprofile-ejb120623。
  2. 为资源组保存新的资源组名称 - 例如 myResourceGroupTM1。
到达添加流量管理器终结点部分时，请使用以下步骤：
1. 在步骤从搜索结果中选择配置文件后执行此附加操作。
  1. 在“设置”下，选择“配置”。
  2. 对于 DNS 生存时间 (TTL)，输入 10。
  3. 在终结点监视器设置下，对于路径，输入 /weblogic/ready。
  4. 在快速终结点故障转移设置下，使用以下值：
    - 对于探测内部，请输入 10。
    - 对于容许的失败次数，输入 3。
    - 对于探测超时，请输入 5。
  5. 选择“保存”。等待它完成。
2. 在添加主终结点 myPrimaryEndpoint 的步骤 4 中，使用以下步骤：
  1. 对于目标资源类型，请选择公共 IP 地址。
  2. 选择选择公共 IP 地址下拉列表，然后输入你之前保存在美国东部 WLS 群集中部署的应用程序网关的 IP 地址。应看到一个匹配的条目。为公共 IP 地址选择它。
3. 在添加故障转移/辅助终结点 myFailoverEndpoint 的步骤 6 中，使用以下步骤：
  1. 对于目标资源类型，请选择公共 IP 地址。
  2. 选择选择公共 IP 地址下拉列表，然后输入你之前保存在美国西部 WLS 群集中部署的应用程序网关的 IP 地址。应看到一个匹配的条目。为公共 IP 地址选择它。
4. 请稍等片刻。选择刷新，直到两个终结点的监视状态值处于联机状态。
到达测试流量管理器配置文件部分时，请使用以下步骤：
1. 在小节检查 DNS 名称中，使用以下步骤：
  1. 在步骤 3 中，请保存流量管理器配置文件的 DNS 名称，例如 http://tmprofile-ejb120623.trafficmanager.net。
2. 在小节查看运行中的流量管理器中，使用以下步骤：
  1. 在步骤 1 和步骤 3 中，将 /weblogic/ready 附加到 Web 浏览器中流量管理器配置文件的 DNS 名称后，例如 http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready。你应该看到一个没有任何错误消息的空白页面。
  2. 完成所有步骤后，请确保通过引用步骤 2 启用主终结点，但将已禁用替换为已启用。然后返回到终结点页。

现在，在流量管理器配置文件中有两个终结点已启用和联机。保持页面打开，稍后你可以使用它来监视终结点状态。

配置 WLS 群集以实现高可用性和灾难恢复

在本节中，将配置 WLS 群集以实现高可用性和灾难恢复。

准备示例应用

在本节中，你将生成并打包一个示例 CRUD Java/JakartaEE 应用程序，稍后你将在 WLS 群集上部署和运行该应用程序以进行故障转移测试。

该应用使用 WebLogic Server JDBC 会话持久性来存储 HTTP 会话数据。数据源 jdbc/WebLogicCafeDB 存储会话数据，以实现跨 WebLogic Server 群集启用故障转移和负载均衡。它配置了一个持久性架构，将应用程序数据 coffee 持久化在同一个数据源 jdbc/WebLogicCafeDB 中。

使用以下步骤生成和打包示例：

使用以下命令克隆示例存储库，并签出与本文对应的标记：
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
如果你看到一条关于 Detached HEAD 的消息，可以放心地忽略。
使用以下命令导航到示例目录，然后编译并打包示例：
```
cd weblogic-cafe
mvn clean package
```

成功生成包后，可以在 <parent-path-to-your-local-clone>/azure-cafe/weblogic-cafe/target/weblogic-cafe.war 找到它。如果没有看到该包，则必须先排查并解决问题，然后才能继续。

部署示例应用

现在，从主群集开始，使用以下步骤将示例应用部署到群集：

在 Web 浏览器的新选项卡中打开群集的 adminConsole。使用之前保存的 WebLogic 管理员的用户名和密码登录到 WebLogic Server 管理控制台。
在导航窗格中找到域结构>wlsd>部署。选择“部署”。
选择锁定并编辑>安装>上传文件>选择文件。选择之前准备的 weblogic-cafe.war 文件。
选择“下一步”>“下一步”>“下一步”。使用选项群集中的所有服务器选择 cluster1 作为部署目标。选择“下一步”>“完成”。选择激活更改。
切换到控制选项卡，然后从部署表中选择 weblogic-cafe。选择开始，选项为所有请求提供服务>为是。等待一段时间并刷新页面，直到看到部署状态 weblogic-cafe 为活动。切换到监视选项卡，并验证已部署应用程序的上下文根是否为 /weblogic-cafe。保持 WLS 管理控制台打开，以便稍后使用它进行进一步配置。

在 WebLogic Server 管理控制台中重复相同的步骤，但针对美国西部区域中的辅助群集。

更新前端主机

使用以下步骤使 WLS 群集能够识别 Azure 流量管理器。由于 Azure 流量管理器是用户请求的入口点，因此从主群集开始，将 WebLogic Server 群集的前端主机更新为流量管理器配置文件的 DNS 名称。

请确保已登录到 WebLogic Server 管理控制台。
在导航窗格中导航到域结构>wlsd>环境>群集。选择群集。
从群集表中选择 cluster1。
选择锁定并编辑>HTTP。删除前端主机的当前值，并输入前面保存的流量管理器配置文件的 DNS 名称，不带前导 http:// -例如，tmprofile-ejb120623.trafficmanager.net。选择保存>激活更改。

在 WebLogic Server 管理控制台中重复相同的步骤，但针对美国西部区域中的辅助群集。

配置事务日志存储

接下来，从主群集开始，为群集的所有托管服务器配置 JDBC 事务日志存储。此做法在使用事务日志文件恢复事务中进行了介绍。

在美国东部区域的主要 WLS 群集上使用以下步骤：

请确保已登录到 WebLogic Server 管理控制台。
在导航窗格中导航到域结构>wlsd>环境>服务器。选择“服务器”。
应会看到服务器 msp1、msp2 和 msp3 列在服务器表中。
选择msp1>服务>锁定并编辑。在事务日志存储下，选择 JDBC。
对于类型>数据源，选择 jdbc/WebLogicCafeDB。
确认前缀名称的值为 TLOG_msp1_，这是默认值。如果值不同，请将其更改为 TLOG_msp1_。
选择“保存”。
选择服务器>msp2，并重复相同的步骤，但前缀名称的默认值为 TLOG_msp2_。
选择服务器>msp3，并重复相同的步骤，但前缀名称的默认值为 TLOG_msp3_。
选择激活更改。

在 WebLogic Server 管理控制台中重复相同的步骤，但针对美国西部区域中的辅助群集。

重启主群集的托管服务器

然后，使用以下步骤重启主群集的所有托管服务器，以使更改生效：

请确保已登录到 WebLogic Server 管理控制台。
在导航窗格中导航到域结构>wlsd>环境>服务器。选择“服务器”。
选择控件选项卡。选择 msp1、msp2 和 msp3。选择关闭，选项工作完成时>为是。选择“刷新”图标。等待直到最后一个操作的状态值为任务已完成。应会看到所选服务器的状态值为关闭。再次选择刷新图标以停止状态监视。
再次选择 msp1、msp2 和 msp3。选择开始>是。选择“刷新”图标。等待直到最后一个操作的状态值为任务已完成。应会看到所选服务器的状态值为正在运行。再次选择刷新图标以停止状态监视。

停止辅助群集中的 VM

现在，使用以下步骤停止辅助群集中的所有 VM，使其处于被动状态：

在浏览器的新选项卡中打开 Azure 门户主页，然后选择所有资源。在筛选任何字段... 框中，输入在其中部署辅助群集的资源组名称，例如 wls-cluster-westus-ejb120623。
选择类型等于全部，以打开类型筛选器。对于值，请输入虚拟机。应看到一个匹配的条目。为值选择它。选择“应用”。应看到列出了 4 个 VM，包括 adminVM、mspVM1、mspVM2 和 mspVM3。
选择打开每个 VM。为每个 VM 选择停止并确认。
从 Azure 门户中选择通知图标，以打开通知窗格。
监视每个 VM 的事件停止虚拟机，直到值变为成功停止虚拟机。保持页面打开，以便以后可以将其用于故障转移测试。

现在，切换到浏览器选项卡，可在其中监视终结点的流量管理器的状态。刷新页面，直到看到终结点 myFailoverEndpoint 已降级，终结点 myPrimaryEndpoint 为联机。

注意

生产就绪型 HA/DR 解决方案可能希望通过让 VM 运行但只停止 VM 上运行的 WLS 软件来实现较低的 RTO。然后，在发生故障转移时，VM 将已经在运行，WLS 软件将需要更少的时间来启动。本文选择停止 VM，因为当 VM 启动时，Azure VM 上的 Oracle WebLogic Server 群集会自动启动 WLS 软件。

验证应用

由于主群集已启动并运行，因此它充当活动群集，并处理由流量管理器配置文件路由的所有用户请求。

在浏览器的新选项卡中打开 Azure 流量管理器配置文件的 DNS 名称，并附加已部署应用的上下文根 /weblogic-cafe，例如 http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe。创建一个带有名称和价格的新咖啡 - 例如，价格为 10 的咖啡 1。此条目被持久化到数据库的应用程序数据表和会话表中。看到的 UI 应该类似于以下屏幕截图：

如果 UI 看起来不相似，请排除故障并解决问题，然后继续。

保持页面打开，以便以后可以将其用于故障转移测试。

测试从主服务器故障转移到辅助服务器

若要测试故障转移，请手动将主数据库服务器和群集故障转移到辅助数据库服务器和群集，然后使用本节中的 Azure 门户进行故障回复。

故障转移到辅助站点

首先，使用以下步骤关闭主群集中的 VM：

找到在其中部署主 WLS 群集的资源组的名称 - 例如 wls-cluster-eastus-ejb120623。然后按照停止辅助群集中的 VM 部分中的步骤操作，但将目标资源组更改为主 WLS 群集，以停止该群集中的所有 VM。
切换到流量管理器器的浏览器选项卡，刷新页面，直到看到终结点 myPrimaryEndpoint 的监视状态值变为已降级。
切换到示例应用的浏览器选项卡并刷新页面。应会看到 504 网关超时或 502 错误的网关，因为无法访问任何终结点。

接下来，使用以下步骤将 Azure SQL 数据库从主服务器故障转移到辅助服务器：

切换到 Azure SQL 数据库故障转移组的浏览器选项卡。
选择故障转移>是。
等待它完成。

然后，使用以下步骤启动辅助群集中的所有服务器：

切换到浏览器选项卡，可在其中停止辅助群集中的所有 VM。
选择 VM adminVM。选择开始。
在通知窗格中监视 adminVM 的正在启动虚拟机事件，并等待值变为已启动虚拟机。
切换到辅助群集的 WebLogic Server 管理控制台的浏览器选项卡，然后刷新页面，直到看到登录的欢迎页面。
切换回浏览器选项卡，其中列出了辅助群集中的所有 VM。对于 VM mspVM1、mspVM2 和 mspVM3，选择每个 VM 将其打开，然后选择开始。
对于 VM mspVM1、mspVM2 和 mspVM3，在通知窗格中监视正在启动虚拟机事件，并等待值变为已启动虚拟机。

最后，在终结点 myFailoverEndpoint 处于联机状态后，使用以下步骤验证示例应用：

切换到流量管理器的浏览器选项卡，然后刷新页面，直到看到终结点 myFailoverEndpoint 的监视状态值进入联机状态。
切换到示例应用的浏览器选项卡并刷新页面。你应该在应用程序数据表和 UI 中显示的会话表中看到相同的数据，如以下屏幕截图所示：

如果未观察到此行为，可能是因为流量管理器需要时间来更新 DNS 以指向故障转移站点。问题也可能是浏览器缓存了指向故障站点的 DNS 名称解析结果。等待一段时间，然后再次刷新页面。

注意

生产就绪型 HA/DR 解决方案将负责定期将 WLS 配置从主群集持续复制到辅助群集。有关如何执行此操作的信息，请参阅本文末尾的 Oracle 文档参考。

若要自动执行故障转移，请考虑对流量管理器指标和 Azure 自动化使用警报。有关详细信息，请参阅流量管理器指标和警报的流量管理器指标的警报部分和使用警报触发 Azure 自动化 runbook。

故障回复到主站点

使用故障转移到辅助站点部分中的相同步骤，故障回复到主站点，包括数据库服务器和群集，但存在以下差异：

首先，关闭辅助群集中的 VM。应会看到终结点 myFailoverEndpoint 已降级。
接下来，将 Azure SQL 数据库从辅助服务器故障转移到主服务器。
然后，启动主群集中的所有服务器。
最后，在终结点 myPrimaryEndpoint 为联机后验证示例应用。

清理资源

如果不打算继续使用 WLS 群集和其他组件，请使用以下步骤删除资源组以清理本教程中使用的资源：

在 Azure 门户顶部的搜索框中输入 Azure SQL Database 服务器的资源组名称（例如 myResourceGroup），并从搜索结果中选择匹配的资源组。
选择“删除资源组”。
在输入资源组名称以确认删除中，输入资源组名称。
选择“删除”。
对流量管理器的资源组重复步骤 1-4，例如 myResourceGroupTM1。
对主 WLS 群集的资源组重复步骤 1-4，例如 wls-cluster-eastus-ejb120623。
对辅助 WLS 群集的资源组重复步骤 1-4，例如 wls-cluster-westus-ejb120623。