WebLogic 管理服务器的多可用区高可用性自动化：第一部分

作者：Jack Zhou Robin Geddes Sami Hoda 和 Tony Ten Broeck 于 2023 年 9 月 22 日发表在：Amazon EC2，Architecture，AWS Lambda永久连结

关键要点

WebLogic 管理服务器的重要性：用于域配置和管理应用性能。高可用性挑战：动态云设置中更换管理服务器会导致 IP 地址更改，影响连接。解决方案总览：使用浮动虚拟 IP 实现高可用性，配合 Auto Scaling 和 Lambda 函数自动更新路由表。

WebLogic Server 是企业用来运行生产工作负载的重要平台，包括 Oracle EBusiness Suite (EBS) 和 Oracle Fusion Middleware 应用程序。客户应用程序通常部署在 WebLogic Server 实例管理服务器上，并通过一个称为领域的逻辑组织单位的管理服务器进行管理。管理服务器的集群提供了应用可用性和水平扩展，而单实例的管理服务器则不托管应用。

本篇文章展示了使用可用区 (AZ) 和浮动 IP 地址实现“扩展集群” Oracle 的术语的架构与实施方法。

问题概述

WebLogic 管理服务器在领域配置、管理、监控应用性能和系统健康方面至关重要。历史上，WebLogic 通过 IP 地址进行配置，管理服务器在失去连接时会缓存管理服务器的 IP 地址以便重新连接。

在动态云环境中，这会引发两个主要问题： 域内通信：管理服务器与受管服务器之间通过 T3 协议通信，基于 Java RMI。 远程访问管理控制台：如何允许互联网管理访问以及所需的额外安全控制超出了本篇文章的范围。

在这里，我们将探讨如何最小化停机时间，实现管理服务器的高可用性。

解决方案概述

客户可以采取以下三种方案： 使用浮动虚拟 IPVIP保持地址静态。此方案对于 WebLogic 管理员来说是较为熟悉的，因为它复制了传统的本地高可用性实现。本文的剩余部分将深入探讨这种实用实现。 使用DNS解析管理服务器 IP 地址。这也受到支持，相关配置将在第二部分中详细讨论。 以“无头配置”运行，不通常运行管理服务器： 使用 WebLogic 脚本工具进行命令操作。 通过其他工具收集和观察指标。

“无头”运行需要较高的操作成熟度，并且可能不兼容某些打包应用程序在 WebLogic 上部署。

使用浮动 IP 地址为 WebLogic 管理服务器

这里，我们讨论在 AWS 上的参考 WebLogic 部署架构，如图 2 所示。

在这个例子中，WebLogic 域位于一个虚拟私有云 (VPC) 的私有子网中。管理服务器在各自的 Amazon Elastic Compute Cloud (Amazon EC2) 实例上，绑定到跨多个 AZ 的私有 IP 100118。实现这一目标有两种方式： 在 VPC 内创建一个“虚拟”子网可以在任何 AZ，最小子网大小为 /28。排除前四个和最后一个保留的 IP 地址，选择一个地址。以 100110/28 为例，我们使用100118并配置 WebLogic 管理服务器绑定到该地址。 使用一个位于 VPC 外部的 IP 地址。我们将在“多 AZ 浮动 IP 的替代解决方案”部分讨论第二种方法并比较两个过程。

通过这种方式，创建一个包含一个 WebLogic 域和一个管理服务器的 Amazon Web Services 的伸展架构： 在两个或多个 AZ 之间创建一个 VPC，为每个 AZ 创建一个用于管理服务器的私有子网以及一个额外的“虚拟”子网。 创建两个 EC2 实例，每个 WebLogic 管理服务器对应一个分布在私有子网中。 使用 Auto Scaling 组确保只有一个管理服务器在运行。 为管理服务器创建一个 Amazon EC2 启动模板。 将启动模板与 Auto Scaling 组关联，其最小、最大和期望容量均为 1。如果当前实例故障，Auto Scaling 组 (ASG) 将自动检测 EC2 和/或 AZ 降级，并在不同的 AZ 中启动新实例。 创建一个 AWS Lambda 函数后面示例会说明，由 Auto Scale 组生命周期钩子调用，以更新路由表。 更新启动模板的用户数据命令示例会后面提供以： 将浮动 IP 地址添加到网络接口 使用浮动 IP 启动管理服务器

