部署 IBM Maximo Application Suite on Azure

IBM Maximo Application Suite （MAS） 8.x，並在 OpenShift 上執行，而且最好熟悉 OpenShift，以及建議在 Azure 上安裝的模式。 如需詳細資訊，請參閱準備安裝到 Azure。 此架構說明 OpenShift 叢集。 它不會詳細說明如何安裝 MAS。 若要深入瞭解安裝程式，請參閱 安裝 Maximo Application Suite。

架構

下載此架構的 Visio 檔案。

該工作負載可視您的需求在內部或外部部署。

工作流程

從基礎結構的觀點來看，此架構提供以下內容：

• 容器裝載平台，可跨可用性區域部署高可用性工作負載
• 已與儲存體整合之背景公作和控制節點的私有化部署
• 適用於儲存體的 Azure 進階檔案和標準檔案 (不需要 OpenShift Data Foundation)
• Azure VM 上的 SQL Server 或容器型 IBM Db2 Warehouse
• 適用於 OpenShift 及其容器之 DNS 管理的 Azure DNS
• 使用 Microsoft Entra ID 進行單一登入 (SSO) 到 MAS。

元件

• Azure Virtual Machines，裝載 OpenShift 平台並執行 Maximo 容器。 虛擬機器是基礎結構即服務 (IaaS) 的供應項目。 您可以使用虛擬機器來部署隨選、可縮放的計算資源。

• Red Hat Enterprise Linux CoreOS，提供 OpenShift 的自訂 VM 映射。

• Azure Load Balancer，提供與叢集的連線。 Azure Load Balancer 為高效能、超低延遲的第 4 層負載平衡服務 (傳入和傳出)，適用於所有 UDP 和 TCP 通訊協定。 旨在每秒處理數百萬個要求，同時確保解決方案的高可用性。 Azure Load Balancer 是區域備援，可確保跨可用性區域的高可用性。

• 虛擬網路，節點、Azure 服務和混合式連線需求之間的通訊。 虛擬網路是 Azure 中私人網路的基本建置組塊。

• Azure 檔案以託管叢集內資料庫和系統的有狀態資料。 Azure 檔案在雲端中提供完全受控檔案共用，可透過 SMB 和網路檔案系統 (NFS) 通訊協定存取。

• Azure DNS，管理解決方案內外容器的 DNS 解析。 Azure DNS 支援所有常見的 DNS 記錄，並提供高可用性。

• Azure Bastion (選用) 和子網路，可以增強安全性存取任何工作者節點或選用的 JumpBox 機器。 Azure Bastion 是完全受控的服務，可讓您安全順暢地以增強安全性 RDP 和 SSH 存取 VM，而不會透過公用 IP 位址曝光。

• Azure 虛擬機器上的 SQL Server (選用) 提供資料服務給 MAS。 資料庫也可以是另一個資料庫，例如 Oracle Exadata 或 IBM Db2 Warehouse。 目前不支援 Azure SQL 資料庫和 Azure SQL 受控執行個體。

• Twilio Send Grid (選擇性) 將來自 MAS 的電子郵件傳送給您的取用者。

• Azure 中的 Linux 虛擬機器 (選擇性) 提供用於安裝 OpenShift 的跳板機。 您也可以使用此 VM 來連接和管理 OpenShift 叢集，因為它在安裝之後包含 Kubernetes 組態檔。 如果您有 Azure 環境的網路連線能力，則可以從現有的機器執行安裝。

替代項目

下列服務通常不需要，但它們是有效的替代方案：

• Azure NetApp Files 作為 Azure 檔案儲存體的替代方案。 Azure NetApp Files 支援具有高可用性和高效能的任何類型的工作負載。
• 適用於 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 對遠端資產進行進階 AO 支援的大規模監控。
• 健康情況。 使用來自感應器、資產資料和維護歷程記錄的 IoT 資料來管理資產健康情況。
• 目視檢查。 訓練機器學習模型，以使用視覺檢查進行新問題的視覺化分析。
• 預測。 使用機器學習和資料分析預測未來的失敗。
• 協助。 提供 AI 支援的指引，幫助技術人員存取設備維護資料的知識庫，並為他們提供遠端專家支援。
• 安全性. 收集和分析感應器資料，提供上下文資料並衍生有意義的分析。
• 土木。 整合檢查、缺陷追蹤和維護活動，以幫助提高資產壽命、保持關鍵系統運作，並降低土木基礎設施的總擁有成本。

