顯示具有 SDS 標籤的文章。 顯示所有文章
顯示具有 SDS 標籤的文章。 顯示所有文章

前言

自從 Windows Server 2016 推出後,大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。本文,將要深入探討在 S2D 軟體定義儲存運作環境中「Storage Pool」的功能改進:

  • 每個 Storage Pool 最大支援「416 Drives」及 「1 PB Raw Capacity」,同時最佳建議是「One pool per Cluster」。
  • 執行「Enable-ClusterS2D」指令啟用 S2D 功能時,會自動建立 Storage Pool 並且把「合格的儲存裝置」(例如,未格式化過的磁碟) 加入到 Storage Pool 當中。同時,當加入新的 S2D 儲存節點時 (Scale-Out) 也會自動把相關的儲存裝置加入到 Storage Pool 當中,當儲存裝置發生故障時會自動退出並從 Storage Pool 當中移除。
  • 透過 S2D PM「Cosmos Darwin」撰寫的 PowerShell,可以輕鬆幫助你了解 Storage Pool 及儲存裝置空間的使用情況。






混亂的開始 (Resiliency, Slabs, Striping)

讓我們先從 3 Nodes 的 S2D 運作架構,每台 S2D Node 具備「2 x 800GB NVMe」以及「4 x 2TB SATA SSD」開始談起。




什麼是 Resiliency?

舉例來說,當我們建立「1 TB - 2WayMirror」的 Volume 時,這表示在「不同 Server、不同 Drives」必須維護共「2 份」副本資料,以便 1 份資料損壞時另 1 份仍然可用。所以,雖然建立 1TB Volume 但實際會佔用 2 TB 空間,這樣的行為稱之「Footprint on the Pool」。




什麼是 Slabs?

在建立的 1 TB Volume 儲存空間中,系統將會把它拆解成眾多的「Slab」並且每個 Slab 大小為「256 MB」(在 Windows Server 2016 技術預覽版本時稱為 Extent 大小為 1024 MB) 。因此,倘若建立 1 TB Volume 儲存空間的話便會拆解成「4,000 Slabs」。




什麼是 Striping?

當我們採用 2-Way Mirror 的方式建立 Volume 並且拆解成眾多 Slab 之後,「每個 Slab」將會建立「2 份副本」,然後透過 S2D 演算法分別存放在「不同 Server, 不同 Drives」當中。




因此,原則上眾多 Slabs 將會「平均且分散」的儲存到不同 Server 不同 Drives 當中。同時,預設情況下 Cluster 當中至少會有 5 個 Drive 儲存「Pool Metadata」以便後續「同步」(Synchronized)及「修復」(Repaired)等作業。此外,即便儲存的 Pool Metadata 都遺失,也不會影響 S2D 的部署及運作。






S2D 這樣設計的目的為何?

效能考量

將 Volume 拆解成眾多 Slab 然後平均分散放置到多個儲存媒體時,這樣可以提供「資料讀寫」的效益同時可以使用多個儲存媒體,以期「最大化 IOPS & I/O Throughput」。因此,S2D 的 2-Way Mirror 機制與傳統的 RAID-1 並不相同。



提升資料安全性

當「儲存裝置」發生故障時,原有儲存的資料副本將會在其它位置進行重建,這個行為稱之為「修復」(Repairing) 並執行下列 2 項操作步驟:

修復步驟1、從「存活」的資料副本中讀取 (讀取單位為 Bytes):
  • 想像一下,假設 S2D 沒有把 Volume 拆解成眾多 Slab 的話,那麼當 1TB Volume 副本所在的硬碟損壞時,採用的若是機械式硬碟要進行上述修復程序的第 1 項時,光是讀取 1TB Bytes 資料這個動作,可想而知整個資料重建程序將會非常緩慢!! 
  • 回到 S2D 的運作架構,有顆機械式硬碟損壞裡面存放一堆 Slab,但是這些 Slab 存活的資料副本是分佈在「不同機械式硬碟」中,有的可能在 Drive03、Drive15、Drive17……等。 
  • 重點就是,這個重建的動作可以同時使用到「多顆」機械式硬碟而非「單顆」機械式硬碟!!

修復步驟2、在其它位置寫入「新的」資料副本,以取代遺失的資料副本:
  • 原則上,只要哪裡有儲存空間就往哪裡寫。但是,機械式硬碟損壞的那台伺服器就會不再放置重新的資料副本。
  • 簡單來說,透過 Volume 打散成 Slab 的機制,不但提升資料安全性讓故障事件發生時「Resync」的等待時間縮短。






考量 Reserve Capacity

簡單來說,在你所建立的 Storage Pool 當中,應該要「預留」一些額外的儲存空間而不要都用盡!! 舉例來說,當機械式硬碟故障進行資料副本的修復程序時,才有緩衝的儲存空間可供使用。這個概念有點類似 HDD Hot Spare 但在實際運作上又有點不同。

強烈建議要預留空間,但就算沒有預留儲存空間 S2D 還是能正常運作,只是當「故障事件」發生時倘若沒有預設儲存空間的話將會影響修復速度。






自動建立儲存集區及重新負載平衡

當 S2D 叢集當中加入新的 S2D Node 時,會自動將 Slab 資料副本自動負載平衡到新的 S2D Node 當中,這個動作稱之為「最佳化」(Optimizing)「重新平衡」(Re-Balancing)。例如,在本文 S2D Cluster 中原本只有 3 Nodes 現在加入第 4 台 Node,只要鍵入「Add-ClusterNode -Name <Name>」PowerShell 指令即可。



順利將第 4 台 Node 加入後,「一開始」該 Node 的儲存裝置的使用空間還是空的。



預設情況下,經過「30 分鐘後」 S2D 將會「自動」執行「重新平衡」(Re-Balancing)的動作,但隨著運作規模大小將會需要不同的時間 (例如,幾小時)。倘若,你不希望等待 S2D 自動執行的話,可以手動執行「Optimize-StoragePool -FriendlyName "S2D*"」的 PowerShell 指令讓 S2D 立即執行重新平衡的動作,並且透過「Get-StorageJob」查看重新平衡的工作進度。



因此,當重新平衡作業執行完畢後,可以看到前 3 台 Node 的使用空間「下降」,因為平均且分散放置到第 4 台 Node 的儲存空間。






小結

  • 建立 S2D 的 Storage Pool 之後,無須再針對 Storage Pool 進行調整 (例如,新增 HDD、刪除 HDD……等)或額外再建立 Pool。
  • 建立的 Volume 會拆解成眾多 Slabs,然後平均分散到不同 Server / 不同 Drives。
  • 最好在 S2D Storage Pool 當中「預留」儲存空間,以便故障事件發生時能夠更快的進行修復作業。
  • 當 S2D 建立的 Storage Pool 加入新的 Node 時,會「自動」進行重新平衡的動作,保持資料副本平均分散到不同 Server / 不同 Drives 的原則。
  • 你可以透過「Get-StoragePool S2D*」、「Get-StoragePool S2D* | Get-PhysicalDisk」查看 S2D Storage Pool 相關資訊。
S2D PM「Cosmos Darwin」撰寫的 PowerShell





參考資源


前言

