顯示具有 網管人雜誌 標籤的文章。 顯示所有文章
顯示具有 網管人雜誌 標籤的文章。 顯示所有文章

網管人雜誌

本文刊載於 網管人雜誌第 134 期 - 2017 年 3 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。



文章目錄

前言
vSAN 6.5 新功能
          iSCSI 存取
          2 台 vSAN Node 直接對接
          全功能 PowerCLI
          支援新世代硬碟 512e 進階格式
          全版本支援 All Flash
結語





前言

在 2016 年 11 月時,VMware 官方在 VMware VMworld 2016 大會上,正式發佈 VMware vSphere 6.5 最新版本並連同 VMware vSAN 6.5 版本也一起推出。簡單來說,VMware Virtual SAN(簡稱 vSAN),是 VMware 的「軟體定義儲存(Software-Defined Storage,SDS)」解決方案,它能夠將多台 x86 實體伺服器內的「本機硬碟(Local Hard Disk)」互相串連起來,進而將叢集當中所有 vSAN 節點主機的儲存資源整合起來,成為一個巨大的儲存資源池並且能夠互相共同使用。

圖 1、VMware vSAN 運作架構示意圖

事實上,從 VMware vSAN 版本的發佈頻率可知,VMware 官方對於打造 SDDC 軟體定義資料中心內,負責儲存資源的 SDS 軟體定義儲存技術的重視。第 1 代的 VMware vSAN 版本,是在 2014 年 3 月時隨著 vSphere 5.5 Update 1 版本開始內建(vSAN 1.0),接著在隔年推出第 2 代 VMware vSAN 版本,是在 2015 年 3 月隨著當時新版 vSphere 6.0 一同發佈,並直接與 vSphere 版本對齊成為 vSAN 6.0 版本(原訂新版本號應為 vSAN 2.0),在這個版本當中最重要的特色為支援 All Flash 運作架構,同時 vSAN 叢集規模可達到 64 台節點之多。
有關第 1 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 110 期《實戰部署 Virtual SAN套用政策自動化搭配 VM》,而第 2 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 114 期《動手建立 VSAN 6 儲存資源,實戰水平擴充與容錯網域》

接著,半年後於 2015 年 9 月時推出第 3 代的 vSAN 6.1 版本,其中最具代表性的功能便是「延伸叢集」(Stretched Cluster)與「支援 2 Nodes」的運作架構。再隔半年後於 2016 年 3 月推出第 4 代 vSAN 6.2 版本,在這個版本當中最重要的特色為 All Flash 運作架構,支援「重複資料刪除與壓縮」(Deduplication and Compression)及「RAID 5/6 EC 編碼技術」(RAID 5/6 Erasure Coding)。
有關第 3 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 120 期《VMware VSAN 延伸叢集,實作跨站點同步 HA 複寫》,而第 4 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 124 期《概覽 VMware VSAN 6.2 新功能加強健康狀態監控》

現在,於 2016 年 11 月隨著最新 VMware vSphre 6.5 的發佈也同時推出第 5 代的 vSAN 6.5 版本,此版本中重要的特色功能條列如下:
  • iSCSI 存取: 支援將 vSAN 儲存空間以 iSCSI目標的方式提供,讓具備 iSCSI 啟動器功能的伺服器能夠連接及使用 vSAN 儲存空間。
  • 2 台 vSAN Node 直接對接: 支援將 2 台 vSAN節點主機直接對接,讓企業及組織當中的分公司或小型企業在建置 vSAN 軟體定義儲存環境時,無須準備昂貴的 10GbE 網路交換器。
  • 全功能 PowerCLI: 在新版 vSAN 6.5 運作環境中,包括完整的 PowerCLI Cmdlet 功能讓企業及組織的自動化作業更具可擴充性及易用性。
  • 支援新世代硬體: 在新版 vSAN 6.5 運作環境中,支援新世代的 x86 硬體伺服器及相關元件,同時也支援 512e 新式大容量儲存裝置。
  • 全版本支援 All-Flash: 現在不管採用哪種 vSAN 6.5 授權版本,都可以使用及建置 vSAN All-Flash 運作架構。
圖 2、VMware Virtual SAN版本演進及新增功能示意圖





vSAN 6.5 新功能

在過去舊版的 vSAN 運作環境內,當 vSphere 管理人員將 vSAN 叢集中的節點主機儲存資源集合之後,儲存資源只能夠以「VMFS 檔案系統」的方式提供及運作 VM 虛擬主機。但是,對於需要採用其它方式使用儲存資源的應用程式或服務來說便會造成困擾,舉例來說,現行企業及組織當中有許多應用程式及服務的儲存資源,便是透過在伺服器中安裝及啟用「iSCSI 啟動器」(iSCSI Initiator)功能,然後透過 TCP/IP 乙太網路連接至「iSCSI 目標端」(iSCSI Target)所提供的 LUN 儲存資源,最後再將應用程式及服務運作在透過 iSCSI 協定所掛載的 LUN 儲存資源當中。

現在,最新版本的 vSAN 6.5 運作架構中,支援將整合後的 vSAN 儲存資源以 iSCSI 目標端的方式,提供給 iSCSI 啟動器掛載 LUN 儲存資源,有效解決過去舊版 vSAN 儲存資源美中不足的困擾。在運作規模方面,每個 vSAN 叢集最多支援提供 1,024 個 LUN 儲存資源,並且每個 LUN 儲存資源空間最大為 62 TB,同時每個 vSAN 叢集最多支援提供 128 個 iSCSI 目標

因為 iSCSI 目標所建立的 LUN 儲存資源,在 vSAN 運作架構底層中其實是以 VMDK 虛擬磁碟的方式存在,所以儲存空間與 VMDK 虛擬磁碟的限制相同為 62 TB。



iSCSI 存取

雖然,最終是以 iSCSI 協定提供儲存資源服務,但是整個運作架構底層還是建構在 vSAN 軟體定義儲存技術之上,所以當 vSAN 運作架構成型後 vSphere 管理人員若需要啟用 vSAN iSCSI 目標服務時非常簡單,並且同樣能夠以 vSAN 原有的「儲存原則」(Storage Policy),管控由 vSAN 所提供的 iSCSI LUN 儲存資源。此外,倘若運作環境中需要使用 iSCSI 的 CHAP 身分驗證機制時,那麼 vSAN iSCSI 目標也支援單向 CHAP 及雙向 CHAP 身分驗證機制。

圖 3、VMware vSAN 分散式 iSCSI Target 運作架構示意圖

啟用 iSCSI 目標服務
當 vSphere 管理人員需要啟用 vSAN iSCSI 目標服務時,請登入 vSphere Web Client 管理介面並點選叢集物件後,依序點選「Configure > Virtual SAN > General」項目,然後在 Virtual SAN iSCSI Target Service 組態設定區塊中按下「Edit」鈕,準備啟用 vSAN iSCSI 目標服務。

請在彈出的 Edit Virtual SAN iSCSI Target Service 視窗中,組態設定相關選項並在下拉式選單中選擇採用相關功能:
  • Enable Virtual SAN iSCSI target service: 請勾選此項目,以便啟用 vSAN iSCSI 目標服務。
  • Default iSCSI network: 透過下拉式選單指定屆時 vSAN iSCSI 目標服務,要採用哪個 VMkernel Port 進行 iSCSI 儲存流量傳輸作業。
  • Default TCP port: 指定 vSAN iSCSI 目標服務的連接埠號,請採用預設標準的 iSCSI 目標端連接埠號 3260 即可。
  • Default authentication: 透過下拉式選單指定 vSAN iSCSI 目標服務的身分驗證方式,預設值為 None 不啟用 CHAP 身分驗證機制,倘若需要的話 vSAN iSCSI 目標服務也支援單向 CHAP 及雙向 CHAP 身分驗證機制。
  • Storage policy for the home object: 透過下拉式選單指定 vSAN iSCSI 目標服務所要套用的 SPBM 儲存原則。
