Deploy IBM Maximo Application Suite on Azure

本文介紹 IBM Maximo 應用程式套件（MAS）在 Azure 上的部署。 MAS 運行於 Red Hat OpenShift。 如果 Azure Red Hat OpenShift（ARO）符合您的營運、安全及網路需求，則是首選的 OpenShift 平台。 只有在你需要 ARO 不提供控制權時，才在 Azure 上使用自我管理的 Red Hat OpenShift，例如特定的斷開部署模式或叢集層級的自訂。

本文並未詳細說明如何安裝 MAS。 欲了解更多安裝資訊，請參閱 安裝 Maximo 應用程式套件。

架構

下圖展示了基於 ARO 的 Azure MAS 部署。

下載此架構的Visio檔案。

你可以根據需求，將工作負載部署為內部或外部部署。 本文不規定公開或私有的 ARO 部署模式。 根據您的 Azure 登陸區架構，選擇控制平面、入口與出口架構，包括網路拓撲、連接模型、安全控制、營運存取需求、合規要求及 MAS 使用者存取模式。

當 IBM 支援你部署的 MAS 應用程式外部資料庫時，嘗試將這些資料庫外部化，以減少 OpenShift 叢集內的狀態，並將資料庫管理與叢集管理解耦。

Workflow

從基礎架構角度來看，此架構提供以下功能：

• 一個 Azure Red Hat OpenShift 託管服務，用於在多個可用區域部署高可用性工作負載
• 一個整合於 Azure 網路與儲存的 OpenShift 叢集
• Azure 檔案儲存體 Premium 同 Azure 檔案儲存體 Standard for supported MAS storage requirements
• Azure SQL 受控執行個體 或基於容器的 IBM Db2 Warehouse
• Azure DNS 用於 OpenShift 及其容器的網域名稱系統（DNS）管理
• Microsoft Entra ID 用於單一登入（SSO）至 MAS

元件

• Azure Red Hat OpenShift （ARO） 是 MAS on Azure 首選的 OpenShift 平台。 ARO 比起在 Azure 虛擬機（VM）上自管理叢集，減少了你執行 OpenShift 的營運責任。

• Azure 虛擬機器 是一種基礎設施即服務（IaaS），能隨需部署可擴展的運算資源。 使用 虛擬機器 取代 ARO 來部署自管理的 Red Hat OpenShift 在 Azure 上。

  可選擇使用 Azure Linux 虛擬機作為 MAS 安裝和 OpenShift 管理的跳板。 如果你有私有網路連接到 Azure 環境，你可以從現有的安全機器執行管理。

• Red Hat Enterprise Linux CoreOS 提供 OpenShift 節點的作業系統映像檔。

• Azure Load Balancer 提供叢集的連線。 Load Balancer 是一項高效能、超低延遲的第四層負載平衡服務，適用於所有入站與出站用戶資料報協定（UDP）及傳輸控制協定（TCP）協定。 Load Balancer 能每秒處理數百萬個請求，同時確保您的解決方案高度可用。 Load Balancer 具備區域冗餘性，確保各可用區域間的高可用性。

• Azure 虛擬網路是Azure私有網路的基本基石。 使用 虛擬網路 進行節點與 Azure 服務之間的通訊，以及混合式連線。

• Azure 檔案儲存體 提供雲端中完全管理的檔案共享，可透過伺服器訊息區塊（SMB）及網路檔案系統（NFS）協定存取。 使用 Azure 檔案儲存體 來承載叢集內資料庫和系統的有狀態資料。

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

• Azure Bastion 是一項全託管服務，提供遠端桌面協定（RDP）和安全殼層（SSH）存取虛擬機，且不會透過公開 IP 位址暴露。 可選擇使用 Azure Bastion 和一個子網路，以增強安全性存取任何工作節點或可選的跳板機。

• 當 IBM 支援您部署的應用程式的 SQL Server 時，SQL 受管理執行個體 會為 MAS 提供外部資料服務。 你也可以選擇其他資料庫，例如 Oracle Exadata 或 IBM Db2 Warehouse。 Azure SQL Database 不被支援。

• Twilio SendGrid 會從 MAS 向其消費者發送電子郵件。 如果您的 MAS 部署需要電子郵件服務來處理通知與人力派遣情境，可選擇性地將電子郵件服務如 Twilio SendGrid 納入設計中。

替代方案

以下服務通常不是必需的，但都是有效的替代方案：

