Azure NetApp Files 的 SMB 效能最佳做法
本文可協助您瞭解 Azure NetApp Files 的 SMB 效能和最佳做法。
SMB 多重通道
SMB 多重通道預設會在SMB共用中啟用。 所有 SMB 共用預先約會的現有 SMB 磁碟區都已啟用此功能，而且所有新建立的磁碟區也會在建立時啟用此功能。
在啟用功能之前建立的任何SMB連線都必須重設，才能利用SMB多重通道功能。 若要重設，您可以中斷連線並重新連線 SMB 共用。
自 Windows 2012 以來，Windows 支援 SMB 多重通道，以達到最佳效能。 如需詳細資訊，請參閱 部署SMB多重通道 和 SMB多重通道 的基本概念。
SMB 多重通道的優點
SMB 多重通道功能可讓 SMB3 用戶端透過單一網路適配器 （NIC） 或多個 NIC 建立連線集區，並使用它們來傳送單一 SMB 工作階段的要求。 相反地，根據設計，SMB1 和 SMB2 要求用戶端建立一個連線，並透過該連線傳送指定會話的所有 SMB 流量。 此單一聯機會限制可從單一用戶端達成的整體通訊協定效能。
SMB 多重通道的效能
下列測試和圖形示範單一實例工作負載上的SMB多重通道功能。
隨機 I/O
在用戶端上停用SMB多重通道時，使用FIO和40 GiB工作集執行純4 KiB讀取和寫入測試。 每個測試之間已卸離 SMB 共用，每個 RSS 網路介面設定1的 SMB 用戶端連線計數遞增為 、4、8、16。 set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count> 測試顯示的預設設定 4 足以處理 I/O 密集的工作負載;遞增至 8 ，並 16 具有微不足道的效果。
命令 netstat -na | findstr 445 證明已建立其他連接，並以從 1 到 48 到的遞增來 16建立。 每個測試期間都充分利用了SMB的四個CPU核心，如perfmon Per Processor Network Activity Cycles 統計數據所確認（本文未包含）。
Azure 虛擬機不會影響 SMB（或 NFS） 記憶體 I/O 限制。 如下圖所示，D32ds 實例類型對於快取的記憶體 IOPS 有 308,000 的有限速率，而未快取的記憶體 IOPS 則為 51,200。 不過，上圖在SMB上顯示更多I/O。
循序 IO
與先前所述的隨機 I/O 測試類似的測試是使用 64-KiB 循序 I/O 來執行。 雖然每個 RSS 網路介面在 4' 之後的用戶端連線計數增加對隨機 I/O 沒有明顯影響，但同樣不適用於循序 I/O。 如下圖所示，每個增加都會與相應增加的讀取輸送量相關聯。 由於 Azure 針對每個實體類型 / 大小所放置的網路頻寬限制，寫入輸送量維持一般。
Azure 會將網路速率限制放在每部虛擬機類型/大小上。 速率限制只會對輸出流量施加。 虛擬機上存在的 NIC 數目與機器可用的頻寬總量沒有影響。 例如，D32ds 實例類型具有強制的網路限制為16,000 Mbps（2,000 MiB/秒）。 如上圖所示，此限制會影響輸出流量（寫入），但不會影響多重通道讀取。
SMB 簽署
SMB 通訊協定提供檔案和列印共用和其他網路作業的基礎，例如遠端 Windows 系統管理。 為了防止在傳輸中修改SMB封包的中間人攻擊，SMB 通訊協定支援SMB封包的數字簽名。
Azure NetApp Files 支援的所有 SMB 通訊協定版本都支援 SMB 簽署。
SMB 簽署的效能影響
SMB 簽署對SMB效能有刪除效果。 除了效能降低的其他可能原因外，每個封包的數位簽名都會耗用額外的用戶端 CPU，如下面的 perfmon 輸出所示。 在此情況下，Core 0 會負責SMB，包括SMB簽署。 與上一節中非多重通道循序讀取輸送量數字的比較顯示，SMB 簽署會將整體輸送量從 875MiB/秒減少到大約 250MiB/秒。
具有 1 TB 數據集的單一實例效能
為了更詳細地深入解析具有讀取/寫入混合的工作負載，下列兩個圖表顯示具有 1 TB 數據集的單一 Ultra 服務層級雲端磁碟區效能，以及 SMB 多重通道為 4。 使用了最佳IODepth為16，而彈性IO（FIO） 參數則用來確保網路頻寬 （numjobs=16） 的充分使用。
下圖顯示 4k 隨機 I/O 的結果，其中單一 VM 實例和讀取/寫入混合間隔為 10%：
下圖顯示循序 I/O 的結果：
搭配 1 TB 數據集使用 5 部 VM 相應放大時的效能
具有 5 部 VM 的這些測試會使用與單一 VM 相同的測試環境，且每個進程都會寫入自己的檔案。
下圖顯示隨機 I/O 的結果：
下圖顯示循序 I/O 的結果：
如何監視 Hyper-V 乙太網路卡
搭配 FIO 進行測試時所使用的其中一個策略是設定 numjobs=16。 這麼做會將每個作業分叉成 16 個特定實例，以將 Microsoft Hyper-V 網路適配器最大化。
您可以選取 效能監視器 [新增計數器>網络介面 > Microsoft Hyper-V 網络適配器] > 來檢查 Windows 效能監視器 中每個適配卡的活動。
在磁碟區中執行數據流量之後，您可以在 Windows 效能監視器 中監視配接器。 如果您未使用這 16 個虛擬適配卡，您可能不會將網路頻寬容量最大化。
SMB 加密
本節可協助您瞭解 SMB 加密 （SMB 3.0 和 SMB 3.1.1）
SMB 加密 提供SMB資料的端對端加密，並保護資料免於竊聽不受信任網路上的發生次數。 SMB 3.0 和更新版本支援 SMB 加密。
將要求傳送至記憶體時，用戶端會加密要求，然後解密記憶體。 回應同樣會由伺服器加密，並由用戶端解密。
Windows 10、Windows 2012 和更新版本支援 SMB 加密。
SMB 加密和 Azure NetApp Files
SMB 加密是在 Azure NetApp Files 的共享層級啟用。 SMB 3.0 採用 AES-CCM 演算法，而 SMB 3.1.1 則採用 AES-GCM 演算法。
不需要SMB加密。 因此，只有在使用者要求 Azure NetApp Files 啟用時，才會針對指定的共用啟用它。 Azure NetApp Files 共用永遠不會向因特網公開。 它們只能從指定的 VNet、透過 VPN 或快速路由存取，因此 Azure NetApp Files 共用本質上是安全的。 啟用SMB加密的選擇完全由用戶決定。 在啟用這項功能之前，請注意預期的效能降低。
SMB 加密對用戶端工作負載的影響
雖然 SMB 加密會影響用戶端（加密和解密訊息的 CPU 額外負荷）和記憶體（降低輸送量），但下表只會醒目提示記憶體影響。 在將工作負載部署到生產環境之前，您應該先對自己的應用程式測試加密效能影響。
| I/O 設定檔 | 影響 |
|---|---|
| 讀取和寫入工作負載 | 10% 至 15% |
| 元數據密集 | 5% |
加速網路
為了達到最大效能，建議您盡可能在虛擬機上設定 加速網路 。 請記住以下考量：
- Azure 入口網站 預設會針對支援這項功能的虛擬機啟用加速網路。 不過，其他部署方法，例如 Ansible 和類似的組態工具，可能不會。 無法啟用加速網路功能可能會使機器的效能步履蹣跚。
- 如果虛擬機的網路介面上未啟用加速網路，因為虛擬機不支持實例類型或大小，它仍會以較大的實例類型停用。 在這些情況下，您將需要手動介入。
- 不需要為 Azure NetApp Files 專用子網中的 NIC 設定加速網路功能。 加速網路是僅適用於 Azure 虛擬機的功能。 Azure NetApp Files NIC 的設計已優化。
RSS
Azure NetApp Files 支援接收端調整 （RSS）。
啟用SMB多重通道後，SMB3 用戶端會透過支援單一 RSS 的網路適配器 （NIC） 建立與 Azure NetApp Files SMB 伺服器的多個 TCP 連線。
若要查看您的 Azure 虛擬機 NIC 是否支援 RSS，請執行命令 Get-SmbClientNetworkInterface ，如下所示，並檢查 字段 RSS Capable：
SMB 用戶端上的多個 NIC
您不應該在用戶端上為SMB設定多個 NIC。 SMB 用戶端會比對SMB伺服器傳回的NIC計數。 每個記憶體磁碟區都可以從一個和一個記憶體端點存取。 這表示只有一個 NIC 會用於任何指定的 SMB 關聯性。
如下列輸出 Get-SmbClientNetworkInterace 所示，虛擬機有 2 個網路介面--15 和 12。 如下列命令 Get-SmbMultichannelConnection所示，即使有兩個支援 RSS 的 NICS，但只有介面 12 與 SMB 共用連線;介面 15 不在使用中。
下一步
- SMB 常見問題集
- 請參閱 Azure NetApp Files：適用於 SMB 工作負載的受控企業檔案共享，瞭解如何搭配 Azure NetApp Files 使用 SMB 檔案共用。