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

前言

簡單來說 OneNote 可以是個人或團隊內整理資料的萬用筆記本,個人在整理技術筆記上也是使用 OneNote,本文將整理幾個 OneNote 的好用之處有興趣的朋友不妨參考看看,有關 OneNote 的初步認識請參考導覽影片「什麼是 OneNote?」。



使用技巧整理





參考


前言

自從 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





參考資源


前言

自從 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…等。




參考資源


網管人雜誌

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





文章目錄

前言
在 Hyper-V 虛擬化平台上運作 Unix-Like
什麼是 Hyper-V 整合服務?
Unix-Like虛擬主機整合服務
          CentOS 虛擬主機安裝整合服務
          FreeBSD 虛擬主機安裝整合服務
結語





前言

談到微軟作業系統,某些 IT 人員便認為在作業系統的部分一定是只有 Windows。雖然,Windows 偶爾有推出與開放源始碼整合的相關服務,但使用者通常仍覺得整合程度有限,但是這樣的狀況自從微軟 CEO Satya Nadella 上任並喊出 Microsoft Love Linux 之後便一一被打破,甚至最新推出的 Windows Server 2016 作業系統,還能夠原生執行 Container 容器技術。

同時,不光是地面上企業及組織的相關技術支援 Linux,就連微軟公有雲 Azure 也支援 Linux 作業系統的 VM 虛擬主機及相關服務,根據微軟的內部統計目前在 Azure 公有雲的 VM 虛擬主機工作負載當中,有 1/3 是運作 Linux 作業系統另外 2/3 才是運作 Windows 作業系統。

同時在 2016 年 3 月,微軟已經釋出 SQL Server on Linux 的封閉預覽測試版本,並宣佈預定於2017 年 Q2 將正式推出。屆時,在 Linux 作業系統中也可以安裝 Microsoft ODBC Driver for SQL Server,以便 Linux 作業系統能夠順利存取 SQL Server 資料庫服務。

圖 1、SQL Server on Linux 的封閉預覽測試版本

2016 年 4 月,微軟在 Build 開發者大會上正式宣佈,從 Windows 10(Build 14316)作業系統版本開始,將在 Windows 作業系統核心中加入子系統(Windows Subsystem for Linux),以便在 Windows 作業系統中能夠原生支援 Linux 使用者模式,這與舊有透過 Cygwin 模擬的方式完全不同。現在,你可以直接在 Windows 作業系統中原生執行 Ubuntu Bash、apt-get、git……等。

圖 2、運作 Ubuntu 原生 Bash 指令碼環境在 Windows 作業系統中

2016 年 8 月,微軟也宣佈自家的 PowerShell 指令碼工具正式 Open Sourced。現在,可以在多種 Linux 作業系統(例如,Ubuntu 14.04、Ubuntu 16.04、CentOS 7、OS X 10.11……等)中,直接透過 GitHub 下載安裝後運作 PowerShell 指令碼環境。

圖 3、在 CentOS 作業系統中運作 PowerShell 指令碼環境





在 Hyper-V 虛擬化平台上運作 Unix-Like

在 Hyper-V 虛擬化平台上運作 VM 虛擬主機,倘若客體作業系統採用 Windows 時相信 IT 管理人員應該不陌生,舉例來說,在 Windows Server 的部分支援 SBS 2011、2008 SP2、2008 R2、2012、2012 R2 以及最新版本的 Window Server 2016,至於 Desktop 的部分則支援 Vista SP2、7 SP1、8.1 及最新版本的 Windows 10。

那麼,倘若在 Hyper-V 虛擬化平台中要運作 Unix-Like 作業系統(例如,Linux 及 FreeBSD)時,哪些 Unix-Like 版本才有支援?倘若採用不支援的 Unix-Like 作業系統時是否無法運作在 Hyper-V 虛擬化平台上?Hyper-V 虛擬化平台能否運作 Unix(例如,AIX、HP-UX)或者是 Max OS X?

