增加依据。。

舍弃的内容（不是很重要，没必要）

支持同主机部署多个守护进程

可用性

cephadm agent 相关改进梳理

1. 改进内容

1.1 Ceph 16：以 SSH 为主的中心化控制路径

在 cephadm 的主机纳管与生命周期管理中，控制面主要通过 MGR/cephadm 使用 SSH 连接各主机 完成。例如在主机加入集群的标准流程中，需要先将集群公钥写入新主机的 authorized_keys，再执行 ceph orch host add 完成纳管。

1.2 Ceph 17：引入 cephadm agent

Quincy 版本发布信息明确列出 "cephadm agent for increased performance/scalability" ，即将 cephadm agent 作为改善控制面性能与伸缩性的方向性能力引入。

在 Quincy 的大规模测试中，社区使用了 experimental cephadm agent ，用于向 orchestrator 提供 host/device/daemon state metadata。

1.3 Ceph 18：继续推进 agent，但文档口径仍为"under development"

社区在 Quincy@Scale 文章中提到 "意图在 Reef 成为 supported feature" 。

但 Reef 的 cephadm 文档在"Stability"章节仍将 cephadm agent列为"support remains under development"的功能项之一，因此在正式材料中不宜表述为"Reef 已完全成熟/完全 GA"。

2. 参考链接（直接给出 URL）

text 复制代码

1) v17.2.0 Quincy released
https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/

2) Quincy @ Scale: Testing with the Pawsey Supercomputing Centre
https://ceph.io/en/news/blog/2022/scaletesting-with-pawsey/

3) Reef 文档：Compatibility and Stability
https://docs.ceph.com/en/reef/cephadm/compatibility/

4) Reef 文档：Host Management
https://docs.ceph.com/en/reef/cephadm/host-management/

5) Quincy 文档：Cephadm Operations
https://docs.ceph.com/en/quincy/cephadm/operations/

6) Reef 文档：Hardware monitoring
https://docs.ceph.com/en/reef/hardware-monitoring/

7) Red Hat 文档：Monitor hardware health with node-proxy agent
https://docs.redhat.com/en/documentation/red_hat_ceph_storage/7/html/hardware_guide/monitor-hardware-health-with-node-proxy-agent_hw

8) Red Hat Bugzilla：部署 cephadm agent 后 4721/tcp 未自动放行
https://bugzilla.redhat.com/show_bug.cgi?id=2336863

9) Red Hat Errata
https://access.redhat.com/errata/RHSA-2025%3A9775

3. 改进原因

降低大规模场景下 SSH 控制面的连接/失败处理成本

在大规模集群下，SSH 作为控制路径需要处理大量连接、认证、失败重试与返回信息组织；Quincy@Scale 明确指出 cephadm 以 SSH 作为"control path"，并提到在负向测试中 SSH 问题会影响用户可用性与输出信息质量。
将状态获取从"中心侧拉取/探测"演进为"节点侧提供元数据"

Quincy@Scale 明确说明 experimental agent 用于向 orchestrator 提供 host/device/daemon 状态元数据，体现出用 agent 缓解控制面伸缩压力、提升状态数据质量与一致性的设计动机；同时 Quincy release notes 将其价值直接归因到 performance/scalability。

4. 对实际生产影响

4.1 正向影响（可写入生产收益）

控制面伸缩性改善方向明确：Quincy 版本发布信息将 cephadm agent 明确定位为提升性能/伸缩性。
状态感知与编排数据质量改善：在大规模测试中，agent 被用于提供主机、设备、守护进程的状态元数据。

4.2 风险与边界（必须在生产评审中说明）

Reef 文档仍标注 under development：在 Ceph 官方 Reef 文档口径下，cephadm agent 仍属于"支持仍在完善"的功能项，因此生产采用需要结合发行版/厂商支持矩阵与回退策略。
可观测性与日志压力风险：Quincy@Scale 指出 agent 在测试中"generated too much log traffic"，会影响排障可用性与日志系统容量规划。
网络与防火墙基线要求：企业发行版落地实践中存在"部署 cephadm agent 后 4721/tcp 未自动放行"的缺陷记录，说明需要将端口/防火墙策略纳入交付基线检查。

Ceph 16→18（Pacific→Quincy→Reef）RBD块存储可用性/易用性改进梳理（文档版）

说明：本文聚焦RBD块存储生产运维关键改进项，均基于Ceph上游官方证据（发布公告、官方文档），明确各版本归属，同步修正此前版本归属偏差，按"改进内容→参考链接→改进原因→生产影响→使用方法"统一模板整理，便于生产升级决策与运维落地。

RADOS：pg-upmap-primary "一键回退"能力（清理所有映射）

改进内容

1.1 Ceph 16（Pacific）：仅支持按PG逐条移除映射

在read balancer / pg-upmap-primary 相关运维中，移除pg-upmap-primary映射通常是针对单个PG逐条执行。

1.2 Ceph 17（Quincy）：未发现官方"all"级别清理命令作为核心特性宣传

Quincy 的核心发布信息未将 "rm-pg-upmap-primary-all" 作为亮点列出。

1.3 Ceph 18（Reef）：新增ceph osd rm-pg-upmap-primary-all（一次性清理全部映射）

Reef 系列的发布公告明确指出新增命令 ceph osd rm-pg-upmap-primary-all，用于在需要时清理OSDMap中所有pg-upmap-primary映射。此外，读主平衡器（read balancer）文档也给出该命令作为"一键清理全部映射"的手段。

参考链接（直接给出URL）

v18.2.5 Reef released（明确新增rm-pg-upmap-primary-all）

https://ceph.io/en/news/blog/2025/v18-2-5-reef-released/
Operating the Read (Primary) Balancer（文档给出rm-pg-upmap-primary-all用法）

https://docs.ceph.com/en/latest/rados/operations/read-balancer/

改进原因

提供"回到CRUSH默认"的运维回退路径：当调优/平衡过程中遗留大量pg-upmap-primary映射时，逐条清理成本高；新增all命令提供快速回退手段（发布公告的定位即"clear all mappings"）。

对实际生产影响

4.1 正向影响

降低复杂调优后的回退成本：在大量PG映射存在时可"一键恢复默认策略"，减少误配置长期残留风险。

4.2 风险与边界

属于强操作：会同时移除全量映射，建议在变更窗口、明确评估读主分布变化与潜在热点迁移影响后执行。

使用方法

清理所有pg-upmap-primary映射

ceph osd rm-pg-upmap-primary-all

