改善 NFS Azure 檔案共用效能

本文說明如何改善 NFS Azure 檔案共用的效能。

適用於

檔案共用類型	SMB	NFS
標準檔案共用 (GPv2)、LRS/ZRS
標準檔案共用 (GPv2)、GRS/GZRS
進階檔案共用 (FileStorage)、LRS/ZRS

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

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
   

Nconnect

Nconnect 是用戶端 Linux 掛接選項，可讓您在用戶端與適用於 NFSv4.1 的 Azure 進階檔案儲存體之間使用更多 TCP 連線，同時維持平台即服務 (PaaS) 的復原能力，進而大規模提升效能。

nconnect 的優點

透過 nconnect，您可以使用較少的用戶端電腦大規模提高效能，以降低總擁有成本 (TCO)。 Nconnect 會使用單一或多個用戶端，在一或多個 NIC 上使用多個 TCP 通道來提升效能。 如果沒有 nconnect，您大約需要 20 部用戶端電腦，才能達到最大進階 Azure 檔案共用佈建大小所提供的頻寬規模限制 (10 GiB/秒)。 透過 nconnect，您只能使用 6-7 個客戶端來達到這些限制。 這幾乎減少了 70% 的計算成本，同時大規模改善 IOPS 和輸送量 (請參閱資料表)。

計量 (作業)	I/O 大小	效能改進
IOPS (寫入)	64K、1024K	3x
IOPS (讀取)	所有 I/O 大小	2-4x
輸送量 (寫入)	64K、1024K	3x
輸送量 (讀取)	所有 I/O 大小	2-4x

必要條件

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

nconnect 的效能影響

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

nconnect 的建議

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

設定 nconnect=4

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

仔細調整虛擬機器大小

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

讓佇列深度小於或等於 64

佇列深度是儲存體資源可服務的擱置 I/O 要求數目。 不建議使用超過 64 的最佳佇列深度。 如果您這麼做，就不會再看到任何效能提升。 如需詳細資訊，請參閱佇列深度。

Nconnect 個別掛接組態

如果工作負載需要掛接具有與單一用戶端不同 nconnect 設定的一或多個儲存體帳戶的多個共用，我們無法保證這些設定會在透過公用端點掛接時保存。 只有在單一 Azure 檔案共用透過私人端點使用單一 Azure 檔案共用時，才支援個別掛接組態，如案例 1 中所述。

案例 1：(支援) 透過具有多個儲存體帳戶之私人端點的 nconnect 個別掛接組態

• 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：(不支援) 透過公用端點的 nconnect 個別掛接組態

• 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：(支援) 透過單一儲存體帳戶上具有多個共用之私人端點的 nconnect 個別掛接組態

• 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 虛擬機器 (DSv4 系列)
• OS：Linux (Ubuntu 20.40)
• NFS 儲存體：Azure 檔案儲存體進階檔案共用 (已佈建 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% 讀取

64k 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

1024k 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% 寫入

4k 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

8k 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% 寫入

64k 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

1024k 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。
• 如需完整的掛接選項清單，請參閱 Linux NFS 手冊頁。
• 如需延遲、IOPS、輸送量和其他效能概念的相關資訊，請參閱了解 Azure 檔案儲存體效能。