圖 4、啟用 vSAN iSCSI 目標服務功能及組態設定功能項目

建立 LUN 儲存資源
當 vSAN iSCSI 目標服務順利啟動後,接著便可以建立 iSCSI 目標及 LUN 儲存資源。請在 vSphere Web Client 管理介面中,依序點選「Configure > Virtual SAN > iSCSI Targets」項目後,在 Virtual SAN iSCSI Targets 組態設定區塊中按下「新增」鈕(綠色加號圖示),準備組態設定 vSAN iSCSI 目標及建立 LUN 儲存資源。

請在彈出的 New iSCSI Target 視窗中,組態設定相關選項並在下拉式選單中選擇採用相關功能:
  • Target IQN: 系統為 vSAN iSCSI 目標服務隨機產生的 iSCSI Target IQN。
  • Target alias: 管理人員可以為此 vSAN iSCSI 目標服務指定別名以利識別。
  • Target storage policy: 指定此 vSAN iSCSI 目標服務所要套用的 SPBM 儲存原則。
  • Network: 透過下拉式選單指定此 vSAN iSCSI 目標服務,要採用哪個 VMkernel Port 進行 iSCSI 儲存流量傳輸作業。
  • TCP port: 指定 vSAN iSCSI 目標服務的連接埠號,請採用預設的標準 iSCSI 目標端連接埠號 3260 即可。
  • Authentication: 透過下拉式選單指定此 vSAN iSCSI 目標服務的身分驗證方式,vSAN iSCSI 目標服務支援單向 CHAP 及雙向 CHAP 身分驗證機制,預設情況下請採用預設值 None 即可。
  • Add your first LUN to the iSCSI target(Optional): 請勾選此項目,以便建立及組態設定 LUN 儲存資源。
  • LUN ID: 指定此 LUN 儲存空間的 ID 數值。
  • LUN alias: 指定此 LUN 儲存空間的別名以利識別。
  • LUN storage policy: 指定此 LUN 儲存資源所要套用的 SPBM 儲存原則。
  • LUN size: 指定此 LUN 儲存資源的空間大小。
圖 5、組態設定 vSAN iSCSI 目標及 LUN 儲存資源

新增 iSCSI 啟動器存取清單
順利建立 LUN 儲存資源之後,在 Target Details 組態設定區塊中便會看到剛才所建立的 LUN 儲存資源資訊。最後,請在同組態設定區塊中切換到「Allowed Initiators」頁籤後按下「新增」鈕(綠色加號圖示),新增只有哪些 iSCSI 啟動器能夠存取此 vSAN iSCSI 目標所提供的 LUN 儲存資源。

圖 6、組態設定哪些 iSCSI 啟動器能夠存取 vSAN iSCSI 目標所提供的 LUN 儲存資源

現在,只要在允許存取 LUN 儲存資源清單中的 iSCSI 啟動器,便可以透過 TCP/IP 乙太網路順利存取由 vSAN iSCSI 目標所提供的 LUN 儲存資源。值得注意的是,根據 VMware 官方的最佳作法建議,倘若只是要運作 VM 虛擬主機的話,應該保持以原本的 VMFS 檔案系統來運作 VM 虛擬主機即可,倘若是要運作如 MSCS 微軟容錯移轉叢集或 Oracle RAC……等服務,並且規劃使用 IP-SAN(iSCSI)運作架構時才建議使用 vSAN iSCSI 目標服務。

在 vSAN iSCSI 目標服務容錯移轉的部分,因為 vSAN iSCSI 目標服務是完全整合於 vSAN 分散式運作架構,所以當 iSCSI 啟動器端連線時便會連接到 vSAN 目標端的「擁有者」(Owner)節點主機,並且由該台 vSAN 節點主機回應 iSCSI 啟動器端存取負責管理的 LUN 儲存資源。

倘若,原本負責 vSAN iSCSI 目標端擁有者的節點主機突然發生故障事件時,那麼便會由 vSAN 叢集中其它存活的節點主機接手服務,成為 vSAN iSCSI 目標端擁有者並且繼續服務 iSCSI 啟動器,而 iSCSI 啟動器便會連接至新的 vSAN iSCSI 目標端擁有者,繼續使用由 vSAN 叢集所提供的 LUN 儲存資源。

圖 7、vSAN iSCSI目標服務容錯移轉運作架構示意圖



2 台 vSAN Node 直接對接

事實上,在第 3 代 vSAN(vSAN 6.1)運作環境中,便已經支援「2 Node」的 vSAN 節點主機運作環境,也就是只要 2 台 vSAN 節點主機便能建構 vSAN 叢集,這樣的運作架構適用於企業及組織中分公司或小型運作環境時使用。然而這樣的 vSAN 運作架構雖然只有 2 台 vSAN 節點主機,卻仍需要配置 1 台昂貴的 10 Gbps 網路交換器,並且也僅用到該台 10 Gbps 網路交換器的 4 個連接埠而已,倘若考慮預防 SPOF 單點失敗情況的話,則需配置「2 台」10 Gbps 網路交換器,並且每台 10 Gbps 網路交換器只會用到 2 個連接埠而已,這對於建置分公司或小型 vSAN 運作規模的整體預算來說是項吃重的負擔。

現在,全新第 5 代 vSAN 6.5 運作環境中,原有 1 Gbps 負責 VM 虛擬主機網路傳輸的部分可繼續延用,然而原有 10 Gbps 負責 vSAN 節點主機資料同步的部分,正式支援 2 台 vSAN 節點主機透過「交叉式纜線」(Crossover Cables)的方式互相連接,無須再向過往舊版 vSAN 運作環境必須透過 10 Gbps 網路交換器。如此一來,建置分公司或小型 vSAN 運作環境時便無須再採購昂貴的 10 Gbps 網路交換器,因此能夠有效降低分公司或小型 vSAN 運作規模的整體預算,根據 VMware 官方分析調查的結果顯示可以有效降低約「20 %」的投資成本。

在組態設定部分,根據 VMware 官方的最佳作法建議,當在 vSAN 叢集當中的節點主機透過交叉式纜線互相連接之後,在 vSAN 節點主機網路流量規劃的部分,應該要將「vSAN 儲存流量」及「vMotion 遷移流量」分開在不同的 10 Gbps 纜線進行傳輸,以避免儲存或遷移流量互相干擾的情況發生,舉例來說,倘若 2 台 vSAN 節點主機正透過 vSAN 儲存流量網路大量同步資料狀態的情況下,此時又剛好以 vMotion 線上遷移機制大量遷移 VM 虛擬主機的話,那麼有可能會增加 10 Gbps 的網路延遲時間及工作負載。

因此,在 vSAN 節點主機網路流量規劃的部分,除了將儲存或遷移流量分開之外,也同時應設定為互相備援的組態配置以便故障情況發生時,能夠有另 1 個 10 Gbps 纜線進行網路流量的容錯移轉。

圖 8、2 台 vSAN 節點主機透過交叉式纜線連接後,網路流量規劃的組態配置示意圖

此外,在最新的 vSAN 6.5 版本開始,新增將「見證網路流量」(Witness Traffic)分離的功能,解決在 2 台 vSAN 節點主機上必須建立及維護靜態路由的組態設定,降低 vSAN 整體運作架構的複雜度,同時在安全性方面也得到改善,因為 vSAN 儲存網路流量與 WAN 見證網路流量得以完全分離。

因為,負責 vSAN 運作架構的見證虛擬設備不可以運作在 2 台 vSAN 節點主機上,同時一般來說 2 台 vSAN 節點主機的運作架構,通常是運作在企業及組織的分公司或遠端辦公室當中。倘若,分公司或遠端辦公室有透過 WAN 網路與主要辦公室連接時,那麼可以考慮將見證虛擬設備運作在主要辦公室當中,除了節省建置第 3 台 ESXi 主機以運作見證虛擬設備之外,將見證虛擬設備運作在主要辦公室以便統一進行管理。

圖 9、2 台 vSAN 節點主機及見證虛擬設備運作在主要辦公室運作架構示意圖