OSD：慢操作日志从"刷屏"到"聚合/简报"

改进内容

1.1 Ceph 16（Pacific）：慢操作记录偏"逐条输出"，排障信噪比容易下降

上游证据聚焦在Quincy引入"concise reporting"，因此这里不做超出证据的细节断言。

1.2 Ceph 17（Quincy）：引入"慢操作简明/聚合式"日志，并可回退旧行为

Quincy发布说明明确：OSD在集群日志中对慢操作进行Concise reporting；如需恢复旧的更详细行为，可设置osd_aggregated_slow_ops_logging=false。

1.3 Ceph 18（Reef）：延续该策略（作为成熟默认行为的一部分）

Reef release notes仍保留同样的改进描述，表明该方向在Reef延续。

参考链接（直接给出URL）

Quincy release notes（引入concise/aggregated slow ops logging，并给出回退开关）

https://docs.ceph.com/en/latest/releases/quincy
Reef release notes（延续同一改进描述）

https://docs.ceph.com/en/latest/releases/reef

改进原因

提升可观测性"信噪比"：慢操作在故障或资源争用时可能成规模爆发，逐条刷屏会淹没关键信息；聚合/简报式输出更利于定位受影响范围与根因线索（Quincy以"concise reporting"定位该改进）。

对实际生产影响

4.1 正向影响

排障更聚焦：减少日志噪声，提升告警/健康信息可读性。
可控回退：需要详细排障时可临时关闭聚合，恢复旧的详细日志风格。

4.2 风险与边界

聚合日志可能隐藏单请求细节：复杂问题仍可能需要短期关闭聚合以获取更多上下文。

使用方法

恢复旧版更详细的慢操作日志行为

ceph config set osd osd_aggregated_slow_ops_logging false

RBD：rbd-nbd "安全重挂载/重启可恢复" 与厚置备语义（notrim）

修正说明：此前误将该能力归为Ceph 18特性，上游明确为Ceph 17（Quincy）引入，Ceph 18仅延续并固化文档。

改进内容

1.1 Ceph 16（Pacific）：rbd-nbd 进程重启对业务连续性更敏感

缺少官方"安全重挂载"能力作为亮点，不对具体故障行为做无证据扩展，仅强调Quincy引入的能力差异。

1.2 Ceph 17（Quincy）：新增rbd device attach/detach，支持rbd-nbd重启后"安全重挂载"

Quincy发布公告在RBD部分明确：新增rbd device attach / rbd device detach，允许在Linux kernel 5.14起实现rbd-nbd守护进程重启后的safe reattach。Reef的rbd-nbd manpage同样描述--reattach-timeout，即内核等待新rbd-nbd进程重新attach的超时机制。

1.3 Ceph 17（Quincy）：新增notrim映射选项，模拟厚置备语义

Quincy发布公告明确：rbd-nbd新增notrim map option，支持厚置备场景语义（similar to krbd）。

1.4 Ceph 18（Reef）：能力延续并固化为常规参数

Reef的rbd-nbd文档/手册包含--notrim等选项，将Quincy引入的能力标准化、文档化。

参考链接（直接给出URL）

v17.2.0 Quincy released（明确：安全重挂载 + notrim 均在Quincy引入）

https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/
Reef rbd-nbd manpage（包含attach/detach、reattach-timeout等机制说明）

https://docs.ceph.com/en/reef/man/8/rbd-nbd/
Ubuntu rbd-nbd manpage（展示--notrim、--reattach-timeout等参数）

https://manpages.ubuntu.com/manpages/jammy/man8/rbd-nbd.8.html

改进原因

提升rbd-nbd客户端可维护性与升级操作弹性：Quincy直接将attach/detach定位为支持rbd-nbd重启后的safe reattach（并给出kernel 5.14的前置条件）。
减少krbd与rbd-nbd的语义差异带来的运维不确定性：Quincy明确将notrim作为"支持厚置备语义、类似krbd"的改进。

对实际生产影响

4.1 正向影响

客户端侧可维护性增强：对rbd-nbd场景，升级/重启操作的风险降低（满足内核版本前提）。
厚置备语义更可控：在需要避免discard/trim透传的业务中，显式notrim提高可预期性。

4.2 风险与边界

内核版本约束：safe reattach的能力在Quincy公告中明确与Linux kernel 5.14相关。
notrim会影响空间回收策略：启用后discard不再回收底层空间，需与容量规划一致。

使用方法

rbd-nbd 重启后安全重挂载（示例：绑定到指定nbd设备）

rbd device attach / --device-type nbd --device /dev/nbd0

安全解除绑定（注意：rbd(8)文档提示detach操作一般不建议常规使用，应谨慎）

rbd device detach / --device-type nbd

禁用trim/discard透传（厚置备语义）

rbd-nbd map --notrim /

reattach-timeout可按需调整，见rbd-nbd手册说明。

RBD：删除/回收前的依赖关系确认（rbd children 支持 --image-id）

改进内容

1.1 Ceph 16（Pacific）：rbd children 回收站场景可操作性不足

rbd children以常规image语义为主，对回收站（trash）内镜像的依赖查询支持不足，此处不扩展无证据细节，仅以Reef引入项为对照。

1.2 Ceph 17（Quincy）：未引入相关改进

Quincy发布公告及文档中，未发现rbd children相关参数新增或能力优化。

1.3 Ceph 18（Reef）：rbd children 新增 --image-id，支持回收站镜像

Reef v18.2.4发布公告明确：rbd children新增--image-id选项，使其可以对trash中的镜像运行，实现回收站镜像的依赖关系查询。

参考链接（直接给出URL）

v18.2.4 Reef released（明确：rbd children增加--image-id，可用于trash）
https://ceph.io/en/news/blog/2024/v18-2-4-reef-released/

改进原因

降低误删风险，提升回收站治理可操作性：对trash内镜像仍可查询克隆/依赖关系，有利于在purge前做依赖校验（发布公告直接说明该能力）。

对实际生产影响

4.1 正向影响

更安全的回收流程：在rbd trash purge或彻底删除前，可用image-id方式确认依赖关系，避免误删关联镜像。

4.2 风险与边界

需要在运维流程中保存/获取image-id：需与现有运维脚本集成，确保能获取到目标镜像（含回收站镜像）的image-id。

使用方法

通过image-id查询children（适用于trash场景）

rbd children --image-id

RBD：设备取消映射参数标准化（rbd device unmap --namespace）

改进内容

