INTEL：基于IPU组建存储服务器集群

全文概览

云计算、大数据和人工智能的爆炸式增长，对计算和存储资源提出了更高要求。传统的CPU架构在应对这些挑战时逐渐显现瓶颈：CPU不仅要承担核心计算任务，还要处理大量的网络、存储和安全等基础设施管理工作，导致资源利用率低下和性能瓶颈。为了突破这些限制，基础设施处理单元（IPU）应运而生。IPU作为一种新型的可编程网络设备，旨在将CPU从繁重的基础设施任务中解放出来，专注于核心计算，从而提高数据中心的整体效率和性能。

本文将深入探讨IPU如何通过构建可横向扩展的服务器集群，为现代数据中心带来革命性的变革，特别是在应对AI和高性能计算工作负载方面展现出的巨大潜力。通过对比IPU与DPU、AWS Nitro卡的差异，分析IPU作为独立服务器集群的优势，并结合Apache Cassandra等应用案例，揭示IPU在重塑数据中心架构中的关键作用和未来趋势。

阅读收获

• 深入了解基础设施处理单元（IPU）的概念、背景及其在现代数据中心中的作用。
• 掌握IPU与DPU、AWS Nitro卡的关键区别，以及IPU作为独立服务器集群的独特优势。
• 洞悉IPU在构建低成本、低功耗、可扩展的数据中心解决方案中的潜力，尤其是在运行Apache Cassandra等横向扩展应用时的优势。
• 理解IPU的关键技术特性、硬件架构以及软件生态，为未来数据中心基础设施的选型和优化提供参考。

基础设施处理单元（IPU）是一种新型的可编程网络设备，旨在卸载中央处理器（CPU）在现代数据中心中执行的基础设施任务。简单来说，IPU 可以看作是专门为处理网络、存储和安全等基础设施工作负载而设计的专用处理器。

IPU 出现的背景和动机：

随着云计算、大数据、人工智能等技术的快速发展，现代数据中心面临着前所未有的挑战：

• CPU 负载过重： 传统的服务器架构中，CPU 不仅要处理核心的计算任务，还要负责大量的网络、存储和安全等基础设施管理工作。这导致 CPU 资源被过度占用，影响了核心应用程序的性能和效率。
• 资源利用率低下： 为了满足不断增长的基础设施需求，数据中心需要部署更多的服务器，导致硬件成本和能耗不断增加，但整体资源利用率可能并不高。
• 性能瓶颈： 传统的网络和存储架构在处理大规模数据和高并发请求时可能成为性能瓶颈，影响应用程序的响应速度和整体吞吐量。
• 安全性挑战： 数据中心需要提供强大的安全保障，而将安全功能集成到 CPU 中会增加其复杂性和开销。

为了解决这些问题，业界开始探索将基础设施任务从 CPU 中剥离出来，交给专门的硬件进行处理，从而释放 CPU 资源，提高整体系统性能和效率。IPU 就是在这种背景下应运而生的。

===

比较 IPU、DPU与AWS的Nitro加速卡

• IPU (Intel): Intel 的 IPU 更侧重于提供一个通用的、可编程的平台，可以灵活地适应不同的基础设施需求。它更像是一个“基础设施领域的通用 CPU”，具备一定的通用计算能力，可以运行各种基础设施软件。
• DPU (NVIDIA): NVIDIA 的 DPU 则更强调其在高性能网络和数据处理方面的专长。通过集成 Mellanox 的高速网络技术和自身的 GPU 加速经验，DPU 在处理网络密集型和数据密集型工作负载方面表现出色。它更像是一个“针对特定基础设施任务优化的加速器”。
• Nitro 卡 (AWS): Nitro 卡是 AWS 为其云基础设施量身定制的解决方案。它的设计目标是完全服务于 AWS 的需求，与 AWS 的各种服务深度集成，提供最佳的性能、安全性和可靠性。它更像是一个“为特定云环境高度优化的专用硬件”。

如何选择：

• 如果您需要一个通用的、可编程的卸载加速器，能够处理多种类型的基础设施任务，并且希望拥有较高的灵活性，那么 IPU 可能是个不错的选择。
• 如果您对高性能网络、网络安全、大数据分析或高性能存储等领域有更高的性能要求，并且希望利用 NVIDIA 在这些领域的优势，那么 DPU 可能是更合适的选择。
• 如果您是 AWS 云的用户，并且希望获得最佳的云实例性能、安全性和资源利用率，那么 Nitro 卡 是 AWS 基础设施的固有组成部分，您无需额外选择。

