網管人雜誌

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



文章目錄

前言
VM Groups 運作機制
          建立 VM Collections
          建立 Management Collections
          整合 VM Groups 啟用複寫機制
VM Start Order 運作機制
          實戰 VM Start Order 機制
          測試 VM Start Order 機制
結語





前言

在過去的 Windows Server 版本當中,倘若希望針對某群工作類型相同的 VM 虛擬主機,執行相同的管理動作如備份或複寫等作業時,並沒有內建機制可以幫助 IT 管理人員快速執行此類動作。因此,IT 管理人員必須要非常了解每台 VM 虛擬主機的功能及用途,所以 VM 虛擬主機的命名規則也相形重要,否則將會造成 VM 虛擬主機辨識上的困擾。然而,這樣的運作架構規模若較小則只會有輕微的管理負擔,倘若企業及組織的運作規模隨著業務不斷增大時,每增加 1 個維運任務便會相形增加管理成本。

現在,最新 Windows Server 2016 版本當中,內建「VM Groups」管理機制能有效幫助解決此困擾。舉例來說,我們希望能夠針對一群負責前端 Web 伺服器的 VM 虛擬主機進行複寫的動作時,在沒有 VM Groups 管理機制的幫助下,管理人員只能針對「每台」VM 虛擬主機逐一進行複寫的組態設定動作。

但是,透過 VM Groups 管理機制的幫助之下,只要為負責前端 Web 伺服器建立 1 個 VM Groups,然後將負責前端 Web 伺服器的 VM 虛擬主機加入該 VM Groups,後續便只要針對這個 VM Groups 啟用複寫的組態設定後,那麼系統便會同時針對多台 VM 虛擬主機執行啟用複寫的組態設定。

圖 1、VM Groups 運作架構示意圖





VM Groups 運作機制

簡單來說,VM Groups 管理機制是透過「邏輯」的方式,將相同類型或用途的 VM 虛擬主機群組起來,後續便可以進行相對應的管理動作,例如,備份、複寫……等。在管理工具方面,管理人員可以透過 PowerShell、Hyper-V 管理員、SCVMM 來進行管理作業。在 VM Groups 的運作架構中,支援下列 2 種不同類型:

  • VM Collections: 針對「VM 虛擬主機」進行的邏輯集合,讓 IT 管理人員可以一次針對這些群組後的 VM 虛擬主機執行統一的管理動作,而無須單獨針對「每台」VM 虛擬主機執行管理作業。
  • Management Collections: 針對「VM Collections」進行的邏輯集合,也就是可以針對 VM Collections 後的群組再建立群組,以建立更具彈性的管理機制。




建立 VM Collections

那麼我們直接進入實作 VM Groups 管理機制 VM Collections 的部分吧,首先在本文實作環境中 Windows Server 2016 主機內共有 3 台 VM 虛擬主機,這 3 台 VM 虛擬主機的名稱分別是 VM1、VM2、VM3,接著我們建立名稱為「TestVMG1」的 VM Collections。
請注意,雖然 VM 虛擬主機名稱與客體作業系統電腦名稱並無絕對關係。但是,在實務管理上通常 VM 虛擬主機名稱會與客體作業系統的電腦名稱一致,以避免後續管理上可能產生的困擾。
圖 2、為 3 台 VM 虛擬主機建立名稱為 TestVMG1 的 VM Groups

在本文實作中,我們直接採用 Windows Server 2016 內建的 PowerShell 管理工具進行實作。首先,為了便於日後管理所以透過 PowerShell 建立參數的方式,配合「Get-VM」指令抓取稍後要加入 VM Collections 的 3 台 VM 虛擬主機名稱,接著採用「New-VMGroup」指令搭配「-GroupType」參數,建立名稱為「TestVMG1」的 VM Collections。

圖 3、透過 PowerShell 抓取 3 台 VM 虛擬主機名稱及建立 VM Collections

同樣的,為了後續管理方便我們透過 Get-VMGroup 指令搭配 -Name 參數,為名稱 TestVMG1 的 VM Collections 建立參數名稱,然後就可以透過 Add-VMGroupMember 指令,將剛才指定的 3 台 VM 虛擬主機加入至 TestVMG1 的 VM Collections 當中。

圖 4、將剛才指定的 3 台 VM 虛擬主機加入至 TestVMG1 的 VM Collections 當中

順利將指定的 3 台 VM 虛擬主機加入至 TestVMG1 的 VM Collections 之後,便可以使用 Get-VM 指令查詢指定的 VM 虛擬主機,是否已經順利加入指定的 VM Collections 當中。然而,Get-VM 指令將會顯示此台 Hyper-V 主機上「所有」的 VM 虛擬主機,倘若 Hyper-V 主機上的 VM 虛擬主機數量過多時將會導致查詢上的困擾,此時可以改為採用 Get-VMGroup 指令,查詢 Hyper-V 主機上有哪些 VM Collections 以及加入的 VM 虛擬主機。

圖 5、查詢指定的 VM 虛擬主機是否順利加入指定的 VM Collections

然而,在企業及組織的運作環境中通常並沒有那麼單純,有時某些 VM 虛擬主機並非單一功能或用途,可能身兼不同的角色或在特定時間需要身兼多種角色。此時,為了能夠因應企業及組織多變的環境,VM Groups 也提供更加彈性的機制,也就是單台 VM 虛擬主機可以「同時」加入不同的 VM Collections 當中。

圖 6、將單台 VM 虛擬主機同時加入至不同的 VM Collections 當中

舉例來說,某台 VM 虛擬主機除了希望能夠定期執行備份作業之外,同時也必須加入 Hyper-V Replica 複寫清單當中,定期執行複寫作業至其它 Hyper-V 站台備存,以便發生災難事件時便能夠在最短時間內恢復正常運作。根據這樣的需求,我們可以分別建立備份用途的 VM Collections 以及複寫用途的 VM Collections,然後將指定的 VM 虛擬主機同時加入至這 2 個不同用途的 VM Collections 當中即可。

接續剛才的實作環境,我們假設名稱為 VM1 的 VM 虛擬主機,除了原本加入的 TestVMG1 之外,還要加入另一個用途的 VM Collections。所以,我們再次使用 New-VMGroup 指令,建立名稱為 TestVMG2 的 VM Collections 然後將 VM1 虛擬主機加入 TestVMG2 當中。同樣的,組態設定完成後可以透過 Get-VM 或 Get-VMGroup 指令,查詢 VM1 虛擬主機是否順利加入 2 個不同用途的 VM Collections。

圖 7、將 VM1 虛擬主機加入 2 個不同用途的 VM Collections 當中



建立 Management Collections

當 Hyper-V 虛擬化環境運作規模較小時,相信採用 VM Groups 中的 VM Collections 管理機制便能迎刃有餘,然而當運作規模逐漸變大時單靠 VM Groups 管理機制便會顯得不足。因此,在 VM Groups 當中還有另一個 Management Collections 管理機制,可以讓整個 VM Groups 管理機制更為完備。

值得注意的是,剛才實作的 VM Collections 管理機制目標對象為「VM 虛擬主機」,而 Management Collections 管理機制目標對象則為「VM Collections」,也就是可以把建立好的 VM Collections 再進行邏輯集合。

舉例來說,在企業及組織的 Hyper-V 虛擬化運作環境中,我們分別透過 VM Collections 管理機制,將一群負責 Web 網頁服務的 VM 虛擬主機群組起來執行備份作業,同時我們也將另一群負責 DHCP 伺服器的 VM 虛擬主機群組起來執行備份作業。