1.1 Ceph 16（Pacific）：namespace场景依赖语法拼接

在namespace场景下，rbd device unmap无专门参数支持，更依赖image-spec语法拼接实现，对比项来自Reef引入的"补齐缺失选项"。

1.2 Ceph 17（Quincy）：未引入相关改进

Quincy发布公告及文档中，未发现rbd device unmap新增--namespace选项。

1.3 Ceph 18（Reef）：rbd device unmap 新增 --namespace

Reef v18.2.0发布公告明确：rbd device unmap新增--namespace选项，用于补齐此前命令缺失的namespace参数风格，统一参数使用体验。

参考链接（直接给出URL）

v18.2.0 Reef released（明确：rbd device unmap新增--namespace）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/

改进原因

提升脚本化与参数一致性：发布公告明确指出，namespace支持早已存在，但rbd device unmap缺少对应option；补齐后参数风格更一致，降低脚本编写复杂度。

对实际生产影响

4.1 正向影响

自动化脚本更健壮：避免复杂字符串拼接，降低脚本误解析概率，提升运维自动化可靠性。

4.2 风险与边界

需要对旧脚本做参数升级：原有依赖语法拼接的脚本，需适配新增--namespace参数，兼容性一般可控。

使用方法

rbd device unmap --namespace /

RBD：diff-iterate / fast-diff 路径的性能与稳定性提升（备份/同步可用性）

改进内容

1.1 Ceph 16（Pacific）：diff/增量同步易成为瓶颈

diff/增量同步在大镜像与高频场景更容易成为瓶颈，以Quincy引入的"dramatic performance improvement"作为对照，不扩展无证据细节。

1.2 Ceph 17（Quincy）：fast-diff场景下diff-iterate优先本地执行（性能显著提升）

Quincy release notes明确：当满足fast-diff条件且有exclusive lock时，diff-iterate guaranteed to execute locally，并指出对QEMU live disk sync / backup有"dramatic performance improvement"。

1.3 Ceph 18（Reef）：延续该改进并强化

Reef release notes同样保留该条目，且在Reef v18.2.4发布公告中再次强调，确认该能力的稳定性与实用性。

参考链接（直接给出URL）

Quincy release notes（diff-iterate本地执行保证 + 性能提升说明）

https://docs.ceph.com/en/latest/releases/quincy
Reef release notes（延续相同条目）

https://docs.ceph.com/en/latest/releases/reef
v18.2.4 Reef released（同条目在Reef backport release中再次强调）

https://ceph.io/en/news/blog/2024/v18-2-4-reef-released/

改进原因

减少远端交互开销，提高增量同步/备份路径吞吐：Quincy明确将其收益指向QEMU live sync与备份场景，并强调性能改进显著。
明确fast-diff使用前置条件：该条目明确绑定"exclusive lock可用"这一条件，引导用户正确使用fast-diff能力。

对实际生产影响

4.1 正向影响

备份/同步窗口更可控：对依赖diff的工具链（QEMU live sync / backup）更友好，缩短增量备份耗时，提升备份可靠性。

4.2 风险与边界

需要满足exclusive lock：否则无法获得"保证本地执行"的路径收益，需确保客户端配置支持并启用exclusive lock。

使用方法

启用fast-diff（通常也配合object-map等）

rbd feature enable / fast-diff

rbd feature enable / object-map

是否启用、以及与exclusive-lock的关系需要结合现有客户端/虚拟化栈策略评估；上游改进条目强调exclusive lock条件。

RBD：分层客户端加密（Layered client-side encryption）------多租户/克隆场景可用性增强

改进内容

1.1 Ceph 16（Pacific）：支持基础镜像级加密，分层克隆加密能力不完整

Pacific文档明确：从Pacific起，RBD客户端支持image-level encryption，但分层克隆场景下，加密能力存在缺失，无法实现克隆与父镜像独立加密。

1.2 Ceph 17（Quincy）：未引入分层加密改进

Quincy发布公告及文档中，未发现RBD分层客户端加密相关能力新增。

1.3 Ceph 18（Reef）：支持"分层客户端加密"，克隆可独立加密且保留COW语义

Reef v18.2.0发布公告明确：新增layered client-side encryption，允许每个克隆镜像使用与父镜像及其他克隆不同的加密格式与passphrase，并保留未格式化克隆的高效COW语义。

参考链接（直接给出URL）

v18.2.0 Reef released（明确layered client-side encryption的能力与语义）

https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/
Reef release notes（同条目进入正式release notes）

https://docs.ceph.com/en/latest/releases/reef/
Reef Image Encryption文档（说明RBD encryption的范围与约束，如krbd不支持）

https://docs.ceph.com/en/reef/rbd/rbd-encryption/

改进原因

增强克隆/多租户场景的隔离能力：允许克隆镜像使用不同加密格式与口令，本质是对"共享父层 + 各自独立密钥策略"的补齐，满足多租户场景下的安全隔离需求。

对实际生产影响

4.1 正向影响

更强的租户隔离与密钥策略灵活性：克隆不再被父镜像的加密格式/口令绑定，每个租户可独立配置加密策略，提升多租户场景安全性。

4.2 风险与边界

密钥管理复杂度上升：多租户、多克隆镜像独立加密，需要更严格的密钥生命周期与审计策略，避免密钥泄露或丢失。
krbd不支持加密：若客户端依赖krbd，需要特别关注（文档明确说明），需切换为支持加密的客户端方式。

使用方法

该能力的具体命令/流程应按采用的加密工作流落地（Reef文档对RBD encryption的范围与约束有详细说明）。

Dashboard：RBD相关运维UI增强（快照镜像、可视化管理）

改进内容

1.1 Ceph 16（Pacific）：Dashboard以基础监控为主，RBD运维UI支持不足

Dashboard以"监控 + 基础管理"为主，Day-1运维流程显式化程度有限，缺少RBD快照镜像等专项运维UI。

1.2 Ceph 17（Quincy）：新增扩容向导，未强化RBD专项UI

Quincy发布公告明确：新增Cluster Expansion Wizard，用于引导Day-1运维（添加主机、设备、服务），但未针对RBD新增专项运维UI。

1.3 Ceph 18（Reef）：Dashboard布局优化 + RBD快照镜像UI增强

Reef v18.2.0发布公告明确：

新Dashboard页面布局：活跃告警与关键图表以cards展示，提升可观测性；
RBD Snapshot mirroring：可通过UI配置，且支持快照调度，简化RBD快照镜像运维操作。