这段文字主要介绍了基础设施处理单元（IPU）在数据中心的应用。

• IPU的传统和新型部署方式： 传统上IPU作为服务器的PCIe端点卸载CPU任务，而新型部署方式是作为独立的服务器，通过PCIe交换机连接NVMe SSD。
• IPU的优势： IPU具有高性能网络能力、低成本、低功耗和紧凑的特点，可以运行Linux操作系统，适合构建可横向扩展的服务器集群。
• IPU的应用场景： 像Apache Cassandra这样的NoSQL数据库非常适合在IPU服务器集群上运行，因为其架构更适合于多瘦节点而不是少数胖节点，并且对存储容量的要求较低。其他横向扩展应用如ScyllaDB和Ceph也适用。
• IPU集群的价值： 基于多节点IPU的集群可以有效降低数据库尾部延迟，保持高吞吐量，并为日益增长的数据中心存储需求和功率限制提供解决方案，尤其是在AI/ML应用领域。

问题意识

在数据中心面临运行人工智能（AI）和高性能计算（HPC）工作负载带来的电力和散热限制的情况下，构建一个由低成本、低功耗、紧凑型服务器组成的集群来运行分布式和横向扩展应用程序是否具有价值。

如果答案是肯定的，那么应该考虑哪些类型的分布式和横向扩展应用程序。

IPU的新场景

• 传统的 IPU 用例：
  • 基础设施处理单元 (IPU) 作为 x86 主机中的 PCIe 端点部署，用于将网络/存储/安全等基础设施工作从 CPU 卸载。
• 替代的 IPU 用例：
  • 一个独立的迷你服务器，直接或通过 PCIe 交换机向下游 NVMe SSD 提供 PCIe 根端口接口。

IPU的优势

图片列出了 IPU 的两个主要优势：

1. 作为低成本、低功耗的 Linux 迷你服务器： IPU 具备高速网络能力，并且可以在其嵌入式的 Arm 核心上运行 Linux 操作系统，这使得它能够成为一个功能强大的同时又经济节能的小型 Linux 服务器。
2. 支持构建可扩展的集群： 类似于传统的 CPU 服务器，多个 IPU 迷你服务器可以组成集群。这种集群化的架构可以形成一个可扩展的平台，非常适合运行需要横向扩展能力的应用程序。

Apache Cassandra[1] 作为一种适合在 IPU 集群上运行的横向扩展应用程序。

• Cassandra 的特性： Cassandra 是一个 NoSQL 数据库，具有良好的横向扩展能力，可以扩展到数千个节点。
• IPU 与 Cassandra 的结合： 通过在 IPU 节点上运行 Cassandra，可以降低每个服务器的成本、功耗和尺寸，从而提高数据中心的可持续性。
• 概念验证： 目前的概念验证使用了六个 IPU 硬件节点，每个节点运行了两个 Cassandra 实例，表明了这种组合的可行性。

幻灯片强调了 Apache Cassandra 作为 IPU 集群的一个理想应用，能够带来成本、功耗和可持续性方面的优势。

展示了 Apache Cassandra 的广泛应用和受欢迎程度。

• 广泛的应用： 超过 6500 家公司在生产环境中使用 Cassandra，覆盖了社交媒体后端服务、时间序列数据存储和分布式数据库等多个领域。
• 行业认可度高： 财富 100 强企业中有 40% 使用 Cassandra，这表明了大型企业对 Cassandra 的信任和认可。
• 数据库排名靠前： Cassandra 在所有使用的数据库中排名前 10，进一步印证了其在数据库领域的地位和影响力。

图注：IPU作为独立存储集群的用例

图注：IPU作为独立存储集群的用例

幻灯片展示了 IPU 在存储方面的多种应用场景，从 PCIe 端点和 PCIe 根端口两个角度进行了划分：

作为 PCIe 端点 (连接到 CPU 主机)：

• NVMe-oF 发起方： IPU 可以作为 NVMe over Fabrics (NVMe-oF) 的发起方，实现云规模的存储解耦，支持裸金属主机，并使用 NVMe/TCP 协议。这有助于构建灵活且可扩展的存储架构。
• 本地存储解耦： IPU 可以提供 NVMe 设备的虚拟化层，并支持内联的数据加密和数据完整性检查 (DIF/CRC)。这增强了本地存储的安全性与可靠性。

