升級vSphere 7 U3新版　機敏資訊保護更周全

隨著最新VMworld 2021大會拉開序幕，VMware官方也同步發佈最新版本vSphere 7 Update 3和vSAN Update 3。首先，在容器運作效能方面，VMware官方宣佈在vSphere with Tanzu容器平台上，運作的容器數量與其他主流容器平台及裸機架構相比，不僅運作數量多出6.3倍外，並且容器運算節點也未發生不穩定或效能不佳的情況，如圖1所示。

除了在容器數量勝出其他容器平台外，也同時與GPU/vGPU技術進行整合，如圖2所示。因此企業組織內的資料科學家針對AI/ML等工作負載時，都可以達到更快速的開發週期和縮短模型訓練時間。

vSphere 7 Update 3亮眼特色功能

接下來，分別說明vSphere 7 Update 3新增的特色功能。

vCenter Server雲端更新機制落地

在過去的vSphere版本中，當vCenter Server必須執行重大安全性更新或版本升級時，由於vCenter Server管理平台必須執行部署新版本的目的端vCSA、停止來源端vCSA系統服務、安裝安全性更新、安裝Binary檔案、執行相關自動化腳本、關閉來源端vCSA、目的端vCSA啟動系統服務等等動作，因此除了一開始部署新版本的目的端vCSA動作外，其餘的動作將會讓vCenter Server管理平台產生「停機時間」（Downtime），導致版本升級的整體停機時間過長。

而最新的vSphere 7 U3版本，VMware官方將原有VMware Cloud公有雲環境的「vCenter Server RDU（Reduced Downtime Upgrade）」機制，正式落地到企業組織的地端資料中心內。簡單來說，透過RDU的API-Driven機制可讓vCenter Server管理平台在執行定期安全性更新或升級版本時，將「停機時間」縮短到最低。

下列為透過新版RDU機制，協助vCenter Server管理平台進行版本升級時的流程，如圖3所示：

‧階段一：建立和部署新版本的目的端vCSA主機。

‧階段二：將來源端vCSA主機中，資料庫和組態設定檔內容複製到目的端vCSA主機。

‧階段三：當系統判定來源端和目的端vCSA主機，在資料庫和組態設定檔內容皆同步且一致的時候，才執行「切換」（Switch Over）的動作。整個流程只有在執行切換動作時，才會對vCenter Server管理平台造成短暫的停機時間。

‧階段四：目的端vCSA主機完成接手vCenter Server管理平台服務，系統執行關閉和清除來源端vCSA主機的動作。

雖然透過RDU機制能夠有效避免vCenter Server管理平台因為進行更新或升級版本的工作任務時導致系統損壞的情況，然而它並不能夠取代企業原有的vCenter Server備份機制，這點是管理人員容易忽略的部分。

vMMR機制增強記憶體監控範圍

了解和管理過vSphere虛擬化環境的管理人員便知，記憶體資源在vSphere基礎架構中的重要性。事實上，即便配置再多的記憶體資源都會發現不足，當然記憶體資源的預算占比過高也是導致資源無法充足的原因之一。根據統計，DRAM記憶體資源的預算花費，約占每台伺服器的50～60%，倘若拉高規格配置至1TB DRAM時，更會占用每台伺服器75%的預算費用。

因此，近年來開始流行導入「PMem（Persistent Memory）」技術，市場上大約有NVDIMM-N和DCPMM等兩種主流類型。簡單來說，傳統上DRAM雖然速度最快，但最大的缺點在於伺服器一旦關機後，儲存於其中的資料便消失殆盡，而PMem雖然速度不如DRAM，但是最大優點在於當伺服器關機後，資料仍然能夠儲存於其中不會消失，並且在價格上也較DRAM便宜，同時在速度和效能方面又優於任何傳輸介面的SSD固態硬碟，如圖4所示。

