網管人雜誌

本文刊載於 網管人雜誌第 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 作業系統,能夠擁有最佳的工作負載及最大化的運作效能。

網管人雜誌

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




文章目錄

前言
實體網路基礎架構
          Leaf-Spine 網路架構
          建立多路徑路由環境
          IP MultiCast
          網路安全性
          實體網路卡配置
虛擬網路架構
          vSwitch 虛擬網路交換器
          VMkernel Port
          停用流量管控機制
          NIC Teaming
          Jumbo Frames
          Switch Discovery Protocol
結語





前言

在 VMware 所擘劃的 SDDC 軟體定義資料中心願景中,在 SDC 軟體定義運算的部分由 vSphere ESXi 虛擬化平台擔綱,而在 SDN 軟體定義網路的部分為 NSX 虛擬化平台解決方案,在 SDS 軟體定義儲存的部分,便是由 VMware Virtual SAN(簡稱 VSAN)負責。

圖 1、VMware SDDC 軟體定義資料中心願景

簡單來說,透過 VMware VSAN 技術便能夠將多台 x86 實體伺服器中,配置於實體伺服器的「本機硬碟(Local Hard Disk)」串連起來,進而將叢集當中所有叢集節點主機的儲存資源整合起來,成為一個巨大的儲存資源池並且能夠互相共用。

同時,為了提供足以運作大型運作規模的軟體定義儲存資源,因此 VSAN 支援採用「Hybrid」儲存資源運作架構,將快取資料存放於快閃式儲存(例如,SSH / NVMe)中,至於儲存資料則放於一般機械式硬碟內。倘若,需要更高的儲存效能則可以建置「All-Flash」運作架構,也就是連同資料儲存空間的部分也交由一般的 SSD 固態硬碟負責。

圖 2、VSAN 運作架構示意圖

目前,VMware VSAN 最新釋出為 6.2 版本(第 4 代 VSAN),除了原有加強監控 IOPS 效能及健康狀況外,同時也推出重複資料刪除與壓縮 、EC 編碼技術和 QoS 品質管控機制。在本文中,我們將從實體網路環境至 vSphere 虛擬化環境,深入剖析最佳規劃設計準則及相關組態設定建議,以便幫助企業及組織的管理人員打造高可用效高效能的 VSAN 運作環境。

圖 3、VSAN 版本演進及功能進化示意圖



實體網路基礎架構

在資料中心網路基礎架構中,傳統網路環境採用「Access-Aggregation-Core」的 3 層式架構,以便處理資料中心內「南 - 北(North - South)」的網路流量,同時為了避免網路環境發生「迴圈(Looping)」的情況,通常會啟用 STP(Spanning Tree Protocol)機制防止網路環境發生迴圈的情況,但也等同於將網路的整體頻寬限制在 50 %

然而,隨著虛擬化及雲端運算不斷的發展,現代化資料中心的網路架構已經改為採用架構簡單 、 可擴充性 、 高網路頻寬 、 容錯機制和 QoS 網路流量管控的「Leaf-Spine」2 層式架構。不管採用哪一種網路環境及基礎架構,在 VMware VSAN 運作環境中皆支援舊式的 3 層式網路架構或新式的 2 層式網路架構。

圖 4、 傳統 3 層式架構(Access-Aggregation-Core)與新式 2 層式架構(Leaf-Spine)示意圖



Leaf-Spine 網路架構

VMware VSAN 為 SDS 軟體定義儲存解決方案,所以在 VSAN 叢集中每台 ESXi 成員主機便是 1 台儲存資源節點主機,因此每台儲存資源節點主機之間將會有高速資料傳輸的需求(東 - 西向網路流量),應該要保持網路傳輸極低的延遲時間,否則將會造成 VSAN 儲存效能上的問題。

此外,在網路頻寬的規劃上也非常重要,舉例來說,VSAN 儲存網路環境建議採用 10 Gbps 網路頻寬環境,雖然 1 Gbps 網路環境也能運作但是將會造成 VSAN 儲存效能上的問題,因為在 1 Gbps 網路環境中假設重建儲存空間為 12 TB 時,那麼儲存資源節點主機之間的資料同步作業將需要 24 小時以上。