在 VMware VMworld 2016 大會上,由 VMware 執行長 Pat Gelsinger 正式發表 SDDC 軟體定義資料中心願景中最要的運作元件 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出,並且在日前 2016 年 11 月 15 日時 VMware 官方正式宣佈 vSphere 6.5 新版發佈,同時提供相關新版產品映像檔的下載。



站長將不定期撰寫相關新功能簡介文章: (更新文章符號 💩)

【簡介】




【vCenter Server】




【Security】




【Storage】




【VMware Taiwan vSphere 6.5 新功能介紹】


前言

自從 Windows Server 2016 推出後,大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。甚至,微軟也推出 Project Kepler-47 的輕量型 OEM S2D 解決方案,讓分公司或小型運作環境也能夠享有 S2D 軟體定義儲存技術的好處。本文,將討論在 Windows Server 2016 中的 S2D 軟體定義儲存解決方案中,佔有舉足輕重地位的儲存裝置「SSD 固態硬碟」。



SSD 固態硬碟基礎知識

眾所周知 SSD 固態硬碟具有「資料讀寫壽命」的問題,隨著資料不斷大量的讀取及寫入後即便只是簡單的資料讀取都會有壽命成本的問題,在 SSD 固態硬碟運作環境中這個現象稱之為「讀取干擾 (Read Disturb)」。下列,為常見的 4 種 SSD 固態硬碟類型:

  • SLC: 1 bit per Cell (100,000 or more Write)。
  • MLC: 2 bits per Cell (10,000 ~ 20,000)。
  • TLC: 3 bits per Cell (> 1,000)。
  • QLC: 4 bits per Cell (> 100)。


因此,正確的規劃及選擇 SSD 固態硬碟便更顯現其重要性。那麼,我們來看看 SSD 固態硬碟的存取行為,一般情況下會透過「FTL (Flash Translation Layer)」連接到 NAND Flash 快閃記憶體的內部控制器。同時,FTL 具備下列 2 項機制:
  • 儲存資料時會一起儲存「ECC (Error Correcting Codes)」,當需要恢復資料時便會透過 ECC 機制進行復原的動作。
  • 具備「Over-Provisioning」機制以便超額提供儲存空間。事實上,NAND 是無法直接寫入資料的,必須經過「P/E (Program/Erase)」的處理流程後才能進行寫入資料,每個「Page」的空間最小可達「16 K」。同時,NAND 不會重複寫入同個 Page,然後 FTL 持續追蹤及更新 Erased Pages,並且合併重新寫入的資料區塊以及所對應的 Re-Written Logical Blocks,最終的結果就是 Over-Provisioning。


簡單來說,「NAND Flash SSD」是個複雜且動態的運作環境,必須要整合多項機制才能確保儲存資料的可用性。同時,隨著儲存密度不斷增加的情況下維持資料可用性的難度相形提高,目前為透過「緩衝區 (Buffers)」機制來處理這個部分。同時消費者等級與伺服器等級的 SSD 固態硬碟,在資料可用性的保護機制上也有所不同 :
  • 在「消費者等級」SSD 固態硬碟當中,透過「Volatile Cache」及「電池 (Battery)」機制以確保不會因為意外失去電源而導致資料遺失。
  • 在「伺服器等級」SSD 固態硬碟當中,則透過「電容 (Capacitor)」以提供電源保護機制。


舊式企業級 SSD」(Older Enterprise-Grade SSD),具備可拆卸及更換的「內建電池」提供電源保護機制。


新式企業級 SSD」(Newer Enterprise-Grade SSD),則是使用「電容 (Capacitor)」也就是下圖中 3 顆黃色顆粒裝置以便提供電源保護機制。


那麼,倘若在 S2D 軟體定義儲存的運作環境當中採用「消費者等級 SSD 固態硬碟」時會發生什麼事? 下列,便是採用 1TB SATA SSD (5 年保固)消費者等級的 SSD 固態硬碟進行實驗:
  • QD32 4K Read: 95,000 IOPS
  • QD32 4K Write: 90,000 IOPS
  • 資料儲存耐用性: 185 TB 


根據上述消費者等級的 SSD 固態硬碟效能數據及資料儲存耐用性,我們來估算一下這樣的消費者等級 SSD 固態硬碟其「DWPD (Device Writes per Day)」數值:
  • 185 TB / (365 days x 5 years = 1825 days) = ~ 100 GB writable per day
  • 100 GB / 1 TB total capacity = 0.10 DWPD


首先,透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試:
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Su -D -L -d1800 -Rxml Z:\load.bin

可以看到測試長度為「30 分鐘」,但是從測試數據中可以看到在資料存取不到「3 分鐘」之後 IOPS 突然「下降 10,000 IOPS」,這對於消費者等級的 SSD 固態硬碟來說是非常正常的現象。因為 FTL 已經用完預設準備給 NAND 的寫入空間了,所以導致資料存取速度變得非常的慢,因為整個資料存取動作已經中斷並且必須重新準備。


同樣的工作負載,再次透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試,但是加上「Write-Through」的動作 (參數 -Suw),讓整個 NAND 的延遲時間及 FTL/Buffer 真正顯現出來。從下圖中可以看到,IOPS 效能數據的結果非常差:
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Suw -D -L -d1800 -Rxml Z:\load.bin



結論

因此,在 Windows Server 2016 所建構的 S2D 軟體定義儲存環境中,應該選擇及採用具備「Non-Volatile Write Cache」及「Enterprise-Grade SSD」特性的企業級 SSD 固態硬碟。那麼,該如何確認選擇的企業級 SSD 固態硬碟支援「Non-Volatile Write Cache」機制?
  • 在 DataSheet 中看到「PLP (Power Loss Protection)」字眼,例如,Samsung SM863、Toshiba HK4E…等。
  • 在  DataSheet 中看到「Enhanced Power Loss Data Protection」字眼,例如,Intel S3510、S3610、S3710、P3700…等。




參考資源



前言

日前 (2016.12.8),在 Taiwan 舉辦的 VMware Taiwan vForum 2016 議程簡報已經開放下載了,有興趣的朋友可以參考看看。

簡報下載

主題演講




分會場 1、軟體定義資料中心




分會場 2、軟體定義儲存




分會場 3、軟體定義網路及安全




分會場 4、多雲維運與自動化




分會場 5、行動終端應用




分會場 6、Cloud Native


網管人雜誌

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




文章目錄

前言
實體網路基礎架構
          Leaf-Spine 網路架構
          建立多路徑路由環境
          IP MultiCast
          網路安全性
          實體網路卡配置
虛擬網路架構
          vSwitch 虛擬網路交換器
          VMkernel Port
          停用流量管控機制
          NIC Teaming
          Jumbo Frames
          Switch Discovery Protocol
結語





前言

在 VMware 所擘劃的 SDDC 軟體定義資料中心願景中,在 SDC 軟體定義運算的部分由 vSphere ESXi 虛擬化平台擔綱,而在 SDN 軟體定義網路的部分為 NSX 虛擬化平台解決方案,在 SDS 軟體定義儲存的部分,便是由 VMware Virtual SAN(簡稱 VSAN)負責。

圖 1、VMware SDDC 軟體定義資料中心願景

簡單來說,透過 VMware VSAN 技術便能夠將多台 x86 實體伺服器中,配置於實體伺服器的「本機硬碟(Local Hard Disk)」串連起來,進而將叢集當中所有叢集節點主機的儲存資源整合起來,成為一個巨大的儲存資源池並且能夠互相共用。

