Related Posts Plugin for WordPress, Blogger...

網管人雜誌

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






文章目錄

前言
Windows Server 2019 S2D 新增特色功能
          支援更大型的運作規模
          最適用於邊緣運算環境的仲裁機制
          儲存裝置延遲異常檢測機制
          儲存效能加倍的 Mirror-Accelerated Parity
S2D 實戰–叢集節點主機硬體需求
          建立 S2D 網域環境
          安裝伺服器角色及功能
          vSwitch 虛擬網路交換器
          驗證 S2D 容錯移轉叢集
          建立 S2D 容錯移轉叢集
          啟用 Storage Spaces Direct 機制
          Windows Admin Center 管理平台
結語





前言

根據 Gartner 市調機構的研究結果顯示,在 2017 年時全球大型企業中便已經有高達 75 % 的比例,建構名為「Bimodal IT」的雙重 IT 基礎架構分別是 Mode 1 及 Mode 2(如圖 1 所示)。簡言之,在傳統 Mode 1 資料中心內的工作負載、技術架構、執行流程和部署模式已經行之有年無須再驗證,然而新興的 Mode 2 資料中心則與傳統 Mode 1 資料中心大不相同。

圖 1、Bimodal IT 雙重 IT 基礎架構示意圖

同時,在該份 Gartner 調查報告中也指出,從 2016 年開始便已經有 2/3 以上的企業及組織,開始建構及整合稱為「基礎架構敏捷化」(Infrastructure Agility)的 Mode 2 敏捷式 IT 基礎架構,由 Mode 2 所建構的資料中心,它所強調的便是「敏捷性」(Agility)與「可擴充性」(Scalability),以便協助企業及組織能夠快速推出各種服務以便因應不斷快速變化的商業數位化需求。

過去,在企業及組織中傳統式的 Mode1 資料中心內,運算資源及儲存資源總是各司其職各自獨立,然而 IT 管理人員應該不難發現市場上的解決方案,已經從幾年前的「融合式基礎架構」(Converged Infrastructure),演變為新興的「超融合基礎架構」(Hyper-Converged Infrastructure,HCI),便是希望能夠解決傳統式 Mode1 資料中心內運算及儲存資源整合及擴充方面的困擾,進而打造出高可擴充性且靈活性高的 Mode 2 基礎架構敏捷化的目標(如圖 2 所示)。

圖 2、基礎架構敏捷化發展歷程

事實上,微軟在 2016 年 10 月推出 Windows Server 2016 作業系統版本時,IT 管理人員便可以透過標準的 x86 硬體伺服器,搭配 Windows Server 2016 內建的 S2D(Storage Spaces Direct)機制,手動為企業及組織打造出 HCI 超融合基礎架構,而無須購買相對昂貴且又有硬體綁定問題的 HCI 超融合基礎架構解決方案。

隨著微軟在 2018 年 10 月推出最新一代 Windows Server 2019 雲端作業系統,也將原本 SDS 軟體定義儲存方案的 S2D(Storage Spaces Direct)推升至第 2 世代。在本文中,我們將說明及實作演練,採用最新 Windows Server 2019 雲端作業系統打造的 S2D 軟體定義儲存方案,與前一代 Windows Server 2016 所打造的 S2D 軟體定義儲存方案有哪些不同之處。





Windows Server 2019 S2D 新增特色功能

在 Windows Server 2019 雲端作業系統中,第 2 世代的 S2D 軟體定義儲存解決方案,除了新增多項亮眼功能之外,原有的特色功能及運作規模和相關支援度也都再度提升,舉例來說,在 Windows Server 2016 版本所建構的 S2D 超融合基礎架構,最大儲存空間支援至「1 PB」,現在透過 Windows Server 2019 所打造的 S2D 超融合基礎架構,最大儲存空間可支援高達至「4 PB」。



支援更大型的運作規模

隨著硬碟供應商因應大量儲存需求而不斷提升硬碟儲存容量,現在主流的硬碟儲存空間已經來到單顆硬碟「14 TB」的儲存空間。因此,這也是為什麼新一代 Windows Server 2019 所打造的 S2D 超融合基礎架構,需要支援更大型運作規模的原因之一。

