02_存储快照

存储快照
概述
存储快照技术SNIA（StorageNetworking Industry Association）对快照（Snapshot）的定义是：关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点（拷贝开始的时间点）的映像。

快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。

快照的作用主要是能够进行在线数据备份与恢复。

当存储设备发生应用故障或者文件损坏时可以进行快速的数据恢复，将数据恢复某个可用的时间点的状态。

快照的另一个作用是为存储用户提供了另外一个数据访问通道，当原数据进行在线应用处理时，用户可以访问快照数据，还可以利用快照进行测试等工作。

所有存储系统，不论高中低端，只要应用于在线系统，那么快照就成为一个不可或缺的功能。

快照的实现方式
当前实现快照有主要有两种技术，一种是第一次写时复制(Copy OnFirst Write,COFW)，有时简称为写时复制（CopyOn Write,COW）。

即在数据第一次写入到某个存储位置时，首先将原有的内容读取出来，写到另一位置处（为快照保留的存储空间，此文中我们称为快照空间），然后再将数据写入到存储设备中。

而下次针对这一位置的写操作将不再执行写时复制操作。

这种技术常在计算机相关的技术中经常初使用，其基本原理大同小异，只是面向的对象不同，适用的场合不一样。

从COW 的执行过程我们可以知道，这种实现方式在第一次写入某个存储位置时需要完成一个读操作（读原位置的数据），两个写操作（写原位置与写快照空间），如果写入频繁，那么这种方式将非常消耗IO时间。

因此可推断，如果预计某个卷上的I/O多数以读操作为主，写操作较少，这种方式的快照实现技术是一个较理想的选择，因为快照的完成需要较少的时间。

除此之外，如果一个应用易出现写入热点，即只针对某个有限范围内的数据进行写操作，那么COW 的快照实现方式也是较理想的选择。

因为其数据更改都局限在一个范围内，对同一份数据的多次写操作只会出现一次写时复制操作。

写时复制的示意图
但是这种方式的缺点也是非常明显的。

如果写操作过于分散且频繁，那么COW造成的开销则是不可忽略的，有时甚至是无法接受的。

因此在应用时，则需要综合评估应用系统的使用场景，以判断这种方式的快照是否适用。

快照实现技术中的另一种技术是 I/O 重定向（I/O Redirect）。

即将读写操作重新定向到另一个存储空间中。

在一个快照生成期间，所有的写操作将被重定向到另一个介质，而读操作是否需要读重定向，则需要根据读取的位置是否有过自上次快照以来的写重定向，必须对有过写重定向的位置进行读重定向，否则不需要进行读定向。

当要创建一个快照时，则将自上次快照以来所有的重定向写数据所对应在源介质中的数据复制出来生成这个时间点的快照，然后再将这些重定向写数据写回到源介质中的相应位置上，从而完成一个快照生成过程。

I/O 重定向示意
下图中显示了IO重定向的执行过程。

I/O 重定向示意图
从上面的过程来看，关键的性能影响在于快照生成时的四次I/O操作（一次读源介质，一次写快照数据，一次读快照介质，一次写源介质），另一个则是重定向的计算工作。

这种方式虽然看起来最后生成快照时的I/O操作较多，但是考虑到这个操作是在生成快照时才会发生，特别是快照生成时可以对I/O操作进行排序，可以使得对介质的读写得到较好的优化，因此使影响很小。

而对于重定向的计算操作对于当下的计算能力来说，不会成为一个性能的瓶颈问题。

因此这种快照实现方式在非快照执行期间的影响甚小。

因此这种方式比较适合Write-Intensive（写密集）类型的存储系统。

快照生成
下图是快照生成过程的示意图：
快照生成图
SNIA 将快照的实现方式表述为：镜像分离(split mirror)、改变块(changed block)、并发(concurrent)三大类。

后两种在实现时其实质就是写时复制及I/O 重定向。

对于 split mirror的方式，由于其灵活性以及开销问题，在实际的存储系统中，并不实用。

实现层次
概述
计算机的存储结构是一个类似于 TCP/IP 一样的栈结构。

栈中包括硬件与软件部分。

栈中不同层为上层提供服务，同时利用下层的接口（如下图）。

存储栈
存储栈
因此在实现上，快照可以在不同的栈层上实现。

但是不同的层其效果及特点是不一样的。

一般来说，在应用层不太合适实现快照功能。

因为不同的应用是千差万别的，因此需要针对不同的应用实现快照功能，这个代价也太高了。

但在应用层实现快照也并不是说一无用处，如在应用层实现快照的一个典型的例子就是vmWare 虚拟化软件中的快照功能。

只是这种快照功能应用在存储系统中不现实。

其次在文件系统层实现快照与应用也是具有同样的缺点，就是需要针对不同的文件系统实现快照功能，这样的代价也很大。

实现层次案例
实现的快照的功能的文件系统基本上都是一些专用系统或者专为某个特定功能实现的文件系统。

在这个层级上实现快照，缺乏灵活性和可扩展性。

这个比较典型的例子就是ZFS。

而较为适宜实现快照功能的层应该为卷管理层以及物理层。

在这两个层中都不与特定的应用及文件系统相关。

这里比较典型的例子有Linux 的LVM。

而在硬件层次上实现快照又通常有许多种，在这个层次上实现的快照一般为专用系统，好处是性能是各个方式中最好的。

但是在这个层次上实现的快照也有一个不可避免的缺点，那就是由于不与特定的应用及文件系统关联，
因此其就无法理解上层的应用逻辑，也就无法保证每个快照都处于数据一致性状态的。

但是这个缺点是可以通过其他的方式减少或者解决的，比如在生成快照之前先对数据进行刷新操作，或者在恢复快照时对文件系统进行一致性检查等。