看懂Openstack日志

日志位置

• 日志会统一放在/var/log/目录下，每个服务都有自己的日志，可以通过名字来区分。
  

  日志格式

  OpenStack 的日志格式都是统一的，如下：

ID  日志会记录连续不同的操作，为了便于区分和增加可读性，每个操作都被分配唯一的Request
ID,便于查找 |
| 日志内容 | 这是日志的主体，记录当前正在执行的操作和结果等重要信息 |
| 源代码位置 | 日志代码的位置，包括方法名称，源代码文件的目录位置和行号。这一项不是所有日志都有 |

例子：查看nova-api日志(部分)

 cat /var/log/nova/nova-api.log

2020-05-21 13:18:53.033 1994 INFO nova.osapi_compute.wsgi.server [req-5af02b2c-f7dd-472c-b153-ab80dd0dc0ca - - - - -] (1994) wsgi starting up on http://0.0.0.0:8774
2020-05-21 13:18:53.543 1998 INFO nova.metadata.wsgi.server [req-64f39253-5e90-41ba-b83a-ae8264f6d718 - - - - -] (1998) wsgi starting up on http://0.0.0.0:8775
2020-05-21 13:18:53.588 1995 INFO nova.osapi_compute.wsgi.server [req-c4bb5d0b-4ba1-4957-a039-e749d161888a - - - - -] (1995) wsgi starting up on http://0.0.0.0:8774
2020-05-21 13:18:53.732 1999 INFO nova.metadata.wsgi.server [req-9ca7b32e-7f92-4286-b50c-93c2b552ea85 - - - - -] (1999) wsgi starting up on http://0.0.0.0:8775

关于日志的几点说明

• 如果你是Openstack最终用户，不需要看日志，找运维人员
• 如果你是Openstack运维人员，必须要看日志，并且先掌握Openstack的运行机制，了解每个服务的子服务之间如何协同工作，这样才能通过日志定位问题，针对性地解决问题。
• 如果你是Openstack开发人员，我们必须能看懂源码，当开发过程中出现问题的时候，可以查询日志，定位报错源码位置来解决问题。

Launch/Shut off/Start/Soft or Hard Reboot

Launch

Launch就是创建虚拟机的操作
流程：

• ①Nova-api接收用户请求（创建VM）
• ②API对请求进行一些授权等操作后，发送请求消息给Messaging（RabbitSMq）
• ③Messaging将获取的API消息发送给nova-scheduler
• ④Nova-scheduler接收到API消息后，执行调度选出合适的计算节点A
• ⑤Scheduler发送消息给Messaging（创建VM）
• ⑥计算节点A的nova-compute接收到从Messaging的scheduler消息后，通过Hypervisor Driver 创建 Instance。
• ⑦在Instance创建的过程中，Compute如果需要查询或更新数据库信息，会通过Messaging向nova-condutor发送消息和数据库进行交互。

Shut off

关闭虚拟机

流程：（不需要scheduler参加）

• ①向nova-api发送请求
• ②Nova-api发送消息
• ③Nova-compute执行操作，并且将信息同步给数据库，同步数据库这个操作是由nova-conductor去操作的

如何在日志中快速找到有用的信息：

• ①先确定大范围，在操作之前用tail –f打印日志文件
• ②利用“代码模块”快速定位有用信息

Start

启动虚拟机

流程：（不需要scheduler参加）

• 向nova-api发送请求
• Nova-api发送消息

• Nova-compute执行操作

  • a.开始启动
  • b.准备虚拟网卡
  • c.准备instance的XML文件
  • d.准备instance镜像文件
  • e.成功启动

Soft/Hard Reboot

重启操作，分为软重启硬重启

• soft
  reboot 与 hard reboot 的区别在于：

  • soft reboot 只是重启操作系统，整个过程中，instance 依然处于运行状态。相当于在 linux 中执行 reboot 命令。
  • hard reboot 是重启 instance，相当于我们电脑上关闭虚拟机之后再开机

Lock/Unlock

• 为了避免误操作，比如意外重启或删除
  instance，可以将 instance  加锁。
• 对被加锁（Lock）的 instance 执行重启等改变状态的操作会提示操作不允许（admin角色的用户不受lock的影响）。
• 执行解锁（Unlock）操作后恢复正常。
• Lock/Unlock
  操作都是在
  nova-api
  中进行的。
• 操作成功后
  nova-api
  会更新 instance 加锁的状态。
• 执行其他操作时，nova-api 根据加锁状态来判断是否允许。

Terminate

这个词虽然有停止的意思，不是暂停的意思，而是删除。