• Azure NetApp Files 作為Azure 檔案儲存體的替代品。 Azure NetApp Files 支援需要高可用性與高效能的工作負載。
• 如果支援且你偏好的話，Azure 上的 Oracle Database 就更好。
• OpenShift Data Foundation，如果您想在 OpenShift Data Foundation 上使用 Db2 Warehouse。

案例詳細資料

IBM Maximo 應用套件是一款具備 AI 資產維護功能的企業資產管理平台。 MAS 著重於作業復原和可靠性。 該套件包含 MAS 核心應用平台，以及以下基於該平台的應用與產業專用解決方案。

• 馬克西莫管理。 透過資產管理降低停機時間與成本，提升營運效能。
• 馬克西莫監視器。 利用物聯網（IoT）進行大規模遠端資產的先進 AI 監控。
• Maximo 健康。 利用感測器、資產資料及維護歷史的物聯網資料來管理資產健康。
• Maximo 視覺檢查。 訓練機器學習模型利用視覺檢查來分析新興議題。
• Maximo 預測。 利用機器學習與資料分析預測未來失敗。
• Maximo 合作。 透過設備維護資料知識庫，協助技術人員提供AI指導，並提供專家遠端連線。
• Maximo 健康、安全與環境（HSE）。 將安全、環境合規及工作控制流程與資產、地點及工單連結起來。
• Maximo 土木基礎設施。 整合檢查、缺陷追蹤與維護活動，協助提升資產壽命、維持關鍵系統運作，並降低土木基礎設施的總擁有成本。
• Maximo 房地產與設施。 管理不動產組合及設施資產，涵蓋空間管理、預訂、資本專案、設施狀況評估、租賃管理、營運及維護。

潛在的使用情境

許多產業與部門採用MAS解決方案，例如以下領域：

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

欲了解更多 MAS 使用案例，請參閱 IBM 官網的 IBM Maximo 應用套件 。

建議

本文是針對目前支援的 Azure MAS 9.x 部署而撰寫。 Microsoft 與 IBM MAS 團隊及其他合作夥伴合作，確保此解決方案能在 Azure 上最佳運行並提供最佳體驗。 這些文件、架構與指引遵循Microsoft Azure Well-Architected框架中所述的最佳實務。 如需產品相關的問題及支援，請聯絡您的 IBM 客戶團隊，超出本文件說明。

當您有 IBM 支援及合作夥伴安裝時，請參考本文作為架構指導。 Azure 也提供一套 MAS 安裝路徑，支援自行攜帶授權。 如需詳細資訊，請參閱 IBM Maximo Application Suite (自備授權 (BYOL))。

安裝一個 IBM 標示為與你所選 OpenShift 版本及 MAS 應用程式相容的 MAS 版本。 對於新的 Azure 部署，除非你需要自我管理叢集，否則使用 ARO 作為首選的 OpenShift 平台。

OpenShift 支援的相容性取決於三個重疊的支援邊界：IBM MAS 相容性、Red Hat OpenShift 生命週期支援，以及 ARO 版本可用性。 使用 IBM 未在軟體產品相容性報告（SPCR）中列出，或不在 Red Hat 或 ARO 支援範圍內的 OpenShift 版本，可能會導致你的 MAS 部署無法支援。

在建置部署前，請先閱讀 IBM Maximo 應用程式套件的概覽、計畫安裝於 Microsoft Azure 及軟體產品相容性報告（SPCR）文件，以了解目前的部署與設定需求。

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

• 您需要哪些 MAS 應用程式？
• 您的應用程式有哪些相依性？
• IBM 支援哪個 OpenShift 版本用於你的 MAS 版本和應用程式？
• ARO 符合你的需求嗎？還是你需要在 Azure 上自行管理的 Red Hat OpenShift？
• 你需要哪些資料庫？
• 所需的 VM 數目和大小？
• 使用者需要從外部網路連線嗎？

Maximo 應用程式套件

使用目前支援的 MAS 9.x 版本，並在最終架構前驗證 IBM SPCR 中支援的 OpenShift 版本、資料庫及相依性。 如果你使用的是較早期版本的 Maximo 應用程式套件，請檢視其 IBM 生命週期狀態，並計劃升級至支援的 MAS 9.x 版本。

檢視您完整的商業情境所需的MAS申請，然後再檢視每個申請的需求。 如需詳細資訊，請參閱 IBM Maximo Application Suite 系統需求。