在應用方面，DCPMM支援多種不同運作模式，包括App Direct Mode、Memory Mode、Mixed Mode、vPMem、vPMemDisk等，方便管理人員針對不同的效能需求和層級使用DCPMM資源：

‧App Direct Mode：應用程式直連模式，通常用於改善VM虛擬主機中應用程式的I/O儲存效能，例如SAP HANA、Oracle、MSSQL、Redis等等資料庫，但必須針對應用程式進行調整，例如允許客體作業系統能夠使用PMem持久性儲存，才能有效提升儲存效能減少I/O瓶頸。

‧Memory Mode：記憶體模式，透過PMem更便宜且容量更大的特性，將PMem資源轉化為DRAM給vSphere使用，並且關閉PMem持久性儲存的特色。簡單來說，可以使用更低的成本大幅提升vSphere的DRAM記憶體資源，並且VM虛擬主機和應用程式無須任何調整即可使用。

‧Mixed Mode：混合模式，允許管理人員針對PMem資源配置使用百分比，例如配置35%為App Direct Mode，而剩下的65%為Memory Mode。

‧vPMem和vPMemDisk：讓VM虛擬主機能夠直接使用NVDIMM-O資源，或是將PMem資源配置成為VM虛擬主機的虛擬硬碟，如圖5所示。

透過PMem資源的Memory Mode機制，能夠在有限的IT預算之內最大化vSphere記憶體資源。舉例來說，在ESXi主機配置256GB的傳統DRAM，加上新式的512GB PMem並開啟Memory Mode後，在vCenter Server操作介面中依序點選「Configure > Hardware > Overview > Memory」，即可看到Memory分層資訊，並確保PMem資源正確採用為Memory Mode，如圖6所示。

然而，即便再耐用的DRAM和PMem資源，都可能因為運作時間拉長而產生故障，造成VM虛擬主機、應用程式、容器等等工作負載效能異常或低落，因此最新的vSphere 7 U3新增支援「Host Level/VM Level」這二個層級在DRAM和PMem記憶體資源方面的監控和修復機制，如圖7所示，所以無論是ESXi主機或VM虛擬主機層級，在DRAM和PMem效能發生問題時都會發出告警，當然管理人員也可以自行定義相對事件發生時觸區告警機制。

更智慧的vCLS調度機制

在過去的vSphere版本中，管理人員無法針對vCLS調整進階組態設定，所以有可能會影響其他工作負載造成潛在問題，因此新版vSphere 7 U3同樣將VMC on AWS雲端環境中智慧型的運算工作負載原則落地到地端資料中心內。

此外，新版中針對自動化產生的vCLS虛擬主機的隨機名稱，改為用UUID取代之外，如圖8所示，也取消過去採用的「空格」和「括號」等名稱規則，避免自動化腳本發生非預期性的問題。

vSphere安全加強—保護機敏資訊

在虛擬化浪潮的推波助瀾下，企業和組織在地端資料中心內將工作負載虛擬化的比例不斷提升，雖然在VM虛擬主機作業系統內，已經有許多安全性機制保護內部應用程式和機敏資料。然而，許多管理人員卻可能忽略最根本的安全性防護機制，也就是vSphere虛擬化基礎架構的保護。

下列將根據最新發佈的VMware CyberSecurity Awareness Month 2021建議要點，提醒管理人員務必檢查和審視vSphere虛擬化基礎架構中容易被忽略的基礎安全性設定，在著重工作負載和效能調校的同時，也應注意根本的安全性設定有效提升vSphere整體防護層級。

確保誰能存取vCenter Server

企業組織內的管理人員除了常常身兼數職外還必須處理日常工作事務，例如哪台VM虛擬主機當機需要重新啟動、哪台VM虛擬主機效能不佳、誰的密碼過期需要重新設定等等。同時，有可能管理人員的調動或離職，在過渡期間未即時停用或刪除該帳號而造成安全性漏洞，甚至心生怨恨的員工透過這樣的正常存取管道，連回公司刪除重要商務資料犯下大錯的新聞也時有耳聞。

