適用於Linux的 Azure NetApp Files 一般磁碟區效能基準檢驗
本文說明 Azure NetApp Files 為 Linux 提供一般磁碟區的效能效能評定。
整個檔案串流工作負載 （向外延展效能評定測試）
向外延展測試的目的是在向外延展時顯示 Azure NetApp File 磁碟區的效能（或增加）產生相同磁碟區同時工作負載的用戶端數目。 這些測試通常能夠將磁碟區推送至其效能限制的邊緣，並指出工作負載，例如媒體轉譯、AI/ML 和其他利用大型計算伺服器數位來執行工作的工作負載。
高 I/OP 向外延展效能評定設定
這些基準檢驗使用下列專案：
- 單一 Azure NetApp Files 100-TiB 一般磁碟區，具有使用 Ultra 效能層級的 1 TiB 數據集
- FIO （不含設定 randrepeat=0）
- 4-KiB 和 8-KiB 區塊大小
- 6 D32s_v5執行 RHEL 9.3 的虛擬機
- NFSv3
- 手動 QoS
- 掛接選項：rw，nconnect=8，hard，rsize=262144，wsize=262144，vers=3，tcp，bg
高輸送量向外延展效能評定設定
這些基準檢驗使用下列專案：
- 單一 Azure NetApp Files 一般磁碟區，具有使用 Ultra 效能層級 FIO 的 1 TiB 數據集（若沒有設定 randrepeat=0）
- FIO （不含設定 randrepeat=0）
- 64-KiB 和 256-KiB 區塊大小
- 6 D32s_v5執行 RHEL 9.3 的虛擬機
- NFSv3
- 手動 QoS
- 掛接選項：rw，nconnect=8，hard，rsize=262144，wsize=262144，vers=3，tcp，bg
平行網路連線 （nconnect） 基準檢驗設定
這些基準檢驗使用下列專案：
- 使用 Ultra 效能層級搭配 1 TiB 數據集的單一 Azure NetApp Files 一般磁碟區
- FIO （不含設定 randrepeat=0）
- 4-KiB 和 64-KiB wsize/rsize
- 執行 RHEL 9.3 的單一D32s_v4虛擬機
- NFSv3 與 不含
nconnect - 掛接選項：rw，nconnect=8，hard，rsize=262144，wsize=262144，vers=3，tcp，bg
相應增加基準檢驗
相應增加測試的意圖是在相應增加 （或增加） 單一用戶端上的多個 TCP 連線上同時產生工作負載的作業數目，以顯示 Azure NetApp File 磁碟區的效能（例如 使用 nconnect）。
如果沒有 nconnect，這些工作負載就無法推送磁碟區最大效能的限制，因為客戶端無法產生足夠的 IO 或網路輸送量。 這些測試通常表示單一用戶體驗可能位於工作負載中，例如媒體轉譯、資料庫、AI/ML 和一般檔案共用。
高 I/OP 向外延展基準
下列基準檢驗顯示使用高 I/OP 工作負載的 Azure NetApp Files 所達到的效能：
- 32 個用戶端
- 4-KiB 和 8-KiB 隨機讀取和寫入
- 1-TiB 數據集
- 讀取/寫入比率如下：100%：0%、90%：10%、80%：20%等等
- 涉及與不使用檔案系統快取 （在 FIO 中使用
randrepeat=0）
如需詳細資訊，請參閱 測試方法。
結果：包含 4 KiB、隨機、用戶端快取
在此基準檢驗中，FIO 在沒有隨機化數據的選項的情況下 randrepeat 執行。 因此，無法確定的快取量正在發揮作用。 此組態會產生比測試執行的整體效能數位稍微好一些，而不會使用整個 IO 堆疊進行快取。
在下圖中，測試顯示 Azure NetApp Files 一般磁碟區可處理大約 130,000 個純隨機 4 KiB 寫入，以及此基準檢驗期間約 460,000 個純隨機 4 KiB 讀取。 針對每個執行調整 10% 的工作負載讀寫混合。
當讀寫 I/OP 混合增加至大量寫入時，I/OPS 總數會減少。
結果：4 KiB、隨機、用戶端快取已排除
在此效能評定中，FIO 是以隨機化數據的設定 randrepeat=0 來執行，可降低對效能的快取影響。 這會導致寫入 I/OPS 減少約 8%，讀取 I/OPS 減少約 17%，但顯示效能數位更能代表記憶體實際執行的動作。
在下圖中，測試顯示 Azure NetApp Files 一般磁碟區可以處理大約 120,000 個純隨機 4-KiB 寫入，以及大約 388,000 個純隨機 4-KiB 讀取。 針對每個執行調整為 25% 的工作負載讀寫混合。
當讀寫 I/OP 混合增加至大量寫入時，I/OPS 總數會減少。
結果：8 KiB、隨機、用戶端快取已排除
較大的讀取和寫入大小會導致 I/OPS 總數減少，因為每個作業可以傳送更多數據。 8-KiB 讀取和寫入大小可用來更準確地模擬大多數新式應用程式使用的內容。 例如，許多EDA 應用程式會利用8-KiB的讀取和寫入。
在此基準中，FIO 會執行 randrepeat=0 來隨機化數據，以便降低用戶端快取影響。 在下圖中，測試顯示 Azure NetApp Files 一般磁碟區可以處理大約 111,000 個純隨機 8 KiB 寫入，以及大約 293,000 個純隨機 8-KiB 讀取。 針對每個執行調整為 25% 的工作負載讀寫混合。
當讀寫 I/OP 混合增加至大量寫入時，I/OPS 總數會減少。
並存比較
為了說明快取如何影響效能效能評定測試，下圖顯示 4 KiB 測試的 I/OPS 總數，且不需要有快取機制。 如圖所示，快取可為 I/OPS 提供相當一致趨勢的輕微效能提升。
特定位移、串流隨機讀取/寫入工作負載：使用平行網路連線相應增加測試 （nconnect）
下列測試顯示使用單一用戶端搭配 4 KiB 隨機工作負載和 1 TiB 數據集的高 I/OP 效能評定。 產生的工作負載混合每次都會使用不同的 I/O 深度。 為了提升單一用戶端工作負載的效能， nconnect 掛接選項 可用來改善與沒有 nconnect 掛接選項的用戶端掛接相比的平行處理原則。
使用只提供記憶體單一路徑的標準 TCP 連線時，每秒傳送的作業總數會比掛接能夠利用每個裝入點更多的 TCP 連線（例如 使用 nconnect）時少。 使用 nconnect時，作業的總延遲通常會較低。 這些測試也會搭配 執行 randrepeat=0 ，以刻意避免快取。 如需此選項的詳細資訊，請參閱 測試方法。
結果：4 KiB，隨機，不含 nconnect，並排除快取
下圖顯示與 4 KiB 讀取和寫入的並存比較，而不 nconnect 使用 來反白顯示使用 nconnect時看到的效能改善：整體 I/OPS 較高、延遲較低。
高輸送量基準檢驗
下列基準檢驗顯示針對具有高輸送量工作負載的 Azure NetApp Files 所達成的效能。
高輸送量工作負載在本質上比較循序，而且通常具有低元數據的讀取/寫入繁重。 輸送量通常比 I/OPS 更重要。 這些工作負載通常會利用較大的讀取/寫入大小（64K 到 256K），這會產生比較小的讀取/寫入大小更高的延遲，因為較大的承載自然需要較長的時間才能處理。
高輸送量工作負載的範例包括：
- 媒體存放庫
- 高效能計算
- AI/ML/LLP
下列測試顯示使用 64-KiB 和 256-KiB 循序工作負載和 1 TiB 數據集的高輸送量基準檢驗。 產生的工作負載混合會一次減少一個設定的百分比，並示範在使用不同讀取/寫入比率時可以預期的情況（例如，100%：0%、90%：10%、80%：20%等等）。
結果：64 KiB 循序 I/O，包含快取
在此效能評定中，FIO 會使用循環邏輯執行，以更積極地填入快取，因此不確定的快取數量會影響結果。 這會導致整體效能數位略高於測試執行而不快取。
在下圖中，測試顯示 Azure NetApp Files 一般磁碟區可以處理大約 4,500MiB/秒的純循序 64-KiB 讀取，以及大約 1,600MiB/秒的純循序 64-KiB 寫入。 工作負載的讀寫混合會針對每個執行調整 10%。
結果：64 KiB 循序 I/O，已排除快取
在此基準中，FIO 會使用較不積極填入快取的循環邏輯執行。 用戶端快取不會影響結果。 此設定會產生稍微更好的寫入效能數位，但讀取數目比測試低，而不需要快取。
在下圖中，測試示範 Azure NetApp Files 一般磁碟區可以處理大約 3,600MiB/秒的純循序 64-KiB 讀取，以及大約 2,400MiB/秒的純循序 64-KiB 寫入。 在測試期間，50/50 混合顯示與純循序讀取工作負載相等的總輸送量。
工作負載的讀寫混合會針對每個執行調整 25%。
結果：256 KiB 循序 I/O，已排除快取
在此效能評定中，FIO 使用較不積極填入快取的循環邏輯執行，因此快取不會影響結果。 此設定會導致寫入效能數位略低於 64-KiB 測試，但讀取數目高於執行相同的 64 KiB 測試，而不會快取。
在下圖中，測試顯示 Azure NetApp Files 一般磁碟區可以處理大約 3,500MiB/秒的純循序 256-KiB 讀取，以及大約 2,500MiB/秒的純循序 256-KiB 寫入。 在測試期間，50/50 混合顯示總輸送量尖峰高於純循序讀取工作負載。
工作負載的讀寫混合會針對每個執行調整 25% 的增量。
並存比較
為了更清楚地說明快取如何影響效能基準測試，下圖顯示 64-KiB 測試的 MiB/秒總計，且不需要快取機制。 快取提供MiB/秒總計的初始輕微效能提升，因為快取通常比寫入更能改善讀取。 當讀取/寫入混合變更時，不快取的總輸送量超過使用用戶端快取的結果。
平行網路連線 （nconnect）
下列測試顯示使用具有 64-KiB 隨機工作負載的單一用戶端和 1 TiB 數據集的高 I/OP 效能評定。 產生的工作負載混合每次都會使用不同的 I/O 深度。 為了提升單一用戶端工作負載的效能，相較於未使用nconnect掛接選項的用戶端掛接，nconnect會利用掛接選項來提升平行處理原則。 這些測試只會在排除快取時執行。
結果：64 KiB、循序快取、不含 nconnect
下列結果顯示當在單一用戶端上以 4-KiB 區塊讀取和寫入 NFSv3 掛接時，且不需要平行處理作業時nconnect，相應增加測試的結果。 圖表顯示，隨著 I/O 深度的成長，I/OPS 也會增加。 但是，使用只提供記憶體單一路徑的標準 TCP 連線時，每秒傳送的作業總數會比掛接能夠利用每個裝入點更多的 TCP 連線時少。 此外，使用 nconnect時作業的總延遲通常會較低。
並存比較（含和不含 nconnect）
下圖顯示與 64 KiB 循序讀取和寫入的並存比較，而不 nconnect 用強調使用 nconnect時所看到的效能改善：整體輸送量較高、延遲較低。