過去,在 Windows Server 2016 版本所建構的第 1 世代 S2D 超融合基礎架構中,單一 S2D 叢集最大儲存空間支援上限為「1 PB」、每台 S2D 節點主機儲存空間支援上限為「100 TB」、單一 Volume 儲存空間支援上限為「32 TB」。

現在,透過 Windows Server 2019 版本所打造的第 2 世代 S2D 超融合基礎架構,單一 S2D 叢集儲存空間最大可支援至「4 PB」、每台 S2D 節點主機儲存空間支援上限提升至「400 TB」、單一 Volume 儲存空間支援上限提升為「64 TB」(如圖 3 所示)。

圖 3、Windows Server 2019 支援更大型運作規模的 S2D 超融合基礎架構



最適用於邊緣運算環境的仲裁機制

事實上,無論 IT 管理人員採用市面上哪種 HCI 超融合基礎架構解決方案,都必須要搭配「仲裁/見證」(Quorum / Witness)機制,以便因應 HCI 超融合基礎架構發生災難或故障事件時能夠保持高可用性。過去,在 Windows Server 2016 版本中,當管理人員建構好 S2D 超融合基礎架構後,仲裁機制方面僅支援「File Share Witness」及「Cloud Witness」等 2 種仲裁機制。

現在,新一代 Windows Server 2019 版本所建構的 S2D 叢集,已經支援將仲裁機制指向至「USB 隨身碟」(如圖 4 所示)。因此,當企業及組織在分支機構或邊緣運算等小型運作環境時,無須其它硬體伺服器、VM虛擬主機、Active Directory、網際網路……等,也仍然能夠順利運作 S2D 叢集並啟用仲裁機制。

圖 4、組態設定 Windows Server 2019 USB Witness 流程示意圖



儲存裝置延遲異常檢測機制

在建置 S2D 超融合基礎架構時,相信管理人員已經採用微軟的最佳建議作法,為每一台 S2D 叢集節點主機配置相同型號且高效能高耐久性的儲存裝置。然而,即便是企業等級的儲存裝置,也有可能因為儲存裝置中的某個硬體元件不良或即將損壞而導致效能低落,那麼管理人員如何在 S2D 叢集內眾多的儲存裝置中找出效能低落的儲存裝置 ?

在 Windows Server 2019 S2D 叢集中新增儲存裝置延遲異常檢測機制(如圖 5 所示),這項新增機制的靈感來自於 Microsoft Azure 公有雲環境檢測儲存裝置異常的作法。現在,Windows Server 將會記錄每個儲存裝置每次資料「讀取/寫入」(Read / Write)的結果以及延遲時間,因此當儲存裝置發生資料讀寫效能低落,甚至是資料讀寫失敗的情況時,管理人員可以輕鬆透過 WAC(Windows Admin Center)管理平台或 PowerShell Cmdlet 快速找出有問題的儲存裝置。

圖 5、儲存裝置延遲異常檢測機制示意圖



儲存效能加倍的 Mirror-Accelerated Parity

事實上,不管採用哪種 HCI 超融合基礎架構,在「效能/儲存空間/資料可用性」這 3 方面是很難同時面面俱到的,舉例來說,為了考量資料可用性將資料複寫 3 份以便因應儲存裝置故障損壞時,仍然能夠保有資料可用性,然而卻也因為資料複寫 3 份而導致消耗大量的儲存空間。

因此,在 S2D 叢集中便推出整合 RAID-1 資料可用性,以及 RAID-6 節省儲存空間特性的 Volume 稱之為「Mirror-Accelerated Parity」。簡單來說,在此 S2D Volume 中快取層級將會採用效能最佳的 3-Way Mirror 處理資料讀寫,至於資料儲存層級則是採用能夠節省儲存空間的 Dual Parity 來處理,希望讓管理人員能夠在運作效能及儲存空間的節省方面取得平衡點。

現在,Windows Server 2019 S2D 叢集中,針對 Mirror-Accelerated Parity 儲存效能表現的部份,提供相較於舊版 Windows Server 2016 S2D 叢集成長 1 倍(如圖 6 所示),讓管理人員在享有節省儲存空間的同時,又能享有更好的儲存運作效能。