在管理介面中依序點選「Administration > Single Sign On > Users and Groups > Groups > Administrators」，即可看到具備vSphere架構中最大管理權限Administrators群組中有誰，在一般管理思維情況下，通常會採用使用者群組的方式，例如vSphere Admins，將相關管理人員加入群組以方便管理。

然而，這樣的管理架構缺點在於，當Windows AD團隊和vSphere團隊不同管理人員時，就有可能發生上述過渡期間安全性漏洞的問題，因為在vSphere管理介面中無法查看使用者群組內詳細的使用者帳號清單，所以面對這種情況時的管理思維是，應該單獨將具備管理權限的使用者帳號加入，例如Weithenn，以避免Windows AD和vSphere管理團隊落差的情況，如圖9所示。

停用SSH通訊協定

在vSphere運作架構中，vCenter Server和ESXi虛擬化平台透過啟用SSH通訊協定進行故障排除和其他維護工作任務，例如管理人員需要從ESXi主機複製VM日誌檔案等等。值得注意的是，執行完故障排除和維護工作任務後，應該立即停用SSH通訊協定，然而許多時候管理人員可能一時疏忽，或是正要準備停用SSH通訊協定時被其他事情打斷而忘記，這便是造成安全性風險的情況。

因為一旦ESXi開啟SSH通訊協定，任何登入到Shell環境的人員，基本上相當於在Linux作業系統中獲得「root」帳號和權限，雖然在Shell環境下的所有操作都會同步記錄到系統日誌當中，但稍有資訊安全的管理人員便知，所有惡意程式一旦掃描到主機有開啟SSH通訊協定時，便會嘗試使用root帳號搭配常用密碼，甚至使用暴力破解密碼的方式登入，造成安全性漏洞的產生。

這就是為何一旦為ESXi開啟SSH通訊協定後，在vCenter Server管理介面中，如圖10所示，該台ESXi主機便會出現警告圖示，並且點選Summary頁籤時，系統會提醒管理人員該台ESXi主機已經啟用SSH通訊協定的主要原因。

當企業組織的vSphere虛擬化架構中有多台ESXi虛擬化平台時，上述透過GUI圖形化介面的檢查方式便不切實際，管理人員可以透過下列PowerCLI，一次檢查指定的vCenter Server中所有的ESXi主機，是否啟用和執行SSH通訊協定並且關閉SSH通訊協定：

Get-VMHost | Get-VMHostService | Where- Object {$_.Key -eq 'TSM-SSH' -and $_.Running  -eq 'True'} Get-VMHost | Get-VMHostService | Where-Object {$_.Key -eq 'TSM-SSH'} | Set- VMHostService -Policy Off Get-VMHost | Get-VMHostService | Where-Object {$_.Key -eq 'TSM-SSH'} | Stop- VMHostService

值得注意的是，有些管理人員可能會開啟SSH通訊協定，卻又不希望ESXi主機顯示警告圖示和系統提示訊息，所以透過調整「UserVars.SuppressShellWarning」進階參數的方式，隱藏警告圖示和提醒訊息，如圖11所示，這樣的系統管理方式並未受到VMware官方的推薦，管理人員應該採用預設值開啟警告提示功能，這才是VMware官方建議的方式。有關啟用SSH通訊協定，卻又想隱藏警告圖示和提醒訊息的詳細資訊，可參考VMware KB2003637知識庫文章。

此外，在vCenter Server啟用SSH通訊協定的部分，也常常被管理人員所遺忘。因為在安裝vCenter Server過程中，系統會提示需要建立vCenter Server HA高可用性機制時，必須為vCenter Server啟用SSH通訊協定才行，所以有些管理人員為了確保後續可以順利建立vCenter Server HA機制，便在安裝過程中不經意地為vCenter Server啟用SSH通訊協定，然而在目前的vCenter Server管理介面中，卻不會提醒管理人員vCenter Server已經啟用SSH通訊協定。

