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、 84 和 8 到 16。 每個測試期間都完整利用了 SMB 的四個 CPU 核心，如效能監視器 Per Processor Network Activity Cycles 統計資料所確認 (本文未包含。)

Azure 虛擬機 （VM） 不會影響 SMB （或 NFS） 記憶體 I/O 限制。 如下列圖表所示，D32ds 執行個體類型針對快取儲存體 IOPS 有 308,000 的速率限制，而針對未快取儲存體 IOPS 有 51,200 的速率限制。 不過，上圖顯示相較於 SMB 明顯更多的 I/O。

循序 I/O

與先前所述的隨機 I/O 測試類似的測試是使用 64-KiB 循序 I/O 來執行。 雖然每個 RSS 網路介面的用戶端連線計數增加對隨機 I/O 沒有任何明顯影響，但相同的動作不適用於循序 I/O。 如下圖所示，每個增加都會與讀取輸送量對應的增加相關聯。 由於 Azure 針對每個實體類型和大小所放置的網路頻寬限制，寫入輸送量維持一般。

Azure 會將網路速率限制放在每個 VM 類型和大小上。 速率限制只會對輸出流量實施。 VM 上存在的 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 ：彈性 I/O （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 或快速路由存取，因此 Azure NetApp Files 共用本質上是安全的。 啟用 SMB 加密的選擇完全由使用者決定。 啟用此功能之前，請注意預期的效能負面影響。

SMB 加密對用戶端工作負載的影響

雖然 SMB 加密會同時影響用戶端 (加密和解密訊息的 CPU 額外負荷) 和儲存體 (降低輸送量)，下表只會強調儲存體影響。 在將工作負載部署到生產環境之前，您應該先對自己的應用程式測試加密效能影響。

加速網路

為了達到最大效能，建議您盡可能在 VM 上設定 加速網路 。 請記住以下考量：

• Azure 入口網站 預設會針對支援此功能的 VM 啟用加速網路。 不過，其他部署方法，例如 Ansible 和類似的組態工具無法。 無法啟用加速網路功能可能會使機器的效能降低。
• 如果 VM 的網路介面上未啟用加速網路，因為 VM 不支援實例類型或大小，它仍會以較大的實例類型停用。 在這些情況下，您需要手動介入。
• 不需要為 Azure NetApp Files 專用子網中的 NIC 設定加速網路功能。 加速網路是僅適用於 Azure VM 的功能。 Azure NetApp Files NIC 會依設計最佳化。

接收端調整

Azure NetApp Files 支援接收端調整 （RSS）。

啟用 SMB 多重通道後，SMB3 用戶端會透過具備單一 RSS 功能的網路介面卡 (NIC) 建立與 Azure NetApp Files SMB 伺服器的多個 TCP 連線。

若要查看您的 Azure VM NIC 是否支援 RSS，請執行命令 Get-SmbClientNetworkInterface ，如下所示，並檢查 字段 RSS Capable：

SMB 用戶端上有多個 NIC

您不應該在用戶端上為SMB設定多個 NIC。 SMB 用戶端不符合SMB伺服器傳回的NIC計數。 每個記憶體磁碟區都可從一個和一個記憶體端點存取，這表示只有一個 NIC 用於任何指定的 SMB 關聯性。

如下列輸出 Get-SmbClientNetworkInterace 所示，VM 有兩個網路介面：15 和 12。 如下列命令 Get-SmbMultichannelConnection所示，即使有兩個支援 RSS 的 NIC，但只有介面 12 與 SMB 共用連線;介面 15 不在使用中。

下一步

• SMB 常見問題集