全功能 PowerCLI

在新版 vSAN 6.5 運作環境中,VMware 官方已經將 vSphere API 抽象化為簡單的 Cmdlet。因此,現在 vSphere 管理人員可以透過 VMware PowerCLI 的方式,以更快速且自動化的方式部署及管理 vSAN 運作環境:
  • 啟用重複資料刪除及壓縮機制。
  • 啟用 vSAN 效能服務。
  • 組態設定 vSAN 健康檢查服務。
  • 建立 All Flash 磁碟群組。
  • vSAN 故障網域管理。
  • 組態設定 vSAN 延伸叢集。
  • 為維護模式選擇正確的資料遷移選項。
  • 檢索儲存空間資訊。
圖 10、透過 VMware PowerCLI 管理 vSAN 運作環境示意圖



支援新世代硬碟 512e 進階格式

過去,舊有的儲存裝置(硬碟)都採用「512 Byte Sector」(又稱為 512n)格式,而新式儲存裝置「進階格式」(Advance Format,AF)則是採用「4,096 Byte Sector」(又稱為 4Kn)格式。現在,從 VMware vSphere 6.5 及vSAN 6.5 版本開始,只要配合最新的「VMFS 6」檔案系統便全面支援以「512e(512B Emulation)」的方式運作,也就是以 512e 模擬 4K 的方式運作配合實體硬碟特性增強整體運作效能。
請注意!! 採用舊版 vSAN 或 VMFS 檔案系統的話,不支援以 512e 的方式運作所以採用 512e 的儲存裝置時,可能會引發或造成潛在的運作效能問題。有關 512 / 4,096 Byte Sector 詳細資訊請參考 VMware KB 2091600

圖 11、vSAN 6.5 支援新式進階格式 512e 儲存裝置示意圖

簡單來說,「磁區大小」(Sector Size)是影響作業系統及 Hypervisor 虛擬化管理程序運作效能的關鍵,因為它是儲存裝置(硬碟)最底層 I/O 的基本單位。因此,新式 512e 與舊有 512n 相較之下,雖然新式 512e 邏輯磁區大小也是 512 Byte,但是實體磁區大小則是 4,096 Byte 這是二者間最大的不同,所以在資料的「讀取-修改-寫入」(Read-Modify-Write,RMW)行為上,新式的 512e 與舊有的 512n 相較之下,會減少許多在資料 RMW 行為時效能懲罰的部分。

雖然,原生 4Kn 不管在邏輯磁區大小或實體磁區大小都是 4,096 Byte,但是目前的情況為並非所有儲存裝置、作業系統及 Hypervisor 虛擬化管理程序都完全支援。在下列表格中,為讀者們條列舊有 512n 及新式 512e 和原生 4Kn 在邏輯及實體磁區大小上的運作差異:

請注意!! 目前最新版本的 VMware vSphere ESXi 6.5 及 vSAN 6.5 運作環境中,仍尚未支援原生 4K 儲存裝置。
在目前儲存裝置市場中,支援新式進階格式 512e 的儲存裝置空間從 300 GB 到 10 TB 都有,並且通過 VMware vSAN 6.5 版本硬體認證的 512e 硬碟約有 230 個型號,不同 OEM 硬碟供應商所通過的數量不定。建議在使用及建置前應向硬碟供應商再次確認,所使用的硬碟是否支援新式進階格式 512e,以確保屆時建置的 VMware vSAN 6.5 運作效能及穩定性。

圖 12、各家 OEM 廠商通過 VMware vSAN 6.5 版本硬體認證的 512e 硬碟統計圖



全版本支援 All Flash

雖然,VMware vSAN 從第 2 代 vSAN 6.0 版本開始便支援 All Flash 運作架構,然而在過去的 vSAN 軟體授權版本當中,至少要採用「進階版或企業版」的 vSAN 軟體授權才能夠使用 All Flash 的運作架構及特色功能。

現在,最新的 VMware vSAN 6.5 版本當中,不管採用哪種 vSAN 軟體授權版本皆支援使用 All Flash 運作架構。因此,即便是由 2 台 vSAN 節點主機所建構的小型 vSAN 運作環境,也能夠使用 All Flash 的硬體運作架構,為需要高 IOPS 儲存效能的分公司或小型 vSAN 環境提供解決方案。

值得注意的是,雖然開放「標準版」及「ROBO 版」支援採用 All Flash 硬體架構來建立 vSAN 運作環境,但是在 All Flash 運作架構中進階特色功能,例如,「重複資料刪除及壓縮」、「RAID5/6 Erasure Conding」特色功能,仍需要採用「進階版或企業版」vSAN 軟體授權才能夠使用。

此外,如果要讓建置的 vSAN 運作架構支援「延伸叢集」或「IOPS 儲存效能管控」特色功能時,那麼只能採用「企業版」的 vSAN 軟體授權才能夠使用這 2 項進階功能特色。

圖 13、VMware vSAN 6.5 軟體授權可使用特色功能示意圖





結語

透過本文的說明及實作相信讀者已經了解,在第 5 代最新 vSAN 6.5 版本當中有哪些特色功能,能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 SDS 軟體定義儲存運作環境。

同時,對於企業及組織的分公司或小型企業運作環境來說,以往在建立虛擬化環境時令人困擾的初期建置成本問題,在新版 vSAN 6.5 當中透過交叉式纜線的方式解決僅 2 台 vSAN 節點主機,就必須採購昂貴 10Gbps 網路交換器的問題。

網管人雜誌

本文刊載於 網管人雜誌第 133 期 - 2017 年 2 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。





文章目錄

前言
實戰 Hyper-V 巢狀式虛擬化
          Guest Hypervisor 安裝 Hyper-V 角色
          Guest Hypervisor 啟用 MAC 位址變更機制
          Guest Hypervisor 啟用 NAT 機制
          Nested VM 再生 Nested VM?
結語





前言

在伺服器虛擬化運作環境中,談到「巢狀式虛擬化」(Nested Virtualization)的運作環境時,大家通常都會想到 VMware vSphere 虛擬化解決方案。沒錯,在過去的 Hyper-V 虛擬化平台當中,要建構出「巢狀式虛擬化」的運作環境,確實非常困難並且難以達成的。現在,透過最新發行的 Windows Server 2016 雲端作業系統,所建構的 Hyper-V 虛擬化平台便能原生內建支援「巢狀式虛擬化」運作機制。
事實上,從 Windows Server 2016技術預覽版本 4 的「10565」組建號碼開始,便原生內建支援巢狀式虛擬化機制。

簡單來說,在過去舊版 Hyper-V 虛擬化平台運作架構中,最底層 Hyper-V Hypervisor 虛擬化管理程序,將會完全管控「虛擬化擴充功能」(Virtualization Extensions)的部分,也就是如圖 1 所示中「橘色箭頭」的部分。同時,Hyper-V Hypervisor 並不會將底層硬體輔助虛擬化功能,傳遞給運作於上層的客體作業系統,所以在舊版的 Hyper-V 虛擬化平台上很難實作出巢狀式虛擬化的運作環境。

圖 1、舊版 Hyper-V 虛擬化平台運作架構(不支援巢狀式虛擬化)


現在,透過最新 Windows Server 2016 雲端作業系統所建置的 Hyper-V 虛擬化平台當中,Hyper-V Hypervisor 虛擬化管理程序,已經可以順利將「虛擬化擴充功能」也就是底層硬體輔助虛擬化技術,傳遞給 Hyper-V 虛擬化平台上運作的客體作業系統了。

因此,當 Hyper-V 虛擬化平台上運作的客體作業系統為 Windows Server 2016 時,因為能夠順利接收到由底層所傳遞過來的硬體輔助虛擬化技術,所以便能啟用 Hyper-V 虛擬化功能並建立 VM 虛擬主機,達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
事實上,當客體作業系統運作 Windows 10 時,也能順利接收底層所傳遞過來的硬體輔助虛擬化技術,達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
圖 2、新版 Hyper-V 虛擬化平台運作架構(支援巢狀式虛擬化)

