網管人雜誌
本文刊載於
網管人雜誌第 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 項機制，確實可以幫助企業及組織降低維運成本，同時也能降低管理人員的管理負擔。