簡單歸納來說,Hyper-V 虛擬化平台無法運作 Unix 及 Max OS X。同時,當採用未支援的 Unix-Like 作業系統版本時,將會因為無法安裝「整合服務」(Integration Service),除了導致運作於 VM 虛擬主機當中的 Unix-Like 作業系統,無法針對相關虛擬硬體裝置安裝驅動程式與 Hyper-V 虛擬化平台進階功能整合之外,也將會影響 VM 虛擬主機的運作效能。

圖 4、Hyper-V 虛擬化平台是否能運作 Unix 及 Unix-Like 作業系統判斷流程示意圖





什麼是 Hyper-V 整合服務?

事實上,不管採用哪一種虛擬化平台都會需要幫其上運作的 VM 虛擬主機安裝適當的 Tools,以使其上運作的 VM 虛擬主機能夠與虛擬化平台進行最緊密的結合(例如,虛擬裝置驅動程式最佳化……等),舉例來說,倘若採用 VMware vSphere 虛擬化平台便需要幫 VM 虛擬主機安裝 VMware Tools,而 Citrix XenServer 虛擬化平台便需要幫 VM 虛擬主機安裝 Xen Tools。

在 Microsoft Hyper-V 虛擬化平台上,則是需要幫其上運作的 VM 虛擬主機安裝「整合服務」(Integration Services),安裝整合服務完畢後在驅動程式部份將會針對 IDE、SCSI、網路 、視訊 、滑鼠 …… 等方面進行最佳化,而在客體服務方面則會整合作業系統關閉(Shutdown)、時間同步化(Time Synchronization)、資料交換(Key/Value Exchange)、活動訊號(Heartbeat)、線上備份(Volume Shadow copy Service,VSS)……等機制,以期 VM 虛擬主機與 Microsoft Hyper-V 虛擬化平台不管是在效能運作上,或者是虛擬裝置驅動程式最佳化方面都能進行完美的結合。

圖 5、Hyper-V運作元件架構示意圖





Unix-Like 虛擬主機整合服務

倘若,您的 VM 虛擬主機安裝「Windows作業系統」的話,那麼在VM虛擬主機的Console視窗中可以直接執行插入整合服務安裝光碟的動作。當安裝「Linux 作業系統」如 RHEL / CentOS 時,Hyper-V 虛擬化平台雖然也支援「Emulated / Specific」2 種虛擬裝置,但是若需要發揮 Linux 作業系統最佳效能,建議您使用 Hyper-V Specific Devices 並配合安裝「LIS(Linux Integration Services)」,也就是專供 Linux 使用的整合服務映像檔並進行安裝才能達到效能最佳化。

專供 Linux 作業系統使用的 LIS 整合服務映像檔,目前最新版本為 4.1 您可至 Microsoft Download Center 下載「Linux Integration Services Version 4.1 for Hyper-V」,所下載整合服務映像檔名稱為「LinuxIC-4.1.2-2.iso」。

圖 6、下載專供 Linux 作業系統使用的 LIS 整合服務映像檔

LIS 4.1 for Hyper-V 整合服務,支援的 Linux 版本以 RHEL / CentOS 為例的話是 5.2 ~ 5.11、6.0 ~ 6.8、7.0 ~ 7.2,並且可以應用在多種Hyper-V虛擬化平台版本上,例如,Hyper-V 2.0(Windows Server 2008 R2)、Hyper-V 3.0(Windows 8 / 8.1 Pro、Windows Server 2012 / 2012 R2)以及最新的 Windows 10 和 Windows Server 2016。

最新的 LIS 4.1 版本中,除了原有整合服務的特色功能之外還支援下列 5 項新增功能:
  • Hyper-V Sockets。
  • 記憶體熱新增及移除。
  • SCSI WWN。
  • lsvmbus 指令。
  • 反安裝 LIS 整合服務指令碼。

安裝整合服務後的Linux虛擬主機,將具備核心(Core)、網路(Networking)、儲存(Storage)、記憶體(Memory)、視訊(Video)、其它(Miscellaneous)……等特色功能或最佳化效能:

核心(Core)

  • 整合式關機: 透過此功能,在開啟的VM Console視窗中便能為客體作業系統執行關機的動作,而無須登入至客體作業系統手動進行關機。
  • 時間同步處理: 確保VM虛擬主機能夠與Hyper-V主機保持時間同步。
  • 準確時間: 整合 Windows Server 2016 準確時間功能,改善主應用程式與時間同步處理的精確度,能夠將時間誤差值縮短在 1 毫秒的範圍內。
  • 多處理器支援: 支援組態配置 VM 虛擬主機多顆 vCPU 虛擬處理器,達到真正使用 Hyper-V主機多顆 CPU 處理器進行 SMP 平行運算。
  • 活動訊號: 以便 Hyper-V 虛擬化平台能夠偵測及追蹤 VM 虛擬主機運作狀態。
  • 整合式滑鼠支援: 滑鼠功能將可正常運作於 VM 虛擬主機的 Console 視窗中,以及自動在Hyper-V 虛擬化平台中正常切換。
  • Hyper-V 特定儲存裝置: 使 VM 虛擬主機擁有高效能及最佳化的 IDE/SCSI 儲存介面卡,有效提升工作負載能力。
  • Hyper-V 特定網路裝置: 使 VM 虛擬主機擁有高效能及最佳化的 Network Controller 介面卡,有效提升工作負載能力。

網路(Networking)

  • Jumbo Frame: 可設定 MTU 數值大於 1500 bytes 以增加網路效能。
  • VLAN Tagging 及 Trunking: 支援單一 VLAN ID 或多個 VLAN ID Trunking 網路環境。
  • 即時遷移: 讓 VM 虛擬主機支援即時遷移(Live Migration)、無共用儲存即時遷移(Shared Nothing Live Migration)、Hyper-V複本(Hyper-V Replica)…… 等進階功能。
  • 靜態 IP 導入: 當 Hyper-V 主機執行複本容錯移轉之後,因為已經複寫 VM 虛擬主機靜態 IP 位址,所以能夠確保網路工作負載能在發生容錯移轉事件後無縫繼續運作。
  • vRSS 虛擬接收端調整: 將 VM 虛擬主機虛擬網路卡的工作負載,平均分散到 VM 虛擬主機中的多個 vCPU 虛擬處理器。
  • TCP 分割和總和檢查碼卸載: 在傳輸網路數據時,從 VM 虛擬主機的 vCPU 虛擬處理器到 Hyper-V 主機的 vSwitch 虛擬網路交換器之間,進行資料分割及總和檢查碼的動作。
  • LRO 大型接收卸載: 透過將多個封包彙總為更大的緩衝區,以便提升高網路頻寬流入的傳輸量,進而降低 CPU 運算資源的開銷。

儲存(Storage)

  • VHDX 調整大小: 系統管理員可以隨時因應需求,線上調整 VM 虛擬主機的 VHDX 磁碟空間。
  • vHBA 虛擬光纖通道: 讓 VM 虛擬主機能夠感知原生光纖通道裝置,進而支援及使用虛擬光纖通道功能。
  • VM 虛擬主機即時備份: 讓 VM 虛擬主機能夠在運作中的情況下進行備份作業。
  • TRIM: 當應用程式不再需要磁碟空間時,協助執行磁碟空間回收的動作。
  • SCSI WWN: Storvsc 驅動程式將會擷取連接埠和連接至 VM 虛擬主機的全球名稱(WWN),以便建立適當的 sysfs 檔案。

記憶體(Memory)

  • PAE 核心支援: 在 Linux 作業系統中透過 PAE 技術,可以讓 32 位元核心存取超過 4 GB 的記憶體位址空間。舉例來說,舊版的 RHEL 5.x 必須個別在核心中啟用 PAE 功能,而較新版的 RHEL 6.x 則核心已經預先啟用 PAE 功能。
  • MMIO: 協助 JeOS(Just Enough Operating Systems)與 Hyper-V 主機實體記憶體區塊進行對應的動作。
  • 記憶體熱新增及移除: 提供 VM 虛擬主機在運作狀態中,線上動態增加及移除記憶體空間的機制。
  • Ballooning: 活化 Hyper-V 主機記憶體空間,以便渡過記憶體空間暫時不足的因應機制。

