適用於 HPC PixStor 儲存的 Dell EMC Ready Solution - 容量擴充
Summary: 適用於 HPC PixStor 儲存的 Dell EMC Ready Solution - 容量擴充
Symptoms
由 HPC 與 AI 創新實驗室的 Mario 自格列格索于 2020 年 4 月撰寫
Cause
Resolution
目錄
- 簡介
- 解決方案架構
- 解決方案元件
- 效能特性
- 順序 IOne Performance N 用戶端至 N 檔案
- 順序 IOR Performance N 用戶端至 1 個檔案
- 隨機小型區塊 IOne Performance N 用戶端至 N 檔案
- 使用空檔案使用 MDtest 的中繼資料效能
- 使用 4 個 KiB 檔案使用 MDtest 的中繼資料效能
- 結論和未來工作
簡介
現今的 HPC 環境對超高速儲存的需求與日新月增，也經常需要透過 NFS、SMB 和其他數種標準通訊協定進行高容量和分散式存取。這些高需求 HPC 需求通常涵蓋于平行檔案系統，這些系統可提供來自多個節點的單一檔案或一組檔案的平行存取權，且非常有效率且安全地在多個伺服器上將資料分配給多個 LUN。解決方案架構
此部落格是適用于 HPC 環境的連續平行檔案系統 （PFS） 解決方案， HPC PixStor 儲存裝置適用的 DellEMC 就緒解決方案， 其中使用 PowerVault ME484 EBOD 陣列來增加解決方案的容量。圖 1 提供標示現有 PowerVault ME4084 儲存陣列容量擴充 SAS 新增功能的參考架構。PixStor 解決方案包含廣泛的一般平行檔案系統 （又稱為頻譜擴充） 作為 PFS 元件，此外還有許多其他的 Arcastream 軟體元件，例如進階分析、簡化的管理與監控、高效率的檔案搜尋、進階閘道功能等等。
圖 1：參考架構。
解決方案元件
此解決方案計畫搭配最新的 Intel Xeon 第 2 代可擴充 Xeon CPU （又稱 Cascade Lake CPU） 發佈，部分伺服器將使用他們可用的最快 RAM （2933 MT/秒）。然而，由於目前可用的硬體可在解決方案的原型上執行，以描繪效能的特性，因此搭載 Intel Xeon 第 1 代可擴充 Xeon CPU 的伺服器。又稱 a.Skylake 處理器和在某些情況下較慢的 RAM 是用來表示此系統的特性。由於解決方案的瓶頸位於 DellEMC PowerVault ME40x4 陣列的 SAS 控制器中，一旦 Skylake CPU 和 RAM 更換為預期的 Cascade Lake CPU 和更快速的 RAM，則預期不會出現顯著的效能差異。此外，解決方案已更新至支援 RHEL 7.7 和 OFED 4.7 以標示系統的 PixStor （5.1.1.4） 最新版本。由於先前所述的情況，表 1 具有解決方案的主要元件清單，但在出現差異時，第一個說明欄的元件會在發佈時間使用，因此可供客戶使用，最後一欄是用於描述解決方案效能的元件。列出用於資料 （12TB NLS） 和中繼資料 （960Gb SSD） 的磁片磁碟機用於效能特性，而較快速的磁片磁碟機可提供更好的隨機 IOP，並改善建立/移除中繼資料作業。
最後，為了達到完整性，系統會根據線上提供的 DellEMC PowerVault ME4 支援表格中所列舉的磁片磁碟機，列出可能的資料 HDD 和中繼資料 SSD。
表 1 發佈時使用的元件和測試表中使用的元件
| 解決方案元件 |
發行時 |
測試台 |
|
| 內部連線能力 |
Dell Networking S3048-ON Gigabit 乙太網路 |
||
| 資料儲存子系統 |
1 個至 4 個 Dell EMC PowerVault ME4084 1 個至 4 個 Dell EMC PowerVault ME484 （每個 ME4084 一個） |
||
| 選配的高需求中繼資料儲存子系統 |
1 個至 2 個 Dell EMC PowerVault ME4024 （4 個 ME4024 ，僅限大型組態） |
||
| RAID 儲存控制器 |
12 Gbps SAS |
||
| 已設定的容量 |
原始：8064 TB （7334 TiB 或 7.16 PiB） 格式化至 6144 GB （5588 TiB 或 5.46 PiB） |
||
| 處理器 |
閘道 |
2 個 Intel Xeon 黃金級 6230 2.1G、20C/40T、10.4 GT/秒、27.5 M 快取記憶體、渦輪加速、HT （125 W） DDR4-2933 |
N/A |
| 高需求中繼資料 |
2 個 Intel Xeon 黃金級 6136 （3.0 GHz），12 個核心 |
||
| 儲存節點 |
2 個 Intel Xeon 黃金級 6136 （3.0 GHz），12 個核心 |
||
| 管理節點 |
2 個 Intel Xeon 黃金級 5220 2.2G、18C/36T、10.4 GT/秒、24.75 M 快取記憶體、渦輪加速、HT （125 W） DDR4-2666 |
2 個 Intel Xeon 黃金級 5118 （2.30 GHz），12 個核心 |
|
| 記憶體 |
閘道 |
12 條 16GiB 2933 MT/秒 RDIMM （192 GiB） |
N/A |
| 高需求中繼資料 |
24 條 16GiB 2666 MT/秒 RDIMM （384 GiB） |
||
| 儲存節點 |
24 條 16GiB 2666 MT/秒 RDIMM （384 GiB） |
||
| 管理節點 |
12 條 16 GB DIMM、2666 MT/秒 （192GiB） |
12 條 8GiB 2666 MT/秒 RDIMM （96 GiB） |
|
| 作業系統 |
Red Hat Enterprise Linux 7.6 |
Red Hat Enterprise Linux 7.7 |
|
| 核心版本 |
3.10.0-957.12.2.el7.x86_64 |
3.10.0-1062.9.1.el7.x86_64 |
|
| PixStor 軟體 |
5.1.0.0 |
5.1.1.4 |
|
| 頻譜擴充 （GPFS） |
5.0.3 |
5.0.4-2 |
|
| 高效能網路連線能力 |
Mellanox ConnectX-5 雙埠 InfiniBand EDR/100 GbE 和 10 GbE |
Mellanox ConnectX-5 InfiniBand EDR |
|
| 高效能交換器 |
2 個 Mellanox SB7800 （HA – 備援） |
1 個 Mellanox SB7700 |
|
| OFED 版本 |
Mellanox OFED-4.6-1.0.1.0 |
Mellanox OFED-4.7-3.2.9 |
|
| 本機磁片 （OS 與分析/監控） |
管理節點以外的所有伺服器 3 個 480GB SSD SAS3 （RAID1 + HS），適用于作業系統 PERC H730P RAID 控制器 管理節點 3 個 480GB SSD SAS3 （RAID1 + HS），適用于作業系統 PERC H740P RAID 控制器 |
管理節點以外的所有伺服器 2 個 300GB 15K SAS3 （RAID 1），適用于作業系統 PERC H330 RAID 控制器 管理節點 5 個 300GB 15K SAS3 （RAID 5），適用于作業系統與 PERC H740P RAID 控制器 |
|
| 系統管理 |
iDRAC 9 Enterprise + DellEMC OpenManage |
iDRAC 9 Enterprise + DellEMC OpenManage |
|
效能特性
為了描繪這個全新就緒解決方案的特性，我們使用表 1 最後一欄指定的硬體，包括選配的高需求中繼資料模組。為了評估解決方案效能，使用下列基準：- IVidone N 至 N 順序
- IOR N 至 1 順序
- IOne 隨機
- MDtest
表 2 用戶端測試表
| 用戶端節點數目 |
16 |
| 用戶端節點 |
C6320 |
| 每個用戶端節點的處理器數 |
2 個 Intel（R） Xeon（R） 黃金級 E5-2697v4 18 核心 @2.30 GHz |
| 每個用戶端節點的記憶體 |
12 條 16GiB 2400 MT/秒 RDIMM |
| BIOS |
2.8.0 |
| 作業系統核心 |
3.10.0-957.10.1 |
| GPFS 版本 |
5.0.3 |
順序 IOne Performance N 用戶端至 N 檔案
以 IVidone 3.487 版測量了順序 N 用戶端至 N 檔案的效能。執行的測試範圍從單一線程到 1024 個執行緒不等，且容量擴充解決方案 （4 個 ME4084s + 4 個 ME484s） 的結果與大型解決方案 （4 個 ME4084s） 形成對比。將 GPFS 頁面集區可調轉為 16GiB，並使用大於該大小兩倍的檔案，將快取效果降至最低。請務必注意，針對 GPFS，可調式設定快取資料所用的最大記憶體量，無論已安裝和釋放的 RAM 數量為何。此外，請注意，在先前的 DellEMC HPC 解決方案中，大型順序傳輸的區塊大小為 1 MiB，而 GPFS 的格式化為 8 MiB 區塊，因此效能指標會使用該值來達到最佳效能。這可能會看起來過大且浪費太多空間，但 GPFS 使用子區塊配置來防止這種情況發生。在目前的組態中，每個區塊都會在每個 32 KiB 的 256 個子區塊中細分。下列命令用於執行寫入和讀取的效能指標，其中線程是使用執行緒數量的變數 （1 到 1024 乘以兩個電源增量），而執行緒清單則是將每個執行緒分配到不同節點上的檔案，使用迴圈方式將執行緒同質分散到 16 個運算節點上。
./i}one -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./i濕松 -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
圖 2： N 至 N 順序效能
從結果中，我們可以看到效能會隨著使用的用戶端數量快速提升，然後達到穩定狀態，直到達到 IOne 允許的最大執行緒數目為止，因此大型檔案連續效能即使在 1024 個並行用戶端中仍穩定。請注意，讀取和寫入效能會因磁片磁碟機數量增加一倍而受益。最大讀取效能受限於儲存節點上從 8 個執行緒開始使用的兩個 IB EDR 連結頻寬，而 ME4 陣列可能有一些額外的可用效能。同樣地，請注意，在 64 個執行緒和 128 個執行緒下，最大寫入效能從最大 16.7 GB 增加到 20.4 GB/秒，並且更接近 ME4 陣列的最高規格 （22 GB/秒）。
請務必記住，GPFS 偏好的作業模式分散，且解決方案已格式化為使用此類模式。在此模式中，區塊會以虛擬隨機的方式從運作一開始就分配，將資料分散到每個 HDD 的整個表面。雖然明顯缺點是初始最大效能較小，但無論檔案系統使用多少空間，效能都會維持相當恒不變。這與其他平行檔案系統不同，這些系統最初使用的外部磁軌可在每個磁片革命中容納更多資料 （磁區），因此擁有 HDD 可提供的最高效能，但是當系統使用更多空間時，每次革命都會使用較少資料的內通路，進而降低效能。
順序 IOR Performance N 用戶端至 1 個檔案
透過 IOR 版本 3.3.0 與 OpenMPI v4.0.1 輔助，透過 16 個運算節點執行效能指標，為單一共用檔案效能的順序 N 用戶端進行測量。執行的測試從一個執行緒到最多 512 個執行緒不等 （因為沒有足夠 1024 個執行緒的核心），結果會與解決方案進行對比，而不需要擴充容量。將 GPFS 頁面集區可調轉為 16GiB，並使用大於該大小兩倍的檔案，將快取效果降至最低。這項效能指標測試使用了 8 個 MiB 區塊，可發揮最佳效能。前一個效能測試區段有更完整的相關說明。
下列命令用於執行寫入和讀取的效能指標，其中線程是使用執行緒數量的變數 （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 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/1ompi /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 順序效
能 從結果中，我們可以再次觀察到，額外的磁片磁碟機有利於讀取和寫入效能。效能會隨著使用的用戶端數目再次快速提升，接著到達穩定可讀取和寫入此測試所用之執行緒數目上限的網域。請注意，16 個執行緒的最大讀取效能為 24.8 GB/秒，瓶頸是 InfiniBand EDR 介面，ME4 陣列仍有一些額外的可用效能。從那一點開始，讀取效能就從該值降低，直到到達海拔高度約 23.8 GB/秒為止。同樣地，請注意，在 8 個執行緒中達到 19.3 的最大寫入效能，並到達一個海拔高度。
隨機小型區塊 IOne Performance N 用戶端至 N 檔案
隨機 N 用戶端到 N 檔案的效能是以 FIO 3.7 版而非傳統 I warrantone 來測量。如上一個部落格所列，其目的在於利用更大的佇列深度來調查 ME4084 陣列可提供的最大可能效能 （先前針對不同 ME4 解決方案進行的測試顯示，ME4084 陣列需要更多的 IO 壓力，I warrantone 才能達到其隨機 IO 限制）。執行的測試從單一線程到最多 512 個執行緒不等，因為沒有足夠的用戶端核心來容納 1024 個執行緒。每個執行緒都使用不同的檔案，而用戶端節點上的執行緒是以迴圈方式指派。這項效能指標測試會使用 4 個 KiB 區塊來模擬小型區塊流量，並使用 16 的佇列深度。比較大型解決方案和容量擴充的結果。
將 GPFS 頁面集區可調轉為 16GiB，並使用大小兩倍的檔案，再次將快取效果降至最低。第一個效能測試區段有更完整的說明，說明為什麼此測試會在 GPFS 上有效。
圖 4： 從 N 到 N 隨機效
能的結果中，我們可以觀察到，寫入效能會以 29.1K IOps 的高值開始，並持續上升多達 64 個執行緒，其中似乎在 40K IOps 左右達到穩定狀態。另一方面，讀取效能從 1.4K IOps 開始，並使用用戶端數量幾乎以線性方式提升效能 （請記住，每個資料點的執行緒數目都會加倍），並在 64 個執行緒中達到 25.6K IOPS 的最大效能，而此執行緒似乎接近到達一個接地。使用更多執行緒將需要超過 16 個運算節點，以避免資源不足和效能降低，陣列實際上可以維持效能。
使用空檔案使用 MDtest 的中繼資料效能
中繼資料效能是以 MDtest 3.3.0 版進行測量，由 OpenMPI v4.0.1 輔助，在 16 個運算節點上執行效能指標。執行的測試從單一線程到 512 個執行緒不等。效能指標僅用於檔案 （無目錄中繼資料），取得解決方案可處理的建立數量、統計資料、讀取和移除，結果與大型解決方案形成對比。為了正確評估解決方案，與其他 DellEMC HPC 儲存解決方案和先前的部落格結果比較，已使用選配的高需求中繼資料模組，但使用單一 ME4024 陣列時，即使此作品中的大型組態和測試組態被指定為有兩個 ME4024s。此高需求中繼資料模組最多可支援四個 ME4024 陣列，建議您在新增其他中繼資料模組之前，將 ME4024 陣列的數目增加到 4 個。其他 ME4024 陣列預期會隨著每個額外陣列線性增加中繼資料效能，但 Stat 作業 （以及空白檔案讀取） 除外，因為數位非常高，因此 CPU 在某些時候將成為瓶頸，效能不會繼續線性增加。
下列命令用於執行效能指標，其中線程是以使用執行緒數目 （1 到 512 以兩個功率遞增） 的變數，而 my_hosts.$Threads 是將每個執行緒分配到不同節點上的對應檔案，使用迴圈方式將它們同質分散到 16 個運算節點上。與隨機 IO 效能指標類似，執行緒上限限制為 512 個，因為沒有足夠的核心可處理 1024 個執行緒，而內容切換會影響結果，報告的數位比解決方案的實際效能低。
由於效能結果可能會受到 IOP 總數、每個目錄的檔案數量和執行緒數目的影響，因此決定將檔案總數固定為 2 個 MiB 檔案 （2^21 = 2097152）、每個目錄修正為 1024 的檔案數量，以及目錄數量，會隨著表 3 所示的執行緒數量而有所變更。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
表 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 和 Read 作業分別以 64 個執行緒和將近 11M 的作業/秒和 4.7M 作業/秒達到尖峰值。在 16 個執行緒中，移除作業達到最高 170.6K 的作業量，並以 222.1K 作業/秒以 32 個執行緒建立作業達到峰值。Stat 和 Read 作業有更多變化性，但一旦達到尖峰值，統計資料的效能不會低於 3M，讀取則不會低於 2M 作業/ 秒。建立與移除作業在到達安地後更加穩定，且保持在 140K 作業/秒以上，且在移除作業上保持在 120K 作業/秒以上。請注意，額外的磁片磁碟機不會如預期影響空置檔案上大部分的中繼資料作業。
使用 4 個 KiB 檔案使用 MDtest 的中繼資料效能
除了使用 4KiB 的小型檔案而非空白檔案之外，這項測試幾乎與先前的測試完全相同。下列命令用於執行效能指標，其中線程是以使用執行緒數目 （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 和 Removal 作業中取得非常良好的結果，分別以 8.2M 作業/秒和 400K 作業/秒達到 256 個執行緒的峰值值。讀取作業達到最多 44.8K 營運量，並以 512 個執行緒的 68.1K 作業/秒達到尖峰。Stat and Removal 作業有更多變化性，但一旦達到峰值值，統計資料的效能不會低於 3M 的作業/秒，以及 280K 的移除作業/ 秒。建立和讀取的差異性較低，而且會隨著執行緒數目增加而持續增加。如上所見，容量擴充的額外磁片磁碟機僅提供中繼資料效能的微量變更。
由於這些數位適用于配備單一 ME4024 的中繼資料模組，因此每個額外的 ME4024 陣列的效能會提高，但不能只假設每個作業的線性增加。除非整個檔案適合這類檔案的 Inode 內部，否則 ME4084s 上的資料目標將用於儲存 4K 檔案，將效能限制在一定程度上。由於 inode 大小為 4KiB，但仍需要儲存中繼資料，因此只有 3 KiB 左右的檔案可裝入內部，且任何大於該檔案的檔案會使用資料目標。
結論和未來工作
擴充容量的解決方案不僅能提高隨機存取的效能，更能提高效能，甚至還能提高順序效能。由於分散模式的行為是隨機存取，而且擁有更多磁片，因此預期會有所改善。此效能可概觀于表 4，預期會從閒置的檔案系統穩定到即將滿為止。此外，隨著新增更多儲存節點模組，解決方案的容量和效能也會線性擴充，而選用的高需求中繼資料模組也預期也會產生類似的效能提升。此解決方案可為 HPC 客戶提供許多前 500 大 HPC 叢集所使用的非常可靠的平行檔案系統。此外，還提供卓越的搜尋功能、進階的監控和管理功能，以及新增選用閘道，可視需要透過無所不在的標準通訊協定 （例如 NFS、SMB 和其他通訊協定） 共用檔案。
表 4 尖峰和持續效能
|
|
尖峰效能 |
持續效能 |
||
| 寫 |
讀取 |
寫 |
讀取 |
|
| 大型連續 N 用戶端至 N 檔案 |
20.4 GB/秒 |
24.2 GB/秒 |
20.3 GB/秒 |
24 GB/秒 |
| 大型順序 N 用戶端至單一共用檔案 |
19.3 GB/秒 |
24.8 GB/秒 |
19.3 GB/秒 |
23.8 GB/秒 |
| 隨機小型區塊 N 用戶端至 N 檔案 |
40KIOps |
25.6KIOps |
40.0KIOps |
19.3KIOps |
| 中繼資料建立空白檔案 |
169.4K IOps |
123.5K IOps |
||
| 中繼資料狀態空白檔案 |
11M IOps |
320 萬次 IOps |
||
| 中繼資料讀取空檔案 |
470 萬次 IOps |
240 萬次 IOps |
||
| 中繼資料移除空白檔案 |
170.6K IOps |
156.5K IOps |
||
| 中繼資料建立 4KiB 檔案 |
68.1K IOps |
68.1K IOps |
||
| 中繼資料 Stat 4KiB 檔案 |
820 萬次 IOps |
3M IOps |
||
| 中繼資料讀取 4KiB 檔案 |
44.8K IOps |
44.8K IOps |
||
| 中繼資料移除 4KiB 檔案 |
40 萬次 IOps |
280K IOps |
||
由於解決方案可搭配 Cascade Lake CPU 和更快速的 RAM 一起發佈，因此一旦系統擁有最終組態，將會進行一些效能現場檢查。測試選配的高需求中繼資料模組，其中至少有 2 個 ME4024s 和 4KiB 檔案，以便更清楚記錄資料目標涉及時中繼資料效能的擴充方式。此外，閘道節點的效能將會在新的部落格或白皮書中，與任何相關的檢查結果一併測量和報告。最後，計畫使用更多解決方案元件進行測試和發佈，以提供更多功能。