即便規劃 10 Gbps 網路頻寬環境搭配 Leaf-Spine 網路架構,後續在規劃 VSAN 叢集時也必須考量實務上儲存資源節點主機的放置及環境。舉例來說,如圖 5 所示可以看到為 10 Gbps 網路頻寬的 Leaf-Spine 網路架構,機櫃 1 中為編號 1 ~ 16 儲存資源節點主機而機櫃 2 為編號 17 ~ 32 儲存資源節點主機,倘若只是單純將這 32 台儲存資源節點主機建立 1 個 VSAN 容錯網域的話,那麼屆時在儲存資源節點主機之間的溝通網路頻寬,將會因為比例(4:1)的關係有可能只達到 2.5 Gbps 的水準。

因此,建議在這樣的運作環境中建立 3 個 VSAN 容錯網域(Fault Domains),假設每台儲存資源節點主機原始儲存空間為 10 TB,當設定 FTT = 1 時將會有 6 TB 空間用於保護 VM 虛擬主機,在這種情況下將會有 4/3(也就是 30 Gbps 可以進行重建資料的動作),並且在沒有發生磁碟資源爭奪的情況下只需要 26 分鐘即可完成,即便重建資料儲存空間達 12 TB 並且頻寬少到 10 Gbps,那麼重建時間也僅需要 156 分鐘即可完成。

圖 5、VMware VSAN 採用 Leaf-Spine 網路架構示意圖



建立多路徑路由環境

目前,許多企業或組織已經在資料中心網路環境內,建立 STP 機制以防止網路環境發生迴圈的情況,同時在 Layer 2 網路環境內也應建立 ECMP(Equal-Cost Multi-Path routing)、SPB(Shortest Path Bridging)或 TRILL(Transparent Interconnection of Lots of Links)……多路徑路由或最短路徑等機制。同樣的,在 VMware VSAN 運作環境中皆支援這些網路拓撲基礎架構,重要的是必須良好規劃設計 VSAN 叢集中 ESXi 成員主機的「東 - 西」向網路。

根據 VMware 官方最佳作法,在 VSAN 叢集同一個容錯網域內的 ESXi 成員主機之間,除了確保東西向網路具備低延遲網路時間之外,在實體交換器的部分應該採用「交換機堆疊」(Switch Stack)的運作架構,以滿足高可用性及網路頻寬輸送量的需求。

圖 6、ECMP 多路徑路由運作示意圖



IP MultiCast

簡單來說「IP 多點傳送」(IP Multicast)機制,是可以「1 對多」或「多對多」的 IP 網路通訊技術。一般來說,會建議將 VSAN 運作環境建立於 Layer 2 網路環境中,以便降低複雜度及管理成本。倘若,將 VSAN 運作環境建立於 Layer 3 網路環境時,那麼實體網路一定要建立 IP Multicast 機制。

在 IP 多點傳送運作環境中,使用的 IP 多點傳送位址稱為「多點傳送群組」(Multicast Group,MG)。同時,在預設情況下當 VSAN 叢集建立時,預設便會自動分配 IP 多點傳送位址給節點主機,預設的 VSAN 多點傳送群組位址為「224.1.2.3」,而 VSAN 多點傳送群組代理程式位址為「224.2.3.4」。
請注意! 倘若希望調整預設的 VSAN 多點傳送群組位址,或是 VSAN 多點傳送群組代理程式位址的話,請參考 VMware KB 2075451 文件內容即可進行調整。

在 VSAN 叢集運作環境中,叢集節點主機透過 VMkernel Port 以 IP 多點傳送機制,透過 IGMP(Internet Group Management Protocol)互相傳送 Metadata 以及加入或離開 VSAN 叢集等資訊,同時在叢集節點主機之間也是透過 IP 多點傳送機制,互相偵測對方是否存活。

在預設情況下,VSAN 叢集將會採用 IGMP v3 版本進行「交涉」(Negotiate)的動作,倘若網路環境不支援 IGMP v3 的話,那麼就會採用 IGMP v2 進行交涉的動作。VMware 最佳作法,建議在 Layer 3 網路環境中採用一致的 IGMP 版本即可。

