升級vCenter管理平台　無痛變更命名及網路組態

在2019年8月13日時，VMware官方正式發佈全新vSphere 6.7 Update 3版本，同時VMware SDDC軟體定義資料中心內，各項解決方案版本也同步推升至Update 3版本，例如vSphere ESXi 6.7 Update 3虛擬化平台、vCenter Server 6.7 Update 3管理平台、vSAN 6.7 Update 3超融合解決方案。

值得注意的是，企業組織的資料中心倘若仍採用舊有的vSphere 6.0版本，例如vSphere ESXi 6.0、vCenter Server 6.0、vCenter Update Manager 6.0、vSphere Replication 6.0/6.1等等，以及對應到vSAN為6.0、6.1、6.2版本，都將於「2020年3月12日」正式進入EOGS結束標準支援階段，如表1所示。

因此，企業應儘快準備版本升級程序至vSphere 6.5或6.7版本，倘若在2020年3月12日進入EOGS結束標準支援階段時仍無法升級版本的話，則應購買「延伸支援」（Extended Support）服務，最多可以延長支援服務至2022年3月12日。

本文將深入剖析最新vSphere 6.7 Update 3和vSAN 6.7 Update 3版本亮眼新功能，以及實作演練vCenter Server 6.7 Update 3新增特色功能，變更vCenter Server FQDN和IP位址網路組態設定的部分。

vSphere 6.7 Update 3新增特色功能

接下來，介紹幾項vSphere 6.7 Update 3所新增的功能。

VM虛擬主機支援多NVIDIA vGPU

從最新的vSphere 6.7 Update 3版本開始，每台VM虛擬主機新增支援多個NVIDIA vGPU（GRID virtual GPU）特色功能，如圖1所示，以便因應VM虛擬主機處理圖形和運算密集的工作負載。舉例來說，採用這種類型的VM虛擬主機，將能夠最大化加快機器學習的運算速度。

值得注意的是，如果採用vGPU技術的VM虛擬主機有vMotion遷移需求時，管理人員除了要確認vCenter Server和ESXi均採用最新的vSphere 6.7 Update 3版本之外，還必須在進階設定中加上「vgpu.hotmigrate.enabled = true」組態設定值，才能順利地針對採用vGPU技術的VM虛擬主機，進行vMotion線上遷移至別台ESXi虛擬化平台的動作。

支援AMD EPYC Gen2處理器

從最新的vSphere 6.7 Update 3版本開始，支援x86硬體伺服器採用新式AMD EPYC Gen2處理器，並且在後續的vSphere ESXi虛擬化平台版本中，針對AMD EPYC Gen2處理器的新式安全性，例如安全記憶體加密（Secure Memory Encryption，SME）、安全加密虛擬化（Secure Encrypted Virtualization，SEV），將有更全面的整合和支援。

然而，目前企業和組織的資料中心內主流的x86硬體伺服器，大多採用Intel Xeon處理器，那麼管理人員該如何將原有運作於Intel Xeon處理器的VM虛擬主機，遷移至採用新式AMD EPYC Gen2處理器的VMware Cluster運作環境中呢？

或許，有IT管理人員會說，可以嘗試啟用EVC（Enhanced vMotion Compatibility）機制為VM虛擬主機進行遷移，但事實上為VMware Cluster啟用EVC特色功能後，僅能針對「同一家廠商」，也就是僅能都是Intel或者都是AMD處理器的運作環境，如表2所示，並不支援Intel和AMD處理器混合運作環境。

事實上，可以透過「冷遷移」（Cold Migration）的方式，如圖2所示，將原本運作於Intel Xeon處理器的VM虛擬主機，遷移至新式AMD EPYC Gen2處理器運作環境中繼續運作，並且透過冷遷移的特性，VM虛擬主機無須共享儲存資源，也可以將Datastore儲存資源進行遷移。

下列便是採用冷遷移的執行步驟，分別加以說明：

1. 在開始進行冷遷移執行步驟之前，先將來源端伺服器（Intel-Based）上欲進行遷移的VM虛擬主機「關機」（Powered Off）。

2. 在準備執行冷遷移前，若VM虛擬主機採用64位元的作業系統版本，vCenter Server將透過CPU相容性機制，檢查目標伺服器是否支援64位元作業系統版本。