此時,我們便可以針對「備份」作業這個工作任務,建立 1 個 Management Collections,然後將負責 Web 網頁服務及 DHCP 伺服器的 VM Collections,加入至負責備份工作任務的 Management Collections。屆時,只要針對負責備份工作任務的 Management Collections,下達執行備份工作任務的指令後,便會直接為 2 個所屬的 VM Collections 及加入的 VM 虛擬主機進行備份作業。

圖 8、建立 Management Collections 並群組 2 個不同 VM Collections

事實上,建立 Management Collections 的操作步驟與剛才實作 VM Collections 類似,不同的部分在於使用 New-VMGroup 指令搭配 -GroupType 參數時,記得參數值必須設定為「ManagementCollectionType」才行。同時,在使用 Add-VMGroupMember 指令搭配參數時,則必須改為採用「-VMGroupMember」參數即可。
在建立 VM Collections 時,使用 New-VMGroup 指令搭配 -GroupType 參數值為 VMCollectionType,而使用 Add-VMGroupMember 指令時則是搭配 -VM 參數。

了解建立 Management Collections 的方式,與剛才實作建立 VM Collections 的不同之處後,我們便可以透過同樣的操作方式建立 Management Collections。在本實作中,我們建立名稱為「TestVMGM1」的 Management Collections,然後將剛才所建立的 TestVMG1、TestVMG2 加入至此 Management Collections 內。

圖 9、將 TestVMG1、TestVMG2 加入名稱為 TestVMGM1 的 Management Collections 內

由於剛才已經提到,Management Collections 的目標對象為 VM Collections 而非 VM 虛擬主機。因此,當我們建立好 Management Collections 之後,倘若需要查詢是否套用生效時若採用先前的 Get-VM 指令將無法順利查詢到結果,必須改為採用 Get-VMGroup 指令才能夠順利查詢。

圖 10、查詢建立的 Management Collections 是否套用生效

同樣的,VM Groups 的彈性設計,可以讓 Management Collections 再包括 Management Collections,讓整個管理作業更富彈性且應用範圍更廣。舉例來說,我們可以再建立名稱為「OutsideGroup」的 Management Collections,然後將剛才建立的 TestVMGM1 加入到這個新建立的 OutsideGroup 當中。因為,操作步驟相同所以便不再贅述,在建立完畢後我們同樣使用 Get-VMGroup 指令,即可查詢操作的步驟是否套用生效。

圖 11、讓 Management Collections 再包括 Management Collections



整合 VM Groups 啟用複寫機制

在 Hyper-V 管理員的操作介面中,管理人員倘若要針對「單台」VM 虛擬主機啟用 Hyper-V Replica 複寫機制非常簡單,只要點選該台 VM 虛擬主機便可以在右鍵選單中點選「啟用複寫」選項。然而,若是希望一次針對多台 VM 虛擬主機同時啟用複寫時,在 Hyper-V 管理員操作介面中便會發現,選擇多台 VM 虛擬主機後在右鍵選單中並沒有啟用複寫選項可供選擇。

圖 12、選擇多台 VM 虛擬主機後在右鍵選單中並沒有啟用複寫選項可供選擇

在本文一開始時,我們便已經說明 VM Groups 機制可以幫助降低管理負擔。同時,我們也已經分別建立好 VM Collections 及 Management Collections,接下來我們便實作透過 VM Groups 機制,一次針對 VM Collections 所屬的 VM 虛擬主機啟用 Hyper-V Replica 複寫機制。

在本文實作環境中,目前 VM1、VM2、VM3 這 3 台 VM 虛擬主機,運作在名稱為 HV1 的 Hyper-V 主機上(FQDN 為 HV1.weithenn.org),稍後我們將透過 PowerShell 組態設定 VM1、VM2、VM3 這 3 台 VM 虛擬主機,複寫至名稱為「HV2.weithenn.org」的 Hyper-V 主機。

整個 VM Groups 啟用複寫作業只要執行 2 行指令即可完成,首先使用 Enable-VMReplication 指令告訴 Hyper-V 主機,要將 VM 虛擬主機複寫到哪台目的端 Hyper-V 主機,同時透過 -VM 參數指定哪些 VM 虛擬主機要啟用 Hyper-V Replica 複寫機制,此時便可以使用剛才 VM1、VM2、VM3 所加入的「TestVMG1」VM Collections。在執行指令後,便會在 Hyper-V 管理員操作介面中的「工作狀態」欄位,看到 VM1、VM2、VM3 虛擬主機顯示「啟用複寫–成功」的訊息。

接著,執行 Start-VMInitialReplication 指令,告訴 Hyper-V 主機哪些 VM 虛擬主機要開始進行複寫初始化的動作,也就是開始將 VM1、VM2、VM3 這 3 台 VM 虛擬主機,透過 Hyper-V Replica 複寫技術傳送至目的端 Hyper-V 主機。同樣的,在指定 VM 虛擬主機時使用剛才 VM1、VM2、VM3 所加入的「TestVMG1」VM Collections 即可。

圖 13、整合 VM Collections 管理機制一次針對多台 VM 虛擬主機啟用複寫機制





VM Start Order 運作機制

在過去舊版的 Hyper-V 虛擬化平台運作環境中,雖然我們可以在容錯移轉叢集中針對指定的 VM 虛擬主機,指定優先順序以便執行 Live Migration 即時遷移大量 VM 虛擬主機時,可以讓高優先順序的 VM 虛擬主機優先進行即時遷移的動作,或者是在執行 Quick Migration 快速遷移時,讓高優先順序的 VM 虛擬主機優先遷移至目的端 Hyper-V 主機。

但是,這可能還是無法滿足企業及組織多變的環境需求,舉例來說,倘若 Hyper-V 虛擬化環境中部分叢集節點主機發生災難事件時,此時將會透過 Quick Migration 快速遷移機制,將 VM 虛擬主機快速遷移至容錯移轉叢集中其它存活的叢集節點主機,然而因為災難事件導致必須遷移數量眾多的 VM 虛擬主機,因此 VM 虛擬主機遷移及啟動的順序便無法完全掌握,但有些 VM 虛擬主機上所運作的服務有相依性或先後順序之分,例如,應該先啟動擔任 Active Directory 服務 VM 虛擬主機,再啟動其它 VM 虛擬主機,或者是應該先啟動擔任資料庫角色的 VM 虛擬主機後,再啟動擔任前端網頁伺服器角色的 VM 虛擬主機。

因此,在過往的 Hyper-V 虛擬化環境中倘若發生這樣的管理需求時,往往需要管理人員介入處理才行,例如,VM 虛擬主機服務若有相依性問題而無法順利存取時,則重新啟動相關服務或重新啟動 VM 虛擬主機。

現在,透過 Windows Server 2016 容錯移轉叢集中「VM Start Order」新的特色功能,便可以有效解決過往 VM 虛擬主機相依性或先後順序啟動的問題。舉例來說,透過 VM Start Order 特色功能,我們可以組態設定擔任資料庫角色的 VM 虛擬主機,一定要優先於擔任前端網頁伺服器角色的 VM 虛擬主機啟動,同時必須在擔任資料庫角色的 VM 虛擬主機啟動後間隔一段時間( 例如,5 分鐘 ),前端網頁伺服器角色的 VM 虛擬主機才會接著啟動。

圖 14、VM Start Order 運作機制示意圖