在 VSAN 叢集運作環境中,倘若叢集節點主機之間需要跨越多個子網路時,便需要採用 PIM(Protocol Independent Multicast)機制,並且支援 4 種模式以便因應不同的應用情境,PIM-DM(PIM Dense Mode)適用於 1 對多環境,PIM-SM(PIM Sparse Mode)同樣適用於 1 對多環境,當 Layer 3 網路環境僅支援 IGMP v2 時便建議採用此模式,Bi-PIM(Bidirectional PIM)適用於多對多環境,PIM-SSM(PIM Source-Specific Multicast)適用於多對多環境,且完全支援 IGMP v3 環境中使用。

圖 7、Layer 3 網路環境 PIM-SSM 運作機制示意圖

Layer 2 網路規劃建議
當你決定將 VSAN 架構運作於 Layer 2 網路環境時,下列為 Layer 2 網路規劃建議假設採用 VLAN ID 1,並且 IGMP Querier 運作於網路交換器上而非路由器。值得注意的是,務必確認實體網路交換器支援 IGMP v2 或 IGMP v3(例如,Cisco Nexus 交換器支援 IGMP v3,而 Brocade VDX 交換器僅支援 IGMP v2)。

圖 8、 運作於 Layer 2 網路環境的 VSAN 架構示意圖

Layer 3 網路規劃建議
當你決定將 VSAN 架構運作於 Layer 3 網路環境時,表示屆時 VSAN 叢集節點主機之間將有 Layer 3 設備(例如,L3 網路交換器或路由器)。同時,因為必須針對每個 Layer 3 分區送出請求,所以 IGMP Querier 必須是預設閘道,並且必須具備多點傳送群組的成員資格以便執行加入及更新 PIM 的動作。

圖 9、 運作於 Layer 3 網路環境的 VSAN 架構示意圖



網路安全性

與其它 IP 儲存網路流量一樣,在 VSAN 儲存網路中儲存資源節點主機之間的流量並「沒有加密」。因此,在規劃設計 VSAN 儲存網路時,應該規劃獨立且安全的 VLAN 網段進行 VSAN 儲存流量隔離。倘若,管理人員需要更高的安全性,那麼可以在更高運作層級中進行資料加密的動作即可,舉例來說,可以在 VM 虛擬主機的客體作業系統中執行資料加密工作任務。

實體網路卡配置

下列為 VSAN 叢集運作環境中,為每台 ESXi 主機規劃設計實體網路卡時的配置建議:

  • 至少配置 1 個專屬於 VSAN 儲存流量的實體網路卡。建議配置 2 個或以上實體網路卡,以便達到 VSAN 儲存流量負載平衡及容錯移轉機制。
  • 建議將 VSAN 儲存流量(VMkernel Port),在 Layer 2 層級以 VLAN 隔離以維持基本網路安全性。倘若,需要與其它網路流量共用(例如,VM 虛擬主機 、vSphere vMotion……等),那麼務必要搭配 NIOC(Network I/O Control)網路流量頻寬管控機制。
  • 在 Hybrid VSAN 運作架構中,若採用 1 Gbps 網路頻寬則必須規劃多個且專屬的實體網路卡,建議改為採用 10 Gbps 網路頻寬環境。
  • 在 All Flash VSAN 運作架構中,倘若採用 SATA SSD 固態硬碟時仍可採用 10 Gbps 網路頻寬環境,倘若採用 SAS、NVMe、PCIe 或 Ultra DIMM 等快閃儲存資源時,建議採用 25 Gbps 或 40 Gbps 網路頻寬環境(甚至 100 Gbps 也支援)。






虛擬網路架構

了解 VSAN 運作架構中實體網路環境的部分後,接下來我們將 VSAN 叢集的規劃設計重點轉移到 vSphere 虛擬化環境中,我們將依序討論 vSwitch 虛擬網路交換器和 VMkernel Port,然後再深入至 NIC Teaming 負載平衡機制及交換器探索機制的部分。


vSwitch 虛擬網路交換器