要将流量路由到浮动 IP，我们需要更新公共和私有子网的路由表。

飞鱼 加速器

我们创建一个 Lambda 函数，自动在新管理实例创建时，由 Auto Scale 组生命周期钩子启动。该 Lambda 代码会更新两个路由表中的路由规则，将“浮动” IP 的虚拟子网 CIDR (100110/28) 映射到管理 Amazon EC2。这样一来，就可以为动态启动的管理服务器更新公共和私有子网的路由，确保管理服务器能够连接。

启用对管理服务器的互联网访问

如需启用互联网访问，创建一个与公共子网相连的互联网应用负载均衡器 (ALB)。通过指向管理服务器的路由，ALB 可以将流量转发给管理服务器。

创建一个基于 IP 的目标组，指向浮动 IP。在 ALB 中添加转发规则，将 WebLogic 管理流量路由到管理服务器。在启动模板中的用户数据命令使管理服务器可在 ASG 扩展时访问

在管理服务器的 EC2 启动模板中，添加用户数据代码以监控 ASG 生命周期状态。当其达到 InService 状态时，将调用 Lambda 函数更新路由表。接着，脚本会启动 WebLogic 管理服务器的 Java 进程以及相关的 NodeManager，若已使用。

需要将管理服务器实例的 SourceDestCheck 属性设置为 false，以便能够绑定到逻辑 IP。此更改也可以在 Lambda 函数中完成。

当用户通过互联网访问管理服务器时：1 流量流向与互联网负载均衡器相连的弹性 IP 地址。2 ALB 将该流量转发至配置信息的目标组。3 ALB 使用更新过的路由访问 100118管理服务器。

当管理服务器与管理服务器通信时，它们使用更新过的路由表来访问 100118管理服务器。

Lambda 函数示例

以下是一个示例 Lambda 函数，设置 EC2 实例的 SourceDestCheck 属性为 false，并更新两个公共和私有路由表中虚拟子网 CIDR管理服务器 EC2 的“浮动” IP的路由规则。

javascriptimport { AutoScalingClient CompleteLifecycleActionCommand } from @awssdk/clientautoscalingimport { EC2Client DeleteRouteCommand CreateRouteCommand ModifyInstanceAttributeCommand } from @awssdk/clientec2

export const handler = async (event context callback) =gt { consolelog(LogAutoScalingEvent) consolelog(Received event JSONstringify(event null 2))

// 重要：替换为浮动 IP 所在的虚拟子网 CIDRconst destCIDR = 100110/28// 重要：替换为你的路由表 IDconst rtTables = [rtbff0 rtbaf5]const asClient = new AutoScalingClient({region eventregion})const eventDetail = eventdetailconst ec2client = new EC2Client({region eventregion})const inputModifyAttr = {    SourceDestCheck {        Value false    }    InstanceId eventDetail[EC2InstanceId]}const commandModifyAttr = new ModifyInstanceAttributeCommand(inputModifyAttr)await ec2clientsend(commandModifyAttr)// 修改两个路由表中的路由for (const rt of rtTables) {    const inputDelRoute = { // DeleteRouteRequest        DestinationCidrBlock destCIDR        DryRun false        RouteTableId rt // 必需项    }    const cmdDelRoute = new DeleteRouteCommand(inputDelRoute)    try {        const response = await ec2clientsend(cmdDelRoute)        consolelog(response)    } catch (error) {        consolelog(error)    }    const inputCreateRoute = { // addRouteRequest        DestinationCidrBlock destCIDR        DryRun false        InstanceId eventDetail[EC2InstanceId]        RouteTableId rt // 必需项    }    const cmdCreateRoute = new CreateRouteCommand(inputCreateRoute)    await ec2clientsend(cmdCreateRoute)}// 继续 ASG 生命周期const params = {    AutoScalingGroupName eventDetail[AutoScalingGroupName] / 必需项 /    LifecycleActionResult CONTINUE / 必需项 /    LifecycleHookName eventDetail[LifecycleHookName] / 必需项 /    InstanceId eventDetail[EC2InstanceId]    LifecycleActionToken eventDetail[LifecycleActionToken]}const cmdCompleteLifecycle = new CompleteLifecycleActionCommand(params)const response = await asClientsend(cmdCompleteLifecycle)consolelog(response)return response

}

