適用於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、讀取與寫入、基準而不快取
在此基準基準基準中，測試示範 Azure NetApp Files 一般磁碟區可以處理大約 3,600 MiB/秒的純循序 64-KiB 讀取，以及大約 2,400 MiB/秒的純循序 64-KiB 寫入。 在測試期間，50/50 混合顯示與純循序讀取工作負載相等的總輸送量。
至於純讀，64-KiB 基準的表現略高於 256-KiB 基準。 不過，當談到純寫入和所有混合讀取/寫入工作負載時，256-KiB 基準的表現優於 64 KiB，表示較大的區塊大小為 256 KiB 對於高輸送量工作負載而言，整體效率更高。
工作負載的讀寫混合會針對每個執行調整 25%。
結果：256 KiB 循序 I/O 而不快取
在下列兩個基準基準檢驗中，FIO 用來測量 Azure NetApp Files 中單一一般磁碟區可以傳遞的循序 I/O 數量（讀取和寫入）。 為了產生反映完全未快取讀取工作負載可達到之真實頻寬的基準，FIO 已設定為使用 參數 randrepeat=0 執行以產生數據集。 每個測試反覆專案都是藉由讀取完全獨立的大型數據集而非基準檢驗的一部分來抵消，以便清除基準檢驗數據集可能發生的任何快取。
在此圖表中，測試顯示 Azure NetApp Files 一般磁碟區可以處理大約 3,500 MiB/秒的純循序 256-KiB 讀取，以及大約 2,500 MiB/秒的純循序 256-KiB 寫入。 在測試期間，50/50 混合顯示總輸送量尖峰高於純循序讀取工作負載。
平行網路連線 （nconnect）
下列測試顯示使用具有 64-KiB 隨機工作負載的單一用戶端和 1 TiB 數據集的高 I/OP 效能評定。 產生的工作負載混合每次都會使用不同的 I/O 深度。 為了提升單一用戶端工作負載的效能，相較於未使用nconnect掛接選項的用戶端掛接，nconnect會利用掛接選項來提升平行處理原則。 這些測試只會在排除快取時執行。
結果：64KiB 循序 I/O、讀取輸送量快取比較
為了示範快取如何影響效能結果，FIO 用於下列微基準比較中，以測量 Azure NetApp Files 中單一一般磁碟區可以傳遞的循序 I/O 數量（讀取和寫入）。 這項測試與部分可快取工作負載可能提供的優點形成對比。
在沒有快取的結果中，測試的設計目的是要降低任何快取發生，如上述基準基準檢驗中所述。
在其他結果中，FIO 會針對沒有 參數的 randrepeat=0 Azure NetApp Files 一般磁碟區使用，並使用迴圈測試反覆專案邏輯來緩慢填入快取一段時間。 這些因素的組合會產生不確定的快取量，從而提升整體輸送量。 此設定導致整體讀取效能數位比測試執行而沒有快取時略好。
圖形中顯示的測試結果會顯示與 讀取效能的並存比較，而且沒有快取影響，其中快取會產生高達 ~4500 MiB/秒的讀取輸送量，而快取則達到約 3600 MiB/秒。
並存比較（含和不含 nconnect）
下圖顯示與 64 KiB 循序讀取和寫入的並存比較，而不 nconnect 用強調使用 nconnect時所看到的效能改善：整體輸送量較高、延遲較低。