這些應用程式和 MAS 8。x 和向上測試，以在 Azure 上使用。 Microsoft 和 IBM Maximo 小組合作，以確保此解決方案已設定為在 Azure 上以最佳方式執行。 本文提供執行 MAS 8 的設計。azure 上x，供支援 IBM 的客戶和安裝合作夥伴使用。 有關特定產品的問題，請連絡 IBM 小組。 Azure Marketplace 提供了一種替代的 MAS 安裝方式，支援使用自備授權。 如需詳細資訊，請參閱 IBM Maximo Application Suite (自備授權 (BYOL))。 本指南詳細說明如何手動安裝 Maximo。

潛在使用案例

許多產業和部門都使用 MAS 中的解決方案，例如：

• 能源與公共事業
• 石油與天然氣
• 製造業
• 旅遊、汽車和運輸
• 公共部門

在 IBM Maximo Application Suite 的 IBM 網站上尋找 MAS 使用案例的詳細資訊。

建議

建議您安裝最新的穩定版 MAS，因為它提供與 Azure 的最佳整合選項。 請密切關注支援的 OpenShift 版本，因為支援的版本會隨著特定版本的 MAS 而有所不同。

使用舊版或更新版本 OpenShift 可能會導致 MAS 失去官方支援。 在建置您自己的部署之前，建議您徹底閱讀在 Azure 上安裝 ，並 規劃 Azure 檔，讓您瞭解部署和設定的運作方式。 瞭解安裝詳細數據可加速建立實作的設計需求。

Microsoft與 IBM 和其他合作夥伴合作，以確保文件、架構和指引提供您在 Azure 上的最佳體驗。 他們會遵循 Microsoft Azure Well-Architected Framework 中所述的最佳做法。 請連絡 IBM 帳戶小組以取得本文件以外的支援。

在繼續進行部署之前，您需要回答下列有關設計的問題：

• 您需要哪些 MAS 應用程式？
• 您的應用程式有哪些相依性？
• 需要哪個版本的 OpenShift？
• 您應該使用哪一種 OpenShift 安裝方法？
• 需要哪些資料庫？
• 所需的 VM 數目和大小？
• 使用者是否會從外部網路連接？

Maximo Application Suite

Microsoft已在 Azure 上測試 MAS 8.7 版和更新版本。 我們建議使用目前為9.0版的MAS最新版本。 如果您使用的是舊版 Maximo Application Suite，建議您升級以受益於與 Azure 的較佳整合。

檢閱完整商務案例所需的 MAS 應用程式，然後檢閱每個應用程式的需求。 如需詳細資訊，請參閱 IBM Maximo Application Suite 系統需求。 每個應用程式可能需要個別的資料庫。 我們已在 Azure 上測試並支援下列資料庫：

• 使用 Windows 或 Linux 的 Azure 虛擬機器上的 SQL Server 版本 2019
• Cloud Pak for Data 5 上的 IBM Db2 倉儲

您也可以選擇使用互連在 VM 或 Oracle 雲端基礎架構上執行 Oracle Exadata，但這不是經過測試的設定。 如需相互連線的詳細資訊，請參閱 使用 Microsoft Azure 將 Oracle 雲端互連。 目前不支援 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 Machine Learning 和 IBM App Connect。 您可以在相同的 OpenShift 叢集上部署所有工具和服務。

OpenShift

安裝 OpenShift 之前，您必須決定要使用哪一種方法：

• Installer Provisioned Infrastructure (IPI)。 此方法使用安裝程式在 Azure 上部署和設定 OpenShift 環境。 IPI 是在 Azure 上部署的最常見方法，除非您的安全性需求太嚴格而無法這樣做，否則應該使用 IPI。

• User Provisioned Infrastructure (UPI)。 此方法可讓您更精細地控制您的部署。 UPI 需要更多步驟和考量，才能建置您的環境。 如果 IPI 不符合您的需求，請使用 UPI。 UPI 的常見使用案例是用於私人的、實體隔離斷網的安裝。 當您在建置環境時沒有輸出網際網路存取時，請選擇 UPI。

建議您盡可能使用 IPI，因為它可大幅減少完成 OpenShift 安裝所需的工作量。

安裝 OpenShift 時，您必須解決下列考量：

• 區域選擇。 我們建議使用具有可用性區域的區域。 在部署期間，OpenShift 會根據組態檔 install-config.yaml 中的組態，自動嘗試跨區域建立節點。 根據預設，OpenShift 會平衡所有可用節點和可用性區域之間的工作負載。 如果區域發生中斷，您的解決方案可以讓其他區域中的節點接管工作以繼續運作。

• 備份 & 復原。 您可以使用 Azure Red Hat OpenShift 的指示進行備份和復原。 有關詳細資訊，請參閱建立 Azure Red Hat OpenShift 4 叢集應用程式備份。 如果使用此方法進行備份和復原，則必須為資料庫提供另一個災害復原方法。

• 容錯移轉。 請考慮在兩個區域中部署 OpenShift，並使用 Red Hat 進階叢集管理。 如果解決方案有公用端點，您可以在它們與網際網路之間放置 Azure 流量管理員，以在發生區域中斷時，將流量重新導向至適當的叢集。 在這種情況下，您也必須移轉應用程式的狀態和永續性磁碟區。

實體隔離斷網安裝

在某些情況下，例如為了遵守法規，您可能需要在 Azure 上實體隔離斷網安裝 MAS。 實體隔離斷網表示沒有輸入或輸出網際網路存取。 如果沒有網際網路連接，您的安裝就無法在執行階段擷取安裝 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。 我們的參考使用 3 個 Standard_D8s_v4 節點。

• 背景工作節點。 所選區域內每個可用性區域至少要有兩部機器。 我們建議 vCPU 計數至少為 8。 我們的參考使用 6 個 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 中，背景工作節點的子網路具有 /25 的 CIDR 首碼，而控制節點的首碼為 /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 目前不支援搭配 Azure Cosmos DB 使用 MongoDB API。

如果您部署 IoT 服務，也必須提供 Kafka 端點。 該預設指引是使用 Strimzi 在 OpenShift 叢集內部署 Kafka。 在災害復原期間，Strimzi 內的資料很可能遺失。 如果無法接受 Kafka 中的資料遺失，您應該考慮在 Azure 上使用 Confluent Kafka。 目前，不支援具有 Kafka 端點的 Azure 事件中樞。

MAS 在其 Pod 內包含許多資料庫，這些資料庫在為 MAS 提供的檔案系統上保留其狀態。 建議您使用區域備援儲存體 (ZRS) 機制來保留叢集外部的狀態，以吸收區域失敗。 我們建議的模式是搭配下列組態使用 Azure 檔案儲存體：

• 標準。 提供伺服器訊息區塊 (SMB) 共用，以降低輸送量和 ReadWriteOnce (RWO) 工作負載。 標準非常適合不會經常寫入儲存體且需要單一永續性磁碟區的應用程式部分 (例如，IBM 單一層級儲存體)。

• 進階。 為更高的輸送量和 ReadWriteMany (RWX) 工作負載提供網路檔案系統 (NFS) 共用。 這類磁碟區會在整個叢集中用於 RWX 工作負載，例如 Cloud Pak for Data 中的 Db2 Warehouse 或 Manage 中的 Postgres。

請務必停用在 Azure Blob 儲存體上強制執行安全傳輸的原則，或使帳戶免受此類原則的影響。 具有 NFS 的 Azure 進階檔案要求停用安全傳輸。 請務必使用私人端點來確保與您的共用私人連線。

根據預設，Db2 Warehouse 會部署在 OpenShift Data Foundation 之上 (先前稱為 OpenShift 容器儲存體)。 出於成本、效能、縮放和可靠性方面的考量，我們建議使用具有 NFS 的 Azure 進階檔案，而不是 OpenShift Data Foundation。

請勿搭配 CSI 驅動程式使用 Azure Blob 儲存體，因為它不支援必要的永久連結。 有些 Pod 無法在沒有永久連結的情況下執行。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。

