Nutanix虛擬平台再進化　AOS 6.10開箱部署

最新的Nutanix AOS 6.10版本，在2024年10月正式發佈，並且為「長期支援」（Long Term Support，LTS）版本，除了擁有更長的支援時間12～15個月以及臭蟲修復之外，也包括過去發佈版本的所有新增及增強功能，如圖1所示。

事實上，前一個LTS長期支援版本為AOS 6.5.x，而後續發佈的AOS 6.6和6.7版本皆為「短期支援」（Short Term Support，STS）版本，雖然僅擁有升級及維護3～6個月的支援期間，但此版本的主要功能在於提供新增特色功能。

至於前一個版本AOS 6.8，則是屬於「短期擴充支援」（Extended Short Term Support，eSTS）版本，雖然主要也是以提供新增特色功能為主，但提供比STS短期支援更長的12個月支援時間，詳細資訊可參考Nutanix KB-5505知識庫文件。

AOS亮眼新功能介紹

如上所述AOS v6.10版本為LTS長期支援版本，主要在於臭蟲修復和系統穩定性，但也同時包括過去STS的AOS v6.6和v6.7版本，以及eSTS的AOS v6.8和v6.8.1的新增特色功能，下列將逐一盤點這些亮眼新功能能夠對企業和組織的地端資料中心帶來哪些優勢。

AOS 6.6採用第八代AHV虛擬化平台

在2023年1月發佈的AOS 6.6版本中，採用新版的Prism Central 2022.9，搭配第八代的AHV虛擬化平台，除了在AHV Hypervisor當中包含最新開放原始碼元件之外，也減少許多系統服務和Open vSwitch虛擬交換器當中有關無效中斷的情況，以便提升系統空閒時輪詢的執行效率，對於EUC和VDI虛擬桌面等密集系統，以及針對延遲時間敏感的EPIC和SAP工作負載，在效能表現上都有明顯地提升。

此外，在這個版本中，Guest VM客體作業系統也開始支援採用「虛擬可信任平台模組」（Virtual Trusted Platform Module，vTPM）的Windows 11作業系統，以便提升針對韌體攻擊的安全性，如圖2所示。

在過去的AOS 6.1舊版中，「儲存原則」（Storage Policy）是套用於儲存容器當中，然後將VM虛擬主機存放至符合需求的儲存容器，一旦運作環境中有多個叢集時，必須分別為每個叢集建立儲存容器才行。

從AOS 6.6版本開始，管理人員只要在PC管理主控台中建立儲存原則，便能將儲存原則套用至VM虛擬主機，也無須為每個叢集分別建立儲存容器，並且支援將「複寫份數」（Replication Factor，RF）套用至VM虛擬主機層級，同時也提供儲存原則檢查功能，幫助管理人員快速找出不符合儲存原則的VM虛擬主機，如圖3所示。

雖然過去的AOS版本皆支援「遠端直接記憶體存取」（Remote Direct Memory Access，RDMA），但是在組態設定RDMA的時候較為麻煩，必須實體網路交換器搭配PFC優先流量控制，和ECN明確壅塞通知等組態設定，同時在使用Foundation部署和建立叢集時，便要進行RDMA的啟用設定才行。

從AOS 6.6版本開始，只要採用支援「零接觸RoCE」（Zero Touch RoCE，ZTR）功能的RDMA網路卡，便可組態設定啟用RDMA功能，無須搭配實體網路交換器的組態設定，因此也無須擔心實體網路交換器的相容性，同時也不必強制在Foundation部署和建立叢集時啟用，現在只要透過Prism管理介面，便能輕鬆啟用RDMA特色功能，提升整體儲存效能並降低CPU工作負載，如圖4所示。

在AOS 6.6版本中，也針對「重複資料刪除」（Deduplication）和「清除編碼」（Erasure Coding，EC）這兩大儲存功能進行增強。在重複資料刪除的部分，改為在「Sub Extent」層級便進行處理，以便提升執行效率，而非過去傳統整個1MB Extent層級進行處理。

在清除編碼的運作機制中，雖然與傳統RAID-5/RAID-6運作機制類似，主要差異在於資料和Parity驗算，是分布在單台伺服器節點上，而非分布在本機儲存裝置中，同時在更新資料時會重新計算Parity所需要的叢集資源，並且只有被系統判斷為「Write-Cold」的資料，才會進行清除編碼的動作，也因為Nutanix物件資料僅會寫入一次，所以能夠最佳化儲存空間和叢集運算資源，如圖5所示。

此外，在AOS 6.6和PC 2022.9版本中，針對NearSync的增強支援20秒RPO。簡單來說，在叢集中受到NearSync保護的VM虛擬主機，除了具備每小時「復原點」（Recovery Points）外，還能夠恢復最後15分鐘的NearSync快照內容，如圖6所示。

