前言

最新的 Intel Xeon Scalable 處理器於日前正式發佈,同一時間 Claus Joergensen (S2D Team Leader) 也隨即在 Storage at Microsoft 部落格上,發表 S2D on Intel Xeon Scalable 處理器的效能測試成功。




S2D on Intel Xeon Platinum 處理器效能測試

下列便是 Windows Server 2016 S2D (Storage Spaces Direct) 軟體定義存技術,搭配最新 Intel Xeon Scalable 處理器的測試環境。有關 Windows Server 2016 S2D (Storage Spaces Direct) 運作環境建置的詳細資訊,請參考 Intel Implementation Guide - Intel Optimized Configurations for Windows Server 2016 with Storage Spaces Direct 文件。

S2D 叢集由 4 台 S2D 叢集節點主機組成,每台伺服器硬體配置如下:
  • Intel Server System R2208WF
  • 2x Intel Xeon Platinum 8168 CPU (24cores @ 2.7Ghz)
  • 128GiB DDR4 DRAM
  • 2x 375GB Intel Optane SSD DC P4800X (NVMe SSD)
  • 4x 1.2TB Intel SSD DC S3610 SATA SSD
  • Intel Ethernet Connection X722 with 4x 10GbE iWARP RDMA
  • BIOS configuration
  • C States disabled
  • BIOS performance plan
  • Turbo On
  • HT On


同樣的,採用 VMFleet 儲存效能壓力測試工具進行測試,相關測試條件如下:
  • 4x 3-copy mirror CSV volumes
  • Cache configured for Read and Write
  • 24 VMs (diskspd 4K IO 90% read / 10% write) per node
  • Each VM rate limited to 7,500 IOPS (similar to Azure P40 disk)

測試結果可以看到,在 Read IO 的表現為「80 μs」 Write IO 則是「300 μs」,在 CPU 工作負載的表現則是「低於 25%」




Intel Xeon Scalable 處理器簡介

簡單來說,最新一代 Intel Xeon Scalable 處理器共分為「Platinum、Gold、Silver、Bronze」4種不同等級的 CPU處理器。詳細資訊請參考 Intel® Xeon® Scalable Processors Product Specifications



Intel Xeon Platinum Processors


Intel Xeon Gold Processors



Intel Xeon Silver Processors


Intel Xeon Bronze Processors




參考資源


前言

今天微軟混合雲平台 Microsoft Azure Stack 正式 GA 了 (詳細資訊請參考 Microsoft Azure Stack is ready to order now | Blog | Microsoft Azure)。





目前,可以銷售「Azure Stack Integrated Systems」的廠商只有 3 家,分別是 Dell / EMC, HPE, Lenovo。


在銷售上有分別「Azure Stack Software pricing and availability」,搭配「pay-as-you-use」及「capacity-based model」,或是用於開發用途單台「ASDK (Azure Stack Development Kit)」,至於計價的詳細資訊請參考 Microsoft Azure Stack packaging and pricing




Azure Stack 運作架構簡述

Azure Stack 運作架構的設計原則為「1、1、4 ~ 12」,分別是「1 Region」、「1 Scale Unit」、「4 ~ 12 Node」


同時,在 Microsoft Azure Stack 的運作架構中,分為「User Portal」「Administrator Portal」







然而即便是 Azure Stack 的管理者也碰觸不到底層的各項運作元件。




至於更新機制的部分,即同樣套用 Microsoft Azure 的管理經驗進行更新。







參考資源


[天瓏 - 雙書合購特價 74 折]💪

即日起,天瓏書局針對本專家手冊推出雙書合購特價 74 折活動,有興趣的朋友可以參考看看。😁



書籍簡介

在本書中,我們將會指導你如何規劃及調校 VMware vSphere 6.x 的基礎架構。我們將會為你提供相關的專業知識及操作技巧,以便引導你順利建構高可用性、高效能的 VMware vSphere 虛擬化基礎架構。同時,我們將會一步一步帶領你進行操作並輔以畫面截圖。