維護對資產維護生命週期的存取和可見性，可能是您的組織高效運作和維持正常運作時間的最佳機會之一。 若要改善環境的安全性態勢，請務必使用安全驗證，並讓您的解決方案保持在最新狀態。 使用加密來協助保護移入和移出架構的所有資料。

Azure 會使用基礎結構即服務模型 (IaaS) 和 PaaS 模型來提供 MAS。 Microsoft 在以下層級的服務中建置了安全性保護：

• 實體資料中心
• 實體網路
• 實體主機
• Hypervisor

仔細評估您為 Hypervisor 之上的區域所選取的服務和技術，例如針對主要版本的 OpenShift 的最新修補版本。 請務必為您的架構提供適當的安全性控制。 您負責修補和維護 IaaS 系統的安全性。 Microsoft 針對 PaaS 服務擔任該角色。

使用網路安全性群組來篩選進出虛擬網路中資源的網路流量。 透過這些群組，您可以定義授與或拒絕存取 MAS 服務的規則。 範例包含：

• 允許 SSH 存取 OpenShift 節點以進行疑難排解
• 封鎖對叢集所有其他部分的存取
• 控制哪些位置可以存取 MAS 和 OpenShift 叢集

如果您出於某種原因需要存取 VM，可以透過混合式連線或 OpenShift 管理主控台進行連接。 如果您有線上部署或不想依賴連線，您也可以透過 Azure Bastion (選擇性) 存取您的 VM。 基於安全性考量，您不應該在沒有設定網路安全性群組以控制其存取權的情況下，將 VM 公開至網路或網際網路。

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 設定。 如需 SAML 與 MAS 的相關資訊，請參閱 MAS 文件中的 SAML。 有關使用 Azure 的 SAML 的資訊，請參閱快速入門：為企業應用程式啟用單一登入。

您也應該為 OpenShift 設定 Open Authorization (OAuth)。 如需詳細資訊，請參閱 OpenShift 文件中的驗證和授權概觀。

保護您的基礎結構

控制您部署之 Azure 資源的存取權。 每個 Azure 訂用帳戶都會與 Microsoft Entra 租用戶有信任關係。 使用 Azure 角色型存取控制 (RBAC) 授與組織內的使用者對 Azure 資源的正確權限。 將 Azure 角色指派給特定範圍的使用者或群組，以授與存取權。 該範圍可以是訂用帳戶、資源群組或單一資源。 請務必稽核基礎結構的所有變更。 有關稽核的詳細資訊，請參閱 Azure 監視器活動記錄。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。

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 建議的叢集調整大小
• 根據您的需求，現有的虛擬網路或 ING 所建立的新虛擬網路
• 特定部署的高可用性和災害復原需求
• 安裝程式的組態檔 install-config.yaml

如需在 Azure 上安裝 OpenShift 和 MAS 的逐步指南，包括如何解決必要條件，請參閱 GitHub 上的快速入門指南。

部署考量

最好是使用基礎結構即程式碼 (IaC) 來部署工作負載，而不是手動部署工作負載，因為手動部署可能會導致設定錯誤。 容器型工作負載很容易受到設定錯誤的影響，進而降低生產力。

建置環境之前，請檢閱 IBM 所提供的 Azure 檔 規劃，以開發對設計參數的瞭解。 快速入門指南不適用於生產環境就緒的部署，但您可以使用該指南的資產來取得生產等級的部署機制。

IBM 提供專業服務來協助您進行安裝。 請連絡 IBM 團隊尋求支援。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• David Baumgarten | 資深雲端解決方案架構師
• Roeland Nieuwenhuis | 首席雲端解決方案架構師

其他投稿人：

• Gary Moore | 程式設計師/作家

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

如需使用者入門協助，請參閱以下資源：

• 在 Azure 上安裝 OpenShift
• 快速入門指南：Maximo Application Suite on Azure
• OpenShift UPI 指南
• Maximo 的需求
• IBM Maximo Application Suite (BYOL)

若要深入了解特色技術，請參閱下列資源：

• IBM Passport 優勢
• Azure DNS 簡介
• Azure NetApp Files 簡介
• Azure 上的 Red Hat 簡介
• Red Hat 客戶入口網站

相關資源

• Azure 企業雲端檔案共用
• 在 ARO 叢集上使用 JBoss 企業應用程式平台 (EAP) 部署 Java 應用程式