在 VSAN 運作環境中,支援「標準型交換器」(vNetwork Standard Switch,vSS)或「分散式交換器」(vNetwork Distributed Switch,vDS)。VMware 最佳作法,建議管理人員採用 vDS 分散式交換器,主要原因是 vSS 並不支援相關進階管理功能,並會增加企業及組織在管理 VSAN 運作環境中的營運成本,舉例來說,vSS 不支援 LBT(Load Based Teaming)負載平衡機制 、LLDP(Link Layer Discovery Protocol)交換器環境探索機制 、NIOC(Network IO Control)網路流量管控機制……等。
請注意! 有關 vSS 標準型交換器及 vDS 分散式交換器,這兩種虛擬化網路交換器的功能差異詳細說明,請參考 VMware KB 1010555 文件內容。
圖 10、vDS 分散式交換器啟用 NIOC 網路流量管控示意圖

值得注意的是,當 vDS 分散式交換器啟用 NIOC 網路流量管控機制後,共有 3 種管控流量的方式分別是「共用率值」(Share)、「保留」(Reservation)、「限制」(Limit)。VMware 最佳作法,考量網路頻寬整體使用率及管理方便度和靈活性,建議採用共用率值的方式進行網路頻寬的管控動作。只要在 vSphere Web Client 管理介面中,依序點選「首頁 > 網路功能 > vDS Switch > 管理 > 資源配置」項目,即可針對網路流量進行頻寬管理的組態設定。

此外,如果 VM 虛擬主機有啟用 vSphere FT 高可用性機制的話,那麼也請將 vSphere FT 網路流量的共用率值提升,因為 vSphere FT 為「延遲時間敏感」(Latency-Sensitive)類型的網路流量,倘若發生網路頻寬不足的情況將會造成受保護的 VM 虛擬主機,發生非預設的運作錯誤。

圖 11、vDS 分散式交換器啟用 NIOC 網路流量管控機制



VMkernel Port

完成 vSwitch 虛擬網路交換器的規劃後,接著便是新增 VMkernel Port 來處理 VSAN 儲存流量。基本上,ESXi 虛擬化平台上所有類型的流量,都會透過 VMkernel Port 服務類型的組態設定後進行傳送,並且在 VMkernel Port 當中除了 ESXi 主機的管理網路流量之外,還有其它類型的網路流量。舉例來說,VMkernel Port 還負責 vSphere vMotion、iSCSI、NAS/NFS、VSAN、vSphere Replication 及 vSphere FT……等網路流量。

在舊版 vSphere 5.5 時,VMkernel Port 網路流量類型只有 4 種。在新版 vSphere 6.0 運作環境中,VMkernel Port 網路流量則細分為 7 種,其實是將原本歸納於管理流量的相關網路流量,再細分後拆出來成為獨立的網路流量,分別是佈建流量、vSphere Replication 流量、vSphere Replication NFC 流量。

其中,「佈建流量」負責處理 VM 虛擬主機「複製」(Cloning)、「冷遷移」(Cold Migration),以及建立「快照」(Snapshot)時所產生的網路流量,同時當採用的儲存資源若未支援 VAAI(VMware vSphere Storage APIs Array Integration)硬體卸載功能時,產生的佈建網路流量將會更為明顯。
請注意! 有關 VAAI 硬體卸載功能的詳細資訊,請參考 VMware KB 1021976

「vSphere 複寫流量」項目,則是負責處理 ESXi 主機傳輸複寫資料至 vSphere Replication 虛擬設備時使用,「vSphere 複寫 NFC 流量」項目,負責處理 vSphere Replication 虛擬設備從網路環境複製檔案,至 ESXi 主機 Datastore 儲存資源之間的網路流量。

請依序執行下列操作步驟,即可透過 vSphere Web Client 管理工具建立 VMkernel Port,並加入至現有的 vSwitch 虛擬網路交換器中:

