部署Nutanix叢集時，應該先完成基礎架構的組態設定，讓整體運作架構強健，才開始運作VM虛擬主機或容器等工作負載，切勿因為專案時程緊迫而忽略這些基礎設定，讓日後正式營運的專案架構埋下不穩定的隱憂，為此本文將示範Nutanix叢集的基礎設定。
日前，Nutanix官方發布最新7.5版本，除了原有的特色功能增強外，也新增許多特色功能。舉例來說，過往企業或組織在管理VM虛擬主機時，採用的是Nutanix Prism管理平台，將運算、儲存、網路、自動化、災難復原等等整合至單一介面當中。在容器工作負載管理方面，則是透過Nutanix Kubernetes Platform（NKP）管理平台，簡化Kubernetes叢集的部署、管理以及擴充等等。
新推出的Nutanix Central管理平台，將提供統一且可視化的集中管理機制，無論工作負載是部署在地端資料中心，或是AWS、Azure、GCP Nutanix NC2等等公有雲環境，都可以統一進行管理，如圖1所示。
圖1 Nutanix Central運作架構示意圖。 （圖片來源：Unified Cloud Operating Model: Centralized Management for the Dual World of VMs and Containers | Nutanix Blog）
當企業組織透過Nutanix Foundation VM，部署Nutanix Cluster運作環境和Nutanix叢集節點主機後，雖然Nutanix叢集運作架構已經成形並且正常運作中。然而，此時的Nutanix叢集仍有許多基礎架構的組態設定並未完整。舉例來說，管理人員可以使用預設的admin管理帳號登入Nutanix Prism Element（PE）管理介面進行管理作業，但是想要採用企業或組織的SSO帳號登入時，便需要先進行組態設定，才能順利登入Nutanix PE管理介面，進行Nutanix叢集的管理和維護作業。
在以下的實作演練中，便會逐步示範，在Nutanix叢集部署完畢後，有哪些重要的Nutanix叢集基礎設定必須先進行組態設定和驗證，也就是管理人員應該先完成Day-1 Operations階段後，才接著進行Day-2 Operations階段，例如Nutanix叢集資源使用率和工作負載的管理作業。
DNS名稱解析機制
無論哪種基礎架構，DNS名稱解析機制都是最重要且最基礎的一環。在Nutanix Foundation部署流程中，雖然已經可以指定DNS名稱解析伺服器，但管理人員仍然可以視後續維護管理需求，隨時調整Nutanix叢集指向使用的DNS名稱解析伺服器。
先登入Nutanix PE管理介面，依序點選「Settings > Network > Name Servers」，並在Server IP欄位中填入指定使用的DNS名稱解析伺服器，再按下〔+Add〕鈕即可新增，然後下方IP Address區塊內便會顯示新增的DNS名稱解析伺服器清單，如圖2所示。
圖2 組態設定Nutanix叢集DNS名稱解析伺服器。
值得注意的是，無論是新增或變更Nutanix叢集DNS名稱解析伺服器，系統的組態設定變更套用時間可能需要5分鐘左右，在這段變更套用期間，Nutanix叢集DNS名稱解析機制可能無法正常運作。此外，最多可以為Nutanix叢集組態設定「3台」DNS名稱解析伺服器。
同時，在為Nutanix叢集組態設定DNS名稱解析伺服器後，雖然Nutanix叢集每隔12小時就會自動執行系統健康狀態檢查作業，但也可以登入Nutanix叢集內其中一台CVM主機，並透過NCC Health Check機制中的「dns_server_check」功能，檢查Nutanix叢集DNS名稱解析伺服器的健康狀態。
管理人員只要透過SSH機制登入CVM主機後，執行「ncc health_checks system_checks dns_server_check」指令，即可立即觸發執行Nutanix叢集DNS名稱解析伺服器、健康狀態檢查作業，確保DNS名稱解析伺服器順利套用，並且DNS名稱解析機制正常運作中，詳細資訊請參考Nutanix KB-3005知識庫文件內容。
NTP時間校對機制
與DNS名稱解析機制同等重要的，第二項基礎設定便是指定Nutanix叢集所採用的NTP時間校對伺服器。在Nutanix叢集規模較小，叢集節點主機數量少的情況下，未組態設定NTP時間校對機制時，可能受影響的感受不大。然而，在Nutanix叢集規模中大型並且叢集節點主機數量多的情況時，是否組態設定NTP時間校對機制，便會顯得影響重大。
舉例來說，如果Nutanix叢集規模中叢集節點主機數量有32台時，若未組態設定NTP時間校對機制，雖然在運作上可能不致產生影響，然而當需要追蹤資源使用情況時，或是系統發生錯誤需要故障排除時，由於並未設定NTP時間校對機制，將造成叢集節點主機之間的系統時間不一致，導致系統產生的日誌檔案內容時間點不一致，造成時間追蹤和故障排除的麻煩及困擾。
因此，NTP時間校對機制看似微不足道，但在Nutanix叢集後續的維護管理作業上卻是具備舉足輕重的地位，管理人員應重視才對。在登入Nutanix PE管理介面後，依序點選「Settings > Network > NTP Servers」，接著在NTP Server欄位中填入指定使用的NTP時間校對伺服器，格式可以使用Hostname、FQDN、IP位址，再按下〔+Add〕鈕即可新增，然後下方Hostname or IP Address區塊內便會顯示新增的NTP時間校對伺服器清單，如圖3所示。
圖3 組態設定Nutanix叢集NTP時間校對伺服器。
同樣地，為Nutanix叢集組態設定NTP時間校對伺服器後，系統會每隔12小時自動執行系統健康狀態檢查作業，但管理人員可以登入Nutanix叢集其中一台CVM主機，透過NCC Health Check機制中的「check_ntp」功能，檢查Nutanix叢集NTP時間校對伺服器的健康狀態。
只要透過SSH機制登入CVM主機，執行「ncc health_checks system_checks check_ntp」指令，即可立即觸發執行Nutanix叢集NTP時間校對伺服器，以及健康狀態檢查作業，確保NTP時間校對伺服器順利套用，並且NTP時間校對機制正常運作中，詳細資訊請參考Nutanix KB-4519知識庫文件內容。
LDAP身分認證機制
預設情況下，當Nutanix叢集剛部署完成後，管理人員僅能使用預設的管理帳號「admin」登入，必須組態設定LDAP身分認證機制後，才能指派企業組織的使用者帳號具備哪些管理權限，在Nutanix叢集環境中，支援常見的微軟Active Directory（AD）和OpenLDAP身分認證機制。
登入Nutanix PE管理介面後，依序點選「Settings > Users and Roles > Authentication > Directory List」，然後點選下方的〔+New Directory〕鈕，準備新增LDAP身分認證機制，並填入下列欄位資訊，如圖4所示：
圖4 組態設定Nutanix叢集LDAP身分認證和目錄服務資訊。
‧Directory Type：選擇使用的LDAP身分認證類型，Nutanix支援採用微軟Active Directory（AD）以及OpenLDAP身分認證機制。
‧Name：鍵入目錄名稱，屆時管理人員可以用來識別此目錄服務的名稱，例如WS2025 AD。
‧Domain：鍵入網域名稱，並提供目錄服務的網域名稱，例如lab.weithenn.org。
‧Directory URL：鍵入目錄服務的網址，Nutanix支援採用LDAP（Port 389）、LDAPS（Port 636）、LDAP-GC（Port 3268）、LDAPS-GC（Port 3269），例如ldaps://dc.lab.weithenn.org:636。
‧Search Type：搜尋類型，選擇系統進行身分驗證目錄搜尋方式，除非有特殊情況，否則保持預設值Non Recursive即可。採用非預設值的Recursive目錄搜尋方式，可能會導致登入效能異常緩慢。
‧Service Account：鍵入服務帳號和密碼，這個服務帳號將用於登入剛才指定的目錄服務，通常這個服務帳戶僅僅為了執行特定服務而建立，管理人員應該限制這個服務帳戶的權限，值得注意的是，服務帳號必須採用UPN格式，例如ad-query@lab.weithenn.org。
以上LDAP身分驗證和目錄服務資訊確認無誤後，按下〔Save〕鈕即可儲存，系統便會在Directory List區塊內顯示剛才新增的目錄服務資訊。可以按下〔Test〕鈕，在Test Connection視窗中，於Directory Name欄位選擇目錄服務。在User和Password欄位中鍵入服務帳號和密碼後，按下〔Test〕鈕進行LDAP身分驗證和目錄服務測試程序，驗證成功的話，系統將會出現「Authentication test successful.」資訊。
值得注意的是，預設情況下，組態設定的目錄服務中，通過身分驗證的使用者帳號並不會被系統授予任何權限，所以管理人員必須接著為使用者帳號指定角色並授予權限，才能登入及管理Nutanix叢集環境。
在Nutanix PE管理介面中，依序點選「Settings > Users and Roles > Role Mapping > +New Mapping」，於Create Role Mapping視窗中選擇和鍵入下列資訊，以便為使用者帳號指定角色並授予權限，如圖5所示：
圖5 選擇目錄服務並指派使用者帳號具備的Nutanix叢集角色。
‧Directory or Provider：選擇目錄服務或LDAP身分認證提供者，倘若在下拉式選單中沒有看到欲連接的目錄服務，則回到LDAP身分認證步驟，確認組態設定內容是否正確。
‧Type：選擇LDAP採用類型，支援使用Group、User、OU等三種類型。
‧Role：選擇指派的角色，支援Viewer、Cluster Admin、User Admin、Backup Admin等角色，其中Cluster Admin雖然可以查看叢集資訊，並且執行各種叢集管理任務，但是無法建立或修改使用者帳號，必須採用User Admin角色才能管理使用者帳號。
‧Values：鍵入使用者帳號或群組名稱，不要在此欄位中鍵入網域名稱，例如使用者的UPN帳號為weithenn@lab.weithenn.org，那麼此欄位鍵入weithenn使用者名稱即可。如果有多筆使用者帳號或群組需要鍵入時，用逗號隔開處理。
以上Nutanix叢集角色和目錄服務資訊確認無誤後，按下〔Save〕鈕即可儲存，系統便會在Role Mapping Management區塊中顯示剛才新增的叢集角色資訊，並顯示「Successfully saved Role Mappings」字樣，提醒管理人員叢集角色套用生效。
倘若組態設定LDAP身分驗證和目錄服務後發生錯誤需要故障排除，除了登入CVM主機，執行「ncc health_checks system_checks ldap_config_check」指令，檢查LDAP身分驗證和目錄服務健康情況外，也可以參考Nutanix KB-3363知識庫文件內容進行故障排除作業。
叢集虛擬網路
在Nutanix叢集虛擬網路環境中，包含Subnets虛擬網路環境、Internal Interfaces叢集網路介面、Virtual Switch虛擬網路交換器等組態設定項目，以便因應企業或組織多種網路環境的需求。
其中最簡單的應用場景，便是透過預設的vs0虛擬網路交換器，搭配建立Subnets虛擬網路環境和VLAN ID，來達到Layer 2層級的網路隔離效果。
在登入Nutanix PE管理介面後，依序點選「Settings > Network > Network Configuration > Subnets」，並點選右方的〔+Create Subnet〕鈕，準備新增Subnets虛擬網路環境，並填入下列欄位資訊，如圖6所示：
圖6 管理人員依據需求建立Subnet虛擬網路。
‧Subnet Name：鍵入虛擬網路名稱，以便後續辨識管理使用。
‧Virtual Switch：選擇採用的虛擬網路交換器，預設虛擬網路交換器名稱為vs0。
‧VLAN ID：鍵入VLAN ID識別號碼，例如168。
‧Enable IP address management：是否啟用IP位址管理機制，如果區域網路內已經有DHCP伺服器，那麼便不需要啟動IP位址管理機制避免衝突。
告警郵件
透過為Nutanix叢集組態設定SMTP郵件伺服器，能夠讓Nutanix叢集定期發送系統資訊給予管理人員。在Nutanix PE管理介面中，依序點選「Settings > Alerts and Notifications > SMTP Server」，準備新增SMTP郵件伺服器資訊，並填入下列欄位資訊：
‧Hostname Or IP Address：鍵入SMTP郵件伺服器的網域名稱或IP位址，例如relay.lab.weithenn.org。
‧Port：鍵入SMTP郵件伺服器的通訊埠號，支援Port 25（未加密）、465（SSL）、587（TLS）。
‧Security Mode：選擇採用哪種安全模式，支援NONE、STARTTLS、SSL。當選擇採用STARTTLS或SSL安全模式時，需要鍵入使用者帳號和密碼進行身分驗證。
‧From Email Address：鍵入電子郵件地址，屆時郵件中此欄位將顯示為寄件人地址。
填寫完畢確認無誤後，按下〔Save〕鈕即可。然後按下〔Test〕鈕，再填入收件人地址和郵件的主旨及內容，並按下〔Send test email〕鈕，便能立即從Nutanix叢集中寄出測試郵件給指定的收件人，並且系統也將顯示測試郵件送信結果，如圖7所示。
圖7 組態設定Nutanix叢集SMTP郵件伺服器資訊。
接著，點選左側Alert Email Configuration項目，切換到告警郵件組態設定。在Settings頁面中，預設情況下，系統每天會檢查系統情況，一旦發生告警事件，便會在指定時間，例如早上6點，寄送至下方Email Recipients欄位內指定的收件人地址，例如Nutanix_Admins@lab.weithenn.org，然而若沒有任何告警事件，則不予寄送。
倘若管理人員希望無論如何都能夠每天收到系統的檢查郵件時，只需要取消勾選「Skip the daily digest email if there are no alerts generated on a given day」項目即可，如圖8所示。
圖8 管理人員依據需求組態設定告警郵件行為和寄送時間。
儲存資源池
在Nutanix HCI超融合架構中，儲存資源池（Storage Pool）是一組定義的實體磁碟，在建構Nutanix叢集時，系統便會自動將叢集節點主機的實體磁碟融合並建立儲存資源池。
然而，預設的儲存資源池名稱不易辨識，例如預設名稱為「default-storage-pool-<14個字元數字>」，當企業組織的地端資料中心內只有一組Nutanix叢集時，此預設名稱雖然不易辨識，但也還算容易找到，倘若有多組Nutanix叢集，便會造成辨識上的困難，後續若採用Prism Central（PC）主控台納管，也會因為辨識困難導致管理不易。
在Nutanix PE管理介面中，依序點選「Storage > Table > Storage Pool」，並點選欲修改名稱的儲存資源池後，按下右側Update。接著，在彈出的Update Storage Pool視窗中鍵入新的儲存資源池名稱，例如taipei-cluster01-sp，並按下〔Save〕鈕即可套用生效，如圖9所示。
圖9 變更預設的儲存資源池名稱以利識別。
儲存容器
在Nutanix HCI超融合架構中，儲存容器（Storage Container）是底層儲存資源池的可用儲存空間子集。簡單來說，當系統將所有叢集節點的儲存空間匯集融合成70TB儲存資源池後，再利用儲存容器機制，將儲存空間切割成顆粒較細的功能和空間，例如切割出5TB儲存空間，並且啟用壓縮和重複資料刪除的進階儲存功能。
在Nutanix PE管理介面中，依序點選「Storage > Table > Storage Container」後，會看到系統預設建立好的3個儲存容器，分別是系統用途的SelfServiceContainer和NutanixManagementShare，以及預設的「default-container-<14個字元數字>」。
值得注意的是，預設的default-container儲存容器，與預設的儲存資源池不同，當嘗試變更名稱時，會發現呈現灰色無法變更名稱，管理人員可以直接使用，或是刪除它再建立新的儲存容器使用。
雖然在刪除預設的default-container儲存容器時，系統會發出警告並說明一旦刪除後便無法回復，然而目前系統都在初始設定階段，在預設的default-container儲存容器中並沒有任何資料存在，所以管理人員可以放心刪除，並且底層都是使用同一個儲存資源池，因此刪除且過一段時間之後，系統會自動將預設的default-container儲存容器儲存空間回收，管理人員無須擔心。
若擔心叢集不會自動回收儲存空間，只要先透過SSH機制登入CVM主機，再執行「ncc health_checks stargate_checks container_on_removed_storage_pool」指令，即可立即觸發執行Nutanix叢集儲存資源健康狀態檢查作業，確保儲存資源池中標記為移除的儲存容器，是否刪除並回收儲存空間，詳細資訊請參考Nutanix KB-9491知識庫文件內容。
要建立新的儲存容器時，只要按下右上方的+Storage Container，接著在彈出的Create Storage Container視窗中，依據需求選擇或填入下列欄位資訊，如圖10所示：
圖10 新增名稱為windows-server-sc的儲存容器。
‧Name：鍵入儲存容器名稱，例如windows-server-sc，表示此儲存容器屆時將用於存放Windows Server VM虛擬主機，儲存容器名稱最大長度為75個字元。
‧Storage Pool：選擇採用的儲存資源池，準備將此新增的儲存容器建立於指定的儲存資源池內。
‧Cluster Fault Tolerance：叢集的容錯能力，例如目前叢集規模為4台節點主機，所以Replication Factor（RF）能力為2，容錯能力為允許1顆硬碟或1台節點主機發生故障損壞。
‧Reserved Capacity（Logical）：強制系統預留給儲存容器的儲存空間。
‧Advertised Capacity（Logical）：強制系統儲存容器最大能夠使用的儲存空間。
‧Compression：設定此儲存容器是否啟用壓縮功能，以便壓縮資料大小達到節省儲存空間的目的，Nutanix建議設定壓縮延遲時間為60分鐘。
‧Deduplication：設定此儲存容器是否啟用重複資料刪除功能，Nutanix建議用於Full Clone和Persistent Desktops環境，值得注意的是，當RF=1時將無法啟用重複資料刪除功能。
‧Erasure Coding：設定此儲存容器是否啟用Erasure Coding功能，值得注意的是，當RF=1時將無法啟用Erasure Coding功能。
‧Filesystem Allowlists：設定能夠存取此儲存容器的IP位址白名單，例如10.10.75.0/255.255.255.0，表示只有來自這段網路遮罩的主機才能存取，其他IP來源則一律禁止存取。
啟用HA高可用性機制
預設情況下，Nutanix叢集並未啟用HA高可用性機制，管理人員必須登入Nutanix PE管理介面進行啟用。
順利登入Nutanix PE管理介面後，依序點選「Settings > Data Resiliency > Manage VM High Availability」，並勾選「Enable HA Reservation」項目，同時系統會顯示啟用HA高可用性功能後，將為叢集預留1,006.9GB記憶體空間，如圖11所示，以便因應單一節點主機發生災難事件時能夠快速因應，叢集預留的記憶體空間將會隨著資源使用和工作負載情況而有所不同。
圖11 為Nutanix叢集啟用HA高可用性機制。
啟用預留重建空間
預設情況下，Nutanix叢集並沒有啟用預留重建空間機制，雖然可用儲存空間會有所增長，但是未來在面對災難事件時，將因為沒有預留重建空間，而讓Nutanix叢集自我修復速度緩慢，甚至無法快速因應重大災難事件。
登入Nutanix PE管理介面，依序點選「Settings > Data Resiliency > Rebuild Capacity Reservation」，勾選「Reserve Rebuild Capacity」項目後，如圖12所示，按下〔Save〕鈕儲存設定，系統經過一段時間計算後，便會為Nutanix叢集啟用預留重建空間機制。
圖12 為Nutanix叢集啟用預留重建空間機制。
到Nutanix PE管理介面中，依序點選「Storage > Overview」，並在Storage Summary區塊中按下View Details，即可看到儲存資源的詳細資訊，包含Nutanix叢集已經啟用預留重建空間機制，其中Rebuild Capacity欄位便會顯示系統經過計算後預留的重建空間，本文實作環境為「30.19TB」，如圖13所示，預留重建空間包含Self-Healing、Rebuilding Failed Nodes、Failed Blocks、Failed Racks等儲存空間。
圖13 查看Nutanix叢集預留重建空間詳細資訊。
此外，預設情況下，儲存空間告警門檻值為「75%」，所以本文實作環境中，Warning Threshold顯示為56.12TB，倘若覺得系統預設的儲存空間告警門檻值需要調整，可以在Storage Summary區塊中按下右上方的齒輪圖示，就會進入告警門檻值設定視窗。再點選Set manually選項，即可在下方Threshold for warning limit欄位內，鍵入儲存空間告警門檻值，如圖14所示。
圖14 調整儲存空間告警門檻值。
結語
雖然Nutanix叢集部署完畢並正常運作，然而應該先將基礎架構的組態設定完成，讓Nutanix叢集整體運作架構強健，才開始運作VM虛擬主機或容器等工作負載，切勿因為專案時程緊迫而忽略這些基礎設定，為日後正式營運的專案架構留下不穩定的隱憂。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