在 Azure 上部署 IBM Maximo Application Suite

Azure 檔案
Azure Load Balancer
Azure Red Hat OpenShift
Azure 虛擬機器
Azure 虛擬網路

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

架構

此架構圖表顯示支援在 Azure 上部署 IBM Maximo Application Suite 的元件和服務。

下載此架構的 Visio 檔案

視您的需求而定,工作負載可以在內部或外部部署。

工作流程

從基礎結構的觀點來看,此架構提供下列專案:

  • 容器裝載平臺,可跨可用性區域部署高可用性工作負載
  • 已與記憶體整合之背景工作和控制節點的私有化部署
  • Azure 進階版 檔案和記憶體的標準檔案 (不需要 OpenShift Data Foundation)
  • Azure VM 上的 SQL Server 或容器式 IBM Db2 倉儲
  • 適用於 OpenShift 及其容器之 DNS 管理的 Azure DNS
  • 單一登錄至 MAS 的 Microsoft Entra ID

元件

  • Azure 虛擬機器 裝載 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 是完全受控的服務,可為 VM 提供安全且順暢的 RDP 和 SSH 存取,而不需要透過公用 IP 位址公開。

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

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

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

替代項目

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

案例詳細資料

IBM 的 Maximo Application Suite (MAS),也稱為 Maximo,是具有 AI 型資產維護的企業資產管理平臺。 MAS 著重於作業復原和可靠性。 此套件包含一個核心應用程式平臺、MAS,以及平臺之上的應用程式和產業特定解決方案。 每個應用程式都提供特定優點:

  • 管理。 使用資產管理來改善作業效能,以降低運行時間與成本。
  • 監視。 使用IoT大規模監視遠端資產的進階 AI 支援。
  • 健康情況。 使用來自感測器、資產數據和維護歷程記錄的IoT數據來管理資產健康情況。
  • 視覺檢查。 將機器學習模型定型,以使用視覺檢查進行新興問題的可視化分析。
  • 預測。 使用機器學習和數據分析預測未來的失敗。
  • 協助。 協助技術人員提供 AI 支援的指引,以 知識庫 設備維護數據,並讓他們遠端訪問專家。
  • 保管庫。 從感測器收集和分析數據、提供內容相關數據,以及衍生有意義的分析。
  • 民事。 整合檢查、缺陷追蹤和維護活動,以協助改善資產生命週期、保持關鍵系統運作,以及降低民用基礎設施總擁有成本。

這些應用程式和 MAS 8。x 已測試在 Azure 上使用。 Microsoft 和 IBM Maximo 小組合作,以確保此解決方案已設定為在 Azure 上以最佳方式執行。 本文提供執行 MAS 8 的設計。x on Azure 適用於支援 IBM 的客戶,以及安裝合作夥伴。 請連絡 IBM 小組以取得產品特定問題。 Azure Marketplace 為支援自備授權的 MAS 提供替代安裝。 如需詳細資訊,請參閱 IBM Maximo Application Suite (BYOL)

潛在的使用案例

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

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

在IBM Maximo Application Suite 的IBM網站上尋找 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 上測試並支援下列資料庫:

您也可以選擇使用相互連線在 VM 或 Oracle 雲端基礎結構上執行 Oracle Exadata,但這不是經過測試的組態。 如需相互連線的詳細資訊,請參閱 瞭解如何將 Oracle Cloud 與 Microsoft Azure 互連。 目前不支援 Azure SQL 資料庫、Azure SQL 受控執行個體 和 Azure Cosmos DB。

注意

在某些情況下,由於資料庫設定衝突,您無法針對多個 MAS 應用程式重複使用資料庫。 例如,您無法將相同的 IBM Db2 Warehouse for Health 與 Manage 搭配使用。 不過,您可以混合不同的資料庫產品,例如將 SQL Server 用於一個應用程式,而 IBM Db2 Warehouse 則用於另一個應用程式。

如需 Health 應用程式資料庫需求的詳細資訊,請參閱 設定 Maximo Health 的資料庫。

MAS 及其部分應用程式相依於 MongoDB 和 Kafka。 根據效能和作業的考慮,決定如何部署這些解決方案。 默認值是在叢集內部署 MongoDB Community Edition 和 Strimzi Kafka。 MAS 的某些必要條件,例如 BAS,使用無法外部化但需要持續記憶體提供給 OpenShift 叢集的資料庫。