同時,為了提供足以運作大型運作規模的軟體定義儲存資源,因此 VSAN 支援採用「Hybrid」儲存資源運作架構,將快取資料存放於快閃式儲存(例如,SSH / NVMe)中,至於儲存資料則放於一般機械式硬碟內。倘若,需要更高的儲存效能則可以建置「All-Flash」運作架構,也就是連同資料儲存空間的部分也交由一般的 SSD 固態硬碟負責。

圖 2、VSAN 運作架構示意圖

目前,VMware VSAN 最新釋出為 6.2 版本(第 4 代 VSAN),除了原有加強監控 IOPS 效能及健康狀況外,同時也推出重複資料刪除與壓縮 、EC 編碼技術和 QoS 品質管控機制。在本文中,我們將從實體網路環境至 vSphere 虛擬化環境,深入剖析最佳規劃設計準則及相關組態設定建議,以便幫助企業及組織的管理人員打造高可用效高效能的 VSAN 運作環境。

圖 3、VSAN 版本演進及功能進化示意圖



實體網路基礎架構

在資料中心網路基礎架構中,傳統網路環境採用「Access-Aggregation-Core」的 3 層式架構,以便處理資料中心內「南 - 北(North - South)」的網路流量,同時為了避免網路環境發生「迴圈(Looping)」的情況,通常會啟用 STP(Spanning Tree Protocol)機制防止網路環境發生迴圈的情況,但也等同於將網路的整體頻寬限制在 50 %

然而,隨著虛擬化及雲端運算不斷的發展,現代化資料中心的網路架構已經改為採用架構簡單 、 可擴充性 、 高網路頻寬 、 容錯機制和 QoS 網路流量管控的「Leaf-Spine」2 層式架構。不管採用哪一種網路環境及基礎架構,在 VMware VSAN 運作環境中皆支援舊式的 3 層式網路架構或新式的 2 層式網路架構。

圖 4、 傳統 3 層式架構(Access-Aggregation-Core)與新式 2 層式架構(Leaf-Spine)示意圖



Leaf-Spine 網路架構

VMware VSAN 為 SDS 軟體定義儲存解決方案,所以在 VSAN 叢集中每台 ESXi 成員主機便是 1 台儲存資源節點主機,因此每台儲存資源節點主機之間將會有高速資料傳輸的需求(東 - 西向網路流量),應該要保持網路傳輸極低的延遲時間,否則將會造成 VSAN 儲存效能上的問題。

此外,在網路頻寬的規劃上也非常重要,舉例來說,VSAN 儲存網路環境建議採用 10 Gbps 網路頻寬環境,雖然 1 Gbps 網路環境也能運作但是將會造成 VSAN 儲存效能上的問題,因為在 1 Gbps 網路環境中假設重建儲存空間為 12 TB 時,那麼儲存資源節點主機之間的資料同步作業將需要 24 小時以上。

即便規劃 10 Gbps 網路頻寬環境搭配 Leaf-Spine 網路架構,後續在規劃 VSAN 叢集時也必須考量實務上儲存資源節點主機的放置及環境。舉例來說,如圖 5 所示可以看到為 10 Gbps 網路頻寬的 Leaf-Spine 網路架構,機櫃 1 中為編號 1 ~ 16 儲存資源節點主機而機櫃 2 為編號 17 ~ 32 儲存資源節點主機,倘若只是單純將這 32 台儲存資源節點主機建立 1 個 VSAN 容錯網域的話,那麼屆時在儲存資源節點主機之間的溝通網路頻寬,將會因為比例(4:1)的關係有可能只達到 2.5 Gbps 的水準。

因此,建議在這樣的運作環境中建立 3 個 VSAN 容錯網域(Fault Domains),假設每台儲存資源節點主機原始儲存空間為 10 TB,當設定 FTT = 1 時將會有 6 TB 空間用於保護 VM 虛擬主機,在這種情況下將會有 4/3(也就是 30 Gbps 可以進行重建資料的動作),並且在沒有發生磁碟資源爭奪的情況下只需要 26 分鐘即可完成,即便重建資料儲存空間達 12 TB 並且頻寬少到 10 Gbps,那麼重建時間也僅需要 156 分鐘即可完成。

圖 5、VMware VSAN 採用 Leaf-Spine 網路架構示意圖



建立多路徑路由環境

目前,許多企業或組織已經在資料中心網路環境內,建立 STP 機制以防止網路環境發生迴圈的情況,同時在 Layer 2 網路環境內也應建立 ECMP(Equal-Cost Multi-Path routing)、SPB(Shortest Path Bridging)或 TRILL(Transparent Interconnection of Lots of Links)……多路徑路由或最短路徑等機制。同樣的,在 VMware VSAN 運作環境中皆支援這些網路拓撲基礎架構,重要的是必須良好規劃設計 VSAN 叢集中 ESXi 成員主機的「東 - 西」向網路。

根據 VMware 官方最佳作法,在 VSAN 叢集同一個容錯網域內的 ESXi 成員主機之間,除了確保東西向網路具備低延遲網路時間之外,在實體交換器的部分應該採用「交換機堆疊」(Switch Stack)的運作架構,以滿足高可用性及網路頻寬輸送量的需求。

圖 6、ECMP 多路徑路由運作示意圖



IP MultiCast

簡單來說「IP 多點傳送」(IP Multicast)機制,是可以「1 對多」或「多對多」的 IP 網路通訊技術。一般來說,會建議將 VSAN 運作環境建立於 Layer 2 網路環境中,以便降低複雜度及管理成本。倘若,將 VSAN 運作環境建立於 Layer 3 網路環境時,那麼實體網路一定要建立 IP Multicast 機制。

在 IP 多點傳送運作環境中,使用的 IP 多點傳送位址稱為「多點傳送群組」(Multicast Group,MG)。同時,在預設情況下當 VSAN 叢集建立時,預設便會自動分配 IP 多點傳送位址給節點主機,預設的 VSAN 多點傳送群組位址為「224.1.2.3」,而 VSAN 多點傳送群組代理程式位址為「224.2.3.4」。
請注意! 倘若希望調整預設的 VSAN 多點傳送群組位址,或是 VSAN 多點傳送群組代理程式位址的話,請參考 VMware KB 2075451 文件內容即可進行調整。

在 VSAN 叢集運作環境中,叢集節點主機透過 VMkernel Port 以 IP 多點傳送機制,透過 IGMP(Internet Group Management Protocol)互相傳送 Metadata 以及加入或離開 VSAN 叢集等資訊,同時在叢集節點主機之間也是透過 IP 多點傳送機制,互相偵測對方是否存活。

在預設情況下,VSAN 叢集將會採用 IGMP v3 版本進行「交涉」(Negotiate)的動作,倘若網路環境不支援 IGMP v3 的話,那麼就會採用 IGMP v2 進行交涉的動作。VMware 最佳作法,建議在 Layer 3 網路環境中採用一致的 IGMP 版本即可。

在 VSAN 叢集運作環境中,倘若叢集節點主機之間需要跨越多個子網路時,便需要採用 PIM(Protocol Independent Multicast)機制,並且支援 4 種模式以便因應不同的應用情境,PIM-DM(PIM Dense Mode)適用於 1 對多環境,PIM-SM(PIM Sparse Mode)同樣適用於 1 對多環境,當 Layer 3 網路環境僅支援 IGMP v2 時便建議採用此模式,Bi-PIM(Bidirectional PIM)適用於多對多環境,PIM-SSM(PIM Source-Specific Multicast)適用於多對多環境,且完全支援 IGMP v3 環境中使用。

