IBM Storage Ceph 通过元数据分层加速集群性能，但基准测试仍待验证

IBM Storage Ceph 在 9.9.2 版本中通过将频繁访问的元数据迁移至更快的存储介质，而非继续保留在较慢设备上，来加速集群性能。

10 月 14 日发布的版本引入了 BlueFS Spillover Cleaner，这是一种面向 RocksDB 管理元数据的自动化分层机制。IBM 表示，该功能有望提升关键工作负载的一致性并降低延迟。不过，其公告并未提供任何基准测试结果。

这一缺口构成了核心矛盾。IBM 确实解决了混合介质 Ceph 集群中的实际性能问题，但采购方仍需要工作负载层面的证据。此次发布挑战了一种固有假设：提升分布式存储集群性能总是需要更多闪存、更多节点或大规模硬件更新。

它也对社区版 Ceph 部署和竞争性存储平台形成压力。管理员现在必须判断，自动化元数据放置能否带来实质性收益，同时不会引入难以接受的迁移、监控或升级风险。

IBM Storage Ceph 通过元数据分层加速集群性能

关键变化并非新的存储协议，而是 Ceph 自动决定将最繁忙的元数据存放在哪里。

IBM Storage Ceph 9.9.2 于 2026 年 10 月 14 日正式发布。IBM 将该产品描述为一个面向企业支持的软件定义平台，通过单一技术栈提供块存储、文件存储和对象存储。

此次发布的核心性能功能是 BlueFS Spillover Cleaner。IBM 也将其底层机制称为智能 BlueFS Tiering Manager。

BlueFS 是 BlueStore（Ceph 的存储后端）使用的小型文件系统，用于管理 RocksDB 文件。RocksDB 是一个嵌入式键值数据库，记录包括逻辑对象与物理存储之间映射关系在内的内部元数据。

一台 Ceph 存储设备可以使用多个介质层级。WAL 设备保存预写日志，而可选的 DB 设备存储 RocksDB 元数据。主设备保存对象数据，也可能接收无法再存放于其他位置的元数据。

管理员通常将 DB 和 WAL 功能部署在 SSD 或 NVMe 设备上，同时将大型对象数据集保留在成本较低的硬盘上。

这种架构会产生一个重要的故障模式。当高速 DB 设备被占满时，RocksDB 文件可能会溢出到主数据设备上。硬盘能够提供足够的容量，但在发生这种溢出后，元数据访问会变得更慢且更难预测。

新管理器会持续检查文件访问模式。根据 IBM 的 9.9.2 版本概述，它会将频繁访问的文件迁移到 DB 设备，并将活跃度较低的文件移向较慢介质。

该机制类似缓存管理，但其操作对象是 RocksDB 文件，而不是应用程序对象。它试图将有限的高速容量留给对活跃工作负载贡献最直接的元数据。

这一差异至关重要。应用程序无需识别热点元数据，也无需发出特殊的放置命令。存储层会监控活动情况，并在后台调整文件位置。

最初的性能报道认为，这种安排可将高价值元数据保留在更快的介质上。它还应避免非活跃数据库文件长期占用稀缺的 SSD 容量。

IBM 表示，结果将是更高效的元数据访问、更低的延迟以及更一致的集群性能。在独立测试通过可重复的工作负载衡量其效果之前，这些说法仍属于厂商主张。

IBM Storage Ceph 9.9.2 还包含更广泛的更新，涵盖 NVMe/TCP 网关管理、S3 对象浏览、CephFS 隔离、NFS 故障转移、SMB 集成以及集群管理。

其中若干新增功能仍处于技术预览阶段。完整对象去重、透明 NFS 状态迁移、macOS SMB 支持和通过 S3 进行 SMB 访问，并非全部被定位为成熟的生产级功能。

BlueFS Spillover Cleaner 则不同，因为它针对的是 RADOS 核心，即 Ceph 服务底层的分布式对象层。因此，它的影响可波及通过多种接口暴露的工作负载。

