網管人雜誌
本文刊載於 網管人雜誌第 152 期 - 2018 年 9 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言全面改用 HTML 5 vSphere Client
最後一版 Windows vCenter Server
ESXi 虛擬化平台再進化
vSphere Quick Boot
安全性功能增強
ESXi 虛擬化平台支援新式 TPM 2.0
vTPM 2.0 擴大保護範圍至 VM 虛擬主機
舊有 VMFS 3 檔案系統正式停用
LUN/Path 擴充性再提升
支援新式 4Kn 儲存裝置
原生支援 Intel VMD 技術
支援新式 PMem NVDIMM 儲存裝置
正式支援 RDMA
SW-FCoE 內建於 vSphere
結語
前言
在日前 2018 年 4 月 17 日時，VMware 官方正式發佈全新 vSphere 6.7 軟體定義資料中心解決方案，同時也發佈 SDDC 軟體定義資料中心內，最重要的 vCenter Server 6.7 管理平台、SDS 軟體定義儲存解決方案 vSAN 6.7 版本……等（如圖 1 所示）。雖然，只是從 vSphere 6.5 更新為 vSphere 6.7 的小版本更新，卻已經相隔約一年半後才推出。前一版 vSphere 6.5 軟體定義資料中心解決方案，於 2016 年 11 月 15 日發佈。
圖 1、VMware 最新發佈 VMware vSphere 6.7 打造 SDDC 軟體定義資料中心解決方案
雖然，只是 vSphere 6.x 的小版本更新，然而相關硬體資源支援度同樣再次倍數提升。在下列表格中，條列出企業及組織使用的主流版本 vSphere 6.0、6.5 及最新 vSphere 6.7 版本，在硬體資源支援度上有哪些提升（詳細資訊請參考 VMware KB 1003497 – ESXi Configuration Maximums）。
請注意，倘若企業或組織仍使用舊版 vSphere ESXi 5.5 及 vCenter Server 5.5 版本的話，那麼將於「2018 年 9 月 19 日」進入「終止支援（End Of Support，EOS）」，所以企業及組織應儘快進行版本升級的動作。
全面改用 HTML 5 vSphere Client
在過去舊版的 vSphere 運作環境中，管理人員皆是採用 vSphere Web Client（Flash）管理工具（如圖 2 所示）。在最新 vSphere 6.7 版本中，VMware 官方已經宣佈舊有 Flash-based 的 vSphere Web Client 將為「最後一版」管理工具。
圖 2、舊有 Flash-based 的 vSphere Web Client 管理工具示意圖
因此，管理人員應該開始改為使用全新 HTML5-based 的 vSphere Client 管理工具（如圖 3 所示），因為在新版 vSphere 6.7 當中的 HTML 5 vSphere Client 管理工具，其整體功能完整性已經達到「90% ~ 95%」，可以順利管理 vSAN、NSX、Storage Policies、Host Profile、vDS vSwitch……等，並且 VMware 官方預計於 2018 年秋天推出完整功能的 HTML 5 vSphere Client 管理工具。
有關 HTML 5 vSphere Client 管理工具，2018 年秋天推出完整功能的詳細資訊，請參考 VMware vSphere Blog - Fully Featured HTML5-based vSphere Client Coming in Fall 2018 文章內容。
圖 3、新版 HTML5-based 的 vSphere Client 管理工具示意圖
最後一版 Windows vCenter Server
在新版 vSphere 6.7 運作架構中，vCSA（vCenter Server Appliance）管理平台已經是「預設」的部署選項。最新版本的 vCSA 6.7 管理平台，除了已經包含 PSC（Platform Services Controller）、Linked Mode……等功能外，透過新增的新式 API 相較於舊版 vCSA 6.5 管理平台在操作效能上提升 2 倍、記憶體資源使用量減少 3 倍、執行自動化遷移 VM 虛擬主機的 DRS（Distributed Resource Scheduler）機制遷移速度提升 3 倍……等（如圖 4 所示）。
圖 4、新版 vCSA 6.7 管理平台執行效率提升資源損耗下降示意圖
現在，管理人員可以透過新版 vCSA 6.7 管理平台，管理任何規模大小的 vSphere 虛擬化基礎架構，下列便是新版 vCSA 6.7 管理平台新增或增強的特色功能：
- 所有 vCenter Server 服務在「單一執行個體」中運作。
- 新增 Enhanced Linked Mode 至 Embedded PSC 運作架構中。
- 無須建置負載平衡機制，即可輕鬆建立 vCSA HA 高可用性機制。
- 支援 vSphere SSO（Single Sign-On）機制達成更高的靈活性，並在 vSphere SSO Domain 中允許進行 15 次的部署作業（如圖 5 所示）。
- 完整支援 vSphere 大型運作規模。
- 減少不必要的管理和維護節點主機數量。
- 底層作業系統由 SUSE Linux 更改為 Photon OS，以便更容易達成 Rollback 機制。
圖 5、vSphere SSO Domain with Enhanced Linked Mode 運作示意圖
由於，vCSA 6.7 管理平台已經能完全取代 Windows vCenter Server 管理平台，因此隨著最新版本 vCSA 6.7 管理平台版本的發佈，VMware 官方也正式宣佈在 vSphere 6.7 版本中 vCenter Server for Windows 管理平台，為「最後一版」的 Windows vCenter Server 管理平台版本，這表示後續推出的新版 vCenter Server 版本中，VMware 官方將只會發佈 vCSA（vCenter Server Appliance）管理平台。
然而，企業或組織當中可能已經建立 Windows vCenter Server 管理平台，那麼該如何將 Windows vCenter Server 管理平台，遷移至最新 vCSA 6.7 管理平台？ 有鑑於此，VMware 官方推出 VMware Migration Assistant 遷移工具（如圖 6 所示），幫助企業及組織將 Windows vCenter Server 管理平台，無縫遷移至最新 vCSA 6.7 管理平台。
值得注意的是，倘若為舊版 vSphere 5.5 的 Windows vCenter Server 管理平台，那麼必須先升級至 vSphere 6.x 版本才行，下列便是版本升級建議：
- vCenter Server 6.0 / 6.5 版本，可直接升級至最新 vCSA 6.7 版本。
- vCenter Server 5.5 版本必須先升級至 vCenter Server 6.0 / 6.5 版本後，才能升級至最新 vCSA 6.7 版本。
有關 VMware Migration Assistant 遷移工具的詳細操作資訊，請參考本雜誌《第 150 期 – vSphere 管理平台大搬風，趁早無痛遷移 vCSA 6.7》文章內容。
圖 6、VMware Migration Assistant 遷移工具操作畫面示意圖
此外，VMware 官方針對 vCSA 管理平台，推出 VAMI（vSphere Appliance Management Interface）系統管理介面，搭配整合 UX Guidelines、HTML/CSS Framework 和 Angular 技術的 Clarity UI 協同運作，讓管理人員能夠擁有最佳的 vCSA 資源管理操作體驗。
現在，管理人員只要開啟瀏覽器，鍵入 vCSA 6.7 管理平台的 FQDN 或 IP 位址搭配「Port 5480」連接埠，即可看到 vCSA 管理平台的 VAMI 系統管理登入畫面，順利登入後即可看到 vCSA 管理平台的硬體資源情況，包含 CPU 工作負載、記憶體使用情況、vCSA 資料庫、儲存資源……等健康資訊（如圖 7 所示）。
VAMI 系統管理介面已經支援多國語系，例如，日語、法語、正體中文……等。
圖 7、透過 Clarity UI 技術打造的 VAMI 管理介面，快速掌握 vCSA 管理平台硬體資源健康情況
ESXi 虛擬化平台再進化
在新版 vSphere 6.7 運作架構中，再次增強並加速 ESXi 主機的生命週期以節省管理人員的維運時間，除了採用新式 HTML 5 vSphere Client 管理介面之外，在 VUM（vSphere Update Manager）管理介面的部分也同步翻新，讓管理人員在升級 vSphere ESXi 虛擬化平台的動作可以輕鬆完成。在新式 VUM 管理介面中（如圖 8 所示），除了預先檢查 ESXi 虛擬化平台是否需要安裝修補程序或版本升級之外，在後續版本還將支援其它特色功能，例如，升級 VMware Tools 版本、硬體相容性檢查……等。
圖 8、新式 VUM 管理介面預先檢查 ESXi 虛擬化平台示意圖
vSphere Quick Boot
過去，當管理人員執行 ESXi 虛擬化平台版本升級作業時，通常 ESXi 虛擬化平台需要重新啟動數次（通常 2 ~ 3 次），同時現代化 x86 硬體伺服器配備的實體記憶體越來越大（數百 GB 甚至高達 TB），這樣的巨大硬體資源所需的初始化及檢查時間也將花費數分鐘，待硬體伺服器檢查程序完成後進入 vSphere Hypervisor 虛擬化管理程序時，又需要花費數分鐘進行初始化及檢查作業，導致 ESXi 虛擬化平台整體停機時間拉長許多。在新版 vSphere 6.7 當中，透過新式的「vSphere Quick Boot」機制，進行 ESXi 虛擬化平台版本升級作業時除了「重新啟動 1 次」（Single Reboot）即可完成之外，同時無須執行硬體伺服器初始化及檢查作業，有效縮短 ESXi 虛擬化平台停機時間。
此外，過去管理人員需要重新啟動 vSphere Hypervisor 虛擬化管理程序時，只能透過重新啟動 ESXi 虛擬化平台的連動方式達成。現在，透過新版 vSphere Quick Boot 快速啟動機制，無須重新啟動 ESXi 虛擬化平台，即可達成重新啟動 vSphere Hypervisor 虛擬化管理程序的目的，此舉再次有效縮短 ESXi 虛擬化平台停機時間。
如圖 9 所示，左邊 Remote Console 的 ESXi 虛擬化平台，採用新式 vSphere Quick Boot 快速啟動機制，已經進入 vSphere Hypervisor 虛擬化管理程序，而右邊 Remote Console 的 ESXi 虛擬化平台，採用傳統的 Standard Reboot 機制仍在 x86 硬體伺服器初始化及檢查作業中。
圖 9、新式 vSphere Quick Boot 與傳統 Standard Reboot 開機速度比較示意圖
安全性功能增強
在目前混合及多雲的運作環境中，如何保護企業及組織的機敏資料更顯重要。因此，在新版 vSphere 6.7 中，ESXi 虛擬化平台正式支援 TPM 2.0（Trusted Platform Module），能夠儲存加密金鑰、憑證、雜湊……等資料，同時透過 vTPM 2.0 機制更可以將保護範圍擴大到 VM 虛擬主機。事實上，ESXi 虛擬化平台已經支援多年 TPM 1.2。值得注意的是，舊版 TPM 1.2 及新版 TPM 2.0 無法相容，因此舊有 TPM 1.2 的裝置驅動程式及 API 必須重新開發。
ESXi 虛擬化平台支援新式 TPM 2.0
在新版 vSphere 6.7 的運作架構中，當 ESXi 虛擬化平台採用的 x86 硬體伺服器，配置 TPM 2.0 安全性模組後，那麼 ESXi 虛擬化平台便能啟用「安全啟動」（Secure Boot）機制，透過底層硬體保護 ESXi 虛擬化平台的 UEFI Firmware、Boot Loader、VMKernel 等初始化及開機程序（如圖 10 所示）。簡單來說，ESXi 虛擬化平台將安全性資訊儲存於 TPM 2.0 安全性模組當中，而 vCenter Server 管理平台將會讀取相關資訊，例如，ESXi Event Log、VIB Metadata……等，並且與受管理的 ESXi 虛擬化平台進行匹配比較，確保 ESXi 虛擬化平台只會運作通過驗證的程式碼免於遭受攻擊。
事實上，在 vSphere 6.5 版本時便已經支援 Secure Boot，但當時僅能使用舊版 TPM 1.2 安全性模組進行實作，詳細資訊請參考 VMware vSphere Blog - Secure Boot for ESXi 6.5 – Hypervisor Assurance 文章內容。
圖 10、Secure Boot 機制有效保護 ESXi 虛擬化平台初始化及開機程序
vTPM 2.0 擴大保護範圍至 VM 虛擬主機
當 ESXi 虛擬化平台配置 TPM 2.0 安全性模組後，便能啟用 vTPM 2.0 機制並將加密金鑰、憑證、雜湊等機敏資料保護機制擴大到 VM 虛擬主機。啟用 vTPM 2.0 機制的 VM 虛擬主機，在客體作業系統中將會如同實體主機一樣看到普通的 TPM 2.0 安全性模組，當管理人員需要進行加密金鑰、憑證、雜湊等機制保護機敏資料時，便會將相關資料寫入 VM 虛擬主機當中的 NVRAM 檔案內，同時採用 VM Encryption 機制保護該檔案，並且同時支援 Windows VBS（Virtualization-Based Security）安全性機制協同運作（如圖 11 所示）。
此外，啟用 vTPM 2.0 保護機制的 VM 虛擬主機，當遷移或匯出至其它資料中心或雲端環境時，倘若該資料中心或雲端環境未支援或使用 KMS（Key Management System），仍然可以透過原有的 vTPM 2.0 保護機制確保機敏資料無法被惡意人士所碰觸。
圖 11、TPM / vTPM 支援 Windows VBS 安全性機制示意圖
舊有 VMFS 3 檔案系統正式停用
在前一版 vSphere 6.5 當中，僅能支援讀取舊有的 VMFS 3 檔案系統但無法建立。在最新 vSphere 6.7 版本中，舊有的 VMFS 3 檔案系統將正式 EOL（End of Life）停止使用（如圖 12 所示），所以管理人員倘若未將 VMFS 3 升級至 VMFS 5 檔案系統版本的話，那麼屆時將不會自動掛載 VMFS 3 檔案系統，屆時也將無法在 VMFS 3 檔案系統中建立或開啟檔案。舊有 VMFS 3 檔案系統僅能升級至 VMFS 5 版本，再從 VMFS 5 升級至最新 VMFS 6 檔案系統，並不支援直接由 VMFS 3 升級至 VMFS 6 檔案系統版本。詳細資訊請參考 VMware KB2003813 - Frequently Asked Questions on VMware vSphere 5.x for VMFS-5 文件內容。
圖 12、新版 vSphere 6.7 運作環境中，將正式停止支援舊有 VMFS 3 檔案系統
LUN/Path 擴充性再提升
在 vSphere 6.0 版本運作環境中，儲存資源 LUN 的最大支援數量為 256 傳輸路徑 1,024，在 vSphere 6.5 時則提升為 LUN 最大支援數量 512 傳輸路徑 2,048。在最新發佈的 vSphere 6.7 版本中，則再次將運作規模提升至 LUN 最大支援數量「1,024」傳輸路徑「4,096」。此外，在 VM 虛擬主機的部分 VMDK 虛擬磁碟的數量，也從過去的 16 個增加至支援最多「64 個」，這表示當 VM 虛擬主機採用 PVSCSI 硬碟控制器時，可以掛載的虛擬磁碟總數多達「256 個」。
因此，過去在 vSphere 虛擬化運作環境中，當 VM 虛擬主機欲建置 Microsoft WSFC（Windows Server Failover Cluster）運作環境時，在 pRDM 的部分會有最大支援「45 個 vDisk / LUNs」的限制，現在則可以將其中 1 個 PVSCSI 硬碟控制器用於管理，另外 3 個 PVSCSI 硬碟控制器各自支援最多「64 個 vDisk / LUNs」，因此在 Microsoft WSFC 環境可擴大支援至總數「192 個 vDisk / LUNs」（如圖 13 所示）。
圖 13、新版 vSphere 6.7 擴大 VM 虛擬主機 vDisk/LUNs 支援數量
支援新式 4Kn 儲存裝置
在 vSphere 6.5 版本中，是採用 512e 來模擬 4Kn 的方式支援 4K Byte Sector 儲存裝置。現在，新版 vSphere 6.7 運作環境中，採用 4Kn SWE（Software Emulation）來支援 4K Byte Sector 儲存裝置（如圖 14 所示）。一般來說 2011 年 1 月後出廠的硬碟，大多採用 4K Byte Sector 進階格式，而非舊有傳統的 512 Byte Sector 格式。
值得注意的是 4Kn SWE 機制有一些使用上的限制，目前僅支援 ESXi 虛擬化平台中本機 SAS 及 SATA 機械式硬碟，同時必須格式化為最新的 VMFS 6 檔案系統，並且必須採用 UEFI 啟動方式才行。
目前的 4Kn SWE 機制，不支援 SSD、NVMe 儲存裝置及 RDM、GOS 儲存資源。
圖 14、4Kn SWE（Software Emulation）儲存堆疊架構示意圖
原生支援 Intel VMD 技術
Intel VMD（Volume Management Device）技術，除了能夠匯整 NVMe PCIe SSD 底層的 Root Port 之外，還提供錯誤管理、熱插拔、LED 管理等特性達到 NVMe 儲存裝置的可維護性。在新版 vSphere 6.7 運作環境中因為原生支援 Intel VMD 技術，所以安裝在 ESXi 虛擬化平台中的 DAS NVMe 儲存裝置可直接使用，而無須再額外安裝相關的 VIBs 套件後才能順利驅動，同時也能夠無縫與 vSAN 軟體定義儲存技術整合。現在，當 vSAN 或 DAS NVMe 發生升級問題或故障時，能夠直接更換「單個」NVMe 儲存裝置。
值得注意的是，必須採用最新的 Intel Xeon Scalable 處理器（如圖 15 所示），並且安裝支援 Intel VMD 技術的 NVMe 驅動程式，同時執行 Intel VMD LED 管理功能指令的 ESXi 虛擬化平台版本，必須是 ESXi 6.0 U3 或 6.5 或最新 6.7 才支援該 Shell 指令。
圖 15、Intel VMD 技術運作架構示意圖
支援新式 PMem NVDIMM 儲存裝置
在新版 vSphere 6.7 運作環境中，支援新式 PMem（Persistent Memory）儲存裝置（如圖 16 所示）。簡單來說，PMem 為 NVDIMM（Non-Volatile DRAM）儲存裝置，具備 DRAM 高速傳輸但不會因為失去電力而遺失已儲存的資料。
圖 16、PMem（Persistent Memory）NVDIMM 儲存裝置示意圖
簡單來說，PMem NVDIMM 儲存裝置具備接近 DRAM 的高速特性，當 CPU 處理器進行存取作業時就像存取 DRAM 一樣。因此，資料存取速度相較於目前主流的 SSD 快閃儲存來說至少快上「100 倍」以上（如圖 17 所示）。
圖 17、主流 SSD 與新式 PMem 儲存裝置運作架構示意圖
值得注意的是，採用 vNVDIMM 儲存資源的 VM 虛擬主機，除了必須採用 Virtual Hardware version 14 之外，在客體作業系統的部分也必須支援才行，例如，Windows Server 2016 或 RedHat 7.4……等。此外，雖然支援大部分的 vSphere 虛擬化功能，但套用 vNVDIMM 儲存資源的 VM 虛擬主機，目前「不支援」快照及 HA 高可用性保護機制。
正式支援 RDMA
事實上，在 vSphere 6.5 虛擬化平台版本中，便已經開始支援 RDMA（Remote Direct Memory Access）的 RoCE（RDMA over Converged Ethernet），以便於達到「Kernel Bypass、Zero Copy、CPU Offloading」的目的，有效降低 ESXi 虛擬化平台處理大量網路封包的工作負載。vSphere 6.5 版本中，僅支援 RoCE v1 並且不支援 InfiniBand 及 iWARP。
在新版 vSphere 6.7 運作環境中，全面支援 RDMA（InfiniBand、iWARP、RoCE v2）之外，更增強vSphere Kernel / Hypervisr / RDMA 之間的協同運作的部分（如圖 18 所示），讓整體運作效能更加提升。值得注意的是，倘若 VM 虛擬主機採用的 RDMA 為「Passthruogh Mode」時，雖然可以得到最大化的運作效能，但是將會限制 VM 虛擬主機的靈活性，例如，無法接受 DRS 自動化機制的調度（無法 vMotion 遷移至其它 ESXi 虛擬化平台）。
圖 18、RDMA – Kernel Bypass 運作機制示意圖
因此，倘若希望 VM 虛擬主機希望具備 RDMA 的運作效能及靈活性（例如，DRS / vSphere vMotion……等），應該要採用 PVRDMA（Para-Virtual Remote Direct Memory Access）機制才對。目前，必須符合下列相關條件才能順利運作 PVRDMA 功能（詳細資訊請參考官網資訊 VMware Docs - PVRDMA Support）：
- 採用 vSphere ESXi 6.5 或 6.7 虛擬化平台。
- 採用 vCenter Server 6.5 或 6.7 管理平台。
- 採用 vDS（vSphere Distributed Switch）虛擬交換器。
- VM 虛擬主機必須採用 Virtual Hardware Version 13 或 14 版本。
同時，當 VM 虛擬主機採用 vRDMA 機制時，在資料傳輸上將會有下列 3 種情境（如圖 19 所示），以便管理人員判斷 vRDMA 機制運作與否：
- Memcpy： 當 VM 虛擬主機之間在「同一台」ESXi 主機時，將採用 ESXi 虛擬化平台記憶體複製機制即時傳輸。
- RDMA： 當 VM 虛擬主機之間跨越「不同台」ESXi 主機時，且兩端 ESXi 主機皆安裝支援的 RDMA 介面卡時，將會透過 RDMA 進行快速傳輸。
- TCP： 當 VM 虛擬主機之間跨越「不同台」ESXi 主機，且其中一台 ESXi 主機「未」安裝支援的 RDMA 介面卡時，將採用傳統的 TCP/IP 進行傳輸。
圖 19、vRDMA 機制運作與否情境示意圖
此外，在新版 vSphere 6.7 運作環境中，更將 RDMA 特色功能擴大服務使用範圍新增支援 iSER（iSCSI Extension for RDMA）機制。簡單來說，透過整合 RDMA 的 iSER 機制，可以讓企業及組織常用的 iSCSI 網路傳輸作業，從傳統的 TCP Transport 通訊協定增強為 RDMA Transport（如圖 20 所示），進而降低 ESXi 虛擬化平台的 CPU 處理器工作負載，同時也全面支援原有的 iSCSI 管理功能，例如，Discovery、Naming、Security、Error-Recovery、Boot……等。
圖 20、iSER（iSCSI Extension for RDMA）運作架構示意圖
SW-FCoE 內建於 vSphere
在過去的 vSphere 版本中，ESXi 虛擬化平台「必須」配置硬體式 FCoE（Fiber Channel over Ethernet），才能夠啟用 SW-FCoE（Software FCoE）機制。現在，在最新發佈的 vSphere 6.7 運作環境中，ESXi 虛擬化平台「無須」配置硬體式 FCoE 介面卡即可啟用 SW-FCoE 機制（如圖 21 所示），除了可以省去配置昂貴的硬體式 FCoE CAN 介面卡之外，同時能夠與支援 DCB（Data Center Bridging）功能的 Layer 2 網路卡協同運作，因此 SW-FCoE 能夠支援多種傳輸速率，例如，10 Gb、25 Gb、40 Gb、100Gb，並且還支援 Vn2Vn（Virtual node to virtual node）連線機制。
圖 21、新版 vSphere 6.7 運作環境中 SW-FCoE 運作架構示意圖