其實，只要登入至vCenter Server Management管理介面中，依序點選「Access > Access Settings > Edit > Enable SSH Login」，即可停用vCenter Server的SSH通訊協定，如圖12所示。

同樣地，管理人員也可以透過下列PowerCLI，為vCenter Server停用SSH通訊協定：

Invoke-GetAccessSsh $AccessSshSetRequestBody = Initialize- AccessSshSetRequestBody -Enabled  $false Invoke-SetAccessSsh -AccessSshSet RequestBody  $AccessSshSetRequestBody

啟用Lockdown Mode安全機制

有經驗的vSphere管理人員便知，當ESXi虛擬化平台被vCenter Server納入管理之後，便應該只透過vCenter Server管理和維護ESXi主機，而非透過vSphere Host Client去連結「單台」ESXi主機，因為此舉可能會造成該台ESXi主機的組態，與vCenter Server資料庫中的組態設定不一致，導致非預期的錯誤產生。

管理人員可透過啟用ESXi主機的「Lockdown Mode」機制，來避免當ESXi主機已經被vCenter Server納入管理，卻又有新手管理人員透過vSphere Host Client管理和維護ESXi主機的情況產生。事實上，啟用Lockdown Mode機制非常簡單，在管理介面中依序點選「Datacenter > Cluster > ESXi > Configure > System > Security Profile > Lockdown Mode > Edit」，便能夠啟用和選擇採用Lockdown Mode的哪種運作模式，如圖13所示。有關啟用Lockdown Mode的詳細資訊，可參考VMware KB1008077知識庫文章。

在正式啟用ESXi主機Lockdown Mode之前，應先了解Lockdown Mode的三種運作模式和差異：

‧Disabled：已停用模式，此運作模式為預設值，也就是允許管理人員可以透過各種機制連線及管理ESXi主機，例如vSphere Host Client、SSH、ESXi Shell、DCUI（Direct Console User Interface）、vCenter Server等等。

‧Normal：正常模式，管理人員僅能透過vCenter Server或DCUI機制連線和管理ESXi主機，嘗試透過vSphere Host Client、SSH、ESXi Shell連線ESXi主機時，將會得到拒絕連線的訊息，如圖14所示，此模式也是VMware建議管理人員採用的運作模式。

‧Strict：嚴格模式，管理人員僅能透過vCenter Server連線和管理ESXi主機，嘗試採用其他機制連線ESXi主機時，都會得到拒絕連線的訊息，如圖15所示。

此時可能有管理人員會問，倘若vCenter Server為VM虛擬主機並且運作在ESXi主機內，當地端資料中心因為災難或歲休而關閉vCenter Server時，那麼該如何登入ESXi主機並Power On vCenter Server呢？

根據VMware的建議，採用Lockdown Mode - Normal運作模式時，雖然僅允許vCenter Server或DCUI機制連線和管理ESXi主機，然而當發生上述情況時，管理人員可先透過DUCI機制登入ESXi主機，將Lockdown Mode機制關閉，如圖16所示，然後再透過vSphere Host Client登入ESXi主機並啟動vCenter Server，待vCenter Server恢復正常運作後，再次為ESXi主機開啟並採用Lockdown Mode - Normal運作模式。

值得注意的是，有些管理人員可能已經注意到Lockdown Mode機制，可以組態設定「例外使用者」（Exception Users），也就是在例外人員清單中的使用者帳號，如圖17所示，不會受到Lockdown Mode運作模式的影響，但這並非VMware所建議的安全性設定，因為此舉同樣讓ESXi主機暴露在攻擊風險中，因為系統安全性和操作便利性一直以來便是互相的兩個拉扯點，從來沒有系統管理人員在操作上非常便利，同時系統安全層級也維持在高安全性的機制，唯有操作上越麻煩，在系統遭受攻擊時才同樣會讓攻擊者不易侵入系統的安全性機制。