視訊(Video)

  • 特定視訊裝置: 提供 VM 虛擬主機高效能及高解析的視訊介面卡,但是此裝置並不提供增強的工作階段模式及 RemoteFX 功能。

其它(Miscellaneous)

  • KVP(Key-Value Pair)Exchange: 取得 VM 虛擬主機在資料方面讀取(Read)/ 寫入(Write)等資訊。
  • NMI 非遮罩式插斷: 協助 VM 虛擬主機當中的客體作業系統,因為應用程式漏洞而發生的崩潰情況,再主機重新啟動後有機會分析導致系統發生崩潰的原因。
  • 客體與主機進行檔案複製: 透過客體服務讓 VM 虛擬主機與 Hyper-V 主機之間,在進行檔案複製作業時無須透過網路介面卡進行傳輸。
  • lsvmbus 指令: 透過此指令可以獲得 Vmbus 的相關資訊。
  • Hyper-V Sockets: 透過載入 Hyper-V Sockets 核心模組,讓 VM 虛擬主機與 Hyper-V 主機之間建立專屬的通訊通道。
  • PCI Passthrough: 將安裝於 Windows Server 2016 主機上的 PCI Express 裝置,例如,網路介面卡、GPU 顯示卡……等,以直接傳遞的方式指派給 VM 虛擬主機使用。

那麼在 Hyper-V 虛擬化平台上所運作的 Linux 作業系統,哪種發行套件及版本分別支援上述說明的功能呢,舉例來說,採用新版 CentOS 7.0 雖然核心中已經支援 Hyper-V 裝置最佳化,但是仍無法使用 vRSS 功能,必須要採用更新的 CentOS 7.1 或 7.2 版本才支援,在 Ubuntu Server 也是一樣的情況,你會發現 Ubuntu 12.04 並不支援 vRSS 功能,必須使用新版本的 Ubuntu 14.04、16.04 或 16.10 才支援。

為了避免不必要的篇幅,在此便不將 Hyper-V 虛擬化平台所支援 Linux 發行套件及版本其所對應的功能逐一說明,有興趣的讀者不妨直接瀏覽 Microsoft 官方網站查詢及核對所支援的特色功能項目:
圖 7、RHEL / CentOS 版本及特色功能對應表



CentOS 虛擬主機安裝整合服務

當管理人員為 VM 虛擬主機,安裝舊版 RHEL / CentOS「5.2 ~ 5.8、6.0 ~ 6.3(32 或 64 位元)」時,那麼必須要為 RHEL/CentOS 客體作業系統安裝「Linux Integration Services Version 4.1 for Hyper-V」整合服務。

其它較新版本 RHEL / CentOS「5.9 ~ 5.11、6.4 ~ 6.8、7.0 ~ 7.2(32 或 64 位元)」,因為官方已經直接在該版本的 Linux 核心當中,直接內嵌 Hyper-V 相關虛擬裝置驅動程式。

因此,當 VM 虛擬主機安裝這些新版本的 RHEL/CentOS 客體作業系統版本後,其實可以無須再額外安裝 LIS 4.1 整合服務。除非,你希望使用 LIS 4.1 整合服務所提供的新增功能,例如,在預設情況下 CentOS 7.2 版本內建的整合服務,並未支援 SCSI WWN、lsvmbus 指令、Hyper-V Sockets 等功能。

那麼,當我們為 VM 虛擬主機安裝新版 CentOS 7.2 客體作業系統後,登入 CentOS 客體作業系統鍵入相關指令「uname -a、cat /etc/redhat-release、cat /var/log/dmesg | grep Vmbus」,便可以看到目前採用的 Linux 核心版本為「3.10.0-327.e17.x86_64」,採用的 CentOS 版本為「7.2.1511」,至於 Hyper-V 整合服務所使用的 hv_vmbus 版本則為「3.0」

圖 8、CentOS 7.2 客體作業系統版本資訊,以及內建的 Hyper-V LIS 整合服務資訊

