带你读《存储漫谈:Ceph原理与实践》——3.1.2 快照与克隆

简介: 带你读《存储漫谈:Ceph原理与实践》——3.1.2 快照与克隆

3.1.2  快照与克隆


块存储设备的快照与克隆都是指定数据集合在某一时刻的一个完全可用的数据拷贝,快照具有只读属性,克隆具有读写属性,也有人将克隆称为可写快照。Ceph RBD 设备的快照和克隆操作存在相关性,即克隆操作一定要基于某一已创建的快照进行。


1. 快照与克隆的使用场景

快照和克隆的使用场景可总结为以下两类。

(1)用于保护数据

存储快照是一种数据保护措施,可以对逻辑卷数据进行一定程度的保护。比如因为某种原因(如误操作等)导致了逻辑卷数据损坏,可以通过对该逻辑卷之前某时刻创建的快照进行回滚(rollback)操作,将数据恢复至快照创建时的状态,这样可以尽量降低数据损坏带来的影响,损失的数据仅为快照创建后更改的数据。

该功能一般推荐在软件升级或者机房设备替换等高危操作之前执行,一般选择在夜间或者其他生产业务负载较低的时段。高危操作之前先对逻辑卷数据进行快照操作,若高危风险的操作变更失败,则将逻辑卷进行快照回滚操作,将数据恢复至高危操作之前的状态。

Ceph 块存储提供的快照服务为崩溃一致性而非应用一致性,即 Ceph 的快照操作不会静默数据库等应用系统,不会备份内存数据,不保证应用系统层面的数据一致性,而仅针对已落盘数据生效。在快照创建操作进行时,虚机内存中缓存的脏数据(新写入的数据)因其未最终落盘,不会包含在快照的保护范围之内。

(2)快照卷作为源数据,提供给上层业务使用

应用于对数据只读场景,如数据挖掘、开发测试的部分场景。该场景下,先对逻辑卷进行快照创建,将创建好的快照卷提供给上层业务使用,快照卷的只读特性不仅可满足上层业务的访问需求,也可以有效防止误操作对原逻辑卷数据的更改。

对于 OpenStack 的虚机发放场景,也可以使用该方法。对于存储虚机系统盘镜像的逻辑卷,在 Ceph 存储集群中为其创建快照,当后续 OpenStack 接收到同样规格镜像的虚机创建请求时,就可以直接基于快照卷进行克隆操作,作为新虚机的系统卷使用,而不必为每台虚机都向 glance 服务拉取镜像。Ceph 块存储的克隆操作速度远远高于从 glance 服务拉取镜像的速度,可以大幅度提升虚机发送的速度。


2. 快照和克隆的实现方式

当前快照 / 克隆有两种实现方式,分别是 COW(Copy on Write)和 ROW(Redirect on Write)。

(1)COW 快照 / 克隆原理

假设有一个卷包含 6 个数据切片,编号分别为 1~6,在某一时刻对该卷进行快照操作生成新的快照卷,快照卷也有 6 个数据块,且和源卷一样指向相同的数据块物理空间。

生成快照后,有新的 I/O 要写入源卷(假设 I/O 落在源卷的第 6 个数据块上),这时会修改源卷的第 6 个物理块空间,对于 COW 而言,其修改步骤会进行如下几个操作。

1)首先会分配一个新的物理块,将其编号为 7 ;

2)读出第 6 个物理块中记录的数据;

3)将读出的第 6 个物理块数据写入到新分配的第 7 个物理块空间内;

4)更新快照卷 map 信息,指向第 7 个物理块空间;

5)更新源卷的第 6 个物理块空间内的数据。

该流程之后的效果为源卷维持原状,数据仍存储在物理块 1、2、3、4、5、6 之中,快照卷数据存储位置则发生了变化,数据存储在物理块 1、2、3、4、5、7 之中,如图 3-5 所示。

image.png

图 3-5 COW 快照示意

对源卷而言,存储数据的物理块不发生变化,数据在物理块中原地修改。该特性在传统的 SAN 存储设备中优势较为突出,因为在 SAN 设备中,LUN 的存储空间通常在物理上也连续,COW 过程对于源卷而言不产生新的碎片,快照之后源卷存储空间仍连续,不影响源卷的顺序读写效率(机械盘的“电梯”调度算法可以很好地处理连续地址空间的读写操作);但该特性在 Ceph 这样一个基于 Object 分片存储的分布式存储系统中,效果十分有限,因为原本逻辑卷的地址空间就是离散的,即使快照后产生新的物理块地址,对于逻辑卷的读写效率影响也不大。

COW 机制会造成写放大,一个 I/O 写入操作,变成了 1 读 2 写。该特性在同一个源卷创建多个快照之后,对于 I/O 性能的劣化效果更为明显,因为在为快照向新的物理空间复制出一份数据之后,还要为所有已创建的快照修改数据块的地址指针,快照越多,需要修改的指针就越多。

(2)ROW 快照 / 克隆原理