針對在 OpenShift 叢集內執行的狀態型服務,需要經常備份數據並將備份移至另一個區域。 在發生災害時設計和規劃復原策略,並據此做出決定,尤其是在OpenShift內執行Kafka或 MongoDB 時。

針對保留狀態的服務,請盡可能使用外部 Azure 平臺即服務 (PaaS) 供應專案。 這樣做可改善中斷期間的支援性。

某些服務可能需要其他 IBM 工具和服務,例如 IBM Watson 機器學習 和 IBM App 連線。 您可以在相同的 OpenShift 叢集上部署所有工具和服務。

OpenShift

注意

IBM Maximo Application Suite 支援 Azure Red Hat OpenShift,前提是 OpenShift 和 Cloud Pak for Data 的基礎版本 (CP4D) 一致。

安裝 OpenShift 之前,您必須判斷要使用哪一種方法:

  • 安裝程式布建的基礎結構 (PI)。 此方法會使用安裝程式在 Azure 上部署和設定 OpenShift 環境。 IL 是部署在 Azure 上最常見的方法,除非您的安全性需求太嚴格,否則您應該使用 IL。

  • 使用者佈建的基礎結構 (UPI) 。 此方法可讓您更精細地控制您的部署。 UPI 需要更多步驟和考慮,才能建置您的環境。 如果 PI 不符合您的需求,請使用 UPI。 UPI 的常見使用案例是用於私人、空中套用的安裝。 當您在建置環境時沒有輸出因特網存取時,請選擇UPI。

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

注意

安裝 OpenShift 之後,控制平面的擁有者會負責維護及調整 Azure 上的背景工作節點。 您可以在管理控制台中使用計算機集來增加叢集大小,而不是透過 Azure 入口網站。 如需詳細資訊,請參閱 在 Azure 上建立機器集。

安裝 OpenShift 時,您必須解決下列考慮:

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

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

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

Air-gapped 安裝

在某些情況下,例如法規合規性,您可能需要在 Azure 上安裝 MAS 的空套安裝。 Air gapped 表示沒有輸入或輸出因特網存取。 如果沒有因特網連線,您的安裝就無法在運行時間擷取安裝 MAS 或 OpenShift 的安裝相依性。

注意

Air-gapped 部署需要 UPI 進行安裝。 不過,它們尚未經過完整測試。

除非這是安全性需求,否則不建議您執行空中套用安裝。 空差會增加解決方案作業的顯著複雜度。 安裝軟體、鏡像容器、更新鏡像以防範安全性弱點的活動,以及管理防火牆可能會變得非常耗時。

如需空中安裝的詳細資訊,請參閱下列 OpenShift 檔:

安裝 OpenShift 之後,請參閱 MAS 檔以取得類似的指引。

調整環境大小

針對所有工作負載(除了視覺檢查之外),我們建議使用最新的 Ds 系列 VM 作為背景工作節點。 範例包括 Dsv3、Dasv4、Dsv4Dasv5Dsv5。 建議您盡可能使用最新版本,因為它們可提供更佳的效能。 只使用具有 進階記憶體的 VM。

Maximo 視覺檢查 需要 GPU 節點執行其機器學習。 解決方案使用 CUDA ,且僅支援 NVIDIA GPU。 建議的 VM 類型為 NCv3NCasT4_v3。 如果您需要使用 YOLOv3 定型,則需要 以 Ampere 為基礎的 GPU。 針對較大的定型工作, 請使用 NVadsA10 v5NC A100 v4

針對 GPU 機器,建議您從最小的節點開始,並在需求增加時相應增加。

警告

如果您需要 GPU 機器,您需要 OpenShift 4.8.22 作為最低版本,才能透過 NVIDIA GPU 操作員啟用 GPU。

對於所有其他計算機,我們建議跨可用性區域設定 VM 以支援高可用性。 設定節點,如下所示:

  • 控制節點。 所選區域內每個可用性區域至少一個 VM。 我們建議至少 4 個 vCPU 計數。 我們的參考使用 3x Standard_D8s_v4 節點。

  • 背景工作節點。 所選區域內每個可用性區域至少兩部機器。 我們建議至少 8 個 vCPU 計數。 我們的參考使用 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 軟體定義網路的預設容器網路介面 (CNI) 提供者。 如需預設 OpenShift CNI 的詳細資訊,請參閱 OpenShift 容器平臺中的叢集網路操作員。 您必須針對您需要的 OpenShift 控制項和背景工作節點數目,以及任何其他需求,例如資料庫和記憶體帳戶,調整網路大小。