每個 MAS 應用程式可能需要獨立的資料庫。 如果 IBM 支援應用程式外部資料庫，建議嘗試外部化資料庫，因為這種方式能減少你在 OpenShift 中必須操作的狀態量。 Microsoft 與 IBM 在 Azure 上測試並支援以下 MAS 資料庫：

• SQL 受控執行個體
• IBM Db2 雲端倉庫 for Data 5

Azure SQL Database 同 Azure Cosmos DB 唔支援。

你也可以選擇在 Oracle Cloud Infrastructure 或透過互連的虛擬機上執行 Oracle Exadata。 這種配置尚未正式測試，但據報導已成功。 欲了解更多關於互連的資訊，請參閱 Interconnecting Oracle Cloud with Microsoft Azure。

MAS 及其部分應用程式依賴 MongoDB 和 Kafka。 當 IBM 預設的叢集內 MongoDB Community Edition 與 Strimzi Kafka 部署符合您的支援、備份與復原需求時，請使用它們。 當 Kafka 和 MongoDB 是內部 MAS 相依，且你的解決方案不在 MAS 外使用它們時，這個選擇是合適的。

需要更強的備份、擴展或災難復原操作時，可以嘗試使用外部管理服務，例如 Azure 上的 MongoDB Atlas 或 Azure 上的 Confluent Cloud。 部分 MAS 先決條件，如行為分析服務（BAS），使用無法外部化但需持續儲存的資料庫，必須提供給 OpenShift 叢集。

對於運行於 OpenShift 叢集內的狀態型服務，請定期備份資料並將備份移至其他區域。 設計、規劃並決定災難復原策略，尤其是在 OpenShift 中執行 Kafka 或 MongoDB 時。 對於能保留狀態的服務，若可能，使用外部 Azure 平台即服務（PaaS）以提升故障時的支援性。

部分服務可能需要其他 IBM 工具與服務，例如 IBM Watson 機器學習 與 IBM App Connect。 你可以在同一個 OpenShift 叢集上部署所有這些工具和服務。

Azure Red Hat OpenShift

使用 ARO 作為 Azure 上 MAS 的首選 OpenShift 平台。 ARO 在 Azure 上提供託管的 OpenShift 服務，減輕安裝、修補及操作 OpenShift 平台的營運負擔。 你仍然擁有 MAS 及其應用程式配置、工作者容量規劃、網路整合、身份整合、儲存選擇、資料保護和災難復原。

在部署 MAS 於 ARO 之前，請考慮以下建議：

• 版本相容性。 選擇 IBM 列出支援的 OpenShift 版本，並選擇 MAS 應用程式。 確認同一版本的 OpenShift 是否在你的目標 Azure 區域內由 ARO 提供並支援。 若可能，請選擇偶數編號的 OpenShift 版本以執行生產 MAS 部署，因為這些版本屬於 擴展更新支援（EUS） 版本。

  交叉驗證 IBM 是否支援所有所選 MAS 應用程式與相依的 OpenShift 版本。 若 MAS 元件在 IBM SPCR 中列出較新的奇數編號 OpenShift 版本作為需求，請在選擇叢集版本前，先驗證完整元件集是否符合 IBM SPCR、Red Hat 生命週期支援及 ARO 版本可用性。

• 部署路徑。 當您已有 Azure 登陸區、網路、身份、儲存和營運控制時，請使用現有的 ARO 叢集。 當您希望使用 IBM 提供的自動化來建立或重用支援的 OpenShift 基礎架構時，請使用 IBM Azure Marketplace 的安裝路徑。 只有當 ARO 不符合你的需求時，才在 Azure 上使用自我管理的 Red Hat OpenShift。

• 區域選擇。 如果可以的話，選擇有 可用區域 的區域。 當目標區域支援該模式時，請在區域間配置 ARO 工作節點。 對於自我管理的 OpenShift，請設定安裝檔案 install-config.yaml，讓 OpenShift 能在不同區域間放置節點。 如果某區域發生停電，你的解決方案可以透過讓其他區域的節點接手工作來繼續運作。

• 備份與救援。 你可以使用 Azure Red Hat OpenShift 的備份與復原說明。 欲了解更多資訊，請參閱 Create a Azure Red Hat OpenShift 4 cluster Application Backup。 若使用此方法進行備份與復原，必須提供另一種災難復原方式。

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

自我管理的 OpenShift

如果 ARO 不符合你的控制、隔離或斷線部署需求，建議在 Azure 上使用自管理的 Red Hat OpenShift。 對於自我管理部署，請選擇以下安裝方法：

• 安裝程式配置基礎設施 (Installer Provisioned Infrastructure, IPI)。 此方法使用安裝程式在 Azure 上部署並設定 OpenShift 環境。 當 IPI 符合你的安全和網路需求時，就使用 IPI。

• User Provisioned Infrastructure (UPI)。 此方法讓您能對部署進行細緻控制。 UPI 需要額外的步驟和考量，才能建置您的環境。 如果 IPI 或 ARO 不符合你的需求，就用 UPI。 私人或斷開的安裝是 UPI 常見的使用情境。

空氣隔間安裝

某些情況，例如法規遵循，可能需要在 Azure 上進行空氣隔離安裝 MAS。 空中隔斷是指沒有進出網際網路。 沒有網路連線，你的安裝無法在執行時取得 MAS 或 OpenShift 安裝的相依關係。

只有在安全需求下才使用隔氣安裝。 空氣間隙會大幅增加解決方案操作的複雜性。 安裝軟體、鏡像容器、更新鏡像以防範安全漏洞，或管理防火牆等活動，都可能耗費大量營運資源。

欲了解更多關於空隙安裝的資訊，請參閱以下 Red Hat OpenShift 關於 Azure 上斷開安裝與私有叢集的文件：

• 使用oc-mirror為斷線安裝的鏡像影像
• 在 Azure 上安裝私有叢集

在完成空氣間隔的 OpenShift 安裝後，你可以繼續參考 MAS 文件，了解 斷開環境的指引。

節點與環境大小

除了 Maximo Visual Inspection 外，所有工作負載都建議從現行世代的 Ds 或 Das 系列虛擬機器家族開始，例如 Dsv6，這些模組在你所選區域內可作為工作節點使用。 選擇支援高級儲存空間，並符合 MAS 應用 CPU、記憶體與儲存需求的虛擬機大小。

Maximo 視覺檢查 需要 GPU 節點以執行其機器學習。 該解決方案使用 CUDA，且僅支援 NVIDIA GPU。 對於 ARO 的 ARO，請從目前 ARO 工作節點支援清單中選擇 NVIDIA GPU VM 大小，然後確認 IBM 是否支援你的 MAS 和 OpenShift 版本。 若要自行管理 OpenShift，請選擇 IBM 與 Red Hat 支援的 NVIDIA GPU VM 尺寸。

對於 GPU 工作節點，從最小的節點開始，隨著需求增加逐步擴展。

對於 ARO 和自管理的 OpenShift，工作節點使用相同的 MAS 工作負載大小指引。 在 不同可用性區域 配置工作節點以支援高可用性。 對於自我管理的 OpenShift，也要在可用區域間設定控制平面。 請參考以下起點：

• 控制節點。 對 ARO 而言，控制平面是服務的一部分來管理的。 對於自我管理的 OpenShift，在所選區域內，每個可用區域至少使用一台虛擬機。

• 工作節點。 在所選區域內，每個可用區域至少使用兩台機器。 根據 IBM 指引、選擇的 MAS 應用程式及預期負載，來規劃工作節點的大小。

MAS 核心需要 13 個 vCPU 來進行標準大小的基底安裝。 工作節點的規模設置會根據您部署的 MAS 應用程式和環境負載而有所不同。 例如，10 位使用者的 Maximo Manage 需要另外 2 顆 vCPU。 將這些數值視為起點，並根據目前 IBM Maximo Application Suite 系統對 您的 MAS 9.x 版本、所選應用程式及預期使用量進行驗證大小。

對於自我管理的 OpenShift，盡量讓虛擬機類型彼此相似，以便在工作節點與控制節點之間保持與各可用區域的接近。 對於 ARO 來說，將工作節點池對齊到相同的 MAS 工作負載需求和 Azure 區域容量。

如果你需要跳板來使用 OpenShift oc 命令列介面或安裝 MAS，請部署符合組織管理與安全需求的支援 Linux 虛擬機。

網路組態

對於 ARO 來說，除非 IBM、Red Hat 和你的網路團隊驗證其他選項，否則使用 ARO 部署的預設 OpenShift 網路配置。 規劃虛擬網路及 ARO 控制平面節點、工作節點、Azure 服務依賴、私有端點、資料庫與混合連接的獨立子網。 根據你需要的 OpenShift 工作節點數量來調整節點子網大小，包括升級容量和未來擴展。

對於自我管理的 OpenShift，也包含啟動機制（bootstrap）及安裝程式建立的基礎架構要求。 將 OpenShift API 與節點的管理權限限制在核准的網路路徑上，例如混合連接、安全跳板主機或其他組織所需的控制。 如果你限制叢集出口，請規劃 OpenShift、MAS 安裝、容器映像拉取、更新、監控及外部服務所需的外站相依。

對於標準的 MAS 生產安裝，不要一開始就建立一個緊密的虛擬網路。 在你的著陸區允許時，保留較大的位址空間，例如無類別 Inter-Domain 路由（CIDR）前綴為 /16，並分配專用子網。 ARO 控制平面子網至少使用 /24 規劃大小，工作節點子網至少使用 /24 規劃大小。 新增一個 /27 或更大的子網路，用於私有端點和外部資料庫服務。 如果你選擇性地部署 Azure Bastion，請新增一個名為 AzureBastionSubnet 的子網路，前綴為 /26。 欲了解更多 Azure Bastion 需求資訊，請參見架構。

如果你使用自我管理的 OpenShift，且 IP 位址不足，可以設計一個受限的高可用性配置，控制節點子網前綴至少為 /27，工作節點子網前綴為 /27。 不要把這種受限規模作為 ARO 生產部署的起點。 不要把虛擬網路或節點子網的容量過小。 安裝後重新處理 OpenShift 部署會造成干擾，可能需要重新部署。

如果你想使用不同的容器網路介面（CNI），請相應地調整你的網路規模。 MAS 搭配部分標準應用程式可部署超過 800 個 pod，這可能需要 /21 或更大的 CIDR 前綴。

資料庫細節

部分 MAS 元件使用 MongoDB 作為元資料儲存。 預設指引是在叢集內部署 MongoDB Community Edition。 如果你使用這種方法，務必確保有適當的備份和還原資料庫程序。 考慮在 Azure 上使用 MongoDB Atlas，提供外部化的儲存、備份和擴展功能。 Azure目前不支援在Azure Cosmos DB中使用MongoDB API。

如果你部署物聯網服務，也必須提供 Kafka 端點。 預設指引是使用 Strimzi 在 OpenShift 叢集中部署 Kafka，但 Strimzi 內部的資料很可能在災難復原時遺失。 如果 Kafka 內部的資料遺失無法接受，可以考慮在 Azure 上使用 Confluent Kafka。 目前 Azure 事件中樞 並未支援 Kafka 端點。

MAS 的 pods 包含多個資料庫，這些資料庫會在 MAS 提供的檔案系統中保留其狀態。 要吸收區域故障，可以使用區域冗餘儲存（ZRS）機制來保留叢集外的狀態。 建議的模式是使用 Azure 檔案儲存，配置如下：

• 標準 版提供較低吞吐量的 SMB 共享與 ReadWriteOnce （RWO） 工作負載。 對於應用程式中不常寫入儲存且需要單一持久磁碟區的部分，例如IBM的單層儲存，請使用標準。

• Premium 提供更高吞吐量及 ReadWriteMany （RWX） 工作負載的 NFS 共享。 這類磁碟區在整個叢集中用於 RWX 工作負載，例如 Cloud Pak 中的 Db2 Warehouse for Data 或 Maximo Manage 中的 Postgres。

Azure 檔案儲存體 NFS 支援傳輸中加密。 如果 MAS OpenShift 用戶端無法使用 NFS 加密，你可以讓該帳號免於安全傳輸執行政策。 欲了解更多資訊，請參閱 NFS Azure 檔案分享：加密。 使用 私人端點 來提供你的共享連結。

如果你透過 Cloud Pak for Data 部署 Db2 Warehouse，請使用 OpenShift Data Foundation。 關於使用 Ceph 檔案系統（CephFS）與 RADOS 區塊裝置（Ceph RBD）儲存類別來管理不同 Db2 倉庫資料類型的 OpenShift Data Foundation 範例，請參見「 使用 Cloud Pak for Data 主控台建立 Db2 實例」。

不要使用 Azure Blob 儲存體 搭配容器儲存介面（CSI）驅動程式，因為它不支援硬連結，而某些 Pod 需要硬連結才能執行。