参考链接（直接给出URL）

v17.2.0 Quincy released（Cluster Expansion Wizard）

https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/
v18.2.0 Reef released（Dashboard cards、RBD snapshot mirroring UI）

https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/

改进原因

从"指标浏览"转向"问题优先"：通过cards突出活跃告警与关键视图，提高当班处置效率。
将RBD日常管理纳入UI：RBD快照镜像配置与调度UI化，降低对CLI命令的依赖，简化运维操作，减少误操作。

对实际生产影响

4.1 正向影响

告警处置更直接：活跃告警可见性提升，便于快速发现并处置RBD相关故障。
RBD运维更贴近业务对象：快照镜像、调度可在UI完成，降低脚本依赖，提升运维效率。

4.2 风险与边界

UI不能替代变更治理：关键RBD操作（如快照删除、镜像克隆）仍建议保留CLI/自动化的审计链路与回滚策略。

使用方法

Quincy：Dashboard入口使用Cluster Expansion Wizard执行扩容（发布公告已定义其用途）。
Reef：在Dashboard中使用RBD Snapshot Mirroring / Scheduling等新增UI能力，完成快照镜像配置与调度。

补充：版本归属修正汇总

本文已修正此前材料中的版本归属偏差，核心修正项如下：

rbd-nbd安全重挂载（rbd device attach/detach，kernel 5.14）：上游明确为Ceph 17（Quincy）引入，非Ceph 18，Ceph 18仅延续并固化文档。
rbd-nbd notrim：同样为Ceph 17（Quincy）引入，非Ceph 18，Ceph 18将其作为常规参数文档化。

下面按你要求，用"是否属于 Ceph16→Ceph18 的变化"先做判断；确认属实且对生产可用性/易维护性有价值的，我再按统一模板整理。对缺少官方材料支撑的点，会明确标注不建议写入正式文档。

结论性判断：哪些确实是 Ceph16→Ceph18 的"架构/易维护性"变化

A. 属实，且与 Ceph16→Ceph18 升级路径强相关（建议写入）

FileStore 在 Ceph18（Reef）已被弃用且不再支持（只剩 BlueStore） ：属实。(Ceph 文档)
LevelDB 支持在 Ceph17（Quincy）被移除，升级到 Ceph18 前需完成 RocksDB 迁移 ：属实。(Ceph)
RADOS Cache Tiering 在 Ceph18（Reef）被标记为 Deprecated（强烈不建议新部署） ：属实。(Ceph 文档)
ceph-objectstore-tool 新增 trim-pg-log-dups 离线修复能力（Quincy 期间引入，18 仍受益） ：属实。(Ceph)
cephadm OSD 移除流程支持 ceph orch osd rm ... --zap（从"先 rm、再单独 zap"演进为"rm 一体化可选 zap"） ：属实（Pacific 文档中移除 OSD 章节未出现 --zap，而 Reef/最新文档明确支持）。(Ceph 文档)

B. 属实，但"不是 Ceph18 新增"，更像 Cephadm 默认策略（建议写入但要改口径）

cephadm 默认启用 osd_memory_target_autotune ：属实，但在 Pacific（Ceph16）阶段就已经是 cephadm 默认行为，因此不能表述为"Ceph18 才开始默认开启"。(Ceph 文档)

C. 仅对 CephFS/文件系统相关；与你的 RBD 块存储生产相关性较弱（可选写入）

snap_schedule 保留快照数比 mds_max_snaps_per_dir 少 1（避免触顶） ：属实。(Ceph)
多 CephFS 场景下 snap-schedule 命令要求显式 --fs ：属实（Reef 18.2.1 级别的变更说明）。(Ceph)

D. 未找到足够"官方/主线文档"支撑（不建议写入，除非你有更权威出处）

"Monitor 日志轮转后需重新设置 mon_cluster_log_to_file=true 才继续写文件" ：我在官方 Reef 文档与发布说明中未检索到明确表述可作为证据链；现有文档更多是介绍 cephadm 的 logrotate 机制与如何启用文件日志，但不足以支撑你这条"行为变更"的结论，因此不建议写入正式材料（或需补充更权威的 issue/commit/发布说明再写）。(Ceph 文档)

按模板整理（可直接入文档）

1) FileStore 弃用，BlueStore 唯一化（结构/易维护性）

1. 改进内容

1.1 Ceph16（Pacific）：FileStore 已是"旧后端"，但仍可能在遗留集群中存在

在 Ceph16 时期，虽然 BlueStore 是主流与推荐，但历史遗留集群仍可能保留 FileStore OSD，生态与升级实践仍需要考虑兼容与迁移路径。

1.2 Ceph18（Reef）：FileStore 明确"deprecated 且不再支持"

Reef 文档明确指出：FileStore 在 Reef 版本已被弃用并且不再支持，要求迁移到 BlueStore。

2. 参考链接（直接给出 URL）

text 复制代码

1) Reef 文档：BlueStore Migration（明确说明 FileStore 不再支持）
https://docs.ceph.com/en/reef/rados/operations/bluestore-migration/

2) Reef/最新文档：Storage Devices（FileStore 章节同样给出"不再支持"的警告）
https://docs.ceph.com/en/latest/rados/configuration/storage-devices/

3. 改进原因

降低维护复杂度与测试矩阵 ：将 OSD 后端收敛到 BlueStore，减少遗留路径与组合带来的维护成本与边缘缺陷暴露面。(Ceph 文档)

4. 对实际生产影响

正向影响：统一后端后，调优、故障处置与升级约束更清晰，避免"同一集群多后端"带来的不一致问题。
风险与边界 ：从 Ceph16 升级到 Ceph18 的集群，如仍存在 FileStore OSD，将面临强制迁移要求 ；升级计划必须包含迁移窗口与回退预案。(Ceph 文档)

5. 如何使用

对于仍有 FileStore 的集群：按照官方迁移指南将 OSD 迁移为 BlueStore 后，再进入 Ceph18 升级阶段。(Ceph 文档)

2) LevelDB 移除，RocksDB 唯一化（结构/易维护性）

1. 改进内容

1.1 Ceph16（Pacific）：历史上存在 LevelDB/RocksDB 并存的迁移与兼容负担

早期组件（尤其是 MON/部分 KVStore 相关路径）存在从 LevelDB 向 RocksDB 迁移的历史包袱。

1.2 Ceph17（Quincy）：LevelDB 支持被移除（升级前要求迁移 RocksDB）

