首页 企业版 Fungible FS1600 将超大规模存储推向数据中心

Fungible FS1600 将超大规模存储推向数据中心

by 哈罗德弗里茨

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™ 提供支持,是一种高性能、安全、横向扩展的分解式全闪存存储平台。

可替代的 FS1600

Fungible FS1600 闪存阵列

数据处理单元 (DPU) 本质上是一个片上系统。 通常,DPU 由一个多核微处理器、一个网络接口和加速引擎组成,这些引擎可以卸载以数据为中心的任务,例如网络、存储、虚拟化、安全和分析功能。 DPU 和 SmartNIC 在企业和云提供商数据中心中继续受到欢迎。

- 可替代 FSC1600 存储集群

FS1600 由两个可替代数据处理单元提供动力。 作为一项独特的 Fungible 创新,DPU 代表了全新设计的新型微处理器,可在运行基础设施服务时提供无与伦比的性能和效率。

可替代的 FS1600 内部结构

可替代 FS1600 内部结构

虽然大多数存储平台都是基于 x86 的,但 FS1600 植根于基础的 Fungible DPU 技术。 DPU 专为比 CPU 更高效地运行以数据为中心的工作负载而设计,使 FS1600 能够提供更高的性能。 FS1600 具有 13M IOPS 的随机读取速率 原始块读取性能 (4KB)、每个节点 75 GB/s 的吞吐量和 +10μs 的读取延迟,性能比直连存储 (DAS) 系统更高效,提供96.5% 的性能效率百分比 (PEP)。

Fungible FS1600 完整内部

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 适配器的占用空间和功率范围内最大限度地提高性能。

可替代 FS1600 DPU

Fungible S1 DPU 经过优化,可在服务器节点内组合以数据为中心的计算并在节点间高效移动数据。 以数据为中心的计算的特点是高速数据流的有状态处理,通常是通过网络、安全和存储堆栈。

可替代的 FS1600 烘焙端口

Fungible FS1600 后端口

S1 DPU 通过其 TrueFabric™ 技术促进服务器节点之间的数据交换。 TrueFabric 是一种大规模的 IP-over-Ethernet 结构协议,提供总网络横截面带宽,具有低平均和尾部延迟、端到端 QoS、无拥塞连接和服务器节点之间的安全性。 TrueFabric 协议完全符合标准并可与 TCP/IP over Ethernet 互操作,确保数据中心 Spine-Leaf 网络可以使用标准的现成以太网交换机构建。

趣味操作系统

S1 和 F1 DPU 的数据平面运行 FunOS™,这是一种用高级编程语言 (ANSI-C) 编写的专用操作系统。 FunOS 运行网络、存储、安全、虚拟化和分析堆栈。 控制平面运行标准操作系统(例如 Linux)并包含允许 S1 和 F1 DPU 集群由一组 REST API 管理、控制和监视的代理。 这些 REST API 可以集成到标准或第三方编排系统中,例如 Kubernetes CSI 插件、OpenStack、OpenShift 等。

通过将这些关键功能组合到一个解决方案中,Fungible DPU 系列处理器可实现计算和存储资源的超分解和池化——为下一代数据中心提供高性能、可大规模扩展的可组合基础设施!

集群的组成

FSC™ 包括一个由两个或更多 Fungible FS1600 存储目标节点和三个 Fungible Composer 节点组成的集群。 Fungible Composer 软件管理控制平面,这是一个集中管理解决方案,用于配置、管理、编排、控制和部署 Fungible 存储集群。 Composer 节点提供存储、网络管理、遥测、用于日志收集的节点管理等服务,以及提供对 Fungible Composer 提供的服务的外部访问的 API 网关。

Fungible FS1600 带 SSD 彩绘盖

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

可替代的 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订阅