高端存储快照实现原理解读（转载）

我个人认为对于高端存储来说，RIAD和快照是所有上层应用的基础。前面我在切西瓜刀法中说过，RAID和后面的分层和瘦分配关系很大，有一个好的RAID基础，如采用RAID 2.0块虚拟化技术，上层的动态分层和精简配置应用实现就会更加灵活和高效。同样，快照技术是灾备的基础，在LUN的复制、迁移、数据的本地备份、远程复制等等都需要用到快照技术的支持。因此，陈列的一切增值功能的底层基础都是RAID和快照。

存储快照技术：SNIA（StorageNetworking Industry Association）对快照（Snapshot）的定义是：关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点（拷贝开始的时间点）的映像。快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。

讲快照实现原理之前，我们先给大家讲业界一个IT人士丁老师给我们讲的一个小故事。丁老师是我非常敬佩的产品销售人员，现在也在销售高端存储产品。一天，丁老师去和客户交流高端存储，在喷了半天讲完产品后，精彩的场景发生了：

笑话听罢，我们来讲讲高端存储快照实现的两种技术。

目前实现快照一般有两种方法，传统的存储快照技术COW(Copy-On-Write)和现在渐渐流行的基于写重定向的存储快照技术ROW(Redirect-On-Write)。

3PAR采用COW技术，我们用它举例来看一下实现原理：

大家看到，快照创建的以后，如果有对原卷的数据修改，修改的数据第一次被修改的时候就把数据COPY到快照卷里，如图中的D。只需要第一次修改的时候复制，因此有些书也把这种技术叫COFW(Copy-On-First-Write）。

而IBM XIV采用完全一种不同的技术ROW(Redirect-On-Write)，我们来看一下XIV如何做的：

大家可以看到，ROW的不做复制，如果原卷有数据块被修改，重新写到一个新的地方好了，原卷的修改一下数据块指针，这个动作非常快，而快照卷不用做任何改变。

估计你马上会问我，那个技术好，我就知道为这么问，哈哈。

这又是一个艺术的问题，为啥这也是一个艺术问题，别急，听我说。

COW最大的问题是对写性能有影响。第一次修改原卷，需要复制数据，因此需要多一次读写的数据块迁移过程。这个就比较要命，应用需要等待时间比较长。但原卷数据的布局没有任何改变，因此对读性能没有任何影响。

ROW最大的问题是对读性能影响比较大。ROW写的时候性能基本没有损耗，只是修改指针，实现效率很高。但多次读写后，原卷的数据就分散到各个地方，对于连续读写的性能不如COW。

由于这两种实现机制不同，因此性能也不同，一般来说，ROW就像采用电子快门的照相机，拍照的速度快，每分钟得到的快照数就多；而COW就像采用机械快门的传统相机，快门的速度慢，系统支持的快照数一般都比较少。下表是我整理的各个厂商的高端存储性能，大家对比一下就知道差别了。

你可能会问，怎么没有HW Oceanstor 18000。我找了很多资料，都没有找到Oceanstor 18000的快照的资料，但我曾经看到一份华为中端存储的资料，说采用的也是COW技术，性能和3PAR一样256。因此，考虑到Oceanstor 18000也采用3PAR一样的RAID 2.0技术，因此，个人估计高端也一样或者比中端高一些。因此，大家理解的时候可以等同3PAR好了。

COW是最传统的实现方法，当然，现在COW也有很多改进，比如采用异步COW，现在的高端存储Cache都很大，如Oceanstor 18000最大支持3TB，因此可以先写到CACHE里面就回复主机写完了，这样应用就不用等待。等落盘的时候再触发快照复制的动作。还有，高端存储一般是数据库的应用，这些应用有一个特点，就是写少读多，一般是1:3到1:10。这个也比较容易理解，你银行存了一笔钱（写），但可能经常查询余额（读)，就怕钱少了，哈哈。因此，COW这种方式在还是比较适合这种应用的。

但现在的备份技术发展也对快照提出了更高的要求，用户需要更快更多的快照来满足RTO/RPO的要求。人总是很贪婪的。IBM XIV由于底层采用非常小的1M大小的CHUNK，因此，本来数据就全部打散的非常均匀了，因此高端存储之父深知原来symmetrix的缺点，让XIV直接采用ROW技术，个人感觉是一个亮点。因为ROW的缺点是连续读写比较慢，但XIV的CHUNK比较小，如果是大数据库的读写，可以分散到很多个CHUNK里面，因此，读写性能应该影响不大。但3PAR的CHUNK是1G，太大了些，但设计的时候可以按照extend的粒度来打散，应该问题也不大。估计是10+年前，ROW的技术还没有流行吧。而HW，估计也是由于延续使用了中端存储的快照代码，有了历史的包袱，因此也没有采用ROW技术。当然XIV的ROW实现有一个问题，因为它的数据块是1M大小，上面不在细分了，因此如果比较小的I/O，如每次只写8K，那么8K需要写到新的地方，原来的数据也要COPY过来，ROW的优势就没有了。

从XIV的实现机制看，我感觉不太适合数据库应用，如ORACLE目前缺省的I/O块大小还是8K，这样ROW的优势就发挥不出来了。

个人认为，RAID 2.0和ROW是个绝配，虽然现在3PAR和HW在快照性能这块已经强于很多传统的高端存储厂商，但如果采用ROW将会给用户带来更大的价值。当然，我建议厂商实现的时候能克服XIV的缺陷，可以依据Grain的粒度来做最好，但这样可能管理的开销会变大，这又是一个艺术的问题，还是由厂商去回答吧，我这等屌丝也就是唧歪一下罢了。

总之，个人认为ROW应该是快照的发展方向，据说EMC的中端支持COW的同时也支持ROW了。