ScaleFlux 是一家專注於計算存儲的公司，更具體地說是大規模計算存儲。 該公司主要通過其 ScaleFlux 計算存儲驅動器 (CSD) 來實現這一點。 正如您可能已經從他們的名字猜到的那樣，CSD 是一種集成了計算引擎的 NVMe SSD，可以提高驅動器和系統性能。 但是計算存儲意味著很多不同的東西，這取決於你在和誰說話。 在本次審查中，我們通過 ScaleFlux CSD 2000 了解了 ScaleFlux 的觀點。
ScaleFlux 是一家專注於計算存儲的公司，更具體地說是大規模計算存儲。 該公司主要通過其 ScaleFlux 計算存儲驅動器 (CSD) 來實現這一點。 正如您可能已經從他們的名字猜到的那樣，CSD 是一種集成了計算引擎的 NVMe SSD，可以提高驅動器和系統性能。 但是計算存儲意味著很多不同的東西，這取決於你在和誰說話。 在本次審查中，我們通過 ScaleFlux CSD 2000 了解了 ScaleFlux 的觀點。
什麼是計算存儲？
事實上，我們多年來一直在 StorageReview 撰寫有關計算存儲的文章。 簡而言之，計算存儲正在獲取計算資源（不是系統的計算和/或內存架構）並將它們放置在存儲本身中。
有時，這些計算資源也位於主機和存儲之間。 這可以減少數據移動，減輕系統計算資源的壓力，並可能提高性能或至少提高性能一致性。 雖然有許多供應商參與計算存儲，因此重要的是要了解術語“計算存儲”可能具有非常不同的含義，具體取決於產品。
ScaleFlux CSD 2000 和計算存儲
ScaleFlux CSD 通過引入數據路徑壓縮/解壓縮引擎而與眾不同。 據該公司稱，這可以有效地將容量翻兩番，性能翻番。 當然，這假設數據是可壓縮的，這是該平台正常運行的基礎。 假設條件合適，有效容量將成為一個強大的賣點。
還有一個成本和密度的論點。 通過壓縮數據和獲得更有效的容量，ScaleFlux 認為組織可以節省高達 50% 的閃存成本。 由於壓縮，它們還可以在同一插槽中提供“更多”閃存。
如果沒有性能，成本和效率就毫無意義，ScaleFlux 聲稱哪些性能可以比傳統 SSD 提高一倍？ 該驅動器有 Data Center 和 Data Scale 兩個版本，但讓我們看看這裡的最高數字。 對於 1:1 數據壓縮，750:4 數據壓縮的最高數字是 490K 讀取 4K IOPS 和 2K 寫入 1K IOPS。 對於連續速度，該驅動器被引用為在任一壓縮中達到 3GB/s，在 2.3:1 壓縮中寫入高達 1GB/s。
與 CSD 的其他一些區別是它具有可調 FTL/FM，允許用戶優化性能和每 GB 價格。 運行高性能可能會導致功率和溫度問題，但可以限制這些問題以避免過熱。 數據保護似乎總是出現在新聞中，為此，CSD 聲稱數據路徑中所有內部存儲器的端到端數據保護和 ECC 以及斷電保護。
要使用 ScaleFlux 參與此 CSD 操作，有幾個缺點。 一個是我們正在審查的驅動器是第 3 代，而此時傳統的 SSD 已經遷移到 PCIe Gen 4。這是一個可以解決的問題。 另一個打擊是目前，驅動程序支持僅限於 Linux。 Windows 和 VMware 都出局了。 本地化虛擬化將是一個有趣的用例，並且可以帶來數據減少的好處。 希望將來會有更廣泛的支持。
ScaleFlux CSD 2000 主要規格
| 形狀因素 | PCIe AIC & 2.5” U.2 |
| 介面 | PCIe Gen3 x4 低延遲塊存儲設備 |
| 與非媒體 | 3D TLC & 3D QLC |
| 電源丟失保護 | 可以 |
| 資料保護 |
|
| 電力 |
|
| 工作溫度 | 50°C @ 200LFM (AIC) 35°C @ 200LFM (U.2) |
| 溫度保護 | 啟用熱節流 |
| 平均無故障時間 | 2 萬小時 |
| 計算能力 |
|
| 軟件兼容性 | 僅限 Linux OS 2.6 內核或更高版本
|
使用 ScaleFlux 進行壓縮
從一開始，我們就想了解壓縮是如何實現的。 要在 Linux 中入門，您需要加載他們的自定義驅動程序以查看驅動程序並與之交互，這是通用 nvme-cli 工具集的一個分支。 這使您可以按原樣查看驅動器、對其進行格式化，以及根據當前數據集進行交互和/或修改可用容量。 下面是我們的工作負載測試前後輸出的快速示例。 “sfx-nvme list”的第一個命令顯示安裝的驅動器。
root@storagereview:~# sfx-nvme 列表
節點 SN 模型命名空間使用格式 FW Rev BUS:slot:func
/dev/sfdv0n1 UC1945A7112M CSDU3RF040B1 1 3.20 TB / 3.20 TB 512 B + 0 B 4870 0000:d8:00.0
在使用完全不可壓縮的數據（我們的正常工作數據集）進行第一輪基準測試後，我們看到該驅動器顯示出 1.00 的壓縮比。
root@storagereview:~# cat /sys/block/sfdv*/sfx_smart_features/sfx_capacity_stat
空閒空間 物理大小 邏輯大小 比較比例 供應上限 空間標誌
2736 6251231232 6251231312 1.00 6251233968 0
接下來，我們將 vdbench 壓縮級別切換為 4x，讓驅動器在幕後發揮它的一些魔力。 完成後我們再次查詢 SSD，我們看到增加的大小和 4.10 的壓縮比。 所以好消息是，通過這種基本的調整，驅動器在壓縮功能方面達到了它聲稱的效果。
root@storagereview:~# cat /sys/block/sfdv*/sfx_smart_features/sfx_capacity_stat
空閒空間 物理大小 邏輯大小 比較比例 供應上限 空間標誌
4728607824 1522626144 6251231312 4.10 6251233968 0
ScaleFlux CSD 2000 性能
VDBench 工作負載分析
在對存儲設備進行基準測試時，應用程序測試是最好的，綜合測試排在第二位。 雖然不能完美代表實際工作負載，但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線，從而可以輕鬆地在競爭解決方案之間進行同類比較。
這些工作負載提供了一系列不同的測試配置文件，從“四個角”測試、常見的數據庫傳輸大小測試到來自不同 VDI 環境的跟踪捕獲。 所有這些測試都利用通用的 vdBench 工作負載生成器，以及一個腳本引擎來自動化和捕獲大型計算測試集群的結果。 這使我們能夠在各種存儲設備上重複相同的工作負載，包括閃存陣列和單個存儲設備。
我們針對這些基準測試的測試過程用數據填充整個驅動器表面，然後將驅動器部分分區為驅動器容量的 25%，以模擬驅動器如何響應應用程序工作負載。 這與完全熵測試不同，後者使用 100% 的驅動器並使它們進入穩定狀態。 因此，這些數字將反映更高的持續寫入速度。
簡介：
- 4K 隨機讀取：100% 讀取，128 個線程，0-120% 重複率
- 4K 隨機寫入：100% 寫入，64 線程，0-120% iorate
- 64K 順序讀取：100% 讀取，16 線程，0-120% 迭代
- 64K 順序寫入：100% 寫入，8 個線程，0-120% 迭代
- 綜合數據庫：SQL 和 Oracle
- VDI 完整克隆和鏈接克隆跟踪
為了進行比較，我們將查看帶有 VDBench 發送不可壓縮數據和 4 倍可壓縮數據的 ScaleFlux SSD。 在隨機 4K 中，不可壓縮的 CSD 在 100 微秒以下開始，峰值為 588,893 IOPS，延遲為 216 微秒。 壓縮後，該驅動器僅稍慢一點，峰值為 573,460 IOPS，延遲為 222µs。
4K 隨機寫入看到不可壓縮驅動器在大約 355µs 時達到約 325K IOPS 的峰值，然後下降一些。 通過壓縮，驅動器大部分時間保持在 100µs 以下，峰值約為 572K IOPS，延遲為 168µs。
切換到 64K 順序工作負載時，不可壓縮驅動器的讀取峰值達到 33,785 IOPS 或 2.11GB/s，延遲為 473µs。 通過壓縮，我們看到該驅動器以 47,489µs 的較低延遲達到 2.97 IOPS 或 336GB/s。
在 64K 寫入中，對於大部分測試，兩種配置的運行時間均低於 100µs。 不可壓縮配置的峰值為 24,074 IOPS 或 1.5GB/s，延遲為 643µs。 通過 4 倍壓縮，我們看到峰值為 36,364 IOPS 或 2.27GB/s，延遲為 397µs。
我們的下一組測試是我們的 SQL 工作負載：SQL、SQL 90-10 和 SQL 80-20。 從 SQL 開始，兩個數據配置非常相似。 不可壓縮的峰值為 188,269 IOPS 和 167µs 的延遲，而壓縮數據進入驅動器的峰值為 190,370 IOPS，延遲也為 167µs。
在 SQL 90-10 中，不可壓縮的 ScaleFlux CSD 2000 達到了 185,310 IOPS 的峰值，延遲為 172µs。 對驅動器進行 4 倍壓縮後，它達到了 220,615 IOPS 的峰值和 144µs 的延遲。
SQL 80-20 的不可壓縮驅動器峰值為 179,482 IOPS，延遲為 177µs。 查看 CSD 的壓縮，我們看到在 221,851µs 的延遲下達到 143 IOPS 的峰值。
接下來是我們的 Oracle 工作負載：Oracle、Oracle 90-10 和 Oracle 80-20。 從 Oracle 開始，不可壓縮的峰值達到 184,048 IOPS，延遲為 194µs。 查看進行壓縮的驅動器，我們看到了 245,385 IOPS 的峰值和 135µs 的延遲。
Oracle 90-10 開始時在性能和延遲方面幾乎相同。 不可壓縮版本在 155,641µs 的延遲下達到 141 IOPS 的峰值。 壓縮版本達到 175,681 IOPS 的峰值，延遲為 125µs。
Oracle 80-20 booth 驅動器配置啟動時間不到 100µs。 對於不可壓縮的數據，峰值為 151,983 IOPS，延遲為 144µs。 對於壓縮數據，我們看到了 182,640 IOPs 的峰值性能，延遲為 120µs。
接下來，我們切換到我們的 VDI 克隆測試，完整和鏈接。 對於 VDI 完全克隆 (FC) 啟動，沒有不可壓縮數據的 ScaleFlux CSD 2000 驅動器在 127,616µs 的延遲下達到了 263 IOPS 的峰值。 發送 4 倍壓縮將性能提高到 161,543 IOPS，延遲為 216µs。
VDI FC Initial Login 在 78,125µs 時為我們提供了 379 IOPS 的峰值和壓縮數據在 154,077µs 時的 189 IOPS。
對於週一的 VDI FC，不可壓縮驅動器的峰值為 62,922 IOPS，延遲為 251µs。 使用 4 倍壓縮時，峰值更高，為 100,680 IOPS，延遲僅為 156µs。
對於 VDI 鏈接克隆 (LC) 引導，驅動器的不可壓縮數據達到 58,705 IOPS 的峰值，延遲為 271µs。 當我們向驅動器發送 4 倍壓縮時，它達到 81,137 IOPPS 的峰值和 196µs 的延遲。
VDI LC Initial Login 的驅動器具有不可壓縮數據，在 36,537µs 的延遲下達到 215 IOPS 的峰值性能。 當 4 倍壓縮數據到達驅動器時，它達到 56,739 IOPS 的峰值和 137µs 的延遲。
最後，在 VDI LC Monday Login 中，不可壓縮驅動器以 48,814µs 的延遲達到了 323 IOPS 的峰值。 通過壓縮，SSD 達到了 81,799 IOPS 的峰值，延遲為 192µs。
結論
ScaleFlux 只專注於計算存儲。 這主要是通過其稱為 ScaleFlux 計算存儲驅動器 (CSD) 的 SSD 完成的。 這些是帶有計算引擎的 PCIe Gen3 SSD，可提高性能和數據效率。 該公司有一些不同的驅動器，但在這次審查中，我們查看了 ScaleFlux CSD 2000。
ScaleFlux 驅動器與其他計算存儲之間的主要區別在於數據路徑壓縮/解壓縮引擎。 ScaleFlux 聲稱容量翻了兩番，同時性能翻了一番，這要歸功於他們的計算技術。 這不僅會影響性能，而且考慮到數據高度可壓縮時的存儲效率，它還可以降低每 TB SSD 存儲的成本。
那麼主要關心的是壓縮引擎是否工作？ 這是一個簡單的肯定，因為我們在測試中直接操縱了壓縮。 我們從完全不可壓縮的數據開始，正如預期的那樣，驅動器的比率為 1:1。 切換到 4X 壓縮率，我們在驅動器上獲得了 4.1:1 的壓縮率。 關鍵的第一步是在查看性能之前打勾。
首先，讓我們看看沒有向其發送不可壓縮數據的驅動器。 亮點包括 589K 讀取 4K IOPS、355K 寫入 4K IOPS、2.11K 讀取 64GB/s 和 1.5K 寫入 64GB/s。 在 SQL 中，我們看到了 188K IOPS 的峰值，SQL 185-90 中的 10K IOPS 和 SQL 179-80 中的 20K IOPS。 對於我們的 Oracle 工作負載，我們看到了 184K IOPS 的峰值，Oracle 156-90 中的 10K IOPS 和 Oracle 152-80 中的 20K IOPS。 通過我們的 VDI 克隆測試，未壓縮的 CSD 2000 在啟動時為我們提供了 128K IOPS，在初始登錄中為我們提供了 78K IOPS，在完整克隆的星期一登錄中為我們提供了 63K IOPS。 對於鏈接克隆，該驅動器在啟動時為我們提供了 59K IOPS，在初始登錄中為我們提供了 37K IOPS，在星期一登錄中為我們提供了 49K IOPS。
一旦我們發送了 4X 壓縮數據，我們驚喜地發現除了 4K 讀取之外，每個測試的性能都有所提升，兩者之間的差距並不大。 亮點包括 573K 讀取 4K IOPS、572K 寫入 4K IOPS、2.97K 讀取 64GB/s 和 2.27K 寫入 64GB/s。 在 SQL 中，我們看到了 190K IOPS 的峰值，SQL 221-90 中的 10K IOPS 和 SQL 222-80 中的 20K IOPS。 對於 Oracle，我們看到了 245K IOPS 的峰值，Oracle 176-90 中的 10K IOPS 和 Oracle 183-80 中的 20K IOPS。 通過我們的 VDI 克隆測試，帶壓縮的 ScaleFlux 在啟動時為我們提供了 162K IOPS，在初始登錄中為我們提供了 154K IOPS，在完整克隆的星期一登錄中為我們提供了 101K IOPS。 對於鏈接克隆，該驅動器在啟動時為我們提供了 81K IOPS，在初始登錄中為我們提供了 57K IOPS，在星期一登錄中為我們提供了 82K IOPS。
ScaleFlux CSD 2000 確實是一個有趣的產品，隨著計算存儲的發展，它預示著傳統 SSD 領域的潛在變革。 CSD 已經存在多年，所以這個概念並不新鮮。 可能缺少的是執行力。 就他們而言，ScaleFlux 是所有 CSD 人員中第一個在我們的實驗室中獲得某些東西的人。 信心本身雖然不會帶來一天，但驅動器必須執行。
在這種情況下，性能不僅僅是您在我們的圖表中看到的數字，儘管它在那裡表現得很好。 這個 SSD 布丁中的證明是關於它能夠很好地處理可壓縮數據的能力。 它完全按照我們測試中的預期執行此操作，甚至在除一個測試配置文件之外的所有測試配置文件中都提供了一點性能提升。 為了讓這個 SSD 有意義，用例只需要對齊。 毫無疑問，可壓縮數據將從 ScaleFlux 技術中受益匪淺。 只要您現在不需要 VMware 或 Windows 虛擬化支持，CSD 2000 絕對值得在 PoC 中探索，看看您的工作負載能從中受益多少。
參與 StorageReview
電子報 | YouTube | LinkedIn | Instagram | Twitter | Facebook | 的TikTok | RSS訂閱