作为 PCIe 根端口 (独立运行或作为存储服务器)：

• IPU+CPU 存储服务器： IPU 可以与 CPU 协同工作，加速存储数据路径的处理。同时，IPU 也支持超融合基础设施 (HCI) 的场景，发起方和目标存储功能可以在同一个 IPU 上同时运行。
• 基于 IPU 的 JBOF 带 PCIe 交换机： IPU 可以用于构建 JBOF (Just a Bunch Of Flash) 存储系统，通过 PCIe 交换机连接大量的 SSD，并加速存储数据路径。这适用于需要高存储容量和性能的场景。
• IPU 服务器或带有直连 SSD 的 JBOF： （重点强调）IPU 可以作为独立的低成本、低功耗的服务器或 JBOF 控制器，直接连接 SSD。这种方案具有高带宽和低延迟的特点，可以构建紧凑型的基于 Arm 的 Linux 服务器，并通过网络连接形成大型的横向扩展集群。这与之前讨论的 Cassandra 在 IPU 集群上的应用场景相符。

IPU 独立集群的优势对比

IPU 服务器或带有直连 SSD 的 JBOF 控制器代表了一种针对特定工作负载（如分布式存储和横向扩展应用）进行优化的新型计算和存储节点。它们通过低成本、低功耗的 Arm 架构和对直接连接 SSD 的优化，实现了高带宽和低延迟的存储访问，并易于构建大规模集群。这与传统 CPU 服务器的通用计算和传统存储控制器的集中式存储管理形成了鲜明的对比。

图注：Intel IPU SoC E2100 结构

图注：Intel IPU SoC E2100 结构

幻灯片展示了 Intel IPU SoC E2100 的计算复合体的关键特性：

• 强大的计算能力： 拥有 16 个运行频率高达 2.5GHz 的 Arm NI 核心，能够高效处理各种基础设施工作负载。
• 大容量缓存： 配备 32MB 的系统级缓存，提升了 IO 处理性能，并为存储和通用计算提供了支持。
• 高内存带宽： 通过 3 个 LPDDR4 控制器，实现了高达 100 GB/s 的内存峰值带宽，满足高性能需求。
• 硬件加速的加密和压缩： 集成了旁路加密加速器，可以加速加密操作，并采用先进的 ZStandard 压缩技术，优化存储和数据库性能。
• 可靠的管理特性： 具备专用的管理处理器和子系统，提供安全启动、维护和升级功能，增强了系统的可靠性和易用性。

幻灯片描述了 IPU 中两个主要部分的软件角色和特性：集成管理复合体 (IMC) 和 ARM 计算复合体 (ACC)。

• 集成管理复合体 (IMC)：
  • 可以选择运行 Rocky Linux 或客户选择的操作系统。
  • 负责底层的设备管理任务，包括启动和重置、设备级安全、资源分区以及与数据中心管理系统的集成。
  • 其关键软件组件（如预启动加载器和恢复镜像）存储在 SPI flash 上，而操作系统镜像和应用程序栈存储在 M.2 SSD 上，并支持活动/备份模型以提高可靠性。
• ARM 计算复合体 (ACC)：
  • 操作系统由客户选择。
  • 负责处理客户特定的工作负载，包括网络数据平面和存储的卸载与编排，以及调试、遥测和配置等生命周期管理操作。
  • 其预启动组件（如 ARM 可信固件和 UEFI）以及操作系统镜像和应用程序栈都存储在 M.2 SSD 上。

图注：IPU基板实物图

图注：IPU基板实物图

幻灯片展示了 IPU（基础设施处理单元）相关的硬件组件：

• IPU 网络参考板 (NRB，左图)： 这是一块 PCIe CEM 卡，具有全高和短长度的规格。它配备了双 QSFP28 接口，支持 LPDDR4x 内存，并通过 PCIe x16 Gen4 接口连接。这表明该参考板具有高性能的网络和内存能力。
• 根端口 (RP4x4) 适配器（右图）： 这是一个 PCIe 适配卡，提供了 4 个 PCIe Gen4 x4 通道的插槽，可以连接 4 个 TB 级别的 NVMe SSD。这表明该适配器用于扩展 IPU 的存储连接能力，支持高速 NVMe 存储。

Note

从实体硬件来看，IPU仍然是基于PCIe 插槽扩展的设计理念，最右边是将PCIe 卡与NVMe-SSD PCB基板组合的示意图，可以看到 IPU现阶段实验室设计与成熟的应用方案间还是有显著差异的，IPU作为互联集群的设计仍需要大量研究工作。