• 删除Instance流程：

  • 向nova-api发送请求
  • Nova-api发送消息

  • Nova-compute执行操作

    • ①关闭instance
    • ②删除instance的镜像文件
    • ③释放虚拟网络的其他资源

Pause/Resume

• 短时间暂停Instance（将Instance状体保存到宿主机内存中）

• 恢复Instance（从内存中读回Instance状态）

  • ①向nova-api发送请求
  • ②Nova-api发送消息
  • ③Nova-compute执行操作

Suspend/Resume

• 长时间暂定Instance（将Instance状态保存到宿主机的硬盘当中）

• 长暂定和短暂停恢复Instance的区别（从磁盘中读回Instance状态）

  • 相同点：两者都是暂停Instance的运行，并保存当前状态，之后通过Resume恢复
    

  • 不同点：

    • ①Suspend将Instance状态保存到磁盘上（恢复慢）；Pause是保存在内存中（恢复快）
    • ②Suspend之后的Instance，其状态是ShutDown；而被Pause的Instance的状态是Pause。也就是说这个时候假如关机，Pause当前状态是恢复不了的，因为都保存在内存中，而suspend则是保存在硬件上，当前状态都能恢复。
    • ③虽然都是通过Resume恢复，Pause对应的Resume在Openstack内部称为“Unpause”；而Suspend对应的Resume才是真正称为“Resume”

故障恢复

• 我们将讨论几种 instance 故障恢复的方法，不同方法适用于不同的场景。

  • 系统故障
  • 操作系统损坏很严重，只能够备份恢复
  • 冷迁移和热迁移
  • 宿主机Down
  • ……

  Rescue/Unrescue

• 有时候由于误操作或者突然断电，操作系统重启后却起不来了。
• 为了最大限度挽救数据，我们通常会使用一张系统盘将系统引导起来，然后在尝试恢复。
• 问题如果不太严重，完全可以通过这种方式让系统重新正常工作。
• 比如某个系统文件意外删除， root 密码遗忘等
• Nova 也提供了这种故障恢复机制，叫做 Rescue。

• Rescue 用指定的 image 作为启动盘引导 instance，将 instance 本身的系统盘作为第二个磁盘挂载到操作系统上。
  

  补充

  持续化存储

  我们在创建虚拟机的时候，不要将系统盘当作数据盘使用，一旦系统盘出现问题的时候数据也就得不到恢复了，一般我们会专门挂一个运行盘去存放用户的数据，系统盘和数据盘是区分开的，数据盘一般由后端的cinder服务提供的，你可以定期的对数据盘做备份，这样当虚拟机出现故障时，不需要担心数据会丢失，我们只需要重新挂载一个系统盘，那么我们的虚拟机其实也就恢复了。
  

  快照

  对我们当前的instance去拍摄快照，保存当前的状态，这样也能保存恢复数据。

流程

• ①向nova-api发送请求
• ②Nova-api发送消息

• ③Nova-compute执行操作

  • a)关闭Instance
  • b)通过image创建新的引导盘，命令为disk.rescue
  • c)启动instance
• Rescue 操作让我们有机会修复损坏的操作系统。 修好之后，使用 Unrescue 操作从原启动盘重新引导 instance。

Snapshot

• Nova 备份的操作叫 Snapshot，其工作原理是对 instance 的镜像文件（系统盘）进行全量备份，生成一个类型为 snapshot 的 image，然后将其保存到 Glance 上，流程：

  • ①向nova-api发送请求
  • ②Nova-api发送消息

  • ③Nova-compute执行操作

    • a)暂停Instance
    • b)对instance的镜像文件做快照
    • c)恢复instance
    • d)将快照上传到Glance
    • e)Snapshot成功保存到Glance中

  举例

  如果已经创建好了一个虚拟机，已经分配好了网络资源和存储资源，但是突然想更换操作系统，此时我们不需要完全的创建，可以进行rebuild重建，重建时只需要更改镜像资源，其他资源就不需要进行配置了，就比如在公有云上更换操作系统，是不会更改网络和存储配置的。

Rebuild

• 如果 instance 损坏了，可以通过 snapshot 恢复，这个恢复的操作就是 Rebuild。

• Rebuild 会用 snapshot 替换 instance 当前的镜像文件，同时保持 instance 的其他诸如网络，资源分配属性不变。流程：

  • ①向nova-api发送请求
  • ②Nova-api发送消息

  • ③Nova-compute执行操作

    • a)关闭Instance
    • b)下载新的image，并准备instance的镜像文件
    • c)启动instance
    • d)Rebuild之后，GUI会显示instance的新image

