使用 nconnect 改善 NFS Azure 檔案共用效能

2023-03-25 22:02| 来源: 网络整理| 查看: 265

使用改善 NFS Azure 檔案共用效能 nconnect 發行項 03/22/2023

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

適用於檔案共用類型 SMB NFS 標準檔案共用 (GPv2)、LRS/ZRS 標準檔案共用 (GPv2)、GRS/GZRS 進階檔案共用 (FileStorage)、LRS/ZRS nconnect 的優點

透過 nconnect ，您可以使用較少的用戶端電腦來大規模增加效能，以降低 TCO) (擁有權總成本。 Nconnect 使用單一或多個用戶端，在一或多個 NIC 上使用多個 TCP 通道來提升效能。如果沒有 nconnect ，您需要大約 20 部用戶端電腦，才能達到頻寬調整限制， (10 GiB/秒) 由最大的進階 Azure 檔案共用布建大小提供。透過 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

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

建議

請遵循這些建議，從 nconnect 取得最佳結果。

設置 nconnect=4

雖然Azure 檔案儲存體支援 nconnect 設定最多 16 個設定，但建議使用的最佳設定 nconnect=4 來設定掛接選項。目前，針對的Azure 檔案儲存體實作，沒有超過四個通道的 nconnect 收益。事實上，超過來自單一用戶端的單一 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:/FileShare1 nconnect=4 Mount StorageAccount2.file.core.windows.net:/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:/FileShare1 nconnect=4 Mount StorageAccount.file.core.windows.net:/FileShare2 Mount StorageAccount2.file.core.windows.net:/FileShare1

注意

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

案例 3： (在單一儲存體帳戶上具有多個共用的私人端點上，不支援 nconnect 每個掛接組態) StorageAccount.file.core.windows.net = 10.10.10.10 Mount StorageAccount.file.core.windows.net:/FileShare1 nconnect=4 Mount StorageAccount.file.core.windows.net:/FileShare2 Mount StorageAccount.file.core.windows.net:/FileShare3 效能測試設定

我們使用下列資源和基準測試工具來達成及測量本文中所述的結果。

單一用戶端：具有單一 NIC 的 Azure 虛擬機器 (DSv4 系列) 作業系統： 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 掛接選項時，您應該仔細評估具有下列特性的工作負載：

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

並非所有工作負載都需要高階 IOPS 或整個效能。對於較小的工作負載， nconnect 可能不合理。使用下表來決定 nconnect 是否對您的工作負載有好處。建議以綠色醒目提示的案例，而紅色醒目提示的案例則不是。以黃色反白顯示的是中性。

另請參閱如需掛接指示，請參閱將 NFS 檔案共用掛接至 Linux。如需掛接選項的完整清單，請參閱 Linux NFS man 頁面。如需延遲、IOPS、輸送量和其他效能概念的相關資訊，請參閱瞭解Azure 檔案儲存體效能。

【本文地址】

公司简介

联系我们