此外,一般對於巢狀式虛擬化技術的認知,僅止於建立測試研發環境上具備方便度而已,通常在線上營運的運作環境中並不會使用到巢狀式虛擬化技術。然而,在新版 Windows Server 2016 中 Hyper-V 虛擬化平台支援巢狀式虛擬化技術,並非只是為了達到 Nested VM 這種 VM 虛擬主機再生出 VM 虛擬主機,方便建立測試研發環境的目的而已。

在新一代 Windows Server 2016 雲端作業系統運作環境中,同時支援 Windows Containers 及 Hyper-V Container 這 2 種容器技術運作環境,其中「Hyper-V Container」容器技術運作環境的部分,便是在 VM 虛擬主機中再運作 Container 容器環境,達到更進一步的容器技術隔離運作環境。事實上,Hyper-V Container 的容器技術運作環境,便是透過 Hyper-V 巢狀式虛擬化技術所達成的。

圖 3、Windows Containers 與 Hyper-V Containers 運作架構示意圖





實戰 Hyper-V 巢狀式虛擬化

在開始實作 Hyper-V 巢狀式虛擬化機制之前,我們先了解建立 Hyper-V 巢狀式虛擬化的運作環境需求以及相關限制:

Hyper-V 主機(Hyper-V Hypervisor)
  • 運作 Hyper-V 巢狀式虛擬化技術的實體伺服器,在 CPU 處理器硬體輔助虛擬化技術的部分,必須採用支援「Intel VT-x 及 EPT」虛擬化擴充功能的 CPU 處理器才行。
  • 作業系統的部分,必須採用 Windows 10 年度更新版(Enterprise、Professional、Education)或 Windows Server 2016(Standard、Datacenter)等版本。

VM 虛擬主機(Guest Hypervisor)
  • 必須採用「第 2 世代」以及新版「8.0」的 VM 虛擬主機格式。
  • 作業系統的部分,必須採用 Windows 10年度更新版(Enterprise、Professional、Education)或 Windows Server 2016(Standard、Datacenter)等版本。
  • 必須「啟用」vCPU 虛擬處理器的虛擬化擴充功能,才能夠順利接收由底層 Hyper-V 虛擬化平台所傳遞的硬體輔助虛擬化技術。
  • 建議「停用」動態記憶體功能。雖然,啟用動態記憶體功能仍然不影響 VM 虛擬主機的運作,但倘若嘗試調整記憶體空間大小時(也就是執行 Runtime Memory Resize 的動作),將會發生失敗的情況。
  • 必須「啟用」MAC Address Spoofing 機制,或建立具備 NAT 功能的 vSwitch 虛擬網路交換器,否則屆時建立的 Nested VM 虛擬主機,將會發生無法與實體網路環境連通或連線至網際網路的情況。

上述 Hyper-V 巢狀式虛擬化的運作環境需求僅為大方向的重點規劃要項,下列將針對 Hyper-V 實體伺服器在 CPU 處理器及記憶體方面的選擇及規劃給予建議。

CPU 處理器的選擇
事實上,從 Windows Server 2008 R2 作業系統版本開始,Windows Server 便僅提供 64 位元的作業系統版本,當然 Windows Server 2012 和 2012 R2 以及新世代的雲端作業系統 Windows Server 2016 也不例外。因此,在選擇原生 64 位元的 CPU 處理器時,請選擇具備更多「定址空間」及具備大容量「L2 / L3 快取」空間的 CPU 處理器,甚至較新世代的處理器如 Intel Haswell、Broadwell 更支援 L4 快取,當擔任 Hyper-V 角色的硬體伺服器配置這樣的 CPU 處理器時,將能夠讓 Hyper-V 伺服器擁有更強大的運算資源。
請注意,雖然從 Windows Server 2008 R2 作業系統版本開始,Windows Server 便不再發行 32 位元版本,但是在原生 64 位元的 Windows Server 環境中運作 32 位元的應用程式,並不會有任何問題產生。

至於,在選擇 CPU 處理器時,應該選擇追求「高時脈」以得到高效能的運算速度,或者是著重在選擇「多核心」以達到平行運算,則應該視屆時運作於 Hyper-V 虛擬化平台上 VM 虛擬主機當中的工作負載類型而定,舉例來說,倘若 VM 虛擬主機當中的應用程式是屬於「單線程」(Single-Thread)類型的話,那麼便應該選擇採用「高時脈」類型的 CPU 處理器,倘若 VM 虛擬主機當中的應用程式是屬於「多線程」(Multi-Thread)類型的話,那麼便應該選擇採用「多核心」類型的 CPU 處理器,如此一來才能夠讓 VM 虛擬主機當中的工作負載得到最佳化的運算效能。

此外,在選擇 CPU 處理器硬體輔助虛擬化技術的部分,目前主流的 CPU 處理器皆已經支援第一代硬體輔助虛擬化技術(例如,Intel VT-x 或 AMD-V),以及第二代硬體輔助虛擬化技術或稱第二層位址轉譯 SLAT(例如,Intel EPT 或 AMD NPT),以便降低因為虛擬化技術所造成的硬體資源耗損。
請注意,在 Windows Server 2016 所建構的 Hyper-V 虛擬化平台中,倘若要建立 Hyper-V 巢狀式虛擬化運作環境的話,目前僅支援 Intel 處理器的硬體輔助虛擬化技術「Intel VT-x 及 EPT」,尚未支援採用 AMD 處理器「AMD-V 及 NPT」虛擬化擴充功能建立 Hyper-V 巢狀式虛擬化運作環境。

Memory 記憶體的選擇
在建構 Hyper-V 虛擬化平台的硬體伺服器上,針對實體記憶體的部分當然是越多越好。因為,當實體伺服器記憶體空間不足時,便會迫使 Windows Server 透過硬碟空間產生「分頁檔案」,以便嘗試渡過記憶體空間不敷使用的情況,此時將會直接影響並降低實體伺服器的運作效能。

倘若,因為 IT 預算的關係在短期之內真的無法購足實體記憶體時,則會建議應該依照如下準則來優化分頁檔案的運作效率:

  • 請將分頁檔案產生在實體隔離的硬碟環境,也就是不要跟作業系統或應用程式共用同一個硬碟空間。
  • 雖然將分頁檔案建立在具備容錯機制的硬碟空間中(例如,RAID 1),可能會導致更慢的儲存 I/O 效能,但是倘若將分頁檔案存放於「未」具備容錯機制的硬碟空間時,雖然會獲得較快的儲存 I/O 效能,然而一旦該硬碟發生災難事件時可能會導致「系統崩潰」的情況發生。
  • 請保持分頁檔案隔離原則,不要將「多個」分頁檔案同時建立在同一個硬碟內。

此外,應該要選擇支援 NUMA 架構的實體伺服器,以避免 CPU 處理器與記憶體之間的資料存取行為,因為匯流排頻寬不足的問題而產生存取瓶頸。值得注意的是,當採用支援 NUMA 架構的實體伺服器時,必須要注意實體記憶體空間必須平均分配到不同的 NUMA 節點,以避免 CPU 處理器仍需跨越 NUMA 節點進行記憶體空間的存取。

了解,上述 Hyper-V 伺服器在 CPU 處理器及記憶體的選擇規劃,以及實作 Hyper-V 巢狀式虛擬化的運作環境需求及限制等準則之後,接著便可以開始實作 Nested VM 巢狀式虛擬化運作環境。



Guest Hypervisor 安裝 Hyper-V 角色

首先,我們在實體伺服器所建構的 Hyper-V 虛擬化平台中,建立擔任 Guest Hypervisor 角色名稱為「WS2016-Outer」的 VM 虛擬主機,同時採用「第 2 世代」以及新版「8.0」的 VM 虛擬主機格式,在客體作業系統的部分則是採用 Windows Server 2016 DataCenter 版本。

