介绍

当前，使用全 NVMe 存储的需求，彻底改变了 Ceph 的存储能力及其竞争领域。多年来，Ceph 凭借能够使用普通的常规硬盘（HDD） 以高性价比的特性被大量使用。这使其成为满足海量对象存储需求的首选。但是，机械磁盘的物理速度总是限制其性能，当涉及到需要极高性能，极高响应速度的应用场景时，总是不如一些专用的商业存储。

NVMe （Non-Volatile Memory Express） 给了 Ceph 一个比较好的选择，让 Ceph 能够打破性能瓶颈。

当将 Ceph 的智能分布式软件与每秒可以处理数百万次作且延迟接近零的 NVMe 存储相结合时，我们将得到一个可以与高端专用的商业存储正面交锋的解决方案。这也为 Ceph 在私有云和混合云中运行要求苛刻的应用（如大规模数据库、AI/ML 训练和高性能计算） 提供了比较好的解决方案。

但要获得这种性能，并非简单地将原来 HDD 旧硬盘换成新 NVMe 驱动器那么简单。硬件的原始速度非常快，但是，依然会在系统的其他地方存在一些新的性能瓶颈。如果没有适当的调优，最终可能只获得新驱动器的十分之一性能。运行一个高性能的全 NVMe Ceph 集群实际上是一项挑战：必须在 CPU、网络和软件设置中找出并消除瓶颈，以充分发挥闪存存储的全部性能。

性能潜力

当进行过正确的架构和调优时，全 NVMe Ceph 集群的性能确实令人惊叹。最近 Ceph 版本的基准测试报告显示，其性能已稳居高性能存储之列。

例如，在一个包含 10 个节点、60 个 NVMe 驱动器 并运行 Ceph Reef 的集群上进行的详细测试，产生了一些惊人的结果。该集群实现了约 440 万的随机读取 IOPS（每秒输入/输出操作）和 71 GB/s 的大文件持续读取速度。在数据写入方面，它处理了约 80 万的随机写入 IOPS。由于 Ceph 默认会为使用三个副本来确保安全，这实际上意味着整个集群的驱动器上发生了 240 万次写入操作。而对于需要即时响应的应用（如数据库），该集群的平均写入延迟保持在 0.5 毫秒以下。

需要注意的是，这些并非默认初始设置就可以达到的性能。它们来自一个特定的、均衡的硬件配置——在本例中是配备 AMD EPYC CPU 和三星 NVMe 驱动器的戴尔服务器——以及大量稍后将详细介绍的精心调优。这些基准测试表明，当有明确计划地构建集群时，可以实现什么。

来源：Ceph Reef RBD 性能基准: https://ceph.io/en/news/blog/2023/reef-freeze-rbd-performance/

读取和写入性能之间的最大差异归结为 Ceph 的工作原理。读取很简单：Ceph 只需从一个主存储守护程序 （OSD） 中获取数据。写入则更复杂。使用 3 倍复制时，Ceph 必须将数据发送到主 OSD，然后主 OSD 将其复制到其他两个 OSD。在将写入标记为完成之前，它必须得到所有 OSD 的确认。这一点，再加上 Ceph 的 BlueStore 后端为管理元数据所做的工作，使得写入数据自然比读取数据慢。 基准测试清楚地显示了这一点 ，随机操作的读取速度是写入的五倍以上，大文件的读取速度也快了近三倍。

通过这些，我们可以知道该集群适合那些场景。全 NVMe Ceph 非常适合数据分析、内容交付网络 （CDN） 和 AI 推理等读取密集型工作。对于数据库或日志记录等写入密集型任务，它仍然非常快，但需要确保性能是否是该应用期望的写入性能值，以尽可能提高写入效率。我们的目标不仅仅是购买更高性能的硬件，而是从一开始就构建一个完整的高性能存储系统。

基础：实现最佳性能的硬件和架构

在传统的的 Ceph 集群中，瓶颈几乎总是驱动器本身。而在全 NVMe 集群中，情况正好相反。NVMe 驱动器速度非常快，以至于影响性能压力往往是服务器的其他方面：CPU、内存和网络。这意味着我们必须采用相对均衡的方法来设计集群，选择每个组件以支持 NVMe 驱动器可以实现的大量 I/O。

CPU: 存储的新引擎

使用 NVMe，CPU 不再仅仅是运行操作系统，它也在主动驱动存储。每一次 I/O 操作都需要 CPU。Ceph 的算法需要计算数据存放位置，纠删码需要数学计算来创建校验位，校验和的计算是为了保证数据安全，而 BlueStore 后端使用的名为 RocksDB 的数据库也需要 CPU 算力来处理元数据。

