適用於 HPC BeeGFS 高效能儲存的 Dell EMC Ready Solutions

由 Dell EMC  HPC 與 AI 創新實驗室的 Nirmala Sundararajan 於 2019 年 11 月撰寫的文章

適用於 HPC BeeGFS 高效能儲存的 Dell EMC Ready Solutions

目錄

1. 簡介
2. 解決方案參考架構
3. 硬體與軟體組態
4. 解決方案組態詳細資料
   • 管理服務
   • 中繼資料服務
   • 儲存服務
   • 用戶端服務
5. R740xd，24 個 NVMe 磁碟機，CPU 對應詳細資料
6. 效能特性
   • 循序讀取和寫入 N-N
   • 隨機讀取和寫入 N-N
7. 結論和未來工作
    

簡介

解決方案參考架構

硬體與軟體組態

表 1 和 2 分別說明管理伺服器和中繼資料/儲存伺服器的硬體規格。表 3 說明解決方案使用的軟體版本。

解決方案組態詳細資料

• 管理服務
• 中繼資料服務
• 儲存服務
• 用戶端服務

管理服務

中繼資料服務

圖 3： 中繼資料伺服器

圖 4 顯示中繼資料伺服器的 RAID 組態。圖片中強調了在中繼資料伺服器中 NUMA 區域 0 中的磁碟機代管 MDT，而 NUMA 區域 1 中的磁碟機則代管儲存資料，而儲存伺服器則在兩個 NUMA 區域中代管 ST。

儲存服務

1. 寫入效能使用 dd 命令測量，透過建立區塊大小為 1MiB 的 10GiB 檔案，以及直接的資料 I/O。在 RAID 0 裝置上，每個裝置的平均寫入效能約為 5.1 GB/秒，而在 RAID 10 裝置上，每個裝置的平均效能為 3.4GB/秒。
2. StorageBench 效能指標測試顯示，RAID 0 組態的最大輸送量為 5.5 GB/秒，而 RAID 10 組態則為 3.4 GB/秒。這些結果與使用 dd 命令取得的結果類似。
3. RAID 10 能提供 50% 的磁碟容量使用率，而寫入效能將降低約 50%。透過 RAID 10 進行儲存冗餘十分昂貴。
4. NVMe 磁碟機價格昂貴，並可在 RAID 0 組態中妥善發揮加速效果

用戶端服務

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd，24 個 NVMe 磁碟機，CPU 對應詳細資料

# cat /proc/sys/kernel/numa_balancing
0

效能特性

循序寫入和讀取 N-N

為了評估循序讀取和寫入效能，我們使用了循序讀取和寫入模式的 IOzone 效能指標。這些測試是從 1 個執行緒開始，並以「2 的次方」增加，最多 1024 個執行緒，計算其多執行緒計數。在每個執行緒計數中，會產生相同的檔案數量，因為此測試會在每個執行緒針對一個檔案，或是 N 用戶端對 N 個檔案 (N-N) 的方式運作。此程序會以循環制或週期式的方式分佈在 32 個實體用戶端節點中，因此要求會平均分佈，並實現負載平衡。選取的彙總檔案大小為 8TB，在任何指定的測試中，此檔案會平均分配給執行緒。選擇的彙總檔案大小足以將來自伺服器和 BeeGFS 用戶端的快取影響降至最低。以寫入然後讀取 (-i 0, -i 1) 的合併模式執行 IOzone，使其可協調作業之間的邊界。在此測試和結果中，我們每次執行都使用 1MiB 的記錄大小。用於執行順序 N-N 測試的命令如下：

Sequential Writes and Reads: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

執行以下命令，在每次迭代和讀寫測試之間清除或清理用戶端節點間的作業系統快取：

# 同步 &&; echo 3 > /proc/sys/vm/drop_caches

Beegfs 的預設 stripe 計數為 4。不過，您可以根據每個目錄的需求設定每個檔案的區塊大小和目標數目。在所有這些測試中，我們將 BeeGFS stripe 大小選擇為 2MB，而 stripe 計數則選擇為 3，因為我們每個 NUMA 區域有三個目標，如下所示：

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

透明巨大頁面 (transparent huge page) 已停用，並為中繼資料和儲存伺服器設定下列調整選項：

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

除了上述內容外，還使用下列 BeeGFS 調整選項： 

• 在中繼資料組態檔案中將 tuneTargetChooser 參數設定為「roundrobin」 
• 將 tuneNumWorkers 中繼資料參數設為 24，儲存參數設為 32 
• 將 connMaxInternodeNum 中繼資料參數設為 32、儲存參數設為 12，用戶端參數設為 24

