Azure NetApp Files 的 SMB 效能最佳做法

本文可協助您了解 Azure NetApp Files 的 SMB 效能和最佳做法。

SMB 多重通道

SMB 多重通道預設會在 SMB 共用中啟用。 時間上早於現有的 SMB 磁碟區的所有 SMB 共用都已啟用該功能，而且所有新建立的磁碟區也會在建立時啟用該功能。

在啟用功能之前建立的任何 SMB 連線都必須重設，才能利用 SMB 多重通道功能。 若要重設，您可以中斷連線並重新連線 SMB 共用。

Windows 自 Windows 2012 以來支援 SMB 多重通道，以實現最佳效能。 如需詳細資料，請參閱部署 SMB 多重通道和 SMB 多重通道的基本概念。

SMB 多重通道的優點

SMB 多重通道功能可讓 SMB3 用戶端透過單一網路介面卡 (NIC) 或多個 NIC 來建立連線集區，並使用其來傳送單一 SMB 工作階段的要求。 相反地，根據設計，SMB1 和 SMB2 會要求用戶端建立一個連線，並透過該連線傳送指定工作階段的所有 SMB 流量。 這個單一連線會限制可從單一用戶端達成的整體通訊協定效能。

SMB 多重通道的效能

下列測試和圖形會示範單一執行個體工作負載上 SMB 多重通道的功能。

隨機 I/O

在用戶端上停用 SMB 多重通道後，使用 FIO 和 40 GiB 工作集執行了純 4 KiB 的讀取和寫入測試。 每個測試之間的 SMB 共用已中斷連結，每個 RSS 網路介面設定的 SMB 用戶端連線計數遞增為 1、4、8、16、set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count>。 測試顯示 4 的預設設定對於 I/O 密集工作負載已足夠；遞增至 8 和 16 的效果可忽略。

命令 netstat -na | findstr 445 已證明已建立其他連線，其增量從 1 到 4 到 8 和到 16。 每個測試期間都完整利用了 SMB 的四個 CPU 核心，如效能監視器 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，如下列效能監視器輸出所示。 在此情況下，核心 0 會負責 SMB，包括 SMB 簽署。 與上一節中非多重通道循序讀取輸送量數字的比較顯示，SMB 簽署會將整體輸送量從 875MiB/秒減少到大約 250MiB/秒。

具有 1 TB 資料集的單一執行個體的效能

為了針對具有讀取/寫入混合的工作負載提供更詳細的深入解析，下列兩個圖表顯示一個 50 TB 並具有 1 TB 資料集和 4 個 SMB 多重通道的超服務層級雲端磁碟區的效能。 使用了 16 個的最佳 IODepth，且使用彈性 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 網路介面卡最大化。

您可以在 Windows 效能監視器中檢查每個介面卡上的活動，方法是選取 [效能監視器] > [新增計數器] > [網路介面] >[Microsoft Hyper-V 網路介面卡]。

磁碟區中有資料流量執行之後，您可以在 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 或 ExpressRoute 存取，因此 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 的 NIC，只有使用的介面 12 與 SMB 共用有關；介面 15 未在使用中。

下一步

• SMB 常見問題集
• 如需使用 SMB 檔案共用搭配 Azure NetApp Files 的詳細資訊，請參閱 Azure NetApp Files：SMB 工作負載的受控企業檔案共用。