图注：基于IPU的 Cassandra 集群

图注：基于IPU的 Cassandra 集群

幻灯片展示了一个使用 IPU 迷你服务器构建的 Cassandra 集群的概念验证 (PoC) 架构。

• 集群规模： 该 PoC 包含 6 个 IPU 迷你服务器节点，总共运行了 12 个 Cassandra 实例。
• 硬件配置： 每个 IPU 迷你服务器配备了 Intel IPU E2100，并通过 RAID-0 配置使用了两个 7.68TB 的 Cassandra 实例，这两个实例分别由两个 4TB 的三星 PM9A3 TLC SSD 组成。
• 网络连接： 所有 IPU 迷你服务器通过 Arista 7050X3 100Gbe TOR 交换机进行连接。每个 IPU 拥有 100Gbe 的以太网接口。
• 软件环境： 每个节点运行 Linux 操作系统、Java Corretto 和 Cassandra 3.9。
• 存储扩展能力： 右侧的图示表明，每个 IPU E2100 可以通过 M.2 适配器连接最多 8 个 4TB TLC SSD，这为每个 IPU 提供了潜在的 32TB 存储容量。
• 网络优化： 通过整合每个 IPU 端口的 IP 地址，减少了对 TOR 交换机端口的需求。

图注：IPU 的能耗分析

图注：IPU 的能耗分析

功耗分析

幻灯片展示了基于 IPU 的 Cassandra 集群与传统 x86 服务器在功耗方面的对比结果。

• IPU 集群功耗： 在压力测试下，一个 IPU 网络参考板 (NRB) 的功耗约为 40W。每个 NVMe TLC SSD 的功耗约为 8W，因此 4 个 SSD 的总功耗约为 32W。一个 IPU NRB 加上 4 个 SSD，总功耗为 72W，可以支持两个 Cassandra 实例。
• 传统 x86 服务器功耗： 一台传统的 x86 服务器在支持四个 Cassandra 实例时，功耗约为 1200-1500W。
• 单实例功耗对比： 换算到每个 Cassandra 实例，基于 IPU 的方案功耗约为 36W，而传统 x86 服务器的功耗则高达 300-375W。

传统 x86 服务器的可扩展性

幻灯片中提到的“支持四个 Cassandra 实例”很可能是一个基于实际测试和性能考量的配置。 这个数字可能代表了在该特定服务器配置下，能够保证每个 Cassandra 实例都具有相对合理的性能和稳定性的一个平衡点。

虽然可以通过 PCIe 交换机连接更多的存储，但这并不能解决 CPU、内存和网络等其他资源的瓶颈问题。简单地增加存储容量而不考虑其他关键资源，并不能有效地扩展单个服务器上可运行的 Cassandra 实例数量。

与 IPU 的对比：

IPU 的设计理念之一就是通过低成本、低功耗的小型服务器构建大规模横向扩展集群。在这种架构下，每个 IPU 服务器可能只运行少量 Cassandra 实例（例如，幻灯片中提到的每个 IPU 硬件节点运行两个 Cassandra 实例），但通过增加服务器的数量来实现整体性能和容量的提升。这种方式可以更好地利用资源，避免单个服务器出现资源瓶颈。

图注：IPU 方案的性能调优路径

图注：IPU 方案的性能调优路径

性能调优

幻灯片介绍了对基于 IPU 的 Cassandra 集群进行的性能调优工作。

• 当前瓶颈： 目前的 IPU/Cassandra 节点性能瓶颈在于计算和内存，而不是网络和 SSD。未来的 IPU 将会改进这些方面。
• CPU 核心利用率： 在一个 Cassandra 实例的情况下，Arm 核心利用率约为 80-90%。运行两个实例时，利用率会更高。理想目标是将利用率控制在 75-80%，为后台任务（如压缩和垃圾回收）预留资源。Cassandra 的多线程特性使其能够有效利用 IPU 的 16 个 Arm 核心。
• 内存优化： 通过调整内存分配策略，增加了 ARM 计算复合体 (ACC) 的可用内存，从 29GB 增加到 37GB。这直接提升了 Cassandra 的内存表和缓存大小，有助于提高性能。
• 软件配置： 目前为止的最佳性能是通过特定的软件配置实现的，包括使用 Cassandra 3.0-beta 版本、OpenJDK 17、ZGC 垃圾回收器以及分配 16GB 的堆内存。

