Quincy @ Scale：三个大型集群的故事

简介 ¶

在新的 Ceph 版本发布之前，会产生新的见解和想法，为未来的 Ceph 版本铺平道路。在 Quincy 的第一个版本发布之前，我们看到了进行大规模测试的必要性——目的是针对 1000 多个 OSD 集群验证 Quincy 的新功能、性能和弹性。

大规模测试的需求超出了我们目前小规模集成测试场景的能力。对 Quincy 进行大规模测试将使我们能够首次识别仅在大型集群上出现的错误和瓶颈。我们还将能够评估大型集群在不同环境中的行为，例如硬件、资源限制和工作负载模式。

在这篇博文中，我们介绍了我们合作的三个大型测试集群，并概述了我们为每个集群遇到的挑战和成果。我们还解释了作为测试工作结果而获得的性能结果。

Gibba 上游集群：逻辑大规模 ¶

Gibba 集群是一个大型测试集群，Ceph 工程师会定期使用它来测试升级和新功能。Gibba 集群由 Cephadm 提供支持，共有 975 个 OSD（SSD）和 40 个主机。它还具有 13 TiB 的原始容量。

Gibba 集群最初的挑战包括将上游 teuthology 节点转换为大型测试集群、处理有限的 CPU 和内存资源、弄清楚如何在规模上使用 CBT（Ceph 基准测试工具）等工具，以及解决导致重新部署的错误。

通过在 Gibba 集群上的工作，我们得出了继续大规模测试的最佳调整方案，测试了 Cephadm 的全新部署，修复了在发布 17.2.0 之前未在集成测试中发现的多个错误，并使开发人员能够对未来版本进行大规模测试。

在 Cephadm 上进行测试 ¶

我们在 Gibba 上遇到了几个特定于 Cephadm 的挑战和成果。我们处理的三个主要挑战是：1) 从 16.2.7 到 Quincy 的大规模滚动升级，2) 在资源不足的情况下管理升级，以及 3) 在许多 OSD 和主机上运行 orch 命令。

为了应对这些挑战，我们设置了一个 Ansible playbook，在每个主机上安装 Cephadm 二进制文件，以确保主机拥有所需的依赖项，例如 podman 和 lvm。我们还测试了大规模的 Cephadm 清理，这为我们提供了关于未来客户场景中如何执行此操作的更好知识。最后，我们确定并修复了 Cephadm、BlueStore 和管理器模块中的六个值得注意的错误，这些错误在上游集成测试中未被发现。有关详细信息，请参阅 跟踪器索引。

测试遥测 ¶

将 Gibba 的管理器升级到 Quincy 后，我们能够检查遥测的新 选择加入流程 和性能通道的行为，这两个都是 Quincy 添加的新功能。我们还观察了该模块在大规模下的行为。

通过我们的观察，我们确认了选择加入流程在升级后按预期工作，修复了性能、设备和崩溃通道中的几个错误，为仪表板行为引入了一些修复，并解决了性能通道中的匿名化问题。有关详细信息，请参阅 跟踪器索引。

测试 QoS (mClock) ¶

随着 Cephadm 和遥测错误的修复，QoS mClock 调度程序也出现了一些新进展。关于 mClock，我们主要好奇的是其配置文件在大规模下的行为。我们还希望测试 mClock 配置文件对恢复和客户端 I/O 的影响，以及对 scrub、snaptrim 和 PG 删除等后台操作的影响。

经过测试，我们验证了 mClock 配置文件能够为恢复和客户端 I/O 提供所需的 QoS。这包括使用 3 个客户端和并行恢复执行的测试，在进行 scrub、恢复和客户端 I/O 时进行测试，在 snaptrim 和客户端 I/O 接下来排队时进行测试，以及为性能评估添加了额外的统计数据。

对于未来，我们希望根据 Gibba 集群的发现引入一个新的 mClock 配置文件，该配置文件优化 scrub、snaptrim 和 PG 删除等后台操作，而不是恢复和客户端 I/O。

Red Hat 的 Scalelab “逻辑大规模”：逻辑扩展到 8,000 个 OSD ¶

Scalelab “逻辑大规模”集群是我们用于观察 Cephadm 可扩展性和其他性能方面的集群。Scalelab 集群有 127 台 Red Hat 提供的服务器，8,134 个 OSD（NVMe 支持的 nbd），一个 25 Gb 网络（VLAN），以及 75% 的容量利用率。

Scalelab 集群的一个值得注意的挑战是超过 3,776 个 OSD 后监控不一致，这是由于每 10 秒发送到 Prometheus 的性能计数器有效载荷过大。还观察到由于每 5 秒收集一次统计数据，管理器 CLI 中会出现间歇性延迟。

