本文共 1090 字，大约阅读时间需要 3 分钟。

经常会有人问我关于Ceph中级联快照的问题，级联过多时，是否会影响性能，这篇文章就来说一说这个事情。先根据下图说一下什么是级联快照。

1）Base Image，没做任何改变的情况下，创建一个Snap S1

2）在过了一段时间之后，Base Image进行了修改，比如修改了DataA1，那么这个修改实际上发生了如下事情

2A）找到DataA1对应的Object，然后将其从Base Image中拷贝之后形成S1中对应的Object比如Base1。

2B）然后修改Base Image中的DataA1。

3）基于S1生成一个Clone的卷比如说名为S1C1，然后对S1C1做了一些修改，比如说，生成了修改数据DataB1，先要从S1中查找DataB1对应的Object，发现S1种没有，则会继续查找BaseImage，找到最终的Object进行修改。如果在S1种找到对应的Object，则直接进行更新。

4）过了一段时间之后，基于S1C1又进行了快照操作，生成S1C1-S1，则之后针对S1C1的改动，将会影响S1C1-S1中的数据。比如说之后又做了修改，改变了DataB2，则会先将之前的数据DataB1拷贝到S1C1-S1中形成DataB1.

5）再之后，又从S1C1-S1中clone生成了S1C1-S1C1。

6）此时，针对S1C1-S1C1进行更新操作时，就会有级连的问题。比如生成DataC1，librbd会首先从找自己节点上是否有这个对象，如果没有，librbd会查找它的父亲S1C1-S1，发现仍然没有，则继续向上查找，直到最后从BaseImage中将数据读取出来。

在使用这种级连方式访问，数据时，大家会有一个顾虑，就是所有后来创建的卷的数据访问，可能都需要从BaseImage中抓取过来，那么BaseImage可能成为访问的热点，但其实这点大可不必担心。如果针对BaseImage的访问很多时，Ceph底层的文件系统会将这些热数据缓存在内存中，所有后期的数据访问也都是访问内存的。

另外，只要之前Crush设计的足够合理，那么BaseImage中的数据也基本上会随机均匀的分布在集群中的所有OSD上，所以也基本上不存在某个或者某几个Object成为热点的问题。

解决这种卷级连的问题，目前有两种方法：

1）避免出现太长的卷级连，一般建议维持在5级以内，当出现大于5级的情况时，最好使用卷的flatten功能将链截断。卷的flatten就是将父卷中所有的数据都拷贝到子卷中去。

2）通过Ceph的Object Map

在接下来的文章中会会介绍Object Map。