图注：性能调优结果

图注：性能调优结果

幻灯片展示了经过数月的性能调优后，基于 IPU 的 Cassandra 集群的性能提升效果，主要关注 P99 尾部延迟。

• 初始性能： 在 2023 年底，经过初步的性能调优，测得的 P99 尾部延迟平均为 185 毫秒，并且抖动非常明显。
• 优化后的性能： 经过广泛的性能优化，包括 Cassandra、Java（特别是垃圾回收）、Linux 操作系统、网络、NVMe SSD 和内存等多个方面的调优，在 2024 年 2 月底测得的平均 P99 尾部延迟已降至 20 毫秒以下，并且抖动显著减少。
• 性能目标： 目标是将 P99 尾部延迟控制在 10 毫秒以下的绿色窗口内。

Note

图片传递出硬件创新优化的基本思路，基于问题意识，先构建出硬件原型，部署软件后，不断调优，最终将瓶颈收敛到硬件资源，从而迭代升级。对于并非硬件开发的同学来说，文章完整呈现了软硬协同开发的核心要义。

图注：KV键值工作负载测试结果

图注：KV键值工作负载测试结果

幻灯片展示了在 IPU 上的 Cassandra 集群进行 tip-stress 键值 (KV) 工作负载测试的结果，分别呈现了读操作和 mutation（写入/更新）操作的 p99 尾部延迟和吞吐量随时间的变化。

• 读操作：
  • p99 尾部延迟： 大约在 25 毫秒到 40 毫秒之间波动。
  • 吞吐量： 开始时约为 75 万请求/秒，随着时间推移逐渐下降到约 65 万请求/秒。
• Mutation 操作：
  • p99 尾部延迟： 大约在 10 毫秒到 20 毫秒之间波动。
  • 吞吐量： 开始时约为 80 万请求/秒，随着时间推移逐渐下降到约 70 万请求/秒。

总而言之，这些图表显示了在压力测试下，基于 IPU 的 Cassandra 集群在读写操作方面都表现出了相对稳定的延迟和较高的吞吐量。尽管吞吐量随着时间的推移略有下降，但整体性能指标表明该集群在处理高负载的键值工作负载时具有良好的性能。

Note

这里的测试结果，由于缺乏同等性价比的对照测试，仍是孤岛数据，需要参考基准测试结果来比较 IPU 的真实性能。

图注：x86 vs. IPU 的基准测试结果

图注：x86 vs. IPU 的基准测试结果

幻灯片展示了使用 SPECjvm2008 基准测试套件对 Intel Ice Lake 处理器（8 核 16 线程）和 IPU（标记为 MtEvans TS）进行的性能比较。SPECjvm2008 是一套用于衡量 Java 运行时环境性能的工具。

图表中的蓝色条代表 Ice Lake 处理器的性能，黄色条代表 IPU 的性能。在不同的 Java 工作负载下，两种处理器的性能表现有所不同。

• 在某些工作负载下，例如 compress、crypto.aes、crypto.rsa、scimark.large、sunflow 和 xml.transform 等，Ice Lake 处理器的性能明显优于 IPU。
• 而在其他一些工作负载下，例如 crypto.signverify 和 Score on derby，IPU 的性能似乎与 Ice Lake 相当或略有优势。

Note

从 SPECjvm2008 基准测试数据来看，现阶段IPU在 Java 应用场景的性能与通用 x86 处理器仍是有较大差距。

图注：IPU 互联集群的下一步研究方向

图注：IPU 互联集群的下一步研究方向

幻灯片展望了 IPU 技术和基于 IPU 的解决方案的未来发展方向。

• 下一代 IPU： 将从当前的 200G IPU 升级到下一代 Mount Morgan IPU 400G SoC，这意味着网络带宽将得到提升。同时，每个节点支持的 Cassandra 实例数量也将从两个增加到四个。
• RDMA 支持： 未来将支持远程直接内存访问 (RDMA) 技术。通过采用基于硬件的传输层协议来替代传统的基于软件的 TCP/IP 协议栈，可以进一步提高整体性能，降低延迟。
• 扩展应用场景： 除了 Cassandra 之外，未来还将考虑在 IPU 集群上运行其他横向扩展应用程序，例如 ScyllaDB 和 Ceph，以支持更多类型的分布式存储和计算需求。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

原文标题：Scaling out IPUs to create a server cluster

Notice：Human's prompt, Datasets by Gemini-2.0-flash-thinking