圖 7、Layer 3 網路環境 PIM-SSM 運作機制示意圖

Layer 2 網路規劃建議
當你決定將 VSAN 架構運作於 Layer 2 網路環境時,下列為 Layer 2 網路規劃建議假設採用 VLAN ID 1,並且 IGMP Querier 運作於網路交換器上而非路由器。值得注意的是,務必確認實體網路交換器支援 IGMP v2 或 IGMP v3(例如,Cisco Nexus 交換器支援 IGMP v3,而 Brocade VDX 交換器僅支援 IGMP v2)。

圖 8、 運作於 Layer 2 網路環境的 VSAN 架構示意圖

Layer 3 網路規劃建議
當你決定將 VSAN 架構運作於 Layer 3 網路環境時,表示屆時 VSAN 叢集節點主機之間將有 Layer 3 設備(例如,L3 網路交換器或路由器)。同時,因為必須針對每個 Layer 3 分區送出請求,所以 IGMP Querier 必須是預設閘道,並且必須具備多點傳送群組的成員資格以便執行加入及更新 PIM 的動作。

圖 9、 運作於 Layer 3 網路環境的 VSAN 架構示意圖



網路安全性

與其它 IP 儲存網路流量一樣,在 VSAN 儲存網路中儲存資源節點主機之間的流量並「沒有加密」。因此,在規劃設計 VSAN 儲存網路時,應該規劃獨立且安全的 VLAN 網段進行 VSAN 儲存流量隔離。倘若,管理人員需要更高的安全性,那麼可以在更高運作層級中進行資料加密的動作即可,舉例來說,可以在 VM 虛擬主機的客體作業系統中執行資料加密工作任務。

實體網路卡配置

下列為 VSAN 叢集運作環境中,為每台 ESXi 主機規劃設計實體網路卡時的配置建議:

  • 至少配置 1 個專屬於 VSAN 儲存流量的實體網路卡。建議配置 2 個或以上實體網路卡,以便達到 VSAN 儲存流量負載平衡及容錯移轉機制。
  • 建議將 VSAN 儲存流量(VMkernel Port),在 Layer 2 層級以 VLAN 隔離以維持基本網路安全性。倘若,需要與其它網路流量共用(例如,VM 虛擬主機 、vSphere vMotion……等),那麼務必要搭配 NIOC(Network I/O Control)網路流量頻寬管控機制。
  • 在 Hybrid VSAN 運作架構中,若採用 1 Gbps 網路頻寬則必須規劃多個且專屬的實體網路卡,建議改為採用 10 Gbps 網路頻寬環境。
  • 在 All Flash VSAN 運作架構中,倘若採用 SATA SSD 固態硬碟時仍可採用 10 Gbps 網路頻寬環境,倘若採用 SAS、NVMe、PCIe 或 Ultra DIMM 等快閃儲存資源時,建議採用 25 Gbps 或 40 Gbps 網路頻寬環境(甚至 100 Gbps 也支援)。






虛擬網路架構

了解 VSAN 運作架構中實體網路環境的部分後,接下來我們將 VSAN 叢集的規劃設計重點轉移到 vSphere 虛擬化環境中,我們將依序討論 vSwitch 虛擬網路交換器和 VMkernel Port,然後再深入至 NIC Teaming 負載平衡機制及交換器探索機制的部分。


vSwitch 虛擬網路交換器

在 VSAN 運作環境中,支援「標準型交換器」(vNetwork Standard Switch,vSS)或「分散式交換器」(vNetwork Distributed Switch,vDS)。VMware 最佳作法,建議管理人員採用 vDS 分散式交換器,主要原因是 vSS 並不支援相關進階管理功能,並會增加企業及組織在管理 VSAN 運作環境中的營運成本,舉例來說,vSS 不支援 LBT(Load Based Teaming)負載平衡機制 、LLDP(Link Layer Discovery Protocol)交換器環境探索機制 、NIOC(Network IO Control)網路流量管控機制……等。
請注意! 有關 vSS 標準型交換器及 vDS 分散式交換器,這兩種虛擬化網路交換器的功能差異詳細說明,請參考 VMware KB 1010555 文件內容。
圖 10、vDS 分散式交換器啟用 NIOC 網路流量管控示意圖

值得注意的是,當 vDS 分散式交換器啟用 NIOC 網路流量管控機制後,共有 3 種管控流量的方式分別是「共用率值」(Share)、「保留」(Reservation)、「限制」(Limit)。VMware 最佳作法,考量網路頻寬整體使用率及管理方便度和靈活性,建議採用共用率值的方式進行網路頻寬的管控動作。只要在 vSphere Web Client 管理介面中,依序點選「首頁 > 網路功能 > vDS Switch > 管理 > 資源配置」項目,即可針對網路流量進行頻寬管理的組態設定。

此外,如果 VM 虛擬主機有啟用 vSphere FT 高可用性機制的話,那麼也請將 vSphere FT 網路流量的共用率值提升,因為 vSphere FT 為「延遲時間敏感」(Latency-Sensitive)類型的網路流量,倘若發生網路頻寬不足的情況將會造成受保護的 VM 虛擬主機,發生非預設的運作錯誤。

圖 11、vDS 分散式交換器啟用 NIOC 網路流量管控機制



VMkernel Port

完成 vSwitch 虛擬網路交換器的規劃後,接著便是新增 VMkernel Port 來處理 VSAN 儲存流量。基本上,ESXi 虛擬化平台上所有類型的流量,都會透過 VMkernel Port 服務類型的組態設定後進行傳送,並且在 VMkernel Port 當中除了 ESXi 主機的管理網路流量之外,還有其它類型的網路流量。舉例來說,VMkernel Port 還負責 vSphere vMotion、iSCSI、NAS/NFS、VSAN、vSphere Replication 及 vSphere FT……等網路流量。

在舊版 vSphere 5.5 時,VMkernel Port 網路流量類型只有 4 種。在新版 vSphere 6.0 運作環境中,VMkernel Port 網路流量則細分為 7 種,其實是將原本歸納於管理流量的相關網路流量,再細分後拆出來成為獨立的網路流量,分別是佈建流量、vSphere Replication 流量、vSphere Replication NFC 流量。

其中,「佈建流量」負責處理 VM 虛擬主機「複製」(Cloning)、「冷遷移」(Cold Migration),以及建立「快照」(Snapshot)時所產生的網路流量,同時當採用的儲存資源若未支援 VAAI(VMware vSphere Storage APIs Array Integration)硬體卸載功能時,產生的佈建網路流量將會更為明顯。
請注意! 有關 VAAI 硬體卸載功能的詳細資訊,請參考 VMware KB 1021976

「vSphere 複寫流量」項目,則是負責處理 ESXi 主機傳輸複寫資料至 vSphere Replication 虛擬設備時使用,「vSphere 複寫 NFC 流量」項目,負責處理 vSphere Replication 虛擬設備從網路環境複製檔案,至 ESXi 主機 Datastore 儲存資源之間的網路流量。