接著,我們從 Hyper-V 虛擬化平台方面,透過 Hyper-V 管理員來驗證此台 VM 虛擬主機是否真的已經支援整合服務了。首先,點選安裝 CentOS 7.2 的 VM 虛擬主機後,在下方 Hyper-V 管理員「摘要」頁籤中,可以看到活動訊號欄位的顯示結果為「良好(無應用程式資料)」,表示 Hyper-V 虛擬化平台可以正確偵測到VM虛擬主機運作狀態。

切換到「記憶體」頁籤後,您可以看到記憶體需求及記憶體狀態欄位為「1036 MB、確定」,表示 Hyper-V 虛擬化平台的動態記憶體功能,與目前 CentOS 客體作業系統已經順利協同運作了。
請注意! 倘若採用舊版 Windows Server 2012 虛擬化平台版本的話,則「尚未」支援 Linux 作業系統動態記憶體功能,必須採用 Windows Server 2012 R2 或新版 Windows Server 2016 虛擬化平台版本,才正式支援動態記憶體功能。

切換到「網路功能」頁籤中,你會看到在狀態欄位的部分顯示結果為「良好(VMQ 作用中)」,表示 CentOS 客體作業系統已經採用內建的整合服務,為 VM 虛擬主機所指派使用的虛擬網路介面卡,安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。

圖 9、新版 CentOS 7.2 已經內建 LIS 整合服務

倘若,你希望測試新版 LIS 4.1 整合服務中 lsvmbus 指令及 Hyper-V Sockets 功能的話,那麼便需要為 CentOS 7.2 安裝 LIS 4.1 整合服務。請為 VM 虛擬主機掛載剛才下載的 Linux Integration Services Version 4.1 for Hyper-V 整合服務映像檔 LinuxIC-4.1.2-2.iso,準備為 CentOS 7.2 作業系統安裝整合服務。

圖 10、為 VM 虛擬主機掛載 LIS 整合服務映像檔

順利掛載 LIS 整合服務映像檔之後,回到 CentOS 7.2 虛擬主機 Console 畫面,請依序鍵入指令「mount /dev/cdrom /media、cd /media/CentOS72、./install.sh」,執行掛載光碟機資源、切換到適合安裝的整合服務 CentOS 版本路徑、安裝整合服務等動作。

圖 11、為 CentOS 7.2 安裝新版 LIS 4.1 整合服務

當新版 LIS 4.1 整合服務安裝完畢後,請將 CentOS 7.2 客體作業系統重新啟動並卸載 LIS 整合服務映像檔。當 CentOS 7.2 客體作業系統重新啟動完畢後,便可以透過「/sbin/modinfo hv_vmbus」指令查看 hv_vmbus 版本,可以從指令執行結果中看到已經採用最新「4.1.2-2」版本。此外,如同剛才所說明的我們可以使用新版 LIS 4.1 整合服務中的「lsvmbus」指令,來查看相關虛擬裝置的 Vmbus ID 資訊。

圖 12、確認 CentOS 客體作業系統,是否採用最新的 hv_vmbs 4.1.2-2 版本
目前有個已知問題值得注意,倘若安裝 CentOS 客體作業系統的 VM 虛擬主機有啟用「安全開機」功能的話,那麼在安裝新版 LIS 4.1 整合服務後必須將安全開機功能「停用」,否則將會發現 CentOS 客體作業系統無法正常啟動或啟動後直接進入安全模式。



FreeBSD 虛擬主機安裝整合服務

雖然,FreeBSD 也是 Unix-Like 作業系統,但是 FreeBSD 的系統核心與 Linux 完全不同。同樣的,微軟官方也採用與 LIS 整合服務同樣的方式,讓運作於 Hyper-V 虛擬化平台中的 FreeBSD 虛擬主機,能夠支援及使用 Hyper-V Specific Devices 高效能虛擬裝置機制,此機制稱之為「BIS(BSD Integration Services)」

圖 13、微軟開發人員協同 FreeBSD 團隊開發 BIS 整合服務,讓系統核心支援 Hyper-V 虛擬化平台