經由專業認證的 VMware 專業人士,基於各種真實狀況,親自分享實務性的操作步驟以及詳細的概念解釋。使你可以透過本書瞭解 VMware vSphere 6.x 的完整功能,並能夠藉此應付作業環境中的各項挑戰。

本書內容涵蓋從安裝、設定、操作及安全性控制等方面的詳細步驟,協助你克服大型虛擬化環境的管理及自動化難題。藉由對 VMware vSphere 的全方位教學,本書可引令初學者成為虛擬化技術的專家,或是作為資深管理者的重要參考書目。



誰適合閱讀此書

本書是專為希望加強 vSphere 6.0 虛擬化基礎架構,以及進階虛擬化技術的 IT 專業人士所寫。對於剛開始學習虛擬化技術的 IT 管理人員,可以依循本書中每個章節一步一步進行實作,進而學習到完整的虛擬化技術及虛擬化環境管理技巧。不過,讀者仍應先具備以下基礎:
  • 對於網路基礎架構有基本認識。
  • Microsoft Windows 運作環境的操作經驗。
  • DNS 及 DHCP 網路服務的管理經驗。
  • 對於虛擬化環境與傳統實體架構之差異有基本認識。
  • 對標準 x86 及 x64 伺服器硬體架構及軟體元件有基本認識。



網路購書





本書導讀

在本書中,我們將會詳盡說明 VMware vSphere 6.0 虛擬化環境的安裝、設定、管理及監控。在本書中除了深入剖析 vSphere 虛擬化產品,以及相關進階技術的特色功能外,更輔以實作,讓你可以詳細了解產品的安裝及組態設定。

這些組態設定包括 vSphere 虛擬網路及儲存功能,以及 HA 高可用性、容錯移轉和資源使用率⋯⋯等。當完成基礎架構的安裝及組態設定後,我們將會進入 VM 虛擬主機的建立及管理,然後深入到效能監控及故障排除。通讀本書能夠使你了解如何建置一個全新的vSphere 虛擬化環境,或者如果你是一名 IT 專業人員,對虛擬化技術已有所了解,則本書可視為是一部參考書,使你可以藉由書中的提示、訣竅與最佳實踐,來增強自己的技能。

本書將以提供虛擬化專業技術為導向,幫助你建置、整合、管理、維運企業等級的虛擬化解決方案。

VMware vSphere 6 企業級專家手冊 (上)

  • 《第 1 章:簡介 VMware vSphere 6》,開始討論有關 vSphere 6.0 虛擬化產品。在本章中,將介紹 vSphere 軟體授權資訊,以及企業及組織採用 vSphere 虛擬化解決方案時的實際使用案例。
  • 《第 2 章:規劃設計及安裝 VMware ESXi》,本章將著重在選擇實體伺服器、VMware ESXi 版本、規劃設計及安裝、以及手動和自動化部署 VMware ESXi 運作環境。
  • 《第 3 章:安裝及組態設定 vCenter Server》,在本章中我們將深入討論如何規劃vCenter Server,以及 vCenter Server 相關運作元件,同時也將討論如何規劃設計、安裝、組態設定 vCenter Server 運作環境。
  • 《第 4 章:vSphere Update Manager 及 vCenter Support Tools》,在本章中將說明規劃設計、安裝及組態配置 vSphere Update Manager。透過 vCenter Update Manager 更新機制,將能確保 vSphere 運作環境擁有最新的安全性更新。
  • 《第 5 章:建立及組態設定 vNetwork 虛擬網路》,在本章中我們將討論虛擬網路的規劃設計、管理及最佳化,同時也將討論相關更新功能如 VDS 分散式交換器,以及協力廠商的虛擬網路交換器。在本章中,我們將討論虛擬網路及實體網路的運作架構整合,以及網路運作環境的安全性,同時提供相關解決方案。
  • 《第 6 章:建立及組態設定 vStorage 儲存資源》,在本章中我們將深入討論 vSphere 儲存架構,包括光纖通道、iSCSI 及 NAS 儲存設備的規劃設計及最佳化,以及相關進階功能的使用如精簡佈建、MPIO 多重路徑和負載平衡。
  • 《第 7 章:確認 HA 高可用性及商務連續性》,在本章中我們將深入剖析商務連續性及災難復原等熱門議題,我將提供有關 VM 虛擬主機建立 HA 高可用性,以及伺服器叢集的詳細資訊。此外,本章也將討論如何建構 vSphere HA(High Availability)及 vSphere FT(Fault Tolerance)等機制,以便為 vSphere 運作環境中的 VM 虛擬主機,提供高可用性及容錯移轉的運作機制,同時也將討論如何透過 vSphere Storage API 進行備份作業。


