带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(二)

简介: 《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(二)

3.1.2     快照与克隆

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

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

 

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

 

1)用于保护数据

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

该功能一般推荐在软件升级或者机房设备替换等高危操作之前执行,一般选择在夜间或者其他生产业务负载较低的时段。高危操作之前先对逻辑卷数据进行快照操作,若高危   风险的操作变更失败,则将逻辑卷进行快照回滚操作,将数据恢复至高危操作之前的状态。Ceph 块存储提供的快照服务为崩溃一致性而非应用一致性,即Ceph 的快照操作不会静默数据库等应用系统,不会备份内存数据,不保证应用系统层面的数据一致性,而仅针   对已落盘数据生效。在快照创建操作进行时,虚机内存中缓存的脏数据(新写入的数据)   因其未最终落盘,不会包含在快照的保护范围之内。

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

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

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

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

 

当前快照/克隆有两种实现方式,分别是COWCopyonWriteROWRedirecton 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 个物理块空间内的数据。

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

image.png


3-5Cow快照示意

 

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

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

(2)  ROW快照 /克隆原理

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

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

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

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

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


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


image.png

3-6Row快照示意

 

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

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

 

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

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

 

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

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

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

相关实践学习
块存储快速入门
块存储是阿里云为云服务器ECS提供的块设备产品。通过体验挂载数据盘、分区格式化数据盘(Linux)、创建云盘快照、重新初始化数据盘、使用快照回滚云盘和卸载数据盘等功能,带您快速入门块存储。
相关文章
|
存储 容灾 安全
带你读《存储漫谈: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 块设备映射
|
存储 缓存 算法
带你读《存储漫谈:Ceph原理与实践》——3.1.2 快照与克隆
带你读《存储漫谈:Ceph原理与实践》——3.1.2 快照与克隆
|
存储 算法 网络性能优化
带你读《存储漫谈:Ceph原理与实践》——3.1.5 QoS
带你读《存储漫谈:Ceph原理与实践》——3.1.5 QoS
|
3月前
|
存储 测试技术
阿里云块存储问题之测试不聚焦可能导致测试不稳定如何解决
阿里云块存储问题之测试不聚焦可能导致测试不稳定如何解决
38 3
|
4月前
|
存储 固态存储 大数据
阿里云服务器实例、块存储、带宽收费标准与云服务器最新活动价格参考
阿里云服务器价格通常包括云服务器实例价格、块存储价格和带宽价格组成,云服务器不同实例规格收费标准不一样,选择不同类型的块存储收费标准也不一样,选择不同的带宽收费标准也不一样。现在阿里云轻量应用服务器2核4G4M峰值带宽298元1年,云服务器2核4G5M固定带宽199元1年、2核8G1M固定带宽652.32元1年、4核8G1M固定带宽955.58元1年、4核16G10M带宽100G ESSD Entry云盘70元1个月。本文为大家整理了目前阿里云服务器实例、块存储、带宽收费标准与云服务器最新的活动价格情况,以供参考。
阿里云服务器实例、块存储、带宽收费标准与云服务器最新活动价格参考
|
3月前
|
存储
阿里云块存储问题之高效的Code Review可以发现70-90%的bug如何解决
阿里云块存储问题之高效的Code Review可以发现70-90%的bug如何解决
37 1
|
3月前
|
存储 Linux 测试技术
阿里云块存储问题之在编码和提交代码时确保代码提交的原子性如何解决
阿里云块存储问题之在编码和提交代码时确保代码提交的原子性如何解决
41 0
|
3月前
|
存储 Cloud Native Linux
阿里云块存储问题之poison发布阻塞机制实现如何解决
阿里云块存储问题之poison发布阻塞机制实现如何解决
41 0

热门文章

最新文章