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

Soft/Hard Reboot

soft reboot 与 hard reboot 的区别在于:

1. soft reboot 只是重启操作系统,整个过程中,instance 依然处于运行状态。相当于在 linux 中执行 reboot 命令

2. hard reboot 是重启 instance,相当于关机之后再开机

soft/hard reboot 的日志分析留给大家作为练习。

提示:

1. soft/hard reboot 在 nova-api 的日志里找不到,这是因为 /opt/stack/nova/nova/compute/api.py 的 reboot 方法中没有输出 log。

可以通过关键字 “nova.api.openstack.wsgi” 或者 “reboot” 搜索。

2. 在 nova-compute 的日志中可以看到 “soft reboot” 和 “hard reboot” 二者有明显的区别。

Lock/Unlock

为了避免误操作,比如意外重启或删除 instance,可以将 instance 加锁。

对被加锁(Lock)的 instance 执行重启等改变状态的操作会提示操作不允许。

执行解锁(Unlock)操作后恢复正常。

Lock/Unlock 操作都是在 nova-api 中进行的。

操作成功后 nova-api 会更新 instance 加锁的状态。

执行其他操作时,nova-api 根据加锁状态来判断是否允许。

Lock/Unlock 不需要 nova-compute 的参与。

Lock/Unlock 的日志比较简单,留给大家练习。

提示:

1. admin 角色的用户不受 lock 的影响,及无论加锁与否都可以正常执行操作。

2. 根据默认 policy 的配置,任何用户都可以 unlock。也就是说如果发现 instance 被加锁了,可以通过 unlock 解锁,然后在执行操作。

时间: 2024-11-07 05:31:49

Nova reboot 和 lock 操作 - 每天5分钟玩转 OpenStack(32)的相关文章

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

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

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

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

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 请求 客

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

Restore Volume 操作 - 每天5分钟玩转 OpenStack(60)

前面我们 backup 了 voluem,今天我们将讨论如何 restore volume. restore 的过程其实很简单,两步走: 在存储节点上创建一个空白 volume. 将 backup 的数据 copy 到空白 voluem 上. 下面我们来看 restore 操作的详细流程: 向 cinder-api 发送 backup 请求 cinder-api 发送消息 cinder-scheduler 挑选最合适的 cinder-volume cinder-volume 创建空白 volum

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

本节我们讨论 volume 的 Backup 操作. Backup 是将 volume 备份到别的地方(备份设备),将来可以通过 restore 操作恢复. Backup VS Snapshot 初看 backup 功能好像与 snapshot 很相似,都可以保存 volume 的当前状态,以备以后恢复.但二者在用途和实现上还是有区别的,具体表现在: Snapshot 依赖于源 volume,不能独立存在:而 backup 不依赖源 volume,即便源 volume 不存在了,也可以 rest

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

Snapshot Volume 操作 - 每天5分钟玩转 OpenStack(58)

Snapshot 可以为 volume 创建快照,快照中保存了 volume 当前的状态,以后可以通过 snapshot 回溯.snapshot 操作实现比较简单,流程图如下: 向 cinder-api 发送 snapshot 请求 cinder-api 发送消息 cinder-volume 执行 snapshot 操作 下面我们详细讨论每一个步骤. 向 cinder-api 发送 snapshot 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发

每天5分钟 玩转OpenStack

最近在学习OpenStack的相关知识,一直苦于OpenStack的体系庞大以及复杂程度,学习没有进度,停滞不前.偶然机会在51CTO上发现了一个热点的专题关于OpenStack的,题目叫做<每天5分钟 玩转OpenStack>,抱着试试的态度看了几篇,被文章的内容和书写风格吸引了,内容全面,思路清晰,简单易懂,关键是每篇博文的内容很少,绝对是一泡大便的功夫.每周一.周三.周五定时更新,微信也有同步更新.不过大神在博客园cnblogs上的博文没有目录,每次翻阅的时候甚是费劲,可能是大神太忙了,