首页 企业 ScaleFlux CSD 2000 回顾

ScaleFlux CSD 2000 回顾

by 亚当·阿姆斯特朗

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
断电保护控制 充足
数据保护
  • 端到端保护
  • 所有内存上的 ECC
  • 全数据路径 CRC
  • LDPC 和芯片级 RAID 保护
电力
  • 18Watt 典型有源
  • 最大 25W att
  • 12W att 空闲(零退出延迟)
工作温度 50°C @ 200LFM (AIC) 35°C @ 200LFM (U.2)
温度保护 启用热节流
平均无故障时间 2 万小时
计算能力
  • 透明数据路径压缩
  • 加速性能
  • 扩展容量
操作系统 仅限 Linux OS 2.6 内核或更高版本

  • 存储库支持:Ubuntu 16/18/20、RedHat/CentOS 6/7/8

使用 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 中探索,看看您的工作负载能从中受益多少。

比例通量

使用 ScaleFlux 安排 PoC

参与 StorageReview

电子报 | YouTube | LinkedIn | Instagram | Twitter | Facebook | TikTokRSS订阅