分布式软件定义存储 快照过多的问题

随风_YA2H2

　　这是Ceph开发每周谈的第九十八篇文章，分布式软件定义存储记录从17年11月01号到17年11月6号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。

　　一句话消息

　　无

　　快照过多的问题

　　目前在 rbd 和 cephfs 会使用 unmanaged snapshot 接口进行快照的管理，每个池所得到的 snapid 并不是连续的，当快照删除时，会采用异步的方式在 osdmap 中记录要删除的 snap id，但这个 id 会变得非常大如果删除过程持续很久。

　　目前经过社区讨论，期望将原本把所有要 remove 的快照 id 放在 osdmap 中，改为只放一个 removed_snaps_lb_epoch 用于最小的删除快照 id，这样用来保证比这个更小的 id 都是安全删除过的。同时在 OSD 维护的 pg_info_t 中增加 removed_snaps，这样每次 osdmap 更新一个 removed snapid 时，都会增加到这个 pg_info_t 中，当成功删除后，把这个 id 移动到 purged_snaps。这样就可以在内存中维护 purged_snaps 和 removed_snaps，同时会把 purged_snaps 汇报给 mgr。

　　Mon 需要记录删除的 epoch 和snaps，mgr 同时需要汇报 puged_snaps 的并集给 MON，MON 负责收集所有 PG 的这些 snap 信息，形成完整的记录，最好跟现在 osdmap 类似的结果保存起来。

　　警告: 在当前 Ceph 版本中，切勿大量删除快照，极容易造成庞大的 OSDMap，形成集群故障。