請依序執行下列操作步驟,即可透過 vSphere Web Client 管理工具建立 VMkernel Port,並加入至現有的 vSwitch 虛擬網路交換器中:

1. 在本文實作環境中,請開啟瀏覽器鍵入網址 https://vcenter.vdi.weithenn.org:9443/vsphere-client,鍵入管理者帳號密碼後便能透過 vSphere Web Client 管理工具,連接至 vCenter Server 執行個體。
2. 依序點選「首頁 > 主機和叢集」項目後,點選準備建立 VMkernel Port 的 ESXi 主機。
3. 依序點選「管理 > 網路功能 > VMkernel 介面卡」項目後,按下「新增網路」圖示。此時,管理畫面將會彈出新增網路精靈視窗。
4. 在選取連線類型視窗中,請點選「VMkernel 網路介面卡」項目後,按下一步鈕。
5. 在本文實作環境中,我們要將 VSAN 用途的 VMkernel Port 加入至現有的 vDS 分散式交換器中,因此選擇「選取現有網路」項目後按下瀏覽鈕,選擇要將 VMkernel Port 加入至哪個連接埠群組內(本文實作環境中,vDS 分散式交換器名稱為 Dswitch,而連接埠群組名稱為 DPortGroup),請按下一步鈕繼續組態設定程序。
6. 在連接埠內容頁面中,請於啟用服務設定區塊中勾選「Virtual SAN 流量」項目,以便為此 VMkernel Port 啟用 VSAN 儲存流量,請按下一步鈕繼續組態設定程序(如圖 12 所示)。
7. 在 IPv4 設定頁面中,請為 VMkernel Port 指定採用 DHCP 動態取得 IPv4 位址,或選擇採用靜態 IPv4 設定,手動為 VMkernel Port 指定 IP 位址及子網路遮罩等網路資訊。建議為每台 VSAN 叢集節點主機設定固定的 IPv4 位址,請按下一步鈕。
8. 在即將完成頁面中,檢視 VMkernel Port 組態設定內容正確無誤後,按下完成鈕系統便立即於剛才選定的 vDS 分散式交換器,以及所屬的連接埠群組中建立 VMkernel Port 並啟用 VSAN 儲存流量功能。

圖 12、建立 VSAN 用途的 VMkernel Port 並勾選啟用 VSAN 流量項目

請注意! 倘若 VSAN 用途的 VMkernel Port 網段,與 ESXi 主機的管理網路不同(採用不同預設閘道及 DNS 伺服器 IP 位址),那麼便需要建立及採用非預設值的 TCP/IP 堆疊。有關建立 VSAN 用途的 VMkernel Port 及 TCP/IP 堆疊的詳細資訊,請參考 VMware KB 2058368 文件內容。



停用流量管控機制

在 VMware VSAN 軟體定義儲存的網路環境中,VSAN 不管採用 vSS 標準型交換器或 vDS 分散式交換器,都必須與 ESXi 主機的實體網路卡(在 vSphere 環境中稱為 Uplink)進行關聯,以便屆時其上運作的 VM 虛擬主機能夠透過 Uplink 與實體網路環境溝通。

預設情況下,在 vSphere 虛擬化環境中所有的 Uplink 都會啟用「流量管控」(Flow Control)機制。因為,在乙太網路環境運作架構中,倘若 ESXi 主機不堪網路流量沈重的工作負載時,將會送出「暫停封包」(Pause Frames),以便通知在網路流量發送端暫時停止網路傳輸。

但是,在 VSAN 運作環境中已經內建「壅塞管理」(Congestion Management)機制,能夠有效防止因為網路流量爆發而產生壅塞的情況,或者是因為快取及緩衝機制所導致的壅塞。因此,VMware 官方最佳作法為建議將 VSAN 叢集中所有 ESXi 成員主機,組態設定 VSAN 用途的 VMkernel Port「停用」(Disable)Flow Control 機制,以避免與內建的壅塞管理機制互相干擾。
請注意! 有關如何在 VSAN 叢集節點主機中,組態設定 VMkernel Port 停用 Flow Control 機制的詳細資訊,請參考 VMware KB 1013413 文章內容。



NIC Teaming

在 VSAN 運作架構中啟用 NIC Teaming 功能後,若採用「Port ID」、「Source MAC」、「IP Hash」等原則時,其實僅具備高可用性(容錯移轉)特色並沒有負載平衡功能。VMware 最佳作法,當採用 vDS 分散式交換器時能夠使用特殊 NIC Teaming 機制,也就是「LBT(Load Based Teaming)」的負載平衡機制,啟用後將會每隔 30 秒偵測實體網路卡流量並進行流量負載平衡作業。

圖 13、LBT(Load Based Teaming)負載平衡機制運作示意圖

圖 14、將 NIC Teaming 負載平衡機制調整為 LBT 模式

請注意! 有關 NIC Teaming 負載平衡及容錯移轉機制的詳細資訊,請參考 VMware KB 2006129KB 1004048 文件內容。



Jumbo Frames

VSAN 運作架構中支援 Jumbo Frames,但是並非運作 VSAN 環境的必要條件。在 VMware 的測試結果中,發現 Jumbo Frames 機制可以減少 CPU 使用率並提高輸送量,但是因為 vSphere 已經使用 TCP Segmentation Offload(TSO)及 Large Receive Offload(LRO)機制,所以 Jumbo Frames 的幫助其實是有限的。
請注意! 有關 TSO 及 LRO 的詳細資訊,請參考 VMware KB 2055140 文件內容。

VMware 最佳作法,建議採用現有的 MTU/Frame Size 即可。也就是說倘若企業及組織的資料中心內已經啟用 Jumbo Frames 機制,那麼 VSAN 用途的網路環境也請啟用 Jumbo Frames。倘若資料中心並沒有啟用 Jumbo Frames,那麼不必單獨為 VSAN 網路特地啟用 Jumbo Frames。

圖 15、在 vSphere 運作環境中啟用 Jumbo Frames 機制



Switch Discovery Protocol

在 vSphere 虛擬化網路環境中,偵測實體網路環境探索協定分別支援 CDP(Cisco Discovery Protocol)及 LLDP(Link Layer Discovery Protocol)。值得注意的是,採用 vSS 標準型交換器僅支援 CDP,採用 vDS 分散式交換器才支援 CDP/LLDP。同時,VMware 最佳作法為不管採用 CDP 或 LLDP 皆請開啟傳送及接受模式。

圖 16、啟用 LLDP 探索通訊協定並啟用傳送及接受模式



結語

透過本文的說明及實作,從實體網路環境到 vSphere 虛擬化網路環境,相信企業或組織的 IT 管理人員只要遵從 VMware 官方的最佳作法及建議進行設計規劃,便能建構出高可用性、高效能並具備靈活性的 VSAN 軟體定義儲存環境。


網管人雜誌

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



文章目錄

前言
S2D 簡介
          S2D 支援的部署模式
          S2D 硬體需求
S2D in Azure實戰演練
          建立用於 S2D 的 vNet 虛擬網路
          建立用於 S2D 的儲存體帳戶
          建立 S2D 環境 DC 網域控制站
          建立 S2D-Node 成員伺服器
          建立 S2D 容錯移轉叢集
          啟用 Storage Spaces Direct 機制
          建立 vDisk 及 Volume
          建立 SOFS 檔案分享資源
結語





前言