在圖 9 中，我們發現尖峰讀取效能為 1024 個執行緒時的 132 GB/秒，尖峰寫入為 256 個執行緒時的 121 GB/秒。每個磁碟機可提供 3.2 GB/秒的尖峰讀取效能和 1.3 GB/秒的尖峰寫入效能，使理論上的尖峰讀取效能為 422 GB/秒，寫入則為 172 GB/秒。不過在這裡，網路是限制了效能的因素。在設定中，我們總共有 11 個儲存伺服器的 InfiniBand EDR 連結。每個連結都可提供 12.4 GB/秒的理論尖峰效能，總共應可提供 136.4 GB/秒的理論尖峰效能。所達到的尖峰讀取和寫入效能，分別是理論尖峰效能的 97% 和 89%。

觀察到的單一執行緒寫入效能為約 3 GB/秒，讀取效能則為約 3 GB/秒。我們觀察到寫入效能以線性增加，在 256 個執行緒時達到尖峰，然後開始減少。使用較低的執行緒計數時，讀取和寫入效能相同。因為在 8 個執行緒之前，我們有 8 個用戶端在 24 個目標寫入 8 個檔案，表示並未充分運用所有儲存裝置目標。系統中有 33 個儲存目標，因此至少需要 11 個執行緒，才能充分運用整個伺服器。讀取效能會隨著並行執行緒的數量增加而持續增加，我們在 512 和 1024 個執行緒上觀察到幾乎相同的效能。

我們也觀察到，在執行緒計數從 16 到 128 之間時，讀取效能會低於寫入效能，然後讀取效能就會開始提高。這是因為 PCIe 讀取作業是非張貼作業，需要同時取得要求和完成通知，PCIe 寫入作業卻是一種自主導引 (fire and forget) 的作業。當交易層封包移交給資料連結層後，作業即完成。寫入作業是一種「張貼」作業，僅包含要求。

讀取的輸送量通常低於寫入輸送量，因為在處理相同資料量時，讀取需要兩次交易，而寫入僅需要一次。PCI Express 使用分割交易模式進行讀取。讀取交易包含下列步驟：

• 要求者傳送記憶體讀取要求 (MRR)。
• 完成者傳送 MRR 的確認。
• 完成者傳回完成通知與資料。

讀取傳輸量取決於發出讀取要求的時間，以及完成者傳回資料之間的延遲。但是，當應用程式發出可彌補此延遲的大量讀取要求時，便可最大化輸送量。這也是為什麼讀取效能會在 16 個執行緒到 128 個執行緒之間低於寫入效能，並在要求增加後輸送量也隨之增加。  當要求者等待完成通知，再發出後續請求時，會測量到較低的輸送量。當發出多個要求，便可在第一次資料傳回後進行延遲分攤，便可實現較高的輸送量。

隨機寫入和讀取 N-N

為了評估隨機 IO 效能，我們使用了隨機模式的 IOzone。測試從 4 個執行緒到最多 1024 個執行緒，計算執行緒總數。我們使用直接 IO 選項 (-I) 執行 IOzone，讓所有作業都略過緩衝快取，並直接前往磁碟。使用的 BeeGFS stripe 計數為 3，區塊大小為 2MB。在 IOzone 使用 4KiB 要求大小。效能以每秒 I/O 作業 (IOPS) 計算。在 BeeGFS 伺服器及 BeeGFS 用戶端運行間會清理作業系統快取。用於執行隨機寫入和讀取的命令如下：

Random reads and writes: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

圖 10：  在 IOzone 使用 8TB 彙總檔案大小的隨機讀取與寫入效能

效能為 512 執行緒時，隨機寫入尖峰約 360 萬 IOPS，而 1024 執行緒時，隨機讀取的尖峰約 350 萬 IOPS，如圖 10 所示。當 IO 要求的數量提高時，觀察到的寫入和讀取效能也都更高。這是因為 NVMe 標準最多可支援 64K I/O 佇列，每個佇列最多可支援 64K 個命令。這樣的大型 NVMe 佇列集區，可提供更高層級的 I/O 平行處理，因此我們觀察到超過 300 萬的 IOPS。

結論和未來工作

此部落格宣佈推出 Dell EMC 高效能 BeeGFS 儲存解決方案，並強調其效能特性。解決方案的尖峰循序讀取與寫入效能分別為約 132 GB/秒和 ~121 GB/秒，隨機寫入尖峰效能為約 360 萬 IOPS，隨機讀取效能則為約 350 萬 IOPS。

此部落格是「BeeGFS 儲存解決方案」的一部分，其設計著重於高效能的暫存空間。請持續關注部落格系列的第 2 部分，其中將說明如何藉由增加伺服器數量來擴充解決方案，以提升效能和容量。部落格系列的第 3 部分將討論 BeeGFS 的其他功能，並將強調「StorageBench」的使用，這是 BeeGFS 的內建儲存目標效能指標。

我們接下來的步驟是發佈白皮書，內容包含中繼資料效能和 N 執行緒至 1 檔案的 IOR 效能，以及有關設計考量、調整和組態的其他詳細資料。

參考資料