百度快照实现原理 存储快照实现原理

存储快照实现原理

2018年01月08日 11:21:36

阅读数：406



Mclaren的博客http://blog.sina.com.cn/u/3031876173

存储快照有两种实现方式：COW(写时复制 Copy-On-Write)、ROW(写重定向 Redirect-On-Write)，两种实现方法有区别，造成读写性能、应用场景有比较大的区别。
COW：

原理见下图(从网上找的，没自己画)。
1)原卷数据是A~G。此卷Metedata像指针一样指向这些数据。
2)当做快照时，重新复制一份Metedata，并且也指向这些A~G数据。
3)当有数据要写入到源卷时(下图写入D')，写入到D的原位置之前，需要把D拷贝出放到一个新位置。然后修改快照的Metedata的其中一个指针指向拷贝出的位置[D](图中是Snapshot data的存储位置)。同时，把D’写入到D原来的位置。

此方式可以看出，源卷的Metedata的是没有变化的。对原卷是连续的数据，多次快照，多次写之后还是 连续的数据，因此读性能或者对单个位置的多次写性能都不会有很大的影响。
但是， 快照的数据是非连续的，如数据ABCEFG还是在源卷的位置，是连续数据。而数据D在存储的其他位置，非连续。如果多次快照，不同位置的多次读写后，快照的数据可能就比较混乱。造成对快照的读写延时较大。

应用场景：

这种实现方式在第一次写入某个存储位置时需要完成一个读操作（读原位置的数据）， 两个写操作（写原位置与写快照空间），如果写入频繁，那么这种方式将非常消耗IO时间。因此可推断，如果预计某个卷上的I/O多数以 读操作为主，写操作较少的场景，这种方式的快照实现技术是一个较理想的选择，因为快照的完成需要较少的时间。除此之外，如果一个应用易出现写入热点，即只针对某个 有限范围内的数据进行写操作，那么COW的快照实现方式也是较较理想的选择。因为其数据更改都局限在一个范围内，对同一份数据的多次写操作只会出现一次写时复制操作。

但是这种方式的 缺点也是非常明显的。如果写操作过于分散且频繁，那么 COW造成的开销则是不可忽略的，有时甚至是无法接受的。因此在应用时，则需要综合评估应用系统的使用场景，以判断这种方式的快照是否适用。

ROW：

原理见下图：

Vd是源卷的Metedata，分别指向4块数据。做快照时，snap的metadata也指向此4块数据。当有数据写入时，把数据写入另外一个位置，然后修改vd的其中一个metedata到新位置。snap的metedata数据不变化。

此方式源卷经过长时间写后，所有数据块的位置可能都会重定向到其他位置，导致源卷的数据不连续。在集中式存储情况下，会导致对源卷的读写性能降低。

两种方式的优缺点，及应用场景：

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

ROW在传统存储情况下最大的问题是对读性能影响比较大。ROW写的时候性能基本没有损耗，只是修改指针，实现效率很高。但多次读写后，原卷的数据就分散到各个地方，对于连续读写的性能不如COW。这种方式比较适合Write-Intensive（写密集）类型的存储系统

但是，在分布式存储的情况下，ROW的连续读写的性能会比COW差吗？就不一定了。正常情况下，读写性能的瓶颈一般是在磁盘上。分布式存储情况下，业务层看到连续存储，实际上是分布在不同的服务器的不同硬盘中，数据越是分散，系统性能越高。而ROW把原数据打散之后，对性能反而有好处。

因此，整体情况下ROW基本上是对读写性能影响较小，因此是业界发展方向。

下图是几个厂家的快照实现方式：

   

目前分布式存储比较流行，华为有个FusionStorage数据，说是无限次快照，而且0性能下降，vSAN快照10%~30%的性能下降。从上面的分析来看，就知道两个场景的实现方法了。 

快照另外一个非常重要的特性是快照一致性组（Consistency Group），这个功能就是支持多个LUN或者叫卷volume同时做快照，保证数据的一致性。

如果采用阵列的快照来做数据库的备份，必须所有的LUN都是一个时间点的才行，这样数据库恢复的时候才能起来，否则数据库必须回滚到某一个一致的时间点，意味数据的丢失。比较完美的做法就是在主机安装一个快照的agent，最好是多路径软件具备这个功能，在高端存储要做快照的时候，对主机的快照agent说，别动，要照相了。主机agent接受到摄影师的命令后，把ORACEL主机缓存的内容flush一下到陈列来，然后hold住，阵列也尽快把cache的内容 flush到硬盘里，ORACLE用到的所有硬盘一块喊”茄子“，摄像师一按快门，一幅完美的快照就产生了。

一致性组除了保证照相的时候一致性外，还有恢复的时候要一致性恢复。这块的实现的重要性就不如照相的时候重要，可以人工选择同一时间的LUN快照恢复就可以了。最重要的是照相的时候必须要一致，而且这个人工干不了。



Mclaren的博客http://blog.sina.com.cn/u/3031876173

存储快照有两种实现方式：COW(写时复制 Copy-On-Write)、ROW(写重定向 Redirect-On-Write)，两种实现方法有区别，造成读写性能、应用场景有比较大的区别。
COW：

原理见下图(从网上找的，没自己画)。
1)原卷数据是A~G。此卷Metedata像指针一样指向这些数据。
2)当做快照时，重新复制一份Metedata，并且也指向这些A~G数据。
3)当有数据要写入到源卷时(下图写入D')，写入到D的原位置之前，需要把D拷贝出放到一个新位置。然后修改快照的Metedata的其中一个指针指向拷贝出的位置[D](图中是Snapshot data的存储位置)。同时，把D’写入到D原来的位置。

此方式可以看出，源卷的Metedata的是没有变化的。对原卷是连续的数据，多次快照，多次写之后还是 连续的数据，因此读性能或者对单个位置的多次写性能都不会有很大的影响。
但是， 快照的数据是非连续的，如数据ABCEFG还是在源卷的位置，是连续数据。而数据D在存储的其他位置，非连续。如果多次快照，不同位置的多次读写后，快照的数据可能就比较混乱。造成对快照的读写延时较大。

应用场景：

这种实现方式在第一次写入某个存储位置时需要完成一个读操作（读原位置的数据）， 两个写操作（写原位置与写快照空间），如果写入频繁，那么这种方式将非常消耗IO时间。因此可推断，如果预计某个卷上的I/O多数以 读操作为主，写操作较少的场景，这种方式的快照实现技术是一个较理想的选择，因为快照的完成需要较少的时间。除此之外，如果一个应用易出现写入热点，即只针对某个 有限范围内的数据进行写操作，那么COW的快照实现方式也是较较理想的选择。因为其数据更改都局限在一个范围内，对同一份数据的多次写操作只会出现一次写时复制操作。

但是这种方式的 缺点也是非常明显的。如果写操作过于分散且频繁，那么 COW造成的开销则是不可忽略的，有时甚至是无法接受的。因此在应用时，则需要综合评估应用系统的使用场景，以判断这种方式的快照是否适用。

ROW：

原理见下图：

Vd是源卷的Metedata，分别指向4块数据。做快照时，snap的metadata也指向此4块数据。当有数据写入时，把数据写入另外一个位置，然后修改vd的其中一个metedata到新位置。snap的metedata数据不变化。

此方式源卷经过长时间写后，所有数据块的位置可能都会重定向到其他位置，导致源卷的数据不连续。在集中式存储情况下，会导致对源卷的读写性能降低。

两种方式的优缺点，及应用场景：

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

ROW在传统存储情况下最大的问题是对读性能影响比较大。ROW写的时候性能基本没有损耗，只是修改指针，实现效率很高。但多次读写后，原卷的数据就分散到各个地方，对于连续读写的性能不如COW。这种方式比较适合Write-Intensive（写密集）类型的存储系统

但是，在分布式存储的情况下，ROW的连续读写的性能会比COW差吗？就不一定了。正常情况下，读写性能的瓶颈一般是在磁盘上。分布式存储情况下，业务层看到连续存储，实际上是分布在不同的服务器的不同硬盘中，数据越是分散，系统性能越高。而ROW把原数据打散之后，对性能反而有好处。

因此，整体情况下ROW基本上是对读写性能影响较小，因此是业界发展方向。

下图是几个厂家的快照实现方式：

   

目前分布式存储比较流行，华为有个FusionStorage数据，说是无限次快照，而且0性能下降，vSAN快照10%~30%的性能下降。从上面的分析来看，就知道两个场景的实现方法了。 

快照另外一个非常重要的特性是快照一致性组（Consistency Group），这个功能就是支持多个LUN或者叫卷volume同时做快照，保证数据的一致性。

如果采用阵列的快照来做数据库的备份，必须所有的LUN都是一个时间点的才行，这样数据库恢复的时候才能起来，否则数据库必须回滚到某一个一致的时间点，意味数据的丢失。比较完美的做法就是在主机安装一个快照的agent，最好是多路径软件具备这个功能，在高端存储要做快照的时候，对主机的快照agent说，别动，要照相了。主机agent接受到摄影师的命令后，把ORACEL主机缓存的内容flush一下到陈列来，然后hold住，阵列也尽快把cache的内容 flush到硬盘里，ORACLE用到的所有硬盘一块喊”茄子“，摄像师一按快门，一幅完美的快照就产生了。

一致性组除了保证照相的时候一致性外，还有恢复的时候要一致性恢复。这块的实现的重要性就不如照相的时候重要，可以人工选择同一时间的LUN快照恢复就可以了。最重要的是照相的时候必须要一致，而且这个人工干不了。