在上個月(9/26 ~ 9/30)時,微軟在 Ignite 2016 年度技術大會上正式發佈 Windows Server 2016,以及 System Center 2016 產品。在玲瑯滿目的眾多新功能當中,相信不少 IT 人員對於「軟體定義儲存(Software-Defined Storage,SDS)」技術的部分應該越越欲試,它是由 Windows Server 2012 R2 當中的「Storage Space」技術演化而來,並且在 Windows Server vNext 開發時期時稱之為「Storage Spaces Shared Nothing」,在 Windows Server 2016當中則正式稱為「Storage Spaces Direct(S2D)」。

圖 1、Storage Spaces Direct 運作架構示意圖

但是,企業或組織的 IT 管理人員可能苦無手邊沒有相關硬體資源可以進行測試而苦惱。本文,將實作演練透過 Microsoft Azure 公有雲環境,輕鬆建立 S2D 運作環境,讓 IT 管理人員無須準備任何硬體伺服器,即可實作微軟最新一代軟體定義儲存技術 S2D。





S2D 簡介

簡單來說,最新 Windows Server 2016 當中的 S2D 軟體定義儲存技術,與舊版 Windows Server 2012 R2 的 Storage Spaces 技術,最大不同在於它可以將多台硬體伺服器的「本機硬碟(Local Disk)」串聯後整合成一個巨大的儲存資源池。

圖 2、S2D軟體定義儲存技術支援本機硬碟運作架構示意圖



S2D 支援的部署模式

那麼我們來看看 S2D 軟體定義儲存技術支援哪些部署模式,以避免往後實作時發生觀念混亂的情況。在 S2D 技術中支援兩種部署模式:

  • 超融合式(Hyper-Converged)。
  • 分類(Disaggregated)。


倘若,企業或組織希望採用「超融合式(Hyper-Converged)」部署模式,也就是將「運算(Compute)、儲存(Storage)、網路(Network)」等資源,全部都「整合」在一起並將 Hyper-V 及 S2D 技術都運作在「同一個」容錯移轉叢集環境中。那麼,屆時 VM 虛擬主機應該直接運作在 CSV 叢集共用磁碟,而非運作在 SOFS(Sacle-Out File Server)共享路徑,同時也能省去針對檔案伺服器存取及權限的部份進行組態設定,這樣的部署方式適合用於「中小型」規模的運作架構。

圖 3、S2D 超融合式部署模式運作示意圖

如果,企業或組織採用「分類(Disaggregated)」部署模式的話,那麼將會把「運算(Compute)、儲存(Storage)、網路(Network)」等資源「分開」管理,也就是將 Hyper-V 及 S2D 技術都運作在「不同」的容錯移轉叢集環境中,這樣的部署方式則適合用於「中大型」規模的運作架構。

圖 4、S2D 分類部署模式運作示意圖

請注意,在 Microsoft Azure 公有雲環境上,Windows Server 2016 主機「不支援」啟用 Hyper-V 伺服器角色。因此,在 Microsoft Azure 公有雲環境中的 S2D 軟體定義儲存技術,只能建立及使用 SOFS 檔案共享機制。



S2D 硬體需求

倘若,企業或組織的 IT 管理人員,希望在內部資料中心建置 S2D 軟體定義儲存技術的話。下列便是建立 S2D 軟體定義儲存技術時,建議採用的硬體規格及需求清單:

  • 叢集節點: 最少必須由 2 台叢集節點組成,最多支援至 16 台叢集節點。
  • CPU / Memory: 每台叢集節點,建議至少採用 Dual-Socket CPU(Intel Xeon E5 v3 Family)及 128 GB 記憶體。
  • 硬碟控制器: 每台叢集節點,必須採用 SATA Connected 或 SAS HBA Connected 硬碟控制器,不支援採用內建的 ACHI Controller 硬碟控制器,或是 RAID Controller 磁碟陣列卡。
  • 硬碟數量: 每台叢集節點,最少應該使用 2 顆 SSD 固態硬碟及 4 顆機械式硬碟,並且採用下列搭配方式: 
          NVMe + SAS 或 SATA SSD。
          NVMe + SAS 或 SATA HDD。
          SAS 或 SATA SSD + SAS 或 SATA HDD。
  • 網路卡: 每台叢集節點,最少應具備 1 Port 10GbE 網路卡,並且必須支援 RDMA 特色功能(RoCE、iWARP),目前支援的網路卡廠商有 Mellanox(CX3-Pro)、Chelsio(T5)、Avago/Emulex(Skyhawk)……等。





S2D in Azure實戰演練

建立用於 S2D 的 vNet 虛擬網路

那麼,讓我們開始在 Microsoft Azure 公有雲建立 S2D 運作環境吧。登入 Microsoft Azure Portal 入口網站後,依序點選「新增 > 網路 > 虛擬網路」,請在選取部署模型下拉選單中選擇至「資源管理員」項目後按下建立鈕,在建立虛擬網路視窗中依序填入下列資訊後按下建立鈕:

  • 名稱: 請填入用於 S2D 運作環境的 vNet 虛擬網路名稱,本文實作環境為「EA-vNet-S2D」。
  • 位址空間: 請填入此 vNet 虛擬網路的 IP 位址空間,本文實作環境為「10.10.0.0/16」。
  • 子網路名稱: 請填入此 vNet 虛擬子網路的名稱,本文實作環境為「S2D-Node」。
  • 子網路位址範圍: 請填入此 vNet 虛擬子網路的 IP 位址空間,本文實作環境為「10.10.75.0/24」。
  • 訂用帳戶: 請選擇採用的 Azure 訂閱帳戶名稱。
  • 資源群組: 此 vNet 虛擬網路要加入新建的資源群組,或加入至現有的資源群組當中。本文實作環境為建立新的資源群組,並且名稱為「RG-S2D」。
  • 位置: 此 vNet 虛擬網路及資源群組所要部署的位置,本文實作環境挑選離台灣最近的資料中心「東亞」。

圖 5、建立資源群組及 vNet 虛擬網路



建立用於 S2D 的儲存體帳戶

順利建立用於 S2D 架構的虛擬網路環境後,接著建立用於 S2D 架構的儲存資源。請在 Azure Portal 入口網站中,依序點選「新增 > 資料+儲存體 > 儲存體帳戶」,在建立儲存體帳戶視窗中依序填入下列資訊後按下建立鈕:

  • 名稱: 請填入用於 S2D 運作環境的 Blob 儲存體帳戶名稱,本文實作環境為「eablobs2d」。
  • 部署模型: 請選擇 Blob 儲存體帳戶所採用的部署類型,本文實作環境搭配新式的 vNet 儲存網路,而非傳統的 vNet 虛擬網路。因此,選擇採用「資源管理員」部署類型。
  • 帳戶種類: 考量到後續此 Blob 儲存體帳戶,仍有可能整合 Blob、檔案、資料表與佇列,所以選擇採用「一般用途」帳戶種類。
  • 效能: 選擇此 Blob 儲存體帳戶的效能選項,考量屆時 Azure VM 虛擬主機運作效率,因此選擇採用「進階」效能選項。
  • 複寫: 選擇此 Blob 儲存體帳戶的複寫方式,預設情況下採用進階效能選擇的 Blob 儲存體帳戶,將自動採用「本地備援儲存體(LRS)」。
  • 訂用帳戶: 請選擇採用的 Azure 訂閱帳戶名稱。
  • 資源群組: 此 vNet 虛擬網路要加入新建的資源群組,或加入至現有的資源群組當中。本文實作環境採用剛才新建立的資源群組「RG-S2D」。
  • 位置: 此 vNet 虛擬網路及資源群組所要部署的位置,本文實作環境挑選離台灣最近的資料中心「東亞」。

