針對以上列出的所有效能指標，測試台的用戶端組態如下表 2 所述。由於可供測試的運算節點數目只有 16 個，當需要更高的執行緒數量時，這些執行緒會平均分佈在運算節點上 (例如 32 個執行緒 = 每個節點 2 個執行緒、64 個執行緒 = 每個節點 4 個執行緒、128 個執行緒 = 每個節點 8 個執行緒、256 個執行緒 = 每個節點 16 個執行緒、512 個執行緒 = 每個節點 32 個執行緒，1024 個執行緒 = 每個節點 64 個執行緒)。其目的是以有限的可用運算節點數量模擬數量較高的並行用戶端。由於某些效能指標支援大量的執行緒，因此使用的最大值達 1024 (針對每個測試指定)，同時避免因產生過多的背景關係交換和其他相關副作用，進而影響效能結果。

表 2 用戶端測試台

循序 IOzone 效能 N 用戶端至 N 檔案

循序 N 用戶端至 N 檔案的效能是以 IOzone 3.487 版測量。執行的測試範圍從單一執行緒到 1024 個執行緒，以二的次方增加。

將可調適 GPFS 分頁集區設定為 16 GiB，並使用大於該大小兩倍的檔案，將快取對伺服器的影響降至最低。請務必注意，GPFS 會將快取資料可調適設定為使用最大記憶體使用量，無論已安裝和可用的 RAM 數量為何。此外亦請注意，在先前的 Dell EMC HPC 解決方案中，大型循序傳輸的區塊大小為 1 MiB，而 GPFS 格式化為 8 MiB 區塊，因此效能指標會使用該值來達到最佳效能。這可能會看起來過大，且浪費太多空間，但 GPFS 會使用子區塊配置，以避免發生這種情況。在目前的設定中，每個區塊被細分為 256 個且每個 32 KiB 的子區塊。

我們使用下列命令執行寫入與讀取的效能指標，其中「$Threads」是使用之執行緒數量的變數 (1 到 1024，以二的次方增加)，而「threadlist」則是將每個執行緒分配到不同節點上的檔案，使用循環制將執行緒同質分散到 16 個運算節點上。

為了避免用戶端可能產生的任何資料快取影響，所使用的檔案總資料大小為用戶端所用 RAM 總量的兩倍。也就是說，由於每個用戶端都有 128 GiB 的 RAM，當執行緒等於或超過 16 個執行緒時，檔案大小為 4096 GiB 除以執行緒數目 (以下變數 $Size 用於管理該值)。當執行緒少於 16 時 (代表每個執行緒都在不同的用戶端上運行)，檔案的大小固定為每個用戶端記憶體總量的兩倍，或 256 GiB。

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

圖 2 N 至 N 循序效能

從結果中，我們能觀察到寫入效能會隨著使用的執行緒數目提高，然後達到寫入約為 64 個執行緒，讀取約為 128 個執行緒的穩定水平。接著，讀取效能也會隨著執行緒數目的提高而快速上升，然後保持穩定，直到達到 IOzone 允許的最大執行緒數目，因此即使在 1024 個並行用戶端下，大型文件的循序效能也是穩定的。寫入效能在 1024 個執行緒時會下降約 10%。但是，由於用戶端叢集數目少於核心數，因此無法確定效能下降是否由交換所導致，在傳統儲存媒體中並未觀察到類似的額外負載 (因為相較於傳統儲存媒體，NVMe 的延遲非常低)，亦無法判斷 RAID 10 資料同步機制是否導致此瓶頸。需要更多用戶端才能釐清此問題。在 64 個執行緒時觀察到讀取異常，其中效能的擴張速率不如前一個資料點所觀察到的速率，但在下一個資料點又移動到非常接近持續效能的值。需要更多的測試來找到此異常的原因，但這超出了本部落格的討論範圍。

讀取的最大讀取效能低於 NVMe 裝置的理論效能 (~102 GB/s) 或 EDR 連結的效能，即使假設有一個連結主要用於NVMe over fabric 流量 (4x EDR BW ~96 GB/s) 亦是如此。
不過這並不令人意外，因為在硬體組態中，每個 NVMe 裝置和各 CPU 插槽的 IB HCA 不平衡。其中一張 CX6 配接卡位於 CPU1 下，而 CPU2 下則設定了所有 NVMe 裝置和第二個 CX6 配接卡。所有使用第一個 HCA 的儲存流量，都必須使用 UPI 來存取 NVMe 裝置。此外，CPU1 所使用的任何核心都必須存取指派給 CPU2 的裝置或記憶體，因此資料位置會受到影響，且會使用 UPI 連結。這可以解釋相較於 NVMe 裝置的最大效能或 CX6 HCA 的管道速度，最大效能有所降低的原因。修正此限制的替代方案是使用更平衡的硬體組態，也就是使用具有四個 x16 插槽的 R740，搭配兩個 x16 PCIe 擴充板，將 NVMe 裝置平均分配至兩個 CPU 上，並在每個 CPU 下各安裝一個 CX6 HCA，將密度降低一半。

