改善 NFS Azure 檔案共用的效能

適用於： ✔️ NFS 檔案共享

本文提供多種提升網路檔案系統（NFS）Azure 檔案分享效能的方法。 主題包括設定 Linux read_ahead_kb 核心參數以提升序列讀取吞吐量、使用 nconnect 掛載選項以減少用戶端機器擴展吞吐量，以及將儲存帳號放在與用戶端相同的可用性區以降低延遲。

增加預先讀取大小以改善讀取輸送量

Linux 中的 read_ahead_kb 核心參數代表應該在循序讀取作業期間「預先讀取」或預先擷取的資料量。 5.4 之前的 Linux 核心版本會將預先讀取值設定為掛接檔案系統 rsize 的 15 倍，這代表讀取緩衝區大小的用戶端掛接選項。 這會設定夠高的預先讀取值，以在大部分情況下改善用戶端循序讀取輸送量。

不過，從 Linux 核心5.4版開始，Linux NFS 用戶端會使用預設 read_ahead_kb 值 128 KiB。 這個較小的值可能會降低大型檔案的讀取吞吐量。 從具有較大預讀值的 Linux 發行版本升級到預設值為 128 KiB 的版本的使用者，可能會遇到循序讀取效能下降的情況。

對於 Linux 核心 5.4 或更新版本，持續設定 read_ahead_kb 為 15 MiB 以提升效能。

若要變更此值，請在 Linux 核心裝置管理員 udev 中新增規則，以設定預先讀取大小。 請遵循下列步驟：

1. 在文字編輯器中，輸入並儲存下列文字，以建立 /etc/udev/rules.d/99-nfs.rules 檔案：

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. 在控制台中，執行 udevadm 命令作為超級使用者並重新載入規則檔案和其他資料庫，以套用 udev 規則。 你只需要執行這個指令一次，讓 udev 知道新檔案。

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect 是一種用戶端掛載 NFS 檔案分享的選項，你可以用它來建立用戶端與 NFS 檔案分享之間的多條 TCP 連線。 它對於大規模工作負載特別有用，因為單一 TCP 連線會成為瓶頸。

NCONNECT 的好處

透過 nconnect，您可以使用較少的用戶端電腦來大規模提升效能，以降低總擁有成本 （TCO）。 nconnect 功能會使用單一或多個用戶端，在一或多個 NIC 上使用多個 TCP 通道來提升效能。 沒有 nconnect 的話，你需要大約 20 台用戶端機器，才能達到最大 SSD 檔案共享配置容量所提供的頻寬擴展限制（10 GiB / sec）。 使用 nconnect 時，您只能使用 6-7 個客戶端達到這些限制，藉此將計算成本降低近 70%，同時大幅改善每秒 I/O 作業 （IOPS） 和大規模輸送量。 請參閱下表。

nconnect 先決條件

• 最新的 Linux 發行版完全支持 nconnect。 針對較舊的 Linux 發行版本，請確定 Linux 核心版本為 5.3 或更高版本。
• 只有在每個儲存體帳戶透過私人端點使用單一檔案共用時，才支援個別掛接組態。

效能影響

以下效能結果是透過 nconnect 掛載選項在 Linux 用戶端上大規模使用 NFS Azure 檔案分享進行測量。 關於這些結果如何達成的更多資訊，請參見 效能測試配置。

NCONNECT 推薦

請遵循這些建議以從 nconnect 獲得最佳結果。

設定 nconnect=4

雖然 Azure 檔案儲存體 支援將 nconnect 設為最高值 16，但建議將掛載選項設為最佳值 nconnect=4。 目前，針對 nconnect 的 Azure 檔案實作沒有超過四個通道的收益。 事實上，從單一用戶端超過單一 Azure 檔案共用的四個通道，可能會因為 TCP 網路飽和而對效能造成負面影響。

仔細調整虛擬機器大小

