本文將實作Nutanix CE Single Node Cluster，透過深入剖析和實戰演練後，管理人員即便在沒有專屬Nutanix硬體伺服器的情況下，也可以透過巢狀式虛擬化技術，輕鬆建構出Nutanix單節點叢集的運作環境來進行測試和研究。
在Gartner Report HCI超融合魔力象限中，Nutanix常年居於Leader領導者象限內，如圖1所示，然而，當企業和組織的管理人員想要體驗Nutanix各項功能時，採用普通的x86硬體伺服器卻連安裝運作環境都無法順利安裝成功。因此，本文將實戰演練透過「巢狀式虛擬化」（Nested Virtualization）技術，讓IT預算不足的企業和組織也能夠安裝部署及測試體驗Nutanix單節點叢集環境。
圖1 2021年發佈的Gartner HCI超融合報告。 （圖片來源：Gartner Magic Quadrant for Hyperconverged Infrastructure Software）
認識Nutanix CE運作架構
在開始實作前，先說明Nutanix社群版本（Community Edition，CE）的運作架構。
HCI超融合平台
在傳統三層式虛擬化架構中，雖然強大但是較為缺乏彈性，因此Nutanix運作架構便是直接針對更為彈性靈活的超融合基礎架構（HCI）進行設計。值得管理人員注意的是，在每一台主機中都會有AHV（Nutanix Acropolis Hypervisor）、AOS（Nutanix Acropolis OS）、CVM（Controller VM）等三個重要運作元件，如圖2所示。
圖2 傳統三層式架構轉換為HCI超融合架構示意圖。 （圖片來源：Compare HCI & Hybrid Cloud Solutions | Nutanix）
其中AHV是原生Hypervisor並專為AOS所設計，除了擔任虛擬化基礎架構外，也將實體伺服器的網路資源進行整合，而AOS則是運作在CVM主機之上的基礎作業系統，並將儲存、運算、網路等資源整合至軟體定義基礎架構當中，其中CVM主機負責運作許多重要的叢集服務，例如負責資料I/O的Stargate、負責存取介面的Zeus、分佈式Matadata儲存機制的Cassandra、負責叢集組態設定管理的Zookeeper等等，如圖3所示。
圖3 CVM主機內運作許多重要的叢集服務示意圖。 （圖片來源：Controller VM Components | Nutanix Community）
硬體需求
在CPU處理器運算資源方面，最少應配置4 Cores核心，其中有2 Cores核心將給予CVM主機使用，在記憶體資源的部分，建議至少32GB或更多，以便AOS的重複資料刪除或壓縮等儲存機制能夠順利運作。
在安裝硬碟方面，至少需要1顆32GB硬碟擔任Hypervisor Boot Device，1顆200GB SSD固態硬碟擔任Hot Tier也就是屆時CVM主機安裝碟，另1顆500GB的HDD或SSD固態硬碟則擔任Cold Tier，也就是屆時儲存資料的部分。
AHV網路架構
在AHV網路架構上，可以看到運作AOS的CVM主機和OVS（Open vSwitch），每台AHV都會運作一台CVM，除了處理I/O、UI、API和升級等服務之外，並為其上運作的全部VM虛擬主機器提供所有I/O操作。
在AHV預設網路運作架構中，AHV和CVM直接透過Linux Bridge（virbr0/vnet1）網路介面互相溝通，AHV預設採用192.168.5.1，而CVM預設採用192.168.5.2位址，其中CVM同時連接到Linux Bridge virbr0和OVS br0，OVS中的br0橋接器連接每台VM虛擬主機的Tap網路介面，並透過br0-up介面存取實體網卡和外部網路（圖4）。
圖4 AHV網路架構示意圖。 （圖片來源：Integrating Contrail SDN controller to manage overlay networks in an AHV cluster | Nutanix Community）
介紹完Nutanix CE運作架構之後，接下來就開始逐步實作Nutanix CE Single Node Cluster。
建立巢狀式虛擬化環境
由於本文實作環境並非採用裸機方式直接安裝Nutanix Hypervisor，如圖5所示，而是先在硬體主機中透過傳遞硬體輔助虛擬化功能給予VM虛擬主機，讓該台VM虛擬主機擔任Guest Hypervisor，屆時再建立Nested VM虛擬主機，達成「巢狀式虛擬化」（Nested Virtualization）的測試環境。
圖5 Hypervisor運作示意圖。 （圖片來源：What are hypervisors? A complete guide | Nutanix）
屆時Nested VM虛擬主機能否順利建立的關鍵，在於部署Guest Hypervisor虛擬主機時硬體主機是否將硬體輔助虛擬化功能傳遞給Guest Hypervisor虛擬主機。
在本次實作環境中，硬體主機的作業系統採用Windows Server 2022，當然也可以採用Windows 10或Windows 11進行實作。在實作之前先下載Coreinfo工具，並使用系統管理員權限開啟命令提示字元，然後執行「Coreinfo64.exe -v」指令，即可看到硬體主機所支援的硬體輔助虛擬化功能，可以看到這台硬體主機支援VMX和EPT硬體輔助虛擬化功能，如圖6所示，並且目前沒有被任何Hypervisor占用的情況，後續即可順利建立Guest Hypervisor虛擬主機。
圖6 確認硬體主機是否支援VMX和EPT硬體輔助虛擬化功能。
建立Guest Hypervisor虛擬主機
在硬體主機Windows Server 2022作業系統中，安裝VMware Workstation Player虛擬化軟體，在建立Guest Hypervisor虛擬主機的過程中，雖然簡單但仍有些需要注意的部分，否則稍後安裝的Nutanix CE運作環境將無法順利運作，或無法順利建立「單點主機叢集」（Single Node Cluster）。
或許，管理人員會有疑惑，為何不直接使用Windows Server 2022，直接建構Hyper-V巢狀式虛擬化環境來安裝和測試Nutanix CE環境？主要原因在於Hyper-V巢狀式虛擬化環境在安裝Nutanix CE的過程中，進行至AHV Hypervisor安裝作業時，將會因為網路卡驅動程式不支援的關係而導致安裝作業失敗。
開啟VMware Workstation Player虛擬化軟體後，點選Create a New Virtual Machine，選擇載入Nutanix CE ISO映像檔，在選擇客體作業系統時，選擇Linux選項中的「CentOS 7 64-bit」項目，如圖7所示，稍後安裝完成，就可以看到Nutanix AHV和CVM皆採用CentOS 7.9作業系統版本。
圖7 選擇採用CentOS 7 64位元作業系統版本。
接著，組態設定Guest Hypervisor虛擬主機名稱和儲存路徑。在指派硬碟空間時，將預設值20GB調整為50GB儲存空間，屆時此空間將會安裝AHV Hypervisor使用，最後按下〔Finish〕按鈕建立Guest Hypervisor虛擬主機。
建立之後，按下〔Edit virtual machine settings〕按鈕，在記憶體部分，由預設的1GB調整為64GB記憶體空間，在CPU處理器的部分，由預設的1 Core調整為8 Cores，並且要記得勾選「Virtualize Intel VT-x/EPT or AMD-V/RVI」項目，如圖8所示，確保硬體主機的硬體輔助虛擬化功能能夠傳遞給Guest Hypervisor虛擬主機，並額外新增2顆硬碟，1顆為200GB屆時為安裝CVM也就是Hot Tier的部分，另1顆為500GB屆時為Cold Tier。
圖8 確保傳遞硬體輔助虛擬化功能給Guest Hypervisor虛擬主機。
組態設定後，先別急著開機進入安裝程序，使用系統管理員權限開啟Notepad筆記本，修改Guest Hypervisor虛擬主機的「.vmx」組態設定檔，加上「disk.EnableUUID = "TRUE"」參數值，確保指派給硬碟Serial Number，否則稍後的安裝程序中，可以看到硬碟並沒有顯示Serial Number，如圖9所示，這將會導致後續啟動叢集服務，在啟動Medusa服務時將會卡住並產生錯誤，造成Nutanix叢集無法順利啟動。
圖9 未指派硬碟Serial Number給Guest Hypervisor虛擬主機。
安裝Nutanix AHV虛擬化平台
在安裝Nutanix CE擔任Guest Hypervisor虛擬主機之前，管理人員必須預先準備「2個」IP位址，稍後在安裝程序中將會進行指定，第1個IP位址為底層AHV Hypervisor使用，第2個IP位址則是CVM使用。值得注意的是，由於Nutanix CE預設會使用「192.168.5.0/24」網段，所以須避開使用這個網段。
開機並通過硬體檢測程序後，首先選擇Hypervisor採用預設的AHV，或是採用ESXi虛擬化平台。在安裝硬碟的部分，可以看到系統預設已經自動選取50GB硬碟空間為Hypervisor Boot使用，至於CVM或Data的硬碟空間則可能發生選擇錯誤的情況，倘若系統自動選擇錯誤時，可以先選擇至正確的硬碟空間再按下〔C〕或〔H〕進行切換。同時，也可以看到3個安裝硬碟，皆有指派Serial Number更貼近模擬成實體主機的運作型態。
確認安裝硬碟的組態配置後，接著組態設定AHV和CVM的IP位址，以及網路遮罩和預設閘道。必須注意的是，是否勾選「Create single-node cluster」選項，如圖10所示，取決於管理人員的測試需求。舉例來說，如果勾選此選項，那麼系統建立叢集後將會鎖定，後續即便有其他Nutanix Node節點主機，也無法加入這個Single-Node Cluster內。此外，勾選此選項後，系統將會自動建立RF2 Storage儲存空間，簡單來說，現有儲存空間將會降低一半。
圖10 安裝Nutanix CE Guest Hypervisor並組態設定AHV和CVM IP位址。
組態設定完畢，選擇Next Page後，到Nutanix CE EULA使用者授權條款頁面，使用上下箭頭或〔Page Up〕/〔Page Down〕按鈕，閱讀完EULA使用者授權條款頁面內容，然後勾選「I accept the end user license agreement」項目，選擇Start即可立即進行安裝。
值得注意的是，在EULA使用者授權條款頁面中，必須閱讀完所有的使用者授權條款內容。如果未閱讀完內容，便按下Start立即進行安裝程序的話，那麼系統會在安裝程序至一半時出現錯誤並停止安裝，可以看到系統提示必須重新回到EULA使用者授權條款頁面，閱讀完所有的內容後才能繼續安裝程序，如圖11所示。
圖11 未閱讀完EULA使用者授權條款內容造成安裝程序中斷。
順利安裝一段時間並完成安裝程序後，系統會提示退出安裝映像檔，並鍵入「Y」重新啟動主機以便套用生效，如圖12所示。
圖12 安裝完畢並重新啟動主機。
查詢AHV和CVM運作資訊
重新啟動後，可以從Guest Hypervisor虛擬主機的Console登入，或是透過SSH Client登入AHV Hypervisor系統。在登入系統之前，先了解相關管理者登入帳號和密碼，以便稍後登入進行管理作業：
‧AHV：SSH登入、管理帳號root、管理密碼nutanix/4u。
‧CVM：SSH登入、管理帳號nutanix、管理密碼nutanix/4u。
‧Prism Element：Web登入、管理帳號admin、管理密碼nutanix/4u。
無論透過Console或SSH登入AHV Hypervisor，之後可以執行「cat /etc/nutanix-release」和「cat /etc/centos-release」指令，分別查詢Nutanix CE版本，以及採用CentOS 7.9作業系統版本。同時，執行「virsh list」指令來查詢運作於AHV Hypervisor之上的CVM運作狀態，一開始CVM運作狀態為「paused」，也就是CVM在啟動中尚未開機完成，這時也無法ping到CVM IP位址，經過一段時間後，CVM運作狀態會轉變為「running」，此時就可以ping到CVM IP位址，如圖13所示。
圖13 查詢AHV版本資訊和CVM啟動狀態。
也可以在AHV執行「ip a」或是「ip -c -br a」指令，查看AHV Hypervisor使用的IP位址資訊，可以看到「br0」介面，使用剛才安裝程序中組態設定的「10.10.75.30」位址，而與CVM溝通的「virbr0」介面，則是使用系統預設的「192.168.5.1」位址，如圖14所示，這也是一開始提醒管理人員切勿使用192.168.5.0/24系統預設網段的原因。
圖14 查詢AHV Hypervisor網路組態資訊。
確認CVM啟動成功後，同樣可以透過SSH登入CVM主機，執行「cat /etc/centos-release」指令，查詢到使用的CentOS 7.9作業系統版本，以及執行「ip -c -br a」指令查詢CVM網路組態，可以看到「eth0」介面，使用剛才安裝程序中組態設定的「10.10.75.31」位址，而「eth1」介面則使用系統預設的「192.168.5.2」和「192.168.5.254」位址，如圖15所示。
圖15 查詢CVM作業系統版本和網路組態資訊。
部署並啟動Single-Node Cluster
確認AHV和CVM網路組態設定無誤後，由於是部署單一節點的叢集，所以在「資料可用性」（Data Resiliency）的部分，只能搭配「--redundancy_factor=1」參數，等同於是沒有資料保護的情況，必須部署多節點的叢集才能提升參數值，增加資料可用性。
切換到CVM主機，執行「cluster -s 10.10.75.31 --redundancy_factor=1 create」指令，部署和啟動叢集的動作，需要等待一段時間才能完成。同時，在過程中可以看到相關服務逐步啟動中，而整個叢集的指揮中心名稱為ZeusLeader。一旦所有服務順利啟動後，系統將會出現「INFO MainThread cluster:3104 Success!」訊息，表示單一節點的Nutanix叢集已經部署和啟動完成，如圖16所示。若是後續需要確認叢集狀態時，執行「cluster status」指令即可進行確認。
圖16 部署和啟動單一節點Nutanix叢集。
叢集基礎設定
雖然單點叢集已經部署和啟動完成，但預設情況下系統並未組態設定叢集名稱。執行「ncli cluster info」指令，可以查詢單點叢集的相關資訊，會看到在Cluster Name的欄位值為「Unnamed」，而執行「ncli cluster edit-params new-name=ntnx-cluster」指令，組態設定單點叢集的名稱是「ntnx-cluster」。若執行「ncli cluster set-external-ip-address external-ip-address="10.10.75.35"」指令，可組態設定單點叢集的VIP（Virtual IP）位址，如圖17所示。
圖17 組態設定單點叢集的名稱ntnx-cluster和VIP位址。
預設情況下，叢集採用的DNS名稱解析伺服器，為網際網路上的「8.8.8.8」和「8.8.4.4」。在本文實作環境中，內部使用的DNS名稱解析伺服器為「10.10.75.10」，在組態設定之前，先執行「nc -zv 10.10.75.10 53」指令，確認CVM能夠與即將指定的DNS名稱解析伺服器進行溝通。
確認與DNS名稱解析伺服器溝通無誤後，執行「ncli cluster add-to-name-servers servers="10.10.75.10"」指令，組態設定叢集節點中CVM和AHV的DNS名稱解析伺服器。此時，可以發現預設的「8.8.8.8」和「8.8.4.4」DNS名稱解析伺服器仍存在，因此執行「ncli cluster remove-from-name-servers servers="8.8.8.8,8.8.4.4"」指令，移除預設的DNS名稱解析伺服器，最後執行「ncli cluster get-name-servers」指令，再次確認目前叢集的DNS名稱解析伺服器組態設定，如圖18所示。
圖18 組態設定叢集節點中CVM和AHV的DNS名稱解析伺服器。
預設情況下，單點叢集的時區組態設定值為「UTC格林威治標準時間」，執行「ncli cluster info | grep Timezone」指令，可以查詢目前單點叢集的時區組態設定。接著，執行「timedatectl list-timezones | grep Asia/Taipei」指令，先確認系統是否支援「UTC+8」的「Asia/Taipei」台北時區。
確認系統支援台北時區後，執行「ncli cluster set-timezone timezone= "Asia/Taipei"」指令，組態設定單點叢集為台北時區，接著系統會詢問是否要套用新的時區設定，鍵入「y」確認進行變更，系統將會提示必須重新啟動CVM，或是重新啟動叢集所有服務才能完全套用生效。隨後，再次執行「ncli cluster info | grep Timezone」指令，確認時區設定是否套用生效，如圖19所示。詳細資訊請參考Nutanix KB1050知識庫文章。
圖19 組態設定單點叢集的時區組態設定為台北時區（UTC+8）。
叢集採用的NTP時間校對伺服器，預設情況下為網際網路上的「1.pool.ntp.org」和「0.pool.ntp.org」。在本文實作環境中，內部使用的NTP時間校對伺服器為「10.10.75.10」，在組態設定之前，先執行「nc -zv 10.10.75.10 -u 123」指令，確認CVM能夠與即將指定的NTP時間校對伺服器進行溝通。必須注意的是，nc指令預設情況下會採用TCP通訊協定，但NTP時間校對伺服器必須採用UDP通訊協定進行溝通，所以必須加上「-u」參數。
確認與NTP時間校對伺服器溝通無誤後，執行「ncli cluster add-to-ntp-servers servers="10.10.75.10"」指令，組態設定叢集節點中CVM和AHV的NTP時間校對伺服器。此時，可以發現預設的「1.pool.ntp.org」和「0.pool.ntp.org」NTP時間校對伺服器仍然存在，所以執行「ncli cluster remove-from-ntp-servers servers="1.pool.ntp.org,0.pool.ntp.org"」指令，移除預設的NTP時間校對伺服器。倘若希望立即執行時間校對作業，則執行「/usr/sbin/ntpdate -t 10 -q 10.10.75.10」指令，立即尋找組態設定的NTP時間校對伺服器進行時間校對，如圖20所示。詳細資訊請參考Nutanix KB4519知識庫文章。
圖20 組態設定單點叢集的NTP時間校對伺服器。
預設情況下，CVM的主機名稱由系統產生，命名規則為NTNX---CVM，例如本文實作環境主機名稱為NTNX-bd3ffec5-A-CVM。必須注意的是，即便管理人員要變通CVM主機名稱，也必須遵照系統命名規則，開頭為「NTNX-」結尾為「-CVM」，可執行「sudo /usr/local/nutanix/cluster/bin/change_cvm_hostname NTNX-Node01-CVM」指令，如圖21所示，將CVM主機名稱改為「NTNX-Node01-CVM」。另一點值得注意的是，變更CVM主機名稱後，系統會提醒必須重新啟動才能套用生效，按下〔Y〕鍵後便會重新啟動。詳細資訊請參考Nutanix KB3517知識庫文章。
圖21 執行指令變更CVM主機名稱。
登入Prism Element管理介面
預設情況下，在單點叢集架構中，透過CVM IP位址即可連線Prism Element管理介面。當CVM主機重新啟動完成後，在登入Prism Element管理介面之前，執行「netstat -tunpl | grep 9440」指令，確認CVM主機Prism Element管理介面（Port 9440）已經運作中。
開啟瀏覽器鍵入網址「https://ntnx-cluster.lab.weithenn.org:9440」，然而使用Chrome或Edge嘗試登入Prism Element管理介面時，卻顯示「NET::ERR_CERT_INVALID」的警告訊息，並且按下〔Advanced〕按鈕，展開內容後也沒有略過的按鈕可以繼續，如圖22所示。
圖22 預設自簽憑證錯誤無法顯示Prism Element登入介面。
此時，只要在錯誤網頁中空白處直接鍵入「thisisunsafe」（舊稱為badidea），即可順利載入這個不安全的網頁，並看到Prism Element登入畫面。預設登入管理帳號為「admin」，密碼是「nutanix/4u」。登入後，系統會提示立即變更管理密碼，變更後會再度回到登入介面以新的管理密碼登入，如圖23所示。
圖23 使用新的管理密碼登入Prism Element管理介面。
第一次登入Prism Element管理介面時，系統將會彈出NEXT Credentials視窗，原因在於採用Nutanix CE社群版本時，必須使用在My Nutanix中的帳號登入進行註冊作業，如圖24所示。要注意的是，在My Nutanix帳號中，必須針對Community Edition區塊，點選〔Activate〕按鈕進行啟用後，才能順利執行註冊作業。如果確認無誤卻仍無法完成註冊作業的話，有可能是單節點叢集所處網路環境，註冊作業的網路流量被防火牆所阻擋，確保防火牆上允許單節點叢集中，流出的TCP通訊協定Port 80或8443放行通過。
圖24 採用Nutanix CE社群版本時必須使用My Nutanix的帳號登入進行註冊作業。
此時，系統會先檢查My Nutanix的帳號，其中Community Edition是否Activate，接著啟動Pulse遙測服務，以便定期擷取Nutanix叢集診斷資訊並進行回傳作業。最後，檢查Acropolis版本是否為最新版本，確認無誤後，即可看到Prism Element儀表板管理介面，如圖25所示。
圖25 順利登入Prism Element儀表板管理介面。
結語
透過本文的深入剖析和實戰演練後，相信管理人員即便在沒有專屬Nutanix硬體伺服器的情況下，也可以透過巢狀式虛擬化技術，輕鬆建構出Nutanix單節點叢集的運作環境進行測試和研究，後續也將和大家分享部署Nutanix多節點叢集。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