AOS 6.7支援跨叢集即時遷移VM

AOS 6.7為搭配Prism Central 2023.3管理主控台，同時包括新一代的AHV 9虛擬化平台。在舊版的AOS平台中，雖然可以透過AHV Metro Availability機制，如圖7所示，搭配兩個叢集之間啟用同步儲存複寫技術，達到類似將VM虛擬主機在兩個叢集之間遷移的效果，但是在組態設定上管理人員需要花費更多心力才行。

從AOS 6.7版本開始，無須像過去繁雜的組態設定，以及兩個叢集之間是否由同一台PC管理主控台所納管，都可以透過「跨叢集即時遷移」（Cross-Cluster Live Migration，CCLM）機制，將VM虛擬主機工作負載，跨越不同叢集進行即時遷移，除了遷移過程中不會造成VM虛擬主機停機事件外，如圖8所示，也整合跨多個CPU處理器核心和網路進行多執行緒處理，讓整體遷移時間比過往版本更快完成。

此外，在執行虛機跨叢集即時遷移之前，系統還會執行相關檢查任務，例如目標主機的CPU、記憶體、儲存、GPU、虛擬網路等是否符合需求，必須通過檢查後才能順利執行遷移工作。

在Nutanix Guest Tools（NGT）軟體部署方面，從AOS 6.7版本開始也有所提升，以便簡化大規模部署NGT，開始支援使用軟體套件管理工具進行安裝，無須像過去需要透過SSH或WinRM連線，進入每一台VM虛擬主機執行安裝作業。

現在，針對Windows虛擬主機支援exe安裝執行檔，以及Linux虛擬主機支援deb和rpm安裝檔，同時支援第三方軟體套件管理工具，例如Microsoft Intune、HCL BigFix等端點管理工具，或採用Ansible自動化機制，達成NGT軟體客製化安裝的目的。

另外，在AOS 6.7版本中，針對AHV虛擬化平台的儲存效能提升再次最佳化。簡單來說，透過AHV Turbo Mode技術，最大化提升資料路徑的工作效率，在使用者空間中達成多個I/O佇列，以便最大化提升資料儲存多工特性，同時降低AHV節點主機的CPU處理器使用率。

預設情況下，AOS和AHV之間的路徑連接，採用iSCSI通訊協定達成，若採用支援的RDMA介面卡，則能透過iSCSI Extensions for RDMA（iSER）進一步將資料直接傳輸到Stargate中，無須中斷系統的CPU處理程序，因此除了避免再次複製記憶體資料外，並降低CPU處理器使用率，達到降低網路延遲提升儲存效能的目的（圖9）。

AOS 6.8發佈X-Small PC管理主控台

首先，在AOS 6.8版本中，針對資料庫工作負載的部分，透過AES、Blockstore、SPDK等機制提升儲存效能，其中「自主擴充儲存」（Autonomous Extent Store，AES）機制，如圖10所示，最佳化後的中繼資料機制，有效降低CPU處理器使用率並提升效能，特別是在工作負載產生持續隨機讀取和寫入資料的情境中。

根據Nutanix內部測試結果顯示，最佳化後的AES機制讓大型資料庫工作負載，例如Oracle或Microsoft SQL資料庫工作負載，在IOPS儲存效能整體表現提升17%，並且資料讀取延遲時間降低16%，而資料寫入延遲時間則降低3%，如圖11所示。

從AOS 6.8版本開始，當管理人員的PC管理主控台納管多個叢集時，在建立VM虛擬主機選擇目標叢集時，將會發現系統多出一個「自動選擇叢集」（Automatic Cluster Selection）選項，如圖12所示，簡單來說，採用此選項時，系統將會自動根據叢集資源可用性、主機親和性、VM虛擬主機規格等等，更聰明地放置VM虛擬主機至適合的叢集運作。

在過去的PC管理主控台規格中，即便是最小的Small PC也需要至少6 vCPU、28GB vRAM、500GB vDisk的資源，這對於小型規模的叢集來說，可能占用過多的資源，導致無謂的資源浪費，並且減少可分配給VM虛擬主機工作負載的資源。

從AOS 6.8版本開始，支援X-Small PC規格，只要4 vCPU、18GB vRAM、100GB vDisk資源即可，如圖13所示，但是能夠管理的叢集規模也可以符合小型企業及組織的需求，X-Small PC支援管理5個叢集、50台AHV主機、500台VM虛擬主機、5位管理人員同時操作。

值得注意的是，X-Small PC規格的管理主控台，不支援用於中大型規模的相關功能，例如不支援將X-Small PC由原本單台VM虛擬主機擴充至具備高可用性的3台VM虛擬主機架構，不支援Nutanix DR異地備援機制，不支援Nutanix NKP容器引擎、不支援Flow Virtual Networking和Flow Network Security等等功能，若需要這些中大型規模的相關功能時，必須先將X-Small PC升級為Small、Large、X-Large規格的PC管理主控台才行。

