Backup Volume 操作 - 每天5分钟玩转 OpenStack(59)

本节我们讨论 volume 的 Backup 操作。

Backup 是将 volume 备份到别的地方(备份设备),将来可以通过 restore 操作恢复。

Backup VS Snapshot

初看 backup 功能好像与 snapshot 很相似,都可以保存 volume 的当前状态,以备以后恢复。但二者在用途和实现上还是有区别的,具体表现在:

  1. Snapshot 依赖于源 volume,不能独立存在;而 backup 不依赖源 volume,即便源 volume 不存在了,也可以 restore。
  2. Snapshot 与源 volume 通常存放在一起,都由同一个 volume provider 管理;而 backup 存放在独立的备份设备中,有自己的备份方案和实现,与 volume provider 没有关系。
  3. 上面两点决定了 backup 具有容灾功能;而 snapshot 则提供 volume provider 内便捷的回溯功能。
配置 cinder-backup

Cinder 的 backup 功能是由 cinder-backup 服务提供的,devstack 默认没有启用该服务,需要手工启用。与 cinder-volume 类似,cinder-backup 也通过 driver 架构支持多种备份 backend,包括 POSIX 文件系统、NFS、Ceph、GlusterFS、Swift 和 IBM TSM。支持的driver 源文件放在 /opt/stack/cinder/cinder/backup/drivers/

本节我们将以 NFS 为 backend 来研究 backup 操作。

在实验环境中,存放 volume backup 的 NFS 远程目录为 192.168.104.11:/backup cinder-backup 服务节点上 mount point 为 /backup_mount。

需要在 /etc/cinder/cinder.conf 中作相应配置。

然后手工启动 cinder-backup 服务。

/usr/bin/python /usr/local/bin/cinder-backup --config-file /etc/cinder/cinder.conf

一切准备就绪,下面我们来看 backup 操作的流程

  1. 向 cinder-api 发送 backup 请求
  2. cinder-api 发送消息
  3. cinder-backup 执行 backup 操作

下面我们详细讨论每一个步骤。

向 cinder-api 发送 backup 请求

客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发送请求:“请 backup 指定的 volume。

这里我们将 backup volume “vol-1”,目前 backup 只能在 CLI 中执行。

这里因为 vol-1 已经 attach 到 instance,需要使用 --force 选项。

cinder-api 接收到 backup volume 的请求。日志文件在 /opt/stack/logs/c-api.log。

cinder-api 发送消息

cinder-api 发送 backup 消息。cinder-api 没有打印发送消息的日志,只能通过源代码查看 /opt/stack/cinder/cinder/backup/api.py,方法为 create。

cinder-backup 执行 backup 操作

cinder-backup 收到消息后,通过如下步骤完成 backup 操作,日志为 /opt/stack/logs/c-vol.log。

  1. 启动 backup 操作,mount NFS。
  2. 创建 volume 的临时快照。
  3. 创建存放 backup 的 container 目录。
  4. 对临时快照数据进行压缩,并保存到 container 目录。
  5. 创建并保存 sha256(加密)文件和 metadata 文件。
  6. 删除临时快照。

Backup 完成后,我们可以查看一下 container 目录的内容

里面有三个文件,根据前面的日志我们可以知道:

  1. backup-00001,压缩后的 backup 文件。
  2. backup_metadata,metadata 文件。
  3. backup_sha256file,加密文件。

可以通过 cinder backup-list 查看当前存在的 backup。

另外我们可以查看一下 cinder backup-create 的用法。

这里有 --incremental 选项,表示可以执行增量备份。
如果之前做过普通(全量)备份,之后可以通过增量备份大大减少需要备份的数据量,是个很不错的功能。增量备份的操作和日志分析留给大家做练习。

以上就是 volume backup 的分析,下一节我们讨论如何通过 restore 操作恢复备份的 volume。

  

时间: 2024-07-30 13:17:47

Backup Volume 操作 - 每天5分钟玩转 OpenStack(59)的相关文章

Detach Volume 操作 - 每天5分钟玩转 OpenStack(55)