为了应对这些挑战，我们启动了一个工作流，以更好地分配性能计数器收集，审查和减少发送到管理器的数据，使统计数据收集与集群大小保持一致，并提高控制指标收集的能力。

在测试过程中，我们还发现用于预检和清理的 Cephadm-ansible playbook 是成功的。Cephadm 的可扩展性被确认为 8,134 个 OSD。

Red Hat 的 Scalelab：Cephadm 升级 ¶

Scalelab 集群（不要与 Scalelab “逻辑大规模”集群混淆）是我们用于执行 Cephadm 升级、测试 RGW 性能以及比较不同工作负载结果的集群。Scalelab 集群由 Cephadm 管理，有 13 台 Red Hat 提供的服务器，832 个 OSD（NVMe 支持的 nbd），一个 25 Gb 网络（VLAN），一个 Canary RBD 工作负载（R/W），以及 75% 的容量利用率。

在 Cephadm 升级期间，我们遇到了一个 pg_autoscaler 错误，其中自动缩放器在 cephfs 元数据池上将 pg 从 32 缩放到 32,768 个 pg。我们还注意到高摄取率超过了 mgr 和自动缩放器，导致 OSD 利用率暂时倾斜。

尽管存在这些最初的挑战，升级仍然成功；832 个 OSD 总共花费了 9 个小时。针对自动缩放器错误，我们为其创建了一个跟踪器问题并解决了根本原因。我们还发现 Cephadm 升级对 Canary 工作负载的影响最小。

Scalelab 上的 RGW S3 对象工作负载 ¶

除了 Cephadm 升级之外，我们还使用 Scalelab 在 RGW S3 对象工作负载上测试了 Quincy 的早期版本。这项工作的目标是验证 Quincy 的功能并测试其在大规模下的基线性能。

我们的大规模环境包括

• 3x MON/MGR 节点
  • Dell R640 服务器
  • 2 个 Intel Xeon Gold 5218 处理器（总共 32 核，64 线程）
  • 384 GB 内存
• 8x OSD/RGW 协同定位服务器
• Supermicro 6048R
• 2 个 Intel E5-2660 v4 处理器（总共 28 核，56 线程）
• 256 GB RAM
• 192 个 OSD（bluestore）。用于数据的 HDD（每个 OSD 节点 24 个 HDD 和 2 个用于 WAL/DB 的 NVMe）
• 池 default.rgw.buckets.data = EC 4+2, pgcnt=4096

RGW S3 工作负载的性质 ¶

RGW S3 测试通常采用两组对象大小。通用大小的工作负载使用

• 50% 1KB 对象，15% 64KB 对象，15% 8MB 对象，15% 64MB 对象，以及 5% 1024MB 对象

而较小大小的工作负载使用

• 25% 介于 1KB 和 2KB 之间的对象，40% 介于 2KB 和 4KB 之间的对象，25% 介于 4KB 和 8KB 之间的对象，以及 10% 介于 8KB 和 256KB 之间的对象

然后按如下方式执行这两组对象大小

• 集群填充（COSBench 准备）- @4小时
• 1 小时 COSBench 混合测量新集群
• 44% 读取，36% 写入，15% 列表，5% 删除
• 3 个存储桶执行写入/删除，3 个执行列表/读取
• 48 小时 COSbench 混合老化工作负载
• 1 小时 COSBench 混合测量老化集群

调整和问题 ¶

虽然通用大小的对象测试执行没有问题并提供了预期的结果，但较小的对象工作负载观察到了一个阻塞问题（跟踪器 54124），该问题通过调整（在本例中为加倍）rgw_thread_pool_size 和 rgw_max_concurrent_requests 的默认值来解决。

我们还看到 Quincy 17.2.0 中小型对象工作负载的性能比 17.2.1 有了巨大的提升。调查显示，差异在于 bluestore 零块检测 在 17.2.0 中默认启用，但在 17.2.1 中禁用。Bluestore 零块检测是一个旨在用于大规模合成测试的功能，在 17.2.0 中对某些 RBD 和 CephFS 功能产生了意想不到的影响，这就是为什么它在 17.2.1 中被禁用的原因。关于我们如何在未来的 Ceph 版本中安全地实现相同的性能提升，正在进行中的调查（在 跟踪器 56640 中跟踪）。

为了在大规模下进行测试，应用了以下非默认设置

• osd_memory_target = 7877291758
• osd_memory_target_autotune = false
• rgw_max_concurrent_requests = 2048
• rgw_thread_pool_size = 1024

有关我们遇到并修复的错误列表，请参阅 跟踪器索引。

与 Pacific 的比较 ¶

在比较 Pacific 16.2.7 和 Quincy 17.2.1 的 RGW S3 小型对象工作负载时，我们观察到

