多年来我们遇到的最常见问题之一是用户是否应该在每个闪存驱动器上部署多个 OSD。这个问题比较复杂，因为随着Ceph的发展，这个问题的答案也在不停的变化。早在 Ceph Nautilus 时代，我们通常建议每个闪存驱动器部署2 个甚至 4 个 OSD。当时在每个闪存设备部署多个 OSD 时，特别是在使用 NVMe 驱动器时，会具有很明显的性能优势。
但在 Octopus 和 Pacific 的发布周期中，这一问题的答案也开始发生变化。社区在 OSD 和 BlueStore 代码中引入了多项性能改进，极大地提高了每个 OSD 的性能。随着Pacific 版本的发布，我们也进行了各种测试，以确定我们的建议是否应该改变。
图片
正如预期的那样，Octopus 和 Pacific 的速度明显快于 Nautilus，但与每个 NVMe 2 个 OSD 与 1 个 OSD 相比，也不再表现出一致的性能增益。一些测试仍然显示出一些增益，但其他测试则显示出轻微的损失。然而，这些测试的范围相当有限。 CPU 资源的可用性是否会改变结果？在性能或资源消耗方面还有其他优点或缺点吗？最后，自 Pacific 以来，我们不断改进 OSD 和 bluestore 代码。下面我们将进行详细验证下。
集群设置
|
Nodes |
10 x Dell PowerEdge R6515 |
|
CPU |
1 x AMD EPYC 7742 64C/128T |
|
Memory |
128GiB DDR4 |
|
Network |
1 x 100GbE Mellanox ConnectX-6 |
|
NVMe |
6 x 4TB Samsung PM983 |
|
OS Version |
CentOS Stream release 8 |
|
Ceph Version |
Reef v18.2.0 (built from source) |
其中 5 个节点被配置为托管 OSD，其中 5 个节点被配置为客户端节点。所有节点都位于同一台 Juniper QFX5200 交换机上，并通过单个 100GbE QSFP28 链路进行连接。使用 CBT 部署了 Ceph 并启动了 FIO 测试。英特尔系统上一个重要的操作系统级别优化是将 TuneD 配置文件设置为“延迟性能”或“网络延迟”。这主要有助于避免与 CPU C/P 状态转换相关的延迟峰值。基于 AMD Rome 的系统在这方面似乎并不那么敏感，而且我还没有确认 TuneD 实际上限制了 AMD 处理器上的 C/P 状态转换。尽管如此，对于这些测试，TuneD 配置文件仍设置为“网络延迟”。
测试设置
安装 Ceph 并配置CBT。通常，在测试 Ceph 时，通常会考虑内核数量和分配给每个 OSD 的内存。然而，在此测试中，最好考虑每个 NVMe 驱动器有多少 CPU 和内存可用。这些系统中的每一个都可以轻松支持每个 NVMe 驱动器 16GB 内存，并且每个 NVMe 最多可以扩展至 20 个 CPU 线程。为了保持正确的内存比率， osd_memory_target 在 1 OSD/NVMe 情况下设置为 16GB，在 2 OSD/NVMe 情况下设置为 8GB。 Numactl 用于控制每个 OSD 的 CPU 线程数。 OSD 被分配给两个“处理器”池，试图同时扩展物理核心和 HT 核心。为此，使用以下 bash 单行代码生成处理器到物理核心的映射：
paste