该功能还瞄准了一个反复出现的运维问题，而不是增加另一种访问方式。IBM 试图从许多客户已在运行的硬件中获得更稳定的性能。

这使得本次更新比其狭义描述所暗示的更具影响力。存储采购方获得了一种软件机制，若其改善效果能经受真实部署条件的考验，便可能延后硬件扩容。

为什么元数据放置会成为集群级性能问题

少量放置不当的元数据便可能影响规模大得多的数据集，因为每项对象操作都依赖准确的内部映射。

Ceph 将信息分布在多个对象存储守护进程（称为 OSD）中。每个 OSD 管理本地存储设备，并参与复制、恢复、再平衡和客户端操作。

BlueStore 将数据直接写入原始块设备。它使用 RocksDB 存储描述对象及其组成部分位置的元数据，而 BlueFS 则为该数据库提供文件系统服务。

与大型对象传输相比，元数据查找规模很小。然而，延迟的查找可能处于许多应用请求的关键路径上。当工作负载产生大量小型或随机操作时，其影响会更加明显。

性能也可能变得不一致，而非均匀地变慢。一个请求可能访问位于 SSD 上的元数据，另一个请求则可能触及已溢出至硬盘的 RocksDB 文件。

平均吞吐量可能掩盖这一差异。数据库平台、虚拟机和交互式分析通常对长尾延迟的反应比对标称顺序带宽更为明显。

这正是 IBM 自动化放置决策的重要性所在。集群可能已经安装了高速 DB 设备，但在其元数据规模发生变化后，仍可能无法有效利用这些设备。

这种情况可能随增长逐渐出现。即使底层硬件保持健康，更多对象、快照、存储桶或放置组也会增加元数据压力。

运维事件可能带来额外压力。再平衡、恢复、压实和维护活动会改变访问模式，或争夺设备资源。

管理员可以规划 DB 设备容量并监控溢出情况，但静态方案并不总能匹配不断演变的工作负载。一个为大型对象设计的集群，日后可能接收大量小文件或快速变化的虚拟机镜像。

BlueFS Spillover Cleaner 试图让高速层具备自适应能力。它会根据观测到的访问情况，提升活跃 RocksDB 文件的层级，并降低较冷文件的层级。

这一概念易于理解，但其实现伴随着棘手问题。管理器必须识别有用模式，同时避免产生过多后台 I/O。它还必须避免过于频繁地移动文件，以致分层本身消耗掉其试图获得的收益。

IBM 尚未在公告中公布该策略的阈值或详细决策模型。因此，采购方无法清楚了解管理器对工作负载变化的响应速度。

他们还需要了解该功能在压实期间的表现。RocksDB 会定期重组数据文件，从而产生可能改变文件大小和访问模式的写入活动。

对于将高容量硬盘与较小 SSD 元数据设备配对的混合型集群而言，该清理器可能尤其有价值。这类系统中的 DB 与较慢介质之间存在最大的性能差异。

全闪存集群则是另一种情况。在两个闪存层之间移动元数据仍可能产生影响，但延迟差距可能更小。CPU、网络或软件串行化可能成为主要瓶颈。

IBM 的硬件指南强调，Storage Ceph 可运行于非专有的通用系统上。它支持 Intel 和 AMD x86-64 处理器，而 9.9.0 版本新增了完整 ARM 支持。

这种硬件灵活性是 Ceph 吸引力的核心。它也意味着，任何单一性能主张都无法代表所有部署环境。

硬盘类型、网络设计、OSD 密度、CPU 分配、故障域、数据保护策略和对象大小都会改变结果。分层功能也会继承这种差异性。

因此，实际承诺比“让 Ceph 更快”更为有限。当元数据溢出构成实质性瓶颈且仍有可用的高速 DB 容量时，IBM Storage Ceph 才能加速集群性能。

这种情况会存在于许多混合介质系统中，但并非全部。采购方应先确定其延迟来源，再将升级视为普遍适用的解决方案。

