通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在 Azure 上重新搭建 AIX 工作负荷的平台

Azure 应用程序网关
Azure 文件
Azure 虚拟机
Azure 通信服务
Azure 应用程序服务

本文介绍在云端为 AIX 工作负荷更换平台的迁移方法。 可以使用 Azure Functions 来实现无服务器体系结构，也可以使用 Azure 虚拟机来保留有服务器的模式。

在将旧版应用程序迁移到 Azure 时，请考虑 AIX 工作负荷的更换平台迁移策略，以便最大限度地提高投资回报 (ROI)。 更换平台迁移只需进行最少的改动，却能带来与重构迁移类似的云原生优势。

更换平台迁移的好处包括：

  • 更低的总拥有成本 (TCO)。
  • 更高的业务敏捷性。
  • 提高了运营复原能力。

体系结构（已更换平台）

已重新建模的体系结构的关系图。

下载此体系结构的 Visio 文件 。

工作流

此工作流与前述体系结构相对应。

  1. 用户请求和入站 API 集成通过 TCP/443 (HTTPS) 传输到 Azure 应用程序网关，该网关提供 Web 应用程序防火墙 (WAF) 功能。 应用程序网关会将请求作为反向代理请求发送到 Red Hat JBoss 企业应用程序平台 (EAP) 上托管的各种服务。

  2. Java Web 服务会询问 Oracle 数据库 (TCP/1521)。 同步 Web 请求响应时间小于 50 毫秒 (ms)。

  3. 异步请求（如计划批处理任务）会在数据库表中放置一条记录，而数据库表则充当应用程序层中的队列。

    注意

    未来，Azure 队列存储将取代数据库表，因此可以随时访问正在运行的分析作业。

  4. 以 KornShell (ksh) 脚本编写的 cron 作业会被移植到 Bash，并在 Azure 虚拟机规模集中的独立 Red Hat Enterprise Linux (RHEL) 服务器上运行。 cron 作业每 15 分钟运行一次（包括在系统启动时），以查询 Oracle 数据库中的队列。 每个主机一次运行一个作业。 虚拟机规模集可对长期运行的分析工作进行并行处理。 此解决方案不要求在非高峰期进行批处理，以限制在工作时间对系统性能的影响。

  5. Azure 通信服务通过 Azure CLI 工具 (docs) 发送电子邮件警报。 Azure 系统分配的托管标识（如 az login --identity）可对虚拟机 (VM) 进行身份验证。

  6. 分析作业结果通过安全 SMBv3 (TCP/445) 传输到 Azure 文件存储共享，该共享也会使用系统分配的托管标识。

组件

  • Microsoft Entra ID 可消除基于网络的信任，并提供系统分配的托管标识，从而提高安全性。

  • Azure 应用服务 无需管理作系统和服务器，从而提高运营效率和业务敏捷性。

  • 应用程序网关 是一项完全托管且可缩放的服务，可提供 Web 应用程序防火墙和反向代理功能。

  • Azure 文件 存储提供通过托管服务发布的数据报告。

  • Azure Functions 是事件驱动的无服务器计算平台，用于以指定的编程语言高效开发代码。

  • Oracle 数据库和 SAS 分析节点使用 Azure 虚拟机 。

  • Azure 计算库 生成并存储 Oracle 数据库和 SAS 分析节点的映像。 共有两个库：一个在主要区域中，另一个在灾难恢复区域中。

  • 通信服务 使用 CLI 实用工具发送电子邮件。 此服务取代了 AIX 上的 mailx 命令。

备选方法

另一种方法是采用完整的服务器体系结构，它会保留所有中间件组件。

此解决方案类似于原始体系结构，它满足 类似于 许多 IT 组织运营的任务。 此替代解决方案的成本也与原始体系结构大致相同，但无法提供更换平台体系结构所能带来的优势。 例如：

  • 节省许可费用：替代解决方案保留了 WebSphere，并增加了更多的 RHEL 节点。

  • 运营效率：替代解决方案需要维护的服务器数量相同。

  • 业务敏捷性：借助替代解决方案，报告仍仅限于夜间，且无法进行自动缩放的全天分析。

方案详细信息

根据现有应用程序的可移植性以及团队的工作流程偏好和技术路线图，选择无服务器模式或有服务器模式。

与 原始体系结构一样， 重新构建的体系结构 具有 Oracle 数据库，但它被重新格式化为 Azure 虚拟机上的 RHEL作系统。 对于已更换平台的体系结构中完全托管的 Azure 应用程序服务，Red Hat JBoss EAP 取代了 WebSphere Java 应用程序。

体系结构（原始）

原始体系结构的关系图。

下载此体系结构的 Visio 文件 。

工作流

