當VM虛擬主機的規模越來越大時，如何輕鬆管理就變得非常重要了。其實只要利用Windows Server 2016內建的VM Group和VM Start Order兩項機制，就可讓工作類型相同的VM虛擬主機群能夠執行相同的管理動作，藉此大幅降低了IT人員的管理負擔。
‧ Name：顯示Set層級的名稱，此實作環境為DB-VMs和App-VMs。
‧ PSComputerName：此Set層級作用的容錯移轉叢集名稱，此實作環境容錯移轉叢集名稱為HV-Cluster（FQDN為HV-Cluster.weithenn.org）。
然後，透過Add-ClusterGroupToSet指令，分別將Database虛擬主機加入至DB-VMs的Set層級當中，以及將App01、App02虛擬主機加入至App-VMs的Set層級內，如圖18所示。接著，再透過Get-ClusterGroupSet指令確認是否將指定的VM虛擬主機加入至相對應的Set層級內。那麼，再說明一下目前已知欄位的意義為何：
 |
| ▲ 圖18 將指定的VM虛擬主機加入至相對應的Set層級當中。 |
‧ GroupNames：加入此Set層級的VM虛擬主機，此實作環境中加入App-VMs的有App01、App02虛擬主機，而加入DB-VMs的則是Database虛擬主機。
最後，設定這兩個Set層級之間的依賴關係，也就是組態設定當Database虛擬主機開機經過20秒之後，系統才會自動啟動App01、App02這兩台VM虛擬主機。如圖19所示，請透過Add-ClusterGroupSetDependency指令，組態設定DB-VMs為App-VMs的提供者，也就是DB-VMs內的VM虛擬主機開機並經過20秒之後，才會啟動App-VMs內的VM虛擬主機。
那麼目前已知欄位的意義為何，請看以下的說明：
 |
| ▲ 圖19 設定這兩個Set層級之間的依賴關係DB-VMs為App-VMs的提供者。 |
‧ ProviderNames：此Set層級的提供者，此實作環境中DB-VMs為App-VMs的提供者，所以加入App-VMs的VM虛擬主機，必須等到DB-VMs所屬的VM虛擬主機啟動，並等待指定的時間後才能啟動。
‧ StartupDelayTrigger：定義延遲啟動的觸發動作為何總共支援兩個選項，分別是Delay及Online，預設值為「Delay」，也就是等待提供者Set層級中StartupDelay欄位的秒數後，這個Set層所屬的VM虛擬主機才能啟動。倘若組態設定為「Online」時，則必須等到提供者Set層級中VM虛擬主機的狀態為Online之後才能啟動。
‧ StartupCount：定義更具彈性的啟動順序。
‧ StartupDelay：定義延遲多少秒之後才執行啟動VM虛擬主機的動作。
測試VM Start Order機制
組態設定完畢，就可以快速驗證VM Start Order機制是否能夠順利運作。請開啟容錯移轉叢集管理員，先選擇本文實作的三台VM虛擬主機，接著如圖20所示在右鍵選單中點選【啟動】選項，也就是執行三台VM虛擬主機「同時」啟動的動作，然後觀察VM虛擬主機會發生什麼樣的情況。
 |
| ▲ 圖20 執行三台VM虛擬主機同時啟動的動作。 |
倘若未組態設定VM Start Order運作機制的話，那麼正常情況下三台VM虛擬主機應該會同時執行啟動的動作。然而，在前面的VM Start Order組態設定中，已經定義必須要Database虛擬主機啟動並等待20秒之後App01、App02虛擬主機才會執行啟動的動作。
因此可以發現，執行三台VM虛擬主機同時啟動的動作後，只有Database虛擬主機自己先啟動，然後App01、App02虛擬主機狀態為「正在啟動」（等待中），如圖21所示，然後經過20秒後才正式執行啟動的動作。
 |
| ▲ 圖21 VM Start Order運作機制順利運作。 |
結語
經過本文的說明及實作演練之後，相信大家已經完全了解VM Group和VM Start Order這兩項機制，確實可以幫助企業及組織降低維運成本，同時也能夠降低管理人員的管理負擔。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