循序 IOR 效能 N 用戶端至 1 檔案

循序 N 用戶端至單一共用檔案的效能是以 IOR 版本 3.3.0，加上 OpenMPI v4.0.1 輔助，在 16 個運算節點上執行效能指標測量。執行的測試範圍從單一執行緒到 512 個執行緒，因為沒有足夠的核心可容納 1024 或更多執行緒。這項效能指標測試使用 8 MiB 區塊，以發揮最佳效能。之前的效能測試部分，針對為什麼這很重要有更完整的解釋。

將可調適 GPFS 分頁集區設定為 16 GiB，並使用總檔案大小為用戶端所用 RAM 總量兩倍的檔案，將資料快取的影響降至最低。也就是說，由於每個用戶端都有 128 GiB 的 RAM，當執行緒等於或超過 16 個執行緒時，檔案大小為 4096 GiB，並將等同此總數的總量除以執行緒數目 (以下變數 $Size 用於管理該值)。當執行緒少於 16 時 (代表每個執行緒都在不同的用戶端上運行)，檔案的大小為每個用戶端所用記憶體總量的兩倍乘以執行緒數目，也就是要求每個執行緒使用 256 GiB。

我們使用下列命令執行寫入與讀取的效能指標，其中「$Threads」是使用之執行緒數量的變數 (1 到 1024，以二的次方增加)，而「my_hosts.$Threads」則是將每個執行緒分配到不同節點上的對應檔案，使用循環制將執行緒同質分散到 16 個運算節點上。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

圖 3 N 至 1 循序效能

從結果中我們可以觀察到，由於所有執行緒都存取同一個檔案 (無論這是否隱含需要鎖定機制)，讀取和寫入效能都很高。相同地，效能隨著所使用的執行緒數目快速提升，接著維持在相對穩定讀取和寫入的狀態，直到達到此測試所使用的最多執行緒數目。值得注意的是，最大讀取效能在 512 個執行緒時為 51.6 GB/秒，但在約 64 個執行緒時達到穩定效能高點。同樣地，我們注意到最大寫入效能是在 16 個執行緒時達到 34.5 GB/s，且可觀察到會維持在穩定的高點，直到達到使用的最大執行緒數目為止。

隨機小型區塊 IOzone 效能 N 用戶端至 N 檔案

隨機 N 用戶端至 N 檔案的效能是以 IOzone 3.487 版測量。執行的測試範圍從單一執行緒到 1024 個執行緒，以二的次方增加。

執行的測試範圍從單一執行緒到 512 個執行緒，因為沒有足夠的用戶端核心可容納 1024 個執行緒。每個執行緒都使用不同的檔案，執行緒以循環制指派到用戶端節點。這項效能指標測試使用 4 KiB 區塊來模擬小型區塊流量，並使用 16 的佇列深度。比較大型解決方案和容量擴充的結果。

將可調適 GPFS 分頁集區設定為 16 GiB，以將快取的影響降至最低，並為了避免用戶端可能產生的任何資料快取影響，檔案總資料大小為用戶端所用 RAM 總量的兩倍。也就是說，由於每個用戶端都有 128 GiB 的 RAM，當執行緒等於或超過 16 個執行緒時，檔案大小為 4096 GiB 除以執行緒數目 (以下變數 $Size 用於管理該值)。當執行緒少於 16 時 (代表每個執行緒都在不同的用戶端上運行)，檔案的大小固定為每個用戶端記憶體總量的兩倍，或 256 GiB。

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Create the files sequentially
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Perform the random reads and writes.

圖 4 N 至 N 隨機效能

從結果中我們可以觀察到，寫入效能以 6K IOps 的高數值開始，並穩定上升至 1024 個執行緒，如果可以使用更多執行緒，似乎可超過 5M IOPS 的穩定水平。另一方面，讀取效能從 5K IOPS 開始，根據使用的執行緒數量穩定提升效能 (請記住，每個資料點的執行緒數目都會加倍)，並在 1024 個執行緒時達到 7.3M IOPS 的最大效能，且尚未出現趨於平穩的跡象。使用更多執行緒會需要超過 16 個運算節點，以避免資源不足和過多的交換導致效能降低，讓 NVMe 節點能維持效能。

使用 4 KiB 檔案的 MDtest 中繼資料效能

中繼資料效能是以 MDtest 版本 3.3.0，加上 OpenMPI v4.0.1 輔助，在 16 個運算節點上執行效能指標測量。執行的測試範圍從單一執行緒到 512 個執行緒。效能指標僅用於檔案 (無目錄中繼資料)，測試解決方案可處理的建立、統計數據、讀取和移除數量，並將結果與大型解決方案對比。