3. 當遷移的VM虛擬主機包含儲存資源時，那麼vCenter Server會把該台VM虛擬主機的組態設定文件、NVRAM組態設定檔（BIOS設定）、vDisk虛擬磁碟等等，進行儲存資源遷移的動作。

4. vCenter Server在目的端伺服器（AMD EPYC）中，註冊VM虛擬主機並執行「開機」（Powered On）的動作。

5. 當冷遷移步驟執行完畢，vCenter Server會把來源端伺服器內的舊版本VM虛擬主機，執行刪除的動作。

Skyline新式健康檢查機制

在過去的版本中，管理人員透過vSphere Health和vSAN Helath健康檢查機制，除了能夠快速了解叢集的健康情況之外，在叢集發生問題時也能夠透過健康檢查機制快速排除故障。

在後續的版本中，原有的vSphere Health和vSAN Helath健康檢查機制，將會併入新式的Skyline健康檢查機制中，並且推出更進階的Skyline Advisor健康檢查機制，以便支援更多的VMware產品，例如NSX-V網路虛擬化、Horizon虛擬桌面等等運作環境。如表3所示，簡要說明原有的vSphere Health和vSAN Helath，以及新式的Skyline健康檢查機制在功能性方面有何不同。

可惜的是，由於新式Skyline Health健康檢查機制仍處於技術預覽階段，如圖3所示，所以在目前最新的vSphere 6.7 Update 3和vSAN 6.7 Update 3版本中仍未整合，VMware官方預計在下一個版本中才會提供整合。

vSAN 6.7 Update 3新增特色功能

在過去的vSAN超融合環境中，針對VM虛擬主機的工作負載和儲存資源部分，已經透過「儲存原則」（Storage Policy）的方式，輕鬆地幫助IT管理人員進行高可用和靈活管理。

適用雲端原生環境的儲存資源

針對新興的「容器」（Container）工作負載，在新版vSAN 6.7 Update 3運作環境中，已經透過vSphere CSI（Container Storage Interface）驅動程式與Kubernetes容器管理平台整合，如圖4所示，讓管理人員在管理容器的儲存資源的時候，就像過去管理VM虛擬主機的儲存資源一樣方便。

因此，即使在vSAN超融合基礎架構環境中，同時運作VM虛擬主機和容器的混合型工作負載，在管理儲存資源方面，針對容器使用的「持續性磁碟區」（Persistent Volumes），管理人員仍然可以透過熟悉的vSphere HTML5 Client管理介面，為容器提供持續性的可用儲存資源，不會因為容器短暫的生命週期，而影響到重要資料的儲存，如圖5所示。

增強和簡化儲存資源使用資訊

在過去的vSAN超融合運作環境中，針對儲存資源使用率資訊的部分都是以VM虛擬主機為主軸，然而，企業和組織新興的應用方式已經改變，除了VM虛擬主機外，還會搭配容器等工作負載。所以，vSAN針對儲存資源使用率的呈現方式進行增強，如圖6所示，例如透過不同顏色的方式讓管理人員更容易識別，並針對不同工作負載和用途的使用量進行呈現，以便管理人員更容易掌握儲存資源的使用情況和剩餘空間。

舉例來說，倘若管理人員忽略剩餘儲存空間，造成「磁碟群組」（Disk Group）儲存空間占滿，vSAN將會暫停重新同步作業，以避免VM虛擬主機發生I/O中斷的情況。因此，管理人員應隨時注意儲存空間使用情況，並視需求考量是否增加vSAN節點主機至vSAN叢集。

更智慧的I/O管理機制有效提升效能

在新版vSAN 6.7 Update 3版本中，針對資料I/O管理機制採用更智慧的運作方式，能夠在同樣的vSAN超融合基礎架構內提供更佳的儲存效能。舉例來說，當vSAN從快取層級的寫入緩衝區中，將資料寫入至容量層級的時候，提供能夠預測的應用程式效能，除了降低資料寫入的延遲時間外，還增加資料吞吐量，以便減少重建工作任務的時間，進而為VM虛擬主機和容器等工作負載提供更佳的儲存效能，如圖7所示。

