改善 NFS Azure 檔案共用的效能

本文會說明如何改善網路檔案系統 (NFS) Azure 檔案共用的效能。

適用於

管理模型	計費模型	媒體分層	冗餘性	SMB	NFS
Microsoft 儲存服務	已佈建的 v2	SSD （進階版）	本地 (LRS)
Microsoft 儲存服務	已佈建的 v2	SSD （進階版）	區域 (ZRS)
Microsoft 儲存服務	已佈建的 v2	HDD （標準）	本地 (LRS)
Microsoft 儲存服務	已佈建的 v2	HDD （標準）	區域 (ZRS)
Microsoft 儲存服務	已佈建的 v2	HDD （標準）	異地 (GRS)
Microsoft 儲存服務	已佈建的 v2	HDD （標準）	GeoZone （GZRS）
Microsoft 儲存服務	已佈建的 v1	SSD （進階版）	本地 (LRS)
Microsoft 儲存服務	已佈建的 v1	SSD （進階版）	區域 (ZRS)
Microsoft 儲存服務	隨用隨付	HDD （標準）	本地 (LRS)
Microsoft 儲存服務	隨用隨付	HDD （標準）	區域 (ZRS)
Microsoft 儲存服務	隨用隨付	HDD （標準）	異地 (GRS)
Microsoft 儲存服務	隨用隨付	HDD （標準）	GeoZone （GZRS）

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

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 連線。

優點

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

計量 (作業)	I/O 大小	效能改進
IOPS (寫入)	64 KiB， 1,024 KiB	3x
IOPS (讀取)	所有 I/O 大小	2到4倍
輸送量 (寫入)	64 KiB， 1,024 KiB	3x
輸送量 (讀取)	所有 I/O 大小	2到4倍

先決條件

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

效能影響

在大規模在Linux用戶端上使用 nconnect 掛接選項搭配 NFS Azure 檔案共用時，我們取得了下列效能結果。 如需如何達成這些結果的詳細資訊，請參閱效能測試組態。

建議

請遵循這些建議以從 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

附註

即使記憶體帳戶解析為不同的IP位址，我們也無法保證該位址會保存，因為公用端點不是靜態位址。

案例 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)
• OS：Linux (Ubuntu 20.40)
• NFS 儲存體： SSD 檔案共用 (已佈建 30 TiB，設定 nconnect=4)

大小	vCPU	記憶體	暫存儲存體 (SSD)	最大資料磁碟	最大 NIC	預期的網路頻寬
Standard_D16_v4	16	64 GiB	僅限遠端儲存體	32	8	12,500 Mbps

效能評定工具和測試

我們使用了彈性 I/O 測試器 (FIO)，這是免費且開放原始碼的磁碟 I/O 工具，用於基準測試和壓力/硬體驗證。 若要安裝 FIO，請遵循 FIO 讀我檔案中的 [二進位套件] 區段，以在您選擇的平台上進行安裝。

雖然這些測試著重於隨機 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 對工作負載是否有利。 建議使用綠色醒目提示的案例，而非紅色醒目提示的案例。 以黃色醒目提示的案例為中性。

另請參閱

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