大家好，Ceph 社区！过去一年左右，我们收到越来越多的人询问在 Ceph 中使用加密，但不知道预计会有什么样的性能影响。今天，我们将研究 Ceph 的磁盘加密和传输中加密在两种不同工作负载下的性能。对于可能不熟悉这些术语的读者，让我们回顾一下

1. 磁盘加密：这有时也称为静态数据加密。数据在写入持久存储时会被加密。在 Ceph 中，这是使用 LUKS 和 dm-crypt 来完全加密 BlueStore 用于存储数据的底层块设备。这会完全加密 Ceph 中存储的所有数据，无论它是块、对象还是文件数据。

2. 传输中加密：数据在通过网络发送时会被加密。在 Ceph 中，这是通过为 messenger 版本 2 客户端选择性地启用“secure” ms 模式来实现的。截至 Ceph Reef v18.2.0，ms secure 模式使用 128 位 AES 加密。

加密也可以在更高级别执行。例如，RGW 可以在将其发送到 OSD 之前自行加密对象。但是，为了本文的目的，我们将重点关注 RBD 块性能，并利用上述两种选项。

致谢

首先，感谢 Clyso 为这项工作提供资金，以造福 Ceph 社区。同时感谢 IBM / Red Hat 和 Samsung 为上游 Ceph 社区提供用于此测试的硬件。感谢所有为 Ceph 的伟大而辛勤工作的 Ceph 开发人员！最后，特别感谢 Lee-Ann Pullar 审阅本文！

集群设置

五个节点配置为托管 OSD，五个节点配置为客户端节点。所有节点都位于同一 Juniper QFX5200 交换机上，并通过单个 100GbE QSFP28 链路连接。Ceph 已部署，并且使用 CBT 启动了 FIO 测试。在 Intel 系统上，一个重要的操作系统级别优化是将 TuneD 配置文件设置为“latency-performance”或“network-latency”。这主要通过避免与 CPU C/P 状态转换相关的延迟峰值来帮助。基于 AMD Rome 的系统似乎对这方面不太敏感，并且我尚未确认 TuneD 实际上限制了 AMD 处理器的 C/P 状态转换。尽管如此，TuneD 配置文件仍然设置为“network-latency”用于这些测试。

测试设置

CBT 配置为使用一些修改后的设置部署 Ceph。OSD 被分配了 16GB osd_memory_target，以保证高的 onode 命中率并消除混淆性能影响。由于 RBD 缓存可能会适得其反，因此禁用了它，尤其是在 OSD 由快速 NVMe 驱动器备份时。使用以下配置选项为关联测试启用了 msgr V2 的安全模式

ms_client_mode = secure
ms_cluster_mode = secure
ms_service_mode = secure
ms_mon_client_mode = secure
ms_mon_cluster_mode = secure
ms_mon_service_mode = secure

进行了三组测试，如下所示，并在每组测试之间重建集群

允许 OSD 使用节点上的所有核心。FIO 配置为首先使用大写写入预填充 RBD 卷，然后进行 300 秒的 4MB 和 4KB IO 测试。某些后台进程，例如 scrub、deep scrub、PG 自动缩放和 PG 平衡被禁用。最后，使用了具有静态 16384 PGs（高于通常建议的数量）和 3 倍复制的 RBD 存储池。

Ceph LUKS 调优 - 4MB IO

Ceph 使用名为 LUKS 的工具来加密 BlueStore 写入数据的块设备。有几个可用的调优选项可以帮助提高性能。在深入研究完整的测试集之前，让我们先看看其中的几个选项。

不幸的是，Centos Stream 8 中可用的内核不支持禁用读写工作队列。因此，我们无法测试这些选项。但是，我们能够测试其他选项，并且首先关注多客户端测试配置。

一开始，我们看到在 OSD 上部署 LUKS 对 4MB 读取性能几乎没有影响，但对写入性能有重大影响。这可能略有误导，因为我们的读取测试在网络上受到限制，每节点约为 11GB/s。但是，对于写入测试，性能影响是显著的。好消息是，使用 --perf_submit_from_crypt_cpus 选项可以减轻一些性能损失。

虽然我们无法在这些测试中测试与工作队列相关的性能选项，但 Ceph 中已经有一个 PR 来启用这些选项，并且 Josh Baergen 已经对其进行了测试

• “在低负载下，延迟似乎不受这些更改的影响。任何差异都不超过我们的误差范围。”
• “在高负载且包含写入时，写入越大，此更改越有效。例如，对于 4m 顺序写入，OSD 节点 CPU 使用率下降了近一半，延迟也得到了显着改善（p90 读取速度快了两个数量级）。”
• “大块只读负载可能略微降低了延迟，但很难确定。”

Josh 的一个观察结果是，工作队列选项可能有助于改善 CPU 使用率。虽然我们没有这些数字，但让我们看看我们能够运行的测试中的 CPU 使用率。

在读取期间，使用 LUKS 时系统 CPU 使用率会急剧增加（CPU 使用率高达 2 倍）。在写入测试中，整体 CPU 消耗量似乎相似甚至更低，但考虑到性能却并非如此。每 IO 的 CPU 使用率实际上更高。在读取和写入测试中，为 LUKS 使用 4K 扇区似乎会导致 CPU 使用率略微下降。

Ceph LUKS 调优 - 4KB IO