vSAN Stretched Cluster支援WSFC共享磁碟

過去的vSAN版本已經透過iSCSI運作機制，提供VM虛擬主機快速建立「Windows容錯移轉叢集運作」（Windows Server Failover Clustering，WSFC）環境，到了新版vSAN 6.7 Update 3版本，更支援SCSI-3 PR（Persistent Reservations）機制，達到應用程式無須中斷，即可動態調整iSCSI LUN儲存空間大小的增強功能。

除了更全面支援WSFC容錯移轉叢集運作環境外，對於其他無共享儲存資源的叢集架構，例如Exchange CCR（Cluster Continuous Replication）、DAG（Database Availability Group）也都已經支援。

此外，在新版vSAN 6.7 Update 3版本中，vSAN Stretched Clusters延伸叢集運作架構，也已經全面支援WSFC容錯移轉叢集運作環境，如圖8所示，因此企業組織可以透過原有的vSphere HA和DRS機制，達成Host Level和VM Level的高可用性服務，搭配vSAN Stretched Clusters延伸叢集和WSFC容錯移轉叢集機制，達成Application Level的高可用性服務，讓企業正式營運服務的SLA提升至另一個層級。

行動監控vSAN叢集運作資訊

在過去的vSAN版本中，當管理人員需要查看vSAN超融合基礎架構運作資訊時，必須透過桌上型電腦或筆記型電腦連結至vSphere HTML5 Client管理介面，才能夠查看vSAN運作資源。

然而，在行動商務的風潮中，如此傳統的管理方式已經漸漸顯得不合時宜，所以VMware官方推出「vSAN Live Mobile Client App」應用程式，讓管理人員透過智慧型手機就能夠隨時隨地輕鬆且快速地查看vSAN運作環境資訊，包括vSAN叢集、健康情況、運作效能、儲存空間使用率等等。

目前的vSAN Live Mobile Client App為1.0版本，管理人員的智慧型手機必須先確保能夠以VPN的方式存取vSAN叢集，並且在安裝好App應用程式連接至vCenter Server後，將下載和安裝連線憑證至智慧型手機內即可。此外，VMware官方將會在後續App版本，提供無須使用VPN的安全性連接方式。

當管理人員為智慧型手機安裝vSAN行動App應用程式後，只要VPN安全連線建立完成，並通過vCenter Server身分驗證程序後，即可順利連接至vSAN叢集查看相關運作資訊，包含Info、Health、Performance、Capacity等四大項目，如圖9所示，讓管理人員方便透過行動裝置隨時查看vSAN叢集運作資訊。

實作演練vCenter Server變更PNID

近來管理人員特別需要的功能是，vCenter Server要能夠「變更」FQDN（Full Qualified Domain Name）和IP位址，這並不是指vCenter Server的VM虛擬主機名稱，而是vCenter Server當中的「PNID（Primary Network ID）」名稱，最新的vCenter Server 6.7 Update 3版本已經正式支援。

為何管理人員會需要重新命名vCenter Server的FQDN呢？主要原因在於，每當升級vCenter Server版本，或者是從Windows vCenter Server遷移至Linux vCenter Server Appliance時，由於舊版的vCenter Server並不支援重新命名vCenter Server的FQDN，所以只能沿用舊有的FQDN或主機名稱，因此便會出現vCenter Server命名標準不符合公司政策的情況，同時也會造成名稱識別度上的困難。

變更vCenter Server FQDN的前置作業

在開始執行變更vCenter Server FQDN的動作之前，必須先確認運作環境是否已經符合要求。

首先，必須採用最新的vCenter Server 6.7 Update 3版本，才能夠支援變更FQDN也就是PNID的動作，同時必須擁有SSO網域管理者帳號和密碼，例如Administrator@vsphere.local，並且應考慮下列事項：

‧目前變更vCenter Server FQDN機制，僅支援採用「Embedded」運作模式的vCenter Server。

‧在變更vCenter Server FQDN以前，先執行SSO網域中所有的vCenter Server的備份作業，以避免在變更過程中發生不可預期的錯誤時，能夠透過備份進行還原作業。

‧在變更vCenter Server FQDN以前，必須在vCenter Server中先取消註冊其他產品，待vCenter Server FQDN變更完成後，再重新進行產品註冊的動作。