倘若運作舊版 FreeBSD 8.4、9.1 ~ 9.3 的話,必須透過 FreeBSD Ports 套件管理機制,安裝「/head/emulators/hyperv-is」套件即可。在 2012 年 5 月 10 日時,Microsoft TechNet Blog發表一篇 FreeBSD Support on Windows Server Hyper-V 文章,內容便說明 Microsoft 以及合作夥伴 NetApp、Citrix 將在 BSDCan 2012 大會上,正式發表 FreeBSD 核心支援 Hyper-V 虛擬裝置驅動程式。

因此,倘若採用的是 FreeBSD 10.x 或最新版本的 FreeBSD 11,因為在 FreeBSD 核心中已經支援 BIS 整合服務,所以便無須再透過 FreeBSD Ports 套件管理機制進行安裝作業。
請注意,目前 Hyper-V 虛擬化平台中的 FreeBSD,仍無法採用「第二世代」格式的 VM 虛擬主機,同時 BIS 整合服務功能性的部分與 LIS 整合服務相較之下較少,舉例來說,動態記憶體功能尚未完全支援運作。

同樣的,在建立第一世代格式的 VM 虛擬主機並安裝最新版本 FreeBSD 11 之後,我們可以切換到 Hyper-V 管理員視窗中,確認 FreeBSD 虛擬主機的 BIS 整合服務是否順利運作。首先,切換到「摘要」頁籤中,可以看到活動訊號欄位的顯示結果為「良好(無應用程式資料)」,表示Hyper-V虛擬化平台可以正確偵測到VM虛擬主機運作狀態。

切換到「記憶體」頁籤中,您可以看到記憶體需求及記憶體狀態欄位為「空白」,這是因為BIS 整合服務機制尚未支援 Hyper-V 虛擬化平台的動態記憶體功能所致。切換到「網路功能」頁籤中,你會看到在狀態欄位的部分顯示結果為「良好(VMQ 作用中)」,表示 FreeBSD 客體作業系統已經透過 BIS 整合服務,為 VM 虛擬主機所指派使用的虛擬網路介面卡,安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。

圖 14、新版 FreeBSD 11 已經內建 BIS 整合服務

順利登入 FreeBSD 11 系統後,可以發現系統已經順利辨識到網路介面卡(代號為 hn0),查看系統開機訊息可知 hn0 網路卡為「Hyper-V Network Interface」,也就是已經採用最佳化效能的 Hyper-V Specific Network Adapter,接著鍵入指令「ls /boot/kernel | grep hv」查看 FreeBSD 模組存放資料夾內容可知,協同 Hyper-V 虛擬化平台運作的相關模組檔案也已經存在。
倘若,VM 虛擬主機組態配置傳統網路介面卡時,將網路介面卡代號將為「de0」並模擬「Digital 21140A Fast Ethernet 100 Mbps」網路卡。
圖 15、順利辨識並載入 Hyper-V Specific Network 網路介面卡及相關模組

鍵入指令「dmesg | grep vmbus0」查詢 FreeBSD 開機訊息內容,你會看到 FreeBSD 透過內建的 BIS 整合服務,已經順利載入 Hyper-V 虛擬化平台協同運作的相關服務,例如,Heartbeat、KVP、Shutdown、Time Synch……等服務。

圖 16、FreeBSD 透過內建的 BIS 整合服務載入 Hyper-V 相關客體服務





結語

透過本文的說明及實作演練,當企業及組織的 IT 管理人員需要在 Hyper-V 虛擬化平台上運作 Unix-Like 作業系統時,便能夠正確為 Unix-Like 作業系統採用 LIS / BIS 整合服務,以便確保運作於 Hyper-V 虛擬化平台上的 Unix-Like 作業系統,能夠擁有最佳的工作負載及最大化的運作效能。

前言

在 Hyper-V 虛擬化化平台舊版本中,要實作出 Nested Virtualization 環境非常困難。現在,Windows Server 2016 直接內建支援「Nested Virtualization in Windows Server Hyper-V」機制,往後 IT 管理人員建置 Lab 環境將更方便了。

簡單來說,在舊版的 Hyper-V 虛擬化平台當中僅支援 Level 0、Level 1 這樣的運作架構。



