注意

本文档适用于 Ceph 开发版本。

Notes and Thoughts on Cephadm’s scalability

关于本文档

本文档并未定义具体的提案或未来的工作。相反，它仅仅列出了一些可能对未来的 cephadm 增强相关的想法。

简介

当前情况：

Cephadm 管理所有注册的主机。这意味着它定期从每个主机收集数据以识别主机上的变化，例如：

  • 添加/删除磁盘

  • 添加/删除守护进程

  • 主机网络/防火墙等发生变化

目前，cephadm 每 6 分钟扫描每个主机（最多并行 10 个），除非手动强制刷新。

磁盘（ceph-volume）、守护进程（podman/docker）等的刷新按顺序进行。

通过 cephadm 导出器，我们现在大大减少了扫描主机的时间，但问题仍然存在：

cephadm 导出器是否足以解决所有未来的可扩展性问题？

关于 cephadm-exporter 的 REST API 的考虑

cephadm 导出器使用 HTTP 为主机元数据提供服务端点。我们可能会遇到一些使用这种方法的问题，需要在某个时候缓解这些问题。

  • 通过 cephadm 导出器，我们使用 SSH 和 HTTP 连接到每个主机。有两个不同的传输层感觉很奇怪，我们可能需要考虑将其减少到仅使用一个协议。

  • 当前的交付方式bin/cephadm到主机的当前方法bin/cephadm需要被打包和分发（以某种方式或另一种方式），以便我们能够使用更好的 HTTP 服务器库。

MON 的配置键存储

在查询每个主机的mgr/cephadm元数据后，cephadm 将数据存储在 mon 的键值存储中。

如果允许每个主机将其自己的元数据写入存储，则mgr/cephadm就不再需要收集数据。

出现了一些问题：

  • mgr/cephadm现在需要从配置键存储中查询数据，而不是依赖于缓存数据。

  • cephadm 知道三种不同类型的数据：(1) 需要存储在配置键存储中的关键数据。(2) 仅能存储在内存中的数据。(3) 可以存储在 RADOS 池中的数据。我们如何将这些想法应用于这些不同类型的数据。

增加工作池的大小

mgr/cephadm目前能够同时抓取 10 个节点。

单个主机的抓取需要相同的时间持久化。我们只是减少了整体执行时间。

最好能达到 O(主机) + O(守护进程)。

向后兼容性

任何更改都需要向后兼容或与任何现有功能完全隔离。目前有正在运行的 cephadm 集群需要升级路径。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.