Amazon EC2 用户数据

在 Amazon EC2 用户数据中添加以下代码，以将逻辑辅助 IP 地址添加到 Amazon EC2 的主弹性网络接口 (ENI)，不断轮询 ASG 生命周期状态，并在 Amazon EC2 进入 InService 状态时启动管理服务器 Java 进程。

shellContentType text/xshellscript charset=usasciiMIMEVersion 10ContentTransferEncoding 7bitContentDisposition attachment filename=userdatatxt

!/bin/bash

ip addr add 100118/28 br 10011255 dev eth0TOKEN=(curl X PUT http//169254169254/latest/api/token H Xawsec2metadatatokenttlseconds 21600)for x in {130}do targetstate=(curl H Xawsec2metadatatoken TOKEN v http//169254169254/latest/metadata/autoscaling/targetlifecyclestate) if [ targetstate = InService ] then su c nohup /mnt/efs/wls/fmw/install/Oracle/Middleware/OracleHome/userprojects/domains/domain1/bin/startWebLogicsh amp ec2user break fi sleep 10done

多 AZ 浮动 IP 的替代解决方案

浮动 IP 的另一种替代方案是使用位于 VPC 外部的 IP。ASG、Amazon EC2 启动模板和 ASG 生命周期钩子 Lambda 函数的配置保持不变。但因需要 VPC 内部子网，ALB 无法从互联网访问 WebLogic 管理控制台应用程序。要在此情况下访问 Web 应用程序，可以在公共子网中建立一个堡垒主机。

虽然这种方法避免了虚拟子网，从而“节省”了16个 VPC IP 地址，但存在一些缺点： 堡垒主机并非 AZ 故障弹性。 缺乏第一种解决方案的真正多 AZ 弹性。 需要额外的成本与管理多 AZ 或 VPN 堡垒主机的复杂性。

结论

AWS 在运行 Oracle 应用程序、Oracle EBS、PeopleSoft 和关键的 JEE 工作负载方面具有良好的声誉。在本篇文章中，我们探讨了通过使用多可用区浮动 IP 为 WebLogic 管理服务器实现高可用性解决方案，以及运用 ASG 确保仅有一个管理服务器在运行。我们演示了如何使用 ASG 生命周期钩子和 Lambda 自动化浮动 IP 的路由更新，同时配置 ALB 以允许互联网访问管理服务器。该解决方案实现了 WebLogic 管理服务器的多可用区弹性与自动恢复，将传统的 WebLogic 管理服务器从“宠物”转变为“牛群”。

进一步阅读

请查看第二部分：使用 DNS 自动化多可用区 WebLogic 管理服务器的高可用性！

作者简介

Jack Zhou：AWS 全球公共部门的高级解决方案架构师，帮助全球咨询合作伙伴建立长期、盈利的 AWS 业务。此前，他是高级技术客户经理，管理高端企业支持账户。

Robin Geddes：专注于 Oracle 技术与应用程序的 AWS 迁移专家。

Sami Hoda：AWS 高级解决方案架构师，专注于全球公共部门的合伙人咨询。Sami 热爱可以利用设计思维、创新和情感智能相结合来为有需要的人解决问题的项目。

Tony Ten Broeck：AWS 高级解决方案架构师，专注于公共部门。他致力于通过实用解决方案产生积极影响，并强调有效性与良好判断力，或称之为“尽量减少愚蠢行为”。