Quincy 发布说明明确：LevelDB support has been removed，并建议在升级到 Quincy 前完成 MON/OSD 的 RocksDB 迁移。

2. 参考链接（直接给出 URL）

text 复制代码

1) v17.2.0 Quincy released（明确说明 LevelDB support has been removed）
https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/

3. 改进原因

收敛 KVStore 实现、减少旧依赖 ：移除 LevelDB 构建与运行路径，降低维护与安全修复成本，并将优化集中在 RocksDB 上。(Ceph)

4. 对实际生产影响

正向影响：统一 RocksDB 后，升级与问题定位链路更清晰，减少"因后端差异导致的行为差异"。
风险与边界 ：Ceph16→Ceph18 的升级路径会跨过 Quincy，因此需要把"迁移 RocksDB"作为升级前置检查项。(Ceph)

5. 如何使用

升级规划中将"MON/OSD RocksDB 迁移检查"纳入变更单与验收项；不建议在未完成迁移时直接跨版本升级到 Quincy/Reef。(Ceph)

3) Cephadm：OSD 内存自动调优默认启用（易维护性，但不是 Ceph18 新增）

1. 改进内容

1.1 Ceph16（Pacific）：cephadm 默认将 `osd_memory_target_autotune` 设为 true

Pacific 文档已明确：cephadm 默认启用 OSD 内存自动调优；同时指出在超融合等场景可能不适用，需要评估与调整。

1.2 Ceph17（Quincy）：安装/引导阶段继续保持默认启用

Quincy 的 cephadm 部署文档同样说明 bootstrap 默认启用该能力，并给出自动分配比例的描述。

2. 参考链接（直接给出 URL）

text 复制代码

1) Pacific 文档：OSD Service（明确说明 cephadm 默认启用 osd_memory_target_autotune）
https://docs.ceph.com/en/pacific/cephadm/services/osd/

2) Quincy 文档：Using cephadm to Deploy a New Ceph Cluster（说明 bootstrap 默认启用）
https://docs.ceph.com/en/quincy/cephadm/install/

3. 改进原因

降低容量扩缩容与混部场景下的参数依赖 ：通过自动调优减少"按经验拍脑袋配置"导致的 OOM/争抢/不一致问题。(Ceph 文档)

4. 对实际生产影响

正向影响：在 OSD 数量变化、主机扩容或不同主机规格混杂时，减少手工调参频率。
风险与边界 ：超融合/极限性能场景仍需结合业务与宿主机资源做策略性关闭或固定值配置（官方文档已提示不适用场景）。(Ceph 文档)

5. 如何使用

默认随 cephadm 生效；如需调整，按文档指引修改相关配置项（例如自动分配比例、或对特定 OSD 关闭 autotune）。(Ceph 文档)

4) Cephadm：OSD 移除与清盘（zap）一体化能力增强（易维护性）

1. 改进内容

1.1 Ceph16（Pacific）：移除 OSD 与设备 zap 更偏"分步操作"

Pacific 的 cephadm OSD 文档中，"移除/替换 OSD"与"zapping devices"是不同小节：设备清理主要通过 ceph orch device zap <host> <path> 完成。

1.2 Ceph18（Reef/最新）：`ceph orch osd rm ... --zap` 将"移除 OSD + 清盘设备元数据"合并为一个运维动作

在 Reef/最新文档中，ceph orch osd rm 明确支持 --zap，用于在移除 OSD 时同步清理 LVM/分区等信息，便于自动化与重复部署。

2. 参考链接（直接给出 URL）

text 复制代码

1) Pacific 文档：OSD Service（设备 zap 作为单独操作）
https://docs.ceph.com/en/pacific/cephadm/services/osd/

2) Reef 文档：OSD Service（osd rm 支持 --zap 的描述）
https://docs.ceph.com/en/reef/cephadm/services/osd/

3) 最新文档：OSD Service（示例中包含 ceph orch osd rm ... --zap）
https://docs.ceph.com/en/latest/cephadm/services/osd/

3. 改进原因

减少"残留元数据导致二次部署失败"的概率 ：把常见的"移除后还要清理 LVM/分区信息"的步骤固化到同一条运维路径中，更适合自动化编排。(Ceph 文档)

4. 对实际生产影响

正向影响 ：回收盘、重建 OSD、批量替换等场景下，流程更短、脚本更稳定，降低漏步骤的风险。(Ceph 文档)
风险与边界 ：--zap 本质是破坏性操作，必须在确认该盘不再承载业务数据后执行，并纳入变更审批与二次确认流程。(Ceph 文档)

5. 如何使用

移除并清盘（示例以文档为准）：

bash 复制代码

ceph orch osd rm <osd_id> --zap

(Ceph 文档)

5) RADOS：Cache Tiering 在 Ceph18（Reef）弃用（易维护性/可用性）

1. 改进内容

1.1 Ceph18（Reef）：Cache tiering 被标记为 Deprecated，并明确不建议新部署

Reef 文档与 Reef 发布说明均明确：Cache tiering 已弃用，且社区强烈建议不要在新集群中部署，并建议从遗留部署迁移出去。

2. 参考链接（直接给出 URL）

text 复制代码

1) Reef 文档：Cache Tiering（顶部 Warning：deprecated in Reef）
https://docs.ceph.com/en/reef/rados/operations/cache-tiering/

2) v18.2.0 Reef released（Release notes 中列出 "Cache tiering is now deprecated"）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/

3. 改进原因

缺少维护者、稳定性与收益不匹配 ：官方文档明确指出长期缺少维护者，并提醒可能在未来被移除；同时社区建议不要新上该能力。(Ceph 文档)

4. 对实际生产影响

正向影响 ：减少复杂特性引入带来的性能抖动与运维成本，鼓励使用更可控的硬件分层/CRUSH 规则等手段实现差异化性能。(Ceph 文档)
风险与边界 ：已有 cache tier 的存量集群需规划迁移与替代方案，否则未来升级可能被动。(Ceph 文档)

5. 如何使用

官方建议口径是"不要新部署、存量尽快迁移"。迁移与替代策略需结合你的业务与 CRUSH/设备分层设计完成。(Ceph 文档)

6) RADOS/OSD 急救能力：`ceph-objectstore-tool trim-pg-log-dups`（易维护性）

1. 改进内容

1.1 Ceph17（Quincy）：引入离线 `trim-pg-log-dups` 以应对 OSD 无法启动的 PGLog dups 膨胀问题

