網管人雜誌
本文刊載於 網管人雜誌第 192 期 - 2022 年 1 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言
隨著最新 VMworld 2021 大會拉開序幕，VMware 官方也同步發佈最新版本 vSphere 7 Update 3 和 vSAN Update 3。首先，在容器運作效能方面，VMware 官方宣佈在 vSphere with Tanzu 容器平台上，運作的容器數量和其它主流容器平台及裸機架構相較之下，不僅運作數量多出「6.3 倍」之外（如圖 1 所示），並且容器運算節點也未發生不穩定或效能不佳的情況。
圖 1、vSphere with Tanzu 和其它容器平台相較之下，可運作多達 6.3 倍的 Pod 數量
除了在容器數量勝出其它容器平台之外，也同時與 GPU/vGPU 技術進行整合（如圖 2 所示）。因此，企業和組織內的資料科學家針對 AI/ML 等工作負載時，都可以達到更快速的開發週期和縮短模型訓練時間。
圖 2、NVIDIA 和 VMware 合作的 AI-Ready Enterprise Platform 運作架構示意圖
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 管理平台，在執行定期安全性更新或升級版本的工作任務時，將「停機時間」（Downtime）縮短到最低。
RDU 的 API-Driven 機制，為 VMC on AWS 公有雲和 Project Arctic 專案所演化而來的技術。
下列為透過新版 RDU 機制，幫 vCenter Server 管理平台進行版本升級時的流程（如圖 3 所示）：
- 階段一： 建立和部署新版本的目的端 vCSA 主機。
- 階段二： 將來源端 vCSA 主機中，資料庫和組態設定檔內容複製到目的端 vCSA 主機。
- 階段三： 當系統判定來源端和目的端 vCSA 主機，在資料庫和組態設定檔內容皆同步且一致時，才執行「切換」（Switch Over）的動作。整個流程只有在執行切換動作時，才會對 vCenter Server 管理平台造成短暫的停機時間。
- 階段四： 目的端 vCSA 主機完成接手 vCenter Server 管理平台服務，系統執行關閉和清除來源端 vCSA 主機的動作。
圖 3、vCenter Server 透過 RDU 機制執行版本升級流程示意圖
雖然，透過 RDU 機制能夠有效避免 vCenter Server 管理平台，因為進行更新或升級版本的工作任務時導致系統損壞的情況。然而，它並不能夠取代企業或組織原有的 vCenter Server 備份機制，這點是管理人員容易忽略的部份。
vMMR 機制增強記憶體監控範圍
了解和管理過 vSphere 虛擬化環境的管理人員便知，記憶體資源在 vSphere 基礎架構中的重要性。事實上，即便配置在多的記憶體資源都會發現不足，當然記憶體資源的預算佔比過高也是導致資源無法充足的原因之一，根據統計 DRAM 記憶體資源的預算花費，約佔每台伺服器的 50~60%，倘若拉高規格配置至 1 TB DRAM 時，更會佔用每台伺服器 75% 的預算費用。
因此，近年來開始流行導入「PMem（Persistent Memory）」技術，市場上大約有 NVDIMM-N 和 DCPMM 等二種主流類型。簡單來說，傳統上 DRAM 雖然速度最快，但是最大的缺點在於伺服器一旦關機後，儲存於其中的資料便消失殆盡，而 PMem 雖然速度不如 DRAM，但是最大優點在於當伺服器關機後，資料仍然能夠儲存於其中不會消失，並且在價格上也較 DRAM 便宜，同時在速度和效能方面又優於任何傳輸介面的 SSD 固態硬碟（如圖 4 所示）。
DCPMM（Intel Optane DC Persistent Memory），雖然延遲時間高於 DRAM 但差距僅在「奈秒」（nanoseconds），並且可以直接使用硬體伺服器的 DDR4 記憶體插槽。
圖 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 所示）。
圖 5、在 vSphere 運作架構中的 PMem 資源使用示意圖
透過 PMem 資源的 Memory Mode 機制，能夠在有限的 IT 預算之內最大化 vSphere 記憶體資源，舉例來說，在 ESXi 主機配置 256GB 的傳統 DRAM，加上新式的 512GB PMem 並開啟 Memory Mode 後，管理人員便可以在 vCenter Server 操作介面中，依序點選「Configure > Hardware > Overview > Memory」，即可看到 Memory 分層資訊，並確保 PMem 資源正確採用為 Memory Mode（如圖 6 所示）。
圖 6、確認 PMem 資源採用 Memory Mode
然而，即便再耐用的 DRAM 和 PMem 資源，都將因為運作時間拉長而可能產生故障，造成 VM 虛擬主機、應用程式、容器……等工作負載效能異常或低落。因此，最新 vSphere 7 U3 版本中，新增支援「Host Level / VM Level」這二個層級在 DRAM 和 PMem 記憶體資源方面的監控和修復機制（如圖 7 所示），所以無論是 ESXi 主機或 VM 虛擬主機層級，在 DRAM 和 PMem 效能發生問題時都會發出告警，當然管理人員也可以自行定義相對事件發生時觸發告警機制。
圖 7、新版 vSphere 7 U3 支援監控和修復 DRAM 和 PMem 記憶體資源
更智慧的 vCLS 調度機制
在過去的 vSphere 版本中，管理人員並無法針對 vCLS 調整進階組態設定，所以有可能會影響其它工作負載造成潛在問題。因此，在新版 vSphere 7 U3 版本中，同樣將 VMC on AWS 雲端環境中，智慧型的運算工作負載原則落地到地端資料中心內。
有關 vCLS 組態設定 Smarter Affinity 機制的詳細資訊，請參考 VMware KB79892、KB80472 知識庫文章。
此外，新版中針對自動化產生的 vCLS 虛擬主機的隨機名稱，改為用 UUID 取代之外（如圖 8 所示），也取消過去採用的「空格」和「括號」等名稱規則，避免自動化腳本發生非預期性的問題。
圖 8、新版中針對自動化產生的 vCLS 虛擬主機隨機名稱改為用 UUID 取代
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 所示）。
圖 9、檢查並審視 vSphere Administrators 群組管理人員帳號
停用 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 通訊協定的主要原因。
圖 10、系統提示 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 OffGet-VMHost | Get-VMHostService | Where-Object {$_.Key -eq 'TSM-SSH'} | Stop-VMHostService值得注意的是，有些管理人員可能會開啟 SSH 通訊協定，卻又不希望 ESXi 主機顯示警告圖示和系統提示訊息，所以透過調整「UserVars.SuppressShellWarning」進階參數的方式，隱藏警告圖示和提醒訊息（如圖 11 所示），這樣的系統管理方式並未受到 VMware 官方的推薦，管理人員應該採用預設值開啟警告提示功能，這才是 VMware 官方建議的方式。
有關啟用 SSH 通訊協定，卻又想隱藏警告圖示和提醒訊息的詳細資訊，請參考 VMware KB2003637 知識庫文章。
圖 11、透過調整進階參數的方式，隱藏系統的警告圖示和提醒訊息
此外，在 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 所示）。
圖 12、停用 vCenter Server 的 SSH 通訊協定
同樣的，管理人員也可以透過下列 PowerCLI，為 vCenter Server 停用 SSH 通訊協定。
Invoke-GetAccessSsh$AccessSshSetRequestBody = Initialize-AccessSshSetRequestBody -Enabled $falseInvoke-SetAccessSsh -AccessSshSetRequestBody $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 知識庫文章。
圖 13、為 ESXi 主機啟用和選擇採用哪種 Lockdown Mode 運作模式
在正式啟用 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 所示）。
圖 14、採用 Normal 運作模式時，無法透過 vSphere Host Client 連線和管理 ESXi 主機
圖 15、採用 Strict 運作模式時，甚至連 DCUI 機制都無法登入 ESXi 主機
此時，可能有管理人員會問，倘若 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 運作模式。
圖 16、透過 DCUI 暫時關閉 Lockdown Mode 機制
值得注意的是，有些管理人員可能已經注意到 Lockdown Mode 機制，可以組態設定「例外使用者」（Exception Users），也就是在例外人員清單中的使用者帳號（如圖 17 所示），不會受到 Lockdown Mode 運作模式的影響，但這並非 VMware 所建議的安全性設定，因為此舉同樣讓 ESXi 主機暴露在攻擊風險中，因為系統安全性和操作便利性一直以來便是互相的兩個拉扯點，從來沒有系統管理人員在操作上非常便利，同時系統安全層級也維持在高安全性的機制，唯有操作上越麻煩在系統遭受攻擊時，才同樣會讓攻擊者不易侵入系統的安全性機制。
圖 17、組態設定 Lockdown Mode 例外人員清單
同樣的，管理人員可以透過下列 PowerCLI，一次為大量的 ESXi 主機組態設定啟用 Lockdown Mode – Normal 運作模式。倘若，希望採用 Lockdown Mode – Strict 運作模式的話，可將 PowerCLI 內容中「lockdownNormal」關鍵字修改為「lockdownStrict」，希望加入例外使用者時，只要將 PowerCLI 內容中「$NULL」關鍵字，修改為例外使用者帳號即可，例如，root。
$Hosts = Get-VMHostforeach（$ESXi in $Hosts）{$view =（Get-VMHost $ESXi | Get-View）$accessmanager =（Get-View $view.ConfigManager.HostAccessManager）$accessmanager.ChangeLockdownMode（"lockdownNormal"）$accessmanager.UpdateLockdownExceptions（$NULL）}啟用 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 主機的接受等級。
圖 18、即可調整 ESXi 主機預設採用的接受等級
此外，管理人員也可以透過「esxcli software vib list」指令，查詢目前 ESXi 虛擬化平台中，已經安裝哪些 VIB 套件和接受等級為何（如圖 19 所示），確保 ESXi 虛擬化平台的安全性和穩定性。倘若，發現有安裝 CommunitySupported 接受等級的 VIB 套件，也可以使用「esxcli software vib remove -n <VIB_Name>」指令進行移除。
有關 esxcli 指令安裝 VIB 套件的詳細資訊，請參考 VMware KB2008939 知識庫文章。
圖 19、查詢目前 ESXi 虛擬化平台中已經安裝哪些 VIB 套件和接受等級
結語
透過本文的深入剖析和實戰演練基本安全性設定後，相關管理人員已經了解最新發佈的 vSphere 7 Update 3 的亮眼新功能，能夠幫助企業和組織解決哪些困擾已久的問題。此外，透過基本安全性組態設定，提醒管理人員在著重調校各項效能數據時，也別忘了鞏固 vSphere 虛擬化基礎架構的安全性，確保企業和組織機敏資料不外洩。
