在 Azure 上部署 IBM Maximo Application Suite

IBM Maximo Application Suite (MAS) 8.x 在 OpenShift 上运行，熟悉 OpenShift 以及在 Azure 上安装的建议模式会有所帮助。 有关详细信息，请参阅准备在 Azure 上安装。 此体系结构演示 OpenShift 群集。 它并不会详细介绍如何安装 MAS。 若要了解有关安装过程的详细信息，请参阅从 OperatorHub 安装 Maximo Application Suite。

体系结构

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

工作负载可以部署在内部或面向外部，具体取决于需求。

工作流

从基础结构的角度来看，此体系结构提供以下内容：

• 容器托管平台，用于跨可用性区域部署高可用性工作负载
• 与存储集成的工作器节点和控制节点的私有化部署
• 用于存储的 Azure 高级文件存储和标准文件存储（不需要 OpenShift Data Foundation）
• Azure VM 上的 SQL Server 或基于容器的 IBM Db2 Warehouse
• 用于对 OpenShift 及其容器进行 DNS 管理的 Azure DNS
• 用于单一登录 (SSO) 到 MAS 的 Microsoft Entra ID

组件

• Azure 虚拟机，用于托管 OpenShift 平台并运行 Maximo 容器。 虚拟机是一种基础结构即服务 (IaaS) 产品/服务。 可以使用虚拟机来部署可按需缩放的计算资源。

• Red Hat Enterprise Linux CoreOS，用于为 OpenShift 提供自定义 VM 映像。

• Azure 负载均衡器，用于提供与群集的连接。 Azure 负载均衡器是一种适用于所有 UDP 和 TCP 协议的高性能、超低延迟第 4 层负载均衡服务（入站和出站）。 它构建用于处理每秒数百万个请求，同时确保解决方案高度可用。 Azure 负载均衡器是区域冗余的，可确保整个可用性区域的高可用性。

• 虚拟网络，用于节点之间的通信、Azure 服务和混合连接需求。 虚拟网络是 Azure 中专用网络的基本构建块。

• Azure 文件存储可托管群集内数据库和系统的有状态数据。 Azure 文件存储提供完全托管于云的文件共享，可通过 SMB 和 网络文件系统 (NFS) 协议进行访问。

• Azure DNS，用于管理解决方案内外容器的 DNS 解析。 Azure DNS 支持所有常见 DNS 记录，并提供高可用性。

• Azure Bastion（可选）和子网，用于增强对任何工作器节点或可选的 JumpBox 计算机的安全访问。 Azure Bastion 是一项完全托管服务，可针对 VM 提供无缝的、增强安全性的 RDP 和 SSH 访问，且完全无需通过公共 IP 地址公开。

• Azure 虚拟机中的 SQL Server（可选），用于向 MAS 提供数据服务。 数据库也可以是另外的数据库，例如 Oracle Exadata 或 IBM Db2 Warehouse。 目前还不支持 Azure SQL 数据库和 Azure SQL 托管实例。

• Twilio 发送网格（可选），以便从 MAS 向使用者发送电子邮件。

• Azure 中的 Linux 虚拟机（可选），以便为安装 OpenShift 提供跳转盒。 还可以使用此 VM 连接和管理 OpenShift 群集，因为其中包含安装后的 Kubernetes 配置文件。 如果 Azure 环境具有网络连接，则可以从现有计算机执行安装。

备选方法

通常不需要以下服务，但它们是有效的替代方案：

• Azure NetApp 文件作为 Azure 文件存储的替代项。 Azure NetApp 文件支持具有高可用性和高性能的任何类型的工作负载。
• Azure 上的 Oracle Database（如果首选的是 SQL Server 或 Db2 Warehouse）。
• OpenShift Data Foundation（如果要在 OpenShift Data Foundation 上使用 Db2 Warehouse）。

方案详细信息

IBM 的 Maximo Application Suite (MAS)，也称为 Maximo，是一个企业资产管理平台，具有基于 AI 的资产维护功能。 MAS 专注于运营复原能力和可靠性。 该套件包含核心应用平台、MAS 以及平台之上的应用程序和行业特定解决方案。 每个应用程序都提供特定优势：

