注意
本文档适用于 Ceph 的开发版本。
关于 Cephadm 可扩展性的注释和思考
关于本文档
本文档没有定义具体的提议或未来的工作。它只是列出了一些可能与未来 cephadm 增强功能相关的想法。
简介
当前情况
Cephadm 管理所有已注册的主机。这意味着它会定期从每个主机上抓取数据，以识别主机上的变化，例如：
添加/移除磁盘
添加/移除守护程序
主机网络/防火墙等发生变化
目前，cephadm 每 6 分钟抓取一次每个主机（最多 10 个并行），除非手动强制刷新。
磁盘 (ceph-volume)、守护程序 (podman/docker) 等的刷新按顺序进行。
有了 cephadm exporter，我们现在大大减少了扫描主机的时间，但问题仍然存在：
cephadm-exporter 是否足以解决未来所有的可扩展性问题？
cephadm-exporter REST API 的考量
cephadm-exporter 使用 HTTP 提供主机元数据的端点。我们可能会遇到这种方法的一些问题，需要适时缓解。
使用 cephadm-exporter，我们使用 SSH 和 HTTP 连接到每个主机。拥有两个不同的传输层感觉很奇怪，我们可能需要考虑将其减少到只使用一个协议。
当前将
bin/cephadm交付给主机的方法不允许使用外部依赖项。这意味着我们只能使用内置的 HTTP 服务器库，这对于提供良好的开发体验来说并不理想。我们需要打包和分发（以某种方式）bin/cephadm，才能使用更好的 http 服务器库。
MON 的 config-key 存储
在 mgr/cephadm 从每个主机查询元数据后，cephadm 将数据存储在 mon 的 k-v 存储中。
如果允许每个主机将自己的元数据写入存储，则 mgr/cephadm 将不再需要收集数据。
出现了一些问题：
mgr/cephadm现在需要从 config-key 存储中查询数据，而不是依赖缓存数据。cephadm 知道三种不同类型的数据：(1) 关键数据，需要存储在 config-key 存储中。(2) 可以只保存在内存中的数据。(3) 可以存储在 RADOS 池中的数据。我们如何将这个想法应用于这些不同类型的数据？
增加工作池大小
mgr/cephadm 目前能够同时抓取 10 个节点。
单个主机的抓取时间保持不变。我们只是减少了总的执行时间。
在最好的情况下，我们可以达到 O(主机) + O(守护程序)。
向后兼容性
任何更改都需要向后兼容，或者与任何现有功能完全隔离。目前有一些正在运行的 cephadm 集群需要升级路径。