真正的竞争是软件优化与硬件扩容之争

IBM 最有力的论点是，更智能的放置方式能够恢复性能，而无需迫使客户更换集群的容量层。

应对存储压力的常见方式是增加资源。管理员可能安装更大的 DB 设备、以 SSD 替换硬盘、增加节点，或重新设计网络。

这些措施可能奏效，但会影响预算、维护计划、故障规划和物理容量。扩展分布式集群也可能触发数据迁移，而新资源在发挥全部效益之前便会产生影响。

BlueFS Spillover Cleaner 提供了另一条路径。它试图通过持续优先处理活跃元数据，提升现有闪存的价值。

这确立了本次发布的主要对手：软件驱动的优化与硬件主导的扩容。IBM 正押注于放置智能能够推迟至少一部分基础设施变更。

该公司并未消除容量规划的必要性。严重不足的 DB 层无论软件排序多么出色，都无法保留每一个活跃文件。

元数据分层也无法修复饱和的网络或过载的处理器。它无法让基于硬盘的对象存储在所有工作负载下都变成全闪存阵列。

其价值在于避免浪费。如果非活跃元数据占据高速介质，而活跃元数据位于较慢设备上，那么购买更多硬件只是在处理症状，并未纠正放置问题。

这一变化也强化了企业版相对于自行运维 Ceph 的优势。社区版 Ceph 仍然开源且高度可配置，但组织必须自行集成、验证、监控和支持所选择的配置。

IBM 将 Ceph 代码与经过测试的版本、管理界面、升级流程、硬件选项和企业支持打包提供。自动化分层管理器为采购方提供了又一个理由，让其将受支持的发行版与内部维护的部署进行比较。

这并非简单的专有软件与开源软件之争。IBM Storage Ceph 仍基于 Ceph，IBM 也在更广泛的生态系统中作出贡献。

真正的区别在于运维责任。社区用户可以直接调优系统，而 IBM 客户则为经过策划的生命周期和受支持的实施方案付费。

Red Hat 还通过 Red Hat Ceph Storage 和平台集成提供企业级 Ceph 技术。IBM 于 2023 年从 Red Hat 接管其企业级 Ceph 产品责任，将 Ceph 纳入 IBM 更广泛的存储产品组合。

传统存储厂商则采取另一种路径。它们通常将专有软件与严格控制的硬件结合，以减少配置差异，但也限制了通用硬件的灵活性。

IBM 位于两者之间。它提供受支持的软件定义存储、可选的认证节点，以及不限于单一一体机模式的部署选择。

性能管理器很契合这一定位。IBM 可以通过软件改善运行表现，同时保留硬件选择空间。

9.9.2 版本还为 RADOS Gateway 实例提供零停机滚动升级。IBM 表示，新版本 RGW 可与现有实例并行启动，同时让旧版本完成正在处理的请求。

该功能强化了其运维层面的论点。性能固然重要，但企业也会评估维护操作是否会中断 S3 兼容应用。

此次发布为 NVMe/TCP 网关组增加了增强的生命周期控制。管理员可通过仪表板扩展管理主机、访问、网络和显示设置。

这些变化不会直接提升 RocksDB 速度。它们降低了块存储和对象服务周边的管理成本，而这会影响企业级发行版的整体价值。

IBM 早期的 Ceph 版本已通过其他机制提升性能。Storage Ceph 8.0 包含快照改进，并继续将 Crimson 后端作为技术预览提供。

Crimson 是一种围绕异步处理和现代 CPU 效率设计的新型 OSD 架构。它所解决的软件执行问题范围，比元数据溢出更广。

9.9.0 版本还默认启用了针对新建存储池的纠删码优化。IBM 表示，这些优化可减少填充，并改善受支持配置下的小 I/O 表现。

这一变化有利于包含小对象或随机访问的 RBD、CephFS 和对象工作负载。根据 IBM 的优化指南，大型顺序对象工作负载获得的收益较小。