1. 在本文實作環境中,請開啟瀏覽器鍵入網址 https://vcenter.vdi.weithenn.org:9443/vsphere-client,鍵入管理者帳號密碼後便能透過 vSphere Web Client 管理工具,連接至 vCenter Server 執行個體。
2. 依序點選「首頁 > 主機和叢集」項目後,點選準備建立 VMkernel Port 的 ESXi 主機。
3. 依序點選「管理 > 網路功能 > VMkernel 介面卡」項目後,按下「新增網路」圖示。此時,管理畫面將會彈出新增網路精靈視窗。
4. 在選取連線類型視窗中,請點選「VMkernel 網路介面卡」項目後,按下一步鈕。
5. 在本文實作環境中,我們要將 VSAN 用途的 VMkernel Port 加入至現有的 vDS 分散式交換器中,因此選擇「選取現有網路」項目後按下瀏覽鈕,選擇要將 VMkernel Port 加入至哪個連接埠群組內(本文實作環境中,vDS 分散式交換器名稱為 Dswitch,而連接埠群組名稱為 DPortGroup),請按下一步鈕繼續組態設定程序。
6. 在連接埠內容頁面中,請於啟用服務設定區塊中勾選「Virtual SAN 流量」項目,以便為此 VMkernel Port 啟用 VSAN 儲存流量,請按下一步鈕繼續組態設定程序(如圖 12 所示)。
7. 在 IPv4 設定頁面中,請為 VMkernel Port 指定採用 DHCP 動態取得 IPv4 位址,或選擇採用靜態 IPv4 設定,手動為 VMkernel Port 指定 IP 位址及子網路遮罩等網路資訊。建議為每台 VSAN 叢集節點主機設定固定的 IPv4 位址,請按下一步鈕。
8. 在即將完成頁面中,檢視 VMkernel Port 組態設定內容正確無誤後,按下完成鈕系統便立即於剛才選定的 vDS 分散式交換器,以及所屬的連接埠群組中建立 VMkernel Port 並啟用 VSAN 儲存流量功能。

圖 12、建立 VSAN 用途的 VMkernel Port 並勾選啟用 VSAN 流量項目

請注意! 倘若 VSAN 用途的 VMkernel Port 網段,與 ESXi 主機的管理網路不同(採用不同預設閘道及 DNS 伺服器 IP 位址),那麼便需要建立及採用非預設值的 TCP/IP 堆疊。有關建立 VSAN 用途的 VMkernel Port 及 TCP/IP 堆疊的詳細資訊,請參考 VMware KB 2058368 文件內容。



停用流量管控機制

在 VMware VSAN 軟體定義儲存的網路環境中,VSAN 不管採用 vSS 標準型交換器或 vDS 分散式交換器,都必須與 ESXi 主機的實體網路卡(在 vSphere 環境中稱為 Uplink)進行關聯,以便屆時其上運作的 VM 虛擬主機能夠透過 Uplink 與實體網路環境溝通。

預設情況下,在 vSphere 虛擬化環境中所有的 Uplink 都會啟用「流量管控」(Flow Control)機制。因為,在乙太網路環境運作架構中,倘若 ESXi 主機不堪網路流量沈重的工作負載時,將會送出「暫停封包」(Pause Frames),以便通知在網路流量發送端暫時停止網路傳輸。

但是,在 VSAN 運作環境中已經內建「壅塞管理」(Congestion Management)機制,能夠有效防止因為網路流量爆發而產生壅塞的情況,或者是因為快取及緩衝機制所導致的壅塞。因此,VMware 官方最佳作法為建議將 VSAN 叢集中所有 ESXi 成員主機,組態設定 VSAN 用途的 VMkernel Port「停用」(Disable)Flow Control 機制,以避免與內建的壅塞管理機制互相干擾。
請注意! 有關如何在 VSAN 叢集節點主機中,組態設定 VMkernel Port 停用 Flow Control 機制的詳細資訊,請參考 VMware KB 1013413 文章內容。



NIC Teaming

在 VSAN 運作架構中啟用 NIC Teaming 功能後,若採用「Port ID」、「Source MAC」、「IP Hash」等原則時,其實僅具備高可用性(容錯移轉)特色並沒有負載平衡功能。VMware 最佳作法,當採用 vDS 分散式交換器時能夠使用特殊 NIC Teaming 機制,也就是「LBT(Load Based Teaming)」的負載平衡機制,啟用後將會每隔 30 秒偵測實體網路卡流量並進行流量負載平衡作業。

圖 13、LBT(Load Based Teaming)負載平衡機制運作示意圖

圖 14、將 NIC Teaming 負載平衡機制調整為 LBT 模式

請注意! 有關 NIC Teaming 負載平衡及容錯移轉機制的詳細資訊,請參考 VMware KB 2006129KB 1004048 文件內容。



Jumbo Frames