Shelve

• Instance 被 Suspend 后虽然处于 Shut Down 状态，但 Hypervisor 依然在宿主机上为其预留了资源，以便在以后能够成功 Resume。

• 如果希望释放这些预留资源，可以使用 Shelve 操作。 Shelve 会将 instance 作为 image 保存到 Glance 中，然后在宿主机上删除该 instance。流程：

  • ①向nova-api发送请求
  • ②Nova-api发送消息

  • ③Nova-compute执行操作

    • a)关闭Instance
    • b)对instance执行Snapshot操作
    • c)生成image保存到Glance上
    • d)删除Instance在宿主机上的资源

Unshelve

• 因为Glance中保存了 instance 的 image，unshelve的过程其实就是通过该 image launch一个新的 instance，nova-scheduler也会调度合适的计算节点来创建该 instance。

• instance unshelve 后可能运行在与shelve之前不同的计算节点上，但instance的其他属性（比如 flavor，IP 等）不会改变。流程：

  • ① 向 nova-api 发送请求
  • ② nova-api 发送消息
  • ③ nova-scheduler 执行调度
  • ④ nova-scheduler 发送消息

  • ⑤ nova-compute 执行操作

    • a)为 instance 准备 CPU、内存和磁盘资源
    • b)创建 instance 镜像文件
    • c)创建 instance 的 XML 定义文件
    • d)创建虚拟网络并启动 instance

Migrate

• Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上。
• Migrate 不要求源和目标节点必须共享存储，当然共享存储也是可以的。
• Migrate 前必须满足一个条件：计算节点间需要配置
  nova
  用户无密码访问。

• 流程：

  • ① 向 nova-api 发送请求（Migrate 操作是特权操作，只能在 Admin 的 instance 菜单中执行）
  • ② nova-api 发送消息（源码中方法是resize而非migrate）
  • ③ nova-scheduler 执行调度
  • ④ nova-scheduler 发送消息

  • ⑤ nova-compute 执行操作

    • a)开始migrate
    • b)在目标节点上创建instance目录（因为没有使用共享存储）
    • c)关闭instance
    • d)将instance的镜像文件通过scp传到目标节点上，目标节点进行launch操作
    • e)若Confirm后，对源计算节点删除instance的目录以及在Hypervisor上删除instance
    • f)若Revert，则目标计算节点关闭并删除instance目录，并在源计算节点上启动instance（这时会有确定/回文选择，点击确定按钮就会删除原文件在目的节点启动instance，回文则是删除目的节点的虚拟机启动源节点的instance,这种迁移是冷迁移的方式，需要关闭instance）

Resize

• Resize 的作用是调整 instance 的 vCPU、内存和磁盘资源。
• Instance 需要多少资源是定义在 flavor 中的，resize 操作是通过为 instance 选择新的 flavor 来调整资源的分配。
• 有了前面对 Migrate 的分析，再来看 Resize 的实现就非常简单了。 因为 instance 需要分配的资源发生了变化，在 resize 之前需要借助 nova-scheduler 重新为 instance 选择一个合适的计算节点，如果选择的节点与当前节点不是同一个，那么就需要做
  Migrate。
• 所以本质上讲：Resize 是在 Migrate 的同时应用新的 flavor。 Migrate 可以看做是 resize 的一个特例： flavor 没发生变化的 resize，这也是为什么我们在上一节日志中看到 migrate 实际上是在执行 resize 操作。

Resize 分两种情况：

• A.nova-scheduler 选择的目标节点与源节点是不同节点。操作过程Migrate 几乎完全一样，只是在目标节点启动 instance 的时候按新的 flavor 分配资源。

• B.目标节点与源节点是同一个节点，nova-compute 执行操作：

  • ①按照新的flavor准备CPU、RAM和Disk资源
  • ②关闭instance
  • ③创建instance镜像文件
  • ④将instance的目录备份一份，命名为<instance_id>_resize，以便revert
  • ⑤创建instance的XML定义文件
  • ⑥准备虚拟网络

  • ⑦启动instance

    • Confirm：删除计算节点上备份的instance目录<instance_id>_resize
    • Revert:关闭instance，通过备份目录进行恢复instance目录，并重新启动instance

Live Migrate

• Migrate
  操作会先将
  instance
  停掉，也就是所谓的“冷迁移”。而
  Live
  Migrate 是“热迁移”，也叫“在线迁移”，instance不会停机。

