微軟新推出的Windows Server 2022雲端作業系統，除了增強原有的功能外，更推出諸多亮眼新功能，為此本文將實際操作Windows Server 2022和Windows 11內建的SMB壓縮機制，示範該機制如何減少網路頻寬使用率，降低檔案傳輸時間，進而避免不必要的時間成本浪費。
在微軟Ignite 2021秋季大會上，總共發佈90多項新服務和功能更新，包含針對元宇宙（Metaverse）、人工智慧（Artificial Intelligence，AI）、數位分身（Digital Twins）、超級連結（Hyperconnectivity）等等關鍵趨勢，如圖1所示，其中也包括最新一代的Windows Server 2022雲端作業系統的正式發佈。
圖1 透過虛擬人物幫助大家在數位環境中相聚的元宇宙概念。 （圖片來源：微軟新聞中心 - 微軟Ignite 2021秋季大會：混合世界中的元宇宙、AI和超級連結）
Windows Server 2022亮眼特色功能介紹
新發佈的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網路封包示意圖。 （圖片來源：Microsoft Tech Community - How to Defend Users from Interception Attacks via SMB Client Defense）
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運作流程示意圖。 （圖片來源：Microsoft Tech Community - SMB over QUIC: Files Without the VPN）
值得注意的是，目前Windows Server 2022 Standard或Datacenter版本並未支援SMB over QUIC功能，必須是「Windows Server 2022 Datacenter: Azure Edition」版本才能啟用，如圖4所示。
圖4 Windows Server 2022版本功能比較表。 （圖片來源：Microsoft Docs - Comparison of Standard, Datacenter, and Datacenter Azure Edition editions of 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組態設定。 （圖片來源：Microsoft Docs – Live Migration Troubleshoot live migration issues）
雖然SMB壓縮機制早已是Windows 10和SMB 2通訊協定規範的一部分，但並未積極整合其他服務，因此一開始只整合Hyper-V Live Migration線上遷移機制，後來則又整合了IT人員常用的檔案複製工具Robocopy和Xcopy。
透過SMB壓縮機制，系統將在檔案傳輸時自動化處理空白區塊進行壓縮，例如VM虛擬主機磁碟、圖形檔案、科學數據等等。如圖6所示，可以看到未啟用和啟用SMB壓縮機制後，在檔案傳輸上有明顯的效能改進。
圖6 未啟用和啟用SMB壓縮機制後傳輸效能比較表。 （圖片來源：Microsoft Tech Community - SMB Compression: Deflate your IO）
更新後無須重新啟動的Hotpatch技術
過去的Windows Server版本在安裝相關安全性更新後，通常必須重新啟動Windows Server，以便安全性更新或相關修正能夠套用生效。雖然管理人員已經習慣此維運節奏，然而有些即時性的安全性更新，管理人員可能因為營運服務暫時無法中斷，而延後安裝安全性更新，間接造成營運服務暴露在資安風險當中。
透過最新的「熱修補」（Hotpatch）技術，如圖7所示，在安裝安全性更新時，會直接針對Windows Server內執行中的系統程序進行記憶體內部程式碼修正的動作，不僅營運服務中系統程序可持續運作，並且修正之後Windows Server也無須重新啟動，達成安全性更新和修補的目的。
圖7 Hotpatch技術運作架構示意圖。 （圖片來源：Microsoft Tech Community - Hotpatching on Windows）
在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安裝安全性更新流程。 （圖片來源：Microsoft IT Ops Talk - Windows Server Azure Edition HotPatch demo）
目前Windows Server 2022 Standard或Datacenter版本並未支援Hotpatch功能，必須採用Windows Server 2022 Datacenter: Azure Edition版本方可使用，如圖9所示。
圖9 Windows Server 2022版本功能比較表。 （圖片來源：Microsoft Docs - Comparison of Standard, Datacenter, and Datacenter Azure Edition editions of 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虛擬化平台巢狀式虛擬化運作架構示意圖。 （圖片來源：Microsoft Docs – Run Hyper-V in Virtual Machine with Nested Virtualization）
隨著AMD處理器的重新崛起，企業和組織也逐漸將採用AMD處理器的伺服器導入至地端資料中心內，甚至從過去僅用於測試和研發用途，也慢慢提升為負責二線服務或部分營運服務。因此，在最新的Windows 11和Windows Server 2022版本中，正式支援採用虛擬化技術的AMD EPYC/Ryzen處理器，也能夠建立Hyper-V巢狀式虛擬化環境，如圖11所示。
圖11 AMD處理器建構Hyper-V巢狀式虛擬化環境。 （圖片來源：Microsoft Tech Community - AMD Nested Virtualization Support）
改採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），這對於高速網路日漸普及的資料中心來說，能夠提供更好更穩定的網路資料流和更多的網路頻寬。
此外，微軟也針對最新Windows Server 2022，以及過去的Windows Server版本進行比較。如圖12所示，可以看到在「128MB」和「200ms RTT」的網路環境中，採用新式網路堆疊機制的Windows Server 2022，在網路吞吐量方面增加超過40倍以上，在其他網路情境測試中也至少提升5倍的網路吞吐量。
圖12 採用新網路堆疊機制的Windows Server 2022網路吞吐量大幅增加。 （圖片來源：Microsoft Tech Community - Algorithmic improvements boost TCP performance on the Internet）
獨立伺服器啟用SBC快取機制
在舊版的Windows Server運作環境中，「獨立伺服器」（Standalone Server）無法使用Storage Spaces Direct相關技術，必須整合多台Windows Server並建構容錯移轉叢集後才能使用。
現在，最新的Windows Server 2022版本中，單台的獨立伺服器只要硬體配置時採用混合式的儲存媒體裝置，例如SSD + HDD或NVMe + HDD的情況下，便能啟用「儲存匯流排快取」（Storage Bus Cache，SBC）機制，讓獨立伺服器能夠大幅提升資料的讀取和寫入效能，如圖13所示。
圖13 獨立伺服器支援SBC儲存匯流排快取機制運作架構示意圖。 （圖片來源：Microsoft Docs – 在獨立伺服器上啟用具有儲存空間的儲存匯流排快取）
值得注意的是，雖然是獨立伺服器運作環境，但要啟用SBC特色功能之前，除了配置混合式儲存媒體裝置外，也必須為Windows Server 2022安裝容錯移轉叢集功能才行，但是不能加入任何一個容錯移轉叢集，也就是不能成為任何一個容錯移轉叢集的成員節點。
當然，採用舊有的Windows Server 2019和2016版本，也無法支援獨立伺服器啟用SBC特色功能。
實戰演練SMB Compress
過去的Windows Desktop和Windows Server版本，主機之間最常進行檔案交換的方式是採用SMB通訊協定。然而，當主機所處的網路環境中，若傳輸頻寬不足導致傳輸速度較慢，例如1Gbps乙太網路或Wi-Fi無線網路等等，或者因為主機數量過多造成網路頻寬擁擠的情況時，往往會大大影響整體檔案交換的傳輸時間。
而新版的Windows 11和Windows Server 2022，已經內建支援最新的「SMB壓縮」（SMB Compress）機制。簡單來說，當SMB用戶端和SMB伺服器端皆啟用SMB壓縮機制，在檔案交換的傳輸過程中，將會使用更少的網路頻寬且更快傳輸完畢，唯一的缺點就是在傳輸過程中主機的CPU使用率會稍微增加。
同時，新式的SMB壓縮機制也已經與其他SMB傳輸機制整合完成，例如支援SMB簽署（SMB Signing）、SMB加密（SMB Encyrption）、SMB over QUIC、SMB多重通道。值得注意的是，目前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壓縮機制。
圖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）選項，在本文實作環境中建立10GB大小的VHDX虛擬磁碟檔案，如圖18所示，建立完成並掛載成功後將一些圖片檔案複製到其中，此次複製了200個圖片檔案並占用約700MB的儲存空間。
圖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用戶端無須重新啟動即可立即套用生效。
結語
相信管理人員已經了解，微軟最新推出的Windows Server 2022雲端作業系統增強哪些原有功能和推出哪些亮眼新功能，並且實戰演練內建於Windows Server 2022和Windows 11的SMB壓縮機制，可幫助企業減少網路頻寬使用率降低檔案傳輸時間。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