根據您的工作負載需求，請務必正確調整用戶端虛擬機（VM）的大小，以避免受到其 預期的網路頻寬限制。 您不需要多個網路介面控制器 (NIC)，才能達到預期的網路輸送量。 雖然搭配 Azure 檔案儲存體使用一般用途 VM 很常見，但根據您的工作負載需求和區域可用性，可以使用各種 VM 類型。 如需詳細資訊，請參閱 Azure VM 選取器。

讓佇列深度小於或等於 64

佇列深度是儲存體資源可服務的擱置 I/O 要求數目。 我們不建議超過 64 的最佳佇列深度，因為您不會看到更多效能提升。 如需詳細資訊，請參閱佇列深度。

每個掛接設定

如果一個工作負載需要從單一用戶端掛載多個擁有不同 nconnect 設定的儲存帳號的共享，這些設定在掛載於公共端點時並不保證會持續存在。 每個掛載設定僅支援每個儲存帳號在私有端點上分享單一 Azure 檔案，如情境 1 所述。

案例 1：透過具有多個儲存體帳戶的私人端點進行每個掛接設定 (支援)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

案例 2：透過公用端點進行每個掛接設定 (不支援)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

案例 3：每個掛接組態在 透過在單一儲存體帳戶上具有多個共用的私人端點進行每個掛接設定 (不支援)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

效能測試設定

要達成並衡量本文所述的成果，請使用以下資源與基準工具。

• 單一用戶端： 具有單一 NIC 的 Azure VM (DSv4-Series)
• 作業系統： Linux（Ubuntu 20.04）
• NFS 儲存體： SSD 檔案共用 (已佈建 30 TiB，設定 nconnect=4)

效能評定工具和測試

這些測試使用 Flexible I/O Tester（FIO），一款免費且開源的磁碟 I/O 工具，可用於基準測試及壓力或硬體驗證。 安裝 FIO 時，請參閱 FIO README 檔案 中的二進位套件區塊，並依照您選擇的平台指示操作。

雖然這些測試著重於隨機 I/O 存取模式，但使用循序 I/O 時，您會取得類似的結果。

高 IOPS：100% 讀取

4k I/O 大小 - 隨機讀取 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

8k I/O 大小 - 隨機讀取 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

高輸送量：100% 讀取

64 KiB I/O 大小 - 隨機讀取 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1,024 KiB I/O 大小 - 100% 隨機讀取 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

高 IOPS：100% 寫入

4 KiB I/O 大小 - 100% 隨機寫入 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8 KiB I/O 大小 - 100% 隨機寫入 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

高輸送量：100% 寫入

64 KiB I/O 大小 - 100% 隨機寫入 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024 KiB I/O 大小 - 100% 隨機寫入 - 64 佇列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

nconnect 的效能考量事項

使用 nconnect 掛接選項時，您應該仔細評估具有下列特性的工作負載：

• 單一執行緒和/或使用低佇列深度 (小於 16) 的延遲敏感性寫入工作負載
• 單一執行緒和/或搭配較小的 I/O 大小使用低佇列深度的延遲敏感性讀取工作負載

並非所有工作負載都需要高規模的 IOPS 或吞吐量效能。 對於較小規模的工作負載，可能 nconnect 不太有幫助。 使用下表來決定 nconnect 對工作負載是否有利。 建議使用綠色醒目提示的案例，而非紅色醒目提示的案例。 以黃色醒目提示的案例為中性。

使用分區佈局

對於使用 Microsoft.Storage 資源提供者建立的經典檔案共享，我們建議使用 區域配置 來選擇儲存帳號所在的特定可用性區域。 這讓你能將虛擬機放在與儲存裝置相同的可用區，延遲可減少高達 30%。 此功能目前僅適用於支援 區域內使用本地冗餘儲存（LRS）的 SSD 儲存帳號。

另請參閱

• 將 NFS 檔案共用掛載至 Linux 系統
• 掛接選項清單
• 了解 Azure 檔案儲存體的效能