Quincy 17.2.4 发布说明明确：新增离线机制，ceph-objectstore-tool 提供 trim-pg-log-dups 操作，用于在某些 PGLog dups 膨胀导致 OSD 无法启动时进行修复。

2. 参考链接（直接给出 URL）

text 复制代码

1) v17.2.4 Quincy released（明确说明新增 ceph-objectstore-tool 的 trim-pg-log-dups 离线机制）
https://ceph.io/en/news/blog/2022/v17-2-4-quincy-released/

2) Quincy release notes（条目化列出该工具能力）
https://docs.ceph.com/en/latest/releases/quincy

3. 改进原因

为"OSD 无法启动"的极端场景提供离线修复路径 ：发布说明将其定位为针对特定膨胀问题的离线补救手段。(Ceph)

4. 对实际生产影响

正向影响 ：增强灾难/疑难场景下的可恢复性，缩短部分无法启动故障的恢复路径。(Ceph)
风险与边界 ：属于底层离线工具链能力，应按官方场景描述使用，纳入标准化 SOP 与操作审计，避免误用扩大故障面。(Ceph)

5. 如何使用

该能力属于 ceph-objectstore-tool 的离线操作范畴，需在 OSD 离线/停机状态下按官方指导执行；建议将官方发布说明与对应 tracker 作为 SOP 附录。(Ceph)

7)（可选，CephFS 相关）snap_schedule 行为优化与多 CephFS 支持（与你 RBD 关联较弱）

1. 改进内容

Reef 18.2.0：snap_schedule 保留数量比 mds_max_snaps_per_dir 少 1，以便下次调度能创建新快照且不触顶。(Ceph)
Reef 18.2.1：多 CephFS 场景下 snap-schedule 命令要求显式 --fs。(Ceph)

2. 参考链接（直接给出 URL）

text 复制代码

1) v18.2.0 Reef released（snap_schedule retains one less snapshot...）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/

2) v18.2.1 Reef released（multi CephFS 需要 --fs）
https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/

3) Reef release notes（同样收录该条目）
https://docs.ceph.com/en/latest/releases/reef/

3. 改进原因 / 4. 生产影响 / 5. 使用方法

该部分主要面向 CephFS 快照调度治理；如果你的生产只做 RBD 块存储，这一节通常不放在"可用性/易维护性（RBD 生产）"主文档里，可作为"跨业务能力附录"。(Ceph)

监控与遥测相关改进梳理（Ceph16→Ceph18）

0. 结论性判断（哪些"确实是 Ceph16→Ceph18 期间的变化"）

SNMP-gateway（cephadm 服务） ：不是 v18 才引入，Ceph17（Quincy）已新增 ，Ceph18 文档/服务形态延续。(Ceph 文档)
ceph pg dump 增加 Scrub 可观测列 ：Ceph17（Quincy）引入 ，并非 v18 新增。(Ceph)
健康告警 POOL_APP_NOT_ENABLED 行为强化 ：Ceph18.2.1（Reef）明确引入行为变化 ，成立。(Ceph)
"43 个新增告警" ：这是 Ceph17（Quincy）监控告警体系增强 ，不是 Ceph18 才有；但从 Ceph16 升到 Ceph18 的路径确实会"获得这批新增告警"。(Ceph 文档)
Telemetry：perf 通道 ：Reef 文档仍建议启用 perf 通道，但该通道并非 v18 才出现（至少 Quincy 文档已存在该建议）。因此只能写成"提供/延续"，不宜写"v18 新增"。(Ceph 文档)
Telemetry：Rook 相关指标 ：Ceph17.2.1（Quincy）已新增 Rook metrics 到 basic 通道 ，不是 v18 新增。(Ceph)
Telemetry：basic 通道新增"按 pool 的 BlueStore 压缩指标" ：Ceph17.2.6（Quincy）引入 ，成立，但不是 v18 新增。(Ceph)

1) Cephadm：SNMP 集成（SNMP-gateway）

1. 改进内容

1.1 Ceph16（Pacific）：以 Prometheus/Alertmanager 为主，SNMP 需自建桥接

Ceph 原生监控主要基于 Prometheus 生态；若要对接传统 NMS（SNMP Trap），通常需要自建脚本或第三方组件桥接，交付与维护成本较高（该点属于行业常见现状，官方材料更多从"为何提供 SNMP 集成"侧面体现）。

1.2 Ceph17（Quincy）：新增 SNMP-gateway 作为 cephadm 可编排服务

Quincy 的版本说明在 cephadm 集成改进项中，明确列出 "New services supported ... SNMP-gateway" ，表明 SNMP-gateway 在 Ceph17 已进入官方服务矩阵。(Ceph 文档)

1.3 Ceph18（Reef）：形成稳定的"Alertmanager → SNMP Notification"官方链路文档

Reef 文档对 SNMP-gateway 的定位非常明确：将 Prometheus Alertmanager 的告警转为 SNMP Notification（Trap/Inform）并发往网管平台 ，实现与传统 NMS 的集成。(Ceph 文档)

2. 参考链接（直接给出 URL）

text 复制代码

1) Quincy release notes（cephadm 新增服务：SNMP-gateway）
https://docs.ceph.com/en/latest/releases/quincy

2) Reef 文档：SNMP Gateway Service（Alertmanager → SNMP Notification 的官方实现）
https://docs.ceph.com/en/reef/cephadm/services/snmp-gateway/

3. 改进原因

兼容传统企业网管体系 ：很多环境仍以 SNMP Trap/Inform 作为统一告警入口；官方通过 SNMP-gateway 将 Ceph 告警融入既有 NMS 流程，减少"自研桥接"成本。(Ceph 文档)

4. 对实际生产影响

正向影响：
- 告警对接标准化，减少脚本与第三方链路的维护负担；
- 告警外发路径更易纳入企业统一告警治理（分级、抑制、值班流程）。(Ceph 文档)
风险与边界：
- SNMP-gateway 本质上是"告警转发/协议转换"，告警质量仍取决于 Prometheus/Alertmanager 规则与收敛策略；若默认规则偏"吵"，需要同步做告警治理（silence、路由、分组）。(Ceph 文档)

5. 如何使用（示例以官方文档为准）

在 cephadm 管理的集群中按 Reef 文档部署/配置 SNMP-gateway，并将其对接到现有 Alertmanager 与 NMS 目标端：
- 参考服务文档与参数说明：(Ceph 文档)

2) RADOS：`ceph pg dump` 增强 Scrub 可观测性（Scrub 进度/耗时/排队状态）

