網管人雜誌
本文刊載於 網管人雜誌第 239 期 - 2025 年 12 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
在最新發佈的 Nutanix 版本中，AOS 和 Prism Central（PC）的版本將會對齊，例如，AOS 7.3 和 PC 7.3，至於 AHV Hypervisor 的部份，則是會在次要版本對齊，例如，AHV 10.3，讓企業和組織能夠對於版本的選擇上，可以快速且立即判斷版本資訊。
在 Nutanix AHV 10.3 版本中，推出「Automatic Cluster Selection」特色功能有更多的功能性增強，進一步提升 VM 部署的智慧化與彈性。事實上，Automatic Cluster Selection 特色功能，在 AOS 6.8 版本時便推出，但是在最新發佈的 Nutanix AHV 10.3 版本中則增強許多特色功能。
那麼 Automatic Cluster Selection 特色功能的用途為何？ 簡單來說，它是 Nutanix AHV 虛擬化平台中的一項，針對 VM 虛擬主機部署的增強機制，當管理人員在 Prism Central 主控台中，部署 VM 虛擬主機時，系統會根據多項資源條件進行判斷後，自動選擇最適合運作該台 VM 虛擬主機的 Nutanix 叢集進行部署作業，如此一來不僅簡化整體操作流程，也降低人為判斷而導致選擇錯誤的風險（如圖 1 所示）。
圖 1、整合 Automatic Cluster Selection 機制的 PC 主控台情境判斷示意圖
值得注意的是，Automatic Cluster Selection 自動選擇機制，僅僅是在 VM 虛擬主機進行一開始部署的時候，自動選擇適合的 Nutanix 叢集進行部署，一旦 VM 虛擬主機部署完成並開始運作後，叢集資源的負載平衡作業，就會交由 Acropolis Dynamic Scheduling（ADS）來負責。
最佳建議作法
Memory Overcommit
在虛擬化基礎架構中，相信大家對於「Memory Overcommit」機制應該要非常熟悉才對（如圖 2 所示）。簡單來說，在 AHV 虛擬化平台中，透過內建的 Memory Overcommit 機制，可以讓 AHV 虛擬化平台中，運作的 VM 虛擬主機數量呈現線性增加的一種技術，舉例來說，在 Nutanix 叢集中，其中一台叢集節點主機具備 128 GB 實體記憶體，然而卻能夠運作 10 台甚至更多台，組態設定 16 GB vMemory 的 VM 虛擬主機，這便是透過 Memory Overcommit 機制，達到虛擬化架構 VM 集縮比的功能之一。
圖 2、部署 VM 虛擬主機時啟用 Memory Overcommit 機制
但是，每項特色功能和機制，都有其適用情境和注意事項，舉例來說，在 Nutanix 官方的最佳建議作法中，Memory Overcommit 機制便非常適合使用於測試或研發環境，但是對於企業和組織的正式營運環境，卻不建議使用，原因在於 Memory Overcommit 機制，雖然可以達成超用記憶體資源，進而運作更多的 VM 虛擬主機和其它工作負載，然而卻可能導致 VM 虛擬主機效能下降，影響營運環境的反應速度，可能造成使用者體驗不佳的情況。
因此，在預設情況下，Nutanix 官方並不建議管理人員，啟用 AHV 虛擬化平台中的 Memory Overcommit 機制。那麼，管理人員可能會感到困惑，在不啟用 Memory Overcommit 機制的情況下，AHV 虛擬化平台又是如何達成，運作數量龐大的 VM 虛擬主機呢？ 答案就是透過 Ballooning 和 Swapping 機制。
首先，在 Nutanix 虛擬化架構中的 VM 虛擬主機，必須確保已經安裝 VirtIO 驅動程式，系統便會透過 VirtIO 驅動程式整合 Ballooning 機制，將 VM 虛擬主機中未使用到的記憶體空間，歸還給 AHV 虛擬化平台，以便提供給其它需要的 VM 虛擬主機進行使用。
舉例來說，管理人員組態設定 3 台配置 20 GB 虛擬記憶體的 VM 虛擬主機，但是對於 AHV 虛擬化平台來說，卻僅僅使用了 40 GB 記憶體空間，那麼這是如何辦到的呢？ 簡單來說，Ballooning 機制會將 VM 虛擬主機中，虛擬記憶體的真實使用情況，回報給底層的 AHV 虛擬化平台，然後 AHV 虛擬化平台便可以針對 VM 虛擬主機中，未使用到的記憶體空間進行回收作業，然後將回收後的記憶體資源，提供給其它 VM 虛擬主機使用，達成動態配置記憶體資源的效果（如圖 3 所示）。
圖 3、AHV 虛擬化架構中 Ballooning 運作機制示意圖
當然，倘若 VM 虛擬主機需要使用到更多記憶體資源時，在 VM 虛擬主機中透過 VirtIO 整合的 Ballooning 機制，便會通知底層 AHV 虛擬化平台後，在不影響 VM 虛擬主機正常運作的情況下，將可用的記憶體空間慢慢進行收回的動作，以便增加可用的記憶體資源。
然而，在工作負載眾多，記憶體資源爭奪強烈的環境中，有可能 Ballooning 機制會來不及調度記憶體空間，並且眾多 VM 虛擬主機使用的記憶體空間加總後，超過 AHV 虛擬化平台所擁有的總記憶體空間時又該怎麼辦？ 此時，就需要使用到 Swapping 機制了 !
當眾多 VM 虛擬主機因為同時間工作負載提升，總共使用的記憶體空間，超過 AHV 虛擬化平台的實體記憶體空間時，系統將會採用「Least Recently Used（LRU）」演算法機制，將不足的記憶體空間，透過 Host Swap 的方式，來滿足 VM 虛擬主機超用的記憶體需求。然而，管理人員應特別注意，因為採用 Host Swap 的方式，所給予 VM 虛擬主機記憶體資源，與使用實體記憶體空間在運算效能上有非常大的差異（如圖 4 所示）。
圖 4、AHV 虛擬化架構中 Ballooning+Swapping 運作機制示意圖
因此，倘若管理人員發現 Host Swap 的情況經常發生時，首先應該考慮為叢集節點主機擴充實體記憶體空間，倘若無法擴充實體記憶體空間的話，則建議的過渡方式為採用 VM 虛擬主機內的 Swap 機制，因為相較之下 Guest Swap 會比 Host Swap 來得有效率。
舉例來說，組態設定 VM 虛擬主機配置 20GB 虛擬記憶體，但是卻會使用到 Host Swap 機制時，不如考慮調整 VM 虛擬主機的組態設定，將其配置為 10GB 虛擬記憶體，並且搭配 VM 虛擬主機內作業系統的 Swap 機制，透過 Guest Swap 機制中 10GB Swap Disk 來滿足過渡需求。
ADS + Memory Overcommit
實務上，在 Nutanix 虛擬化架構中，預設情況下便會啟用 Acropolis Dynamic Scheduler（ADS）負載平衡機制，那麼當 ADS 負載平衡搭配 Memory Overcommit 機制時，又如何因應各式各樣的工作負載情境。舉例來說，在 AHV 虛擬化平台，具備 40GB 記憶體空間的運作環境中，已經組態設定 3 台配置 10GB 虛擬記憶體的VM 虛擬主機，並且需要再啟動 1 台配置 15GB 虛擬記憶體的 VM 虛擬主機時，系統將會發生什麼情況呢？
首先，AHV 虛擬化平台將會進行記憶體可用空間估算作業，假設 3 台配置 10GB vMemory 的 VM 虛擬主機，已經使用記憶體資源池 30GB 的記憶體空間，當需要再啟動 1 台配置 15GB vMemory 的 VM 虛擬主機時，系統會先透過剛才提到的 Ballooning 和 Swapping 機制，嘗試回收尚未被 VM 虛擬主機佔用的記憶體空間，假設系統順利收回 5GB 記憶體空間，此時記憶體資源池降低為使用 25GB 記憶體空間，接著透過 ADS 負載平台機制中，Initial Placement 初始化配置機制，來啟動配置 15GB vMemory 的 VM 虛擬主機（如圖 5 所示）。
圖 5、實務上 ADS 搭配 Memory Overcommit 運作機制示意圖
記憶體空間集縮比
預設情況下，每台 VM 虛擬主機，系統都會確保至少有 25% 的記憶體空間，來自於 AHV 虛擬化平台的實體記憶體空間，這表示當管理人員在部署 VM 虛擬主機時，啟用 Memory Overcommit 機制時，系統透過 Ballooning + Swapping 機制時，最多可以預留 VM 虛擬主機 75% 的虛擬記憶體空間。
當然，預留 25% 和 75% 記憶體空間為理想情況下，然而在實際運作情況下，組態設定 4 台配置 10GB vMemory 的 VM 虛擬主機環境中，每台 VM 虛擬主機最大化縮小至使用 25% 的記憶體空間，所以總共使用 AHV 虛擬化平台中，記憶體資源池內 10GB 記憶體空間。
此時，便可以再額外啟動 3 台配置 10GB vMemory 的 VM 虛擬主機，因為 VM 虛擬主機剛啟動時，客體作業系統會需要使用全部的記憶體空間，但是開機完成經過一段時間後，待客體作業系統內的服務和應用程式啟動完畢後，使用的記憶體空間便會逐漸下降，此時系統便可以透過 Ballooning + Swapping 機制，開始回收 VM 虛擬主機未佔用的記憶體空間，以便提供給更多的 VM 虛擬主機使用。
透過範例圖表可知，當 AHV 虛擬化平台配置 40GB 實體記憶體時，在每台 VM 虛擬主機配置 10GB vMemory 的情況下，最理想的情況可以達到「3.25 倍」的集縮比，也就是能夠運作最多 13 台配置 10GB vMemory 的 VM 虛擬主機（如圖 6 所示）。
圖 6、Memory Overcommit Ratio 範例圖表
值得注意的是，範例表格中的估算，為假設 Nutanix 叢集未啟用 High Availability（HA）高可用性機制，倘若啟用 HA 高可用性機制後，系統為了保留更多系統資源以便因應故障事件，因此 Memory Overcommit 集縮比例將會下降至「1.33 倍」。
線上遷移時間
在 AHV 虛擬化平台版本升級過程中，正常情況下系統會將 AHV 節點主機進入維護模式，當升級程序執行完畢後，AHV 節點主機需要重新啟動以便套用生效，然而在此之前必須先將其上運作的 VM 虛擬主機，透過 ADS Live Migration 機制，將 VM 虛擬主機線上遷移至其它 AHV 節點主機繼續運作。
倘若，管理人員已經啟用 Guaranteed HA 功能時，那麼每一台 VM 虛擬主機，要線上遷移的目地端 AHV 節點主機已經確認完畢，系統會直接將 VM 虛擬主機線上遷移過去，倘若未啟用 Guaranteed HA 功能的話，便會透過 ADS 負載平衡機制，識別每一台 VM 虛擬主機適合運作的 AHV 節點主機後，再進行線上遷移作業。
在線上遷移 VM 虛擬主機時，因為過程中牽涉到記憶體空間複製的動作，並且需要遷移所有的實體記憶體空間。然而，啟用 Memory Overcommit 機制的 VM 虛擬主機，因為使用的記憶體空間並非全部都是實體記憶體空間，所以會導致遷移時間較久的情況發生。
簡單來說，「未啟用」Memory Overcommit 機制的VM虛擬主機，因為都是使用實體記憶體空間，所以相較之下能夠在較短的時間內遷移完畢，而「啟用」Memory Overcommit 機制的 VM 虛擬主機，則因為要將 Swapping 虛擬記憶體空間，回寫至實體記憶體空間中，導致遷移時間較長並會影響運作效能，這也是 ADS 負載平衡機制在計算遷移成本時，啟用 Memory Overcommit 機制的 VM 虛擬主機，會是較高遷移成本的主要原因（如圖 7 所示）。
圖 7、ADS 負載平衡機制線上遷移 VM 虛擬主機示意圖
AHV 記憶體資源開銷估算
事實上，企業和組織的管理人員，可以在導入之前，針對日後預計啟用的特色功能和 VM 虛擬主機數量，估算 AHV 虛擬化平台的運算資源。下列舉例，雖然不是絕對值，也可能因為日後版本的增強而不同，但管理人員可以使用下列基準來進行估算：
- AHV 節點主機，每台主機至少需要 3.5 GB 記憶體空間，外加系統總記憶體的 2.2% 資源開銷。
- 日後預計在 PC 主控台中，啟用 Flow Virtual Networking 特色功能時，每台主機 2 GB 記憶體空間開銷。倘若，需要啟用 Flow MicroSegmentation 特色功能時，每台主機 4 GB 記憶體空間開銷。
- 當 AHV 節點主機安裝 GPU 時，將會產生系統總記憶體的 1.5% 資源開銷。
根據上述的資源開銷估算原則，舉例來說，一台配備 256GB 實體記憶體空間的 AHV 節點主機，預計啟用 Flow Virtual Networking 和 Flow MicroSegmentation 特色功能時，記憶體空間的開銷為 15GB（3.5 + 256 × 0.022 + 2 + 4），表示還剩餘 241G 記憶體空間，可以用於運作 CVM 主機和其它 VM 虛擬主機等工作負載。
此外，VM 虛擬主機也會因為配置不同，而有額外的記憶體資源開銷，一台標準的 VM 虛擬主機，在配置一個 VirtIO 網路卡並且沒有配置 vGPU 的情況下，基本記憶體資源開銷為 50MB 。
同時，隨著 vCPU 數量和 vMemory 的組態設定不同，VM 虛擬主機的記憶體開銷也會隨之增加。舉例來說，每增加 1 個 vCPU 處理器時，便會增加 1MB 的記憶體資源開銷，而每增加 1GB vMemory 時，也會增加 7MB 的記憶體資源開銷。
因此，一台配置 8 vCPU 及 8GB vMemory 的 VM 虛擬主機，將會產生額外的 114MB 記憶體資源開銷（如圖 8 所示）。
圖 8、VM 虛擬主機額外記憶體資源開銷範例圖表
vCPU 和 pCPU 集縮比
在實務應用上，雖然 VM 虛擬主機的 vCPU 運算資源，通常不是最先遭遇效能瓶頸的資源，然而失衡的 vCPU 和 pCPU 集縮比例，除了造成 AHV 節點主機額外的記憶體資源開銷以外，也容易影響 VM 虛擬主機的運算效能。
舉例來說，AHV 節點主機的 x86 實體伺服器，共配置 2 顆 CPU 處理器，每顆 CPU 處理器具備 24 個運算核心，那麼這台的 AHV 節點主機便具備 48 pCPU，可能會有管理人員不解，開啟 Hyper-Threading（HT）功能後，處理器核心增加一倍不是應該用 96 pCPU 來計算？
這個問題筆者認為見仁見智，主要原因在於，透過 HT 功能進而成長的核心數，並非真正的運算單位，而是採用軟體機制搭配邏輯方式增加核心數，並且僅在特定情況下才能提升運算能力，所以開啟 HT 功能的 2 pCPU，並非真正能達到 2 倍的核心運算速度，在支援 SMP 多執行緒的情況下，最多僅能達到 1.2 – 1.4 倍的核心運算能力。
並且從虛擬化平台在 CPU 資源調度時也可以得知，倘若需要指派 2 個運算核心時，CPU 調度機制肯定會優先指派給，開啟 HT 機制中倘未使用的核心數，而非指派給已經使用 1 個開啟 HT 的核心資源，這也就是為什麼開啟 HT 功能的核心數，嚴格來說稱不上是真正的實體運算核心單位的主要原因之一。
那麼 vCPU 和 pCPU 多少的集縮比例才是最佳？ 這個問題的解答很難一概而論，主要原因在於工作負載情況非常複雜，但是卻有通用原則，當然管理人員最後還是必須依照實際情況進行調整。 Nutanix 官方的最佳建議作法中，針對 Tier 1 層級的 VM 虛擬主機，也就是關鍵營運服務和延遲敏感的應用程式，建議採用的 vCPU 和 pCPU 集縮比例為「1:1 或 2:1」，而針對 Tier 2 層級的 VM 虛擬主機，則建議採用的 vCPU 和 pCPU 集縮比例為「2:1 或 4:1」（如圖 9 所示）。
圖 9、針對 Tier 1/ Tier 2 的 vCPU 和 pCPU 集縮比例建議值
CVM 運作規模最佳化
在 Nutanix 超融合運作環境中，HCI 超融合節點主機，每台 HCI 主機皆會啟動 Controller VM（CVM）主機，並且預設分配 8 vCPU 和 32 GB vMemory 虛擬硬體資源，透過 PCI Passthrough 方式直接存取本地磁碟裝置，以便提供分散式儲存服務（如圖 10 所示）。
圖 10、HCI 超融合節點主機運作架構示意圖
原則上，CVM 主機只會在需要時才佔用 CPU 運算資源，其中為 CVM 配置的 vCPU 數量，僅表示最大可使用量而非固定使用量，同時叢集規劃時需要留意維護或失效時的資源容錯情況，尤其針對 SQL Server、Exchange Server……等企業和組織關鍵應用服務。
從 AOS 5.11 版本開始，AHV 叢集節點主機支援「純運算節點」（Computer Node）。簡單來說，Computer Node 主機上，不會運作 CVM 主機以因應運算為主的應用，例如，大型 Oracle……等專屬應用情境，但是採用純運算節點時，有嚴格的佈署與擴充節點上的限制（如圖 11 所示）。
圖 11、HCI 超融合節點主機搭配純運算節點主機運作架構示意圖
同時，因為純運算節點中沒有 CVM 主機，能夠協助處理分散式儲存機制，所以也無法享有資料本地性的嚴重缺點。值得注意的是，純運算節點支援運作在 AHV 虛擬化平台，並且不支援運作 Exchange Server 工作負載。
確認採用 HCI 或純運算節點主機類型後，接著便需要確認屆時 Nutanix 叢集中，要運作哪些類型的工作負載為主要考量點，舉例來說，倘若是 ROBO/Edge 小型環境的話，只要為 CVM 配置 6 vCPU 和 20 GB vMemory 虛擬資源即可（如圖 12 所示），倘若需要搭配 Redundancy Factor 3 的資料容錯設定，儲存裝置採用All-NVMe 時，那麼 CVM 就必須提升至 64 GB vMemory 才行。詳細資訊可以參考 AOS 7.0 - Controller VM（CVM）Specifications 文件內容。
圖 12、依照應用情境決定 CVM 運作規模大小示意圖
在 Nutanix 運作環境中，Controller VM（CVM）扮演資料管理中樞，協調使用者I/O、資料放置與 metadata 管理，確保資料完整性與可用性，同時透過垃圾回收、壓縮、重複資料刪除與糾刪碼技術最佳化儲存效率，並支援快照與複製等保護機制。
CVM 的效能關鍵在於分配到的邏輯核心數量，這會依照部署類型、儲存容量、快照頻率與功能啟用情況而有所不同。在 AOS 安裝時，便會根據這些條件自動配置最低邏輯核心「計算方式：物理核心×執行緒數量」，並將 CVM 的邏輯核心對應至同一個 NUMA 節點的獨立實體核心以避免資源競爭，剩餘核心則留給其它運作的 VM 虛擬主機使用，舉例來說，採用 Intel Xeon Gold 5317S 處理器（12 Cores），開啟 Hyper-Threading（HT）技術的情況下，便具備 24 顆邏輯核心，其中上限 12 Cores 分配給 CVM，其餘 12 Cores 則留給其它運作的 VM 虛擬主機使用（如圖 13 所示）。
圖 13、CVM 邏輯核心對應至同一 NUMA 節點獨立運算核心分配示意圖
圖 14、登入 PE 管理介面線上調整 CVM vMemory Size 大小
PC 主控台運作規模最佳化
在 Nutanix 基礎架構中，Prism Central（PC）主控台角色的重要性不言而喻。因此，良好的 PC size 規模大小的規劃，將會影響後續的日常維護作業，本文將說明基礎的Sizing Prism Central（PC）。
簡單來說，在 Prism Central（PC）主控台運作架構中，有分為「單台」和「三台」PC VMs 的運作架構，即便一開始部署的是單台 PC VM，也可以在之後需求增加時，水平擴充成三台 PC VMs 的架構（如圖 15 所示）。
圖 15、PC 主控台分別支援單台和三台的運作架構示意圖
那麼，PC 有哪些運作規模可以選擇呢？ 分別支援 X-Small、Small、Large、X-Large 等四種運作規模，其中 X-Small（4 vCPU，18 GB vMemory，100GB vDisk），是從 AOS 6.8 或後續版本才新增加的運作規模，可以管理 5 Clusters，50 Hosts，500 VMs 大小的叢集環境（如圖 16 所示）。
圖 16、PC 主控台支援 X-Small、Small、Large、X-Large 等四種運作規模
那麼每種 PC size 能夠承載多大規模的叢集環境，舉例來說，Small 規模能夠承載 10 Clusters，200 Hosts，2500 VMs 的叢集環境，詳細資訊可以參考 Nutanix Configuration Maximums | Nutanix Support & Insights 文件內容（如圖 17 所示）。
圖 17、不同 PC 主控台規模支援不同大小的 Nutanix 叢集運作環境
結語
透過本文的深入剖析和實戰演練後，相信管理人員對於 Nutanix 叢集環境中的重要運作元件，包含 PC 和 CVM 運作規模的規劃，以及 Memory Overcommit 的機制的深入了解後，能夠為企業和組織打造出高效能和最佳化的 Nutanix 叢集。