考量

這些考量實現了 Azure Well-Architected 框架的支柱，這是一套指導原則，用以提升工作負載的品質。 更多資訊請參見 Microsoft Azure Well-Architected Framework。

可靠性

OpenShift 內建自我修復、擴展與韌性功能。 OpenShift 和 MAS 預期元件會故障並恢復。 自我修復的關鍵條件是叢集必須有足夠的工作節點。 要從 Azure 區域內的區域故障中恢復，你的控制節點與工作節點必須在不同可用區域間平衡。

MAS 和 OpenShift 使用儲存空間來維持 Kubernetes 叢集外的狀態。 若要確保儲存體相依性在失敗期間繼續運作，您應該盡可能使用區域備援儲存體。 當單一區域失效時，區域冗餘儲存仍可使用。

為了避免人為錯誤，請盡可能使用自動化來部署 MAS。 請使用目前 IBM 安裝文件及支援自動化，針對您所選的 MAS 版本、OpenShift 平台及部署路徑。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 欲了解更多資訊，請參閱 安全性設計審查清單。

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

透過使用 ARO 部署，您可以享受 ARO 的共同責任模式。 Azure Red Hat OpenShift 由 Microsoft 與 Red Hat 共同設計、營運並支援，Red Hat 代表您修補、更新並監控受管理的 OpenShift 平台。 你仍然負責在 ARO 之外的部署。 此職責涵蓋 MAS 及其應用程式配置、身份整合、網路控制、工作者容量規劃、儲存選擇、備份與災難復原、機密、資料保護及合規要求。 欲了解更多資訊，請參閱 Azure Red Hat OpenShift 簡介及 Azure Red Hat OpenShift 4.0 支援政策。

Microsoft 在 Azure 平台中內建以下層級的安全防護：

• 實體資料中心
• 實體網路
• 實體主機
• Hypervisor（虛擬機管理程式）

使用你 OpenShift 平台支援的 OpenShift 版本，以及 IBM 在你的 MAS 版本和應用程式中支援的版本。 如果可能，請使用支援的長期支援版本。 如果你使用自我管理的 OpenShift，你就必須負責修補和維護 OpenShift 平台及底層虛擬機。 如果你用 ARO，Microsoft 會負責修補和管理。

使用 網路安全群組來過濾進出 虛擬網路資源的網路流量。 透過使用這些群組，您可以定義規則來授予或拒絕存取您的 MAS 服務，例如：

• 允許 SSH 存取 OpenShift 節點以進行故障排除。
• 阻擋叢集其他所有部分的存取。
• 控制哪些地點可以存取 MAS 和 OpenShift 叢集。

要存取虛擬機，可以透過混合連線或 OpenShift 管理控制台連接。 如果你有線上部署或不想依賴混合連線，可以透過 Azure Bastion 存取虛擬機。 出於安全考量，不要在未設定網路安全群組控制存取的情況下，讓虛擬機暴露給網路或網際網路。

Azure 磁碟儲存體 的伺服器端加密（SSE）保護您的資料，並協助您達成組織的安全與合規承諾。 使用 Azure 管理磁碟時，SSE 在將資料持續儲存到雲端時會加密。 在預設情況下，此行為套用至 OS 和資料磁碟。 在預設情況下，OpenShift 會使用 SSE。

驗證

MAS 支援使用 Security Assertion Markup Language（SAML）進行 SSO。 若要使用 Microsoft Entra ID 作為 SAML 身份提供者，請在 Microsoft Entra ID 中建立企業應用程式，並將 MAS 設定為服務提供者。 欲了解更多資訊，請參閱 Microsoft Entra 與 Maximo Application Suite 的 SSO 整合。

在設定基於 SAML 的驗證之前，請先檢視 IBM 和 Azure 的設定。 關於 MAS 的 SAML 資訊，請參閱 配置 SAML 認證。 欲了解 SAML 與 Azure 的資訊，請參見 快速入門：企業應用程式啟用單一登入。

你也應該設定 OAuth 以取得 OpenShift 的管理權限。 關於 ARO，請參閱 Configure Microsoft Entra authentication for a Azure Red Hat OpenShift cluster。 關於自我管理的 OpenShift，請參見 「在 OpenShift 容器平台 4.21 中配置身份提供者」。

資源存取與稽核