1. 改进内容

2.1 Ceph17（Quincy）：`ceph pg dump` 增加 3 个关键列

Quincy 发布说明明确：ceph pg dump 新增三列用于 scrub 可观测性：

LAST_SCRUB_DURATION：上次 scrub 耗时（秒）
SCRUB_SCHEDULING：scrub 排期/排队/执行状态
OBJECTS_SCRUBBED：scrub 开始后的已检查对象数
该增强属于"可观测性改进"，并非 Ceph18 才引入。(Ceph)

2. 参考链接（直接给出 URL）

text 复制代码

1) v17.2.0 Quincy released（ceph pg dump 新增三列）
https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/

3. 改进原因

降低 scrub 排障复杂度 ：将"scrub 是否在跑、跑了多久、跑到哪儿、为何没跑"从日志/多命令拼装，前置到统一输出字段中，提升一线定位效率。(Ceph)

4. 对实际生产影响

正向影响：
- 更容易在容量压力、后台恢复、业务高峰等场景下评估 scrub 对性能的影响与调度是否被延迟；
- 更利于制定 scrub 窗口与参数治理策略（依据历史耗时与对象量做经验回归）。(Ceph)
风险与边界：
- 字段增强不等同于"scrub 本身更快"；它解决的是"可观测/可解释"，scrub 性能仍需结合硬件与参数治理。

5. 如何使用

直接使用 ceph pg dump 并关注新增字段进行 scrub 排障与容量治理分析。(Ceph)

3) RADOS：新增/强化健康警告 `POOL_APP_NOT_ENABLED`

1. 改进内容

3.1 Ceph18.2.1（Reef）：即使 pool 未使用，也会触发 `POOL_APP_NOT_ENABLED`

Reef 18.2.1 发布说明明确：只要 pool 未启用 application tag，就会报告 POOL_APP_NOT_ENABLED，不再依赖"是否在使用/是否有对象" 。并给出规避方式：用 ceph osd pool application enable 打标签；必要时可临时 mute。(Ceph)

2. 参考链接（直接给出 URL）

text 复制代码

1) v18.2.1 Reef released（POOL_APP_NOT_ENABLED 行为变化与处置建议）
https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/

2) Reef release notes（同条目收录）
https://docs.ceph.com/en/latest/releases/reef/

3. 改进原因

强化"池用途声明"这一运维规范 ：通过健康告警把"未声明用途的池"显式暴露出来，降低误用/误操作概率，并提升集群元数据治理一致性。(Ceph)

4. 对实际生产影响

正向影响 ：更早暴露"僵尸池/未初始化池/脚本遗漏"的风险点，利于合规与配置基线管理。(Ceph)
风险与边界：升级到 Reef 后可能出现"告警数量上升"（尤其是历史遗留池未打标签的环境），需要提前纳入升级检查清单。

5. 如何使用

为 pool 显式启用应用标签以消除告警：
- ceph osd pool application enable <pool> rbd|cephfs|rgw（命令在发布说明中已明确提及）(Ceph)
如需临时静默：ceph health mute POOL_APP_NOT_ENABLED（同样在发布说明中给出）(Ceph)

4) 监控与告警：新增 43 条默认告警规则（Prometheus/Alertmanager/Dashboard）

1. 改进内容

4.1 Ceph17（Quincy）：新增 43 个告警（总计 68），覆盖面扩大

Quincy release notes 明确写出："Monitoring and alerting: 43 new alerts have been added (totalling 68)" ，覆盖集群健康、MON、存储设备、PG、CephFS 等。该增强发生在 Ceph17，但从 Ceph16 升到 Ceph18 的升级路径会完整继承这批告警能力。(Ceph 文档)

2. 参考链接（直接给出 URL）

text 复制代码

1) Quincy release notes（明确：新增 43 个告警）
https://docs.ceph.com/en/latest/releases/quincy

2) Dashboard 告警相关配置（需配置 Alertmanager/Prometheus API 才能在 UI 完整展示/管理）
https://docs.ceph.com/en/latest/mgr/dashboard/

3. 改进原因

将"最佳实践告警规则"产品化 ：减少用户从零编写 PromQL 与告警规则的门槛，提升开箱即用的可观测覆盖率。(Ceph 文档)

4. 对实际生产影响

正向影响 ：更快建立告警基线，降低漏报，提升"问题发现前置"。(Ceph 文档)
风险与边界：
- 告警更"全"通常意味着更"吵"；需要做告警治理（分组、路由、静默、阈值校准），否则会引入告警疲劳。(Ceph 文档)

5. 如何使用

确保 cephadm 监控栈（Prometheus/Alertmanager）部署并配置 Dashboard 指向对应 API，才能在 UI 中查看、静默与管理告警。(Ceph 文档)

5) Telemetry：perf 通道、Rook 指标、压缩指标（注意：多为 Ceph17 引入，Ceph18 延续）

1. 改进内容

5.1 perf 通道：提供更细粒度的性能指标（非 Ceph18 新增，但 Reef 仍明确建议启用）

Reef telemetry 文档明确建议：开启 telemetry 后，可考虑启用默认关闭的 perf 通道。该能力至少在 Quincy 文档中已存在同样表述，因此不应写成"v18 新增 perf 通道"，而应写成"提供并延续"。(Ceph 文档)

5.2 Rook 相关指标：Ceph17.2.1 起将 Rook/K8s 信息纳入 basic 通道

Quincy 17.2.1 发布说明明确：Telemetry basic 通道新增 Rook metrics ，包括 Rook 版本、Kubernetes 版本、节点指标等。(Ceph)

5.3 basic 通道新增"按 pool 的 BlueStore 压缩指标"：Ceph17.2.6 引入

Quincy 17.2.6 发布说明明确：Telemetry basic 通道新增 per-pool bluestore compression metrics ，并建议用 ceph telemetry preview 查看样例报告。(Ceph)

2. 参考链接（直接给出 URL）

text 复制代码

1) Reef 文档：Telemetry Module（提到 perf 通道可启用）
https://docs.ceph.com/en/reef/mgr/telemetry/

2) v17.2.1 Quincy released（Telemetry basic 新增 Rook metrics）
https://ceph.io/en/news/blog/2022/v17-2-1-quincy-released/

3) v17.2.6 Quincy released（Telemetry basic 新增按 pool 的压缩指标）
https://ceph.io/en/news/blog/2023/v17-2-6-quincy-released/

3. 改进原因