此外,除了設定 VM 虛擬主機啟動順序及相依性之外,在啟動順序的部分還可以指定「低、中、高」不同的優先順序。下列便是適合採用此機制的一些應用情境:

  • 多層式應用程式架構: 啟動順序為「Database VMs > Middle-Tier VMs > Front-End VMs」。
  • CPS 整合式系統: 啟動順序為「Infrastructure VMs( 例如,Active Directory) > Application VMs(例如,SQL)> Front-End VMs」。
  • 超融合式容錯移轉叢集: 啟動順序為「Utility VMs > Management VMs > Tenant VMs」。
  • 融合式容錯移轉叢集: 啟動順序為「Active Directory VM > Hosting VMs」。




實戰 VM Start Order 機制

在開始實作 VM Start Order 機制之前,為了讓讀者能夠更了解整個組態設定的原則,以便 VM 虛擬主機能夠依照你希望的優先順序進行啟動。在 VM Start Order 運作機制的組態設定上,共區分為「Set、Group、Resource」等 3 個層級以便管理人員能夠更加彈性的調整 VM 虛擬主機啟動的優先順序。

圖 15、VM Start Order 運作機制 3 個層級架構示意圖

在本文實作環境中容錯移轉叢集內,共有 3 台 VM 虛擬主機分別是 Database、App01、App02。那麼,我們開始實作 VM Start Order 機制,組態設定 Database 這台 VM 虛擬主機開機後經過 20 秒,接著系統才會自動啟動 App01、App02 這 2 台 VM 虛擬主機。

圖 16、目前容錯移轉叢集內共有 3 台 VM 虛擬主機

請開啟 PowerShell 指令視窗,首先以 New-CimSession 指令與容錯移轉叢集建立連線,接著透過 New-ClusterGroupSet 指令,建立 2 個名稱為「DB-VMs 及 App-VMs」類型的 Set 層級。那麼,我們來了解一下目前已知欄位的意義為何:

  • Name: 顯示 Set 層級的名稱,此實作環境為 DB-VMs 及 App-VMs。
  • PSComputerName: 此 Set 層級作用的容錯移轉叢集名稱,此實作環境容錯移轉叢集名稱為 HV-Cluster (FQDN 為 HV-Cluster.weithenn.org)。

圖 17、建立 2 個名稱為 DB-VMs 及 App-VMs 類型的 Set 層級

然後,透過 Add-ClusterGroupToSet 指令,分別將 Database 虛擬主機加入至 DB-VMs 的 Set 層級當中,以及將 App01、App02 虛擬主機加入至 App-VMs 的 Set 層級當中。接著,再透過 Get-ClusterGroupSet 指令,確認是否將指定的 VM 虛擬主機加入至相對應的 Set 層級內。那麼,我們來了解一下目前已知欄位的意義為何:

  • GroupNames: 加入此 Set 層級的 VM 虛擬主機,此實作環境中加入 App-VMs 的有 App01、App02 虛擬主機,而加入 DB-VMs 的則是 Database 虛擬主機。

圖 18、將指定的 VM 虛擬主機加入至相對應的 Set 層級當中

最後,我們設定這 2 個 Set 層級之間的依賴關係,也就是組態設定當 Database 虛擬主機開機經過 20 秒之後,那麼系統才會自動啟動 App01、App02 這 2 台 VM 虛擬主機。請透過 Add-ClusterGroupSetDependency 指令,組態設定 DB-VMs 為 App-VMs 的提供者,也就是 DB-VMs 內的 VM 虛擬主機開機並經過 20 秒之後,才會啟動 App-VMs 內的 VM 虛擬主機。那麼,我們來了解一下目前已知欄位的意義為何:

  • ProviderNames: 此 Set 層級的提供者,此實作環境中 DB-VMs 為 App-VMs 的提供者,所以加入 App-VMs 的 VM 虛擬主機,必須等到 DB-VMs 所屬的 VM 虛擬主機啟動並等待指定的時間後才能啟動。
  • StartupDelayTrigger: 定義延遲啟動的觸發動作為何共支援 2 個選項分別是 Delay 及 Online,預設值為「Delay」也就是等待提供者 Set 層級中 StartupDelay 欄位的秒數後,那麼這個 Set 層所屬的 VM 虛擬主機才能啟動。倘若組態設定為「Online」時,那麼必須等到提供者 Set 層級中 VM 虛擬主機的狀態為 Online 之後才能啟動。
  • StartupCount: 定義更具彈性的啟動順序。
  • StartupDelay: 定義延遲多少秒之後才執行啟動 VM 虛擬主機的動作。

圖 19、設定這 2 個 Set 層級之間的依賴關係 DB-VMs 為 App-VMs 的提供者

當然,後續可以採用 Set-ClusterGroupSet 指令調整組態設定值,例如,希望 Database 虛擬主機啟動後延遲 5 分鐘才啟動 App01、App02 虛擬主機,請使用「Set-ClusterGroupSet -Name DB-VMs -StartupDelay 300指令即可。



測試 VM Start Order 機制

組態設定完畢之後,我們可以快速驗證 VM Start Order 機制是否能夠順利運作。請開啟容錯移轉叢集管理員,選擇本文實作的 3 台 VM 虛擬主機之後,在右鍵選單中選擇「啟動」項目,也就是執行 3 台 VM 虛擬主機「同時」啟動的動作,然後觀察 VM 虛擬主機會發生什麼樣的情況。

圖 20、執行 3 台 VM 虛擬主機同時啟動的動作

倘若未組態設定 VM Start Order 運作機制的話,那麼正常情況下 3 台 VM 虛擬主機應該會同時執行啟動的動作。然而,在前面的 VM Start Order 組態設定中,我們已經定義必須要 Database 虛擬主機啟動並等待 20 秒之後,那麼 App01、App02 虛擬主機才會執行啟動的動作。

因此,你可以發現執行 3 台 VM 虛擬主機同時啟動的動作後,只有 Database 虛擬主機自己先啟動,然後 App01、App02 虛擬主機狀態為「正在啟動」(等待中),然後經過 20 秒之後才會正式執行啟動的動作。
倘若,不要執行 3 台 VM 虛擬主機同時啟動的動作,而是刻意只選擇 App01、App02 這 2 台虛擬主機執行啟動的動作時,那麼會發生什麼事情呢 ?你將會發現系統仍會自動先啟動 Database 虛擬主機,並等待 20 秒之後才啟動 App01、App02 虛擬主機。
圖 21、VM Start Order 運作機制順利運作





結語

透過本文的說明及實作演練,相信讀者已經完全了解 VM Group 及 VM Start Order 這 2 項機制,確實可以幫助企業及組織降低維運成本,同時也能降低管理人員的管理負擔。

Q. 在 Failover Cluster 運作環境中,出現「Computer object could not be updated」的錯誤訊息?

Error Message:
當建立好「容錯移轉叢集」(Failover Cluster)運作環境後,進行相關操作時常常會出現下列錯誤訊息說明無法更新 Computer Object? 例如,建立 SOFS 服務時,雖然在 DC 網域控制站中還是有出現 SOFS 電腦帳戶,但就是會出現警告訊息?
The Computer object associated with cluster network name resource 'Backup' could not be updated.
The text for the associated error code is: Unable to protect the Virtual Computer Object (VCO) from accidental deletion.
The cluster identity 'WSFC$' may lack permissions required to update the object. Please work with your domain administrator to ensure that the cluster identity can update computer objects in the domain.



Ans:
簡單來說,這個問題發生的原因在於「容錯移轉叢集電腦帳戶」(本次實作環境為 WSFC),不具備 DC 網域控制站中「Computers」容器「Create Computer objects」的權限所導致。只要讓「容錯移轉叢集電腦帳戶」具備權限即可。

請開啟 Active Directory Users and Computers 後依序點選「View > Advanced Features」,接著點選「Computers > Properties」,在彈出的 Computers Properties 視窗中點選至「Security」頁籤,然後點選「Advanced > wsfc$ >  Edit」勾選「Create Computer objects」項目即可。


後續,再次嘗試建立 SOFS 服務時,容錯移轉叢集電腦帳戶因為具備新增 Computers 容器物件的權限,便不會再出現警告訊息了。





參考資源


課程簡介

  • 熟悉雲端運算定義:五種服務特徵、四種部署模型、三種服務類型。
  • 針對企業及組織建構私有雲虛擬運算環境時,從硬體伺服器的 CPU 處理器及週邊元件如何選擇開始,到 vCPU 及 vRAM 的規劃設計,以便建構出最佳運作效能的基礎架構。
  • 針對企業及組織建構私有雲虛擬網路環境時,如何規劃設計 VM 虛擬主機各種傳輸流量,例如,VM 網路服務流量、高可用性遷移流量、容錯移轉流量…等以避免造成傳輸瓶頸。
  • 針對企業及組織建構私有雲虛擬儲存環境時,從針對不同儲存設備類型的功能及特性,到私有雲運作環境該如何規劃及估算儲存設備 IOPS 效能,以避免資料傳輸瓶頸產生 VM 虛擬主機運作效能不佳的情況。



課程資訊

日期: 2017/7/29 ~ 2017/8/19
時間: 每週六 09:00 ~ 17:00
地點: 台中科技大學 (台中市北區三民路 91 號 2 樓)
網址: 全方位企業私有雲規劃與建置之最佳化調校實務班




活動簡介

雲端運算正在改變整個世界。不論是以雲端技術提升系統運作效率,或是以雲端模式推動企業創新與轉型,雲端技術都扮演著推動企業變革的關鍵角色。而諸如快速成長的物聯網、大數據分析、機器學習、人工智慧等新興應用,也都乘著雲端的翅膀起飛。

雲端不只是企業數位轉型的契機,更將深入 IT 的各個面向,成為企業 IT 的新常態。在萬流歸雲的趨勢下,iThome Cloud Summit 2017 雲端大會特別規畫 8 大趨勢主題,以及現場能親手體驗雲端威力的 Hands-on Lab 實機體驗課程,試圖勾勒出現代化雲端技術更為完整的面貌,誠摯邀請您一起來探究現代化雲端技術的新潛能。



活動資訊

  • 日期: 2017 年 6 月 23 日 (星期五)
  • 時間: 8:00 ~ 17:00
  • 地點: 臺北市信義區菸廠路 88 號 (臺北文創大樓)
  • 報名: 活動報名



活動內容






前言

簡單來說,常用來在 Linux 作業系統中的 sudo 套件被發現存在嚴重漏洞,惡意人士透過「get_process_ttyname ()」這個函數的漏洞可以讓任何擁有 Shell 帳戶使用 Root 權限,即便 RHEL / CentOS 啟用 SELinux 安全性機制的情況下仍無法阻擋。因此,請盡量修補你所管理的 Linux 作業系統。



受影響的 Linux 發行版本

  • Red Hat Enterprise Linux Server (v. 5 ELS) (sudo)
  • Red Hat Enterprise Linux 6 (sudo)
  • Red Hat Enterprise Linux 7 (sudo)
  • Debian wheezy
  • Debian jessie
  • Debian stretch
  • Debian sid
  • Ubuntu 17.04
  • Ubuntu 16.10
  • Ubuntu 16.04 LTS
  • Ubuntu 14.04 LTS
  • SUSE Linux Enterprise Software Development Kit 12-SP2
  • SUSE Linux Enterprise Server for Raspberry Pi 12-SP2
  • SUSE Linux Enterprise Server 12-SP2
  • SUSE Linux Enterprise Desktop 12-SP2
  • OpenSuse




檢測系統中的 sudo 版本是否受漏洞影響

管理人員可以至 Red Hat Customer Portal - sudo: Privilege escalation via improper get_process_ttyname() parsing 下載 sudo 漏洞檢測工具  cve-2017-1000367.sh 進行檢測作業。
簡單來說,只要 sudo 套件版本是 1.8.6p7 ~ 1.8.20 都會受到此漏洞的影響,必須採用 sudo 1.8.20p1 套件版本才順利修復此漏洞。對應到 RHEL 7 / CentOS 7 的話版本則是 sudo-1.8.6p7-22.el7_3.x86_64 才對。

如下所示,在還沒有進行 sudo 套件更新作業之前,檢測結果可以看到目前 CentOS 7.3 當中的 sudo 套件 (sudo-1.8.6p7-20.el7_3.x86_64) 仍受此漏洞所影響。
# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux centos73.weithenn.org 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
# rpm -qa sudo
sudo-1.8.6p7-20.el7.x86_64
# ./cve-2017-1000367.sh

This script is primarily designed to detect CVE-2017-1000367 on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

Detected 'sudo' package is 'sudo-1.8.6p7-20.el7.x86_64'.
This 'sudo' version is vulnerable.
Update 'sudo' package when possible, there are no mitigations available.
Follow https://access.redhat.com/security/vulnerabilities/3059071 for advice.

圖、系統使用具有 sudo 漏洞的套件版本



更新 sudo 套件版本修復漏洞

簡單來說,我們必須將 CentOS 7.3 當中的 sudo 套件版本從原本的 sudo-1.8.6p7-20.el7_3.x86_64 升級至 sudo-1.8.6p7-22.el7_3.x86_64 版本才行。其它 CentOS 版本對應的 sudo 套件版本資訊,請參考 Red Hat Customer Portal - Important: sudo security udpate。請執行「yum -y update」即可下載及更新 sudo 修復漏洞的套件版本 (事實上,昨天也就是 2017 年 5 月 31 日還無法下載成功,今天 2017 年 6 月 1 日測試已經可以順利更新!!)。
# yum -y update
# yum info sudo
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * elrepo: ftp.yz.yamagata-u.ac.jp
 * epel: ftp.cuhk.edu.hk
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
Installed Packages
Name        : sudo
Arch        : x86_64
Version     : 1.8.6p7
Release     : 22.el7_3

Size        : 2.5 M
Repo        : installed
From repo   : updates
Summary     : Allows restricted root access for specified users
URL         : http://www.courtesan.com/sudo/
License     : ISC
Description : Sudo (superuser do) allows a system administrator to give certain
            : users (or groups of users) the ability to run some (or all) commands
            : as root while logging all commands and arguments. Sudo operates on a
            : per-command basis.  It is not a replacement for the shell.  Features
            : include: the ability to restrict what commands a user may run on a
            : per-host basis, copious logging of each command (providing a clear
            : audit trail of who did what), a configurable timeout of the sudo
            : command, and the ability to use the same configuration file (sudoers)
            : on many different machines.

圖、更新 sudo 套件版本

此時,再次使用 sudo 漏洞檢測工具  cve-2017-1000367.sh 進行檢測作業,可以發現結果是已經使用修復 sudo 漏洞的套件版本 (sudo-1.8.6p7-22.el7_3.x86_64) 了。
# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux centos73.weithenn.org 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
# rpm -qa sudo
sudo-1.8.6p7-22.el7_3.x86_64
# ./cve-2017-1000367.sh

This script is primarily designed to detect CVE-2017-1000367 on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

Detected 'sudo' package is 'sudo-1.8.6p7-22.el7_3.x86_64'.
This 'sudo' version is not vulnerable.

圖、順利更新 sudo 套件版本並修復漏洞



參考資源


前言

最近工作關係開始玩 CentOS 了,本次實作環境中採用的是 CentOS 7.3 x86-64 (Kernel version 3.10.0-514.el7.x86_64) 映像檔,也就是新版 CentOS 7.3 最小化安裝版本 (Minimal Install),那麼開始來玩玩吧。💪



實作環境





Anacron 排程服務

當 CentOS 主機安裝設定完畢並上線運作之後,我們希望主機能夠在固定時間(例如 每小時、每天、每週、每月)發送相關資訊至主機管理人員 E-Mail 位址,讓主機管理人員能獲取系統上的服務運作狀態和硬體使用狀況等相關資訊。主機的管理人員只要定期查看每台管理主機的資訊郵件內容,即可進行判斷及適當的處理,或轉交給相對應的人員接手。

CentOS 主機的預設排程為每小時的 01 分、每天凌晨 4 點 02 分、每週日凌晨 4 點 22 分,以及每月 1 號凌晨 4 點 22 分。此時,系統會執行預先撰寫好的自動維護 Shell Script 執行檔,進行系統相關的清理及備份工作,並使用預設的 Postfix 郵件轉送代理 MTA(Mail Transfer Agnet) 寄送資訊郵件(CentOS 5.x 預設為使用 Sendmail)。欲使用別的郵件轉送代理像是 Sendmail、Qmail …等,屆時只要在設定檔內進行指定即可。若讀者有興趣了解系統定期執行的詳細內容,可切換至 /etc 目錄下的四個資料夾,分別是 每小時(cron.hourly)、每天(cron.daily)、每週(cron.weekly)、每月(cron.monthly),每個資料夾內都有相關的自動維護 Shell Script ,查看後即可了解系統維護主機的相關內容。

CentOS 6 / 7 開始系統排程服務「crontab」的設定檔「/etc/crontab」內容中已經沒有排程工作的相關內容了,改為由 「anacron」 取代成為預設系統排程服務,您可以查看 「/etc/anacrontab」 設定檔內容得知排程作業內容(CentOS 5.x 時預設的系統排程服務為 crontab)。

Anacron 排程服務它適合運作於測試機或筆記型電腦上這種 「非長期處於開機狀態」 之用,因為它採用的是 「頻率」 的方式來執行排程工作,以 /etc/cron.daily 執行的方式來說為 「1天」 執行一次,當 CentOS 主機開機後若發現今天尚未執行排程工作便會在 「5分鐘」 之後執行 /etc/cron.daily 目錄下的執行檔案,當執行排程工作完成後會在 「/var/spool/anacron/cron.daily」 檔案中把今天的日期寫入。(只有 root 管理權限能修改此檔)

  • cron.daily: 執行一次,未執行過排程則開機 5 分鐘後執行。
  • cron.weekly:7天 執行一次,未執行過排程則開機 25 分鐘後執行。
  • cron.monthly: 執行一次,未執行過排程則開機 45 分鐘後執行。

查看 Anacron 排程服務 (/etc/anacrontab) 組態設定檔內容:
# cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly


crontab 則是當系統時間到達排程時間時才會執行排程動作,比較適合用於伺服器這種「長時間開機型」的主機使用,由於我們要透過 CentOS 主機建置高可用性服務,屆時主機是處於長時間開機的情況,因此下列操作為將 anacron 套件從系統中移除,並且安裝舊有的 crontab 排程機制及相關設定檔,而安裝完成後您可以查看「/etc/cron.d/dailyjobs」排程檔案,事實上此排程檔案的內容與舊版中 /etc/crontab 檔案內容相同。

值得注意的是,在 CentOS 7 當中不管是 Anacron 或 Crontab 排程服務都是由 crond 系統服務負責,但是在剛才移除 Anacron 服務時會造成 crond 系統服務停止,所以請重新啟動 crond 系統服務即可。
# yum -y remove cronie-anacron     //移除 anacron 及相關套件
# yum -y install cronie-noanacron  //安裝 crontab 及相關套件
# rpm -ql cronie-noanacron         //查詢安裝 crontab 套件的相關檔案
/etc/cron.d/dailyjobs  
# systemctl restart crond          //重新啟動 crond 服務
# systemctl status crond           //確認 crond 服務運作狀態
crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-05-31 17:09:30 CST; 4s ago
 Main PID: 32472 (crond)
   CGroup: /system.slice/crond.service
           └─32472 /usr/sbin/crond -n

May 31 17:09:30 centos73.weithenn.org systemd[1]: Started Command Scheduler.
May 31 17:09:30 centos73.weithenn.org systemd[1]: Starting Command Scheduler...
May 31 17:09:30 centos73.weithenn.org crond[32472]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 66% if used.)
May 31 17:09:31 centos73.weithenn.org crond[32472]: (CRON) INFO (running with inotify support)
May 31 17:09:31 centos73.weithenn.org crond[32472]: (CRON) INFO (@reboot jobs will be run at computer's startup.)


最後,請記得不管採用的是 anacron 或 crontab 系統排程服務,當修改 anacron 設定(/etc/anacrontab) 或 crontab 設定(/etc/crontab) 之後都不需要把 crond 服務重新啟動,因為 crond 程序會在 「每分鐘」 自動監控 /etc/cron.d 及 /var/spool/cron 資料夾變化,若有偵測到內容變化會自動將變化載入記憶體中,所以不需要修改後把 crond 服務重新啟動。



安裝 LogWatch 套件

在 CentOS 系統中我們可以套過 YUM 套件管理工具安裝 LogWatch 套件,它是負責收集系統狀態及相關網路服務運作資訊。安裝此套件後我們可以在每天定期發送的 cron.daily 資料夾中,發現 0logwatch 這隻 Script。也就是說,系統會在每天凌晨 4 點 02 分時,透過此 Script 將系統中系統、硬體、服務的資訊收集後,寄送給主機管理者。接下來便說明相關資訊的設定方法,例如 由哪台主機寄出收集後的資訊、寄件對象、系統資訊收集分析的等級、收集主機服務運作的狀態設定等。

我們可以將相關設定值寫入至 LogWatch 設定檔 「/etc/logwatch/conf/logwatch.conf」 內,下列為稍後操作中相關設定值其參數說明:

  • MailFrom: 填入此台主機的主機名稱(Hostname),或是該主機所擔任的企業服務名稱(如 Web1) 以利識別。
  • MailTo: 填入主機管理者們的郵件信箱(Email),若有多筆郵件位址則可以使用逗點(, ) 加上空格進行隔開即可。
  • Detail: 指定收集主機資訊後分析的等級,共有三種等級可供選擇分別為 低級(Low 或數字 0)、中級(Med 或數字 5)、高級(High 或數字 10)。
  • Service: 指定收集主機服務運作的項目,LogWatch 支援收集服務的項目為 /usr/share/logwatch/scripts/services 目錄下的服務名稱,您可以使用參數 All 來表示要收集該主機所有運作的服務。若不想分析某個服務,則可於服務名稱前加上減號( - ),則系統便會排除收集該項服務的運作狀態。

下列為個人習慣的 LogWatch 設定檔設定內容,若您需要更詳細的參數設定內容請參考 「/usr/share/logwatch/default.conf/logwatch.conf」 範例設定檔內容。在 LogWatch 中「Service All」所有服務項目有哪些呢? 請參考「/usr/share/logwatch/scripts/services」路徑內容,便會條列 LogWatch 所支援的服務項目 (目前共支援 106 項服務):
# yum -y install logwatch               //安裝 logwatch 套件
# cat /etc/logwatch/conf/logwatch.conf  //查看 logwatch 設定檔內容
MailFrom = centos73                     //郵件寄件者顯示資訊
MailTo = weithenn@weithenn.org          //郵件位址
Detail = High                           //分析資訊等級
Service = All                           //收集所有服務運作項目
Service = -yum                          //除了 yum 以外
Format = html                           //格式為 HTML (預設為 Text)


確認 Postfix 運作狀態正常後,便可以執行「/etc/cron.daily/0logwatch」指令來測試每日排程執行時,LogWatch 套件收集主機資訊的郵件是否能順利寄出,而您是否也可以從設定的 E-Mail 地址收到主機所發出的收集資訊郵件,由下列郵件記錄檔內容可以看到 CentOS 主機順利將郵件發送至 logwatch 設定檔中所設定的E-Mail 地址,若您想要查看系統是否有郵件佇列(Mail Queue) 或想刪除所有郵件佇列的郵件,您可以使用「postqueue」指令配合參數「-p、-f」即可。
# /etc/cron.daily/0logwatch  //馬上寄送收集主機資訊郵件
# tail /var/log/maillog      //查看郵件記錄檔
May 31 17:28:12 centos73 postfix/pickup[32553]: CABFC2005097: uid=0 from=
May 31 17:28:12 centos73 postfix/cleanup[32634]: CABFC2005097: message-id=<20170531092812 .cabfc2005097="" centos73.weithenn.org="">
May 31 17:28:12 centos73 postfix/qmgr[663]: CABFC2005097: from=, size=5469, nrcpt=1 (queue active)
May 31 17:28:12 centos73 postfix/smtp[32636]: connect to ASPMX.L.GOOGLE.COM[2404:6800:4008:c04::1b]:25: Network is unreachable
May 31 17:28:14 centos73 postfix/smtp[32636]: CABFC2005097: to=, relay=ASPMX.L.GOOGLE.COM[64.233.187.26]:25, delay=1.8, delays=0.06/0.01/0.36/1.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1496222994 91si46967451plb.204 - gsmtp)
May 31 17:28:14 centos73 postfix/qmgr[663]: CABFC2005097: removed
# postqueue -p            //顯示 Mail Queue
# postqueue -f            //刪除所有 Mail Queue 信件



