網管人雜誌
本文刊載於 網管人雜誌第 193 期 - 2022 年 2 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言
在微軟 Ignite 2021 秋季大會上，總共發佈 90 多項新服務和功能更新，包含針對元宇宙（Metaverse）、人工智慧（Artificial Intelligence，AI）、數位分身（Digital Twins）、超級連結（Hyperconnectivity）……等關鍵趨勢（如圖 1 所示），其中也包括最新一代的 Windows Server 2022 雲端作業系統的正式發佈。
圖 1、透過虛擬人物幫助大家在數位環境中相聚的元宇宙概念
Windows Server 2022 亮眼特色功能
SMB Direct 加密傳輸
在過去的 Windows Server 版本中，雖然支援 RDMA 網路介面卡啟用 SMB 簽署和 SMB 加密機制，然而此舉卻會造成 RDMA 資料放置原則停用，簡單來說將會影響 RDMA 資料讀寫效能，進而影響 S2D 和其它整合 RDMA 機制的運作效能。
現在，全新的 Windows Server 2022 版本，透過新增 AES-128 和 AES-256 密碼編譯套件，針對 SMB 3.1.1 的網路封包進行加密（如圖 2 所示），確保提供最佳的安全性之外，同時不影響 RDMA 資料放置原則，所以並不會因為啟用加密機制而影響到運作效能。
圖 2、透過 SMB 加密機制保護 SMB 網路封包示意圖
SMB over QUIC
傳統的 SMB 網路流量，在企業或組織的地端資料中心內，可以提供穩定可靠且高效能的網路傳輸。然而，在現今混合雲逐漸成為主流應用的時代，傳統 SMB TCP Port 445 網路流量在網際網路上，則是會被大多數的 ISP 網路服務供應商設備所阻擋，倘若企業透過 VPN 建立加密通道後再使用 SMB 進行傳輸，雖然達到網路流量高安全性的需求，卻又會無法兼顧到 SMB 網路傳輸效能。
因此，全新推出的 SMB over QUIC 特色功能，能夠有效解決傳統 SMB 通訊協定，無法在網際網路上全面發揮的痛點。簡單來說，SMB over QUIC 機制讓 SMB 網路流量，採用 IETF 標準化的 QUIC 通訊協定，而非傳統的 TCP 通訊協定，同時搭配「UDP Port 443」來建立 TLS 1.3 加密通道（如圖 3 所示），確保所有傳送的網路封包一律加密，所以無須額外建立 VPN 加密通道，並且能夠順利通過 ISP 網路服務供應商的網路設備且不被阻擋。
圖 3、QUIC 通訊協定網路封包 Handshake 運作流程示意圖
值得注意的是，SMB over QUIC 特色功能，在目前的 Windows Server 2022 Standard 或 Datacenter 版本並未支援，必須採用「Windows Server 2022 Datacenter : Azure Edition」版本（如圖 4 所示），才能支援此項特色功能。
圖 4、Windows Server 2022 版本功能比較表
SMB 壓縮機制再增強
事實上，「SMB 壓縮」（SMB Compress） 機制，在過去的 Windows Server 版本中便已經支援。但是，最早僅用於 Hyper-V 虛擬化平台中，執行 VM 虛擬主機線上即時遷移時，傳輸 VM 虛擬主機的記憶體分頁狀態時使用，也就是「Hyper-V Live Migration with SMB Compression」機制（如圖 5 所示），啟用後可以讓 VM 虛擬主機線上即時遷移的時間有效縮短。
圖 5、Hyper-V Live Migration with SMB Compression 組態設定
雖然，SMB 壓縮機制，早已經是 Windows 10 和 SMB 2 通訊協定規範的一部份，但是並未積極整合其它服務。因此，一開始只有整合 Hyper-V Live Migration 線上遷移機制，後來則是整合 IT 人員常用的檔案複製工具 Robocopy 和 Xcopy 。
透過 SMB 壓縮機制，系統將在檔案傳輸時自動化處理空白區塊進行壓縮，例如，VM 虛擬主機磁碟、圖形檔案、科學數據……等。如圖 6 所示，可以看到未啟用和啟用 SMB 壓縮機制後，在檔案傳輸上將會有明顯的效能改進。
圖 6、未啟用和啟用 SMB 壓縮機制後傳輸效能比較表
更新後無須重新啟動的 Hotpatch 技術
在過去的 Windows Server 版本中，安裝相關安全性更新後，通常必須要重新啟動 Windows Server，以便安全性更新或相關修正能夠套用生效。雖然，企業和組織的管理人員已經習慣此維運節奏，然而有些即時性的安全性更新，管理人員可能因為營運服務暫時無法中斷，而延後安裝安全性更新，間接造成營運服務暴露在資安風險當中。
透過最新的「熱修補」（Hotpatch）技術（如圖 7 所示），在安裝安全性更新時，將會直接針對 Windows Server 內，執行中的系統程序進行記憶體內部程式碼修正的動作，不僅營運服務中系統程序可持續運作，並且修正完畢後 Windows Server 也無須重新啟動，達成安全性更新和修補的目的。
圖 7、Hotpatch 技術運作架構示意圖
在 Microsoft IT Ops Talk 技術社群，和 Windows Server Summit 2021 大會中，實際展示針對傳統 Windows Server，以及支援 Hotpatch 技術的 Windows Server，執行大量檔案複製作業，同時進行安全性更新的修補作業，從展示中可以看到，支援 Hotpatch 技術的 Windows Server，除了不影響運作中的檔案複製作業之外，在展示開始「32 秒」時便完成安全性更新的套用，而傳統的 Windows Server 在安裝安全性更新的過程中，除了影響到檔案複製作業時間之外，更延長安裝安全性更新的整體時間，該測試中傳統 Windows Server 除了花費「8 分 20 秒」，才順利完成安裝安全性更新的動作，最後仍須重新啟動主機才能完成安全性更新套用生效的目的（如圖 8 所示）。
圖 8、實際展示傳統和支援 Hotpatch 技術的 Windows Server 安裝安全性更新流程
值得注意的是，Hotpatch 特色功能，在目前的 Windows Server 2022 Standard 或 Datacenter 版本並未支援，必須採用「Windows Server 2022 Datacenter : Azure Edition」版本（如圖 9 所示），才能支援此項特色功能。
圖 9、Windows Server 2022 版本功能比較表
巢狀式虛擬化技術正式支援 AMD 處理器
事實上，在 Windows 10 和 Windows Server 2016 版本中，只要採用的 Intel 處理器支援「VT-x 和 EPT」硬體輔助虛擬化技術，那麼便可以在 Hyper-V 虛擬化平台中，建立「巢狀式虛擬化」（Nested Virtualization）環境（如圖 10 所示），除了方便管理人員更容易建構複雜的測試環境之外，也讓容器執行個體環境，搭配巢狀式虛擬化技術，實作出隔離性更佳更安全的「Hyper-V 容器」（Hyper-V Container）運作環境。
圖 10、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖
隨著 AMD 處理器的重新崛起，企業和組織也逐漸將採用 AMD 處理器的伺服器，導入至地端資料中心內，甚至從過去僅用於測試和研發用途，也慢慢提升為負責二線服務或部份營運服務。因此，在最新的 Windows 11 和 Windows Server 2022 版本中，正式支援採用虛擬化技術的 AMD EPYC/Ryzen 處理器，也能夠建立 Hyper-V 巢狀式虛擬化環境（如圖 11 所示）。
圖 11、AMD 處理器建構 Hyper-V 巢狀式虛擬化環境
Microsoft Edge 瀏覽器
雖然，相較於 Windows Desktop 來說，在 Windows Server 運作環境中較少使用瀏覽器，然而需要使用到時在 Windows Server 環境中，卻一直都是採用年代已久且效能和支援度不佳的 IE 瀏覽器。因此，在新版 Windows Server 2022 雲端作業系統中，正式將內建的瀏覽器更改為新式的 Edge 瀏覽器，對於採用 WAC（Windows Admin Center）管理伺服器的人員來說，也同時增加管理上的方便度，當然管理人員也可以隨時把內建的 Edge 瀏覽器移除，並採用其它供應商的瀏覽器。
TCP/UDP 傳輸效能再增強
在 Windows Server 2022 雲端作業系統中，針對 TCP 和 UDP 網路通訊協定，有超過數百項資料路徑的功能改進。舉例來說，在 RTP 和 UDP 串流及遊戲通訊協定日益普及之下，以 UDP 為基礎的 QUIC 通訊協定，可將 UDP 效能和穩定度提升至和 TCP 通訊協定相同層級。
此外，Windows Server 2022 預設情況下，便會啟用「UDP 分割卸載」（UDP Segmentation Offload，USO）機制，讓硬體網路介面卡能夠大量處理 UDP 網路封包，而無須損耗 Windows Server 2022 的 CPU 運算資源，讓 Windows Server 2022 能有更多運算資源承載營運服務。
在 TCP 通訊協定部份，Windows Server 2022 預設網路堆疊，便會使用新式的 TCP HyStart++ 機制，以便減少連線啟動期間封包遺失的情況，進而降低「重新傳輸超時」（Retransmit TimeOuts，RTO），這對於高速網路日漸普及的資料中心來說，能夠提供更好更穩定的網路資料流和更多的網路頻寬。
在微軟和 Dropbox 的合作中，針對 WAN 傳輸效能的測試結果顯示，新的 TCP 通訊協定網路吞吐量提升了「10 倍」以上。
此外，微軟也針對最新 Windows Server 2022，和過去的 Windows Server 版本進行比較。如圖 12 所示，可以看到在「128 MB」和「200 ms RTT」的網路環境中，採用新式網路堆疊機制的 Windows Server 2022，在網路吞吐量方面增加超過「40 倍」以上，在其它網路情境測試中也至少提升「5 倍」的網路吞吐量。
圖 12、採用新網路堆疊機制的 Windows Server 2022 網路吞吐量大幅增加
獨立伺服器啟用 SBC 快取機制
在舊版的 Windows Server 運作環境中，「獨立伺服器」（Standalone Server）並無法使用 Storage Spaces Direct 相關技術，必須整合多台 Windows Server 並建構容錯移轉叢集後才能使用。
現在，最新的 Windows Server 2022 版本中，單台的獨立伺服器只要硬體配置時，採用混合式的儲存媒體裝置，例如，SSD + HDD 或 NVMe + HDD 的情況下，便能啟用「儲存匯流排快取」（Storage Bus Cache，SBC）機制，讓獨立伺服器能夠大幅提升資料的讀取和寫入效能（如圖 13 所示）。
獨立伺服器啟用 SBC 機制，僅支援混合式儲存架構不支援 All-Flash 儲存架構。
圖 13、獨立伺服器支援 SBC 儲存匯流排快取機制運作架構示意圖
值得注意的是，雖然是獨立伺服器運作環境，但是要啟用 SBC 特色功能之前，除了配置混合式儲存媒體裝置之外，也必須為 Windows Server 2022 安裝容錯移轉叢集功能才行，但是不能加入任何一個容錯移轉叢集，也就是不能成為任何一個容錯移轉叢集的成員節點。當然，採用舊有的 Windows Server 2019 和 2016 版本，也無法支援獨立伺服器啟用 SBC 特色功能。
實戰演練 - SMB Compress
在過去的 Windows Desktop 和 Windows Server 版本中，主機之間最常進行檔案交換的方式便是採用 SMB 通訊協定。然而，當主機所處的網路環境中，倘若傳輸頻寬不足導致傳輸速度較慢，例如，1 Gbps 乙太網路或 Wi-Fi 無線網路……等，或者因為主機數量過多造成網路頻寬擁擠的情況時，往往就會大大影響整體檔案交換的傳輸時間。
現在，最新版本的 Windows 11 和 Windows Server 2022，已經內建支援最新的「SMB 壓縮」（SMB Compress）機制。簡單來說，當 SMB 用戶端和 SMB 伺服器端皆啟用 SMB 壓縮機制後，在檔案交換的傳輸過程中，將會使用更少的網路頻寬且更快傳輸完畢，唯一的缺點就是在傳輸過程中，主機的 CPU 使用率會稍微增加。
SMB 壓縮機制支援多種壓縮演算法，包含，XPRESS（LZ77）、XPRESS Huffman（LZ77 + Huffman）、LZNT1 或 PATTERN_V1 *，預設情況下將會採用 XPRESS 壓縮演算法。
同時，新式的 SMB 壓縮機制，也已經和其它 SMB 傳輸機制整合完成，例如，支援 SMB 簽署（SMB Signing）、SMB 加密（SMB Encyrption）、SMB over QUIC、SMB 多重通道（SMB MultiChannel）。值得注意的是，目前 SMB 壓縮機制尚未與 SMB Direct over RDMA 機制整合完成，但是微軟官方已經預告，將會在後續的更新版本中，將 SMB 壓縮機制與 SMB Direct over RDMA 進行整合。
啟用 SMB 壓縮機制
首先，在擔任 SMB 伺服器端的 Windows Server 2022 主機上，安裝「檔案伺服器」（File Server）伺服器角色後，在組態設定檔案共享機制時，管理人員可以透過 WAC（Windows Admin Center）或 PowerShell 指令，針對指定的檔案共享啟用 SMB 壓縮機制。
當管理人員登入 WAC 平台並連線 SMB 伺服器端主機後，依序點選「Files & file sharing > File shares > New share」，在彈出的 New file share 視窗中，依據需求組態設定 SMB 檔案共享機制，在 Folder location 欄位，選擇 SMB 伺服器端主機準備分享的資料夾，在 Share name 欄位填入網路分享的名稱，在 Share permissions 欄位組態設定，哪些使用者和群組具備存取此 SMB 檔案共享的權限，最重要的是請勾選「Compress data」項目（如圖 14 所示），再按下 Create 鈕建立 SMB 檔案共享，確保此 SMB 檔案共享啟用並支援 SMB 壓縮機制。
請注意，原有的「伺服器管理員」（Server Manager）管理工具，並未支援組態設定 SMB 檔案共享啟用 SMB 壓縮機制。
圖 14、建立 SMB 檔案共享並啟用 SMB 壓縮機制
當 SMB 檔案共享建立完成後，管理人員也可以透過 WAC 管理平台，輕鬆在 SMB 伺服器主機端查看，哪些 SMB 檔案共享資料夾已經啟用並支援 SMB 壓縮機制（如圖 15 所示）。
圖 15、透過 WAC 管理平台判斷，哪些 SMB 檔案共享資料夾已經啟用並支援 SMB 壓縮機制
習慣使用 PowerShell 指令進行管理任務的資訊人員，可以透過「New-SmbShare」指令，在建立新的 SMB 檔案共享時，加上「-CompressData $true」參數（如圖 16 所示），即可達成建立 SMB 檔案共享資料夾，並且啟用和支援 SMB 壓縮機制。
圖 16、建立 SMB 檔案共享資料夾並啟用和支援 SMB 壓縮機制
倘若，在建立 SMB 檔案共享資料夾時，未啟用 SMB 壓縮機制的話，後續也可以透過「Set-SmbShare」指令搭配「-CompressData $true」參數，針對指定的 SMB 檔案共享啟用 SMB 壓縮機制（如圖 17 所示）。
圖 17、針對已建立的 SMB 檔案共享資料夾啟用 SMB 壓縮機制
手動測試 SMB 壓縮機制
在正式使用支援 SMB 壓縮機制的 SMB 檔案共享資源之前，管理人員可以先透過 Robocopy 或 Xcopy 工具，驗證目標端的 SMB 檔案共享資源，是否真的支援 SMB 壓縮機制。同時，在驗證過程中也可以觀察，SMB 用戶端未支援和支援 SMB 壓縮機制時，對於網路頻寬使用率、CPU 工作負載、檔案傳輸時間上的差異和變化。
由於 SMB 壓縮機制具備空白區塊自動壓縮的特性，所以管理人員可以透過此特性建立簡單的測試環境。首先，在 SMB 用戶端透過磁碟管理員（本文實作採用最新 Windows 11），建立 VHDX 虛擬磁碟檔案，並勾選採用「固定大小」（Fixed size）選項，在本文實作環境中建立 10 GB 大小的 VHDX 虛擬磁碟檔案（如圖 18 所示），建立完成並掛載成功後將一些圖片檔案複製到其中，此次複製了 200 個圖片檔案並佔用約 700 MB 的儲存空間。
圖 18、建立 10GB 檔案大小的 VHDX 虛擬磁碟檔案
在開始執行檔案傳輸之前，請先確保 SMB 用戶端已經將剛才掛載的 C:\tmp\test.vhdx 虛擬磁碟檔案卸載，接著透過「ROBOCOPY」指令，指定檔案傳輸的來源端資料夾「C:\tmp」，以及 SMB 伺服器端的 SMB 檔案共享路徑「\\ws2022-smb.lab.weithenn.org\smb-share」。
在檔案傳輸過程中，管理人員可以透過工作管理員，觀察網路頻寬的使用量和 CPU 工作負載，以便稍後和使用 SMB 壓縮機制時進行比較。在本文實作環境中，可以看到 SMB 用戶端未使用 SMB 壓縮機制時，傳輸 10GB 虛擬磁碟檔案所花費的時間為「1 分 17 秒」（如圖 19 所示）。
圖 19、SMB 用戶端未使用 SMB 壓縮機制進行檔案傳輸花費 1 分 17 秒
刪除 SMB 伺服器端檔案共享路徑內的 test.vhdx 測試檔案後，再次於 SMB 用戶端使用 robocopy 指令執行檔案傳輸作業。但是，這次加上「/COMPRESS」參數，確保在檔案傳輸的過程中，SMB 用戶端也啟用 SMB 壓縮機制和 SMB 伺服器端溝通。
在本文實作環境中，可以看到 SMB 用戶端啟用 SMB 壓縮機制後，傳輸 10GB 虛擬磁碟檔案所花費的時間減少為「46 秒」（如圖 20 所示），並且在傳輸檔案的過程中使用的網路頻寬較少，在 CPU 工作負載方面，則是由原先的未啟用 SMB 壓縮機制的「8% - 13%」，些許升高為「15% - 20%」。
圖 20、SMB 用戶端使用 SMB 壓縮機制進行檔案傳輸僅花費 46 秒
掛載網路磁碟機測試 SMB 壓縮機制
採用 Robocopy 或 Xcopy 檔案複製工具，對於 IT 管理人員來說並沒有任何問題和困擾，但是對於一般使用者來說，除了不熟悉指令和參數之外，在操作上也沒有那麼直覺易用。因此，在手動測試並確認 SMB 壓縮機制正常運作後，接著測試使用者經常使用檔案傳輸的情境，便是將 SMB 檔案共享資源掛載為網路磁碟機，接著透過檔案總管進行檔案傳輸的動作。
首先，在 SMB 用戶端掛載 SMB 檔案共享資源時，使用「NET USE」指令時，可以先採用傳統的掛載方式，完成後測試檔案傳輸機制使用的網路頻寬、傳輸時間、CPU 工作負載，接著卸載該 SMB 檔案共享資源後，再次使用「NET USE」指令並搭配「/REQUESTCOMPRESSION:YES」參數（如圖 21 所示），確保掛載的 SMB 檔案共享資源有啟用 SMB 壓縮機制，並再次測試檔案傳輸，應該可以得到跟剛才 Robocopy 一樣的測試結果，也就是使用網路頻寬少、傳輸時間降低、CPU 工作負載略微升高的結果。
圖 21、掛載 SMB 檔案共享資源並啟用 SMB 壓縮機制
SMB 用戶端一律啟用 SMB 壓縮機制
透過上述的二項測試，相信管理人員已經體會到在執行檔案傳輸時，只要 SMB 伺服器端和 SMB 用戶端，同時支援並啟用 SMB 壓縮機制後，將能有效降低網路頻寬的使用率並降低檔案傳輸時間。然而，SMB 用戶端無論是在指令或是掛載 SMB 檔案共享資源時，必須確保啟用 SMB 壓縮機制，才能享受到 SMB 壓縮機制所帶來的優點，是否有方法能夠讓 SMB 用戶端一律啟用 SMB 壓縮機制，而無須再使用前加上參數？ 答案是有的。
管理人員可以透過 GPO 群組原則，為每台支援 SMB 壓縮機制的 SMB 用戶端中，於「Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Sereivces\LanmanWorkstation\Parameters」路徑下，新增一筆 REG_DWORD 機碼值，名稱為「EnableCompressedTraffic」並設定數值為「1」（如圖 22 所示），即可組態設定 SMB 用戶端一律啟用 SMB 壓縮機制。同時，新增這筆 REG_DWORD 機碼值後，SMB 用戶端無須重新啟動即可立即套用生效。
圖 22、組態設定 SMB 用戶端一律啟用 SMB 壓縮機制
結語
透過本文的深入剖析後，相信管理人員已經了解，微軟最新推出的 Windows Server 2022 雲端作業系統，增強哪些原有功能和推出哪些亮眼新功能，並且實戰演練內建於 Windows Server 2022 和 Windows 11 的 SMB 壓縮機制，有效幫助企業和組織減少網路頻寬使用率降低檔案傳輸時間，為企業和組織減少不必要的時間成本浪費。
