从Ceph到高性能NVMe存储，场景需求有哪些变化？

全文概览

在数据爆炸式增长的今天，企业对存储系统的需求已不再仅仅是容量，高性能和低延迟变得前所未有的重要。特别是随着NVMe SSD技术的普及，存储介质的速度瓶颈被打破，新的挑战随之而来：如何构建能够充分释放闪存潜力的存储架构？

传统的存储系统，如广泛应用的Ceph，以其强大的通用性、可扩展性和丰富的功能集赢得了市场。然而，其诞生于机械硬盘时代的复杂架构，在面对微秒级响应的NVMe SSD时，是否还能保持竞争力？与此同时，一种为闪存时代而生的“专家”级解决方案——原生NVMe over TCP (NVMe/TCP)——正崭露头角，它以极致简化的I/O路径，承诺带来前所未有的性能飞跃。

那么，在高性能存储的十字路口，我们该如何抉择？是选择功能全面的“通才”Ceph，并期待其架构重塑的未来？还是拥抱为速度而生的“专家”原生NVMe/TCP？本文将深入剖析这两种截然不同的存储哲学，对比它们的架构、性能、效率与管理复杂性，帮助您理解在闪存时代，哪种方案更能满足您对极致性能的渴望。

阅读收获

• 理解为何原生NVMe/TCP架构在IOPS和延迟方面能大幅领先传统Ceph。
• 掌握两种架构在硬件资源消耗、能耗和总体拥有成本（TCO）上的显著差异。
• 认识到Ceph为适应高性能需求所进行的架构重塑（Crimson项目）及其当前进展。
• 学会如何根据具体工作负载（如数据库、AI/ML vs 数据湖、备份）和运维能力，选择最适合的存储架构。

架构的十字路口：高性能SSD时代下原生NVMe/TCP与Ceph的比较分析

1.0 摘要

本报告对两种截然不同的存储架构进行了深入分析：原生NVMe over TCP (NVMe/TCP) 解决方案和传统的Ceph存储平台。前者是为高性能块存储量身定制的“专家”，而后者作为一个功能全面的“通才”，正在经历重大的架构重塑，以适应NVMe闪存带来的低延迟需求。

核心发现概要

• 性能鸿沟显著：原生NVMe/TCP架构在IOPS和延迟方面表现出压倒性优势。基准测试显示，由于其高度简化的I/O路径和消除了传统软件开销，其性能可达Ceph的4倍，而硬件资源仅需后者的25% 1。
• 架构效率差异：Ceph凭借其统一存储（块、文件、对象）和成熟的生态系统展现了无与伦比的多功能性。然而，其传统架构即便通过NVMe/TCP网关接入，其固有的多层处理逻辑仍在NVMe SSD环境下引入了显著的延迟和CPU开销，成为性能瓶颈 1。
• 硬件与能耗效益：在实现相同性能目标的前提下，原生NVMe/TCP解决方案的硬件规模和能耗足迹远低于Ceph，这将直接影响总体拥有成本（TCO）1。
• Ceph的未来演进：Ceph的“Crimson”项目是一项长期的战略性重构计划，旨在通过采用现代化的内核旁路（kernel-bypass）技术来弥补性能差距。然而，该项目目前仍处于技术预览阶段，尚未达到生产可用级别 5。

战略建议概述

技术选型并非判断“优劣”，而是寻求“适配”。对于延迟极度敏感的高性能块存储工作负载，如数据库、人工智能/机器学习（AI/ML）和实时分析，原生NVMe/TCP是理想选择。而对于需要经济高效、PB级以上、多协议支持且对极致低延迟要求不高的场景，Ceph依然是强有力的竞争者。Crimson项目的成熟度将是决定Ceph未来在高性能领域竞争力的关键变量，值得持续关注。

Cite

1. Crimson项目背景与特性

• Crimson项目旨在解决现代硬件性能提升与Ceph存储系统原有架构不匹配的问题，通过重新设计Ceph OSD，提供更高性能和扩展性。
• 核心特性包括：shared-nothing设计、run-to-completion模型和基于Seastar框架，优化了多核环境下的性能表现。

2. Crimson在Ceph系统中的角色

• Crimson作为新的OSD实现，是Ceph系统的核心组件之一，支持LIBRADOS、RADOSGW等多种接口和协议，优化了数据分布和存储效率。

3. 技术实现与优化