選用高需求中繼資料模組，但使用單一 ME4024 陣列時，即使是大型組態和此工作的測試組態均設計為搭載兩個 ME4024。使用該中繼資料模組的原因是，目前這些 NVMe 節點作為僅資料的儲存裝置目標使用。不過，節點可用來儲存資料和中繼資料，甚至在有極端的中繼資料需求時，可作為快閃式記憶體方案，來替代高需求中繼資料模組。在這次的工作中，並未對這些設定進行測試。

由於相同的高需求中繼資料模組曾用於先前的適用於 HPC PixStor 儲存的 DellEMC Ready Solution 解決方案，中繼資料的結果會與先前的部落格結果相當類似。出於此原因，本次沒有進行空白檔案的研究，而是使用了 4 KiB 的檔案。由於 4 KiB 檔案無法連同中繼資料資訊放入 inode，因此將使用 NVMe 節點儲存每個檔案的資料。因此，透過 MDtest 能稍微瞭解讀取和其他中繼資料操作的小型檔案效能。

我們使用下列命令執行效能指標，其中「$Threads」是使用之執行緒數量的變數 (1 到 512，以二的次方增加)，而「my_hosts.$Threads」則是將每個執行緒分配到不同節點上的對應檔案，使用循環制將執行緒同質分散到 16 個運算節點上。與隨機 IO 效能指標類似，執行緒的最大數量限制為 512 個，因為沒有足夠的核心可處理 1024 個執行緒，而背景關係交換可能會影響結果，使得報告的數目比解決方案的實際效能低。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

由於效能結果可能會受到 IOPS 總數、每個目錄的檔案數量和執行緒數目的影響，因此決定將檔案總數固定為 2 MiB 檔案 (2^21 = 2097152)、每個目錄的檔案數量固定為 1024，以及目錄數量會隨著表 3 所示的執行緒數量而變更。

表 3 目錄上檔案的 MDtest 分佈

圖 5 中繼資料效能 – 4 KiB 檔案

首先請注意，所選擇的規模是以基數為 10 的對數，以比較幾個數量級的作業差異，否則部分作業在線性尺度上看起來會是一條接近 0 的直線。基數為 2 的記錄圖表可能更適合，因為執行緒數目是以 2 的次方增加，但圖形看起來會非常類似，而且人們往往比較容易理解與記住 10 的倍數。

系統在先前回報的統計作業中獲得很好的結果，在 64 個執行緒時達到近 6.9M op/s 的高峰值，然後在更高的執行緒數目時降低，並趨為平穩。建立作業在 512 個執行緒時達到最大值 113K，若使用更多用戶端節點 (與核心)，預期效能可持續增加。讀取和移除作業在 128 個執行緒時達到高峰，讀取達到接近 705K op/s，移除達到 370K op/s，然後趨為平穩。統計作業的變化性較多，但在達到尖峰值後，統計的效能便沒有低於 3.2M op/s。建立與移除作業在到達穩定後便能持續保持，移除作業可維持在 265K op/s 以上，建立作業則保持在 113K op/s 以上。最後，讀取達到穩定，效能可超過 265K op/s。

結論和未來工作

NVMe 節點是 HPC 儲存解決方案的重要額外功能，可提供極高效能的儲存層，具有良好的密度、極高的隨機存取效能，以及極高的循序效能。此外，隨著新增更多 NVMe 節點模組，解決方案的容量和效能皆可線性擴充。表 4 提供 NVMe 節點的效能概覽，效能預期會保持穩定，而且這些值可用來預估不同 NVMe 節點數目的效能。
但請注意，每對 NVMe 節點僅能提供表 4 所示數值的一半。
此解決方案可為 HPC 客戶提供非常可靠的平行檔案系統，許多前 500 大 HPC 叢集皆正在使用。此外，還提供卓越的搜尋功能、進階的監控和管理，以及可新增選用閘道，透過用戶端所需要的 NFS、SMB 等各種普遍標準通訊協定共用檔案。

表 4 2 對 NVMe 節點的尖峰和持續效能

由於 NVMe 節點僅用於資料，因此日後可能的工作包括將其用於資料和中繼資料，並可形成獨立的快閃式記憶體層與更佳的中繼資料效能，因為相較於 RAID 控制器後的 SAS3 SSD，NVMe 裝置具備更高的頻寬和更低的延遲。或者，如果客戶的中繼資料需求極高，且需要比高需求中繼資料模組所能提供還更密集的解決方案，則可將部分或全部的分散式 RAID 10 裝置用於中繼資料，其使用方式與現在在 ME4024s 上的 RAID 1 裝置相同。
即將發佈的另一篇部落格將討論 PixStor Gateway 節點，該節點可允許使用 NFS 或 SMB 通訊協定，將 PixStor 解決方案連接至其他網路，並支援效能橫向擴充。此外，該解決方案很快即會更新到 HDR100，將有另一篇部落格討論相關內容。