網管人雜誌

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



文章目錄

前言
VCHA 高可用性機制
          VCHA 高可用性運作架構
          部署 VCHA 高可用性的最佳作法
vMotion 即時遷移的安全性
          vMotion 加密技術運作架構
          組態設定加密 vMotion 機制
          部署加密 vMotion 的最佳作法
結語





前言

VMware 官方,在 2016 年 11 月 VMware VMworld 2016 大會上,宣佈 VMware vSphere 6.5VMware vSAN 6.5 正式推出,並且 VMware 官方在最新版本 vCSA 6.5 當中,為 vCSA 管理平台打造「原生 HA 高可用性」機制。
在過去的 vCSA(VMware vCenter Server Appliance)版本中,並沒有原生 vCSA HA 高可用性機制,只能搭配 VMware 叢集內建的 vSphere HA 高可用性機制,來達到 vCSA 服務高可用性的目的。

在本文中,除了介紹 VCHA 高可用性運作架構及最佳建議作法之外,同時也會介紹在 vSphere 6.5 版本當中的另一個亮點功能,也就是針對 vMotion 即時遷移流量進行加密,避免遭受中間人攻擊甚至被竄改記憶體狀態導致資安事件,有效保護企業及組織線上營運的 VM 虛擬主機進行 vMotion 遷移時的安全性。





VCHA 高可用性機制

新版的原生 vCSA HA 機制(簡稱 VCHA),是由「Active、Passive、Witness」成員節點角色所組成。當 VCHA 叢集中某台成員節點主機發生災難事件時(例如,擔任 Active Node 角色的成員節點主機發生硬體故障),將會觸發 VCHA 高可用性機制然後透過 API 存取的使用者在 2 分鐘內便可以繼續使用,而透過 UI 存取的使用者在 4 分鐘便可以繼續存取,原則上 VCHA 機制的 RTO 預計在「5 分鐘」之內便可完成,當然實際上必須視底層硬體資源的工作負載情況而定。

圖 1、VCHA 高可用性機制運作示意圖



VCHA 高可用性運作架構

在實作 VCHA 高可用性機制的部分,必須保持 Active Node 及 Passive Node 節點主機狀態的一致性。首先,在 vCSA 資料庫部分預設採用內嵌「PostgreSQL 資料庫」,所以透過 PostgreSQL 資料庫原生的「複寫」(Replication)機制,保持 Active Node 及 Passive Node 節點主機資料庫同步及內容的一致性。接著,在「組態設定檔」的部分則使用 Linux 作業系統中原生的「Rsync」複寫機制,達到 Active Node 及 Passive Node 節點主機組態設定檔內容一致性。

在 VCHA 高可用性機制運作架構中,高可用性叢集是由 Active、Passive、Witness 成員節點主機所組成,每台成員節點主機的功能如下:

  • Active Node: 運作 vCenter Server 主要執行個體,啟用及使用 VMware 叢集的共用 IP 位址。
  • Passive Node: 運作 vCenter Server 備援執行個體,透過複寫機制不斷從 Active Node 端接收變更內容及狀態,倘若 Active Node 發生故障事件時將會立即接手相關服務。
  • Witness Node: 擔任仲裁角色,當 Active Node 及 Passive Node 發生網路分區或中斷事件時,能夠有效避免 VCHA 高可用性運作架構發生腦裂的情況。在整個 VCHA 運作架構中,使用最少的硬體資源同時也不會接手 Active Node 及 Passive Node 的角色。

圖 2、VCHA 高可用性機制運作架構示意圖

那麼,在 VCHA 高可用性機制的運作架構下,當發生不同的災難事件時(例如,硬體、軟體、網路環境),Passive Node 如何接手 Active Node 服務及叢集公用 IP 位址,並且繼續回應客戶端提出的請求。此外,在 VCHA 高可用性機制中因為 PostgreSQL 資料庫將會進行同步,所以發生災難事件時也不會有資料遺失的情況(RPO=0)

下列,我們將列舉當 VCHA 高可用性機制發生各種災難事件時,系統將如何進行因應措施:

  • Active Node 故障損壞時: 只要 Passive Node 與 Witness Node 能夠互相通訊,那麼 Passive Node 將會提升自己的角色為 Avtive Node,並且開始回應客戶端提出的請求。
  • Passive Node 故障損壞時: 只要 Active Node 與 Witness Node 能夠互相通訊,那麼 Active Node 將繼續保持 Avtive Node 的角色,並且繼續回應客戶端提出的請求。
  • Witness Node 故障損壞時: 只要 Active Node 與 Passive Node 能夠互相通訊,那麼 Active Node 將繼續保持 Avtive Node 的角色,並且繼續回應客戶端提出的請求。同時,Passive Node 將會繼續偵測 Active Node 是否正常運作,以便隨時準備進行故障切換作業。
  • 多台節點發生故障或發生網路隔離: 表示 Active、Passive、Witness 這 3 台節點主機彼此無法互相通訊。此時,VCHA 叢集將無法正常運作並且可用性也受到影響,因為 VCHA 高可用性機制的設計並無法容許同時發生多項故障。
  • 節點隔離行為: 當單台節點主機發生網路中斷事件,在經過間歇性網路故障偵測程序及所有重試機制都耗盡後,系統才會將該台節點主機判定為隔離狀態,同時進入隔離狀態的節點主機將會自動停止所有服務。舉例來說,倘若 Active Node 發生隔離狀態時,那麼 Active Node 將會從叢集中移出並停止所有服務,以便確保 Passive Node 能夠接手角色成為 Avtive Node,並且開始回應客戶端提出的請求。