圖 4、建立擔任 Guest Hypervisor 角色的 VM 虛擬主機

登入 WS2016-Outer 虛擬主機之後,我們可以直接開啟伺服器管理員並嘗試安裝 Hyper-V 伺服器角色,然而你會發現當你勾選「Hyper-V」伺服器角色項目後,在系統執行檢查程序完畢時將會出現「無法安裝 Hyper-V:處理器沒有必要的虛擬化功能」的錯誤訊息。

圖 5、擔任 Guest Hypervisor 角色的 VM 虛擬主機,無法順利安裝 Hyper-V 伺服器角色

此時,我們可以透過 Coreinfo 虛擬化擴充功能檢查工具,下載後解壓縮無須安裝直接在開啟的命令提示字元視窗中鍵入「coreinfo.exe -v」指令,便可以檢查目前在 WS2016-Outer 虛擬主機中,是否擁有 Intel VT-x 及 EPT 硬體輔助虛擬化功能。如圖 6 所示,可以看到在檢查的顯示結果中,目前擔任 Guest Hypervisor 角色的虛擬主機並沒有任何的硬體輔助虛擬化功能,所以才會導致無法順利安裝 Hyper-V 伺服器角色。

圖 6、目前擔任 Guest Hypervisor 角色的虛擬主機並沒有任何硬體輔助虛擬化功能

因此,我們必須為擔任「Guest Hypervisor」角色的 VM 虛擬主機,執行「啟用」vCPU 虛擬處理器虛擬化擴充功能的動作,如此一來 VM 虛擬主機才能順利接收,由底層 Hyper-V 虛擬化平台所傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。

值得注意的是,擔任 Guest Hypervisor 角色的 VM 虛擬主機必須為「關機(Power Off)」狀態,才能透過 PowerShell 順利執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作,倘若 VM 虛擬主機為「運作中(Power On)」狀態的話,那麼當你執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作時,將會得到 PowerShell 指令執行失敗的情況。

圖 7、VM 虛擬主機必須關機,否則啟用 vCPU 虛擬處理器虛擬化擴充功能的動作會失敗

順利將 WS2016-Outer 虛擬主機關機後,便可以執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作,並且於指令執行完畢後再次確認 VM 虛擬主機屬性中,「ExposeVirtualizationExtensions」的欄位值是否為「True」以便確認變更作業已經套用生效。

圖 8、確認 VM 虛擬主機是否啟用 vCPU 虛擬處理器虛擬化擴充功能

請將擔任 Guest Hypervisor 角色的 VM 虛擬主機重新開機並登入後,再次執行 Coreinfo 虛擬化擴充功能檢查作業。如圖 9 所示,可以看到在檢查的顯示結果中,擔任 Guest Hypervisor 角色的虛擬主機,已經順利接收到由底層 Hyper-V 虛擬化平台所傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。

圖 9、VM 虛擬主機,順利接收底層 Hyper-V 虛擬化平台傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化技術

此時,請開啟伺服器管理員並再次嘗試為 WS2016-Outer 虛擬主機,安裝 Hyper-V 伺服器角色時便可以發現能夠順利新增並安裝完成。

圖 10、順利為 WS2016-Outer 虛擬主機安裝 Hyper-V 伺服器角色



Guest Hypervisor 啟用 MAC 位址變更機制

當你順利為 WS2016-Outer 虛擬主機安裝 Hyper-V 伺服器角色,並且在 WS2016-Outer 虛擬主機中建立名稱為「WS2016-Inner」的虛擬主機後,此時你將會發現 WS2016-Inner 虛擬主機的網路組態設定雖然正確無誤,但是它卻無法順利與實體網路環境溝通或連接到網際網路?

主要原因在於,在 Hyper-V 巢狀式虛擬化運作架構中的 VM 虛擬主機(又稱為 Nested VM 虛擬主機),必須在上層 Guest Hypervisor 虛擬主機中,啟用「MAC 位址變更」(MAC Address Spoofing)功能,以便 Nested VM 虛擬主機的網路封包,能夠順利在 2 層(Hyper-V Hypervisor 及 Guest Hypervisor)虛擬網路交換器之間順利路由,才能夠與實體網路環境溝通或碰觸到網際網路。

因此,Hyper-V 主機的管理人員可以透過 PowerShell 指令,或者是 Hyper-V 管理員操作介面進行啟用 MAC 位址變更的動作。倘若,透過 PowerShell 指令進行組態設定的話,請在 Hyper-V 主機指定為「WS2016-Outer」虛擬主機開啟 MAC 位址變更功能,並於執行後再次確認 VM 虛擬主機屬性中「MacAddressSpoofing」欄位值為「On」,以便確認變更作業已經套用生效。

圖 11、透過 PowerShell 指令,為 Guest Hypervisor 啟用 MAC 位址變更功能

或者,管理人員也可以開啟 Hyper-V 管理員操作介面,選擇 WS2016-Outer 虛擬主機後依序點選「設定 > 網路介面卡 > 進階功能」項目,然後勾選「啟用 MAC 位址變更」選項即可。

圖 12、透過 Hyper-V 管理員,為 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能

完成 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能的組態設定後,便可以發現「WS2016-Inner」Nested VM 虛擬主機,已經可以順利通過 WS2016-Outer 這台 Guest Hypervisor 的 vSwitch 虛擬網路交換器,以及 HV01 這台 Hyper-V 實體伺服器的 vSwitch 虛擬網路交換器進行路由,進而與實體網路環境溝通或碰觸到網際網路。

圖 13、Nested VM 虛擬主機,順利在 2 層 vSwitch 虛擬網路交換器之間順利路由



Guest Hypervisor 啟用 NAT 機制

當 Guest Hypervisor 虛擬主機,運作在你能掌控的 Hyper-V 虛擬化平台時,便可以透過上述 PowerShell 指令或 Hyper-V 管理員,幫 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能,進而讓 Nested VM 虛擬主機能夠與實體網路環境溝通或碰觸到網際網路。

倘若,Guest Hypervisor 虛擬主機運作在你「無法」掌控的 Hyper-V 虛擬化平台時,例如,Microsoft Azure 公有雲服務。或者,其它並非採用 Hyper-V 虛擬化解決方案的虛擬化平台,例如,Amazon AWS 公有雲服務 、VMware vSphere 虛擬化解決方案……等。

此時,便需要在 Guest Hypervisor 虛擬主機端,建立具備 NAT 功能的 vSwitch 虛擬網路交換器,以便屆時在 Guest Hypervisor 中所產生的 Nested VM 虛擬主機,能夠順利與實體網路環境溝通或碰觸到網際網路。

請在 Guest Hypervisor 虛擬主機端,執行 PowerShell 指令或透過 Hyper-V 管理員操作介面,建立類型為「內部」(Internal)的 vSwitch 虛擬網路交換器。如圖 14 所示,我們透過「New-VMSwitch」的 PowerShell 指令建立名稱為「VM-NAT」,並且類型為內部的 vSwitch 虛擬網路交換器,然後透過 Hyper-V 管理員操作介面驗證是否建立完成。

圖 14、建立屆時 Nested VM 虛擬主機對外溝通連線的 vSwitch 虛擬網路交換器

接著,再次執行「New-NetNat」的 PowerShell 指令,建立屆時用於 NAT 運作機制中的 IP 網段,在本文實作環境中建立名稱為「LocalNAT」,並且採用「192.168.100.0/24」IP 網段的 NAT 網路環境。

圖 15、建立屆時用於 NAT 運作機制中的 IP 網段網路環境

最後,再為剛才所建立名稱為 VM-NAT 的虛擬網路交換器指定所要採用的 IP 位址即可。在本文實作環境中,我們指派 VM-NAT 虛擬網路交換器採用「192.168.100.254」的 IP 位址,屆時 Nested VM 虛擬主機在設定網路組態時,便需要將預設閘道的 IP 位址設定為 192.168.100.254 後,才能順利與實體網路環境溝通或碰觸到網際網路。