在隐私/可控前提下提升"群体性可观测数据"的粒度 ：通过 channel 机制（basic/crash/device/perf 等）让用户更可控地选择上报内容，同时让社区更容易识别性能瓶颈与特性采用情况。(Ceph 文档)

4. 对实际生产影响

正向影响：
- basic 通道的压缩指标能帮助你评估"压缩节省空间 vs CPU 代价"的收益结构（按 pool 维度尤其利于多业务隔离场景）。(Ceph)
- Rook 指标对 K8s 环境的归因分析更友好（区分存储层与编排层因素）。(Ceph)
风险与边界：
- Telemetry 属于"自愿上报"；企业环境需要结合合规与数据出境策略评估是否启用，以及启用哪些 channel。(Ceph 文档)

5. 如何使用

查看/预览与启用（以文档描述为准）：
- ceph telemetry on --license sharing-1-0（开启）
- ceph telemetry enable channel perf（启用 perf 通道；文档明确 perf 默认 off）(Ceph 文档)
- ceph telemetry preview（查看报告样例，Quincy 17.2.6 发布说明明确提到）(Ceph)

你这段材料里我建议"不要写进正式文档/需要改写"的点

"Ceph v18 引入 snmp-gateway / 引入 pg dump 三列 / 引入 perf 通道 / 引入 rook 指标 / 引入压缩指标"这类表述需要改成：
- 多数是在 Ceph17（Quincy）引入，Ceph18（Reef）延续与完善 （上文已经按真实时间线写了）。(Ceph 文档)

增加依据。。

可用性

cephadm agent 相关改进梳理

1. 改进内容

1.1 Ceph 16：以 SSH 为主的中心化控制路径

1.2 Ceph 17：引入 cephadm agent

1.3 Ceph 18：继续推进 agent，但文档口径仍为"under development"

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

4.1 正向影响（可写入生产收益）

4.2 风险与边界（必须在生产评审中说明）

清理所有pg-upmap-primary映射

恢复旧版更详细的慢操作日志行为

rbd-nbd 重启后安全重挂载（示例：绑定到指定nbd设备）

安全解除绑定（注意：rbd(8)文档提示detach操作一般不建议常规使用，应谨慎）

禁用trim/discard透传（厚置备语义）

通过image-id查询children（适用于trash场景）

启用fast-diff（通常也配合object-map等）

结论性判断：哪些确实是 Ceph16→Ceph18 的"架构/易维护性"变化

A. 属实，且与 Ceph16→Ceph18 升级路径强相关（建议写入）

B. 属实，但"不是 Ceph18 新增"，更像 Cephadm 默认策略（建议写入但要改口径）

C. 仅对 CephFS/文件系统相关；与你的 RBD 块存储生产相关性较弱（可选写入）

D. 未找到足够"官方/主线文档"支撑（不建议写入，除非你有更权威出处）

按模板整理（可直接入文档）

1) FileStore 弃用，BlueStore 唯一化（结构/易维护性）

1. 改进内容

1.1 Ceph16（Pacific）：FileStore 已是"旧后端"，但仍可能在遗留集群中存在

1.2 Ceph18（Reef）：FileStore 明确"deprecated 且不再支持"

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

5. 如何使用

2) LevelDB 移除，RocksDB 唯一化（结构/易维护性）

1. 改进内容

1.1 Ceph16（Pacific）：历史上存在 LevelDB/RocksDB 并存的迁移与兼容负担

1.2 Ceph17（Quincy）：LevelDB 支持被移除（升级前要求迁移 RocksDB）

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

5. 如何使用

3) Cephadm：OSD 内存自动调优默认启用（易维护性，但不是 Ceph18 新增）

1. 改进内容

1.1 Ceph16（Pacific）：cephadm 默认将 osd_memory_target_autotune 设为 true

1.2 Ceph17（Quincy）：安装/引导阶段继续保持默认启用

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

5. 如何使用

4) Cephadm：OSD 移除与清盘（zap）一体化能力增强（易维护性）

1. 改进内容

1.1 Ceph16（Pacific）：移除 OSD 与设备 zap 更偏"分步操作"

1.2 Ceph18（Reef/最新）：ceph orch osd rm ... --zap 将"移除 OSD + 清盘设备元数据"合并为一个运维动作

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

5. 如何使用

5) RADOS：Cache Tiering 在 Ceph18（Reef）弃用（易维护性/可用性）

1. 改进内容

1.1 Ceph18（Reef）：Cache tiering 被标记为 Deprecated，并明确不建议新部署

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

5. 如何使用

6) RADOS/OSD 急救能力：ceph-objectstore-tool trim-pg-log-dups（易维护性）

1. 改进内容

1.1 Ceph17（Quincy）：引入离线 trim-pg-log-dups 以应对 OSD 无法启动的 PGLog dups 膨胀问题

2. 参考链接（直接给出 URL）

3. 改进原因

4. 对实际生产影响

5. 如何使用

7)（可选，CephFS 相关）snap_schedule 行为优化与多 CephFS 支持（与你 RBD 关联较弱）

1. 改进内容

2. 参考链接（直接给出 URL）

3. 改进原因 / 4. 生产影响 / 5. 使用方法

监控与遥测相关改进梳理（Ceph16→Ceph18）

0. 结论性判断（哪些"确实是 Ceph16→Ceph18 期间的变化"）

1) Cephadm：SNMP 集成（SNMP-gateway）

1. 改进内容

1.1 Ceph16（Pacific）：以 Prometheus/Alertmanager 为主，SNMP 需自建桥接

1.1 Ceph16（Pacific）：cephadm 默认将 `osd_memory_target_autotune` 设为 true

1.2 Ceph18（Reef/最新）：`ceph orch osd rm ... --zap` 将"移除 OSD + 清盘设备元数据"合并为一个运维动作

6) RADOS/OSD 急救能力：`ceph-objectstore-tool trim-pg-log-dups`（易维护性）

1.1 Ceph17（Quincy）：引入离线 `trim-pg-log-dups` 以应对 OSD 无法启动的 PGLog dups 膨胀问题

2) RADOS：`ceph pg dump` 增强 Scrub 可观测性（Scrub 进度/耗时/排队状态）

2.1 Ceph17（Quincy）：`ceph pg dump` 增加 3 个关键列

3) RADOS：新增/强化健康警告 `POOL_APP_NOT_ENABLED`

3.1 Ceph18.2.1（Reef）：即使 pool 未使用，也会触发 `POOL_APP_NOT_ENABLED`