Fungible 正在通過 Fungible Storage Cluster、FSC 1600 高性能存儲節點的發布消除現有存儲架構的限制,從而改變存儲平台的設計方式。 Fungible Storage Cluster 提供高性能、低延遲的 NVMe/TCP 分解存儲解決方案,對高級應用程序完全透明。 Fungible Storage Cluster (FSC) 由 Fungible DPU™ 提供支持,是一種高性能、安全、橫向擴展的分解式全閃存存儲平台。
Fungible 正在通過 Fungible Storage Cluster、FSC 1600 高性能存儲節點的發布消除現有存儲架構的限制,從而改變存儲平台的設計方式。 Fungible Storage Cluster 提供高性能、低延遲的 NVMe/TCP 分解存儲解決方案,對高級應用程序完全透明。 Fungible Storage Cluster (FSC) 由 Fungible DPU™ 提供支持,是一種高性能、安全、橫向擴展的分解式全閃存存儲平台。
Fungible FS1600 閃存陣列
數據處理單元 (DPU) 本質上是一個片上系統。 通常,DPU 由一個多核微處理器、一個網絡接口和加速引擎組成,這些引擎可以卸載以數據為中心的任務,例如網絡、存儲、虛擬化、安全和分析功能。 DPU 和 SmartNIC 在企業和雲提供商數據中心中繼續受到歡迎。
可替代 FSC1600 存儲集群
FS1600 由兩個可替代數據處理單元提供動力。 作為一項獨特的 Fungible 創新,DPU 代表了全新設計的新型微處理器,可在運行基礎設施服務時提供無與倫比的性能和效率。
可替代 FS1600 內部結構
雖然大多數存儲平台都是基於 x86 的,但 FS1600 植根於基礎的 Fungible DPU 技術。 DPU 專為比 CPU 更高效地運行以數據為中心的工作負載而設計,使 FS1600 能夠提供更高的性能。 FS1600 具有 13M IOPS 的隨機讀取速率 原始塊讀取性能 (4KB)、每個節點 75 GB/s 的吞吐量和 +10μs 的讀取延遲,性能比直連存儲 (DAS) 系統更高效,提供96.5% 的性能效率百分比 (PEP)。
DPU 硬件加速器包括壓縮、擦除編碼、加密、正則表達式、深度數據包檢測和 DMA,以 800 Gb/s 的線路速率運行。 使用糾刪碼,如果一個節點出現故障,數據將使用來自其他節點的奇偶校驗和數據塊重建,而主機則提供替代路徑以通過多路徑訪問數據。 FS1600 通過適用於 Kubernetes 的容器存儲接口 (CSI) 和適用於 VM 的 Openstack 與 NVMe/TCP 和管理軟件兼容,可以直接替代現有存儲系統。 對使用主機CPU資源的特殊代理沒有要求; 只需要一個標準的 NVMe/TCP 驅動程序。 現有應用程序無需更改。
S1 和 F1 DPU 型號
有兩種 Fungible DPU 模型:S1 DPU 和 F1 DPU。 Fungible 系列處理器利用相同的硬件和軟件協同設計並共享相同的編程模型。 然而,雖然 F1 DPU 專為存儲、安全、AI 和分析服務器等高性能獨立設備而設計,但 S1 DPU 可在標準 PCIe 適配器的佔用空間和功率範圍內最大限度地提高性能。
Fungible S1 DPU 經過優化,可在服務器節點內組合以數據為中心的計算並在節點間高效移動數據。 以數據為中心的計算的特點是高速數據流的有狀態處理,通常是通過網絡、安全和存儲堆棧。
Fungible FS1600 後端口
S1 DPU 通過其 TrueFabric™ 技術促進服務器節點之間的數據交換。 TrueFabric 是一種大規模的 IP-over-Ethernet 結構協議,提供總網絡橫截面帶寬,具有低平均和尾部延遲、端到端 QoS、無擁塞連接和服務器節點之間的安全性。 TrueFabric 協議完全符合標準並可與 TCP/IP over Ethernet 互操作,確保數據中心 Spine-Leaf 網絡可以使用標準的現成以太網交換機構建。
趣味OS
S1 和 F1 DPU 的數據平面運行 FunOS™,這是一種用高級編程語言 (ANSI-C) 編寫的專用操作系統。 FunOS 運行網絡、存儲、安全、虛擬化和分析堆棧。 控制平面運行標準操作系統(例如 Linux)並包含代理,這些代理允許由一組 REST API 管理、控制和監視 S1 和 F1 DPU 的集群。 這些 REST API 可以集成到標准或第三方編排系統中,例如 Kubernetes CSI 插件、OpenStack、OpenShift 等。
通過將這些關鍵功能組合到一個解決方案中,Fungible DPU 系列處理器可實現計算和存儲資源的超分解和池化——為下一代數據中心提供高性能、可大規模擴展的可組合基礎設施!
集群的組成
FSC™ 包括一個由兩個或更多 Fungible FS1600 存儲目標節點和三個 Fungible Composer 節點組成的集群。 Fungible Composer 軟件管理控制平面,這是一個集中管理解決方案,用於配置、管理、編排、控制和部署 Fungible 存儲集群。 Composer 節點提供存儲、網絡管理、遙測、用於日誌收集的節點管理等服務,以及提供對 Fungible Composer 提供的服務的外部訪問的 API 網關。
Fungible Storage Cluster 提供高性能、低延遲的 NVMe/TCP 分解存儲解決方案,對高級應用程序完全透明。 每個 FS1600 最多支持 24 個 U.2 NVMe/TCP SSD,性能從小至 70TB 線性擴展到多 PB。
使用案例
用於超分解的雲原生存儲:FSC 為雲提供商提供了傳統存儲的替代方案。 通過分解存儲,FSC 可以獨立擴展計算和存儲、提高利用率、減少服務器 SKU、降低管理複雜性並提高敏捷性。
人工智能/機器學習: 現代 AI/ML 工作負載通常需要大規模並行性能、低延遲和大容量。 FSC 與高度可擴展的並行文件系統相結合,消除了存儲瓶頸,為這些現代工作負載實現了前所未有的性能、延遲和效率。
雲原生高性能數據庫:當今許多高性能橫向擴展數據庫都部署 DAS 以滿足延遲要求。 這些數據庫通常通過集群冗餘方案(例如副本集或主從配置)提供持久性。 如果服務器出現故障,數據將保存在另一台服務器上。 FSC 保留類似 DAS 的延遲,同時提供改進的存儲利用率和集群冗餘,但容量開銷較低。
簡化的 IT 管理
除了 FS1600 和 Fungible DPU 帶來的所有性能優勢外,還有一種簡化的管理方法。 Fungible 通過單一管理平台為多租戶、安全數據中心提供管理工具。 Fungible Composer 儀表板將使 IT 管理員的工作效率更高,並提供有效管理日常數據中心功能所需的信息。
可替代作曲家
Fungible Composer 儀表板易於使用,包含大量用於跟踪、管理、配置和性能監控的詳細信息。 頂部選項卡將指示連接的系統,完整顯示集群詳細信息、IOPS、存儲詳細信息以及需要注意的任何警報。
顯示屏左側的圖標提供對特定管理工具的即時訪問。
根據部署可替換設備時提供的詳細信息,主機表將為管理員提供連接主機的快速視圖,並提供向下鑽取到特定主機的選項。
對於性能數據,通過選擇分析圖標,屏幕將填充集群性能的詳細信息,從而快速查看 IOPS、帶寬和延遲。
卷詳細信息提供了每個卷的運行狀況的快速概覽。 從這裡您可以深入到各個卷以獲取更多詳細信息。
部署細節
1 x 可替代 FSC1600
- 8 個 100GbE 連接
- 24 個 3.84TB NVME 設備
4 x 戴爾 R740xd
- 1 x 可替代 FC200
- 1 個 100GbE 連接
- 1 個 NVIDIA ConnectX-5
- 1 個 100GbE 連接
- 2 個 Intel Xeon Gold 6130 CPU @ 2.10GHz
- 1 256GB 內存
卷
- 總共 192 個 100G RAW 卷
- 每個主機 16 x 4K RAW 卷
- 每個主機 16 x 8K RAW 卷
- 每個主機 16 x 16K RAW 卷
測試過程
測試準備包括使用寫入工作負載預處理所有捲以在啟動測試工作負載之前填充它們。 卷的大小與應用的工作負載的塊大小一致。 對於測試,4K、8K 和 16K 卷分別用於 4K 隨機、8K 隨機和 64K 順序工作負載。 我們利用 NVMe over TCP 協議和單個節點,在沒有保護方案的情況下測試了存儲。
Fungible DPU 或 100GbE NIC 之間的每個 FIO 迭代都是平衡的,以提供類似的延遲配置文件。 然後增加 100GbE NIC 工作負載以提高性能,從而導致更多延遲和 CPU 利用率。
在初始測試階段,FIO 作業鏈接到安裝卡的 NUMA 節點。 DPU 或 NIC 在每次測試之間被交換並位於相同的 PCIe 插槽中。 除了將服務器 BIOS 配置文件設置為性能外,在服務器級別不需要進行任何特殊調整。 對於每個 loadgen,我們都安裝了 Ubuntu 20.04.2 Live Server。
可替代的 FS1600 總結績效結果
可替代 FC200 IOPS
工作量 | 主機 1 | 主機 2 | 主機 3 | 主機 4 |
4k 讀取 | 2019k | 2015k | 2016k | 2012k |
4k寫入 | 2244k | 2020k | 2280k | 2203k |
64讀取 | 167k | 166k | 166k | 166k |
64k寫入 | 161k | 168k | 164k | 186k |
8k 70r/30w | 1118k / 479k | 1105k / 474k | 1075k / 461k | 1117k / 479k |
可替代 FC200 帶寬
工作量 | 主機 1 | 主機 2 | 主機 3 | 主機 4 |
4k 讀取 | 7886MiB/秒 | 7871MiB/秒 | 7873MiB/秒 | 7858MiB/秒 |
4k寫入 | 8766MiB/秒 | 7890MiB/秒 | 8905MiB/秒 | 8606MiB/秒 |
64讀取 | 9.80GiB/秒 | 10.1GiB/秒 | 10.2GiB/秒 | 10.1GiB/秒 |
64k寫入 | 8732MiB/秒 | 10.2GiB/秒 | 11.3GiB/秒 | 11.4GiB/秒 |
8k 70r/30w | 8732MiB /3743MiB/秒 | 8632MiB/3699MiB/秒 | 8395MiB/3598MiB/秒 | 8729MiB /3741MiB/秒 |
100GbE 網卡 IOPS
工作量 | 主機 1 | 主機 1 加速 | 主機 2 | 主機 3 | 主機 4 |
4k 讀取 | 980k | 2019k | 1108k | 1102k | 1120k |
4k寫入 | 968k | 2776k | 494k | 1025k | 1011k |
64讀取 | 140k | 118k | 125k | 141k | 140k |
64k寫入 | 72.5k | 179k | 40.1k | 100k | 47.0k |
8k 70r/30w | 498k / 213k | 1147k / 491k | 597k / 256k | 567k / 243k | 595k / 255k |
100GbE 網卡帶寬
工作量 | 主機 1 | 主機 1 加速 | 主機 2 | 主機 3 | 主機 4 |
4K閱讀 |
3828MiB/秒 | 7887MiB/秒 | 4330MiB/秒 | 4303MiB/秒 | 4374MiB/秒 |
4K寫 |
3783MiB/秒 | 10.6GiB/秒 | 1931MiB/秒 | 4005MiB/秒 | 3950MiB/秒 |
64K閱讀 | 8761MiB/秒 | 7269MiB/秒 | 7804MiB/秒 | 8832MiB/秒 | 8753MiB/秒 |
64K寫 |
4529MiB/秒 | 10.9GiB/秒 | 2505MiB/秒 | 6251MiB/秒 | 3000MiB/秒 |
8K 70R/30W | 3889MiB/1667MiB/秒 | 8958MiB/3839MiB/秒 | 4663MiB/1998MiB/秒 | 4427MiB/1897MiB/秒 | 4646MiB/1991MiB/秒 |
可替代的 FS1600 是表演者
我們知道進入本次審查時 Fungible FS1600 速度很快; 這是毫無疑問的。 雖然每台主機的單卡飽和,包括DPU和NIC,但陣列還有性能餘量。 主要關注點是 NIC 和 DPU 如何針對使用具有相似測試場景的相同存儲陣列的 NVMe/TCP 工作負載進行比較。 DPU 為存儲市場帶來了難以置信的好處。 它們可以卸載 CPU 的活動,使其能夠處理其他任務,例如使用該 I/O 或帶寬的應用程序工作負載。 通過將我們的關注範圍縮小到單個主機,我們看到了這些好處。
可替代的 DPU
馬上,如果您保持每個工作負載的平均延遲相似,您可以看到 DPU 可以驅動大約兩倍於 NIC 的性能。 在這裡,我們測量了 Fungible DPU 的 2.02M IOPS 4K 隨機讀取,平均延遲為 0.474ms。 查看此工作負載期間的實時 CPU 使用情況,我們可以看到工作負載包含在 FIO 工作負載中指定的 CPU 內核中。
fio –group_reporting –time_based –runtime=10m –rw=randread –bs=4k –iodepth=5 –numjobs=12 –ioengine=libaio –direct=1 –prio=0 –cpus_allowed_policy=split –cpus_allowed=25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63, 0 –randrepeat=XNUMX
100GbE 網卡
接下來,我們轉向 100GbE NIC,它能夠以 980 毫秒的平均延遲驅動 0.39k IOPS。 DPU 的 IO 深度和作業數量已減少,以控制延遲,但查看 CPU 使用情況,您很快就會發現 DPU 的優勢所在。雖然在 FIO 作業中為 NIC 分配了相同的 CPU 內核,它具有更廣泛的系統利用率。 在生產服務器中用於後端進程(NIC、適配器等)的 CPU 與應用程序工作負載等前端進程之間存在權衡。 在這裡,我們看到 NIC 驅動程序消耗 CPU 週期,而 DPU 保持內部化。
fio –group_reporting –time_based –runtime=10m –rw=randread –bs=4k –iodepth=4 –numjobs=6 –ioengine=libaio –direct=1 –prio=0 –cpus_allowed_policy=split –cpus_allowed=25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63, 0 –randrepeat=XNUMX
100GbE NIC 斜坡
最後,我們轉向調整後的 100GbE NIC 工作負載,它可以達到與 DPU 相同的性能水平,大約 2.02M IOPS。 不過,更高速度的代價是延遲,延遲顯著增加到 2.6 毫秒和更高的峰值延遲。 這是通過將 iodepth 從 4 擴展到 16,並將作業數量從 6 擴展到 20。雖然焦點可能集中在增加的延遲上,但查看 CPU 使用率,您可以看到幾乎所有系統資源都集中在I/O 活動,不會為其他進程留下太多。 對於試圖使其服務器部署更加密集和高效的企業來說,很容易看出並非所有 I/O 都生而平等,以及 DPU 如何快速改變存儲市場。
fio –group_reporting –time_based –runtime=10m –rw=randread –bs=4k –iodepth=16 –numjobs=20 –ioengine=libaio –direct=1 –prio=0 –cpus_allowed_policy=split –cpus_allowed=14-63 –randrepeat= 0
最後的話
我們已經使用 Fungible FS1600 及其 DPU 數週了。 雖然陣列本身不需要任何花哨的佈線或更改,但我們希望進行徹底的分析以深入了解 DPU 的影響。 並不是說 DPU 本身是全新的,而是它們最終在企業級解決方案中商用,而不僅僅是科學項目。 需要明確的是,DPU 實現並不完全相同,因此了解設計決策中的基礎架構和性能影響至關重要。
在這個 DPU 世界中,Fungible 脫穎而出,非常獨特。 當公司於 2015 年成立時,他們尋求定制解決方案,並在 2016 年底投入大量現金來建立公司。大致就是在 Mellanox 宣布他們的第一個 DPU 版本,稱為 BlueField 的時候。 雖然可以說 Fungible 採用 BlueField 會做得很好,但走自己的路已經帶來了實質性的技術和領導優勢。 Fungible 可以完全控制其堆棧,並且可以輕鬆地在客戶端和目標端利用 DPU。 與否,決定權在客戶。 但在我們的測試中,我們看到了使用 Fungible 進行端到端的顯著優勢。
Fungible 與在存儲陣列和主機中利用的 DPU 一起出現,完成了一幅在性能方面提供巨大優勢的圖景。 DPU 卸載了原本會分配給系統處理器的資源,這在等式的兩邊使用時呈現出一個有趣的組合。 當您能夠利用 Fungible FC200 代替傳統 NIC 時,您會看到 I/O 速度的顯著提高以及 CPU 使用率的降低。 僅看我們的 4K 隨機讀取傳輸,FC200 能夠以 2 毫秒的延遲驅動超過 0.474M IOPS,而 NIC 可以在 1 毫秒時驅動大約 0.39M IOPS。 提高 NIC 以驅動 2M IOPS 是可能的,但會付出巨大的延遲和系統資源成本。
可替代的 FC200 DPU
在解鎖閃存中可用的本機性能方面,DPU 作為一類具有巨大的潛力。 雖然這在今天已經是一個真實的陳述,但隨著 Gen5 SSD 和更快的互連等技術進入市場,數學對 DPU 變得更加有利。 當涉及到可以利用這些組件的應用程序時,支付 x86 額外費用來管理 PCIe 通道是沒有意義的,而遺留架構的可擴展性不高。
Fungible 擁有極具吸引力的硬件和軟件以及 FS1600 存儲節點和加速器卡。 他們最近還把目光投向了 分解 GPU,為客戶提供更完整的 HPC 和 AI 工作負載堆棧。 在迅速崛起的 DPU 領域將有多個贏家,但 Fungible 無疑是值得關注的一個。 需要充分利用其存儲的組織絕對應該使用 FS1600。
參與 StorageReview
電子報 | YouTube | 播客 iTunes/Spotify | Instagram | Twitter | Facebook | 的TikTok | RSS訂閱