圖 16、為 VM-NAT 虛擬網路交換器指派使用 192.168.100.254 的 IP 位址

在 Guest Hypervisor 虛擬主機端進行 NAT 組態設定的動作執行完畢後,首先請為 Nested VM 虛擬主機調整該網路介面卡所連接的 vSwitch 虛擬網路交換器,在本文實作環境中便是將 WS2016-Inner 虛擬主機的網路介面卡,改為連接至剛才我們所建立的 VM-NAT 虛擬網路交換器,然後在設定網路組態的部分則是指派為 192.168.100.10,當然最重要的是預設閘道必須指向至 192.168.100.254 的 IP 位址。此時,Nested VM 虛擬主機便可以順利透過 WS2016-Outer 虛擬主機,也就是 Guest Hypervisor 的 VM-NAT 虛擬網路交換器進行 NAT 進而能夠碰觸到網際網路。

圖 17、Nested VM 虛擬主機,透過具備 NAT 功能的 vSwitch 虛擬網路交換器碰觸到網際網路



Nested VM 再生 Nested VM?

至此,我們已經順利透過新一代 Windows Server 2016 雲端作業系統,原生內建的 Hyper-V 巢狀式虛擬化技術建立 Nested VM 運作環境,讓管理人員只要透過 1 台硬體伺服器,便能建立出「Hyper-V Host > Guest Hypervisor > Nested VM」的 Hyper-V 巢狀式虛擬化運作環境。

那麼,有沒有可能更進一步在 Nested VM 虛擬主機中再生出 Nested VM 虛擬主機?答案是可行的,只要遵循前述所條列的 Hyper-V 巢狀式虛擬化技術運作環境需求及限制,便可以讓 Nested VM 再生出 Nested VM 虛擬主機。

因為實作方式與前述的操作步驟相同所以便不再贅述,如圖 18 所示我們總共建立出 4 層的 Hyper-V 巢狀式虛擬化技術運作環境:

第 1 層(HV01):Hyper-V Hypervisor 實體伺服器。
     第 2 層(WS2016-Outer):VM 虛擬主機並擔任 Guest Hypervisor。
          第 3 層(WS2016-Inner):Nested VM 虛擬主機並再擔任 Guest Hypervisor。
               第 4 層(WS2016-Innermost):由 Nested VM 再生出的 Nested VM 虛擬主機。

圖 18、由 Nested VM 再生出的 Nested VM 虛擬主機





結語

透過本文的說明及實作演練,相信讀者已經完全了解新一代 Windows Server 2016 雲端作業系統中,原生內建的 Hyper-V 巢狀式虛擬化的強大功能,善用此機制相信能夠有效幫助管理人員只要利用少量的實體伺服器,就能夠建構出複雜的測試研發環境有效減少過往建立測試研發環境時的困擾。

網管人雜誌

本文刊載於 網管人雜誌第 132 期 - 2017 年 1 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。





文章目錄

前言
vCenter Server 功能再進化
安全性
          vMotion 流量加密
高可用性機制
          DRS 自動負載平衡機制再增強
儲存功能增強
          支援 4K Native Drives in 512e 運作模式
          預設採用 SE Sparse 虛擬磁碟格式
          LUN 可擴充性
          CBRC 讀取快取空間支援至 32 GB
網路功能增強
          增強 Nested ESXi 運作效能
          VMkernel Port 可配置不同預設閘道
實戰 VM 虛擬主機加密機制
          組態設定金鑰管理伺服器
          建立加密原則
          VM 虛擬主機套用加密原則
結語





前言

在 VMware VMworld 2016 大會上,由 VMware 執行長 Pat Gelsinger 正式發表 SDDC 軟體定義資料中心願景中最要的運作元件 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出,並且在日前 2016 年 11 月 15 日時 VMware 官方正式宣佈 vSphere 6.5 新版發佈,同時提供相關新版產品映像檔的下載。

圖 1、新版 VMware vSphere 6.5 打造 SDDC 軟體定義資料中心願景

當然,每次只要新版本的發佈相關硬體資源支援度便會再次提升。在下列表格當中,我們條列出目前許多企業及組織仍使用的主流版本 vSphere 5.5 及 vSphere 6.0,以及最新版本 vSphere 6.5 在支援度上有哪些再提升的部分(詳細資訊請參考 VMware KB 1003497)。

請注意,倘若企業或組織仍使用舊版 vSphere ESXi 5.0 / 5.1 以及 vCenter Server 5.0 / 5.1 版本的話,那麼已經於「2016 年 8 月 24 日」進入「終止支援(End Of Support,EOS)」,因此企業或組織應儘快進行版本升級的動作。





vCenter Server 功能再進化

拜雲端運算風潮所賜,在企業或組織當中早已經建立 vCenter Server 管理平台。或許,IT 管理人員可能希望嘗試使用 vCSA,但是目前所管理的 vSphere 虛擬化運作環境中,已經採用安裝於 Windows Server 作業系統的 vCenter Server。事實上,VMware 官方早已經推出 vCenter Server 平台遷移工具,最新的遷移版本為 vCenter Server Migration Tool: vSphere 6.0 Update 2m,同時在新版遷移工具中支援遷移的目標對象為「Windows vCenter Server 5.5、6.0」。

因此,即便企業及組織已經建立最新的 Windows vCenter Server 6.0,仍可以透過 vCenter Server遷移工具將 vCenter Server 管理平台遷移至最新的 vCSA 6.5 版本中。此外,新版的 vCenter Server 遷移工具支援更細緻的遷移選項:

  • Configuration。
  • Configuration、Events、Tasks。
  • Configuration、Events、Tasks、Performance Metrics。


同時,在最新版本的 vCSA 6.5 當中,VMware 官方為 vCSA 打造原生 HA(High Availability)機制,這個 HA 機制是由「Active、Passive、Witness」成員節點所組成。當 vCenter HA Cluster 某個成員節點發生災難事件時(例如,擔任 Active 角色的成員節點主機發生硬體故障),便會觸發 vCenter HA 機制。目前,vCSA HA 機制的 RTO 預計為「5 分鐘」,當然實際上必須視底層硬體資源的工作負載情況而定。

圖 2、vCenter HA 及 PSC HA 協同負載平衡運作架構示意圖





安全性

雖然,加密 VM 虛擬主機的機敏資料是多年來一直在進行的事情,但每項解決方案都有不足或造成困擾的部分。在最新 vSphere 6.5 虛擬化平台中希望能夠解決這個問題,加密的對象將針對「VM Home Files(VMX,Snapshot…等)」以及「VMDK 虛擬磁碟」。同時,加密的動作是當「資料 I/O」從 VM 虛擬主機的 vHBA 虛擬磁碟控制器出來時,再傳送到「Kernel Storage Layer」之前就會進行加密的動作。



vMotion 流量加密

針對 vMotion 傳輸流量進行加密的要求其實已經很長一段時間,現在開始於新一代 vSphere 6.5 虛擬化平台中正式提供此功能。此外,在這個版本中的「vMotion Encryption」並非加密網路所以無須管理憑證或其它網路組態設定。

加密是針對「每台 VM 虛擬主機」層級,當 VM 虛擬主機啟用 vMotion Encryption 機制後,倘若針對該 VM 虛擬主機進行 vMotion 線上遷移作業時,vCenter Server 將會「隨機產生」(Randomly Generated)1 個「One time 256-bit Key」(請注意,此加密金鑰並不會採用 vCenter Server Key Manager 產生)。

除了隨機 256-bit 加密金鑰之外還會搭配「64-bit 隨機數」,所以當進行 VM 虛擬主機 vMotion 線上遷移作業時,將會打包「256-bit Key 加上 64-bit 隨機數」在「2 台 ESXi 主機」之間,以確保兩端之間通訊所傳輸的資料無法被惡意人士所複製。

在組態設定部分提供下列 3 種 vMotion Encryption 設定值:

  • Disabled: 停用 vMotion Encryption 機制。
  • Opportunistic: 預設值,當來源端及目的端 ESXi 主機都支援 vMotion Encryption 機制時,在執行 vSphere vMotion 時將會加密傳輸流量,倘若有任何一方不支援便不會加密 vSphere vMotion 傳輸流量。
  • Required: 來源端及目的端 ESXi 主機都必須支援 vMotion Encryption 機制,倘若有任何一方不支援便無法順利執行 vSphere vMotion 線上遷移機制。

圖 3、為 VM 虛擬主機組態設定加密 vSphere vMotion 遷移流量





高可用性機制

在新版 vSphere 6.5 環境當中增加「vSphere HA Orchestrated Restart」機制,當 ESXi 主機發生故障損壞事件觸發 vSphere HA 高可用性機制時,能夠依照管理人員指定的啟動順序,依序將 VM 虛擬主機啟動以便應用程式能夠正常重新啟動。

圖 4、觸發 vSphere HA 高可用性機制時,依序啟動 VM 以便應用程式能夠正常重新啟動



DRS 自動負載平衡機制再增強

在過去的 vSphere 運作環境中,在 DRS 自動化負載平衡演算法機制是採用「標準差模型」(Standard Deviation Model)的方式運作。現在,新版 vSphere 6.5 運作環境中除了原本標準差模型運作之外,更加入「成對計算」(Pairwise Calculation)機制,以便更容易在 VMware Cluster 內計算 ESXi 主機及 VM 虛擬主機的工作負載,達到更佳的負載平衡機制。

同時,在 vSphere DRS 的組態設定內容中也增加 3 個最常使用的進階功能,以便管理人員能夠更進一步的管控 vSphere DRS 負載平衡機制:

  • 均勻分佈虛擬機器: 啟用後,將盡力在 VMware Cluster 的 ESXi 成員主機之間,讓 VM 虛擬主機的工作負載能夠達到最大限度的負載平衡。
  • 已取用記憶體與作用中記憶體的對照: 啟用後,將以 Active Memory 25% 的記憶體空間當成主要指標,以便盡量避免 VMware Cluster 運作環境中發生 Memory 過度使用的情況。
  • CPU 過度分配: 在 VMware Cluster 層級中套用 vCPU: pCPU 的最大使用比率,一旦到達組態設定的比例後便無法啟動 VM 虛擬主機,有效避免許多 VM 虛擬主機同時啟動(例如,VDI 虛擬桌面環境),造成 CPU 資源嚴重超用的情況。

圖 5、vSphere DRS 組態設定內容中新增 3 個最常使用的進階功能





儲存功能增強

在目前主流的 vSphere 5.5 及 6.0 版本當中,所採用的 VMFS 檔案系統版本為「VMFS 5」。在最新 VMware vSphere 6.5 版本當中,可以使用 VMFS 6 新版檔案系統,下列便是 VMFS 6 檔案系統的新增功能項目:

  • 支援 4K Native Drives in 512e 運作模式。
  • 預設採用 SE Sparse 格式的虛擬磁碟,以便自動化執行空間回收機制。
  • LUN 可擴充性最大支援至 512 個 LUN 及 2,000 路徑。
  • CBRC 讀取快取空間由舊版的最大 2 GB 提升為 32 GB。

圖 6、新版 vSphere 6.5 運作環境中,支援最新 VMFS 6 檔案系統



支援 4K Native Drives in 512e 運作模式

簡單來說,新一代的新式硬碟(2011 年 1 月起出廠的硬碟)採用的進階格式為「4K Byte Sector」而非舊有的「512 Byte Sector」。因此,從 vSphere 6.5 版本開始支援由 512e 模擬 4K 的方式運作,以便配合實體硬碟特性增強整體運作效能。值得注意的是 Virtual SAN 6.5 目前仍僅支援 512e 運作模式,相信後續版本便有可能全面支援 4K Byte Sector,有關 4K / 512 Byte Sector 的相關資訊請參考 VMware KB 2091600

圖 7、4K / 512 Byte Sector 資料讀取及寫入示意圖



預設採用 SE Sparse 虛擬磁碟格式

在過去舊版 vSphere 運作環境中,只有透過 VMware Horizon「連結複製」(Linked Clone)技術,所部署的 VM 虛擬主機虛擬磁碟能夠採用「SE Sparse(Space-Efficient Sparse Virtual Disks)」虛擬磁碟格式,以便達成 VM 虛擬主機中因為使用者建立資料又刪除資料時產生的空白資料區塊能夠自動回收的目的。倘若,在伺服器虛擬化環境中則必須管理人員,手動執行相關指令才能執行空白資料區塊佔用空間回收的動作。

現在,新版 vSphere 6.5 運作環境中當採用 VMFS 6 檔案系統後,預設情況下便採用 SE Sparse 虛擬磁碟格式,讓採用「精簡佈建」(Thin Provision)的 VM 虛擬主機,能夠在使用者刪除 VM 虛擬主機內相關資料後,自動執行空白資料區塊佔用空間回收的動作。

圖 8、SE Sparse 儲存空間自動回收運作示意圖



LUN 可擴充性

在目前 vSphere 6.0 版本運作環境中,儲存資源 LUN 的最大支援數量為「256」路徑為「1,024」,雖然這樣的儲存資源支援度已經可以因應非常大的運作規模。但是,在新版 vSphere 6.5 運作環境中,將儲存資源 LUN 的最大支援數量再次推升至「512」路徑為「2,000」。



CBRC 讀取快取空間支援至 32 GB

早從 VMware vSphere ESXi 5.0 版本開始,便原生支援 ESXi Host Caching 機制「CBRC(Content-Based Read Cache)」,此快取機制是從實體伺服器中切出一塊實體記憶體空間(最大支援至 2 GB),以便降低 ESXi 儲存資源的 Read I/O Requests 工作負載。

現在,最新版本 vSphere 6.5 運作環境中,CBRC 讀取快取空間最大支援至「32 GB」,透過實體記憶體快速存取的特性,有效讓 ESXi 儲存資源的 Read I/O Requests 工作負載降至更低。(有關 CBRC 讀取快取的詳細運作機制,請參考網管人雜誌第 94 期「設定 VMware 內建快取機制,加速虛擬桌面環境效能」文章內容。)

圖 9、新版 vSphere 6.5 運作環境中 CBRC 讀取快取空間最大支援至 32 GB





網路功能增強

在新版 vSphere 6.5 當中網路功能增強的部分,例如,VMkernel 能夠支援 2M Page、VMKAPI 鎖定功能增強以便提升 vDS 分散式交換器可擴展性、健康狀態檢查機制升級……等。同時,除了運作效能提升外對於管理功能也同步增強,舉例來說,在過去舊版 vSphere 運作環境中當需要為 VM 虛擬主機配置 SR-IOV 網路卡時,必須管理人員介入手動為指定的 VM 虛擬主機配置 SR-IOV 網路卡,現在則可以在 VM 虛擬主機中如同增加其它虛擬裝置一樣新增 SR-IOV 網路卡。

圖 10、為 VM 虛擬主機組態配置 SR-IOV 網路卡



增強 Nested ESXi 運作效能

在過去 vSphere 舊版運作環境中,虛擬網路交換器 vSwitch 的設計是每個 vNIC 連接埠僅支援「單一 Unicast MAC 位址」,所以在 Nested ESXi 運作環境中必須「啟用」Promiscuous Mode,那麼 Nested ESXi 的網路功能才能順利運作。但是,此舉也同時造成 vSwitch 將所有流量都傳送到 Nested ESXi 主機中,這會導致不必要的網路封包也都傳送至 Nested ESXi 主機,造成「CPU 高使用率」及「網路效能低落」的情況。

現在,在新版 vSphere 6.5 運作環境中 vSwitch 具備 MAC 學習功能,所以僅會轉送相關的網路封包給 Nested ESXi 主機,因此可以明顯提升 Nested ESXi 主機運作效能。

圖 11、在建立客體作業系統時選擇版本 VMware ESXi 6.5 以便建立 Nested ESXi



VMkernel Port 可配置不同預設閘道

