適用於 HPC PixStor 儲存的 Dell EMC Ready Solution

由 HPC 與 AI 創新實驗室的 Mario Gallegos 於 2019 年 10 月撰寫的文章

目錄

1. 簡介
   1. 解決方案架構
   2. 解決方案元件
2. 效能特性
   1. 循序 IOzone 效能 N 用戶端至 N 檔案
   2. 循序 IOR 效能 N 用戶端至 1 檔案
   3. 隨機小型區塊 IOzone 效能 N 用戶端至 N 檔案
   4. 使用空白檔案的 MDtest 中繼資料效能
   5. 使用 4 KiB 檔案的 MDtest 中繼資料效能
   6. 使用 MDtest 處理 3K 檔案的中繼資料效能
3. 進階分析
4. 結論和未來工作

簡介

解決方案架構

解決方案元件

效能特性

•     IOzone N 至 N 循序
•     IOR N 至 1 循序
•     IOzone 隨機
•     MDtest
  
  針對以上所列的所有效能指標，測試台的用戶端如下 表 2 所述。由於可用於測試的計算節點數為 16，因此當需要更高的線程數時，這些線程在計算節點上分佈均勻（即 32 個線程 = 每個節點 2 個線程，64 個線程 = 每個節點 4 個線程，128 個線程 = 每個節點 8 個線程，256 個線程 = 每個節點 16 個線程，512 個線程 = 每個節點 32 個線程， 1024 個執行緒 = 每個節點 64 個執行緒）。其目的是以有限的運算節點數量模擬數量較高的並行用戶端。由於基準測試支援大量線程，因此使用了高達 1024 的最大值（為每個測試指定），同時避免了過多的上下文切換和其他相關副作用影響性能結果。
  
  表2 用戶端試驗台

  用戶端節點數	16
  用戶端節點	C6320
  每個用戶端節點的處理器數	2 x Intel(R) Xeon(R) Gold E5-2697v4 18 核心 @ 2.30GHz
  每個用戶端節點的記憶體數	12 x 16GiB 2400 MT/s RDIMM
  BIOS	2.8.0
  作業系統核心	3.10.0-957.10.1
  GPFS 版本	5.0.3

   

  ---

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

  循序 N 用戶端至 N 檔案的效能是以 IOzone 3.487 版測量。執行的測試從單個線程到1024個線程不等。
  將可調適 GPFS 分頁集區設定為 16GiB，並使用大於該大小兩倍的檔案，將快取的影響降至最低。需要注意的是，對於 GPFS，可調設置用於緩存數據的最大內存量，而不管安裝和釋放的 RAM 量如何。另外，也需要注意的是，在先前的 Dell EMC HPC 解決方案中，大型循序傳輸的區塊大小為 1 MiB，而 GPFS 則採用 8 MiB 區塊進行格式化，因此此值會用在效能指標中以獲得最佳效能。這可能會看起來過大，且浪費太多空間，但 GPFS 會使用子區塊配置，以避免發生這種情況。在當前配置中，每個塊被細分為 256 個子塊，每個子塊 32 KiB。
  以下命令用於執行寫入和讀取的基準測試，其中 Threads 是具有所用線程數的變數（1 到 1024 以 2 的冪遞增），threadlist 是將每個線程分配到不同節點上的檔，使用輪循機制將它們均勻分佈在 16 個計算節點上。

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

  
  圖 2：  N 至 N 循序效能
  
  
  從結果中我們可以觀察到，性能隨著使用的客戶端數量而快速上升，然後達到穩定的平臺，直到達到IOzone允許的最大線程數，因此即使對於1024個併發用戶端，大檔順序性能也是穩定的。請注意，32 個執行緒的最大讀取效能為 23 GB/秒，而瓶頸很可能出在 InfiniBand EDR 介面，而 ME4 陣列仍有一些額外的效能可供使用。同樣地，請注意，最高寫入效能 16.7 是在 16 個執行緒時稍早達到的，而且與 ME4 陣列規格相比，這顯然較低。
  在這裡，重要的是要記住GPFS首選的操作模式是分散的，並且解決方案被格式化以使用它。在這種模式下，塊從一開始就以偽隨機方式分配，將數據分佈在每個 HDD 的整個表面上。雖然缺點明顯是初始時的最大效能較低，但無論在檔案系統使用了多少空間，效能都會維持不變。這與其他並行檔案系統不同，這些系統最初會使用最外部的磁軌，這些磁軌在每次旋轉時可儲存更多資料 (區段)，因此可提供最高的 HDD 效能，但是當系統使用了更多空間，內圈的磁軌在每次旋轉時能提供的資料空間便越少，導致效能降低。 
  
   

  ---

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

  循序 N 用戶端至單一共用檔案的效能是以 IOR 版本 3.3.0，加上 OpenMPI v4.0.1 輔助，在 16 個運算節點上執行效能指標測量。執行的測試從單個線程到1024個線程不等。
  將可調適 GPFS 分頁集區設定為 16GiB，並使用大於該大小兩倍的檔案，將快取的影響降至最低。這項效能指標測試使用 8 MiB 區塊，以發揮最佳效能。前面的性能測試部分對這些問題有更完整的解釋。
  以下命令用於執行寫入和讀取的基準測試，其中 Threads 是使用線程數的變數（1 到 1024 的冪為 2），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 128G 

  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 128G

  
  
  圖 3：N 比 1 順序性能
  
  從結果中我們可以觀察到，隨著使用的客戶端數量，性能再次以非常快的速度上升，然後達到讀取半穩定，寫入非常穩定的平臺，一直到此測試使用的最大線程數。因此，即使對於 1024 個併發用戶端，大型單個共享檔的順序性能也很穩定。請注意，在 16 個執行緒時，最大讀取效能為 23.7 GB/秒，而瓶頸很可能是 InfiniBand EDR 介面，而 ME4 陣列仍有一些額外的效能可供使用。此外，讀取效能從該值下降到達到約 20.5 GB/s 的平台，在 128 個執行緒時會瞬間降至 18.5 GB/s。同樣地，請注意在 16 個執行緒時會達到最大寫入效能 16.5，而這顯然低於 ME4 陣列規格。
   

  ---

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

  隨機 N 用戶端到 N 個檔案的效能是使用 IOzone 版本 3.487 測量。執行的測試從單個線程到1024個線程不等。此基準測試使用 4 個 KiB 塊來類比小塊流量。
  通過將可調 GPFS 頁面池設置為 16GiB 並使用兩倍於該大小的檔，將緩存效果降至最低。第一個效能測試區段中有更完整的解釋，說明為什麼這會影響 GPFS。
  以下命令用於在隨機 IO 模式下對寫入和讀取執行基準測試，其中 Threads 是具有所用線程數的變數（1 到 1024 的次方為 2），threadlist 是將每個線程分配到不同節點上的檔，使用輪循機制將它們均勻分佈在 16 個計算節點上。

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  圖 4：  N 至 N 個隨機效能
  
  從結果中我們可以觀察到寫入效能從接近 8.2K IOPS 的高值開始，然後穩定上升到 128 個執行緒，達到一個平台，並接近 16.2K IOPS 的最大值。另一方面，讀取性能從超過 200 IOPS 的非常小開始，並隨著使用的用戶端數量幾乎線性地提高性能（請記住，每個數據點的線程數翻倍），並在 512 個線程時達到 20.4K IOPS 的最大性能，而沒有達到最大值的跡象。但是，在當前 16 個計算節點上使用更多線程，每個節點有兩個 CPU，並且每個 CPU 有 18 個內核，則存在以下限制：沒有足夠的內核來運行最大數量的 IOzone 線程 （1024），而不會產生上下文切換 （16 x 2 x 18 = 576 個內核），這會大大限制性能。未來使用更多計算節點的測試可以檢查使用 IOzone 的 1024 個線程可以實現的隨機讀取性能，或者可以使用 IOR 來調查超過 1024 個線程的行為。
  
   

  ---

  使用空白檔案的 MDtest 中繼資料效能

  中繼資料效能是以 MDtest 版本 3.3.0，加上 OpenMPI v4.0.1 輔助，在 16 個運算節點上執行效能指標測量。執行的測試範圍從單一執行緒到 512 個執行緒。效能指標僅用於檔案 （無目錄中繼資料），取得解決方案可處理的建立、統計、讀取和移除次數。
  為了與其他 Dell EMC HPC 儲存解決方案相比，正確評估該解決方案，我們使用了選配的高需求中繼資料模組，但搭配單一 ME4024 陣列，即使是大型組態，並在這項工作中經過測試也指定為擁有兩個 ME4024。
  此高需求中繼資料模組最多可支援四個 ME4024 陣列，建議您在新增其他中繼資料模組之前，將 ME4024 陣列的數量增加到 4 個。額外的 ME4024 陣列預期會隨著每個額外的陣列線性提高中繼資料效能，但可能用於 Stat 作業 （和空檔案的讀取） 除外，由於數量非常高，CPU 在某些時候會成為瓶頸，效能也不會繼續線性增加。
  我們使用下列命令執行效能指標，其中「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

  
  由於性能結果可能會受到 IOP 總數、每個目錄的檔數和線程數的影響，因此決定將檔總數固定為 2 MiB 檔 （2^21 = 2097152），每個目錄的檔數固定為 1024，目錄數隨線程數的變化而變化 ，如表 3 所示。
  
  表 3：  目錄上檔案的 MDtest 發佈

  執行緒數目	每個執行緒的目錄數目	檔案總數
  1	2048	2,097,152
  2	1024	2,097,152
  4	512	2,097,152
  8	256	2,097,152
  16	128	2,097,152
  32	64	2,097,152
  64	32	2,097,152
  128	16	2,097,152
  256	8	2,097,152
  512	4	2,097,152
  1024	2	2,097,152

  
  
  
  
  圖 5：中繼資料效能 - 空檔案
  
  首先，請注意，選擇的刻度是以 10 為底的對數，以便比較具有幾個數量級差異的運算;否則，某些操作在法線圖上看起來像接近 0 的平線。以 2 為基數的日誌圖可能更合適，因為線程數以 2 的冪增加，但圖形看起來非常相似，人們傾向於根據 10 的冪處理和記住更好的數位。
  
  
  系統獲得了非常好的結果，Stat 和讀取操作在 64 個線程時分別以 11.2M op/s 和 4.8M op/s 達到峰值。移除作業在 16 個執行緒時達到最大 169.4K op/秒，而建立作業在 512 個執行緒時以 194.2K op/s 達到尖峰。統計和讀取作業的變化性較多，但在達到尖峰值後，統計的效能便沒有低於 3M op/s，讀取則沒有低於 2M op/s。建立與移除在達到平台後會更加穩定，且在移除時保持在 140K op/s 以上，建立時則保持在 120K op/s 以上。
   

  ---

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

  除了使用 4KiB 的小型檔案而非空白檔案之外，這項測試與先前的測試幾乎完全相同。
  我們使用下列命令執行效能指標，其中「Threads」是使用之執行緒數量的變數 (1 到 512，以二的次方增加)，而「my_hosts.$Threads」則是將每個執行緒分配到不同節點上的對應檔案，使用循環制將執行緒同質分散到 16 個運算節點上。

  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

  
  圖 6：  中繼資料效能 - 小型檔案 （4K）
  
  系統在 Stat 和移除作業方面獲得非常好的結果，分別以 7.7M op/s 和 1M op/s 達到 128 個執行緒的峰值。移除操作達到最大 37.3K op/s，建立操作則以 55.5K op/s 達到峰值，兩者皆在 512 個執行緒上。統計數據和移除操作具有更多可變性，但一旦達到峰值，性能不會低於統計數據的 4M op/s 和移除的 200K op/s。建立和讀取的變化較少，並會隨著執行緒數目增加而持續成長。
  由於這些數字適用於具有單個 ME4024 的中繼資料模組，因此每個額外的 ME4024 陣列的性能都會提高，但我們不能只假設每個操作都線性增加。除非完整檔案位於該檔案的 inode 內部，否則 ME4084 上的資料目標將用於儲存 4K 檔案，使效能有所限制。由於 inode 的大小為 4KiB，但仍需要儲存中繼資料，因此只有約 3 KiB 的檔案可裝入其中，且任何大於該大小的檔案皆會使用資料目標。
   

  ---

  使用 MDtest 處理 3K 檔案的中繼資料效能

  此測試與以前的測試幾乎完全相同，只是使用了 3KiB 的小檔。主要區別在於這些檔完全適合 inode。因此不會使用儲存節點及其 ME4084，透過僅使用 SSD 媒體進行儲存和減少網路存取來提高整體速度。
  我們使用下列命令執行效能指標，其中「Threads」是使用之執行緒數量的變數 (1 到 512，以二的次方增加)，而「my_hosts.$Threads」則是將每個執行緒分配到不同節點上的對應檔案，使用循環制將執行緒同質分散到 16 個運算節點上。

  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 3K -e 3K

   

  
  圖 7：中繼資料效能 - 小型檔案 （3K）
  
  系統在 Stat 和讀取操作方面獲得非常好的結果，分別以 8.29M op/s 和 5.06M op/s 達到 256 個線程的峰值。移除作業在 128 個執行緒時達到最大 609K op/秒，而建立作業在 512 個執行緒時達到 78K op/s 的峰值。統計資訊和讀取操作比創建和刪除操作具有更大的可變性。刪除會導致兩個較高線程點的性能略有下降，這表明 128 個線程后的持續性能將略高於 400K op/s。建立持續增加最多 512 個執行緒，但看起來正在達到一個穩定期，因此最大效能可能仍低於 100K op/s。
  由於此類小檔完全存儲在基於 SSD 的元數據模組上，因此需要卓越小檔性能的應用程式可以使用一個或多個可選的高要求元數據模組來提高小檔性能。但是，按照當前標準，適合 inode 的檔很小。此外，由於中繼資料目標使用的 RAID1 固態硬碟相對較小 （最大大小為 19.2 TB），因此與儲存節點相比，容量會受到限制。因此，必須注意避免填滿元數據目標，這可能會導致不必要的故障和其他問題。
   

  ---

  進階分析

  在 PixStor 功能中，通過高級分析監控文件系統對於大大簡化管理至關重要，有助於主動或被動地發現問題或潛在問題。接下來，我們將簡要回顧其中的一些功能。
  圖 8 顯示了基於文件系統容量的有用資訊。左側是已使用的檔案系統總空間，以及根據使用的檔案系統容量排名前十的使用者。在右側，一個歷史視圖，其中包含多年來使用的容量，然後是使用的十大檔類型和前十個檔集，兩者都基於使用的容量，格式類似於帕累托圖表（沒有累積總計的行）。有了這些資訊，就很容易發現使用者獲得的不僅僅是他們在文件系統中的公平份額、容量使用趨勢，以協助做出有關未來容量增長的決策、哪些檔佔用了大部分空間或哪些專案佔用了大部分容量。
  
  
  圖 8：  PixStor 分析 - 容量視圖
  
  圖 9 提供了一個檔計數檢視，其中包含兩種非常有用的問題查找方法。螢幕的前半部分包含餅圖中的前十名使用者，前十名檔類型和前十名檔集（想想專案），格式類似於帕累托圖（沒有累積總數的線條），所有這些都基於文件數。此資訊可用於回答一些重要問題。例如，哪些使用者通過創建太多檔來獨佔文件系統，哪種類型的檔正在創建元數據噩夢，或者哪些專案正在使用大部分資源。
  下半部分有一個直方圖，其中包含檔大小的文件數量（頻率），使用 5 個不同檔大小的類別。這可用於瞭解整個文件系統中使用的檔大小，這些檔大小與檔類型相協調，可用於確定壓縮是否有益。
  
  
  圖 9：  PixStor 分析 - 檔案計數檢視

  
  
   

  ---

  結論和未來工作

  當前的解決方案能夠提供相當好的性能，無論使用空間如何（因為系統是以分散模式格式化的），預計性能都是穩定的，如 表 4 所示。此外，隨著新增更多儲存節點模組，解決方案的容量和效能也會以線性增長，而選用的高需求中繼資料模組預期也能提供類似的效能提升。此解決方案可為 HPC 客戶提供非常可靠的平行檔案系統，許多前 500 大 HPC 叢集皆正在使用。此外，它還提供卓越的搜索功能、高級監控和管理，並添加可選閘道，允許通過 NFS、SMB 等無處不在的標準協定與任意數量的用戶端共用檔。
  
  表4  尖峰與持續效能
  
   

  	尖峰效能		持續效能
  	寫入	讀取	寫入	讀取
  大型循序 N 用戶端至 N 檔案	16.7 GB/秒	23 GB/秒	16.5 GB/秒	20.5 GB/秒
  大型循序 N 用戶端至單一共用檔案	16.5 GB/秒	23.8 GB/s	16.2 GB/秒	20.5 GB/秒
  隨機小型區塊 N 用戶端至 N 檔案	15.8KIOps	20.4KIOps	15.7 KIOps	20.4KIOps
  中繼資料建立空白檔案	169.4K IOps		127.2K IOps
  中繼資料統計空白檔案	11.2M IOps		3.3 M IOps
  中繼資料讀取空白檔案	4.8M IOps		2.4M IOps
  中繼資料移除空白檔案	194.2K IOps		144.8K IOps
  中繼資料建立 4KiB 檔案	55.4K IOps		55.4K IOps
  中繼資料統計 4KiB 檔案	6.4M IOps		4M IOps
  中繼資料讀取 4KiB 檔案	37.3K IOps		37.3K IOps
  中繼資料移除 4KiB 檔案	1M IOps		219.5K IOps

  
  
  由於解決方案的設計是搭配 Cascade Lake CPU 和更快速的 RAM 一起推出，因此一旦系統擁有最終組態，也會進行一些效能檢查。同時也需要測試選用高需求中繼資料模組，至少搭載 2 個 ME4024 和 4KiB 檔案，以更清楚地記錄在涉及資料目標時，中繼資料效能的擴充方式。此外也會測量閘道節點的效能，並將相關的檢查結果報告在新部落格或白皮書中。最後，我們計劃針對更多解決方案元件進行測試和發佈，以提供更多功能。

  ---