教程:将 Oracle WebLogic Server 迁移到具有高可用性和灾难恢复的 Azure 虚拟机
本教程介绍如何在 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。
- 安装 Java SE 实现版本 17 或更高版本(例如 OpenJDK 的Microsoft版本)。
- 安装 Maven 版本 3.9.3 或更高版本。
在配对区域中设置Azure SQL 数据库故障转移组
在本部分中,将在配对区域中创建一个Azure SQL 数据库故障转移组,用于 WLS 群集和应用。 在后面的部分中,将 WLS 配置为将其会话数据和事务日志 (TLOG) 数据存储到此数据库。 这种做法与 Oracle 的最大可用性体系结构(MAA)保持一致。 本指南提供适用于 MAA 的 Azure 适应。 有关 MAA 的详细信息,请参阅 Oracle 最大可用性体系结构。
首先,按照快速入门中的Azure 门户步骤创建主Azure SQL 数据库:创建单一数据库 - Azure SQL 数据库。 按照步骤执行,但不包括“清理资源”部分。 在浏览本文时,请使用以下说明,然后在创建并配置Azure SQL 数据库后返回到本文:
到达“创建单一数据库”部分时,请使用以下步骤:
- 在创建新资源组的步骤 4 中,请保存 资源组名称 值,例如 myResourceGroup。
- 在步骤 5 中, 保存数据库名称 值 - 例如 mySampleDatabase。
- 在创建服务器的步骤 6 中,使用以下步骤:
- 请保存唯一的服务器名称 - 例如 sqlserverprimary-ejb120623。
- 对于“位置”,请选择“(美国)美国东部”。
- 对于 身份验证方法,请选择“ 使用 SQL 身份验证”。
- 保存服务器管理员登录值 - 例如 azureuser。
- 将密码值保存到一边。
- 在步骤 8 中,对于 工作负荷环境,请选择“ 开发”。 查看说明,并考虑工作负荷的其他选项。
- 在步骤 11 中,对于 备份存储冗余,请选择“ 本地冗余备份存储”。 请考虑备份的其他选项。 有关详细信息,请参阅 Azure SQL 数据库 中自动备份的“备份存储冗余”部分。
- 在步骤 14 的防火墙规则配置中,对于“允许 Azure 服务和资源访问此服务器”,请选择“是”。
到达“查询数据库”部分时,请使用以下步骤:
在步骤 3 中,输入 SQL 身份验证 服务器管理员登录信息以登录。
注意
如果登录失败,出现类似于 IP 地址为“xx.xx.xx.xx.xx”的客户端无法访问服务器的错误消息,请在错误消息末尾选择 服务器 <your-sqlserver-name> 上的 Allowlist IP xx.xx.xx.xx。 等待服务器防火墙规则完成更新,然后再次选择“ 确定 ”。
在步骤 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 数据库故障转移组后返回到本文:
到达“创建故障转移组”部分时,请使用以下步骤:
- 在创建故障转移组的步骤 5 中,选择用于创建新的辅助服务器的选项,然后使用以下步骤:
- 输入并保存故障转移组名称 - 例如 failovergroupname-ejb120623。
- 输入并保存唯一的服务器名称 - 例如 sqlserversecondary-ejb120623。
- 输入与主服务器相同的服务器管理员和密码。
- 对于 “位置”,请选择与用于主数据库的区域不同的区域。
- 确保 已选择“允许 Azure 服务访问服务器 ”。
- 在步骤 5 中,若要配置 组中的数据库,请选择在主服务器中创建的数据库,例如 mySampleDatabase。
- 在创建故障转移组的步骤 5 中,选择用于创建新的辅助服务器的选项,然后使用以下步骤:
完成“测试计划的故障转移”部分中的所有步骤后,请保持故障转移组页处于打开状态,并在以后将其用于 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。
- 对于 DataSource 连接字符串,请将占位符替换为在主SQL 数据库的上一节中保存的值 - 例如 jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433;database=mySampleDatabase。
- 对于 全局事务协议,请选择“ 无”。
- 对于数据库用户名,请将占位符替换为在主SQL 数据库的上一节中保存的值,例如,azureuser@sqlserverprimary-ejb120623。
- 输入以前为 数据库密码保存的服务器管理员登录密码。 为 “确认密码”输入相同的值。
- 保留其他字段的默认值。
- 选择“查看 + 创建”。
- 等到 运行最终验证... 成功完成,然后选择“ 创建”。
过了一会儿,应会看到 “部署 ”页,其中 显示了部署正在进行 中。
注意
如果在运行最终验证期间 看到任何问题...,请修复这些问题,然后重试。
根据所选区域中的网络条件和其他活动,部署最长可能需要 50 分钟才能完成。 之后,应会看到 部署完成后 会显示在部署页上的文本。
同时,可以并行设置辅助 WLS 群集。
设置辅助 WLS 群集
按照与在“设置主要 WLS 群集”部分相同的步骤,在“美国西部”区域设置辅助 WLS 群集,但存在以下差异:
在 “基本信息 ”窗格中,使用以下步骤:
- 在“资源组”字段中,选择“新建”并填写资源组的不同唯一值,例如 wls-cluster-westtus-ejb120623。
- 在“实例详细信息”下,选择“美国西部”。
在 “网络 ”窗格中,使用以下步骤:
对于 “编辑虚拟网络”,请输入与主 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 群集。
对于
wls-subnet
,请输入与主 WLS 群集相同的起始地址和子网大小 ,例如 10.1.5.0 和 /28。
在“ 数据库 ”窗格中,使用以下步骤:
- 对于 DataSource 连接字符串,请将占位符替换为在上一部分中为辅助SQL 数据库保存的值 - 例如 jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433;database=mySampleDatabase。
- 对于数据库用户名,请将占位符替换为在上一部分中为辅助SQL 数据库保存的值,例如,azureuser@sqlserversecondary-ejb120623。
镜像两个群集的网络设置
在故障转移后恢复辅助 WLS 群集中挂起的事务的阶段,WLS 会检查 TLOG 存储的所有权。 若要成功通过检查,辅助群集中的所有托管服务器必须与主群集具有相同的专用 IP 地址。
本部分介绍如何将网络设置从主群集镜像到辅助群集。
首先,使用以下步骤在部署完成后为主群集配置网络设置:
在“部署”页的“概述”窗格中,选择“转到资源组”。
选择网络接口
adminVM_NIC_with_pub_ip
。- 在“设置”下选择“IP 配置”。
- 选择
ipconfig1
。 - 在“专用 IP 地址设置”下,选择“静态”进行分配。 将专用 IP 地址保存到一边。
- 选择“保存”。
返回到主 WLS 群集的资源组,然后对网络接口
mspVM1_NIC_with_pub_ip
重复步骤 3,mspVM2_NIC_with_pub_ip
然后mspVM3_NIC_with_pub_ip
重复步骤 3。等待所有更新完成。 可以选择Azure 门户中的通知图标以打开“通知”窗格进行状态监视。
返回到主 WLS 群集的资源组,然后复制类型 为专用终结点 的资源的名称, 例如 7e8c8bsaep。 使用该名称查找剩余网络接口 - 例如 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a。 选择它并按照上述步骤获取其专用 IP 地址。
然后,使用以下步骤在部署完成后配置辅助群集的网络设置:
在“部署”页的“概述”窗格中,选择“转到资源组”。
对于网络接口、
mspVM1_NIC_with_pub_ip
和adminVM_NIC_with_pub_ip
mspVM2_NIC_with_pub_ip
mspVM3_NIC_with_pub_ip
,请按照前面的步骤将专用 IP 地址分配更新为 Static。等待所有更新完成。
对于网络接口
mspVM1_NIC_with_pub_ip
,mspVM2_NIC_with_pub_ip
请mspVM3_NIC_with_pub_ip
执行前面的步骤,但将专用 IP 地址更新为与主群集一起使用的相同值。 等待网络接口的当前更新完成,然后再继续下一个。注意
无法更改属于专用终结点的网络接口的专用 IP 地址。 若要轻松镜像托管服务器的网络接口的专用 IP 地址,请考虑将专用 IP 地址
adminVM_NIC_with_pub_ip
更新为不使用的 IP 地址。 根据两个群集中专用 IP 地址的分配,可能需要更新主群集中的专用 IP 地址。
下表显示了镜像两个群集的网络设置的示例:
群集 | 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 应用程序网关后端池:
群集 | Azure 应用程序网关后端池 | 后端目标(之前) | 后端目标(之后) |
---|---|---|---|
主要节点 | myGatewayBackendPool |
(10.1.5.5 、、10.1.5.6 10.1.5.8 ) |
(10.1.5.5 、、10.1.5.6 10.1.5.9 ) |
次要 | myGatewayBackendPool |
(10.1.5.7 、、10.1.5.4 10.1.5.6 ) |
(10.1.5.5 、、10.1.5.6 10.1.5.9 ) |
若要自动执行网络设置镜像,请考虑使用 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 流量管理器后返回到本文。
当到达“创建流量管理员配置文件”部分时,请使用以下步骤:
- 在步骤 2 创建流量管理员配置文件中,使用以下步骤:
- 保存名称的唯一流量管理员配置文件名称 - 例如 tmprofile-ejb120623。
- 保存资源组的新资源组名称 - 例如 myResourceGroupTM1。
- 在步骤 2 创建流量管理员配置文件中,使用以下步骤:
到达“添加流量管理员终结点”部分时,请使用以下步骤:
- 在步骤 “从搜索结果中选择配置文件”后执行此附加操作。
- 在“设置”下,选择“配置”。
- 对于 DNS 生存时间(TTL),请输入 10。
- 在“终结点监视器设置”下,输入 /weblogic/ready。
- 在“快速终结点故障转移设置”下,使用以下值:
- 对于 内部探测,请输入 10。
- 对于 允许的失败次数,请输入 3。
- 对于 探测超时, 为 5。
- 选择“保存”。 等待它完成。
- 在添加主终结点
myPrimaryEndpoint
的步骤 4 中,使用以下步骤:- 对于 目标资源类型,请选择 “公共 IP 地址”。
- 选择“选择公共 IP 地址”下拉列表,并输入之前保存在美国东部 WLS 群集中部署应用程序网关的 IP 地址。 应会看到匹配的一个条目。 为 公共 IP 地址选择它。
- 在添加故障转移/辅助终结点 myFailoverEndpoint 的步骤 6 中,使用以下步骤:
- 对于 目标资源类型,请选择 “公共 IP 地址”。
- 选择“选择公共 IP 地址”下拉列表,并输入之前保存在美国西部 WLS 群集中部署应用程序网关的 IP 地址。 应会看到匹配的一个条目。 为 公共 IP 地址选择它。
- 等待一段时间。 选择“刷新”,直到两个终结点的“监视”状态值处于联机状态。
- 在步骤 “从搜索结果中选择配置文件”后执行此附加操作。
到达“测试流量管理员配置文件”部分时,请使用以下步骤:
- 在小节 中检查 DNS 名称,使用以下步骤:
- 在步骤 3 中,请保存流量管理员配置文件的 DNS 名称,例如
http://tmprofile-ejb120623.trafficmanager.net
。
- 在步骤 3 中,请保存流量管理员配置文件的 DNS 名称,例如
- 在子节视图中流量管理员操作中,使用以下步骤:
- 在步骤 1 和步骤 3 中,将 /weblogic/ready 追加到 Web 浏览器中流量管理员配置文件的 DNS 名称,例如
http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready
。 应会看到一个空页,没有任何错误消息。 - 完成所有步骤后,请确保通过引用步骤 2 启用主终结点,但将“已禁用”替换为“已启用”。 然后返回到 “终结点 ”页。
- 在步骤 1 和步骤 3 中,将 /weblogic/ready 追加到 Web 浏览器中流量管理员配置文件的 DNS 名称,例如
- 在小节 中检查 DNS 名称,使用以下步骤:
现在,流量管理员配置文件中同时启用了终结点和联机终结点。 使页面保持打开状态,稍后将其用于监视终结点状态。
配置 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-café/weblogic-café/target/weblogic-café.war 中找到它<。> 如果没有看到该包,则必须先排查并解决问题,然后才能继续。
部署示例应用
现在,使用以下步骤将示例应用部署到群集,从主群集开始:
- 在 Web 浏览器的新选项卡中打开群集的 adminConsole 。 使用之前保存的 WebLogic 管理员的用户名和密码登录到 WebLogic Server 管理控制台。
- 在导航窗格中找到域结构>wlsd> 部署。 选择“部署”。
- 选择“锁定”和“编辑>安装>上传文件”。> 选择之前准备的 weblogic-café.war 文件。
- 选择“下一步”>“下一步”>“下一步”。 为部署目标选择
cluster1
群集中的所有服务器选项。 选择“下一步”>“完成”。 选择“ 激活更改”。 - 切换到 “控制 ”选项卡,然后从部署表中进行选择
weblogic-cafe
。 选择“开始”选项,为所有请求>提供服务是。 等待一段时间并刷新页面,直到看到部署weblogic-cafe
的状态处于活动状态。 切换到 “监视 ”选项卡,验证已部署应用程序的上下文根是否为 /weblogic-café。 使 WLS 管理控制台保持打开状态,以便稍后使用它进行进一步配置。
在 WebLogic Server 管理控制台中重复相同的步骤,但对于美国西部区域中的辅助群集。
更新前端主机
使用以下步骤使 WLS 群集能够识别Azure 流量管理器。 由于Azure 流量管理器是用户请求的入口点,因此从主群集开始,将 WebLogic Server 群集的 Front Host 更新为流量管理员配置文件的 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
。 选择“ 关闭 ”,选项 “工作完成>时为”是”。 选择刷新图标。 等到 “上次操作 ”值的状态为 “任务已完成”。 应会看到所选服务器的“状态”值为 SHUTDOWN。 再次选择刷新图标以停止状态监视。 - 选择
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,因为 Azure VM 上 Oracle WebLogic Server 群集部署的软件在 VM 启动时会自动启动 WLS 软件。
验证应用
由于主群集已启动并运行,因此它充当活动群集,并处理由流量管理员配置文件路由的所有用户请求。
在浏览器的新选项卡中打开Azure 流量管理器配置文件的 DNS 名称,并追加已部署应用的上下文根 /weblogic-café ,例如http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe
。 使用名称和价格创建新咖啡 - 例如,价格为 10 的 Coffee 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,
mspVM2
选择每个 VMmspVM1
将其打开,然后选择“开始mspVM3
”。 - 对于 VM,以及监视“通知”窗格中的事件“启动虚拟机”,并等待值变为“启动”虚拟机。
mspVM3
mspVM2
mspVM1
最后,使用以下步骤在终结点 myFailoverEndpoint
处于 联机 状态后验证示例应用:
切换到流量管理员的浏览器选项卡,然后刷新页面,直到看到终结点
myFailoverEndpoint
的“监视”状态值进入“联机”状态。切换到示例应用的浏览器选项卡并刷新页面。 应会看到应用程序数据表中保留的数据和 UI 中显示的会话表,如以下屏幕截图所示:
如果未观察到此行为,可能是因为流量管理员需要时间来更新 DNS 以指向故障转移站点。 问题也可能是浏览器缓存了指向失败站点的 DNS 名称解析结果。 等待一段时间,然后再次刷新页面。
注意
生产就绪的 HA/DR 解决方案将考虑定期将 WLS 配置从主群集持续复制到辅助群集。 有关如何执行此操作的信息,请参阅本文末尾对 Oracle 文档的引用。
若要自动执行故障转移,请考虑对流量管理员指标和Azure 自动化使用警报。 有关详细信息,请参阅流量管理员指标和警报流量管理员指标的警报部分,并使用警报触发Azure 自动化 Runbook。
故障回复到主站点
使用故障转移到辅助站点部分的相同步骤故障回复到主站点,包括数据库服务器和群集,但存在以下差异:
- 首先,关闭辅助群集中的 VM。 应会看到终结点
myFailoverEndpoint
已 降级。 - 接下来,将Azure SQL 数据库从辅助服务器故障转移到主服务器。
- 然后,启动主群集中的所有服务器。
- 最后,在终结点
myPrimaryEndpoint
为 Online 后验证示例应用。
清理资源
如果不打算继续使用 WLS 群集和其他组件,请使用以下步骤删除资源组以清理本教程中使用的资源:
- 在Azure 门户顶部的搜索框中输入Azure SQL 数据库服务器的资源组名称(例如
myResourceGroup
),并从搜索结果中选择匹配的资源组。 - 选择“删除资源组”。
- 在 输入资源组名称以确认删除时,输入资源组名称。
- 选择“删除”。
- 对流量管理员的资源组重复步骤 1-4 ,例如
myResourceGroupTM1
。 - 对主 WLS 群集的资源组重复步骤 1-4 , 例如
wls-cluster-eastus-ejb120623
。 - 对辅助 WLS 群集的资源组重复步骤 1-4 ,例如
wls-cluster-westus-ejb120623
。
后续步骤
在本教程中,你将设置一个 HA/DR 解决方案,该解决方案由具有主动-被动数据库层的主动-被动应用程序基础结构层组成,以及这两个层跨越两个地理上不同的站点。 在第一个站点中,应用程序基础结构层和数据库层都处于活动状态。 在第二个站点上,辅助域已关闭,辅助数据库处于备用状态。
继续浏览以下参考,以获取更多用于生成 HA/DR 解决方案并在 Azure 上运行 WLS 的选项:
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