VSAN 運作架構中支援 Jumbo Frames,但是並非運作 VSAN 環境的必要條件。在 VMware 的測試結果中,發現 Jumbo Frames 機制可以減少 CPU 使用率並提高輸送量,但是因為 vSphere 已經使用 TCP Segmentation Offload(TSO)及 Large Receive Offload(LRO)機制,所以 Jumbo Frames 的幫助其實是有限的。
請注意! 有關 TSO 及 LRO 的詳細資訊,請參考 VMware KB 2055140 文件內容。

VMware 最佳作法,建議採用現有的 MTU/Frame Size 即可。也就是說倘若企業及組織的資料中心內已經啟用 Jumbo Frames 機制,那麼 VSAN 用途的網路環境也請啟用 Jumbo Frames。倘若資料中心並沒有啟用 Jumbo Frames,那麼不必單獨為 VSAN 網路特地啟用 Jumbo Frames。

圖 15、在 vSphere 運作環境中啟用 Jumbo Frames 機制



Switch Discovery Protocol

在 vSphere 虛擬化網路環境中,偵測實體網路環境探索協定分別支援 CDP(Cisco Discovery Protocol)及 LLDP(Link Layer Discovery Protocol)。值得注意的是,採用 vSS 標準型交換器僅支援 CDP,採用 vDS 分散式交換器才支援 CDP/LLDP。同時,VMware 最佳作法為不管採用 CDP 或 LLDP 皆請開啟傳送及接受模式。

圖 16、啟用 LLDP 探索通訊協定並啟用傳送及接受模式



結語

透過本文的說明及實作,從實體網路環境到 vSphere 虛擬化網路環境,相信企業或組織的 IT 管理人員只要遵從 VMware 官方的最佳作法及建議進行設計規劃,便能建構出高可用性、高效能並具備靈活性的 VSAN 軟體定義儲存環境。

前言

在 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】




前言

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

  • 支援 4K Native Drives in 512e 運作模式。
  • 預設採用 SE Sparse 格式的虛擬磁碟,以便自動化執行空間回收機制。
  • 最大支援 512 個儲存裝置及 2,000 路徑 (舊版為 256 個儲存裝置及 1,024 路徑)。
  • CBRC (View Storage Accelerator) 空間由舊版的最大 2 GB 提升為 32 GB




支援 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 的相關資訊請參考 FAQ: Support statement for 512e and 4K Native drives for VMware vSphere and vSAN (2091600)




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

在最新版本 vSphere 6.5 當中採用的 VMFS 6 檔案系統,預設情況下便會採用「SE Sparse」虛擬磁碟格式。有關 SE Sparse 虛擬磁碟格式的功能說明,請參考:



事實上,這是基於「VAAI Unmap」運作機制並且已經運作一段時間了。簡單來說,就是空白的儲存空間可以被回收並釋放回儲存設備當中,在先前舊版 vSphere 的運作環境中,通常需要管理人員手動執行相關指令來執行空間回收的動作。現在,只要透過 GUI 圖形化操作介面即可達成。



如果,你還是習慣使用「esxcli」指令處理的話,那麼可以執行下列指令: (下列範例中 Datastore 名稱為 sharedVmfs-0)
esxcli storage vmfs reclaim config get -l sharedVmfs-0
Reclaim Granularity: 1048576 Bytes
Reclaim Priority: low

也可以透過「esxcli」指令將儲存層級調整為「High」:
esxcli storage vmfs reclaim config set -l sharedVmfs-0 -p high



最大支援 512 個 LUN 儲存裝置及 2,000 路徑

過去,在舊版 vSphere 運作環境中最大僅支援「256 個 LUN 儲存裝置」及「1,024 路徑」。現在,最新版本 vSphere 6.5 運作環境中擴大支援至「512 個 LUN 儲存裝置」及「2,000 路徑」。



CBRC aka View Storage Accelerator

在過去 CBRC (在 VDI 運作環境中稱之為 View Storage Accelerator) 最大僅支援至「2 GB」。現在,最新版本 vSphere 6.5 運作環境中擴大支援至「32 GB」。有關 CBRC 快取機制的相關資訊請參考站內文章:





參考資源


前言