• 采用多核线程模型和Seastar框架，通过分片架构和跨核心通信机制，显著提升了I/O性能和资源利用率。
• 详细介绍了Crimson的软件栈、线程模型及全局数据共享机制，确保高效的数据一致性和扩展性。

推荐阅读： Intel：Crimson优化Ceph OSD引擎

2.0 架构深度剖析：网络块存储的两种哲学

本章节将深入探讨两种系统设计的核心理念，重点分析I/O请求从客户端到物理存储介质的处理流程。

2.1 原生NVMe/TCP模型：直达闪存的快车道

原生NVMe/TCP技术的核心思想是将轻量级的NVMe命令直接封装在TCP报文中，利用无处不在的标准以太网基础设施进行传输 8。这种方法将NVMe协议的高效性从本地PCIe总线延伸至整个网络，且无需像RDMA或光纤通道（Fibre Channel）那样依赖昂贵的专用硬件。

其典型的软件定义存储（SDS）架构，如Lightbits或simplyblock所采用的，是一种解耦式设计。它由运行在客户端的驱动程序和运行在商用服务器上的目标端软件组成，共同为客户端提供一个简单的块设备接口 4。这种架构是为NVMe/TCP协议“原生”设计的，意味着整个软件堆栈都为之进行了深度优化，以求达到最高效率 1。

I/O路径分析

原生NVMe/TCP的写入路径极为精简，其关键在于缺少复杂的中间处理层，从而最大程度地降低了延迟。

1. 客户端应用程序发起一个块I/O写入请求。
2. 主机操作系统中的NVMe/TCP驱动程序将NVMe命令和数据封装成一个或多个协议数据单元（PDU）。
3. 主机的标准TCP/IP协议栈将这些PDU分段为TCP数据包，通过以太网卡发送出去。
4. 目标服务器的TCP/IP协议栈接收并重组数据包，还原为PDU。
5. 目标服务器的NVMe/TCP目标端软件接收并处理NVMe命令，随后将数据直接写入底层的NVMe SSD。

这种从主机内核到网络，再到目标端内核和存储的直接路径，与Ceph的多守护进程、多阶段处理流程形成了鲜明对比。

2.2 传统Ceph模型：多功能性与可扩展性的典范

Ceph是一个统一的、分布式的存储系统，能够从单一集群同时提供对象、块和文件存储服务 2。其核心是可靠的、自动化的分布式对象存储（RADOS）。

架构组件

• Monitors (MONs): 维护集群状态和映射表（Maps），是集群的“大脑” 15。
• Object Storage Daemons (OSDs): 负责在物理驱动器上处理数据的存储、复制、恢复和再均衡 15。
• Managers (MGRs): 提供运行时指标和外部管理API，如Ceph仪表盘 15。
• CRUSH算法: Ceph的精髓所在，它能通过计算确定性地定位数据，而无需依赖中央查找表，从而实现了大规模的可扩展性 2。
• BlueStore: Ceph现代的默认存储后端。它直接管理裸块设备，绕过了传统的文件系统层，旨在提升在SSD等固态硬盘上的性能 18。

I/O路径分析（RBD写入）

与原生NVMe/TCP相比，Ceph的块设备（RBD）写入路径要复杂得多，涉及多个组件的协同工作。

1. 客户端应用程序（如虚拟机）向RBD设备发起块I/O写入请求。
2. 客户端的librbd库接收请求，并计算出该写入操作对应的RADOS对象和归属的放置组（Placement Group, PG）14。
3. librbd使用从MON获取的CRUSH Map，计算出该PG的主OSD（Primary OSD）。
4. 客户端通过TCP/IP网络直接与主OSD建立连接。
5. 主OSD接收写入请求，并通过其后端存储引擎BlueStore，将数据和元数据（由RocksDB管理）提交到本地的NVMe SSD 20。
6. 同时，主OSD将写入请求复制到该PG acting set中的另外两个副本OSD（Secondary/Tertiary OSDs）。
7. 副本OSD将数据写入各自的本地存储，并向主OSD发送确认信息。
8. 主OSD在收到所有副本的确认后，才向客户端的librbd发送最终的写入完成确认。

2.3 架构的传承与演进：历史包袱与专业化

Ceph的架构诞生于机械硬盘（HDD）主导的时代。在那个时代，存储介质本身延迟高、速度慢，网络很少成为瓶颈。因此，Ceph复杂的架构（如CRUSH、PGs、多副本复制）是为管理大规模、不可靠、低速介质上的数据而设计的绝佳方案，其核心在于数据的可靠放置和弹性。