VMware vSphere 6 企業級專家手冊 (下)

  • 《第 8 章:VMware vSphere 安全性》,安全性一直是基礎架構的重要組成部分,在本章中我們將討論不同層面的安全性管理機制,例如,管控 ESXi 主機的存取以及透過 Active Directory 整合身分驗證機制。同時,在本章中也將介紹在多層次的運作環境中,如何進行系統管理以及使用者身分驗證機制,同時針對 Windows 使用者及群組和 vSphere 安全性模組進行整合,達到企業等級的部署及權限管理和委派作業。
  • 《第 9 章:建立及管理 VM 虛擬主機》,在本章中將介紹如何透過 vCenter Server 部署 VM 虛擬主機。此外也將介紹多項可節省時間的技巧、VM 虛擬主機最佳化、以及最佳實踐作法,讓 VM 虛擬主機即便隨著時間而不斷增加數量,也能夠簡化管理程序。
  • 《第 10 章:建立範本及 vApp》,在本章中將為你介紹範本的運作概念,以及透過VM 虛擬主機映像檔機制,達到標準化及快速部署 VM 虛擬主機的目的。同時,我們也將討論複製及 vApp 的運作概念,以便在眾多 VM 虛擬主機的運作環境中,建立及使用 vSphere 的多用途容器。此外,我們也將討論 VMware 所採用的 OVF 標準,以便輕鬆匯入並使用協力廠商所提供的 VM 虛擬主機。
  • 《第 11 章:管理資源集區》,在本章中我們將全面審視資源的分配及管理,從單台VM 虛擬主機到 ESXi 主機和叢集,深入探討在 vSphere 運作環境中如何使用資源,以及管理人員如何透過「共享」(Share)、「保留」(Reservations)、「限制」(Limits)等機制,管理及調整資源的使用及分配方式。
  • 《第 12 章:負載平衡資源使用率》,在上一章節中我們已經了解到資源的使用及分配,接著在本章中我們將會探討 vSphere 負載平衡資源使用率的方式。在本章中,你將會了解到 vSphere vMotion、EVC(Enhanced vMotion Compatibility)、vSphere DRS(Distributed Resource Scheduler)、Storage vMotion 以及 Storage DRS。
  • 《第 13 章:監控 VMware vSphere 運作效能》,在本章中我們將透過 vSphere 內建工具,讓管理人員能夠審視及解決基礎架構的效能問題,本章將著重於監控 ESXi 主機及叢集中的 vCenter Server,在 CPU、記憶體、磁碟及網路等硬體資源的使用率,同時你也將學習到有關 vCenter Operations Manager 的部分。
  • 《第 14 章:VMware vSphere 自動化》,在 VMware vSphere 運作環境中,管理人員常常面臨的是重複性的管理作業,我們在本章中所介紹的自動化機制將能有效幫助管理人員,輕鬆建構各種自動化機制的方式,包括 vCenter Orchestrator 及 PowerCLI。
  • 《附錄》,在每一章節的結語當中,我們將針對每項問題提供給管理人員最佳建議作法及解決方案。


網管人雜誌

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