此工作流与前述体系结构相对应。

  1. 用户请求和入站 API 集成通过 TCP/443 (HTTPS) 传输到本地 F5 负载平衡器，然后反向代理到各种 IBM WebSphere 托管的 Java Web 服务。

  2. Java Web 服务通过 TCP/1521 询问 Oracle 数据库。 在大多数情况下，同步 Web 请求响应时间小于 1 秒（秒），但根据测试和 Weblog 分析，超过 300 毫秒。

  3. 异步请求（如计划批处理任务）会在 Oracle 数据库表中放置一条记录，而数据库表则充当应用程序层中的队列。

  4. 以 ksh 脚本编写的 cron 作业会查询 Oracle 数据库中的队列，并挑选要运行的 SAS 分析作业。 客户必须在夜间进行批处理，以限制在工作时间对系统性能的影响。

  5. 电子邮件警报通过 SMTP (TCP/25) 通知用户和管理员作业开始和完成时间以及成功或失败结果。

  6. 分析工作结果通过 NFS (TCP+UDP/111,2049) 传输到共享驱动器，然后通过 SMBv3 (TCP/445) 进行收集。

方案详细信息

此原始体系结构会评估在 IBM WebSphere 上运行的单体 Java 应用程序，并评估由 ksh 脚本协调的 SAS 中的批处理。 在独立 AIX 主机上运行的 Oracle 数据库可同时支持两种应用程序工作负荷。

考虑在 AIX 上运行的原始工作负荷，以确定替换平台迁移策略是否适合迁移预算。 从所期望的结果出发，逆向确定以应用程序为中心的转型云迁移路径。 确保大部分应用程序代码都是采用云原生服务（如无服务器体系结构和容器业务流程协调程序）支持的语言编写的。

在此方案中， Tidal Accelerator 分析了 Java 应用程序代码，并确定其与 JBoss EAP 的兼容性。 在项目早期，Azure Pipelines 或 GitHub Actions 会被用来重新生成应用程序作为试点。 然后，客户可以在 Azure 应用程序服务等托管服务中通过持续集成和持续交付 (CI/CD) 管道建立敏捷性。 客户无法在其本地 WebSphere 环境中获得这种功能。

此示例保留了此阶段中的 Oracle 数据库，因为 Tidal Accelerator 在分析阶段发现了大量 PL/SQL。 客户未来的努力包括从 RHEL 上的 Oracle 数据库迁移到完全托管的 Azure Database for PostgreSQL 数据库，采用 Azure 队列存储，以及运行完全按需的 SAS 作业。 这些工作与客户的技术路线图、开发周期以及应用程序负责人访谈中确定的业务方向保持一致。 以下屏幕截图显示了 Tidal Accelerator 中的一次面试。

潮汐加速器中面试的屏幕截图。

可能的用例

可以使用此体系结构将 AIX 迁移到 Azure，其中包括数据分析、客户关系管理 (CRM)、混合云配置中的大型机集成层以及库存和仓库管理方案中的其他定制软件解决方案。

可以将此体系结构用于采用以下技术的传统应用程序工作负荷：

  • Oracle Siebel
  • Oracle 电子商务套件
  • SAS
  • IBM BPM

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性设计评审清单。

该体系结构使用 Azure Site Recovery 将数据库 Azure VM 镜像到次要 Azure 区域，以便在整个 Azure 区域发生故障时进行快速故障转移和灾难恢复。 同样，Azure 文件存储使用异地冗余存储。

数据处理节点使用区域冗余 (RA-ZRS) 托管磁盘在区域中断时提供复原能力。 在整个区域中断期间，可以从冗余 Azure Compute Gallery 中的 VM 映像在不同区域重新配置数据处理节点。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全设计评审清单。

此体系结构采用不可变的基础结构方法进行应用程序部署，并会主动扫描 Azure 管道中的代码，以帮助确保生产中敏感数据的安全。 它整合 了一种用于安全扫描的左移 方法，并经常运行启用了 CI/CD 管道的部署，以提高软件当前遵循性并减少技术债务。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

此解决方案可尽量减少服务器组件，从而将运营成本降低 70% 以上。 这种体系结构可降低计算和软件许可成本。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅 针对卓越运营的设计评审清单。

产品团队可在 Azure 中为自己提供支持，从而缩短了所上报事件工单的解决时间。 此外，由于一个产品团队支持 Azure 中的整个应用程序堆栈，因此工单的退回次数或从一个小组分配到另一个小组的工单数量为零。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅 性能效率的设计评审清单。

客户尽可能采用 Azure 应用服务，以便他们可以自动 纵向扩展和横向扩展 其计算要求，以满足应用程序需求。 这种弹性可确保在高峰期保持稳定的应用程序性能。 这种方法也具有成本效益。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

理查德·贝瑞 |项目经理

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

有关使用 Tidal Accelerator 解决方案的详细信息， 请联系Microsoft Tidal Cloud 团队。

有关迁移到 Azure 的详细信息， 请联系旧版迁移工程团队。