圖 6、Windows Server 2019 S2D Mirror-Accelerated Parity 儲存效能表現示意圖




S2D 實戰–叢集節點主機硬體需求

當企業或組織的 IT 管理人員,希望在內部資料中心建置 S2D 軟體定義儲存技術時,建議可以採用下列硬體規格及基本需求硬體元件:

  • 叢集節點主機: 在 S2D 叢集中,最小運作規模必須由「2 台」叢集節點主機組成,最大運作規模則支援至「16 台」叢集節點主機,並且應採用同一家硬體伺服器製造商及型號。
  • CPU 處理器: 建議至少採用 Intel Nehalem 及 AMD EPYC 或後續新推出的 CPU 處理器。
  • 硬碟控制器: 每台叢集節點主機,必須採用SATA Connected或SAS HBA Connected硬碟控制器,不支援採用內建的ACHI Controller硬碟控制器,或是RAID Controller磁碟陣列卡。
  • 硬碟數量: 採用 Hybrid 架構時,每台叢集節點主機的快取層至少需要 2 顆儲存裝置而資料層則至少需要 4 顆儲存裝置。採用 All-Flash 架構時,每台叢集節點主機至少需要 4 顆儲存裝置。
  • 網路卡: 每台叢集節點主機,建議採用 25 GbE 網路卡或更高速度,並且應選用支援 RDMA 特色功能(RoCE、iWARP)的網路卡。

建議可以直接瀏覽微軟官方網站(Microsoft.com/WSSD),查詢並選擇通過 WSSD(Windows Server Software-Defined)硬體驗證的伺服器,可以有效解決管理人員在挑選硬體伺服器各項硬體元件及 Firmware 版本的困擾。



建立 S2D 網域環境

在本文實作環境中,我們將建立 4 台 Windows Server 主機,其中 1 台擔任 Domain Controller 網域控制站另外 2 台則擔任 S2D 叢集節點主機,最後 1 台則是安裝及擔任 Windows Admin Center 管理平台的工作任務,這 4 台 Windows Server 主機皆安裝最新 Windows Server 2019 雲端作業系統(如圖 7 所示)。

圖 7、安裝 Windows Server 2019 雲端作業系統

值得注意的是,當管理人員要將單機環境的 Windows Server 2019 提升為 DC 網域控制站時,存放 AD 資料庫、記錄檔及 SYSVOL 分割區必須採用傳統的「NTFS」檔案系統才行,因為 AD 資料庫並不支援存放於新式的「ReFS」檔案系統。

在 S2D 叢集節點主機的部份,建立 2 台 S2D 叢集成員伺服器,並將電腦名稱分別命名為「Node01 及 Node02」,每台 S2D 叢集節點主機除了作業系統硬碟之外,皆額外配置「4 顆」300GB 的 SSD 固態硬碟(如圖 8 所示),最後所有的 S2D 叢集節點主機都必須加入「同一個」Windows AD 網域才行。

圖 8、每台 S2D 叢集節點主機額外配置 4 顆 300GB 的 SSD 固態硬碟



安裝伺服器角色及功能

完成 S2D 網域環境及 S2D 成員伺服器加入網域的動作後,接著請為每台 S2D 叢集節點主機安裝所需的伺服器角色及功能。請開啟 PowerShell 指令視窗中,執行「Install-WindowsFeature -Name "Hyper-V","Failover-Clustering","Data-Center-Bridging","RSAT-Clustering-PowerShell","Hyper-V-PowerShell","FS-FileServer"」指令,所安裝的伺服器角色及功能如下:

  • Hyper-V : 安裝 Hyper-V 伺服器角色,以便 S2D 叢集節點主機成為 Hyper-V 虛擬化平台。
  • Failover-Clustering : 安裝容錯移轉叢集伺服器功能。
  • Data-Center-Bridging : 安裝 DCB(Data Center Bridging)伺服器功能,當採用 RoCE v2 的網路卡時此伺服器功能為必要安裝選項,倘若採用 iWARP 網路卡時則可選擇性安裝。
  • RSAT-Clustering-PowerShell : 安裝用於管理容錯移轉叢集的 PowerShell 模組。
  • Hyper-V-PowerShell : 安裝用於管理 Hyper-V 虛擬化平台的 PowerShell 模組。
  • FS-FileServer : 安裝檔案伺服器角色,以便後續 S2D 能夠提供 SOFS 高可用性檔案伺服器服務。

