共用方式為


將大型主機計算移轉至 Azure

大型主機以高可用性和可靠性聞名,並持續成為深受許多企業信賴的支柱。 大型主機通常也被視為具有近乎無限的可擴縮性和計算能力。 儘管如此,對於某些企業而言,現有最大可用的大型主機功能已無法滿足其需求。 如果您有相同困擾,Azure 能為您提供靈活度、觸達和基礎結構節省成本。

若要在 Microsoft Azure 上執行大型主機工作負載,您必須知道大型主機的計算功能與 Azure 相比如何。 本文會告訴您如何基於 IBM z14 大型主機 (本文撰寫時的最新型號),在 Azure 上取得可比較的結果。

請先從將環境進行並排比對開始。 下圖比較執行應用程式的大型主機環境與 Azure 主控環境。

Azure 服務和模擬環境提供可比較的支援並簡化移轉

大型主機的強大功能通常應用於線上交易處理 (OLTP) 系統,這類系統為數千名使用者處理上百萬個更新。 這些應用程式通常會使用軟體,以執行交易處理、畫面控制項處理和表單輸入。 亦會使用客戶資訊控制系統 (CICS)、資訊管理系統 (IMS) 或交易介面套件 (TIP)。

如圖所示,Azure 上的 TPM 模擬器可以處理 CICS 和 IMS 工作負載。 Azure 上的批次系統模擬器會執行工作控制語言 (JCL) 的角色。 大型主機資料會移轉至 Azure 資料庫,例如 Azure SQL Database。 Azure 服務或裝載於 Azure 虛擬機器的其他軟體均可應用於系統管理。

大型主機計算一覽

在 z14 大型主機中,處理器最多會排列在四個「隱藏式選單」中。 「隱藏式選單」就是處理器與晶片組的叢集。 每個隱藏式選單能有六個作用中的中央處理器 (CP) 晶片,而每個 CP 都有 10 個系統控制器 (SC) 晶片。 在 Intel x86 術語中,每個隱藏式選單有六個通訊端、每個通訊端有 10 個核心,以及四個隱藏式選單。 此架構為 z14 提供了最高約等同於 24 個通訊端和 240 個核心。

快速的 z14 CP 具有 5.2 GHz 的時脈速度。 一般而言,z14 會與所有 CP 一起交付。 CP 會視需要啟動。 不論實際使用量為何,客戶通常以每月至少四小時的計算時間來付費。

大型主機處理器可以設為下列其中一種類型:

  • 一般用途 (GP) 處理器
  • System z 整合式資訊處理器 (zIIP)
  • 適用於 Linux (IFL) 處理器的整合式設備
  • 系統輔助處理器 (SAP)
  • 整合式結合設備 (ICF) 處理器

擴大與擴增大型主機計算

IBM 大型主機提供最多可擴大至 240 個核心的能力 (目前單一系統的 z14 大小)。 此外,IBM 大型主機可以透過稱為「結合設備」(CF) 的功能擴增。 CF 能讓多個大型主機系統同時存取相同資料。 運用 CF,大型主機 Parallel Sysplex 技術能將大型主機處理器分組為叢集。 於撰寫本指南時,Parallel Sysplex 功能支援 32 個群組 (每組 64 個處理器)。 多達 2,048 個處理器可運用此方式進行分組,以擴增計算容量。

CF 能讓計算叢集以直接存取的方式共用資料。 亦能用於鎖定資訊、快取資訊和共用資料資源清單。 使用一或多個 CF 的Parallel Sysplex 可被視為「共用所有項目」的擴增計算叢集。 如需這些功能的詳細資訊,請參閱 IBM 網站上的 “Parallel Sysplex on IBM Z”

應用程式可以運用這些功能,提供擴增效能和高可用性。 針對 CICS 如何搭配 CF 使用 Parallel Sysplex 的相關資訊,請下載 “IBM CICS and the Coupling Facility: Beyond the Basics” 紅皮書。

Azure 計算一覽

有些人誤以為 Intel 伺服器比不上大型主機的強大功能。 然而,新的核心密集 Intel 系統擁有與大型主機相同的計算容量。 本節說明適用於計算和儲存的 Azure 基礎結構即服務 (IaaS) 選項。 Azure 也提供平台即服務 (PaaS) 選項,但本文著重於提供類似於大型主機容量的 IaaS 選項。

Azure 虛擬機器提供各種大小和類型的計算能力。 在 Azure 中,虛擬 CPU (vCPU) 大致上相當於大型主機的核心。

目前,Azure 虛擬機器所提供的大小為 1 到 128 個 vCPU。 虛擬機器 (VM) 類型已針對特定工作負載最佳化。 例如,下列清單顯示 VM 類型 (截至本文撰寫時的最新情況),以及其建議用途:

大小 類型和說明
D 系列 具有 64 個 vCPU 和最高 3.5-GHz 時脈速度的通用型產品
E 系列 記憶體最佳化,最高可達 64 個 vCPU
F 系列 計算最佳化,最高可達 64 個 vCPU 和 3.7 GHz 時脈速度
H 系列 針對高效能運算 (HPC) 應用程式最佳化
L 系列 針對由 NoSQL 等資料庫所支援的高輸送量應用程式進行儲存體最佳化
M 系列 最高可達 128 個 vCPU 的最大計算和記憶體最佳化 VM

如需可用 VM 的詳細資訊,請參閱虛擬機器系列

z14 大型主機最多可擁有 240 個核心。 然而,z14 大型主機幾乎從未針對單一應用程式或工作負載使用所有核心。 相反地,大型主機會將工作負載拆分至邏輯分割區 (LPAR),而 LPAR 具有評等 (MIPS (每秒數百萬個指示) 或 MSU (百萬個服務單位))。 當判斷在 Azure 上執行大型主機工作負載所需的類似 VM 大小時,會將 MIPS (或 MSU) 評等納入考慮。

以下為一般估計值:

  • 每個 vCPU 150 MIPS

  • 每個處理器 1,000 MIPS

若要判斷 LPAR 中特定工作負載的正確 VM 大小,需要先針對工作負載將 VM 最佳化。 然後判斷所需的 vCPU 數目。 每個 vCPU 的保守估計值為 150 MIPS。 舉例來說,根據這項估計,具有 16 個 vCPU 的 F 系列 VM 可以輕鬆地支援來自具有 2,400 MIPS LPAR 的 IBM Db2 工作負載。

Azure 計算擴大

M 系列 VM 可以擴充至 128 個 vCPU (截至本文撰寫時的最新情況),。 使用每個 vCPU 150 MIPS 的保守估計值,M 系列 VM 相當於約 19,000 MIPS。 針對大型主機進行 MIPS 評估的一般規則為每個處理器 1,000 MIPS。 z14 大型主機最多可擁有 24 個處理器,並針對單一大型主機系統提供大約24,000 MIPS。

最大型的單一 z14 大型主機,相較於 Azure 中可用的最大型 VM,約多出 5,000 MIPS。 但請務必比較工作負載的部署方式。 如果應用程式和關聯式資料庫同時出現於大型主機系統中,通常會部署在相同的實體大型主機上,並且位於各自的 LPAR 內。 而相同的解決方案,在 Azure 上則通常會針對應用程式使用一個 VM,並為資料庫部署一個單獨、適當大小的 VM。

例如,如果 M64 vCPU 系統支援應用程式,而且資料庫使用 M96 vCPU,則需要約 150 個 vCPU,或大約 24,000 MIPS,如下圖所示。

比較 24,000 MIPS 的工作負載部署

方法便是將 LPAR 移轉至個別 VM。 如此一來,Azure 便能針對部署於單一大型主機系統上的大部分應用程式,根據其需求輕鬆地調整大小。

Azure 計算擴增

Azure 型解決方案的優點之一是能夠相應放大。調整可讓應用程式使用幾乎無限的計算容量。 Azure 支援數種方法來擴增計算能力:

  • 在叢集之間取得負載平衡。 在此案例中,應用程式可以使用負載平衡器或資源管理員,將工作負載分散到叢集的多個 VM 中。 如果需要更多計算容量,則會新增其他 VM 至叢集。

  • 虛擬機器擴展集。 在此高載案例中,應用程式可以根據 VM 使用量擴充至額外的計算資源。 當需求下降時,擴展集的 VM 數目也會減少,以確保計算能力的使用效率。

  • PaaS 規模調整。 Azure PaaS 供應項目可調整計算資源。 例如,Azure Service Fabric 會配置計算資源,以符合要求量的增加。

  • Kubernetes 叢集。 此外,Azure 上的應用程式也能使用 Kubernetes 叢集,作為指定資源的計算服務。 Azure Kubernetes Service (AKS) 屬於受控服務,可在 Azure 上協調 Kubernetes 節點、集區和叢集。

若要選擇擴充計算資源的正確方法,請務必了解 Azure 和大型主機之間的差異。 重要的是,計算資源共用資料的方式,或是否由計算資源所共用。 在 Azure 中,資料依預設通常不會被多個 VM 共用。 如果擴充計算叢集中的多個 VM 需要資料共用,共用資料必須位於支援此功能的資源中。 如下列章節所討論,在 Azure 上的資料共用會涉及儲存體。

Azure 計算最佳化

您可以針對 Azure 結構中的每個處理層最佳化。 針對每個環境,使用最適合的 VM 類型和功能。 下圖顯示在 Azure 中部署 VM 以支援使用 Db2 的 CICS 應用程式的其中一個可能模式。 在主要站台中,會為生產、生產階段前和測試 VM 部署高可用性。 次要站台供備份和災害復原之用。

每一層也都能提供適當的災害復原服務。 例如,生產環境和資料庫 VM 可能需要熱復原或暖復原,而開發和測試 VM 則支援冷復原。

支援災害復原的高可用性部署

下一步

IBM 資源

Azure Government

更多移轉資源