改善 NFS Azure 檔案共用的效能

本文說明如何改善網路文件系統 （NFS） Azure 檔案共用的效能。

適用於

管理模型	計費模型	媒體分層	冗餘性	中小企業 (SMB)	網路檔案系統 (NFS)
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核心版本會將預先讀取值設定為掛接文件系統的 rsize15倍，這代表讀取緩衝區大小的用戶端掛接選項。 這會設定夠高的預先讀取值，以在大部分情況下改善用戶端循序讀取輸送量。

不過，從 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	三倍
IOPS (讀取)	所有 I/O 大小	2到4倍
輸送量 (寫入)	64 KiB， 1,024 KiB	三倍
輸送量 (讀取)	所有 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 系列）
• 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 檔案儲存體的效能