• Live
  Migrate
  分两种：

  • 源和目标节点没有共享存储，instance 在迁移的时候需要将其镜像文件从源节点传到目标节点，这叫做 Block Migration（块迁移）
  • 源和目标节点共享存储，instance 的镜像文件不需要迁移，只需要将 instance 的状态迁移到目标节点。

• 源和目标节点需要满足一些条件才能支持 Live Migration：

  • a)源和目标节点的 CPU 类型要一致。
  • b)源和目标节点的 Libvirt (底层虚拟化版本)版本要一致。
  • c)源和目标节点能相互识别对方的主机名称，比如可以在 /etc/hosts 中加入对方的条目。
  • d)在源和目标节点的 /etc/nova/nova.conf 中指明在线迁移时使用 TCP 协议。
  • e)Instance 使用 config driver 保存其 metadata。在 Block Migration 过程中，该 config driver 也需要迁移到目标节点。由于目前 libvirt 只支持迁移 vfat 类型的 config driver，所以必须在 /etc/nova/nova.conf 中明确指明 launch instance 时创建 vfat 类型的 config driver。

非共享存储 Block Migration

• ① 向 nova-api 发送请求
• ② nova-api 发送消息

• ③ nova-compute 执行操作

  • a)目标节点执行迁移前的准备工作，首先将 instance 的数据迁移过来，主要包括镜像文件、虚拟网络等资源
  • b)源节点启动迁移操作，暂停 instance（Pause）
  • c)在目标节点上 Resume instance
  • d)在源节点上执行迁移的后处理工作，删除 instance
  • e)在目标节点上执行迁移的后处理工作，创建 XML，在 Hypervisor 中定义 instance，使之下次能够正常启动。

共享存储 Block Migration

• 搭建NFS环境，Controller作为NFS服务端、Compute作为NFS客户端。
• 共享存储的迁移过程与 Block Migrate 基本上一样，只是几个环节有点区别：
• a)向 nova-api 提交请求的时候，不能勾选“Block Migrate”
• b)因为源和目标节点都能直接访问 instance 的镜像，所以目标节点在准备阶段不需要传输镜像文件，源节点在迁移后处理阶段也无需删除
  instance
  的目录。
• c)只有 instance 的状态需要从源节点传输到的目标节点，整个迁移速递比 Block Migration 快很多。

补充

• 目前都是用共享存储去做迁移（同一个集群不同节点的热迁移），将instance在源计算节点进行暂停操作（将当前instance状态保存到内存中），然后在目的节点进行恢复操作，此过程中不涉及instance镜像文件传输和instance文件删除，因为这些内容都在共享存储中，源目节点都能够访问。

• 还有一种情况,不同版本之前的迁移,一般来说冷迁移更好,就是底层块设备的迁移操作,V3平台上虚拟机迁移到V5平台上,其实就是通过底层块设备的迁移,然后进行恢复操作,块设备中存储的是用户数据，系统数据，可以通过选择相同的系统镜像进行启动，这种迁移并不是完全自动化的，需要将一些资源信息保持一致，比如说 镜像ID 网络资源（比如网卡名称，主机名等等） 都需要保持一致，然后在新的平台上重新启动。
  

  Evacuate

• Rebuild
  可以恢复损坏的
  instance。
• 那如果是宿主机坏了怎么办呢？
  比如硬件故障或者断电造成整台计算节点无法工作，该节点上运行的 instance
  如何恢复呢？
• 用
  Shelve
  或者 Migrate 可不可以？ 很不幸，这两个操作都要求 instance 所在计算节点的 nova-compute 服务正常运行。 幸运的是，还有 Evacuate 操作。
• Evacuate
  可在 nova-compute 无法工作的情况下将节点上的 instance 迁移到其他计算节点上。
• 但有个前提： Instance
  的镜像文件必须放在共享存储上。所以我们在架构云计算平台时需要规划好，镜像存储存贮在哪，共享存储存储哪些东西，后续需不需要进行持续升级操作，怎么扩容。

流程

• 1. 向 nova-api 发送请求

     • 通过断电模拟计算节点故障，然后执行 Evacuate 操作恢复 instance。

• 2.nova-api 发送消息

  • evacuate

  实际上是通过
  rebuild
  操作实现的。 因为 evacuate 是用共享存储上 instance 的镜像文件重新创建虚机 。

• 3. nova-scheduler 执行调度
• 4. nova-scheduler 发送消息

• 5. nova-compute 执行操作：用共享存储上的镜像文件重建Instance

     • ①为instance分配资源
     • ②使用共享存储上的镜像文件，启动Instance

Instance操作总结