相比之下，原生NVMe/TCP架构则诞生于高速、低延迟的闪存时代。其设计哲学的前提是存储介质本身速度极快，因此网络协议必须尽可能轻量化，以避免自身成为新的性能瓶颈。

这种历史背景的差异导致了一个关键结果：当与高性能NVMe SSD结合时，Ceph曾经最大的优势——其复杂的分布式逻辑——在某种程度上转变成了“架构包袱”。其I/O路径中的每一步，包括librbd的逻辑计算、主OSD的处理、副本间复杂的协调机制，都会累加微秒级的延迟。这些延迟在HDD时代可以忽略不计，但在响应时间低于100微秒的NVMe硬盘面前，则变得极为突出。

反观原生NVMe/TCP解决方案，它们是纯粹的“专家”。它们放弃了Ceph那种通用的文件、块、对象支持能力，转而将所有资源用于极致优化一件事：高性能块存储。这种没有历史包袱的专注，正是其性能优势的根源。因此，两种架构的核心差异不仅是技术层面的，更是设计哲学层面的。Ceph是一个通用的数据平台，正在努力适应新的技术范式；而原生NVMe/TCP解决方案则是为这个新范式而生的专用工具。

3.0 对比分析：效率、简易性与性能

本节将基于实证数据，对用户关心的关键指标进行直接比较。

3.1 存储路径与协议开销

• Ceph：其I/O路径涉及多个逻辑步骤和守护进程。CPU开销主要来源于librbd的计算、CRUSH查找、OSD守护进程的处理、BlueStore通过RocksDB进行的元数据管理，以及维护复制状态机的复杂工作 2。即使引入了NVMe/TCP网关，其本质仍是在现有复杂的RADOS块设备路径之上叠加了一个新的协议层，而非原生实现 1。这导致了更高的CPU使用率，尤其是处理TCP/IP协议栈所需的系统态CPU消耗 21。
• 原生NVMe/TCP：路径更为直接。其主要的CPU开销来自于主机和目标端的TCP/IP协议栈处理 8。虽然这比完全由硬件（如RDMA网卡）卸载的开销要高，但与Ceph多层次的软件处理开销相比则要低得多 8。此外，NVMe/TCP协议本身比iSCSI更轻量，后者还需进行额外的SCSI命令封装 8。

这里的关键在于理解“CPU开销”的构成。原生NVMe/TCP的开销主要来自传输协议（TCP）本身。而Ceph的开销则是传输协议加上分布式存储逻辑（CRUSH、复制、PG状态管理等）的总和。这个根本性的区别解释了两者之间的性能差距。

3.2 硬件足迹与能耗状况

• Ceph硬件要求：
  • CPU：要求苛刻。为避免瓶颈，推荐配置从每个HDD OSD 1-2个核心，到每个NVMe OSD 4-8个甚至更多核心 23。需要大量的CPU核心来处理OSD进程、数据复制和后台恢复等任务。
  • 内存：需求巨大。经验法则是每TB HDD存储需要约1GB内存。而对于NVMe上的BlueStore，osd_memory_target默认即为4GB，实际推荐为每个OSD配置8GB以上内存，以应对缓存和数据恢复时的开销 25。一个大型集群的MON/MGR节点可能需要64GB至128GB内存 25。
  • 功耗：由于需要更强的CPU和更多的内存来驱动性能，单个节点的功耗相对较高 28。
• 原生NVMe/TCP硬件要求：
  • CPU/内存：对存储逻辑本身的要求较低。目标端服务器的CPU和内存主要用于高速处理网络流量（如25/100GbE）8。其架构的高效率意味着可以用更少、配置更低的节点来提供更高的性能 1。
  • 功耗：在提供同等性能水平的情况下，由于集群规模更小、效率更高，其功耗也更低。例如，Lightbits就明确将其产品“减少数据中心足迹和提高能效”作为核心优势进行宣传 4。

表1：高性能目标节点硬件与能耗对比

下表对两种架构在实现高性能目标时的单节点资源需求进行了概括，这对于进行总体拥有成本（TCO）分析至关重要。它将抽象的性能指标转化为具体的资本支出（CapEx）和运营支出（OpEx）考量。

3.3 存储管理与运维复杂性