部署 VCHA 高可用性的最佳作法

在 vCSA 6.5 版本中,每台 vCSA 支援管理最多 64 叢集、2,000 台 ESXi 主機、35,000 台註冊的 VM 虛擬主機、20,000 台開機的 VM 虛擬主機。同時,不同運作規模大小對於 vCSA 硬體資源的配置建議也不同,在下列表格中便是 VMware 官方針對不同運作規模的 vCSA 硬體資源建議:
事實上,vCSA 還支援更小型的運作規模稱為「Tiny」,只需要 2 vCPUs 及 10 GB RAM 的硬體資源,可以管理 10 台 ESXi 主機及 100 台 VM 虛擬主機。但是,VCHA 高可用性運作機制不支援 Tiny 運作規模,所以要啟用 VCHA 高可用性機制至少需要採用 Small 運作規模才行。
圖 3、針對不同運作規模的 vCSA 硬體資源建議

雖然,VMware 建立的 VCHA 高可用性機制運作架構非常簡單易用,但是 vSphere 管理人員應該遵循最佳作法,以便讓 VCHA 高可用性機制運作效能更佳之外也更穩定:

  • 離峰時間才啟用 VCHA 機制: 雖然,可以在 vCenter Server 運作的任何時間啟用 VCHA 高可用性機制,但是 VMware 強烈建議在工作負載的離峰時間再啟用。主要原因在於,建立 VCHA 高可用性機制後系統便會立即執行 PostgreSQL 資料庫同步作業,倘若在工作負載高峰時間啟用的話,那麼 Passive Node 的 PostgreSQL 資料庫有可能會來不及同步。
  • 僅容許單台節點發生故障: 在 VCHA 高可性機制的運作架構下只有 3 台節點主機,所以容許故障的節點主機數量不能超過「單台」。因此,每台節點主機的角色應部署在不同 x86 硬體伺服器上,以避免硬體伺服器發生故障損壞事件時直接影響所有角色。此外,每台節點主機也應部署在獨立且隔離的 Datastore 儲存資源中,以避免將 3 台節點主機都部署在同 1 個 Datastore 儲存資源中,導致發生 SPOF 單點失敗的問題進而影響 VCHA 高可用性機制。


此外,在 VCHA 高可用性運作架構中,網路環境應該具備低延遲時間、高傳輸頻寬、隔離且專用的網路,以避免因為不適當的網路環境進而影響 VCHA 高可用性機制的運作及效能。下列,為 VCHA 高可用性網路環境規劃設計的最佳建議作法:

  • 採用隔離且專用的網路: 因為在 VCHA 高可用性機制運作架構中,Active Node 及 Passive Node 之間,必須不斷同步 PostgreSQL 資料庫的資料,倘若 2 台節點主機之間的網路頻寬無法達到資料同步要求時,那麼將會退化為非同步並導致 PostgreSQL 資料庫內容相異。
  • 支援高達 10 ms 的低延遲網路: 在 VCHA 高可用性機制運作架構中,可以支援高達 10 ms 網路環境延遲時間。倘若,網路環境的延遲時間高於 10 ms 時,那麼 VCHA 高可用性機制仍然能夠順利運作,但是將會產生延遲操作、低輸送量、效能損失……等運作不佳的情況。


下列是 VMware 官方透過 VCbench 壓力測試軟體,針對 VCHA 高可用性運作環境進行壓力測試的結果。其中採用 64-clients 方式為最貼近實務應用的工作負載,當延遲時間高達 5 ms 時那麼傳輸量將會下降 9 %,倘若延遲時間高達 10 ms 時傳輸量更會下降 15 %。若是更進一步,採用 256-clients 方式以更極端的工作負載方式進行壓測時,當延遲時間高達 5 ms 時那麼傳輸量將會下降 23 %,倘若延遲時間高達 10 ms 時傳輸量更會下降 27 %。

圖 4、透過 VCbench 針對 VCHA 網路環境進行壓力測試的統計數據





vMotion 即時遷移的安全性

過去,在 VMware vSphere 虛擬化運作環境中,針對 vMotion 線上遷移傳輸流量的規劃及設計,除了應規劃獨立專用的網路環境以便快速遷移線上運作的 VM 虛擬主機之外,規劃獨立專用網路環境的另一個考量便是「安全性」

因為,預設情況下當 vSphere 管理人員透過 vMotion 線上遷移機制,將線上運作中的 VM 虛擬主機從來源端 ESXi 主機,傳輸至目的端 ESXi 主機的過程中 vMotion 傳輸流量並「未進行加密」。同時,透過 vMotion 所傳輸的是 VM 虛擬主機的「記憶體狀態」,惡意攻擊者有可能在傳輸期間修改記憶體狀態內容,進而達到破壞 VM 虛擬主機應用程式或作業系統的目的,所以規劃獨立專用網路環境除了網路頻寬獨享之外,同時也達到 vMotion 傳輸流量安全性隔離的效果。

在 2015 年 3 月推出的 VMware vSphere ESXi 6.0 版本中,vMotion 線上遷移傳輸機制打破地域及環境的限制。新版 vMotion 即時遷移機制不只可以跨越 vSwitch 虛擬交換器,以及跨越不同的 vCenter Server 伺服器之外更可以跨越地域的限制,只要執行 vMotion 線上遷移的網路環境,能夠支援封包延遲時間在 100 ms 之內的話,那麼就能達成跨越地域限制的 vMotion 即時遷移。

現在,最新 VMware vSphere 6.5 版本當中,支援將 vMotion 線上遷移傳輸流量「加密」機制,透過 AES-GCM 加密標準將 VMkernel 的 vMotion 即時遷移流量,進行加密的動作達到高安全性的 vMotion 即時遷移。

圖 5、加密 vMotion 即時遷移傳輸數據運作示意圖



vMotion 加密技術運作架構

在 VMware vSphere 6.5 運作環境中,加密 vMotion 運作機制採用內嵌於 ESXi 主機 VMkernel 當中,並整合通過 FIPS 密碼模組檢測標準的 vmkcrypto 模組及搭配 AES-GCM 標準加密演算法,然後透過 TCP 通訊協定傳輸「vMotion 中繼資料」(vMotion Metadata)

事實上,加密 vMotion 運作機制並未依賴 SSL 或 IPSec 技術來加密 vMotion 即時遷移流量,相反的它著重在 TCP 通訊協定層級中達到加密的目的,主要原因在於考量 vMotion 即時遷移的運作效能。舉例來說,倘若採用 SSL 加密技術保護 vMotion 即時遷移流量時,因為 SSL 加密為「計算密集型」(Compute Intensive)的運作機制,所以 vMotion 即時遷移流量採用 SSL 加密技術的話,將會導致 ESXi 主機運算效能過多的額外開銷。

倘若採用 IPSec 加密技術保護 vMotion 即時遷移流量時,將會讓 vMotion 即時遷移受到限制,因為 ESXi 主機「僅」支援在 IPv6 網路環境中採用 IPSec 加密技術,在 IPv4 網路環境中並不支援 IPSec 加密技術。

因此,採用 VMkernel 內 vmkcrypto 模組的加密機制,除了有效讓 vMotion 避免發生效能損失的情況之外,透過 TCP 通訊協定傳輸的方式能夠讓加密 / 解密的工作負載,平均分散到 CPU 處理器的多個運算核心上。