上一节我们成功地通过 attach 操作为 instance 添加了 volume,而与之相对的操作是 detach,就是将 volume 从 instance 上卸载下来. 下图是 Detach 操作的流程图 向 cinder-api 发送 detach 请求 cinder-api 发送消息 nova-compute detach volume cinder-volume 删除 target 下面我们详细讨论每一个步骤. 向 cinder-api 发送 attach 请求 客户(可以是 Ope

Extend Volume 操作 - 每天5分钟玩转 OpenStack(56)

前面我们讨论了 volume 的 attach 和 detach 操作,今天讨论如何扩大 volume 的容量.为了保护现有数据,cinder 不允许缩小 volume. Extend 操作用于扩大 Volume 的容量,状态为 Available 的 volume 才能够被 extend.如果 volume 当前已经 attach 给 instance,需要先 detach 后才能 extend. Extend 实现比较简单,流程图如下: 向 cinder-api 发送 extend 请求 c

Delete Volume 操作 - 每天5分钟玩转 OpenStack(57)

今天讨论 cinder 如何删除 volume . 状态为 Available 的 volume 才能够被 delete.如果 volume 当前已经 attach 到 instance,需要先 detach 后才能 delete. Delete操作实现比较简单,流程图如下: 向 cinder-api 发送 delete 请求 cinder-api 发送消息 cinder-volume 执行 delete 操作 下面我们详细讨论每一个步骤. 向 cinder-api 发送 delete 请求 客

准备 LVM Volume Provider - 每天5分钟玩转 OpenStack(49)

Cinder 真正负责 Volume 管理的组件是 volume provider. Cinder 支持多种 volume provider,LVM 是默认的 volume provider.Devstack 安装之后,/etc/cinder/cinder 已经配置好了 LVM,如下图所示: 上面的配置定义了名为"lvmdriver-1"的 volume provider,也称作 back-end.其 driver 是 LVM,LVM 的 volume group 名为"st

Nova reboot 和 lock 操作 - 每天5分钟玩转 OpenStack(32)

前面 CloudMan 通过日志详细分析了 nova 的 launch, shut off 和 start 操作.不知道大家现在是否已经掌握了日志分析的技能? 今天咱们就来检验一下.本节讨论的是 nova 相对较简单的操作: reboot 和 lock/unlock.我首先会讲解这几个操作的理论知识,然后将日志分析留给大家来完成.大家在分析过程中如有任何疑问,可以给我留言. Soft/Hard Reboot soft reboot 与 hard reboot 的区别在于: 1. soft reb

Live Migrate 操作 - 每天5分钟玩转 OpenStack(42)

Migrate 操作会先将 instance 停掉,也就是所谓的"冷迁移".而 Live Migrate 是"热迁移",也叫"在线迁移",instance不会停机. Live Migrate 分两种: 源和目标节点没有共享存储,instance 在迁移的时候需要将其镜像文件从源节点传到目标节点,这叫做 Block Migration(块迁移) 源和目标节点共享存储,instance 的镜像文件不需要迁移,只需要将 instance 的状态迁移到目

1 张图秒懂 Nova 16 种操作 - 每天5分钟玩转 OpenStack(44)

前面我们讨论了 Instance 的若干操作,有的操作功能比较类似,也有各自的适用场景,现在是时候系统地总结一下了. 如上图所示,我们把对 Instance 的管理按运维工作的场景分为两类:常规操作和故障处理. 常规操作 常规操作中,Launch.Start.Reboot.Shut Off 和 Terminate 都很好理解. 下面几个操作重点回顾一下: Resize通过应用不同的 flavor 调整分配给 instance 的资源. Lock/Unlock可以防止对 instance 的误操作

写在最前面 - 每天5分钟玩转 OpenStack(1)

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack.   为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所

Create Volume 操作(Part I) - 每天5分钟玩转 OpenStack(50)

前面已经学习了 Cinder 的架构和相关组件,从本节我们开始详细分析 Cinder 的各种操作,首先讨论 Cinder 如何创建 volume. Create 操作流程如下: 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(cinder-api)发送请求:"帮我创建一个 volume". API 对请求做一些必要处理后,向 Messaging(RabbitMQ)发送了一条消息:"让 Scheduler 创建一个 volume". Sche