控制你部署的 Azure 資源存取權。 每個Azure訂閱都與Microsoft Entra租戶建立信任關係。 使用 Azure 角色型存取控制 (Azure RBAC) 來授與組織內的使用者對 Azure 資源的正確權限。 透過在特定範圍內（如訂閱、資源群組或單一資源）指派 Azure 角色來授予存取權限。 審核所有基礎設施變更。 欲了解更多審計資訊，請參閱 Azure 監視器活動日誌。

成本最佳化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 欲了解更多資訊，請參閱成本優化設計審查清單。

Azure 上的標準 MAS 部署包含以下主要成本驅動因素：

• ARO 叢集成本，包括工作節點及任何可計費的控制平面或叢集費用
• 為 MAS Core 及你部署的 MAS 應用程式大小設計的工作節點池
• Maximo 視覺檢查的可選 GPU 工作節點
• 資料庫服務，如 SQL 受管理執行個體、Db2 Warehouse 或其他 IBM 支援的資料庫
• 儲存帳號或管理儲存服務，用於持久磁碟、備份及安裝產物
• DNS 區域、負載平衡、私有端點，以及可選的 Azure Bastion 實例

對於 ARO 與自管理 OpenShift，標準 MAS 部署通常使用相同的工作節點規模基準。 請以以下庫存作為成本估算的起點：

• 六台工作型虛擬機。
• 三個工作型虛擬機用於 Db2 倉庫。 你可以在某些配置中用 SQL 受管理執行個體 取代 Db2 Warehouse。
• 兩個 Azure 儲存體 帳戶。
• 兩個 DNS 區域。
• 兩個負載平衡器。
• Azure Bastion。
• 如果你打算在 MAS 裡執行 Maximo Visual Inspection，就用一個 Maximo Visual Inspection GPU 工作節點。

控制平面成本因部署模式而異。 對於使用 IPI 或 UPI 的自管理 OpenShift 部署，也包含三個控制虛擬機。 對於 ARO 來說，請考慮管理控制平面及任何 ARO 專屬叢集費用，而非新增客戶管理的控制虛擬機。

您可以使用 費用計算器查看範例估價。 配置各異，因此在最終部署前，請先向 IBM 規模團隊確認您的配置。

部署此方案

開始前，請先閱讀 IBM Maximo Application Suite 系統需求 及 IBM SPCR 對您的 MAS 版本與應用程式的說明。 在開始部署前，請準備以下資源：

• 以 Reader 權限存取 Azure 訂閱
• 擁有貢獻 者 與 使用者存取管理員 權限的應用程式註冊或服務主體名稱
• 一個網域或委派到Azure DNS區域
• 支援的 ARO 叢集，或建立叢集所需的權限與前提條件
• 如果你的部署路徑是建立或管理 OpenShift 基礎設施，這是來自 Red Hat 的 pull 秘密
• MAS 授權金鑰
• 一個安裝 MAS 後建立的 MAS 授權檔案
• IBM 建議的叢集規模
• 既有的虛擬網路，或符合 ARO 與 MAS 要求的新虛擬網路
• 特定部署的高可用性和災害復原需求
• 所選部署路徑的設定細節，例如 ARO 叢集細節或自我管理的 OpenShift 安裝參數

在建置環境前，請先閱讀 IBM 計畫安裝於 Microsoft Azure 的文件，以了解設計參數。 有關目前 Azure 安裝指引，請參閱 Maximo Application Suite on Microsoft Azure 概覽。 請根據目前 IBM 文件及 MAS 版本的支援矩陣驗證部署流程。

部署考量

透過使用基礎設施即程式碼（IaC）部署工作負載，而非手動。 手動部署可能導致設定錯誤。 容器型工作負載很容易受到設定錯誤的影響，進而降低生產力。

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

參與者

本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。

主要作者：

• 大衛·鮑姆加滕 |首席建築師
• Roeland Nieuwenhuis | 首席架構師

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

下一步

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

• Azure Red Hat OpenShift
• Maximo Application Suite on Microsoft Azure 概覽
• 計劃安裝在 Microsoft Azure 上
• 在 Azure 上安裝 OpenShift
• OpenShift UPI 指南
• Maximo 的系統需求
• IBM 軟體產品相容性報告
• IBM Maximo Application Suite （BYOL）

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

• IBM Passport 優勢
• Azure DNS 導論
• Azure NetApp Files 導論
• Azure Red Hat OpenShift 簡介
• Red Hat 客戶入口網站

相關資源

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