• 管理。 使用资产管理来提高运营性能，从而减少故障时间和成本。
• 监视。 使用 IoT 对远程资产进行高级 AI 提供支持的大规模监视。
• 运行状况。 使用来自传感器、资产数据和维护历史记录的 IoT 数据来管理资产健康状况。
• 视觉检测。 训练机器学习模型，以使用视觉检测来直观分析新出现的问题。
• 预测。 使用机器学习和数据分析预测未来的故障。
• 帮助。 通过为设备维护数据的知识库提供 AI 所支持的指导并让技术人员可远程联系专家来为他们提供帮助。
• 安全。 从传感器收集和分析数据，提供上下文数据，并得出有意义的分析。
• 民用。 集成检查、缺陷跟踪和维护活动，用于帮助延长资产寿命、保持关键系统运行并降低民用基础设施的总拥有成本。

这些应用程序和 MAS 8.x 经过测试，以便在 Azure 上使用。 Microsoft 和 IBM Maximo 团队进行合作，以确保此解决方案配置为在 Azure 上以最佳方式运行。 本文提供了在 Azure 上运行 MAS 8.x 的设计，适用于获得 IBM 和合作伙伴安装支持的客户。 请联系 IBM 团队，了解特定于产品的问题。 Azure 市场为支持自带许可证的 MAS 提供替代安装。 有关更多信息，请参阅 IBM Maximo Application Suite（自带许可证 (BYOL)）。

可能的用例

许多行业和部门在 MAS 中使用解决方案，例如：

• 能源和公用事业
• 石油和天然气
• 制造
• 旅行、汽车与运输
• 公共部门

在 IBM 网站 IBM Maximo Application Suite 上查找有关 MAS 用例的更多信息。

建议

建议安装最新的稳定版 MAS，因为该版本提供了与 Azure 的极佳集成选项。 请密切关注支持的 OpenShift 版本，因为支持的版本因 MAS 的具体版本而异。

使用较旧或较新主版本的 OpenShift 可能会导致失去对 MAS 的官方支持。 在构建自己的部署之前，建议使用快速入门指南部署 MAS，以便了解部署和配置的工作原理。 了解此操作如何完成可加快确立实现设计要求的速度。 有关详细信息，请参阅快速入门指南：Azure 上的 Maximo Application Suite。

我们与 IBM 和其他合作伙伴密切合作，确保指南、体系结构和快速入门指南为你提供出色的 Azure 体验。 它们遵循 Microsoft Azure 架构良好的框架中所述的最佳做法。 请联系 IBM 帐户团队，获取本文档以外的支持。

在继续部署之前，需要回答以下有关设计的问题：

• 需要哪些 MAS 应用程序？
• 应用程序具有哪些依赖项？
• 需要哪种版本的 OpenShift？
• 应使用哪种 OpenShift 安装方法？
• 需要哪些数据库？
• 需要多少数量和大小的 VM？
• 用户是否会从外部网络进行连接？

Maximo Application Suite

Microsoft 已在 Azure 上测试 MAS 8.5 及更高版本。 建议使用最新版本的 MAS，即版本 8.7。

查看完整业务场景所需的 MAS 应用程序，然后查看各应用程序的要求。 有关详细信息，请参阅 IBM Maximo Application Suite 系统需求。 各应用程序可能需要单独的数据库。 我们已在 Azure 上测试以下数据库并支持这些数据库：

• 使用 Windows 或 Linux 的 Azure 虚拟机上的 SQL Server 2019 版
• 适用于 Data 3.5 的 Cloud Pak 上的 IBM Db2 Warehouse

还可以选择使用互连在 VM 或 Oracle 云基础结构上运行 Oracle Exadata，但这不是经过测试的配置。 有关互连的详细信息，请参阅 将 Oracle 云与 Microsoft Azure 互连。 目前，不支持 Azure SQL 数据库、Azure SQL 托管实例和 Azure Cosmos DB。