實戰部署AOS 6.10

由於最新發佈的Nutanix CE 2.1版本中，採用的是AOS 6.8.1而非最新發佈的AOS 6.10版本，但是管理人員會發現，即便安裝Nutanix CE 2.1版本後，在AOS 6.8.1叢集中嘗試使用LCM更新至AOS 6.10版本時，仍會發現系統提示無法辨別硬體類型而失敗，如圖14所示，並提示參考Nutanix KB-15185知識庫文章。

簡單來說，因為是巢狀式虛擬化環境，所以無法通過LCM更新機制的硬體伺服器驗證程序。雖然無法透過LCM更新機制將Nutanix CE 2.1安裝的AOS 6.8.1升級至AOS 6.10，但管理人員可以透過部署Foundation VM，以及下載最新AOS 6.10和AHV映像檔，製作出可進行單台安裝作業的Nutanix CE ISO客製化映像檔。

部署Foundation VM

首先，登入Nutanix支援網站，下載最新版本的Foundation VM，如圖15所示，值得注意的是，企業組織必須具備Nutanix相關軟體授權，才能下載Foundation、AOS、AHV相關映像檔，本文實作環境中，將下載可部署於VMware Workstation環境的Foundation_VM-5.7.tar檔案。

將下載的Foundation_VM-5.7.tar檔案解壓縮，就會解壓縮出.ovf和.vmdk檔案。開啟Vmware Workstation，然後依序點選「File > Open > Foundation_VM-5.7.ovf」，接著鍵入匯入後的VM虛擬主機名稱和路徑，再按下〔Import〕按鈕。

執行開機作業後，預設情況下會自動登入，倘若遇到需要鍵入身分驗證資訊時，鍵入預設的管理者帳號「nutanix」及密碼「nutanix/4u」。順利登入後，在圖形介面中依序點選「System > Preferences > Internet and Network > Advanced Network Configuration > Ethernet > Wired connection 1」，點選IPv4 Settings頁籤後，將預設的Automatic（DHCP）選擇至「Manual」項目，然後按下〔Add〕按鈕，鍵入固定IP位址資訊。本文實作環境中，IP位址、網路遮罩、預設閘道分別是「10.10.75.25, 24, 10.10.75.254」，按下〔Save〕按鈕後重新啟動主機。重新啟動完成並登入系統後，開啟瀏覽器鍵入「https://fvm.lab.weithenn.org:8000」，即可測試連線至Foundation的部署畫面，如圖16所示。

建立客製化AOS 6.10 ISO映像檔

雖然官方並未正式發佈採用最新AOS 6.10的Nutanix CE ISO映像檔，但是這裡只要在原有的Nutanix CE 2.1 ISO映像檔中，把AOS 6.8.1和搭配的AHV映像檔置抽掉即可。下列為前置作業準備的ISO映像檔：

‧Nutanix CE 2.1 ISO映像檔：phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso

‧AOS 6.10壓縮檔：nutanix_installer_package-release-fraser-6.10-stable-45706f65299ffde905da43b6e7d98478d071b7b9-x86_64.tar.gz

‧AHV ISO映像檔：AHV-DVD-x86_64-el8.nutanix.20230302.102001.iso

首先，由於AOS 6.10壓縮檔容量超過4GB，所以必須將檔案進行拆分才行，管理人員可以挑選順手的工具，在本文實作環境中則採用ExpLZH for Windows工具，將檔案以3GB的分式進行分割，執行後可以發現總共產生3個檔案，分別是結尾的.001、.002、.BAT，其中.BAT檔案可以刪除無須保留，拆分後的檔案重新命名為「nutanix_installer_package.tar.p00」和「nutanix_installer_package.tar.p01」。

接著使用WinSCP工具，將拆分後的AOS 6.10檔案、Nutanix CE 2.1映像檔、AHV映像檔上傳至Foundation VM主機「/home/weithenn」路徑，再執行「sudo mount phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso /mnt/iso」指令來掛載Nutanix CE 2.1映像檔，建立名稱為AOS610的資料夾後，將掛載的Nutanix CE 2.1映像檔所有資料夾和檔案複製到AOS610資料夾，再卸載Nutanix CE 2.1映像檔。

把路徑中「AOS610\images\svm」內的檔案，置換成剛才拆分的兩個AOS 6.10檔案，將路徑中「AOS610\images\hypervisor\kvm」內的檔案刪除，並複製AHV映像檔進去。現在，即可執行genisoimage指令，打包客製化具備AOS 6.10和AHV的Nutanix CE ISO映像檔，切換到「/home/weithenn/AOS610」路徑後，執行「sudo genisoimage -o .. /nutanix-ce-aos-6.10.iso -R -J -T -V PHOENIX -b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table .」指令，系統便會打包出名稱為「nutanix-ce-aos-6.10.iso」的ISO映像檔，如圖17所示。