同樣地，管理人員可以透過下列PowerCLI，一次為大量的ESXi主機組態設定啟用Lockdown Mode - Normal運作模式：

$Hosts = Get-VMHost foreach （$ESXi in $Hosts） {   $view = （Get-VMHost $ESXi | Get-View）   $accessmanager = （Get-View $view.     ConfigManager.HostAccessManager）   $accessmanager.ChangeLockdownMode （"lockdownNormal"）   $accessmanager.UpdateLockdownExceptions （$NULL）

若想採用Lockdown Mode - Strict運作模式，可將PowerCLI內容中的lockdownNormal關鍵字修改為lockdownStrict，希望加入例外使用者時，只要將PowerCLI內容中「$NULL」關鍵字，修改為例外使用者帳號即可，例如root。

啟用VIB安裝管控機制

在Windows作業系統中有MSI（Microsoft Installer），在Linux作業系統中常見有RPM（Redhat Package Manager）等套件安裝和管理機制，在VMware vSphere虛擬化架構中則稱為VIB（vSphere Installable Bundle）。

當管理人員手動為ESXi安裝更新或其他支援套件時，應該先確認這個VIB的「接受等級」（Acceptance Level），再判斷是否進行安裝的動作，否則有可能會影響ESXi虛擬化平台的效能和穩定性。

舉例來說，管理人員為ESXi主機安裝由某個VMware社群所發佈的VIB，由於該VIB並未通過VMware審核的測試計畫，當然就不受VMware官方和合作夥伴的技術支援。

簡單來說，VMware官方針對不同類型的VIB共有四種接受等級：

‧VMwareCertified：受到VMware最嚴格的要求並完整通過所有測試項目，例如IOVP（I/O Vendor Program），等同於該VIB套件受到VMware內部品質測試保證，所以VMware將接受該VIB套件的所有技術支援。

‧VMwareAccepted：僅通過相關測試項目而非全面測試，例如CIM providers、PSA plug-ins，VMware合作夥伴會先執行測試後，再交給VMware官方驗證結果並發佈，所以VMware會把該VIB套件的技術支援轉交給該合作夥伴。

‧PartnerSupported：由VMware合作夥伴所發佈並通過相關測試，例如Infiniband、SSD driver，通常合作夥伴在VMware環境中啟用新技術或支援非主流技術時使用，同樣地，VMware會把該VIB套件的技術支援轉交給該合作夥伴。

‧CommunitySupported：未通過任何一項VMware測試項目，所以不受VMware官方和合作夥伴的技術支援。

管理人員可以先確認ESXi主機預設採用的接受等級，然後再檢查所要安裝的VIB套件接受等級為何。在管理介面中，依序點選「Datacenter > Cluster > ESXi > Configure > System > Security Profile > Host Image Profile Acceptance Level > Edit」，即可調整ESXi主機預設採用的接受等級，如圖18所示。另外，也可以透過「esxcli software acceptance get」指令來檢查ESXi主機的接受等級。

管理人員也可以透過「esxcli software vib list」指令，查詢目前ESXi虛擬化平台中已經安裝哪些VIB套件和接受等級為何，如圖19所示，確保ESXi虛擬化平台的安全性和穩定性。 如果發現有安裝CommunitySupported接受等級的VIB套件，也可以使用「esxcli software vib remove -n 」指令進行移除。有關esxcli指令安裝VIB套件的詳細資訊，請參考VMware KB2008939知識庫文章。

結語

透過本文的深入剖析和實戰演練基本安全性設定後，相關管理人員已經了解最新發佈的vSphere 7 Update 3亮眼新功能，能夠幫助企業和組織解決哪些困擾已久的問題。

此外，透過基本安全性組態設定，提醒管理人員在著重調校各項效能數據時，也別忘了鞏固vSphere虛擬化基礎架構的安全性，確保企業和組織機敏資料不外洩。

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