圖 9、為每台 S2D 叢集節點主機安裝所需的伺服器角色及功能



vSwitch 虛擬網路交換器

事實上,在 Windows Server 2012 作業系統版本時,便已經開始支援 RDMA 功能的網路卡,但是有項限制便是 RDMA 網路卡「無法」建立 vSwitch 虛擬交換器及 NIC Teaming,也就是說 RDMA 網路卡只能專用於儲存網路而缺少維運管理上的彈性。

雖然,這項限制已經從 Windows Server 2016 作業系統版本開始便徹底解除,但是在建立 Hyper-V vSwitch 虛擬網路交換器時,必須採用搭配 RDMA 網路卡的「SET(Switch-Embedded Teaming)」機制(如圖 10 所示),而非一般 vSwitch 虛擬網路交換器。

圖 10、RDMA with Switch-Embedded Teaming 運作架構示意圖

此外,目前主流的 RDMA 通訊協定為 RoCE 及 iWARP,倘若 S2D 叢集節點主機配置的 RDMA 網路卡為「RoCE」時,那麼除了 S2D 叢集節點主機必須安裝 DCB 伺服器功能之外,所連接的實體網路交換器也必須支援及啟用 DCB 功能,並組態設定 ETS(Enhanced Transmission Service)和 PFC(Priority Flow Control)功能才行。倘若,S2D 叢集節點主機配置的 RDMA 網路卡為「iWARP」時,則無須依賴實體網路交換器的 DCB 功能及組態設定 ETS 和 PFC 功能即可運作。

目前,RDMA 網路卡中主要支援 iWARP 協定的供應商為 Chelsio 及 Intel,主要支援 RoCE 協定的供應商則是 Broadcom 和 Mellanox,甚至 Cavium(Marvell)供應商則同時支援 iWARP 和 RoCE 協定。



驗證 S2D 容錯移轉叢集

在建立 S2D 容錯移轉叢集之前,請先執行「叢集驗證」(Cluster Validation)的動作,確認目前每台 S2D 叢集節點主機已經符合各項需求,以避免稍後建立 S2D 容錯移轉叢集發生非預期的錯誤。

在本文實作環境中,2 台 S2D 叢集節點主機的電腦名稱為「Node01 和 Node02」,請在其中 1 台主機上開啟 PowerShell 指令視窗,鍵入「Test-Cluster –Node Node01,Node02 –Include "Storage Spaces Direct","Inventory","Network","System Configuration"」指令進行叢集環境的驗證動作(如圖 11 所示)。

圖 11、驗證 S2D 叢集節點主機確保符合建立 S2D 叢集的各項需求



建立 S2D 容錯移轉叢集

當 S2D 叢集節點主機通過容錯移轉叢集驗證程序後,在建立 S2D 容錯移轉叢集之前,請先確保每台 S2D 叢集節點主機沒有任何硬碟已經被「宣告」(Claimed)使用,例如,硬碟初始化為 MBR/GPT、格式化為 ReFS 檔案系統……等。

倘若,不確認硬碟是否已經初始化或格式化過的話,可以採用 Diskpart 指令確認硬碟編號,然後使用 PowerShell 的 Clear-Disk 指令清除硬碟中所有內容,舉例來說,本文實作環境共有 4 顆 300GB 的 SSD 固態硬碟且編號為 1 ~ 4,便可以執行「Clear-Disk –Number 1,2,3,4 –RemoveData –RemoveOEM」指令清除硬碟中所有內容。
請注意,硬碟若已經被宣告使用後,稍後啟用 Storage Spaces Direct 機制時,將無法順利將儲存裝置加入至 S2D 儲存資源池當中。