综合来看，这些进展展现出分层策略。IBM 正在改进数据保护效率、OSD 执行、元数据放置、协议管理和管理工作流。

BlueFS Spillover Cleaner 尤为突出，因为它解决了高速与低速存储之间的即时错配问题。它承诺在无需应用修改的情况下改善运行表现。

如今的竞争问题可以量化：软件驱动的放置能否带来足够的提升，从而推迟硬件扩容，还是仅仅缓解了一个有限的瓶颈？

IBM 的性能主张尚未说明什么

此次发布提出了可信的机制，但 IBM 尚未提供足够数据来量化其在生产工作负载中的效果。

IBM 的公告和初步报道均未包含 BlueFS Spillover Cleaner 的标准化基准测试结果。没有已发布的 IOPS、吞吐量或延迟对比数据，以比较启用和未启用该功能的配置。

IBM 也没有提供尾延迟分布。这一缺失很重要，因为更稳定的性能是其宣称的优势之一。

单靠平均值无法解答这一问题。买家需要百分位数据，以了解元数据溢出后，该功能是否能减少偶发的慢操作。

公告没有说明测试集群的配置。读者无法评估驱动器类型、DB 设备比例、网络速度、OSD 数量、副本设置或对象配置文件。

它也没有区分该功能对块、文件和对象访问的影响。每项服务对 RADOS 层提出的需求不同。

虚拟机工作负载可能侧重于小型随机块操作。S3 存储库可能包含大型顺序对象，而数据管道则可能产生数百万个小文件。

清理器的价值在这些场景之间可能存在显著差异。专注于刻意配置不足的 DB 设备的基准测试，可能会夸大其对配置充足集群的收益。

反过来，短期测试也可能低估该功能。自动分层需要足够的时间和工作负载变化，才能识别活跃文件并重新安排其位置。

后台迁移带来另一项不确定性。升级和降级会消耗 I/O 带宽，而此次发布没有衡量这一开销。

管理员应询问系统如何防止抖动。快速变化的工作负载可能导致文件在不同层级间反复切换，除非策略采用稳定的阈值。

他们还应审查恢复期间的行为。设备或节点故障后，Ceph 集群可能生成高强度的内部活动，而这正是可预测延迟变得重要的时候。

此次发布没有解释清理器在恢复期间是否暂停、调整优先级，或继续迁移文件。这些决策可能影响应用流量和修复时间。

升级行为同样值得关注。现有部署需要了解管理器是否自动启动、是否需要配置，或者是否会执行初始重新分布。

IBM 的公开摘要没有为每一种历史布局提供兼容性矩阵。买家应根据文档确认前提条件，并在投入生产前测试具有代表性的集群。

容量仍是硬性限制。清理器可以对元数据进行排序，但无法创造更多 DB 空间。若持续活跃的元数据集大于高速设备，仍然会发生溢出。

这种改进也可能暴露另一项限制。一旦元数据查找变快，网络饱和或 CPU 处理可能限制整体收益。

这并不否定 IBM 的设计。它只是界定了该主张的边界。

Ceph 架构指南描述了一个分布式系统，其行为取决于相互作用的存储、网络和软件组件。优化一条路径并不保证带来同等幅度的应用层改进。

因此，组织应将 IBM Storage Ceph 9.9.2 视为可测试的升级，而非可观测性的替代品。部署前，团队应记录基准延迟、吞吐量、设备利用率和溢出情况。

升级后，他们应重放具有代表性的工作负载。测试应包括稳态流量、突发工作负载变化、RocksDB 压缩、恢复和维护操作。

团队应比较百分位延迟，而不仅是平均值。他们还应追踪有多少数据在 DB 和 SLOW 设备之间迁移。

成功的结果应表明，更多活跃元数据保留在高速介质上，同时不会产生干扰性的后台活动。它还应体现应用层收益，而不仅是更整洁的存储布局。