MAS 及其一些应用程序依赖于 MongoDB 和 Kafka。 请根据性能和操作方面的考虑，决定如何部署这些解决方案。 默认值是在群集内部署 MongoDB Community Edition 和 Strimzi Kafka。 MAS 的一些先决条件（例如 BAS）使用无法外部化但需要向 OpenShift 群集提供持久存储的数据库。

对于在 OpenShift 群集内运行的基于状态的服务，经常备份数据并将备份移动到另一个区域很有必要。 设计和计划一个恢复策略，以防灾难发生，并做出相应的决定，特别是在 OpenShift 中运行 Kafka 或 MongoDB 时。

对于保留状态的服务，请尽可能使用外部 Azure 平台即服务 (PaaS) 产品/服务。 这样做可以提高中断期间的可支持性。

某些服务可能需要其他 IBM 工具和服务，如 IBM Watson 机器学习和 IBM App Connect。 可以在同一 OpenShift 群集上部署所有工具和服务。

OpenShift

安装 OpenShift 之前，需要确定要使用哪种方法：

• 安装程序预配的基础结构 (IPI)。 此方法使用安装程序在 Azure 上部署和配置 OpenShift 环境。 PI 是在 Azure 上部署的最常用方法，并且应使用 IPI，除非安全要求过于严格。

• 用户预配的基础结构 (UPI)。 此方法支持对部署进行精细控制。 UPI 需要更多步骤和注意事项来生成环境。 如果 IPI 不符合需求，请使用 UPI。 UPI 的常见用例是用于专用实体隔离安装。 生成环境时没有出站 Internet 访问权限时，请选择 UPI。

建议尽可能使用 IPI，因为该方法可显著减少完成 OpenShift 安装所需的工作量。

安装 OpenShift 时，必须解决以下注意事项：

• 区域选择。 建议将区域与可用性区域配合使用。 部署期间，OpenShift 会根据配置文件 (install-config.yaml) 中的配置自动尝试跨区域创建节点。 默认情况下，OpenShift 会在所有可用节点和可用区域之间平衡工作负载。 如果某个区域中发生服务中断，解决方案可通过让其他区域中的节点接管工作来继续运行。

• 备份和恢复。 可以使用 Azure Red Hat OpenShift 的说明进行备份和恢复。 有关详细信息，请参阅创建 Azure Red Hat OpenShift 4 群集应用程序备份。 如果使用此方法进行备份和恢复，则必须为数据库提供另一种灾难恢复的方法。

• 故障转移。 请考虑在两个区域中部署 OpenShift，并使用 Red Hat 高级群集管理。 如果解决方案具有公共终结点，则可以在它们和 Internet 之间放置 Azure 流量管理器，以便在区域中断时将流量重定向到适当的群集。 在这种情况下，还必须迁移应用程序的状态和永久性卷。

实体隔离安装

在某些情况下（例如为满足法规合规性），可能需要在 Azure 上以实体隔离的方式安装 MAS。 实体隔离表示没有入站或出站 Internet 访问。 如果没有 Internet 连接，安装将无法在运行时检索安装 MAS 或 OpenShift 的安装依赖项。

不建议执行实体隔离安装，除非这是一项安全要求。 实体隔离给解决方案的操作带来了明显的复杂性。 安装软件、镜像容器、更新镜像以防范安全漏洞以及管理防火墙等活动可能会变得非常耗时。

有关实体隔离安装的详细信息，请参阅以下 OpenShift 文档：

• 断网安装的镜像映像
• 在 Azure 上安装专用群集

安装 OpenShift 后，请参阅 MAS 文档以获取类似指南。

调整环境大小

对于所有工作负载（视觉检测除外），建议使用最新的 Ds 系列 VM 作为工作器节点。 例如 Dsv3、Dasv4、Dsv4、Dasv5 或 Dsv5。 建议尽可能使用最新版本，因为它们提供更好的性能。 仅使用具有高级存储的 VM。