‧在變更vCenter Server FQDN以前，先將vCenter HA運作機制摧毀，待vCenter Server FQDN變更完成後，再重新組態設定和啟動vCenter HA高可用性機制。

‧採用舊有vCenter Server FQDN產生的SSL憑證，待vCenter Server FQDN變更完成後，必須搭配新的FQDN重新產生新的SSL憑證。

‧倘若有採用Hybrid Linked Mode機制時，待vCenter Server FQDN變更完成後，Cloud vCenter Server必須重新建立Hybrid Linked Mode機制。

‧當vCenter Server FQDN變更完成後，vCenter Server必須重新加入Active Directory。

‧必須確認新的vCenter Server FQDN，具備正確的DNS正向解析和反向解析記錄。

確認目前vCenter Server的FQDN

變更vCenter Server FQDN前置作業準備完成後，首先連結至vCenter Server的VAMI（Virtual Appliance Management Interface）管理介面，在本文實作環境中URL為「https://vcsa67.weithenn.org:5480」，並以vCenter Server管理者帳號「root」和密碼登入。

通過身分驗證程序登入vCenter Server VAMI管理介面後，首先點選「Time」項目，確認目前vCenter Server時區設定，與Active Directory、DNS伺服器、ESXi虛擬化平台採用同一個時間，本文實作環境採用的時區為「Asia/Taipei」。

緊接著，點選「Summary」項目，就可以看到目前vCenter Server FQDN的名稱為「vcsa67.weithenn.org」，畫面如圖10所示。

變更vCenter Server的FQDN

接著，確認vCenter Server指向的DNS伺服器，已經能夠正確解析新的vCenter Server FQDN，本文實作環境為「vcsa67u3.weithenn.org」，然後在vCenter Server VAMI管理介面中，依序點選「Networking > Edit」項目。

在彈出的Edit Network Settings精靈互動視窗中，於Select Network Adapter頁面中，倘若vCenter Server有配置多張網路卡時，確認選擇至「NIC 0 （Management Network）」項目的網路卡，確認後按下〔Next〕按鈕。進入Edit Settings頁面後，先在Hostname and DNS欄位中填入新的vCenter Server FQDN名稱，本文實作環境為「vcsa67u3.weithenn.org」，如圖11所示，由於新的vCenter Server FQDN名稱同時搭配新的vCenter Server管理IP位址，在本文實作環境中，DNS伺服器正向解析已經新增對應的IP位址為「10.10.75.25」，因此展開NIC 0項目選擇「Obtain Ipv4 settings automatically」項目即可，確認後按下〔Next〕按鈕。

在SSO Credentials頁面中，填入vCenter Server管理平台中SSO管理憑證，本文實作環境管理者帳號為「Administrator@weithenn.org」，如圖12所示，確認後按下〔Next〕按鈕繼續。

在Ready to complete頁面中，再次檢視新的vCenter Server FQDN名稱是否正確，並勾選「I acknowledge」項目以及檢視Next Steps項目內容。

確認無誤後按下〔Finish〕按鈕，便正式執行變更vCenter Server FQDN的動作。

系統將會開始執行「Network update in progress」程序，先停止vCenter Server相關管理服務，再執行vCenter Server網路組態設定的變更作業，包括新的FQDN和IP位址等網路組態設定，當所有變更作業完成後，重新啟動相關管理服務。

此時，系統將會提醒倒數10秒，之後自動重新導向至新的vCenter Server VAMI管理介面，本文實作環境為「https://vcsa67u3.weithenn.org:5480」，使用vCenter Server管理者帳號「root」和密碼登入後，點選Summary和Networking項目，如圖13所示，確認新的vCenter Server FQDN和IP位址已經套用生效。至此，變更vCenter Server FQDN作業順利完成。

結語

透過本文的深入剖析後，幫助大家快速了解新版vSphere 6.7 Update 3和vSAN 6.7 Update 3亮眼特色功能，並且實作演練vCenter Server Update 3新功能，也就是變更vCenter Server FQDN和IP位址，以便因應企業和組織升級版本或更換vCenter Server平台時，必須變更名稱和網路組態設定的需求。

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