現在,可以在 Hyper-V Hypervisor (Level 1) 當中,再產生出一層 Guest Hypervisor (Level 2並且能夠運作 Guest OS,甚至 Level 2 的 VM 虛擬主機還能再次產生出一層 Guest Hypervisor (Level 3) 並運作 Guest OS。



下列為目前 Hyper-V Nested Virtualization 的環境需求及相關限制:
  • 實體主機 CPU 必須支援 Intel VT-x EPT 硬體輔助虛擬化技術,作業系統必須採用 Windows 10 年度更新版 (Enterprise, Professional, Education) 或 Windows Server 2016 (Standard, Datacenter)。
  • 必須為擔任 Guest Hypervisor 的 VM 虛擬主機啟用 vCPU Virtualization Extensions 功能。
  • 必須為擔任 Guest Hypervisor 啟用 MAC Address Spoofing 功能,否則屆時建立的 Guest OS 網路連線會發生不通的情況。
  • 必須為擔任 Guest Hypervisor 採用第 2 世代及 8.0 版本格式的 VM 虛擬主機。
  • 必須要停用 VM 動態記憶體功能,同時為 VM 虛擬主機執行 Runtime Memory Resize 的動作時會失敗。



實作 Hyper-V Nested Virtualization

首先,我們可以看到在 Level 1Hyper-V Host 中,所建立的 VM 虛擬主機採用 Coreinfo 檢查後可以發現,目前的 VM 虛擬主機「尚未感知」到母體的虛擬化功能。同時,當你嘗試為 VM 虛擬主機 (準備擔任 Guest Hypervisor) 安裝 Hyper-V 伺服器角色時,將會發現無法順利安裝。



請在 Level 1 的 Hyper-V Host 中,執行下列指令將 Hyper-V Host 的硬體輔助虛擬化技術「傳遞」給 VM 虛擬主機 (此實作該 VM 的名稱為 WS2016-Nested,當然前提是 Hyper-V Host 支援 Intel VT-x / EPT 硬體輔助虛擬化技術)。但是,請先將準備擔任 Guest Hypervisor 的 VM 虛擬主機關機,倘若 VM 虛擬主機未關機的話,稍後執行 vCPU Virtualization Extensions 的動作時,將會發生 PowerShell 指令執行失敗的情況。



順利將擔任 Guest Hypervisor 的 VM 虛擬主機關機後,便可以執行 PowerShell 指令「Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true」,為 Guest Hypervisor 的 VM 虛擬主機 (此實作中名稱為 WS2016-Nested)啟用「vCPU Virtualization Extenstions」的功能。




此時,重新將擔任 Guest Hypervisor 的 VM 虛擬主機 (WS2016-Nested) 開機後,再度使用 Coreinfo 檢查後可以發現,目前已經可以「感知」到 Hyper-V Host 所傳遞過來的硬體輔助虛擬化技術。當然,也就可以順利安裝 Hyper-V 伺服器角色了。



至此,我們完成為 Level 1 的 VM 虛擬主機啟用 Guest Hypervisor 功能。記得,啟用 MAC Address Spoofing 功能,否則屆時建立的 Guest OS 網路連線會發生不通的情況。


下列為 Hyper-V Nested Virtualization 巢狀虛擬化實作階層說明:
     Level 1 (實體伺服器、Hyper-V Hypervisor、Guardhost01)
          Level 2 (Guest Hypervisor、WS2016-Nested)
               Level 3 (Guest OS、WS2016)



同樣的組態設定方式,我們可以為 Level 3 的 VM 虛擬主機啟用 Guest Hypervisor 功能,建立出 Level 4 的 VM 虛擬。

下列為 Hyper-V Nested Virtualization 巢狀虛擬化實作階層說明:
     Level 1 (實體伺服器、Hyper-V Hypervisor、Guardhost01)
          Level 2 (Guest Hypervisor、WS2016-Nested)
               Level 3 (Guest Hypervisor、WS2016)
                    Level 4 (Guest OS、WS2016-Inner)






參考資源



網管人雜誌

本文刊載於 網管人雜誌第 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 軟體定義儲存技術。