圖 6、建立 Blob 儲存體帳戶



建立 S2D 環境 DC 網域控制站

首先,請建立 1 台 Azure VM 虛擬主機(採用 Windows Server 2016 TP5 作業系統),以便擔任屆時 S2D 運作環境的 DC 網域控制站。請在 Azure Portal 入口網站中,依序點選「新增 > Marketplace > 虛擬機器 > Windows Server > Windows Server 2016 Technical Preview 5」,在選取部署模型下拉選單中選擇至「資源管理員」項目後按下建立鈕,在建立虛擬機器視窗中依序填入下列資訊後按下建立鈕:

  • 名稱: 請填入此台 Azure VM 虛擬主機的名稱,本文實作環境為「S2D-DC」。
  • VM disk type: 選擇此台 Azure VM 虛擬主機的磁碟種類,考量屆時 Azure VM 虛擬主機運作效率,因此選擇採用「高階(SSD)」選項。
  • 使用者名稱: 請鍵入此台 Azure VM 虛擬主機預設管理者帳號名稱,本文實作環境為「Weithenn」。
  • 密碼: 請鍵入此台 Azure VM 虛擬主機預設管理者密碼。
  • 確認密碼: 請再次鍵入此台 Azure VM 虛擬主機預設管理者密碼,以確認 2 次管理者密碼皆鍵入相同無誤。
  • 訂用帳戶: 請選擇採用的 Azure 訂閱帳戶名稱。
  • 資源群組: 此 vNet 虛擬網路要加入新建的資源群組,或加入至現有的資源群組當中。本文實作環境採用剛才新建立的資源群組「RG-S2D」。
  • 位置: 此 vNet 虛擬網路及資源群組所要部署的位置,本文實作環境挑選離台灣最近的資料中心「東亞」。

圖 7、建立 Azure VM 虛擬主機

請注意,本文在撰寫時 Azure 公有雲的 Makeplace 當中,仍僅提供 Windows Server 2016 TP5 技術預覽版本。因此,倘若你採用如同本文的建置方式,則建置好的 S2D 軟體定義儲存資源,應該僅使用於測試或研發環境而非線上營運環境。
接著,在選擇 VM 虛擬主機規模大小的視窗中,選擇此 VM 虛擬主機的運作規模。本文實作環境中選擇採用「DS1 標準」的 VM 虛擬主機規模後,請按下「選取」鈕。

圖 8、選擇 Azure VM 虛擬主機採用的規模大小

建立 Azure VM 虛擬主機的第 3 個步驟,選擇此台 VM 虛擬主機採用的儲存體帳戶、vNet 虛擬網路……等資訊,請依序選擇下列相關資訊後按下確定鈕:

  • 儲存體帳戶: 請選擇此台 Azure VM 虛擬主機採用的儲存體帳戶,本文實作環境選擇剛才建立的「eablobs2d」儲存體帳戶。
  • 虛擬網路: 請選擇此台 Azure VM 虛擬主機採用的 vNet 虛擬網路,本文實作環境為選擇剛才建立的「EA-vNet-S2D」虛擬網路。
  • 子網路: 請選擇此台 Azure VM 虛擬主機採用的 vNet 虛擬網路子網段,本文實作環境選擇剛才建立的「S2D-Node(10.10.75.0/24)」虛擬子網路。
  • 公用 IP 位址: 啟用此台 Azure VM 虛擬主機採用 Public IP 位址,以便屆時可由網際網路透過 RDP 遠端桌面連線進行管理,本文實作環境定義名稱為「S2D-DC-PIP」。
  • 網路安全性群組: 定義此台 Azure VM 虛擬主機的防火牆規則,預設情況下只會開啟「RDP(TCP / 3389)」防火牆輸入規則,本文實作環境定義名稱為「S2D-DC-NSG」。
  • 擴充功能: 選擇 Azure VM 虛擬主機是否安裝其它擴充功能,例如,Microsoft Antimalware。本文實作環境未選擇安裝任何擴充功能。
  • 可用性設定組: 在 Azure 公有雲環境中的 VM 虛擬主機,倘若需要可用性則需要建立可用性設定組。考量後續 S2D 運作環境的可用性,應該要建立 2 台 DC 網域控制站,因此建立名稱為「AS-S2D-DC」的可用性設定組。
  • 監控: 是否針對 VM 虛擬主機啟用監控機制,預設情況下便會為 VM 虛擬主機啟用監控機制。
  • 診斷儲存體帳戶: 將 Azure VM 虛擬主機的診斷資料寫入至儲存體帳戶中,本文實作環境定義名稱為「eablobs2ddiag」。

圖 9、組態設定 Azure VM 虛擬主機選擇性功能

在建立 Azure VM 虛擬主機的最後步驟中,確認相關資訊無誤後便可以按下確定鈕,執行建立 Azure VM 虛擬主機的動作。

圖 10、建立 Azure VM 虛擬主機

當 Azure 公有雲環境的 VM 虛擬主機部署完成後,便可以準備將這台單機 VM 虛擬主機提升為 DC 網域控制站。值得注意的是,與「內部部署(On-Premise)」DC 網域控制站不同的地方,需要建立「額外」的資料磁碟來儲存 AD 資料庫、記錄檔及 SYSVOL。請在 Azure Portal 管理介面中,依序點選「S2D-DC > 設定 > 磁碟 > 連結新項目」,在連結新磁碟視窗中依序填入及點選填入下列資訊後按下建立鈕:

  • 名稱: 請鍵入 S2D-DC 虛擬主機新增的資料磁碟名稱,本文實作環境為「S2D-DC-Database-Disk」。
  • 類型: 因為此資料磁碟僅用於儲存 AD 資料庫、記錄檔及 SYSVOL,因此採用預設的「標準」類型即可。
  • 大小: 此資料磁碟儲存空間大小,本文實作環境為「10 GiB」。
  • 位置: 指定將此新增的資料磁碟,存放至先前所建立的「eablobs2ddiag」Blob 儲存體當中。
  • 主機快取: 由於儲存 AD 資料庫、記錄檔及 SYSVOL 等資料,並不適合使用主機快取機制因此請選擇至「無」。

圖 11、為 S2D-DC 新增資料磁碟以便存放 AD 資料庫、記錄檔及 SYSVOL

完成建立及掛載空的資料磁碟後,便可以將該資料磁碟進行「初始化(Initialize)」及「格式化(New Volume)」的動作。值得注意的是,存放 AD 資料庫、記錄檔及 SYSVOL 的分割區,檔案系統必須採用「NTFS」才行,並不支援採用新式的「ReFS」檔案系統。
預設情況下,Windows Server 2016 主機掛載的資料磁碟,將會採用新式的「ReFS」檔案系統進行分割區格式化的動作。