Maximo 视觉检测要求 GPU 节点执行其机器学习。 该解决方案使用 CUDA，且仅支持 NVIDIA GPU。 建议的 VM 类型为 NCv3 和 NCasT4_v3。 如果需要使用 YOLOv3 进行训练，则需要基于 Ampere 的 GPU。 使用 NVadsA10 v5 或 NC A100 v4 执行较大的训练任务。

对于 GPU 计算机，建议从最小的节点着手，并在需求增加时纵向扩展。

对于所有其他计算机，建议跨可用性区域配置 VM 以支持高可用性。 请按照如下所示配置节点：

• 控制节点。 所选区域中每个可用性区域至少一个 VM。 建议 vCPU 计数至少为 4。 我们的参考使用 3x Standard_D8s_v4 节点。

• 工作器节点。 所选区域中每个可用性区域至少两台计算机。 建议 vCPU 计数至少为 8。 我们的参考使用 6x Standard_D8s_v4 节点。

MAS 核心需要 13 个 vCPU 进行标准大小的基础安装。 工作器节点大小因配置部署的 MAS 应用程序以及环境中的负载而异。 例如，管理 10 位用户需要另外 2 个 vCPU。 建议查看 IBM Maximo Application Suite 系统要求，以获得良好的大小调整估计。

尝试使 VM 类型彼此相似，以便与工作器节点与控制节点之间的每个可用性区域相近。 换言之，如果将 v4 VM 用于控制节点，则也对工作器节点使用 v4 VM。

如果需要跳转盒才能使用 OpenShift 命令行接口 (oc) 或安装 MAS，请部署运行 Red Hat Enterprise Linux 版本 8.4 的 VM。

网络

对于 OpenShift，我们使用 OpenShift 软件定义网络 (SDN) 的默认容器网络接口 (CNI) 提供程序。 有关默认 OpenShift CNI 的详细信息，请参阅 OpenShift 容器平台中的群集网络操作员。 必须为所需的 OpenShift 控件和工作器节点数以及针对任何其他要求（例如数据库和存储帐户）调整网络大小。

对于标准 MAS 生产安装，建议使用类别域际路由选择 (CIDR) 前缀 /24 提供的地址空间的虚拟网络。 虚拟网络具有三个或四个子网（用于 Azure Bastion）。 对于 OpenShift，工作器节点子网的 CIDR 前缀为 /25，控制节点的前缀为 /27。 终结点和可选外部数据库服务器的子网应具有前缀 /27。 如果要部署 Azure Bastion（可选），则需要名为 AzureBastionSubnet 的子网，其前缀为 /26。 有关 Azure Bastion 要求的详细信息，请参阅体系结构。

如果 IP 地址不足，则可以实现一个高度可用的配置，其中控制节点子网的最小前缀为 /27，工作器节点子网的最小前缀为 /27。

如果要使用其他 CNI，请相应地调整网络大小。 具有一些标准应用程序的 MAS 部署了 800 多个 Pod，这可能需要 /21 或更大的 CIDR 前缀。

数据库细节

MAS 的各个组件使用 MongoDB 作为元数据存储。 默认指南是在群集内部部署 MongoDB Community Edition。 如果使用此方法对其进行部署，请确保备份和还原数据库的适当过程已就绪。 请考虑在 Azure 上使用 MongoDB Atlas，因为它提供外部化存储、备份、缩放等。 Azure 目前不支持将 MongoDB API 与 Azure Cosmos DB 配合使用。

如果部署 IoT 服务，则还需要提供 Kafka 终结点。 默认指南是使用 Strimzi 在 OpenShift 群集中部署 Kafka。 在灾难恢复期间，Strimzi 中的数据很可能丢失。 如果 Kafka 中的数据丢失不可接受，应考虑在 Azure 上使用 Confluent Kafka。 目前，不支持具有 Kafka 终结点的 Azure 事件中心。

MAS 在其 Pod 中打包了许多数据库，这些数据库会在为 MAS 提供的文件系统上保留其状态。 建议使用区域冗余存储 (ZRS) 机制来保留群集外部的状态，以便能够应对区域故障。 建议的模式是通过以下配置使用 Azure 文件存储：