独立基准测试对于采购尤为重要。IBM 将 Storage Ceph 作为软件、服务以及搭配认证硬件的产品提供。

这些部署模式不会产生完全相同的结果。买家需要与自身环境相似配置的证据。

谨慎的结论很直接。IBM 描述了一种在技术上可信的方法，用于减少 Ceph 延迟的一个来源，但公开证据尚未量化其影响。

三项信号将表明这一改进是否重要

下一个考验是，IBM 的放置机制能否在发布公告之外带来可重复的收益。

第一个信号是发布基准测试。IBM、合作伙伴或独立测试人员应在相同硬件上，对比启用和禁用清理器的 9.9.2 版本。

有价值的测试应包括搭配 NVMe DB 设备的硬盘数据设备。报告应涵盖平均和百分位延迟、IOPS、吞吐量、迁移开销以及 DB 层占用情况。

应分别覆盖虚拟机、小型 S3 对象、大型对象和 CephFS 元数据密集型操作。若改进在不止一种工作负载中保持一致，这些结果将增强 IBM 的主张。

若结果仅限于刻意受限的演示环境，则会削弱更广泛的解读。它们或许仍能证明该机制，但无法证明其普遍的生产价值。

第二个信号来自升级集群的运维证据。管理员应观察，在需求变化数周后，活跃的 RocksDB 文件是否仍保留在高速设备上。

稳定的行为将支持 IBM 的软件优化论点。频繁迁移、意外的写放大或难以调优，将使更大的 DB 设备和更简单的静态布局更具优势。

真实部署还应揭示清理器在恢复和压缩期间的表现。这些时期可区分真正有效的策略与仅针对理想实验室条件优化的策略。

第三个信号是 IBM 从功能描述转向详细生命周期指导。文档应说明默认设置、阈值、监控指标、告警、回滚行为和升级前提条件。

清晰的指导将表明 IBM 期待广泛的生产使用。有限的文档则意味着客户应通过受到密切监督的部署谨慎推进。

竞争对手和上游社区的回应也很重要，但居于次要位置。决定性证据将来自性能数据和运行经验，而非营销比较。

客户还应关注 IBM 对 Crimson 的持续投入。元数据分层改善文件放置，而 Crimson 则针对 OSD 软件路径内的效率。

如果两者都能成功成熟，IBM 就可以论证 Ceph 的性能限制正越来越能够通过软件解决。这将增强其相对于以硬件为中心的扩容和专有存储系统的竞争地位。

纠删码优化提供了另一个参考点。它们表明，IBM 已在其认为效率收益足够成熟的新存储池中改变默认行为。

只有当客户了解 BlueFS Spillover Cleaner 在持续负载下的行为后，它才能赢得类似信心。硬件故障或需求突然变化时，自动放置必须保持可预测。

更广泛的启示超越了 Ceph。现代存储系统越来越依赖协调更大容量池的小型高速介质层。

有效管理这一高速层可能与其标称容量同样重要。糟糕的放置会浪费闪存，而失控的迁移可能带来自身的性能代价。

IBM Storage Ceph 通过将元数据放置转化为主动过程来加速集群性能。即使没有醒目的基准测试数据，这也是一项有意义的架构变化。

然而，架构只是购买决策的起点。企业团队需要了解延迟降低多少、哪些工作负载受益，以及迁移伴随哪些运维成本。

此次发布为管理员提供了一项具体实验。识别存在 BlueFS 溢出的集群，建立基准，在受控环境中升级，并观察应用延迟和后台活动。

如果清理器能持续提升正确的文件，IBM 将证明软件能够从现有混合存储中恢复性能。如果收益仍然有限，硬件扩容将继续扮演其熟悉的角色。

目前，IBM Storage Ceph 9.9.2 值得关注，因为它以连贯的机制瞄准了一个具体瓶颈。下一步取决于运营人员和独立测试人员。

真实集群会否证实自动化元数据放置能够推迟下一次硬件采购，还是会揭示瓶颈只是转移到了别处？