最後,預設情況下 Azure VM 虛擬主機會採用「動態」IP 位址,但這樣可能會影響 DC 網域控制站的運作,因此請為 S2D-DC 虛擬主機設定採用「靜態」IP 位址。請依序點選「S2D-DC > 設定 > 網路介面 > IP configurations > ipconfig1」,在 ipconfig1 視窗中請在指派區由預設的動態選擇至「靜態」,然後按下儲存圖示即可。

圖 12、為 S2D-DC 虛擬主機指派使用固定 IP 位址

之後便可以如同內部部署方式,將 S2D-DC 虛擬主機提升為 DC 網域控制站(本文實作網域名稱為 s2d.weithenn.org)。值得注意的是,在提升成為 DC 網域控制站的過程中,記得將 AD 資料庫、記錄檔及 SYSVOL 的分割區指向至剛才新增的資料磁碟(本文實作環境為 F 槽)。

圖 13、將 AD 資料庫、記錄檔及 SYSVOL 指向至新增的資料磁碟 F 槽

當 S2D-DC 成功擔任 DC 網域控制站後,記得以網域管理員身分登入 S2D-DC 主機,然後開啟 DNS 管理員將預設的 Forwarders 設定刪除。然後,回到 Azure Portal 頁面中,為 S2D 使用的 vNet 虛擬網路指定採用的 DNS 伺服器。在本文實作環境中,為「EA-vNet-S2D」虛擬網路指定的 DNS 伺服器為「S2D-DC(10.10.75.4)」。

圖 14、為 vNet 虛擬網路指定使用的 DNS 伺服器 IP 位址



建立 S2D-Node 成員伺服器

在本文實作環境中,我們建立「3 台」S2D-Node 成員伺服器,分別命名為「S2D-Node01、S2D-Node02、S2D-Node03」。由於建立 S2D-Node 虛擬主機的操作步驟,與剛才建立 S2D-DC 虛擬主機大致相同因此便不再贅述。唯一不同的部分是每台 S2D-Node 成員伺服器,屆時將會新增「3 顆」資料磁碟,因此在 VM 虛擬主機規模大小視窗中,選擇採用「DS2標準」的運作規模。

順利部署 3 台 S2D-Node 成員伺服器後,請幫每台 S2D-Node 主機新增「3 顆」資料磁碟,並且加入剛才所建立的「s2d.weithenn.org」網域環境。

圖 15、將 3 台 S2D-Node 成員主機加入 s2d.weithenn.org 網域環境



建立 S2D 容錯移轉叢集

請使用伺服器管理,為 3 台 S2D-Node 成員主機安裝「容錯移轉叢集」伺服器功能,或使用 PowerShell 指令一次幫 3 台主機進行安裝伺服器功能的動作。

圖 16、使用 PowerShell 指令,快速幫 3 台 S2D-Node 成員主機安裝容錯移轉叢集伺服器功能

接著,請開啟容錯移轉叢集管理員建立 S2D 容錯移轉叢集,或使用 PowerShell 指令快速建立 S2D 容錯移轉叢集。本文實作環境中,指定 S2D 容錯移轉叢集名稱為「S2D-Cluster」,而容錯移轉集的固定 IP 位址為「10.10.75.10」。

圖 17、使用 PowerShell 指令,建立 S2D 容錯移轉叢集

順利建立 S2D 容錯移轉叢集後,便可以開啟容錯移轉叢集管理員確認相關運作狀態是否正常,例如,叢集核心資源是否正確進行組態設定作業,並且運作狀態為「線上(Online)」。

圖 18、確認 S2D 容錯移轉叢集運作狀態正確無誤





啟用 Storage Spaces Direct 機制

在啟用 S2D(Storage Spaces Direct)機制之前,先確認是否可以看到加入 S2D 叢集中所有 S2D-Node 主機的磁碟數量。舉例來說,本文實作環境中每台 S2D-Node 叢集節點掛載 3 顆磁碟,因此應該看到總數「9 顆」磁碟才正確。請使用 PowerShell 指令「Get-PhysicalDisk」,確認 S2D 叢集中磁碟總數量。

圖 19、使用 PowerShell 指令確認 S2D 叢集中磁碟總數量

因為,此 S2D 軟體定義儲存運作環境為 Azure 公有雲的 VM 虛擬主機,所以磁碟的「媒體類型(MediaType)」判定為「UnSpecified」,因此在我們建立 S2D 機制時,執行的 PowerShell 指令「Enable-ClusterS2D」必須加上額外參數處理,例如,停用 S2D 的快取模式及略過自動組態設定機制。

圖 20、執行 PowerShell 指令 Enable-ClusterS2D 建立 S2D 軟體定義儲存環境

因為在剛才執行 Enable-ClusterS2D 指令時,我們略過自動組態設定機制,所以必須手動執行「New-StoragePool」指令,建立 S2D 的 Storage Pool 部分。也就是將 3 台 S2D-Node 共 9 顆磁碟串聯成 1 個大的儲存資源池。

圖 21、執行 PowerShell 指令建立 S2D Storage Pool

順利建立好 S2D Storage Pool 之後,我們就可以處理剛才磁碟 MediaType 的問題了。請執行 PowerShell 指令「Get-StorageSubsystem」,將剛才磁碟 MediaType 判斷為 UnSpecified 的部分,手動指定為「HDD」。

圖 22、手動指定磁碟的 MediaType 為 HDD



建立 vDisk 及 Volume

現在,我們可以放心在 S2D 叢集運作環境中,分別建立具備 2 份鏡像資料(2-Way Mirror),以及 3 份鏡像資料(3-Way Mirror)的 vDisk 及 Volume。在下列執行的 PowerShell 指令「New-Volume」中,我們將會分別建立名稱為「2Way-vDisk」以及「3Way-vDisk」的 S2D 叢集共用磁碟,同時這個 S2D Volume 將會採用最新的「ReFS」檔案系統。

圖 23、建立 2 份及 3 份鏡像資料的 vDisk 及 Volume

建立 2 份鏡像資料的 vDisk 倘若指派的空間為 10 GB,那麼實際佔用的儲存空間將為 20 GB,建立 3 份鏡像資料的 vDisk 則佔用的儲存空間為 30 GB。鏡像資料將由 S2D 機制的演算法進行管理,實際上使用以及看到的儲存空間仍為 10 GB

順利建立 2 份及 3 份鏡像資料的 vDisk 及 Volume 之後,在容錯移轉叢集管理員中當然也可以順利看到 Storage Disk 等相關資訊。

圖 24、透過容錯移轉叢集管理員管理介面,查看 S2D Storage Disk 資訊



建立 SOFS 檔案分享資源

最後,請為 3 台 S2D-Node 叢集節點主機安裝「檔案伺服器」角色,並且新增高可用性檔案伺服器角色,在本文實作環境中名稱為「S2D-SOFS」。接著,便可以新增 SOFS 檔案分享資源並且設定資料夾的存取權限,在本文實作環境中建立的分享資料夾名稱為「Share」,組態設定完畢後便可以開啟檔案總管,嘗試放入測試檔案至 S2D 所建立的 SOFS 分享資料夾。

圖 25、測試能否順利放入測試檔案至 S2D 所建立的 SOFS 分享資料夾





結語

透過本文的說明及實作演練,即使手邊沒有相關硬體資源可供利用的 IT 管理人員,也可以透過 Microsoft Azure 公有雲,輕鬆建立及測試微軟新一代 S2D 軟體定義儲存技術。