同样,对于上述场景,假设有一个卷包含 6 个数据切片,编号分别为 1~6,在某一时刻对该卷进行快照操作生成新的快照卷,快照卷也有 6 个数据块,且和源卷一样指向相同的数据块物理空间。

生成快照后,有新的 I/O 要写入源卷(假设 I/O 落在源卷的第 6 个数据块上),这时会修改源卷的第 6 个物理块空间,对于 ROW 而言,其修改步骤包括如下几个操作。

1)首先会分配一块新的物理块,将其编号为 7 ;

2)将新的 I/O 数据写入新分配的第 7 个物理块中;

3)更新源卷 map,指向第 7 个物理块空间。

该流程之后的效果为源卷数据写入位置发生变化,存储在物理块 1、2、3、4、5、7 之中,快照卷数据存储维持原状,数据存储在物理块 1、2、3、4、5、6 之中,如图 3-6 所示。

image.png

图 3-6 ROW 快照示意

ROW 机制没有写放大,写性能比 COW 要好。对快照卷而言,不需要修改存储数据的物理块位置,即 ROW 的性能与源卷已创建的快照数量无关。

ROW 机制下,源卷数据存储物理空间发生变化,但同前文分析,对于传统 SAN 存储系统,该特性会劣化源卷的顺序读写性能,但对于分布式存储系统,源卷的数据寻址性能不会受到任何影响。

通过上述介绍可知,COW 与 ROW 两种快照 / 克隆机制各有优劣势,有自身适用的场景,ROW 机制更适合分布式存储场景,但遗憾的是 Ceph 分布式存储系统采用的是 COW 快照 / 克隆机制,目前业界已有部分基于 Ceph 定制的存储系统将快照 / 克隆机制从 COW 改为 ROW。

3. Ceph RBD 设备的快照和克隆

RBD 快照是 RBD 设备在某个特性时间点全部数据的只读镜像,一个 RBD 设备支持创建多个快照。目前 RBD 层面已具备一致性快照组的功能,可将相关的若干个 RBD 设备(如同一个虚机的系统盘和数据盘)组成一个组(Group),然后直接对该一致性组统一进行快照操作。Ceph 的一致性快照组功能提供的也是崩溃一致性,仅对已落盘数据生效,不保证应用系统层面的数据一致性。

RBD 克隆基于 RBD 快照功能实现,基于 RBD 的某个快照执行克隆操作,即可得到一个新的克隆卷,用户不感知其所使用的卷是否为克隆卷,用户可以像操作一般的 RBD 设备一样,使用克隆卷。

Ceph 的 RBD 快照和克隆均采用了 COW 机制,在对 RBD 进行创建快照和克隆操作时,此过程不会涉及数据复制,故这些操作可瞬时完成。需要说明的是,当一个 RBD 上有较多层级的克隆卷时,对克隆卷进行读写时,可能会涉及较多层级的递归查询操作,会对克隆卷的性能产生不小的影响,故当克隆层级过多时,可解除克隆卷与源卷(或上层快照)之间的依赖关系,这样在对克隆卷进行读写访问时便不再涉及 COW 和多级递归查询操作。

相关文章
|
3月前
|
存储 安全 API
OpenStack的块存储卷管理快照 (Snapshot)
【8月更文挑战第26天】
112 13
|
3月前
|
存储 数据管理 API
OpenStack的块存储卷管理快照与克隆
【8月更文挑战第27天】
52 4
|
3月前
|
存储 API 块存储
OpenStack的块存储卷快照
【8月更文挑战第25天】
54 4
|
块存储
阿里云最新产品手册——阿里云核心产品——块存储——自动创建快照
阿里云最新产品手册——阿里云核心产品——块存储——自动创建快照自制脑图
99 1
|
块存储
阿里云最新产品手册——阿里云核心产品——块存储——快照创建注意事项
阿里云最新产品手册——阿里云核心产品——块存储——快照创建注意事项自制脑图
111 1
|
块存储
阿里云最新产品手册——阿里云核心产品——块存储——快照分类
阿里云最新产品手册——阿里云核心产品——块存储——快照分类自制脑图
92 1
|
块存储
阿里云最新产品手册——阿里云核心产品——块存储——快照使用
阿里云最新产品手册——阿里云核心产品——块存储——快照使用自制脑图
95 1
|
存储 容灾 安全
带你读《存储漫谈:Ceph原理与实践》——3.1.3 远程复制
带你读《存储漫谈:Ceph原理与实践》——3.1.3 远程复制
带你读《存储漫谈:Ceph原理与实践》——3.1.3 远程复制
|
存储 缓存 Linux
带你读《存储漫谈:Ceph原理与实践》——3.1.4 RBD Cache
带你读《存储漫谈:Ceph原理与实践》——3.1.4 RBD Cache
带你读《存储漫谈:Ceph原理与实践》——3.1.4 RBD Cache
|
存储 Linux 虚拟化
带你读《存储漫谈:Ceph原理与实践》——3.1.1 块设备映射
带你读《存储漫谈:Ceph原理与实践》——3.1.1 块设备映射