當 vCenter Server 準備遷移線上運作的 VM 虛擬主機時,將會隨機產生 1 個「One time 256-bit」的加密金鑰,同時除了隨機 256-bit 加密金鑰之外還會搭配「64-bit 隨機數」成為 vMotion 遷移規範,然後將這個 vMotion 遷移規範傳遞給來源端及目的端 ESXi 主機,所以在進行 VM 虛擬主機 vMotion 線上遷移作業時,便會透過「256-bit 加密金鑰+ 64-bit 隨機數」的 vMotion 遷移規範,在 2 台 ESXi 主機之間以 vMotion 專屬網路環境進行傳輸,確保 2 台 ESXi 主機之間傳輸的遷移流量無法被惡意人士所複製或竄改。

值得注意的是,這個 256-bit 的加密金鑰並非採用 vCenter Server Key Manager 產生,而是 vCenter Server 會為每次的 vMotion 即時遷移工作任務,自動產生 1 個新的 256-bit 加密金鑰,並且在 vMotion 線上遷移任務結束後便會「捨棄」該加密金鑰。同時,剛才已經提到加密 vMotion 運作機制,是採用 VMkernel 內的 vmkcrypto 模組達成,因此並不需要專用的硬體設備即可達成。

倘若,執行 vMotion 即時遷移工作任務並非 2 台 ESXi 主機,而是「跨越」不同台 vCenter Server 時則會有些許不同。簡單來說,在執行跨 vCenter Server 進行加密 vMotion 即時遷移時,與剛才說明的加密 vMotion 即時遷移運作原理相同,唯一不同的部分在於「256-bit 加密金鑰 + 64-bit 隨機數」的 vMotion 遷移規範,將會從來源端 vCenter Server 透過「SSL」傳送到目的端 vCenter Server。

圖 6、跨 vCenter Server 執行加密 vMotion 即時遷移傳輸數據運作示意圖



組態設定加密 vMotion 機制

由於加密 vMotion 即時遷移機制不需要專用的硬體設備即可達成,因此可以隨時針對希望保護的 VM 虛擬主機進行啟用的動作即可。在實務應用上,通常會針對重要工作任務或存放企業及組織機敏資料的 VM 虛擬主機進行套用,例如,負責線上營運服務 SQL 資料庫伺服器。

請透過 vSphere Web Client 管理工具登入 vCenter Server 管理平台後,依序點選「首頁>主機和叢集」圖示,點選欲啟用加密 vMotion 即時遷移機制的 VM 虛擬主機後,按下滑鼠右鍵並於右鍵選單中選擇編輯設定,此時在彈出的 VM 虛擬主機組態設定視窗中,點選至「虛擬機器選項」頁籤後於「Encrypted vMotion」子項目中,在下拉式選單內看到下列 3 種加密 vMotion 即時遷移機制設定值:

  • Disabled: 停用加密 vMotion 即時遷移機制,有可能導致 VM 虛擬主機在執行 vMotion 即時遷移的過程中,遭受中間人攻擊讓惡意攻擊者在傳輸期間修改記憶體狀態內容,進而達到破壞 VM 虛擬主機應用程式或作業系統的目的。
  • Opportunistic: 預設值,當來源端及目的端 ESXi 主機都支援加密 vMotion 即時遷移機制時,也就是 2 台 ESXi 主機皆為 ESXi 6.5 版本,那麼在執行 vMotion 即時遷移的過程中便會加密傳輸流量。倘若有任何一端不支援,例如,目的端 ESXi 主機採用 ESXi 6.0 或更舊的版本,那麼在執行 vMotion 即時遷移的過程中便不會加密 vMotion 傳輸流量。
  • Required: 來源端及目的端 ESXi 主機都必須支援加密 vMotion 即時遷移機制,倘若有任何一端不支援便無法執行 vMotion 即時遷移機制。同時,當 VMware 叢集啟用 DRS 自動化負載平衡機制後,那麼 DRS 便僅會選擇支援加密 vMotion 即時遷移機制的目的端 ESXi 主機。


圖 7、組態設定 VM 虛擬主機啟用加密 vMotion 即時遷移機制



部署加密 vMotion 的最佳作法

雖然,採用加密 vMotion 即時遷移機制,能夠達到保護 vMotion 即時遷移流量並對於 ESXi 主機的工作負載影響最小,舉例來說,在 20 GbE 的網路環境中執行 vMotion 即時遷移作業,「來源端」ESXi 主機上倘若未啟用 vMotion 加密機制僅需 1 Core 運算核心資源,倘若啟用 vMotion 加密機制則需要 2.2 Cores 運算核心資源,相較之下在「目的端」ESXi 主機上的工作負載差距更小,倘若未啟用 vMotion 加密機制需 2.5 Cores 運算核心資源,倘若啟用 vMotion 加密機制則需要 3.3 Cores 運算核心資源。

從測試結果可知,在執行 vMotion 即時遷移時來源端比目的端需要更多的 CPU 運算資源開銷,因為 vMotion 接收程式碼路徑比起傳輸程式碼路徑需要更多 CPU 運算資源,同時在加密及解密 vMotion 即時遷移流量的開銷也不同。事實上,從測試結果可以看到開啟加密 vMotion 即時遷移機制後,每增加 10 Gb/s 的網路流量對於 CPU 運算資源開銷,在來源端或目的端 ESXi 主機都只需要增加 1.x Core 運算核心資源。

圖 8、啟用及停用加密 vMotion 即時遷移機制 CPU 運算資源開銷比較圖表

同時,為了確保在 VMware vSphere 6.5 運作環境中,啟用加密 vMotion 即時遷移機制時能夠得到最佳效能,VMware 的最佳建議作法如下:

  • 雖然,啟用加密 vMotion 即時遷移機制並不需要任何硬體設備,但是在選擇 ESXi 主機硬體伺服器的 CPU 處理器時,VMware 強烈建議選擇具備「高階加密標準新指令」(Advanced Encryption Standard New Instruction,AES-NI)指令集功能,以便啟用加密 vMotion 即時遷移機制時,能夠對來源端及目的端 ESXi 主機的 CPU 工作負載降至最低。
  • 雖然,在剛才啟用及停用加密 vMotion 即時遷移機制 CPU 運算資源開銷比較圖表中,我們已經知道每增加 10 Gb/s 網路頻寬,對於來源端及目的端 ESXi 主機的 CPU 運算資源開銷僅約增加 1.x Core。但是,這僅用於處理 vMotion 網路流量的 CPU 使用率,對於 ESXi 主機整體處理 vMotion 工作任務來說至少需要 2 Cores 運算資源,因此應確保 ESXi 主機具備足夠的 CPU 運算資源,以便確保 vMotion 即時遷移工作任務能快速且順利執行。
  • 不管啟用或停用加密 vMotion 即時遷移機制,對於 vMotion 即時遷移運作效能的最佳建議作法都是相同的。有關 VMware vSphere 6 效能調校最佳實務的詳細資訊,請參考本雜誌<第 118 期 - VMware vSphere 6.0 效能調校最佳實務>文章內容。


圖 9、啟用及停用 AES-NI 加密指令集對於工作負載的效能影響比較圖表





結語

透過本文的說明及最佳建議作法相信讀者已經了解,在新版的 vSphere 6.5 當中採用 vCSA 建立原生 VCHA 高可用性機制的時要點,以及在規劃 vMotion 即時遷移網路環境時,除了注意獨立隔離且專用的網路環境之外,也應針對企業及組織線上營運或存有機敏資料的 VM 虛擬主機,開啟加密 vMotion 即時遷移機制避免遭受中間人攻擊,甚至被竄改記憶體狀態導致資安事件。