Quincy @ Scale：与 Pawsey 超级计算中心的测试

2022年7月18日 Paul Cuzner

在开发新功能时，Ceph开发者面临的最困难的考虑因素之一是新功能是否需要在规模上进行验证。我们的实验室环境允许我们在拥有数百个 OSD 的集群中测试新功能，并且在大多数情况下，这都能很好地工作！

然而，我们的开发者们都非常谨慎，如果机会合适，他们喜欢测试超出我们通常的“测试上限”。

去年年底，这样的机会出现了。位于澳大利亚珀斯的 Pawsey Supercomputing Centre 联系了我们，提供了一个潜在的测试窗口。他们确定了在硬件安装完毕但仍未使用的几个周的时间段。

由于我们正处于 Quincy 版本的开发周期末期，这是一个不容错过的机会！

硬件 ¶

Pawsey 提供了超过 200 台服务器的访问权限，所有服务器都通过 100Gb 网络连接。服务器规格针对大型对象存储用例进行了优化，使我们能够创建以下 Ceph 集群；

虽然 orchestrator/cephadm 控制平面自 Ceph Octopus 版本发布以来就已到位，但部署和管理如此大规模的集群的挑战被定义为我们的主要目标。

除了集群管理之外，我们还想评估监控/告警，并“道路测试”实验性的 cephadm agent 功能。

通过使用 Pawsey 的集群，我们能够在 Quincy 的初始发布之前识别并解决许多规模问题，并确定进一步改进以在 Ceph Reef 版本中交付改进的领域。

所有 Ceph 守护进程默认每 5 秒向活动管理器报告其性能计数器。我们发现由于此数据负载以及与 mgr/prometheus 模块的交互，超过 2,800 个 OSD 时 mgr 和 CLI 的响应速度变得不稳定。一个 PR 被合并，这显著减少了这个问题。
在 pg_autoscaler 的扩展配置文件中发现了一个错误，该错误阻止了 pg 的配对。此错误已得到修复，并回溯到 Pacific 和 Octopus。

ceph-volume 得到了增强，以更好地处理意外的磁盘格式，例如 Atari 分区和基于 GPT 的设备。
cephadm 使用 SSH 作为到每个集群主机的控制路径。在我们的负面测试期间，我们发现当遇到 ssh 问题（坏密钥/丢失密钥）时，返回给用户的相应信息过于冗长。这在 PR 45132 中得到了修复。
Cephadm 的实验性“agent”功能用于为 orchestrator 提供主机、设备和守护进程状态元数据。测试表明部署和数据质量符合预期，但 agent 生成了过多的日志流量，使得潜在的故障排除变得困难。Agent 计划在 Ceph Reef 版本中成为受支持的功能。
由于主机数量众多，orch host ls 命令 中缺乏过滤功能，使得与集群的交互更加困难。在 PR 44020 中添加了过滤功能，解决了这个问题。

从历史上看，如此大规模的 Ceph 集群都是使用基于 CLI 的工具链进行管理的，但我们借此机会简要查看了集成的 Ceph UI（仪表板）。

虽然仪表板的监控功能可用，但管理主机和 OSD 存在问题，导致浏览器超时。

缺乏分页被确定为导致大多数响应问题的原因。目前正在进行工作，以将分页引入到仪表板的后端服务层 (PR 46644)。

默认情况下，cephadm 部署 Prometheus 服务器，为集群提供监控和告警功能。发送到 Prometheus 的数据由 mgr/prometheus 模块发出，该模块与 ceph-mgr 交互，以 Prometheus 暴露格式呈现 Ceph 计数器。

当集群扩展到超过 2,800 个 OSD 时，Prometheus 服务器无法始终从 mgr/prometheus 端点检索数据，主要是由于返回的数据量（来自单个端点的 > 400K 样本）。

尽管存在监控问题，我们仍然能够确定监控 69PB Ceph 集群所需的 Prometheus 实例的一些尺寸指南（YMMV！）。

深入了解规模对指标“路径”的影响是一个关键发现，并将作为后续博客文章中涵盖的进一步分析的基础。

那么我们学到了什么？