在新一代 vSphere 6.5 虛擬化平台中,針對「安全性」(Security)的部分新增許多特色功能。同時,在兼顧安全性的同時又不失「管理」(Management)及「自動化」(Automation)等特性,如此一來才會讓企業及組織能夠順利及樂意使用這些安全性功能。



VM Encryption

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

透過 VM Encryption 加密機制可以獲得的優點如下:
1. 加密行為是發生在「Hypervisor 層級」而非 VM 虛擬主機層級,所以 Guest OS 及 Datastore 類型不會是影響加密的因素。
2. 加密機制是透過「原則」(Policy)來進行部署及管理作業。簡單來說,不管 VM 虛擬主機採用哪種 Guest OS 都可以進行加密。
3. 由於加密機制是在 Hypervisor 層級,所以不必監控 VM 虛擬主機是否有運作加密機制,同時「加密金鑰」(Key)也不會儲存在 VM 虛擬主機的記憶體當中。
4. 加密金鑰的管理作業是採用業界標準的「KMIP 1.1」,其中 vCenter Server 就是 KMIP Client 也是 KMIP 1.1 Key Manager。同時,管理人員也可以選擇 VM Keys 不要儲存在 vCenter Server 中。
5. 在 vSphere 6.5 當中 VM Encryption,採用 CPU 指令集中的「AES-NI」來進行加密的動作。此舉,可以有效降低 ESXi 主機的工作負載。




vMotion Encryption

針對 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 主機」之間,以確保兩端之間通訊所傳輸的資料無法被惡意人士所複製。




支援 Secure Boot

在新一代 vSphere 6.5 虛擬化平台中,同時支援「ESXi Hypervisor」及「VM 虛擬主機」啟用「安全啟動」(Secure Boot)機制。

ESXi - Secure Boot

當管理人員為 ESXi 主機啟用 Secure Boot 機制後,在 UEFI Firmware 中將會針對 ESXi Kernel 進行數位簽章的動作,確保只有通過安全認證的模組或 VIB 軟體套用包才能被啟動及使用。值得注意的是,當 ESXi 主機啟用 Secure Boot 機制後,只能在 ESXi 主機上安裝由 VMware 所簽署的 VIB (vSphere Installation Bundle) 套件包,其它 VIB 套件包則是無法強制進行安裝的。


VM - Secure Boot

首先,不管 VM 虛擬主機採用的是 Windows 或 Linux 作業系統,只要針對 VM 虛擬主機使用「EFI」後便可以勾選啟用 Secure Boot 機制。同樣的,當 VM 虛擬主機啟用 Secure Boot 機制之後,那麼只能安裝「通過簽署」的驅動程式。




增強的日誌機制

在過去 vSphere 的日誌機制,一直專注於故障排除的部分而未包含「安全」或「IT 操作」的部分。現在,可以得到詳細的日誌並透過 Syslog 機制,將 vCenter Server 的日誌傳送到 Vmware Log Insight。舉例來說,假設有台 VM 虛擬主機原本 vRAM 為 6GB,然後我們為它增加「4 GB」的 vRAM 空間此時便可以在日誌中看到相關資訊,或者是 VM 原本連接的 vSwitch 為 PCI 異動至「Non-PCI」 也將會詳細記錄下來。




自動化

後續,將會看到自動化作業的相關文件,例如,透過 PowerCLI 達到針對 VM 虛擬主機自動化加密及解密、針對大量 VM 虛擬主機同時啟用 Secure Boot 安全啟動機制、針對 VM 虛擬主機啟用 vMotion Encrypted……等。同時,這些自動化指令碼範例也將會上傳至 GitHub 中。



參考資源



課程簡介

  • 了解建置私有雲運作環境時對於實體的 網路、儲存、交換器…等設備該如何進行規劃,並且會帶來何種影響。
  • 了解在規劃私有雲環境時應該如何針對虛擬網路、儲存、交換器…等,將網路流量統一集中或者依服務類型進行切割,同時導入流量管控機制以達成網路與頻寬最佳利用率。
  • 了解在規劃私有雲環境時對於何種使用情境,適合採用哪種儲存設備類型如 DAS、NAS、SAN。
  • 熟悉及實作各種儲存設備種類及特性,以規劃出高可用性儲存架構。
  • 實作虛擬化環境網路傳輸高可用性機制 NIC Teaming、Failover。
  • 實作虛擬化環境 SAN 儲存傳輸高可用性機制 MPIO。
  • 實作虛擬化環境上運作的 VM 虛擬主機,其效能最佳化調校以及主機安全性調整。
  • 實作 VMware vSphere 虛擬化技術相關機制及運作原理,如 vMotion、HA (High Availability)、FT(Fault Tolerance)…等,並實作出可擴充性及高可用性虛擬化環境。