建立支援巢狀技術的VM虛擬主機

在巢狀式虛擬化環境內，AOS 6.5和先前的舊版中，AHV和CVM均採用CentOS 7.9作業系統版本，然而從AOS 6.8版本開始，AHV和CVM則改為升級採用Rocky Linux 8.9作業系統版本。

因此，在開啟VMware Workstation虛擬化軟體，點選Create a New Virtual Machine選項後，選擇Guest OS客體作業系統時，須選擇Linux選項中的「Rocky Linux 8 64-bit」項目，如圖18所示，待安裝程序完成後，屆時管理人員登入便能看到AHV和CVM採用Rocky Linux 8.9作業系統版本。

在SCSI硬碟控制器部分，雖然系統預設建議採用LSI Logic類型，倘若安裝VMware Workstation的主機採用的是SSD固態硬碟而非一般HDD機械式硬碟時，建議改為選擇採用「Paravirtualized SCSI」硬碟控制器，如圖19所示，可以有效加快VM虛擬主機的運作效率。

在選擇vDisk虛擬硬碟類型時，由於採用Rocky Linux 8作業系統版本，所以系統預設採用的vDisk虛擬硬碟類型是「NVMe」，請改為採用「SCSI」選項，如圖20所示，否則屆時安裝完成後，由於巢狀式VM虛擬主機採用模擬的NVMe固態硬碟，將會導致CVM主機將無法順利啟動。

此外，在完成建立VM虛擬主機後，先別急著開機進入安裝程序，使用系統管理員權限開啟Notepad筆記本，修改Guest Hypervisor虛擬主機的「.vmx」組態設定檔，加上「disk.EnableUUID = "TRUE"」參數值，確保指派給vDisk虛擬硬碟Serial Number序列號，否則在稍後的安裝程序中，可以看到硬碟未顯示Serial Number，後續也將導致啟動叢集服務時，在Medusa服務啟動環境時卡住並產生錯誤，造成叢集無法順利啟動。

在安裝畫面中，如圖21所示，可以看到確實採用最新的AOS 6.10版本，以及搭配的AHV虛擬化平台版本20230302.102001，在IP位址的配置如下：

‧Host IP Address：10.10.75.11

‧CVM IP Address：10.10.75.12

‧Subnet Mask：255.255.255.0

‧Gateway：10.10.75.254

部署AOS 6.10叢集

安裝完成並重新啟動主機後，可以從Console登入或透過SSH Client登入AHV虛擬化平台和CVM主機，下列為系統預設的管理者帳號密碼：

‧AHV：SSH登入、管理帳號root、管理密碼nutanix/4u

‧CVM：SSH登入、管理帳號 nutanix、管理密碼nutanix/4u

‧Prism Element：Web登入、管理帳號admin、管理密碼nutanix/4u

首先，登入AHV虛擬化平台，執行「cat /etc/rocky-release」指令，可以發現最新AOS 6.10的AHV虛擬化平台採用Rocky Linux 8.10作業系統版本，如圖22所示。接著執行「virsh list」指令，查詢運作於AHV虛擬化平台之上的CVM主機運作情況，當State欄位狀態由原本的paused轉換為「running」，就表示CVM主機已經啟動完畢。

確認CVM主機成功運作後，同樣可以透過SSH Client登入CVM主機，執行「cat /etc/rocky-release」指令，查詢CVM主機為採用Rocky Linux 8.9作業系統版本。再執行「ip -c -br a」指令查詢CVM網路組態，可以看到「eth0」介面已使用先前安裝程序中組態設定的「10.10.75.12」位址，而「eth1」介面則為系統預設的「192.168.5.2」和「192.168.5.254」位址。

確認AHV和CVM網路組態設定無誤後，由於本次是部署單一節點的叢集，所以在「資料可用性」（Data Resiliency）部分只能搭配「--redundancy_factor=1」參數，也就是不支援資料保護的狀況，如果需要確保資料可用性，必須部署多台節點的叢集才能支援。

切換到CVM主機操作畫面，執行「cluster -s 10.10.75.15 --redundancy_factor=1 create」指令，如圖23所示，部署並啟動叢集的動作，需要等待一段時間才能完成。在叢集自動部署工作流程中，可以看到相關系統服務逐一啟動中，整個叢集的指揮中心名稱為ZeusLeader。一旦所有叢集系統服務皆順利啟動，系統將會出現「INFO MainThread cluster:3104 Success!」訊息，表示叢集部署作業已經順利完成，後續管理人員需要確認叢集狀態時，只要執行「cluster status」指令就能夠進行確認。

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