適用於Linux的 Azure NetApp Files 大型磁碟區效能基準檢驗
本文說明單 一 Azure NetApp Files 大型磁碟 區與 Linux 使用案例相關的測試效能功能。 測試探索了相應放大和相應增加讀取和寫入工作負載的案例，涉及一部和多部虛擬機（VM）。 瞭解大型磁碟區的效能信封可協助您加速磁碟區重設大小。
測試摘要
Azure NetApp Files 大型磁碟區功能提供三個服務等級，每個層級都有輸送量限制。 當您的效能需求變更時，服務等級可以不中斷地相應增加或減少。
- Ultra 服務等級：12,800 MiB/秒
- 進階服務等級：6,400 MiB/秒
- 標準服務等級：1,600 MiB/秒
Ultra 服務等級用於這些測試中。
循序寫入：在這些基準檢驗中，100% 的循序寫入上限為 ~8,500 MiB/秒。 （服務限制為12,800 MiB/秒的單一大型磁碟區最大輸送量，因此可能會有更多潛在的輸送量。
循序讀取：在這些基準檢驗中，100% 的循序讀取上限為 ~12,761 MiB/秒。 （單一大型磁碟區的輸送量上限為 12,800 MiB/秒。此結果接近目前可達到的最大輸送量。
隨機 I/O：相同的單一大型磁碟區每秒提供超過 700,000 個作業。
由於大量磁碟區的平行處理原則增加，元數據繁重的工作負載對 Azure NetApp File 大型磁碟區有利。 在大量檔案建立、取消鏈接和檔案重新命名的工作負載中，效能優點明顯，如同 VCS 應用程式一般，以及存在高檔案計數的 EDA 工作負載。 如需高元數據工作負載效能的詳細資訊，請參閱 使用 Azure NetApp Files 進行電子設計自動化的優點。
FIO 是設計為記憶體壓力測試的合成工作負載產生器，可用來驅動這些測試結果。 記憶體效能測試基本上有兩種模型：
- 向外延展計算，這是指使用多個 VM 在單一 Azure NetApp Files 磁碟區上產生最大負載。
- 相應增加計算，其是指使用大型 VM 在單一 Azure NetApp Files 磁碟區上測試單一用戶端的上限。
Linux 向外延展測試
測試觀察到相應放大單一大型磁碟區的效能臨界值，並使用下列設定進行：
| 元件 | 組態 |
|---|---|
| Azure VM 大小 | E32s_v5 |
| Azure VM 輸出頻寬限制 | 2000MiB/秒 (2GiB/秒) |
| 作業系統 | RHEL 8.4 |
| 大型磁碟區大小 | 101 TiB Ultra （12,800 MiB/秒輸送量） |
| 掛接選項 | hard,rsize=65536,wsize=65536,vers=3 注意：同時使用 262144 和 65536 會有類似的效能結果。 |
256-KiB 循序工作負載 (MiB/秒)
此圖表代表 256-KiB 循序工作負載，使用 12 部虛擬機使用 1-TiB 工作集讀取和寫入至單一大型磁碟區。 此圖表顯示，單一 Azure NetApp Files 大型磁碟區可以處理大約 8,518 MiB/s 的純循序寫入和 12,761 MiB/s 純循序讀取。
8-KiB 隨機工作負載 (IOPS)
此圖表代表 8-KiB 隨機工作負載和 1 TiB 工作集。 此圖表顯示：Azure NetApp Files 大型磁碟區可以處理大約 474,000 個純隨機寫入，以及大約 709,000 個純隨機讀取。
Linux相應增加測試
雖然向外延展測試的設計目的是要找出單一大型磁碟區的限制，但相應增加測試的設計目的是要針對上述大型磁碟區尋找單一實例的上限。 Azure 會對其 VM 放置網路輸出限制;表示每個 VM 的寫入頻寬上限為網路連接記憶體。 這些相應增加測試會示範具有大量可用頻寬上限的功能，以及有足夠的處理器來驅動上述工作負載。
本節中的測試是使用下列組態來執行：
| 元件 | 組態 |
|---|---|
| Azure VM 大小 | E104id_v5 |
| Azure VM 輸出頻寬限制 | 12,500MiB/s （12.2GiB/秒） |
| 作業系統 | RHEL 8.4 |
| 大型磁碟區大小 | 101 TiB Ultra （12,800 MiB/秒輸送量） |
| 掛接選項 | hard,rsize=65536,wsize=65536,vers=3 注意： 使用 262144 和 65536 具有類似的效能結果 |
本節中的圖表顯示用戶端掛接選項 nconnect 的結果，以及 NFSv3。 如需詳細資訊，請參閱 Azure NetApp File 的 Linux NFS 掛接選項最佳做法。
下圖比較 nconnect 的優點與未 nconnect掛接的NFS磁碟區。 在測試中，FIO 會使用 64-KiB 循序工作負載，從美國東部 Azure 區域中的單一 E104id-v5 實例產生工作負載：已使用 256 I/0 大小，這是 Azure NetApp Files 建議的最大 I/O 大小，因此會產生可比較的效能數目。 如需詳細資訊，請參閱 rsize 和 wsize。
Linux 讀取輸送量
下圖顯示大約 10,000M iB/s 的 nconnect256-KiB 循序讀取，大約是未 nconnect達到的輸送量的十倍。
請注意，10,000 MiB/秒大約是附加至E104id_v5的 100 Gbps 網路介面卡行速率。
Linux 寫入輸送量
下圖顯示循序寫入。 使用 nconnect 可提供連續寫入 6,600 MiB/秒的可觀察優點，大約是沒有 nconnect的掛接的四倍。
Linux 讀取 IOPS
下圖顯示 ~426,000 個讀取 IOPS 的 8 KiB 隨機讀取， nconnect大約是沒有 nconnect觀察到的七倍。
Linux 寫入 IOPS
下圖顯示 ~405,000 個寫入 IOPS 的 nconnect8-KiB 隨機寫入，大約是沒有 nconnect觀察到的 7.2 倍。