現在,管理人員可以放心建立 S2D 容錯移轉叢集。在本文實作環境中,S2D 叢集名稱為「wsfc」,而容錯移轉叢集 IP 位址為「10.10.75.30」,請鍵入「New-Cluster –Name wsfc -Node Node01,Node02 –NoStorage –StaticAddress 10.10.75.30」PowerShell 指令建立容錯移轉叢集(如圖 12 所示)。

圖 12、建立 S2D 容錯移轉叢集



啟用 Storage Spaces Direct 機制

在為 S2D 叢集啟用 Storage Spaces Direct 機制之前,請再次確認 S2D 叢集任意 1 台 S2D 叢集節點主機,是否可以看到本機硬碟以及 S2D 叢集中其它叢集節點主機的硬碟數量,舉例來說,本文實作環境中每台 S2D 叢集節點主機除了作業系統之外,還額外配置 4 顆 300GB 的 SSD 硬碟,因此任意 1 台 S2D 叢集節點主機都應該看到總數「8 顆」300GB 的 SSD 硬碟才正確(如圖 13 所示)。

圖 13、確認 S2D 叢集節點主機皆可看到本機及其它台叢集節點主機的硬碟數量

確認 S2D 叢集中總硬碟數量無誤後,便可以在 PowerShelld 指令視窗中執行「Enable-ClusterStorageSpacesDirect」指令,進行啟用 Storage Spaces Direct 機制的動作。

順利為 S2D 叢集啟用 Storage Spaces Direct 機制後,管理人員可以在容錯移轉叢集管理員視窗中,依序點選至「Storage > Pools」項目,即可看到目前 S2D 儲存資源池的空間大小,在本文實作環境中共採用 8 顆 300GB 的 SSD 固態硬碟,建立後的 S2D 儲存資源池儲存空間大小便是 2.33TB(如圖 14 所示)。

圖 14、順利為 S2D 叢集啟用 Storage Spaces Direct 機制



Windows Admin Center 管理平台

現在,管理人員可以透過新世代的 WAC 管理平台進行 S2D 超融合基礎架構的管理作業。在本文實作環境中,安裝最新的 Windows Admin Center 1809 版本,當安裝程序完畢後管理人員便可以採用 Microsoft Edge 或 Google Chrome 瀏覽器,連接 WAC 管理平台並在順利通過使用者身份驗證程序登入後,會先看到 WAC 管理介面簡易的導覽資訊,管理人員可以按下 Next 了解導覽資訊或按下 Skip Tour略過導覽程序,便會立即進入 WAC 管理介面(如圖 15 所示)。
事實上,WAC 管理平台除了支援新世代 Windows Server 2019 建構的 S2D 叢集之外,也支援管理舊版 Windows Server 2016 所建構的 S2D 叢集環境。
圖 15、採用最新 Windows Admin Center 1809 版本的 WAC 管理介面

請在 WAC 管理介面中,依序點選「All Connections > Add > Add Hyper-Converged Cluster Connection」項目,然後在「Cluster name」欄位鍵入希望納管的 S2D 超融合基礎架構叢集名稱,在本文實作環境中名稱為「wsfc.s2d.weithenn.org」(如圖 16 所示),當 WAC 管理平台成功納管 S2D 超融合基礎架構叢集後,將會自動連同所有 S2D 叢集節點成員主機也一併加入至納管的主機清單中。

圖 16、WAC 管理平台順利探索到 S2D 叢集及所有 S2D 叢集節點成員主機

此時,管理人員便可以輕鬆看到 S2D 超融合基礎架構叢集工作負載情況,包括,S2D 叢集節點數量、IOPS 儲存效能、Latency 延遲時間、Throughput 傳輸速率、儲存資源剩餘空間、VM虛擬主機運作數量……等(如圖 17 所示)。

圖 17、透過 WAC 管理平台管理及查詢 S2D 超融合基礎架構運作環境





結語

透過本文的深入剖析及實作演練,相信讀者已經了解新世代 Windows Server 2019 雲端作業系統中,在 SDS 軟體定義儲存技術方面有哪些新增及增強的亮眼特色功能,同時管理人員只要透過 Windows Admin Center 管理平台,更可以達到輕鬆且快速管理 S2D 叢集的目標。