测试表明，速度与为每个 NVMe 驱动器分配的 CPU 线程数成正比。在 Ceph Reef 版本中，单个 OSD 在大约 14-16 个 CPU 线程后性能提升就不再明显（https://docs.clyso.com/blog/reef-osds-per-nvme/）。这意味着需要具有大量核心的 CPU 来处理一台服务器上的多个 OSD。由 Clyso 构建的破纪录的 1 TiB/s 集群（https://www.clyso.com/us/a-journey-to-1-tib-s-a-milestone-in-performance/），在其 68 个节点中的每一个都使用了强大的 48 核 AMD EPYC 9454P CPU，以获得同时运行数百个 NVMe OSD 所需的并行处理能力（稍后会详细介绍）。在全 NVMe 构建中试图节省 CPU 开销，是导致集群缓慢、瓶颈的必然因素。

存储驱动器：企业级是硬性要求

构建全 NVMe Ceph 集群时，最大且代价最高的错误之一是使用消费级 NVMe 驱动器。它们前期看起来可能更便宜，但它们缺少企业存储绝对必需的两样东西：写入耐久性和掉电保护（PLP）。

企业应用，尤其是在像 Ceph 这样总是在后台工作的系统上，可能是写入密集型的。企业级 SSD 为此而生，企业级 SSD 有一个“每日驱动器写入次数”（DWPD）的评级，这个会表明在其 5 年保修期内，每天可以向整个驱动器写入多少次。以读取为主的的企业级驱动器通常 DWPD 低于 1，混合用途驱动器评级为 1 到 3，而以写入为主的可以超过 3。

更重要的是掉电保护。企业级驱动器板载电容器，在断电时，能提供足够的电力将驱动器临时缓存中的数据保存到永久闪存中。没有这个功能，可能会丢失正在写入过程中的数据，导致静默数据损坏。这对于依赖其日志和元数据完整性的 Ceph BlueStore 来说是致命的。正如一位在 Reddit 上尝试使用消费级驱动器的用户发现的那样，结果是“平庸”的速度和在任何实际写入负载下都“飙升”的延迟(https://www.reddit.com/r/ceph/comments/mp121c/ceph_nvme/)。

网络：集群的核心

网络是 Ceph 集群的神经系统。它处理从客户端流量和数据复制到重新平衡，以及最重要的——故障后恢复的所有事情。10GbE/10Gbps 网络可能是生产环境的最低要求，但对于全 NVMe 集群来说远远不够。基准测试表明，单个客户端读取大文件就可以完全占满一个 10GbE 链接。

对于严格的全 NVMe Ceph 集群的配置，都需要 25GbE、40GbE 甚至 100GbE 的网络。达到 1 TiB/s 的集群在每个节点中都使用了两张 100GbE 网卡，这表示在极高性能场景下需要什么样的带宽。网络速度不高快在恢复期间会成为最大的问题。当一个驱动器或服务器发生故障时，Ceph 开始将其数据复制到集群中的其他地方以恢复完全冗余。这会跑满网络。较慢的网络会使这个恢复窗口变得更长，使集群处于危险的降级状态，并增加再次故障导致数据丢失的风险。

合理的硬件

选择一个适合的硬件环境是非常重要的，也是实现超高性能存储的必备条件，这也是本文的目的。本文也将提供已经经过验证并准备好应对严苛的 OpenStack 和 Ceph 工作负载的硬件配置。像“Large”和“XL”这样的服务器选项提供了一个坚实的基础，配备了高核心数 CPU（16-32 核）、充足的 RAM（1TB）以及对每个服务器多个 NVMe 驱动器的支持。对于存储密集型需求，像 Large v3 这样的服务器混合了高容量 HDD 和 NVMe 闪存选项以加快速度。具体配置如下：

Large V2/V3/V4

• 16 核，32 线程

• 512GB 内存

• 2 个 6.4 TB NVMe SSD（每台服务器最多 6 个）

• 20Gbps 上行链路

XL V2/V3/V4

• 32 核，64 线程

• 1TB 内存

• 4 个 6.4 TB NVMe SSD（每台服务器最多 10 个）

• 20Gbps 上行链路

通过上述提供的这些预先验证的配置，免去了硬件选择的复杂性。下面就可以在一个准备好用于高性能私有云的平台上进行部署，从而避免一些可能导致系统缓慢和不稳定的常见错误。

硬件选择决定了集群的性能上限。再多的软件调优也无法弥补 CPU 性能不足、网络缓慢或驱动器不可靠的问题。顶级基准测试始终使用高核心数 CPU 和 100GbE 网络说明了一个明确的情况：顶级性能需要顶级硬件。这也需要成为预算规划的一部分。试图在 CPU 或网络上省钱来购买更多 NVMe 容量，只会留下一个不平衡的系统，无法满足对性能的期望。

关于集群的物理设计，还有一个重要的选择要做。现代服务器可以容纳十个或更多的 NVMe 驱动器，这带来了一个需要思考的新问题：服务器故障的“影响范围”。存储密集的节点更便宜，但如果其中一台服务器发生故障，会引发大规模的数据恢复事件。据估计，从一台丢失的 60 驱动器服务器中恢复可能需要长达两个月的时间，在此期间，集群一直处于高风险状态。这迫使我们必须在更少、更密集的节点（前期成本更低，但风险更高）和更多、密度更低的节点（成本更高，但风险更低、恢复更快）之间做出选择。这个决定不仅仅是涉及性能的考量，也是一个成本与风险的综合考量。

性能调优：系统和 Ceph 级别调优

第一步是从最基础的企业级硬件开始。但是，要让系统以及应用程序获取硬件的实际性能，需要进行一些针对性的调优。这些调优（范围从服务器的 BIOS 到 Ceph 的配置文件）区分普通集群和高性能集群的关键。通常，最大的好处是来自 Ceph 本身之外进行的更改。

系统级调优

在启动 Ceph 进程之前，通过最基础的两个优化，可以获取明显的性能提升。这两个最有效的更改是：关闭旨在节省电源和管理设备的功能，因为它们会增加延迟，这对高性能存储系统不利。

禁用 CPU 节能 （C-states）

现代 CPU 使用 C-states 的节能模式，在空闲时消耗更少的资源。当 CPU 核心无事可做时，操作系统可以将其置于“睡眠”状态（C1、C2 等），关闭其时钟和缓存等部分以节省电力。这对于台式机来说哼不错，但对于需要始终保持快速的存储系统来说，却是性能杀手。

CPU 从深度 C-state “唤醒”的过程不是瞬时的；它会增加一个微小但关键的延迟。对于像 Ceph 这样需要在微秒内响应请求的存储系统，这种唤醒延迟会使性能不一致。我们可以发现，仅仅在服务器 BIOS 中关闭 C-states，就立即为他们带来了 10-20% 的性能提升。对于任何全 NVMe Ceph 配置，将 CPU 设置为“性能”模式并禁用 C-states 是必须做的第一步。

禁用 IOMMU （VT-d/AMD-Vi）

输入/输出内存管理单元（IOMMU）是一种硬件功能，它为设备创建一个虚拟内存层。它允许将设备直接传递给虚拟机，并保护系统内存免受故障设备的影响。

但这种保护是有代价的。IOMMU 必须为每一次 I/O 操作转换内存地址，这会给每个请求增加一点开销和延迟。在一个受信任的、专用的存储环境中，这个转换层是一个不必要的性能损失。Clyso 团队发现大量 CPU 时间被浪费在与 IOMMU 相关的操作上。在内核级别关闭 IOMMU，通过消除这种开销，为他们带来了“实质性的性能提升”。虽然这不适用于所有环境，但对于裸机、以性能为中心的 Ceph 集群来说，这是一个关键的优化。

一个 NVMe，到底该配几个 OSD？

对 Ceph 而言，做出的最大调优决策之一是在每个 NVMe 驱动器上运行多少个 OSD 守护进程。过去，由于闪存速度较慢，因此每个驱动器运行多个 OSD 是提高其性能的好方法。对于当今的超高速 NVMe 驱动器和现代 Ceph，选择变得更加复杂。这是原始速度和一致延迟之间的直接权衡 。

使用 Ceph Reef 的测试显示了两种主要策略：

• 每个 NVMe 一个 OSD： 这是最简单的设置。它通常提供写入大型顺序文件的最佳速度，并且在 CPU 上更容易。如果集群没有大量额外的 CPU 能力，或者主要作业是流式传输大文件，例如用于视频存储或备份，则建议使用此默认值。

• 每个 NVMe 两个 OSD： 此设置需要更多的 CPU 和内存，但对于对延迟敏感的应用程序来说，它有很大的优势。测试表明，每个驱动器运行两个 OSD 可以将第 99 个百分位的尾部延迟减少一半。它还可以在 CPU 密集型环境中获得更多 IOPS（例如，如果每个 NVMe 驱动器有 16 个或更多 CPU 线程）。这使其成为虚拟桌面 （VDI） 或数据库等的更好选择，在这些应用中，可预测的快速响应时间比获得绝对的最大吞吐量更重要。

这里没有正确或错误的答案。这是关于将集群的设置与主要应用程序的需求相匹配。我们必须了解，优化平均延迟与优化尾部延迟不同，后者是用户的实际感受。

必要的 ceph.conf 和 BlueStore 设置

除了 OSD 布局之外，其他一些 Ceph 设置也是性能的关键：

• 内存分配： BlueStore 后端使用大量内存来缓存元数据。ceph.conf 文件中的 osd_memory_target 设置应为每个 OSD 至少 8GB，以确保它有足够的内存来工作，而不必不断从速度较慢的驱动器中读取数据。如果有足够的 RAM，则分配更多的内存可以进一步提高性能。

• RocksDB 编译： 在高性能测试期间发现的一个棘手问题是，某些 Linux 发行版的标准 Ceph 软件包没有使用 RocksDB 的最佳设置进行编译。这会导致数据库作变慢和写入性能受限。为了获得顶级性能，必须确保 Ceph 是使用优化的 RocksDB 构建的。

• 网络配置： 在集群的内部网络上， 通过将 MTU（最大传输单位）设置为 9000 来启用巨型帧是一种标准的最佳实践。这样，可以在每个网络数据包中发送更多数据，从而减少需要处理的数据包数量并降低 CPU 使用率。

以下是这些基本调优设置的快速清单，可帮助用户充分调优全 NVMe Ceph 集群。

实际结果：简解 1 TiB/s Ceph 集群

基准测试和优化指南是一个不错的开始，但真正的考验是了解这些在真实的环境中是如何工作的。2024 年初，Ceph 咨询公司 Clyso 的一个团队承担了一个项目，该项目突破了人们认为 Ceph 可能的极限。他们构建并优化了一个全 NVMe 集群，打破了 1 TB/秒 （TiB/s） 的速度限制 (https://www.clyso.com/us/a-journey-to-1-tib-s-a-milestone-in-performance/)，为我们提供了高性能存储方面的强大案例研究。

挑战和硬件

目标很宏大：将现有的基于 HDD 的集群迁移到新的 10 PB 全 NVMe 设置，而无需任何停机时间。他们使用的硬件令人印象深刻。最终设置有 68 台 Dell PowerEdge R6615 服务器。每台服务器都是一个性能野兽，配备一个 48 核 AMD EPYC 9454P CPU、192GiB DDR5 RAM、两个 100GbE Mellanox 网卡和十个 15.36TB 戴尔企业级 NVMe 驱动器。该硬件因其高内存带宽、大量 CPU 内核和极快的网络速度而被特别选择，从而构建了一个可以跟上快速驱动器的超高性能集群。

从失望到突破

即使拥有所有这些强大的硬件， 第一次测试也令人大失所望 。性能远低于他们的预期，更糟糕的是，它不一致。它会随着时间的推移而变慢，只有在完全重启后才会变得更好。这导致了一项深入调查，发现了几个棘手的系统级瓶颈。他们找到的修复程序证明，我们讨论的优化策略确实有效：

• 问题：延迟尖峰。 第一个问题是不一致的延迟，这扼杀了性能。

  • 解决方案：禁用 C-States。 团队正确地猜测到 CPU 节能状态导致了唤醒延迟。在 BIOS 中关闭 C-states，通过确保 CPU 始终处于活动和就绪状态，立即为他们带来了 10-20% 的性能提升。

• 问题：内核级瓶颈。 即使关闭了 C-states，性能仍然没有达到应有的水平。使用内核级工具进行更深入的观察显示，大量时间被浪费在内核操作上。

  • 解决方案：禁用 IOMMU。 团队将此问题追溯到 IOMMU。通过使用内核启动设置将其关闭，他们消除了每次 I/O 操作的地址转换开销，这带来了另一次“实质性的性能提升”，尤其是在他们添加更多 NVMe 驱动器时。

• 问题：写入性能差。 最后一个主要问题是出奇地慢的 4K 随机写入性能。

  • 解决方案：修复 RocksDB 编译。 调查发现，他们使用的标准 Ceph 软件包没有使用 RocksDB（驱动 BlueStore 的数据库）的最佳设置进行编译。通过使用正确的设置重新编译 Ceph，RocksDB 的内部清理时间下降了，4K 随机写入性能基本上翻了一番。

这段历程揭示了一个关键点：获得顶级性能不是一个简单的“安装即用”的工作。它需要数据驱动的问题解决、深入的系统知识，以及愿意超越 Ceph 自身的设置，去审视底层的操作系统和硬件。

结果：将 Ceph 推向极限

随着这些修复措施的到位，集群的真正潜力终于被释放出来。结果为 Ceph 的性能创下了新的公开记录：

• 3 倍复制性能： 在其使用 3 倍复制的最快配置中，这个 63 节点、630 OSD 的集群实现了令人难以置信的 1025 GiB/s（略高于 1 TiB/s）的大文件读取速度。对于小文件随机读取，它达到了 2550 万 4K IOPS。这些数字表明，一个经过良好调优的大规模 Ceph 集群，其性能可以与最先进的专有存储系统相媲美。

• 纠删码性能： 团队随后重新配置了集群，以使用 6+2 纠删码（EC）配置文件，这是客户计划用来获得最大存储效率的设置。即使有 EC 的额外工作，集群仍然提供了惊人的性能：读取超过 500 GiB/s，写入近 400 GiB/s。

这个案例研究为我们提供了一个宝贵的真实场景，让我们了解了在全 NVMe 平台上复制和纠删码之间的性能权衡。虽然 3 倍复制提供了绝对最佳的读取性能，但纠删码以仍然巨大的速度（尤其是对于写入）提供了巨大的存储效率。

NVMe 上的 EC 性能与它在 HDD 上的表现完全不同。在机械磁盘上，EC 带来的随机 I/O 冲击通常难以承受。但在 NVMe 上，驱动器速度非常快，以至于计算校验和的 CPU 成本以及与多个节点通信的网络成本成为新的瓶颈。

Clyso 的基准测试发现了一些可能看起来与我们默认理解相反的事情：在这个规模集群上，EC 写入比复制写入快得多。这是因为 EC 写入同时分布在许多节点（K+M 个节点）上，而复制写入则受限于逐个写入三个节点的过程。另一方面，EC 读取比复制读取慢（500 GiB/s vs. 1 TiB/s）。EC 读取必须从多个（K 个）OSD 获取数据，并由客户端的 CPU 将原始对象重新组合起来，这比从复制池中的单个 OSD 进行简单读取产生了更多的网络流量和工作。对于任何构建高性能、全 NVMe Ceph 集群并使用纠删码的人来说，这是一个关键的设计选择。

速度的经济性：TCO 和成本效益

采用全 NVMe 存储的最大障碍一直是成本。如果只看前期价格，以每 GB 美元 （$/GB） 为单位，与传统的 HDD 系统相比，全闪存解决方案似乎太昂贵了。但这并不代表所有。完整的总拥有成本 （TCO） 分析，应该还包括电力、冷却、机架空间和管理时间等运营成本。对于性能要求高的工作负载，全 NVMe Ceph 可能是一个不错的选择。

纠删码提高可用容量

使全 NVMe Ceph 集群变得经济实惠的最重要方式是使用纠删码（EC）。在标准设置中，Ceph 使用 3 倍复制，这意味着它存储每个数据片段的三个副本。这意味着有 200% 的额外存储开销；要存储 1PB 的数据，则需要 3PB 的原始磁盘空间。

纠删码以少得多的开销提供相同甚至更好的数据保护级别。例如，一个常见的 k = 4, m = 2（或 4+2）EC 配置文件，将数据分成四个“数据块”并创建两个“校验块”。此设置可以承受任何两个 OSD 的故障，就像 3 倍复制一样，但它只需要 1.5PB 的原始存储空间就能提供 1PB 的可用空间——这是 50% 的额外开销，而不是 200%。这基本上将原始存储硬件成本减半。

在 HDD 集群上，纠删码的随机 I/O 模式对性能的影响通常意味着它仅用于冷存档。但在全 NVMe 集群上，基准性能非常高，以至于 EC 成为更广泛的工作负载（包括暖数据甚至热数据 ） 的绝佳且经济高效的选择 。

耗电、散热和空间占用

全 NVMe 的 TCO 优势远不止存储驱动器。闪存存储在电力、散热和空间方面效率要高得多。

• 功耗： 一个正常使用中的 3.5 英寸企业级 HDD 消耗 6 到 10 瓦，而一个正常使用中的企业级 NVMe SSD 通常消耗 3 到 8 瓦。当它们空闲时，差异更大，HDD 可以消耗 4-8W，而 NVMe 驱动器可以降至 0.5-2W。美光公司一项比较全 NVMe Ceph 集群与混合 HDD+NVMe 集群的研究发现，全 NVMe 配置效率要高得多，每 GBps 写入速度的功耗低 46 倍，每 GBps 读取速度的功耗低 16 倍。（https://www.micron.com/about/blog/storage/innovations/drop-hdd-from-your-object-storage-ceph-micron-6500-ion）

• 密度和占用空间： 因为它们在小空间内集成了非常高的性能，因此，只需要很少的全 NVMe 节点就可以获得与基于 HDD 的集群相同的性能。同一项美光研究发现，需要 161 个基于 HDD 的节点才能匹配仅仅 6 个全 NVMe 节点的写入性能。

耐力问题：管理长期成本

对于所有的闪存系统，需要考虑的一个有效长期成本是驱动器的写入耐久性有限。如果计划好，这是一个可控的问题。企业级 NVMe 驱动器提供一定写入量的保修，以典型五年期间的每日驱动器写入次数 （DWPD） 衡量。

管理此成本的关键是将驱动器的耐用性评级与工作负载的写入量相匹配。一个普遍的误解是，所有企业应用程序都需要昂贵的高耐用性驱动器。实际上，我们可以根据工作负载选择驱动器 ：

• 读取密集型工作负载 （如分析或存档）可以使用 DWPD 为 1 或更低的更便宜、高容量的“读取密集型”驱动器。

• 混合用途工作负载 （如通用虚拟机存储或 Web 应用程序）与 DWPD 在 1 到 3 之间的主流“混合用途”驱动器一起使用。

• 写入密集型工作负载 （如数据库日志或高频数据收集）是唯一通常需要 DWPD 大于 3 的高级“写入密集型”驱动器的工作负载。

通过查看应用程序的 I/O 模式并选择合适的企业级 NVMe 驱动器，可以避免在不需要的耐用性上超支，从而优化初始成本和长期更换成本。

下表提供了假设的 1PB 可用存储集群的高级 TCO 比较，显示了如何通过大幅的运营成本节省来平衡 NVMe 硬件较高的初始成本。

注： 值仅用于说明，取决于特定的硬件和电源成本。来源：美光(https://www.micron.com/about/blog/storage/innovations/drop-hdd-from-your-object-storage-ceph-micron-6500-ion)

最终，全 NVMe Ceph 的主要经济优势不是更低的每 GB 成本，而是更低的每 IOPS 成本和每瓦特成本。当开始基于性能和运营效率而不是仅仅是容量来衡量时，全闪存的成本案例就变得非常有力。它还使数据中心更加简单。混合阵列依赖复杂的缓存和分层在快速闪存和慢速 HDD 之间移动数据，这增加了管理工作并可能导致不可预测的性能。全闪存配置消除了这种复杂性，创建了一个单一的、高性能的层，更易于管理并提供更可预测的应用程序响应时间。

未来：Ceph Crimson 和 NVMe 存储的未来

虽然，目前构建在稳定的 BlueStore 后端上的全 NVMe Ceph 集群提供了出色的性能，但 Ceph 社区一直知道，该平台的原始设计并不是为现代存储的微秒级延迟场景而设计的。为了真正释放下一代硬件的全部潜力，社区正在进行重大重新设计。这个名为 Crimson 的项目是 Ceph 的未来，它表明了社区致力于保持存储技术前沿的承诺。

问题：为什么传统 Ceph 无法满足需求

Ceph 是在物理磁盘（可以处理几百 IOPS）是最常见场景的时代创建的。在这些场景中，CPU 有足够的时间来管理每个 I/O 操作。随着存储变得越来越快，该时间已经急剧缩短。一个现代 NVMe 驱动器可以达到超过一百万的 IOPS，这使得 CPU 只有几千个周期来处理每个请求。

以往的 Ceph OSD 具有多线程设计，并不是为此场景设计的。其内部架构可能导致性能下降的上下文切换、线程争夺锁以及其他开销，从而消耗宝贵的 CPU 周期并增加延迟。这是原始硬件可以执行的作与 Ceph 开箱即用提供的功能之间存在性能差距的主要原因。

解决方案：Crimson 和 SeaStore

Crimson 项目(https://ceph.io/en/news/crimson/) 是 Ceph 社区的说法，即要突破此限制，需要一种新的架构。这是对 Ceph OSD 的完全重写，而不仅仅是一次更新。Crimson 基于 Seastar（一种用于高性能应用程序的高级 C++ 框架）构建，采用一组不同的规则进行设计。

它的主要目标是通过使用每核线程、无共享设计来减少 CPU 开销和延迟。在此模型中，任务在 CPU 内核之间进行拆分，以避免线程必须相互通信和锁定，从而允许在单个内核上尽可能不间断地处理单个 I/O 。

除了这个新的 OSD 之外，还推出了 SeaStore，这是一个新的存储后端，专为 NVMe 等快速、随机访问媒体而设计。SeaStore 最终将取代 BlueStore 成为 Crimson 的默认后端，提供更简化、更高效的数据路径，而不会受到支持 HDD 的遗留问题所拖累。

现状和现实期望

开发新的存储引擎是一项艰巨的工作。从长远来看，BlueStore 本身花了两年多 的时间才从一个想法到可用于生产。Crimson 和 SeaStore 是一个复杂程度相似的项目。

目前，Crimson 在最近的 Ceph 版本（如 Squid）和商业版本中作为技术预览提供。这意味着它的功能尚未完成，例如，对纠删码的全面支持仍在开发中，不建议用于生产用途。将新的 Crimson OSD 与稳定的 BlueStore 后端配对的早期性能测试表明，其性能已经与传统 OSD 一样好或略好 。但是，当原生 SeaStore 后端完全成熟时，预计会出现真正的、颠覆性的性能改进。

在未来的一段时间内，高性能 Ceph 的生产部署仍然将继续基于经过验证、稳定且非常快速的经典 OSD 和 BlueStore。这种架构为当今最快的集群提供支持，包括比如上述提到的 1 TiB/s 系统。企业可以放心使用这些解决方案。因为这是当前部署的最成熟的技术，另外，也持续跟进 Crimson ，因为，这有希望在未来几年获取更多性能。总结就是：“现在稳定而强大，未来更快。

总结和关键要点

将全 NVMe 存储与 Ceph 配对是开源存储平台向前迈出的一大步，将其从一个横向扩展的集群转变为一个可以与专业专有系统竞争的高性能机器。潜力是巨大的，基准测试显示数百万的 IOPS 和超过 1 TiB/s 的速度。然而，正如本文所示，那种性能并非开箱即用，它是有合理规划且精心调优的结果。

以下是一些值得考虑的要点：

• 最佳性能是有条件的： 从全 NVMe Ceph 获得最佳性能取决于合理的架构和具体的调优。NVMe 驱动器的原始速度将瓶颈转移到系统的其他部分，这使得高内核数 CPU 和高带宽 （25/100Gbps） 网络成为成功的关键。

• 系统级调优是关键： 一些明显的性能优势来自 Ceph 自己的设置之外。关闭 CPU 节能功能 （C-states） 以及在受信任的设置中关闭 IOMMU 是减少延迟和释放硬件真正潜力的关键步骤。

• 经济性被效率所改变： 虽然 NVMe 的前期硬件成本高于 HDD，但 TCO 分析却讲述了不同的情况。在 NVMe 上使用纠删码使其具有成本竞争力，而性能密度的巨大提高可大幅节省电力、散热和机架空间，通常可以降低性能密集型工作负载的总体拥有成本。

• 架构必须适合工作负载： 没有单一的“最佳”设置。但是，我们必须权衡所有，例如在每个驱动器选择一个 OSD 以提高速度，或者选择两个 OSD 以获得更好的尾部延迟，并在 3 倍复制之间进行选择以获得最佳读取性能，或在擦除码之间进行选择以实现存储效率和写入速度。

• 未来的存储架构： 当今基于 BlueStore 的生产就绪型集群成熟、稳定，可以处理最棘手的企业工作负载。下一代 Crimson OSD 和 SeaStore 后端的持续开发确保 Ceph 有一个明确的路线图，可以更好地利用未来的存储技术。

部署一个高性能的全 NVMe Ceph 集群是一项复杂的工作，需要存储、网络和系统管理的深入知识。像使用消费级硬件、网络配置不足或跳过系统级调优等常见错误，很容易会导致存储系统无法发挥出应有的性能。

对于那些希望利用全 NVMe Ceph 的强大功能而又不想经历陡峭学习曲线和风险的组织来说，本文可以提供一个比较好的参考案例。

常见问题 （FAQ）

全 NVMe Ceph 集群与基于 HDD 的传统集群相比如何？

全 NVMe Ceph 集群与基于 HDD 的 Ceph 集群完全不同。差异不小，而是数量级。经过良好调优的全 NVMe 集群可以提供数百万 IOPS 和每秒数十 GB 的速度，而 HDD 集群的测试速度为数千 IOPS 和每秒数百兆字节。延迟从 HDD 上的毫秒下降到 NVMe 上的微秒。

在成本方面，NVMe 硬件的每 GB 前期价格高于 HDD。但是，对于性能至关重要的应用场景来说，全 NVMe 集群的总拥有成本 （TCO） 通常要低得多。这是因为在电源、冷却和机架空间方面取得了巨大的效率提升。例如，一项研究发现，仅 6 个全 NVMe 节点的写入性能就需要 100 多个基于 HDD 的节点才能匹配 (https://www.micron.com/about/blog/storage/innovations/drop-hdd-from-your-object-storage-ceph-micron-6500-ion)，这可以节省大量运营成本，弥补较高的初始硬件成本。

全 NVMe 集群最关键的优化步骤是什么？

虽然有很多配置可以调整，但三个调优步骤对于实现全 NVMe Ceph 集群的超高性能最为重要：

1. 禁用 CPU C-States： 这是 BIOS/UEFI 设置。关闭省电的 C 状态会阻止 CPU 进入睡眠模式，从而消除损害低延迟存储的“唤醒”延迟。这一项更改可以带来 10-20% 的性能提升 。

2. 禁用 IOMMU： 在受信任的裸机设置中，IOMMU （VT-d/AMD-Vi） 会向每个 I/O 添加不必要的地址转换步骤。使用内核引导设置将其关闭可以通过 减少 CPU 工作来显著提高性能 。

3. 优化每个驱动器的 OSD 策略： 决定每个 NVMe 驱动器运行一个或两个 OSD 是一个关键的选项。 每个驱动器使用一个 OSD 以获得最佳的大写入速度和 CPU 效率。每个驱动器使用两个 OSD 可大幅减少 99% 的尾部延迟，这对于需要一致、可预测的响应时间的应用程序至关重要。

网络设置如何影响全 NVMe Ceph 集群的性能和恢复速度？

网络是 Ceph 集群的命脉，它在全 NVMe 设置中的重要性怎么强调都不为过。快速、低延迟的网络（最低 25 Gbps，对于较大的集群，建议使用 100 Gbps）是必不可少的，原因有两个：

1. 峰值性能： 现代 NVMe 驱动器的速度很容易压垮速度较慢的网络。例如，10Gbps 网络可以被单个客户端完全用完 ，无论驱动器有多快，都会对性能造成硬性限制。

2. 恢复速度： 这是最关键的部分。当驱动器或服务器发生故障时，Ceph 必须通过网络复制数 TB 的数据才能恢复完全冗余。此恢复的速度与可用网络带宽直接相关。缓慢的网络会使恢复过程更长，使集群处于降级和易受攻击的状态，并增加因再次故障而丢失数据的风险。更快的网络意味着更具弹性和可靠的集群。

何时应该在全 NVMe 集群上使用纠删码而不是 3 副本？

在全 NVMe 集群上选择纠删码 （EC） 和 3 倍复制是一种基于应有和成本目标的战略性选择。

• 将 3x 复制用于：

• • 最大读取性能： 如果主要目标是绝对最高的读取 IOPS 和最低的读取延迟，那么 3 倍复制是理想的选择。这使其非常适合延迟敏感型工作负载，例如高事务数据库的数据块存储。使用 3 倍复制可以达到 1 TiB/s性能 。

  • 简单性： 复制对 CPU 的工作量比纠删码少。

• 将纠删码（例如 4+2、8+3）用于：

• • 存储效率和成本节约： EC 可显著降低存储开销 ，这是使大型全 NVMe 集群经济实惠的关键。

  • 高写入吞吐量： 它可能看起来有点不太可能，但从实际上讲，一定规模的集群，EC 可以提供比复制更高的写入速度 ， 因为写入同时分布在多个 OSD 中。

  • 对象存储和归档： 它非常适合大规模对象存储或文件存储，其中容量和成本效益是首要考虑因素，读取延迟略高是可以的。

在全 NVMe 上部署 Ceph 时最常见的错误是什么？

最常见和最具严重的错误是使用 消费级硬件 。此错误主要以两种方式表现出来：

1. 消费级 NVMe 驱动器： 使用台式机或笔记本电脑类型的驱动器是导致问题的根源。这些驱动器缺少基本的企业功能，如掉电保护（有数据损坏的风险），并且写入耐久性 （DWPD） 非常低，这会导致它们在 Ceph 的持续 I/O 负载下过早磨损和失效。

2. 网络配置不足： 在 1GbE 甚至 10GbE 网络上部署全 NVMe 集群。这会直接导致明显的性能瓶颈，使集群无法获得快速存储的任何优势，并严重影响数据恢复的速度，使集群面临风险。

这些硬件选择往往会产生一些基础限制和可靠性风险，而且是再多的软件调优都无法解决的。一个成功的全 NVMe Ceph 部署始于正确的企业级硬件的基础。