• Ceph：
  • 部署：一个多步骤的过程，包括集群引导、添加主机、部署MON/MGR/OSD、创建存储池和配置CRUSH规则。尽管cephadm等工具简化了流程，但底层的复杂性依然存在 31。
  • 管理：要求管理员对Ceph的核心概念（PGs、CRUSH Maps、OSD状态等）有深入理解。日常工作包括监控集群健康、管理用户、处理OSD故障替换和性能调优等 34。Ceph功能强大，但学习曲线陡峭。
• 原生NVMe/TCP (例如Lightbits, NetApp)：
  • 部署：更接近传统的SAN管理体验。工作流通常包括部署集群软件（常通过CloudFormation等模板）、发现主机（通过NQN）、创建卷（命名空间）并将其映射到指定主机 37。集中式发现控制器（CDC）的引入进一步简化了这一过程，其功能类似于光纤通道的分区（Zoning）41。
  • 管理：管理员的关注点集中在卷级别的操作（创建、快照、扩容）和通过图形界面或专用CLI监控集群健康。底层的分布式复杂性在很大程度上被抽象和隐藏了 37。

这两种管理模式的差异，根植于它们不同的设计哲学。原生NVMe/TCP解决方案优先考虑抽象化，旨在隐藏分布式系统的复杂性，提供一种类似SAN的简洁管理体验，其目标是运维简单。而Ceph则优先考虑控制力，它向管理员暴露了其内部的运行机制（如CRUSH规则、存储池参数），提供了巨大的灵活性，允许用户根据特定需求定制数据放置和冗余策略。这种差异也反映了它们的起源：SAN一直致力于将存储抽象为LUN，而Ceph则诞生于对大规模分布式环境中数据进行灵活、透明控制的需求。因此，“更好”的管理模式取决于组织的具体需求和技术能力。

4.0 NVMe的挑战：Ceph的适应与未来之路

本节将聚焦于两种技术间的核心张力，通过性能数据分析Ceph为应对挑战所采取的战略性举措。

4.1 压力下的性能：NVMe工作负载基准测试

公开的基准测试一致表明，在NVMe硬件上，原生NVMe/TCP解决方案的性能远超Ceph。例如，simplyblock声称其产品能用25%的NVMe驱动器数量，实现超过Ceph 4倍的IOPS 1。Lightbits的测试也显示，与Ceph相比，其带宽更高，延迟更低 43。

造成这种性能差距的核心原因在于，Ceph的NVMe/TCP支持是一种在其现有架构之上叠加的“网关”模式，而非从头开始的原生实现。它无法摆脱librbd和OSD数据路径中固有的延迟 1。Ceph官方也承认，随着吞吐量需求的增加，其延迟会随之上升，这是软件成为瓶颈的典型迹象 3。尽管Ceph的性能可以线性扩展，但其性能基线较低，因此即使线性增长，其总体性能仍然落后于基线更高的系统 1。

表2：聚合性能基准测试摘要

下表量化了前述的架构差异，为高层决策者提供了直观的证据，证明架构选择对性能和效率有巨大且可衡量的影响。

注：数据来源于不同厂商的基准测试，硬件和测试条件可能存在差异，但总体趋势具有参考价值。

4.2 Crimson：Ceph应对高性能时代的回应

Ceph社区清醒地认识到，BlueStore虽然相较于其前身FileStore有了巨大改进，但仍不足以完全释放NVMe的潜力。因此，一项根本性的重新设计势在必行。Crimson项目应运而生，其目标是从零开始构建一个全新的ceph-osd，专为低延迟、高吞吐量的存储设备而优化 5。

Crimson的技术核心包括：

• Seastar框架：基于专为高性能应用设计的C++框架Seastar。它采用“每核心一线程”的无共享（shared-nothing）架构，从根本上消除了锁竞争和线程上下文切换的开销 5。
• 内核旁路（Kernel Bypass）：利用SPDK（用于存储）和DPDK（用于网络）等库，让应用程序直接与硬件通信，绕过操作系统内核及其带来的性能开销 5。
• SeaStore：与Crimson并行开发的一个全新的、原生的对象存储后端，它遵循与Seastar相同的设计原则，专为高速设备打造 7。

Crimson的终极目标是最小化每个I/O操作的CPU周期消耗和跨核通信，实现性能随CPU核心数线性增长，直至硬件饱和 5。

然而，截至目前，Crimson仍处于技术预览阶段。它仅支持基础的RBD工作负载，与经典的OSD相比，在功能上仍有差距（如完整的纠删码支持、RGW网关支持等仍在开发中），因此官方不建议在生产环境中使用 5。

4.3 开源世界的“创新者窘境”

Ceph是一个非常成功、成熟的开源项目，拥有庞大的用户基础和丰富的功能集，其成功建立在现有架构之上。然而，NVMe技术的出现，对Ceph现有设计的性能竞争力构成了颠覆性的挑战。

对于Ceph项目而言，简单地抛弃现有的ceph-osd并用Crimson取而代之是不可行的。这会疏远现有用户，破坏兼容性，并扰乱整个围绕Ceph建立的生态系统。因此，Ceph项目面临着一个典型的“创新者窘境”：它必须继续支持和改进其成熟、稳定的现有产品（经典OSD + BlueStore），以服务于绝大多数用户；同时，又必须投入巨资开发一个颠覆性的新架构（Crimson），而这个新架构在未来某天可能会取代前者。

这对技术选型者意味着，在可预见的未来，市场上将存在两个“Ceph”：一个稳定、功能丰富、适用于通用工作负载的Ceph，以及一个新兴的、性能卓越但尚不成熟的基于Crimson的Ceph。潜在用户在做选择时，不仅是在选择一个产品，更是在对这场历时数年的大规模架构转型的速度和成功率进行一次战略性押注。这是一个重大的风险与回报并存的决策。

5.0 结论与战略建议

本节将综合所有分析，提供一个清晰的决策框架，避免给出一个简单的“赢家”，而是根据具体需求提供细致的指导。

5.1 推荐框架：将架构与工作负载相匹配

• 选择原生NVMe/TCP，如果：
  • 您的核心工作负载是高性能、延迟敏感的块存储，如交易型数据库（Oracle等）、高频交易平台、实时分析等。
  • 运维简单和类似SAN的管理体验是优先考虑的因素。
  • 通过提升单位性能的硬件和能耗效率来优化总体拥有成本（TCO） 是关键的业务驱动力。
  • 您当前没有从同一平台获得统一文件或对象存储的迫切需求。
• 选择传统Ceph (采用BlueStore)，如果：
  • 您需要一个统一平台来提供块、文件和对象存储，以避免存储孤岛。
  • 您的主要需求是以经济高效的每GB成本实现海量的、从PB到EB级别的扩展，并且可以容忍相对较高的延迟。
  • 您的工作负载对吞吐量敏感，但对极致低延迟不敏感，如数据湖、备份归档、通用云计算虚拟机等。
  • 您拥有或愿意投入资源培养能够管理一个复杂、高度灵活的分布式系统的内部技术专长。

5.2 “观望”策略：密切关注Crimson项目

对于需求混合或希望对未来技术进行布局的组织而言，Crimson项目的成熟度是需要关注的最重要趋势。

需要监控的关键里程碑：

1. 生产就绪状态：项目达到生产可用级别，并与经典OSD在核心功能上（尤其是纠删码和RGW支持）实现对等。
2. 独立性能评测：出现第三方对生产就绪的Crimson集群进行的独立、可信的性能基准测试。
3. 明确的升级路径：社区提供从经典Ceph到Crimson的清晰、无缝的升级方案。

5.3 最终展望

存储市场正在经历一次分化。原生NVMe/TCP解决方案的崛起，为高性能、专业化的块存储开辟了一个独特的市场，迫使通用平台做出回应。Ceph与Crimson的演进之路，正是在颠覆性硬件创新面前，所有成熟软件平台所面临挑战的缩影。其转型的成功与否，将决定它在未来十年高性能存储领域的地位。

对于任何组织而言，最终的决策都应建立在对其特定工作负载需求、运维能力以及战略风险偏好的清醒评估之上，从而选择是拥抱一个正在积极适应的成熟平台，还是一个为新时代而生的专业化解决方案。

===

参考资料