• 两个版本之间的集群填充工作负载吞吐量性能几乎相同。
• 在混合 48 小时工作负载中，Quincy 的性能比 Pacific 高出 50%。
• 在混合 1 小时老化工作负载中，Quincy 的性能比 Pacific 高出 15%。

填充工作负载结果 ¶

下图描绘了 4 小时集群填充（准备）工作负载期间的 I/O 吞吐量和平均响应时间。

混合-1小时（新）结果 ¶

只有在集群填充到所需容量后，才会执行 1 小时混合工作负载作为基线测量，以便进行后续比较。此图绘制了混合工作负载的读取和写入吞吐量。

混合-48小时结果 ¶

执行 48 小时混合工作负载以对集群进行压力测试和老化。下面绘制了平均读取和写入吞吐量。

混合-1小时（老化）结果 ¶

第二次 1 小时测量工作负载突出了集群长时间使用对性能的影响。

重点领域 ¶

我们所有规模测试工作的结论是，规模测试非常有价值！对于未来的版本，我们计划增加性能和规模测试的频率，以发现更多的错误和性能瓶颈。非常欢迎在硬件方面提供任何帮助。

目前，我们定期使用 Gibba 集群来尽早识别上游回归，根据功能测试要求构建不同规模的集群，并执行持续升级。

最后，我们计划在 teuthology 集成测试中引入一个新的套件，该套件将在合并之前对上游拉取请求运行大规模合成测试。

跟踪器索引 ¶

Gibba：在 Cephadm 上进行测试 ¶

• 跟踪器 53610 - 'Inventory' 对象没有属性 'get_daemon'
  • 排除为真正的 Cephadm 错误；标记为“无法重现”
• 跟踪器 53624 - cephadm agent: set_store mon returned -27: error: entry size limited to 65536 bytes
  • 确定原因是密集节点上有太多设备信息
• 跟踪器 53693 - ceph orch upgrade start is getting stuck in gibba cluster
  • 由 Adam King 通过移除有问题的节点 gibba045 解决
• 跟踪器 54132 - ssh errors too verbose
  • 由 Melissa Li 在 PR 45132 中修复
• 跟踪器 53923 - [Upgrade] mgr FAILED to decode MSG_PGSTATS
  • 由 Aishwarya Mathuria 在 PR 45694 中修复
• 跟踪器 55145 - Bogus assert in SimpleBitmap
  • 由 Gabriel BenHanokh 在 PR 45733 中修复

Gibba：测试遥测 ¶

• 跟踪器 53985 - mgr/telemetry: down osds result in empty perf report fields
  • 由 Laura Flores 在 PR 44746 中修复
• 跟踪器 53603 - mgr/telemetry: list index out of range in gather_device_report
  • 由 Yaarit Hatuka 在 PR 44327 中修复
• 跟踪器 53604 - mgr/telemetry: list assignment index out of range in gather_crashinfo
  • 由 Yaarit Hatuka 在 PR 44328 中修复
• 跟踪器 53831 - mgr/dashboard/telemetry: reduce telemetry dashboard preview size
  • 由 Laura Flores 在 PR 44523 中修复
• 跟踪器 54120 - mgr/dashboard: dashboard turns telemetry off when configuring report
  • 由 Sarthak Gupta 在 PR 44985 中修复
• 跟踪器 55229 - mgr/telemetry: anonymize host names in perf counters in perf channel
  • 由 Laura Flores 和 Yaarit Hatuka 在 PR 45819 中修复

Red Hat 的 Scalelab：调整和问题 ¶

• 跟踪器 53906 - BlueStore.h: 4158: FAILED ceph_assert(cur >= fnode.size)
• 跟踪器 53907 - BlueStore.h: 4148: FAILED ceph_assert(cur >= p.length)
  • 上述两个问题仅在混合 OSD（DB 在 NVMe 上，块在 HDD 上）中观察到
  • 都在最新的 Quincy 中修复
• 跟踪器 53924 - EC PG stuck recovery_unfound+undersized+degraded+remapped+peered
  • 不再可重现
• 跟踪器 53956 - pacific radosgw-admin binary reports incorrect stats on quincy cluster
  • 不再可重现
• 跟踪器 54124 - 较小的对象工作负载在几个小时后减弱并终止
  • 需要调整 rgw_thread_pool_size 和 rgw_max_concurrent_requests
• 跟踪器 54142 - quincy cephadm-purge-cluster needs work
• 跟踪器 55383 - monitor cluster logs(ceph.log) appear empty until rotated
  • 由胡玮文在 PR 46124 中修复
• 跟踪器 56640 - RGW S3 workload has a huge performance boost in quincy 17.2.0 as compared to 17.2.1

** 注意：标题图片来自 生物多样性遗产图书馆。