針對標準 MAS 生產環境安裝,我們建議使用位址空間為 /24 的 CIDR 前置詞提供的虛擬網路。 虛擬網路有三或四個子網(適用於 Bastion)。 針對 OpenShift,背景工作節點的子網具有 /25 的 CIDR 前置詞,而控制節點的前置詞為 /27。 端點和選擇性外部資料庫伺服器的子網應具有 /27 的前置詞。 如果您要部署 Azure Bastion,這是選擇性的,您需要名為 AzureBastionSubnet 且前置詞為 /26 的子網。 如需 Azure Bastion 需求的詳細資訊,請參閱 架構

如果您不熟悉 IP 位址,您可以針對控制節點的子網實作高可用性組態,而背景工作節點子網的子網的前置詞為 /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 的文件系統上。 建議您使用區域備援儲存機制來保留叢集外部的狀態,以吸收區域失敗。 我們建議的模式是搭配下列組態使用 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 容器 儲存體)。 基於成本、效能、調整和可靠性的原因,我們建議使用 Azure 進階版 Files 搭配 NFS,而不是 OpenShift Data Foundation。

請勿搭配 CSI 驅動程式使用 Azure Blob,因為它不支援必要的硬式連結。 有些 Pod 無法在沒有硬式鏈接的情況下執行。

考量

這些考慮會實作 Azure Well-Architected Framework 的支柱,這是一組指導原則,可用來改善工作負載的品質。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊,請參閱 安全性要素概觀。

維護資產維護生命週期的存取權和可見度,可能是組織最有機會有效率地運作和維護運行時間。 若要改善環境的安全性狀態,請務必使用安全驗證,並讓您的解決方案保持最新狀態。 使用加密來保護移入和移出架構的所有數據。

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)。 若要進行這項工作,您需要 Microsoft Entra ID 內的企業應用程式,以及修改應用程式的許可權,或全域管理員的協助,這些系統管理員可以進行必要的變更。

GitHub 上的快速入門指南有如何設定 SAML 與 MAS 的教學課程。 如需詳細資訊,請參閱 針對 Microsoft Entra ID 啟用 SAML 驗證。

設定 SAML 型驗證之前,建議您先完成 IBM 設定和 Azure 設定。 如需 SAML 與 MAS 的相關信息,請參閱 MAS 檔中的 SAML 。 如需 SAML 與 Azure 的相關信息,請參閱 快速入門:啟用企業應用程式的單一登錄。

您也應該設定 OpenShift 的 OAuth。 如需詳細資訊,請參閱 OpenShift 檔中的驗證和授權 概觀。

保護您的基礎結構

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

成本最佳化

成本優化是考慮如何減少不必要的費用,並提升營運效率。 如需詳細資訊,請參閱 成本優化要素概觀。

MAS 的標準部署包含下列元件:

  • 3 個控制 VM
  • 6 個背景工作 VM
  • Db2 倉儲的 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 訂用 帳戶 存取權
  • 具有訂用帳戶之參與者使用者存取權的應用程式註冊或服務主體名稱 管理員 istrator 許可權
  • 網域或委派的子域至 Azure DNS 區域
  • 從 Red Hat 提取秘密以部署 OpenShift
  • MAS 權利金鑰
  • MAS 授權檔 (在 MAS 安裝之後建立)
  • IBM 建議的叢集重設大小
  • 根據您的需求,現有的虛擬網路或 ING 所建立的新虛擬網路
  • 特定部署的高可用性和災害復原需求
  • 安裝程式的組態檔 install-config.yaml

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

注意

快速入門指南:Azure 上的 Maximo Application Suite 包含 /src/ocp/中的 install-config.yaml 檔案範例

部署考量

最好是使用基礎結構即程序代碼 (IaC) 來部署工作負載,而不是手動部署工作負載,因為手動部署可能會導致設定錯誤。 容器型工作負載可能會因設定錯誤而敏感,這可能會降低生產力。

在建置環境之前,請先檢閱 快速入門指南 ,以瞭解設計參數。 快速入門指南不適用於生產環境就緒的部署,但您可以使用指南的資產來取得生產等級的部署機制。

IBM 提供專業服務來協助您進行安裝。 請連絡 IBM 小組以取得支援。

參與者

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

主要作者:

其他參與者:

若要查看非公用LinkedIn配置檔,請登入LinkedIn。

下一步

如需開始使用的說明,請參閱下列資源:

若要深入瞭解精選技術,請參閱下列資源: