前言

簡單來說 OneNote 可以是個人或團隊內整理資料的萬用筆記本,個人在整理技術筆記上也是使用 OneNote,本文將整理幾個 OneNote 的好用之處有興趣的朋友不妨參考看看,有關 OneNote 的初步認識請參考導覽影片「什麼是 OneNote?」。



使用技巧整理





參考


前言

自從 Windows Server 2016 推出後,大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。本文,將要深入探討在 S2D 軟體定義儲存運作環境中「Storage Pool」的功能改進:

  • 每個 Storage Pool 最大支援「416 Drives」及 「1 PB Raw Capacity」,同時最佳建議是「One pool per Cluster」。
  • 執行「Enable-ClusterS2D」指令啟用 S2D 功能時,會自動建立 Storage Pool 並且把「合格的儲存裝置」(例如,未格式化過的磁碟) 加入到 Storage Pool 當中。同時,當加入新的 S2D 儲存節點時 (Scale-Out) 也會自動把相關的儲存裝置加入到 Storage Pool 當中,當儲存裝置發生故障時會自動退出並從 Storage Pool 當中移除。
  • 透過 S2D PM「Cosmos Darwin」撰寫的 PowerShell,可以輕鬆幫助你了解 Storage Pool 及儲存裝置空間的使用情況。






混亂的開始 (Resiliency, Slabs, Striping)

讓我們先從 3 Nodes 的 S2D 運作架構,每台 S2D Node 具備「2 x 800GB NVMe」以及「4 x 2TB SATA SSD」開始談起。




什麼是 Resiliency?

舉例來說,當我們建立「1 TB - 2WayMirror」的 Volume 時,這表示在「不同 Server、不同 Drives」必須維護共「2 份」副本資料,以便 1 份資料損壞時另 1 份仍然可用。所以,雖然建立 1TB Volume 但實際會佔用 2 TB 空間,這樣的行為稱之「Footprint on the Pool」。




什麼是 Slabs?

在建立的 1 TB Volume 儲存空間中,系統將會把它拆解成眾多的「Slab」並且每個 Slab 大小為「256 MB」(在 Windows Server 2016 技術預覽版本時稱為 Extent 大小為 1024 MB) 。因此,倘若建立 1 TB Volume 儲存空間的話便會拆解成「4,000 Slabs」。




什麼是 Striping?

當我們採用 2-Way Mirror 的方式建立 Volume 並且拆解成眾多 Slab 之後,「每個 Slab」將會建立「2 份副本」,然後透過 S2D 演算法分別存放在「不同 Server, 不同 Drives」當中。




因此,原則上眾多 Slabs 將會「平均且分散」的儲存到不同 Server 不同 Drives 當中。同時,預設情況下 Cluster 當中至少會有 5 個 Drive 儲存「Pool Metadata」以便後續「同步」(Synchronized)及「修復」(Repaired)等作業。此外,即便儲存的 Pool Metadata 都遺失,也不會影響 S2D 的部署及運作。






S2D 這樣設計的目的為何?

效能考量

將 Volume 拆解成眾多 Slab 然後平均分散放置到多個儲存媒體時,這樣可以提供「資料讀寫」的效益同時可以使用多個儲存媒體,以期「最大化 IOPS & I/O Throughput」。因此,S2D 的 2-Way Mirror 機制與傳統的 RAID-1 並不相同。



提升資料安全性

當「儲存裝置」發生故障時,原有儲存的資料副本將會在其它位置進行重建,這個行為稱之為「修復」(Repairing) 並執行下列 2 項操作步驟:

修復步驟1、從「存活」的資料副本中讀取 (讀取單位為 Bytes):
  • 想像一下,假設 S2D 沒有把 Volume 拆解成眾多 Slab 的話,那麼當 1TB Volume 副本所在的硬碟損壞時,採用的若是機械式硬碟要進行上述修復程序的第 1 項時,光是讀取 1TB Bytes 資料這個動作,可想而知整個資料重建程序將會非常緩慢!! 
  • 回到 S2D 的運作架構,有顆機械式硬碟損壞裡面存放一堆 Slab,但是這些 Slab 存活的資料副本是分佈在「不同機械式硬碟」中,有的可能在 Drive03、Drive15、Drive17……等。 
  • 重點就是,這個重建的動作可以同時使用到「多顆」機械式硬碟而非「單顆」機械式硬碟!!

修復步驟2、在其它位置寫入「新的」資料副本,以取代遺失的資料副本:
  • 原則上,只要哪裡有儲存空間就往哪裡寫。但是,機械式硬碟損壞的那台伺服器就會不再放置重新的資料副本。
  • 簡單來說,透過 Volume 打散成 Slab 的機制,不但提升資料安全性讓故障事件發生時「Resync」的等待時間縮短。






考量 Reserve Capacity

簡單來說,在你所建立的 Storage Pool 當中,應該要「預留」一些額外的儲存空間而不要都用盡!! 舉例來說,當機械式硬碟故障進行資料副本的修復程序時,才有緩衝的儲存空間可供使用。這個概念有點類似 HDD Hot Spare 但在實際運作上又有點不同。

強烈建議要預留空間,但就算沒有預留儲存空間 S2D 還是能正常運作,只是當「故障事件」發生時倘若沒有預設儲存空間的話將會影響修復速度。






自動建立儲存集區及重新負載平衡

當 S2D 叢集當中加入新的 S2D Node 時,會自動將 Slab 資料副本自動負載平衡到新的 S2D Node 當中,這個動作稱之為「最佳化」(Optimizing)「重新平衡」(Re-Balancing)。例如,在本文 S2D Cluster 中原本只有 3 Nodes 現在加入第 4 台 Node,只要鍵入「Add-ClusterNode -Name <Name>」PowerShell 指令即可。



順利將第 4 台 Node 加入後,「一開始」該 Node 的儲存裝置的使用空間還是空的。



預設情況下,經過「30 分鐘後」 S2D 將會「自動」執行「重新平衡」(Re-Balancing)的動作,但隨著運作規模大小將會需要不同的時間 (例如,幾小時)。倘若,你不希望等待 S2D 自動執行的話,可以手動執行「Optimize-StoragePool -FriendlyName "S2D*"」的 PowerShell 指令讓 S2D 立即執行重新平衡的動作,並且透過「Get-StorageJob」查看重新平衡的工作進度。



因此,當重新平衡作業執行完畢後,可以看到前 3 台 Node 的使用空間「下降」,因為平均且分散放置到第 4 台 Node 的儲存空間。






小結

  • 建立 S2D 的 Storage Pool 之後,無須再針對 Storage Pool 進行調整 (例如,新增 HDD、刪除 HDD……等)或額外再建立 Pool。
  • 建立的 Volume 會拆解成眾多 Slabs,然後平均分散到不同 Server / 不同 Drives。
  • 最好在 S2D Storage Pool 當中「預留」儲存空間,以便故障事件發生時能夠更快的進行修復作業。
  • 當 S2D 建立的 Storage Pool 加入新的 Node 時,會「自動」進行重新平衡的動作,保持資料副本平均分散到不同 Server / 不同 Drives 的原則。
  • 你可以透過「Get-StoragePool S2D*」、「Get-StoragePool S2D* | Get-PhysicalDisk」查看 S2D Storage Pool 相關資訊。
S2D PM「Cosmos Darwin」撰寫的 PowerShell





參考資源


前言

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



站長將不定期撰寫相關新功能簡介文章: (更新文章符號 💩)

【簡介】




【vCenter Server】




【Security】




【Storage】




【VMware Taiwan vSphere 6.5 新功能介紹】


網管人雜誌

本文刊載於 網管人雜誌第 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 當中舊有的功能增強部分,以及新增的特色功能機制,能夠幫助企業及組織建立更靈敏、高可用性、高安全性的雲端運算環境。

前言

自從 Windows Server 2016 推出後,大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。甚至,微軟也推出 Project Kepler-47 的輕量型 OEM S2D 解決方案,讓分公司或小型運作環境也能夠享有 S2D 軟體定義儲存技術的好處。本文,將討論在 Windows Server 2016 中的 S2D 軟體定義儲存解決方案中,佔有舉足輕重地位的儲存裝置「SSD 固態硬碟」。



SSD 固態硬碟基礎知識

眾所周知 SSD 固態硬碟具有「資料讀寫壽命」的問題,隨著資料不斷大量的讀取及寫入後即便只是簡單的資料讀取都會有壽命成本的問題,在 SSD 固態硬碟運作環境中這個現象稱之為「讀取干擾 (Read Disturb)」。下列,為常見的 4 種 SSD 固態硬碟類型:

  • SLC: 1 bit per Cell (100,000 or more Write)。
  • MLC: 2 bits per Cell (10,000 ~ 20,000)。
  • TLC: 3 bits per Cell (> 1,000)。
  • QLC: 4 bits per Cell (> 100)。


因此,正確的規劃及選擇 SSD 固態硬碟便更顯現其重要性。那麼,我們來看看 SSD 固態硬碟的存取行為,一般情況下會透過「FTL (Flash Translation Layer)」連接到 NAND Flash 快閃記憶體的內部控制器。同時,FTL 具備下列 2 項機制:
  • 儲存資料時會一起儲存「ECC (Error Correcting Codes)」,當需要恢復資料時便會透過 ECC 機制進行復原的動作。
  • 具備「Over-Provisioning」機制以便超額提供儲存空間。事實上,NAND 是無法直接寫入資料的,必須經過「P/E (Program/Erase)」的處理流程後才能進行寫入資料,每個「Page」的空間最小可達「16 K」。同時,NAND 不會重複寫入同個 Page,然後 FTL 持續追蹤及更新 Erased Pages,並且合併重新寫入的資料區塊以及所對應的 Re-Written Logical Blocks,最終的結果就是 Over-Provisioning。


簡單來說,「NAND Flash SSD」是個複雜且動態的運作環境,必須要整合多項機制才能確保儲存資料的可用性。同時,隨著儲存密度不斷增加的情況下維持資料可用性的難度相形提高,目前為透過「緩衝區 (Buffers)」機制來處理這個部分。同時消費者等級與伺服器等級的 SSD 固態硬碟,在資料可用性的保護機制上也有所不同 :
  • 在「消費者等級」SSD 固態硬碟當中,透過「Volatile Cache」及「電池 (Battery)」機制以確保不會因為意外失去電源而導致資料遺失。
  • 在「伺服器等級」SSD 固態硬碟當中,則透過「電容 (Capacitor)」以提供電源保護機制。


舊式企業級 SSD」(Older Enterprise-Grade SSD),具備可拆卸及更換的「內建電池」提供電源保護機制。


新式企業級 SSD」(Newer Enterprise-Grade SSD),則是使用「電容 (Capacitor)」也就是下圖中 3 顆黃色顆粒裝置以便提供電源保護機制。


那麼,倘若在 S2D 軟體定義儲存的運作環境當中採用「消費者等級 SSD 固態硬碟」時會發生什麼事? 下列,便是採用 1TB SATA SSD (5 年保固)消費者等級的 SSD 固態硬碟進行實驗:
  • QD32 4K Read: 95,000 IOPS
  • QD32 4K Write: 90,000 IOPS
  • 資料儲存耐用性: 185 TB 


根據上述消費者等級的 SSD 固態硬碟效能數據及資料儲存耐用性,我們來估算一下這樣的消費者等級 SSD 固態硬碟其「DWPD (Device Writes per Day)」數值:
  • 185 TB / (365 days x 5 years = 1825 days) = ~ 100 GB writable per day
  • 100 GB / 1 TB total capacity = 0.10 DWPD


首先,透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試:
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Su -D -L -d1800 -Rxml Z:\load.bin

可以看到測試長度為「30 分鐘」,但是從測試數據中可以看到在資料存取不到「3 分鐘」之後 IOPS 突然「下降 10,000 IOPS」,這對於消費者等級的 SSD 固態硬碟來說是非常正常的現象。因為 FTL 已經用完預設準備給 NAND 的寫入空間了,所以導致資料存取速度變得非常的慢,因為整個資料存取動作已經中斷並且必須重新準備。


同樣的工作負載,再次透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試,但是加上「Write-Through」的動作 (參數 -Suw),讓整個 NAND 的延遲時間及 FTL/Buffer 真正顯現出來。從下圖中可以看到,IOPS 效能數據的結果非常差:
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Suw -D -L -d1800 -Rxml Z:\load.bin



結論

因此,在 Windows Server 2016 所建構的 S2D 軟體定義儲存環境中,應該選擇及採用具備「Non-Volatile Write Cache」及「Enterprise-Grade SSD」特性的企業級 SSD 固態硬碟。那麼,該如何確認選擇的企業級 SSD 固態硬碟支援「Non-Volatile Write Cache」機制?
  • 在 DataSheet 中看到「PLP (Power Loss Protection)」字眼,例如,Samsung SM863、Toshiba HK4E…等。
  • 在  DataSheet 中看到「Enhanced Power Loss Data Protection」字眼,例如,Intel S3510、S3610、S3710、P3700…等。




參考資源



前言

日前 (2016.12.8),在 Taiwan 舉辦的 VMware Taiwan vForum 2016 議程簡報已經開放下載了,有興趣的朋友可以參考看看。

簡報下載

主題演講




分會場 1、軟體定義資料中心




分會場 2、軟體定義儲存




分會場 3、軟體定義網路及安全




分會場 4、多雲維運與自動化




分會場 5、行動終端應用




分會場 6、Cloud Native


網管人雜誌

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





文章目錄

前言
在 Hyper-V 虛擬化平台上運作 Unix-Like
什麼是 Hyper-V 整合服務?
Unix-Like虛擬主機整合服務
          CentOS 虛擬主機安裝整合服務
          FreeBSD 虛擬主機安裝整合服務
結語





前言

談到微軟作業系統,某些 IT 人員便認為在作業系統的部分一定是只有 Windows。雖然,Windows 偶爾有推出與開放源始碼整合的相關服務,但使用者通常仍覺得整合程度有限,但是這樣的狀況自從微軟 CEO Satya Nadella 上任並喊出 Microsoft Love Linux 之後便一一被打破,甚至最新推出的 Windows Server 2016 作業系統,還能夠原生執行 Container 容器技術。

同時,不光是地面上企業及組織的相關技術支援 Linux,就連微軟公有雲 Azure 也支援 Linux 作業系統的 VM 虛擬主機及相關服務,根據微軟的內部統計目前在 Azure 公有雲的 VM 虛擬主機工作負載當中,有 1/3 是運作 Linux 作業系統另外 2/3 才是運作 Windows 作業系統。

同時在 2016 年 3 月,微軟已經釋出 SQL Server on Linux 的封閉預覽測試版本,並宣佈預定於2017 年 Q2 將正式推出。屆時,在 Linux 作業系統中也可以安裝 Microsoft ODBC Driver for SQL Server,以便 Linux 作業系統能夠順利存取 SQL Server 資料庫服務。

圖 1、SQL Server on Linux 的封閉預覽測試版本

2016 年 4 月,微軟在 Build 開發者大會上正式宣佈,從 Windows 10(Build 14316)作業系統版本開始,將在 Windows 作業系統核心中加入子系統(Windows Subsystem for Linux),以便在 Windows 作業系統中能夠原生支援 Linux 使用者模式,這與舊有透過 Cygwin 模擬的方式完全不同。現在,你可以直接在 Windows 作業系統中原生執行 Ubuntu Bash、apt-get、git……等。

圖 2、運作 Ubuntu 原生 Bash 指令碼環境在 Windows 作業系統中

2016 年 8 月,微軟也宣佈自家的 PowerShell 指令碼工具正式 Open Sourced。現在,可以在多種 Linux 作業系統(例如,Ubuntu 14.04、Ubuntu 16.04、CentOS 7、OS X 10.11……等)中,直接透過 GitHub 下載安裝後運作 PowerShell 指令碼環境。

圖 3、在 CentOS 作業系統中運作 PowerShell 指令碼環境





在 Hyper-V 虛擬化平台上運作 Unix-Like

在 Hyper-V 虛擬化平台上運作 VM 虛擬主機,倘若客體作業系統採用 Windows 時相信 IT 管理人員應該不陌生,舉例來說,在 Windows Server 的部分支援 SBS 2011、2008 SP2、2008 R2、2012、2012 R2 以及最新版本的 Window Server 2016,至於 Desktop 的部分則支援 Vista SP2、7 SP1、8.1 及最新版本的 Windows 10。

那麼,倘若在 Hyper-V 虛擬化平台中要運作 Unix-Like 作業系統(例如,Linux 及 FreeBSD)時,哪些 Unix-Like 版本才有支援?倘若採用不支援的 Unix-Like 作業系統時是否無法運作在 Hyper-V 虛擬化平台上?Hyper-V 虛擬化平台能否運作 Unix(例如,AIX、HP-UX)或者是 Max OS X?

簡單歸納來說,Hyper-V 虛擬化平台無法運作 Unix 及 Max OS X。同時,當採用未支援的 Unix-Like 作業系統版本時,將會因為無法安裝「整合服務」(Integration Service),除了導致運作於 VM 虛擬主機當中的 Unix-Like 作業系統,無法針對相關虛擬硬體裝置安裝驅動程式與 Hyper-V 虛擬化平台進階功能整合之外,也將會影響 VM 虛擬主機的運作效能。

圖 4、Hyper-V 虛擬化平台是否能運作 Unix 及 Unix-Like 作業系統判斷流程示意圖





什麼是 Hyper-V 整合服務?

事實上,不管採用哪一種虛擬化平台都會需要幫其上運作的 VM 虛擬主機安裝適當的 Tools,以使其上運作的 VM 虛擬主機能夠與虛擬化平台進行最緊密的結合(例如,虛擬裝置驅動程式最佳化……等),舉例來說,倘若採用 VMware vSphere 虛擬化平台便需要幫 VM 虛擬主機安裝 VMware Tools,而 Citrix XenServer 虛擬化平台便需要幫 VM 虛擬主機安裝 Xen Tools。

在 Microsoft Hyper-V 虛擬化平台上,則是需要幫其上運作的 VM 虛擬主機安裝「整合服務」(Integration Services),安裝整合服務完畢後在驅動程式部份將會針對 IDE、SCSI、網路 、視訊 、滑鼠 …… 等方面進行最佳化,而在客體服務方面則會整合作業系統關閉(Shutdown)、時間同步化(Time Synchronization)、資料交換(Key/Value Exchange)、活動訊號(Heartbeat)、線上備份(Volume Shadow copy Service,VSS)……等機制,以期 VM 虛擬主機與 Microsoft Hyper-V 虛擬化平台不管是在效能運作上,或者是虛擬裝置驅動程式最佳化方面都能進行完美的結合。

圖 5、Hyper-V運作元件架構示意圖





Unix-Like 虛擬主機整合服務

倘若,您的 VM 虛擬主機安裝「Windows作業系統」的話,那麼在VM虛擬主機的Console視窗中可以直接執行插入整合服務安裝光碟的動作。當安裝「Linux 作業系統」如 RHEL / CentOS 時,Hyper-V 虛擬化平台雖然也支援「Emulated / Specific」2 種虛擬裝置,但是若需要發揮 Linux 作業系統最佳效能,建議您使用 Hyper-V Specific Devices 並配合安裝「LIS(Linux Integration Services)」,也就是專供 Linux 使用的整合服務映像檔並進行安裝才能達到效能最佳化。

專供 Linux 作業系統使用的 LIS 整合服務映像檔,目前最新版本為 4.1 您可至 Microsoft Download Center 下載「Linux Integration Services Version 4.1 for Hyper-V」,所下載整合服務映像檔名稱為「LinuxIC-4.1.2-2.iso」。

圖 6、下載專供 Linux 作業系統使用的 LIS 整合服務映像檔

LIS 4.1 for Hyper-V 整合服務,支援的 Linux 版本以 RHEL / CentOS 為例的話是 5.2 ~ 5.11、6.0 ~ 6.8、7.0 ~ 7.2,並且可以應用在多種Hyper-V虛擬化平台版本上,例如,Hyper-V 2.0(Windows Server 2008 R2)、Hyper-V 3.0(Windows 8 / 8.1 Pro、Windows Server 2012 / 2012 R2)以及最新的 Windows 10 和 Windows Server 2016。

最新的 LIS 4.1 版本中,除了原有整合服務的特色功能之外還支援下列 5 項新增功能:
  • Hyper-V Sockets。
  • 記憶體熱新增及移除。
  • SCSI WWN。
  • lsvmbus 指令。
  • 反安裝 LIS 整合服務指令碼。

安裝整合服務後的Linux虛擬主機,將具備核心(Core)、網路(Networking)、儲存(Storage)、記憶體(Memory)、視訊(Video)、其它(Miscellaneous)……等特色功能或最佳化效能:

核心(Core)

  • 整合式關機: 透過此功能,在開啟的VM Console視窗中便能為客體作業系統執行關機的動作,而無須登入至客體作業系統手動進行關機。
  • 時間同步處理: 確保VM虛擬主機能夠與Hyper-V主機保持時間同步。
  • 準確時間: 整合 Windows Server 2016 準確時間功能,改善主應用程式與時間同步處理的精確度,能夠將時間誤差值縮短在 1 毫秒的範圍內。
  • 多處理器支援: 支援組態配置 VM 虛擬主機多顆 vCPU 虛擬處理器,達到真正使用 Hyper-V主機多顆 CPU 處理器進行 SMP 平行運算。
  • 活動訊號: 以便 Hyper-V 虛擬化平台能夠偵測及追蹤 VM 虛擬主機運作狀態。
  • 整合式滑鼠支援: 滑鼠功能將可正常運作於 VM 虛擬主機的 Console 視窗中,以及自動在Hyper-V 虛擬化平台中正常切換。
  • Hyper-V 特定儲存裝置: 使 VM 虛擬主機擁有高效能及最佳化的 IDE/SCSI 儲存介面卡,有效提升工作負載能力。
  • Hyper-V 特定網路裝置: 使 VM 虛擬主機擁有高效能及最佳化的 Network Controller 介面卡,有效提升工作負載能力。

網路(Networking)

  • Jumbo Frame: 可設定 MTU 數值大於 1500 bytes 以增加網路效能。
  • VLAN Tagging 及 Trunking: 支援單一 VLAN ID 或多個 VLAN ID Trunking 網路環境。
  • 即時遷移: 讓 VM 虛擬主機支援即時遷移(Live Migration)、無共用儲存即時遷移(Shared Nothing Live Migration)、Hyper-V複本(Hyper-V Replica)…… 等進階功能。
  • 靜態 IP 導入: 當 Hyper-V 主機執行複本容錯移轉之後,因為已經複寫 VM 虛擬主機靜態 IP 位址,所以能夠確保網路工作負載能在發生容錯移轉事件後無縫繼續運作。
  • vRSS 虛擬接收端調整: 將 VM 虛擬主機虛擬網路卡的工作負載,平均分散到 VM 虛擬主機中的多個 vCPU 虛擬處理器。
  • TCP 分割和總和檢查碼卸載: 在傳輸網路數據時,從 VM 虛擬主機的 vCPU 虛擬處理器到 Hyper-V 主機的 vSwitch 虛擬網路交換器之間,進行資料分割及總和檢查碼的動作。
  • LRO 大型接收卸載: 透過將多個封包彙總為更大的緩衝區,以便提升高網路頻寬流入的傳輸量,進而降低 CPU 運算資源的開銷。

儲存(Storage)

  • VHDX 調整大小: 系統管理員可以隨時因應需求,線上調整 VM 虛擬主機的 VHDX 磁碟空間。
  • vHBA 虛擬光纖通道: 讓 VM 虛擬主機能夠感知原生光纖通道裝置,進而支援及使用虛擬光纖通道功能。
  • VM 虛擬主機即時備份: 讓 VM 虛擬主機能夠在運作中的情況下進行備份作業。
  • TRIM: 當應用程式不再需要磁碟空間時,協助執行磁碟空間回收的動作。
  • SCSI WWN: Storvsc 驅動程式將會擷取連接埠和連接至 VM 虛擬主機的全球名稱(WWN),以便建立適當的 sysfs 檔案。

記憶體(Memory)

  • PAE 核心支援: 在 Linux 作業系統中透過 PAE 技術,可以讓 32 位元核心存取超過 4 GB 的記憶體位址空間。舉例來說,舊版的 RHEL 5.x 必須個別在核心中啟用 PAE 功能,而較新版的 RHEL 6.x 則核心已經預先啟用 PAE 功能。
  • MMIO: 協助 JeOS(Just Enough Operating Systems)與 Hyper-V 主機實體記憶體區塊進行對應的動作。
  • 記憶體熱新增及移除: 提供 VM 虛擬主機在運作狀態中,線上動態增加及移除記憶體空間的機制。
  • Ballooning: 活化 Hyper-V 主機記憶體空間,以便渡過記憶體空間暫時不足的因應機制。

視訊(Video)

  • 特定視訊裝置: 提供 VM 虛擬主機高效能及高解析的視訊介面卡,但是此裝置並不提供增強的工作階段模式及 RemoteFX 功能。

其它(Miscellaneous)

  • KVP(Key-Value Pair)Exchange: 取得 VM 虛擬主機在資料方面讀取(Read)/ 寫入(Write)等資訊。
  • NMI 非遮罩式插斷: 協助 VM 虛擬主機當中的客體作業系統,因為應用程式漏洞而發生的崩潰情況,再主機重新啟動後有機會分析導致系統發生崩潰的原因。
  • 客體與主機進行檔案複製: 透過客體服務讓 VM 虛擬主機與 Hyper-V 主機之間,在進行檔案複製作業時無須透過網路介面卡進行傳輸。
  • lsvmbus 指令: 透過此指令可以獲得 Vmbus 的相關資訊。
  • Hyper-V Sockets: 透過載入 Hyper-V Sockets 核心模組,讓 VM 虛擬主機與 Hyper-V 主機之間建立專屬的通訊通道。
  • PCI Passthrough: 將安裝於 Windows Server 2016 主機上的 PCI Express 裝置,例如,網路介面卡、GPU 顯示卡……等,以直接傳遞的方式指派給 VM 虛擬主機使用。

那麼在 Hyper-V 虛擬化平台上所運作的 Linux 作業系統,哪種發行套件及版本分別支援上述說明的功能呢,舉例來說,採用新版 CentOS 7.0 雖然核心中已經支援 Hyper-V 裝置最佳化,但是仍無法使用 vRSS 功能,必須要採用更新的 CentOS 7.1 或 7.2 版本才支援,在 Ubuntu Server 也是一樣的情況,你會發現 Ubuntu 12.04 並不支援 vRSS 功能,必須使用新版本的 Ubuntu 14.04、16.04 或 16.10 才支援。

為了避免不必要的篇幅,在此便不將 Hyper-V 虛擬化平台所支援 Linux 發行套件及版本其所對應的功能逐一說明,有興趣的讀者不妨直接瀏覽 Microsoft 官方網站查詢及核對所支援的特色功能項目:
圖 7、RHEL / CentOS 版本及特色功能對應表



CentOS 虛擬主機安裝整合服務

當管理人員為 VM 虛擬主機,安裝舊版 RHEL / CentOS「5.2 ~ 5.8、6.0 ~ 6.3(32 或 64 位元)」時,那麼必須要為 RHEL/CentOS 客體作業系統安裝「Linux Integration Services Version 4.1 for Hyper-V」整合服務。

其它較新版本 RHEL / CentOS「5.9 ~ 5.11、6.4 ~ 6.8、7.0 ~ 7.2(32 或 64 位元)」,因為官方已經直接在該版本的 Linux 核心當中,直接內嵌 Hyper-V 相關虛擬裝置驅動程式。

因此,當 VM 虛擬主機安裝這些新版本的 RHEL/CentOS 客體作業系統版本後,其實可以無須再額外安裝 LIS 4.1 整合服務。除非,你希望使用 LIS 4.1 整合服務所提供的新增功能,例如,在預設情況下 CentOS 7.2 版本內建的整合服務,並未支援 SCSI WWN、lsvmbus 指令、Hyper-V Sockets 等功能。

那麼,當我們為 VM 虛擬主機安裝新版 CentOS 7.2 客體作業系統後,登入 CentOS 客體作業系統鍵入相關指令「uname -a、cat /etc/redhat-release、cat /var/log/dmesg | grep Vmbus」,便可以看到目前採用的 Linux 核心版本為「3.10.0-327.e17.x86_64」,採用的 CentOS 版本為「7.2.1511」,至於 Hyper-V 整合服務所使用的 hv_vmbus 版本則為「3.0」

圖 8、CentOS 7.2 客體作業系統版本資訊,以及內建的 Hyper-V LIS 整合服務資訊

接著,我們從 Hyper-V 虛擬化平台方面,透過 Hyper-V 管理員來驗證此台 VM 虛擬主機是否真的已經支援整合服務了。首先,點選安裝 CentOS 7.2 的 VM 虛擬主機後,在下方 Hyper-V 管理員「摘要」頁籤中,可以看到活動訊號欄位的顯示結果為「良好(無應用程式資料)」,表示 Hyper-V 虛擬化平台可以正確偵測到VM虛擬主機運作狀態。

切換到「記憶體」頁籤後,您可以看到記憶體需求及記憶體狀態欄位為「1036 MB、確定」,表示 Hyper-V 虛擬化平台的動態記憶體功能,與目前 CentOS 客體作業系統已經順利協同運作了。
請注意! 倘若採用舊版 Windows Server 2012 虛擬化平台版本的話,則「尚未」支援 Linux 作業系統動態記憶體功能,必須採用 Windows Server 2012 R2 或新版 Windows Server 2016 虛擬化平台版本,才正式支援動態記憶體功能。

切換到「網路功能」頁籤中,你會看到在狀態欄位的部分顯示結果為「良好(VMQ 作用中)」,表示 CentOS 客體作業系統已經採用內建的整合服務,為 VM 虛擬主機所指派使用的虛擬網路介面卡,安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。

圖 9、新版 CentOS 7.2 已經內建 LIS 整合服務

倘若,你希望測試新版 LIS 4.1 整合服務中 lsvmbus 指令及 Hyper-V Sockets 功能的話,那麼便需要為 CentOS 7.2 安裝 LIS 4.1 整合服務。請為 VM 虛擬主機掛載剛才下載的 Linux Integration Services Version 4.1 for Hyper-V 整合服務映像檔 LinuxIC-4.1.2-2.iso,準備為 CentOS 7.2 作業系統安裝整合服務。

圖 10、為 VM 虛擬主機掛載 LIS 整合服務映像檔

順利掛載 LIS 整合服務映像檔之後,回到 CentOS 7.2 虛擬主機 Console 畫面,請依序鍵入指令「mount /dev/cdrom /media、cd /media/CentOS72、./install.sh」,執行掛載光碟機資源、切換到適合安裝的整合服務 CentOS 版本路徑、安裝整合服務等動作。

圖 11、為 CentOS 7.2 安裝新版 LIS 4.1 整合服務

當新版 LIS 4.1 整合服務安裝完畢後,請將 CentOS 7.2 客體作業系統重新啟動並卸載 LIS 整合服務映像檔。當 CentOS 7.2 客體作業系統重新啟動完畢後,便可以透過「/sbin/modinfo hv_vmbus」指令查看 hv_vmbus 版本,可以從指令執行結果中看到已經採用最新「4.1.2-2」版本。此外,如同剛才所說明的我們可以使用新版 LIS 4.1 整合服務中的「lsvmbus」指令,來查看相關虛擬裝置的 Vmbus ID 資訊。

圖 12、確認 CentOS 客體作業系統,是否採用最新的 hv_vmbs 4.1.2-2 版本
目前有個已知問題值得注意,倘若安裝 CentOS 客體作業系統的 VM 虛擬主機有啟用「安全開機」功能的話,那麼在安裝新版 LIS 4.1 整合服務後必須將安全開機功能「停用」,否則將會發現 CentOS 客體作業系統無法正常啟動或啟動後直接進入安全模式。



FreeBSD 虛擬主機安裝整合服務

雖然,FreeBSD 也是 Unix-Like 作業系統,但是 FreeBSD 的系統核心與 Linux 完全不同。同樣的,微軟官方也採用與 LIS 整合服務同樣的方式,讓運作於 Hyper-V 虛擬化平台中的 FreeBSD 虛擬主機,能夠支援及使用 Hyper-V Specific Devices 高效能虛擬裝置機制,此機制稱之為「BIS(BSD Integration Services)」

圖 13、微軟開發人員協同 FreeBSD 團隊開發 BIS 整合服務,讓系統核心支援 Hyper-V 虛擬化平台

倘若運作舊版 FreeBSD 8.4、9.1 ~ 9.3 的話,必須透過 FreeBSD Ports 套件管理機制,安裝「/head/emulators/hyperv-is」套件即可。在 2012 年 5 月 10 日時,Microsoft TechNet Blog發表一篇 FreeBSD Support on Windows Server Hyper-V 文章,內容便說明 Microsoft 以及合作夥伴 NetApp、Citrix 將在 BSDCan 2012 大會上,正式發表 FreeBSD 核心支援 Hyper-V 虛擬裝置驅動程式。

因此,倘若採用的是 FreeBSD 10.x 或最新版本的 FreeBSD 11,因為在 FreeBSD 核心中已經支援 BIS 整合服務,所以便無須再透過 FreeBSD Ports 套件管理機制進行安裝作業。
請注意,目前 Hyper-V 虛擬化平台中的 FreeBSD,仍無法採用「第二世代」格式的 VM 虛擬主機,同時 BIS 整合服務功能性的部分與 LIS 整合服務相較之下較少,舉例來說,動態記憶體功能尚未完全支援運作。

同樣的,在建立第一世代格式的 VM 虛擬主機並安裝最新版本 FreeBSD 11 之後,我們可以切換到 Hyper-V 管理員視窗中,確認 FreeBSD 虛擬主機的 BIS 整合服務是否順利運作。首先,切換到「摘要」頁籤中,可以看到活動訊號欄位的顯示結果為「良好(無應用程式資料)」,表示Hyper-V虛擬化平台可以正確偵測到VM虛擬主機運作狀態。

切換到「記憶體」頁籤中,您可以看到記憶體需求及記憶體狀態欄位為「空白」,這是因為BIS 整合服務機制尚未支援 Hyper-V 虛擬化平台的動態記憶體功能所致。切換到「網路功能」頁籤中,你會看到在狀態欄位的部分顯示結果為「良好(VMQ 作用中)」,表示 FreeBSD 客體作業系統已經透過 BIS 整合服務,為 VM 虛擬主機所指派使用的虛擬網路介面卡,安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。

圖 14、新版 FreeBSD 11 已經內建 BIS 整合服務

順利登入 FreeBSD 11 系統後,可以發現系統已經順利辨識到網路介面卡(代號為 hn0),查看系統開機訊息可知 hn0 網路卡為「Hyper-V Network Interface」,也就是已經採用最佳化效能的 Hyper-V Specific Network Adapter,接著鍵入指令「ls /boot/kernel | grep hv」查看 FreeBSD 模組存放資料夾內容可知,協同 Hyper-V 虛擬化平台運作的相關模組檔案也已經存在。
倘若,VM 虛擬主機組態配置傳統網路介面卡時,將網路介面卡代號將為「de0」並模擬「Digital 21140A Fast Ethernet 100 Mbps」網路卡。
圖 15、順利辨識並載入 Hyper-V Specific Network 網路介面卡及相關模組

鍵入指令「dmesg | grep vmbus0」查詢 FreeBSD 開機訊息內容,你會看到 FreeBSD 透過內建的 BIS 整合服務,已經順利載入 Hyper-V 虛擬化平台協同運作的相關服務,例如,Heartbeat、KVP、Shutdown、Time Synch……等服務。

圖 16、FreeBSD 透過內建的 BIS 整合服務載入 Hyper-V 相關客體服務





結語

透過本文的說明及實作演練,當企業及組織的 IT 管理人員需要在 Hyper-V 虛擬化平台上運作 Unix-Like 作業系統時,便能夠正確為 Unix-Like 作業系統採用 LIS / BIS 整合服務,以便確保運作於 Hyper-V 虛擬化平台上的 Unix-Like 作業系統,能夠擁有最佳的工作負載及最大化的運作效能。