在過去舊版 vSphere 運作環境中,vSphere vMotion、vSphere DRS、iSCSI……等進階服務只能共同使用「單一預設閘道」。雖然,可以透過額外新增「靜態路由」的方式,解決不同服務採用不同預設閘道的問題,但是過多的靜態路由會造成管理上的麻煩。

現在,新版 vSphere 6.5 運作環境中,可以針對不同的 VMkernel Port 指定採用「不同預設閘道」。因此,管理人員無須再為不同服務必須採用不同預設閘道及額外新增靜態路由而苦惱,同時也因為無須再額外新增靜態路由同步讓 ESXi 主機的運作效能提升。





實戰 VM 虛擬主機加密機制

那麼就讓我們來實戰 VM 虛擬主機加密機制的組態設定部分吧。簡單來說,當加密機制運作環境準備妥當之後,只需要進行下列 4 項操作步驟即可為 VM 虛擬主機建立加密機制,以便保護 VM 虛擬主機當中的機敏資料:

  • 將金鑰管理伺服器加入至 vCenter Server 管理平台當中。
  • 建立加密原則。
  • 為現有 VM 虛擬主機套用加密原則,或為新建立的 VM 虛擬主機啟用加密原則。
  • 為套用加密機制的 VM 虛擬主機進行解密。




組態設定金鑰管理伺服器

首先,請透過 vSphere Web Client 管理工具登入 vCenter Server 管理平台後,依序點選「首頁 >  vCenter 詳細目錄清單 > 資源 > vCenter Server」,接著在右方管理介面中依序點選「管理 > 金鑰管理伺服器 > 新增伺服器」項目。

圖 12、準備新增金鑰管理伺服器並加入 vCenter Server 管理平台

在彈出的新增 KMIP 伺服器視窗中,請依序在相關欄位填入運作環境資訊:

  • 金鑰伺服器叢集: 因為運作環境中尚未有任何金鑰管理伺服器,所以選擇預設值建立新叢集即可。
  • 叢集名稱: 請鍵入金鑰管理伺服器叢集名稱,此實作環境為 Key MGMT Server Cluster。
  • 伺服器別名: 請鍵入金鑰管理伺服器容易記憶的名稱,此實作環境為 KeyServer。
  • 伺服器位址: 請鍵入金鑰管理伺服器 FQDN 或 IP 位址,此實作環境為 kms.vsphere.weithenn.org。
  • 伺服器連接埠: 請鍵入金鑰管理伺服器服務連接埠號碼,此實作環境為預設的 5696。

圖 13、鍵入金鑰管理伺服器運作環境資訊

當 vCenter Server 順利與金鑰管理伺服器連線後,將會自動彈出信任憑證視窗請按下「Trust」鈕即可。順利新增金鑰管理伺服器後,請將這台金鑰管理伺服器設定為叢集中的預設值,請點選 Key MGMT Server Cluster 項目後按下「將叢集設定為預設值」,並於彈出的視窗中按下「是」鈕即可。

圖 14、將這台金鑰管理伺服器設定為叢集中的預設值

組態設定完畢後,便可以看到 Key MGMT Server Cluster 項目結尾多出「(預設值)」字樣。同時,請確認金鑰管理伺服器的「連線狀態」以及「憑證狀態」是否正常運作中。

圖 15、確認金鑰管理伺服器的「連線狀態」以及「憑證狀態」是否正常運作中



建立加密原則

請依序點選「首頁>原則和設定檔>虛擬機器儲存區原則>建立虛擬機器儲存區原則」。此時,將會彈出建立新的虛擬機器儲存區原則視窗,首先在名稱與說明頁面中請於名稱欄位鍵入此儲存加密原則的名稱(此實作環境中,我們鍵入的名稱為 VM Encryption Policy),在原則結構頁面中採用預設值即可。在一般規格頁面中,請勾選「使用虛擬機器存放區原則中的一般規則」項目後按下「新增元件」鈕後選擇「加密」項目。

圖 16、在虛擬機器儲存區原則中準備新增加密原則

此時,頁面中將出現「加密 > 自訂 > 提供者」項目,然後請在新增規格下拉式選單中選擇至「vmcrypt」項目,並於出現的 Allow I/O filters before encryption 欄位下拉式選單中保持預設值「False」即可。

圖 17、在虛擬機器儲存區原則中新增加密原則

在規則集頁面中,請確認「使用儲存區原則中的規則集」項目並未勾選即可。然後在儲存區相容性頁面中,選擇採用相容的 Datastore 儲存區即可。最後,在即將完成頁面中再次檢視組態設定內容無誤後,按下完成鈕即可。當系統建立好加密原則之後,在虛擬機器儲存區原則中便會看到剛才所新增的「VM Encryption Policy」加密原則。

圖 18、順利新增用於 VM 虛擬主機的加密原則



VM 虛擬主機套用加密原則

順利將用於保護 VM 虛擬主機內機敏資料的加密建立後,請依序點選「首頁 > vCenter 詳細目錄清單 > 虛擬機器 > 新增虛擬機器」。此時,將會彈出新增虛擬機器視窗,在選取建立類型頁面中此實作環境選擇「建立新的虛擬機器」項目。

圖 19、建立新的 VM 虛擬主機並準備套用加密原則

在選取名稱和資料夾頁面中,請鍵入 VM 虛擬主機名稱(此實作環境為 Secret-VM),然後選擇此台 VM 虛擬主機所要存放的目標 DataCenter 或資料夾即可。在選取運算資源頁面中,請選擇此台 VM 虛擬主機所要存放的目標 Cluster 或 ESXi 主機即可。在選取儲存區頁面中,請於虛擬機器儲存區原則下拉式選單中,選擇至剛才所建立的「VM Encryption Policy」加密原則項目,並確認所採用的 Datastore 儲存原則通過相容性檢查作業。

圖 20、為新建立的 VM 虛擬主機選擇套用加密原則

在選取相容性頁面中,請於相容下拉式選單中選擇「ESXi 6.5 及更新版本」項目,確保此台 VM 虛擬主機採用最新虛擬硬體版本 13,以便屆時能夠順利使用加密機制保護 VM 虛擬主機中的機敏資料。

圖 21、為建立的 VM 虛擬主機選擇採用最新虛擬硬體版本 13

在選取客體作業系統頁面中,請選擇 VM 虛擬主機所採用的客體作業系統以及版本即可。在自訂硬體頁面中,首先於虛擬硬體頁面中你會看到 Encryption 欄位顯示為「VM files are encrypted」,表示預設安裝客體作業系統的虛擬磁碟已經受到加密保護。倘若,管理人員為此台 VM 虛擬主機新增其它虛擬硬碟時,那麼也可以展開新增硬碟項目後在虛擬機器儲存區原則下拉式選單中,為新增的虛擬磁碟套用加密機制。

圖 22、為 VM 虛擬主機額外新增的虛擬磁碟套用加密機制

然後,請點選虛擬機器選項頁籤後,展開下方 Encryption 項目將 Encryption vMotion 下拉式選單中選擇至「Required」項目,確保此台 VM 虛擬主機在執行 vSphere vMotion 線上遷移期間,所有傳輸的記憶體狀態及相關網路流量是有進行加密的,避免遭受惡意人士監聽相關流量後引發資安事件或造成安全性風險。

圖 23、為 VM 虛擬主機組態設定加密 vSphere vMotion 遷移流量

在即將完成頁面中,再次檢視組態設定內容無誤後按下完成鈕即可。至此,VM 虛擬主機便順利套用加密原則,即便整台 VM 虛擬主機或虛擬磁碟(VMDK)直接被惡意人士複製後帶走,那麼也無法查看 VM 虛擬主機當中所儲存的機敏資料。





結語

透過本文的說明及實作相信讀者已經了解,在新版的 vSphere 6.5 當中舊有的功能增強部分,以及新增的特色功能機制,能夠幫助企業及組織建立更靈敏、高可用性、高安全性的雲端運算環境。