• 标准。 为较低吞吐量和 ReadWriteOnce (RWO) 工作负载提供服务器消息块 (SMB) 共享。 标准非常适合不经常写入存储并且需要单个永久性卷（例如 IBM 单级存储）的应用程序部分。

• 高级。 为较高吞吐量和 ReadWriteMany (RWX) 工作负载提供网络文件系统 (NFS) 共享。 此类卷在整个群集中用于 RWX 工作负载，例如 Cloud Pak for Data 中的 Db2 Warehouse 或 Manage 中的 Postgres。

请务必禁用在 Azure Blob 存储上强制执行安全传输的策略，或使帐户免受此类策略的影响。 具有 NFS 的 Azure 高级文件存储要求禁用安全传输。 请务必使用专用终结点来保证与共享的专用连接。

默认情况下，Db2 Warehouse 部署在 OpenShift Data Foundation（以前称为 OpenShift 容器存储）的基础之上。 出于成本、性能、缩放和可靠性的原因，建议将 Azure 高级文件存储与 NFS 配合使用，而不是 OpenShift Data Foundation。

请不要将 Azure Blob 存储与 CSI 驱动程序配合使用，因为它不支持所需的硬链接。 有些 pod 没有硬链接就无法运行。

注意事项

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

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。

保持对资产维护生命周期的访问权限和可见性可能是组织高效运行和维护运行时间的最大机会之一。 为了改进环境的安全状况，请务必使用安全身份验证并使解决方案保持最新。 使用加密帮助保护所有进出体系结构的数据。

Azure 使用基础结构即服务 (IaaS) 和 PaaS 模型来提供 MAS。 Microsoft 在以下级别将安全保护构建到服务中：

• 物理数据中心
• 物理网络
• 物理主机
• Hypervisor

仔细评估你为虚拟机监控程序上方的区域选择的服务和技术，例如主要发布的 OpenShift 最新补丁版本。 请务必为体系结构提供适当的安全控制。 由你负责修补和维护 IaaS 系统的安全性。 Microsoft 会为 PaaS 服务扮演该角色。

使用网络安全组来筛选进出虚拟网络中资源的网络流量。 借助这些组，便可以定义可授予或拒绝对 MAS 服务的访问权限的规则。 示例包括：

• 允许 SSH 访问 OpenShift 节点进行故障排除
• 阻止访问群集的所有其他部分
• 控制可以访问 MAS 和 OpenShift 群集的位置

如果出于某种原因需要访问 VM，可以通过混合连接或 OpenShift 管理控制台进行连接。 如果有联机部署或不想依赖于连接，还可以通过 Azure Bastion访问 VM（可选）。 出于安全原因，不应在未配置网络安全组以控制对其的访问的情况下将虚拟机公开给网络或 Internet。

Azure 磁盘存储的服务器端加密 (SSE) 会保护数据。 它还有助于满足组织安全性和合规性承诺。 对于 Azure 托管磁盘，SSE 会在将数据保存到云时加密静态数据。 此行为默认适用于 OS 和数据磁盘。 OpenShift 默认使用 SSE。

身份验证

MAS 目前支持在 Microsoft Entra ID 中使用安全断言标记语言 (SAML) 进行单一登录 (SSO)。 这种身份验证方法需要 Microsoft Entra ID 中的企业应用程序和修改应用程序的权限。 有关详细信息，请参阅 Microsoft Entra SSO 与 Maximo Application Suite 的集成。

在设置基于 SAML 的身份验证之前，建议你完成 IBM 配置和 Azure 配置。 有关使用 MAS 的 SAML 的信息，请参阅 MAS 文档中的 SAML。 有关 SAML 与 Azure 的信息，请参阅快速入门：为企业应用程序启用单一登录。

还应为 OpenShift 配置 Open Authorization (OAuth)。 有关详细信息，请参阅 OpenShift 文档中的身份验证和授权概述。

保护基础结构