1. 4x Faster with 75% Less Hardware: Simplyblock vs Ceph | simplyblock, accessed July 13, 2025, https://www.simplyblock.io/blog/simplyblock-versus-ceph-40x-performance/
2. Architecture - Ceph Documentation, accessed July 13, 2025, https://docs.ceph.com/en/reef/architecture
3. Performance at Scale with NVMe over TCP - Ceph.io, accessed July 13, 2025, https://ceph.io/en/news/blog/2025/nvme-gateway-perf-mb/
4. Lightbits Labs: Software-Defined Storage - Block Storage, accessed July 13, 2025, https://www.lightbitslabs.com/
5. IBM Storage Ceph – Administration, Crimson Crimson project crimson-osd Crimson goals Seastar features, accessed July 13, 2025, https://www.ibm.com/docs/en/storage-ceph/7.1.0?topic=administration-crimson-technology-preview
6. IBM Storage Ceph Crimson (crimson-osd), accessed July 13, 2025, https://www.ibm.com/docs/en/storage-ceph/8.0.0?topic=administration-crimson-technology-preview
7. Ceph.io — Crimson Project, accessed July 13, 2025, https://ceph.io/en/news/crimson/
8. NVMe over TCP: Benefits, Drawbacks, and Implementation Strategies, accessed July 13, 2025, https://www.starwindsoftware.com/blog/what-is-nvme-over-tcp/
9. NVMe over TCP: What's All the Fuss? - Lightbits Labs, accessed July 13, 2025, https://www.lightbitslabs.com/blog/nvme-over-tcp-whats-all-the-fuss/
10. TCP Transport Specification - NVM Express, accessed July 13, 2025, https://nvmexpress.org/specification/tcp-transport-specification/
11. Understanding NVMe-over-TCP, the simplest NVMe SAN storage - Lightbits Labs, accessed July 13, 2025, https://www.lightbitslabs.com/news/understanding-nvme-over-tcp-the-simplest-nvme-san-storage/
12. Lightbits Cluster Architecture, accessed July 13, 2025, https://documentation.lightbitslabs.com/cloud-documentation-azure/lightbits-cluster-architecture
13. Lightbits Labs Unveils Industry's First Scalable Kubernetes Storage Solution for High Performance Block and AI Workloads with AMD, accessed July 13, 2025, https://www.lightbitslabs.com/press-releases/lightbits-labs-unveils-industrys-first-scalable-kubernetes-storage-solution-for-high-performance-block-and-ai-workloads-with-amd/
14. Architecture - Ceph Documentation, accessed July 13, 2025, https://docs.ceph.com/en/octopus/architecture/
15. What is Ceph Architecture? - Platina Systems, accessed July 13, 2025, https://www.platinasystems.com/post/what-is-ceph-architecture
16. Ceph: Scalable and Resilient Distributed Storage Solution - StarWind, accessed July 13, 2025, https://www.starwindsoftware.com/blog/what-is-ceph-and-ceph-storage/
17. Chapter 1. The Ceph architecture - Red Hat Documentation, accessed July 13, 2025, https://docs.redhat.com/en/documentation/red_hat_ceph_storage/4/html/architecture_guide/the-ceph-architecture_arch
18. Red Hat Ceph Storage 3.3 BlueStore compression performance, accessed July 13, 2025, https://www.redhat.com/en/blog/red-hat-ceph-storage-33-bluestore-compression-performance
19. Ceph - Mark's DevOps 雜碎, accessed July 13, 2025, https://devops-insider.mygraphql.com/zh-cn/latest/ceph/ceph.html
20. Ceph.io — New in Luminous: BlueStore, accessed July 13, 2025, https://ceph.io/en/news/blog/2017/new-luminous-bluestore/
21. Accelerating Ceph with RDMA and NVMe-of, accessed July 13, 2025, https://www.openfabrics.org/images/2018workshop/presentations/206_HTang_AcceleratingCephRDMANVMe-oF.pdf?a7362a&a7362a
22. NVMe Transport Performance Comparison - Dell, accessed July 13, 2025, https://www.delltechnologies.com/asset/en-gb/products/storage/industry-market/h18892-nvme-transport-performance-comparison.pdf
23. Hardware requirements and recommendations | SES 7.1 - SUSE Documentation, accessed July 13, 2025, https://documentation.suse.com/en-us/ses/7.1/html/ses-all/storage-bp-hwreq.html
24. CPU requirements for CEPH - Reddit, accessed July 13, 2025, https://www.reddit.com/r/ceph/comments/1cc0vgv/cpu_requirements_for_ceph/
25. Hardware Recommendations - Ceph Documentation, accessed July 13, 2025, https://docs.ceph.com/en/reef/start/hardware-recommendations/
26. Hardware Recommendations - Ceph Documentation, accessed July 13, 2025, https://docs.ceph.com/en/mimic/start/hardware-recommendations/
27. Questions about using CEPH on low power storage node for ml : r/homelab - Reddit, accessed July 13, 2025, https://www.reddit.com/r/homelab/comments/12u85qo/questions_about_using_ceph_on_low_power_storage/
28. Build Log - Ceph Cluster - Homelab redesign - Level1Techs Forums, accessed July 13, 2025, https://forum.level1techs.com/t/build-log-ceph-cluster-homelab-redesign/230371
29. Chapter 2. Ceph Storage node requirements - Red Hat Documentation, accessed July 13, 2025, https://docs.redhat.com/en/documentation/red_hat_openstack_platform/14/html/deploying_an_overcloud_with_containerized_red_hat_ceph/ceph-storage-node-requirements
30. What CPU for LOW power ceph cluster | ServeTheHome Forums, accessed July 13, 2025, https://forums.servethehome.com/index.php?threads/what-cpu-for-low-power-ceph-cluster.36769/
31. Setting up a Ceph storage cluster: a time-saving tutorial for DevOps/Sysadmins - Medium, accessed July 13, 2025, https://medium.com/cubbit/setting-up-ceph-storage-cluster-tutorial-50f101cc695d
32. Admin Tasks - Ceph Deployment - Ceph Documentation, accessed July 13, 2025, https://docs.ceph.com/en/mimic/rados/deployment/ceph-deploy-admin/
33. IBM Storage Ceph – Installing, Initial installation, accessed July 13, 2025, https://www.ibm.com/docs/en/storage-ceph/7?topic=installing-initial-installation
34. Administration Guide | Red Hat Ceph Storage | 5, accessed July 13, 2025, https://docs.redhat.com/en/documentation/red_hat_ceph_storage/5/html-single/administration_guide/index
35. Admin Guide - Ceph Documentation, accessed July 13, 2025, https://docs.ceph.com/en/quincy/radosgw/admin/
36. Chapter 1. Ceph Administration Overview - Red Hat Documentation, accessed July 13, 2025, https://docs.redhat.com/en/documentation/red_hat_ceph_storage/3/html/administration_guide/ceph-administration-overview-admin
37. Lightbits LightOS Administrator's Guide, accessed July 13, 2025, https://www.lightbitslabs.com/wp-content/uploads/2023/01/LightOS_Administrators_Guide_V2_3_12.pdf
38. Lightbits AWS Deployement Guide, accessed July 13, 2025, https://www.lightbitslabs.com/wp-content/uploads/2023/01/Lightbits_AWS_Admin_Guide.pdf
39. NVMe/TCP as supplemental storage for VI Workload Domains - Product documentation, accessed July 13, 2025, https://docs.netapp.com/us-en/netapp-solutions/vmware/vmw-vcf-viwld-supplemental-nvme.html
40. Provisioning NVMe/TCP for Linux - FSx for ONTAP - AWS Documentation, accessed July 13, 2025, https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/provision-nvme-linux.html
41. Centralized Discovery using SFSS | Technical Overview of NVMe/TCP, accessed July 13, 2025, https://infohub.delltechnologies.com/l/technical-overview-of-nvme-tcp/centralized-discovery-using-sfss/
42. Lightbits Administrator's Guide, accessed July 13, 2025, https://www.lightbitslabs.com/wp-content/uploads/2023/01/Lightbits_Administrators_Guide_V3_4_1.pdf
43. Ceph Storage Comparisons - Performance - Lightbits Labs, accessed July 13, 2025, https://www.lightbitslabs.com/blog/lightbits-evolution-beyond-ceph-storage/
44. IBM Storage Ceph - Performance at Scale with NVMe over TCP and IBM X5D Ready Nodes, accessed July 13, 2025, https://community.ibm.com/community/user/blogs/mike-burkhart/2024/12/20/ibm-storage-ceph-71-performance

延伸思考

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

1. 除了技术性能，在实际企业环境中，团队的技术储备、现有基础设施兼容性以及厂商支持等因素，在多大程度上会影响最终的存储架构选择？
2. 随着存储介质技术（如QLC、SMR）和网络技术（如CXL）的持续演进，未来高性能存储架构将面临哪些新的挑战和机遇？原生NVMe/TCP和Ceph又将如何应对？

Notice：Human's prompt, Datasets by Gemini-2.5 #Ceph云存储 #NVMe高性能存储