4KB 随机 IO 的性能影响低于较大的 4MB IO。4KB 读取损失约为 11-12%，而写入损失约为 20%。

总体 CPU 使用率非常接近，但是系统使用率略高，而用户使用率略低（与启用 LUKS 时的性能降低相关）。

从这些测试中得出的总体结论是，--perf-submit_from_crypt_cpus 选项可以提高 LUKS 大写吞吐量，并且可能值得使用，我们将会在本文的其余测试中使用它。如果设备原生支持，4K 扇区也可能值得启用，并且在某些情况下可能略微改善 CPU 使用率。

多客户端测试 - 4MB IO

现在我们已经完成了 LUKS 的基本测试，让我们看看使用相同的高并发工作负载时 msgr V2 安全模式有什么影响。

启用 msgr v2 安全模式存在附加开销，但是这些测试中更大的影响来自 LUKS。

LUKS 再次导致显著的 CPU 使用率开销。有趣的是，启用安全 messenger 似乎降低了在使用未加密块卷（即没有 LUKS）时的系统 CPU 消耗。原因尚不完全清楚，但可能略微减少了 IO 工作负载对块层的冲击可以解释这一点。

多客户端测试 - 4KB IO

最大的影响仍然来自 LUKS。

最大的 CPU 使用率影响也来自 LUKS，系统 CPU 略高，用户 CPU 略低（与性能降低相关）。

将如此多的 IO 投入到此集群中的一个影响是，我们看到高延迟事件。在这种情况下，我们实际上正在稍微加大 OSD 的压力，并看到最坏情况下的延迟高达约 900 毫秒。好消息是，LUKS 和安全模式都没有对这种饱和工作负载中的尾部延迟产生重大影响。我们还从之前的文章 Ceph Reef - 每个 NVMe 1 或 2 个 OSD？ 中了解到，将多个 OSD 放在单个 NVMe 驱动器上可以显著降低尾部延迟，但会以更高的资源消耗为代价。

单客户端测试 - 4MB IO

去年我们研究了 QEMU/KVM 性能与 Msgr V2 AES 加密，并发现加密确实对单客户端性能有明显影响。我们运行了几个单客户端测试来验证 Reef 中是否仍然存在这种情况。

在之前的多客户端测试中，我们观察到 LUKS 通常影响最大。它大大增加了大 IO 的 CPU 消耗，并降低了大写和小型随机 IO 的性能。在这些单客户端大 IO 工作负载中，LUKS 的影响很小。但是，启用 messenger 加密对单客户端性能有重大影响，而它对多客户端测试中的整体集群性能影响较小。

单客户端测试 - 4KB IO

LUKS 和 messenger 级别加密对单客户端小型 IO 的影响也很小，通常只有几个百分点。那延迟呢？

之前的多客户端测试显示由于我们对 OSD 施加的压力过大而导致了显著的延迟峰值。在这些单客户端测试中，延迟更加均匀。读取的典型延迟徘徊在 0.9 毫秒左右，峰值不超过 1.15 毫秒。写入情况更有趣。延迟仍然明显较低，通常约为 1.5 毫秒。峰值通常低于 2.5 毫秒，但当同时使用磁盘加密和 messenger 级别加密时，峰值接近 3.5 毫秒。但是，这种峰值的性质似乎会随着时间的推移而循环，并且该模式在完全重建的集群上的多个测试中重复出现。这种效应值得进一步调查。

单客户端测试 - 4KB SYNC IO

在之前的单客户端测试中，我们仍然使用了较高的 io_depth 以允许许多 IO 保持飞行状态。这允许多个 OSD 并发地服务 IO，从而提高性能。但是，某些应用程序要求 IO 顺序处理。一个 IO 必须完成才能写入或读取下一个 IO。etcd 日志就是一个很好的例子，通常完全受延迟限制。每个 IO 必须完成至少一次往返网络传输以及服务它所需的任何其他开销。

在这种情况下，最大的影响来自 LUKS。4KB 同步读取速度略慢，而 4KB 同步写入速度下降更大。

延迟遵循类似的模式，未加密的结果显示比加密的结果略快的响应时间。读取延迟徘徊在 0.13 毫秒左右，而写入延迟徘徊在 0.4 毫秒左右，偶尔峰值高达 0.5 毫秒。

结论

在本文中，我们研究了 Ceph 在各种 RBD 测试场景下使用磁盘加密和传输中加密的性能。这些测试的结果表明了一些细微的结论。

通常情况下，我们预计用户在使用磁盘加密时会看到CPU消耗增加。最大的影响预计会出现在大IO上。幸运的是，Ceph通常在小IO工作负载期间使用更多的CPU。如果客户的OSD CPU规格是根据IOPS需求设计的，那么由于CPU不足，他们不太可能遭受严重的性能影响。然而，大写操作在使用磁盘加密时会看到显著的性能影响，但这可以通过部分缓解，并且正在进行的工作可能会进一步缓解。磁盘加密对小同步写性能也有中等程度的影响。通过网络加密对性能的最大影响是最大单个客户端吞吐量。它在其他情况下也有一些性能影响，但影响通常较小。与往常一样，我鼓励您自己进行测试，看看您的发现是否与我们在这里看到的一致。感谢您的阅读，如果您有任何问题或想进一步讨论Ceph性能，请随时联系我们。