課程資訊

時間: 四、五、一、二、三 (09:10 ~ 17:20)
地點: 中華電信學院 (新北市板橋區民族路168號)
日期: 2016/11/17、11/18、11/21、11/22、11/23
網址:  VMware vSphere 建置與維護實作進階班


前言

在本篇文章當中,我們將介紹在 vSphere 6.5 版本當中全新打造的 vCSA(vCenter Server Appliance),除了在安裝方式簡化、管理工具 vSphere Web Client 改採「HTML5-based」技術之外,新版的 vCSA 也支援下列特色功能:
  • vCenter Server 平台遷移
  • 增強 vCSA 管理功能
  • vCSA 原生 HA(High Availability) 機制
  • 內建備份/還原機制




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 管理功能

在過去,當企業或組織需要建置 VUM (VMware Update Manager) 時,只能直接安裝在 Windows vCenter Server 或獨立的 Windows Server 主機中,並無法將 VUM 安裝在 vCSA 當中。現在,最新版本的 vCSA 6.5 已經具備 VUM 的功能,倘若你已經遷移運作環境至 vCSA 6.0 的話,那麼升級至最新 vCSA 6.5 版本時,遷移程序將會自動轉換 vCenter Configuration、Inventory、Alarm Data 等組態設定及統計數據。

新版 vCSA 6.5 在管理功能上也增強許多。現在,可以直接在 vCSA 管理介面中查看 CPU、記憶體、網路、資料庫、磁碟空間……等使用情況,有效改善過去 vCSA 欲查看這些硬體資源使用情況時必須依賴 CLI 指令的情況。




vCSA 原生 HA(High Availability) 機制

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




內建備份/還原機制

新版 vCSA 也同時內建「備份 / 還原」功能,讓管理人員可以直接透過 VAMI 或 API 的方式備份 vCenter Server 及 PSC (Platform Services Controller),不管 PSC 是採用「Embedded」或「External」的運作模式都支援。同時,當 VUMAuto Deploy 採用「Embedded」也可以同步進行備份作業。此外,備份好的資料可以選擇透過 SCP、HTTP(s)、FTP(s) 等通訊協定傳輸備份資料至儲存設備中。



vSphere Web Client 管理工具

過去 vSphere Web Client 管理工具,最被管理人員垢病的就是採用「Adobe Flex 平台 - Adobe Flash-based」技術,除了管理介面操作速度不理想之外,Flash 也常常有安全性問題的疑慮。但是,在新版 vCSA 6.5 當中仍持續改進相關機制直到退役為止 (後續將由 HTML 5-based 打造的管理工具接手):
  • 預設檢視模式為 Inventory Tree。
  • 原本「Manage」頁籤改名為「Configure」。
  • 移除「Related Objects」頁籤,並多出「Hosts、VMs、Datastores、Networks」等頁籤。
  • 管理介面運作效能改進 (VM 虛擬主機匯總功能並非舊版 50 VMs 而是 5,000 VMs)。
  • 管理介面將即時更新電力狀態、工作任務……等 (舊版必須手動更新更面)。



vSphere Client 管理工具

現在,新版 vCSA 6.5 的 vSphere Client 管理工具,也已經內建由「HTML 5-based」技術所打造 vSphere Client 管理工具,管理人員只要開啟瀏覽器後鍵入「http://<vCenter_FQDN>/ui」即可連結。同時,VMware 官方除了正常的 vCenter Server 發行週期之外,也會定期更新 vSphere Client 管理工具版本 (有關管理單台 ESXi 的 vSphere Host Client 管理工具詳細資訊,請參考站內文章 128 期 - 最新 VMware Host Client 直接管理單台 ESXi 主機)。




參考資源