控制对已部署的 Azure 资源的访问。 每个 Azure 订阅均与一个 Microsoft Entra 租户存在信任关系。 可使用 Azure 基于角色的访问控制 (RBAC) 向组织内的用户授予对 Azure 资源的正确权限。 通过向特定范围内的用户或组分配 Azure 角色，授予访问权限。 该范围可以是订阅、资源组或单个资源。 请务必审核对基础结构进行的所有更改。 有关审核的详细信息，请参阅 Azure Monitor 活动日志。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

MAS 的标准部署包含以下组件：

• 3 个控制 VM
• 6 个工作器 VM
• Db2 Warehouse 的 3 个工作器 VM
  • 可以在某些配置中替换 Azure VM 上的 SQL Server，而不是使用 Db2 Warehouse。
• 2 个 Azure 存储帐户
• 2 个 DNS 区域
• 2 个负载均衡器
• Azure Bastion
• 1 个视觉检测 VM
  • 除非打算在 MAS 内部运行视觉检测，否则不需要这样做。

可以使用成本计算器查看示例估算值。 配置各不相同，应在最终确定部署之前与 IBM 大小调整团队验证配置。

可靠性

OpenShift 具有自我修复、扩展和复原的内置功能，可确保 OpenShift 和 MAS 成功运行。 OpenShift 和 MAS 专为故障和恢复的部件而设计。 自我修复有效工作的关键要求是有足够的工作器节点。 若要从 Azure 区域中的区域故障中恢复，可用性区域之间的控制节点和工作器节点必须实现均衡。

MAS 和 OpenShift 使用存储在 Kubernetes 群集之外保留状态。 为确保存储依赖项在故障期间继续工作，应尽可能使用区域冗余存储。 当某一区域发生故障时，这种类型的存储仍然可用。

由于人为错误很常见，因此应尽可能使用自动化来部署 MAS。 在快速入门指南中，我们提供了一些用于设置完整端到端自动化的示例脚本。

部署此方案

在开始之前，建议查看 IBM Maximo Application Suite 系统需求。 开始部署前，请确保有以下可用资源：

• 以读者权限访问 Azure 订阅的权限
• 对订阅具有参与者和用户访问管理员权限的应用程序注册或服务主体名称
• Azure DNS 区域的域或委托子域
• 来自 Red Hat 中的机密，用于部署 OpenShift
• MAS 权利密钥
• MAS 许可证文件（在 MAS 安装后创建）
• IBM 推荐的群集大小调整
• 现有虚拟网络或由 IPI 创建的新虚拟网络，具体取决于需求
• 特定部署的高可用性和灾难恢复要求
• 安装程序的配置文件 install-config.yaml

有关在 Azure 上安装 OpenShift 和 MAS 的分步指南，包括如何满足先决条件，请参阅 GitHub 上的快速入门指南。

部署注意事项

最好使用基础架构即代码 (IaC) 来部署工作负载，而不是手动部署工作负载，因为手动部署可能导致配置错误。 基于容器的工作负载可能对错误配置很敏感，这会降低工作效率。

在生成环境之前，请查看快速入门指南，以便了解设计参数。 快速入门指南不适用于生产就绪部署，但可以使用指南的资产来获取用于部署的生产级机制。

IBM 提供专业服务，有助于进行安装。 请联系 IBM 团队获取支持。

作者

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

主要作者：

• David Baumgarten | 高级云解决方案架构师
• Roeland Nieuwenhuis | 首席云解决方案架构师

其他参与者：

• Gary Moore | 程序员/作家

若要查看非公开领英个人资料，请登录领英。

后续步骤

有关入门的帮助，请参阅以下资源：

• 在 Azure 上安装 OpenShift
• 快速入门指南：Azure 上的 Maximo Application Suite
• OpenShift UPI 指南
• Maximo 的要求
• IBM Maximo Application Suite (BYOL)

若要了解有关特色技术的详细信息，请参阅以下文章：

• IBM Passport Advantage
• Azure DNS 简介
• Azure NetApp 文件简介
• Azure 上的 Red Hat 简介
• Red Hat 客户门户

相关资源

• Azure 企业云文件共享
• 制造业预测性维护简介
• 在 ARO 群集上部署带有 JBoss 企业应用程序平台 (EAP) 的 Java 应用程序