本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode

内省实例监控¶

https://blueprints.launchpad.net/masakari/+spec/introspective-instance-monitoring

目前，Masakari 实例监控严格来说是通过 qemu 和 libvirt 进行的非侵入式黑盒监控。然而，存在许多内部实例/VM 故障（内核调度和 IO、应用程序健康状况），如果被 Masakari 检测到，可以通过现有的 Masakari 自动恢复机制进行恢复；从而提高实例/VM 的整体可用性。此蓝图引入了执行 VM 内省实例监控的能力，以便检测、报告并可选地从内部 VM 故障中恢复 VM。具体来说，本规范引入了通过 QEMU Guest Agent 进行 VM 心跳监控，以便间接检测其中一些内部 VM 故障。

问题描述¶

目前，Masakari 实例监控是通过 qemu 和 libvirt 进行的严格的非侵入式黑盒监控。这可以检测到一些可以通过 Masakari 的自动恢复机制来恢复实例/VM 的故障。

然而，这种黑盒监控无法检测到许多内部实例/VM 故障，如果被 Masakari 检测到，也可以通过这些相同的 Masakari 自动恢复机制进行恢复。这包括故障，例如挂起的 Guest OS、Guest OS 无法调度应用程序进程、Guest 内的基本 IO 路由失败、特定于应用程序的进程失败或数据损坏等。本蓝图提出的监控范围的具体内容在“Proposed change”（提议变更）部分的末尾进行了描述。

监控内部实例/VM 故障需要 Guest VM 支持软件来响应此监控。在以下提案中，Guest VM 必须支持 QEMU Guest Agent。由于并非所有 VM 都将支持此软件，因此 OpenStack Host 对内部实例/VM 故障的监控必须针对每个 VM 或 VM 镜像可选地启用。

提议的变更¶

此蓝图引入了内省实例监控；具体来说，通过 QEMU Guest Agent 进行 VM 心跳监控。任何 VM 心跳故障都将通过 Masakari instance-alerter 报告给注册的 API 驱动程序（例如 masakari-api）。

内省实例监控的高级架构如下所示

+--------------------+   instance  +-------------+    + - - - - - - +
| instance-alerter   |<------------|  Masakari   |    |             |
|- - - - - - - - - - |   fault     |     VM      |      F U T U R E
| driver abstraction |             |  Heartbeat  |    |             |
|       layer        |             |    Agent    |
+--------------------+             +-------------+    + - - - - - - +
           |    |                         ^                  ^
  other <--+    |                         |                  |
  apis          |                         | +----------------+
                v                         | |
+--------------------+                    | |
|    masakari-api    |                    v v
+--------------------+             +-------------+
         |                         |  Libvirtd   |
         v                         +-------------+
+--------------------+                    ^
|   masakari-engine  |                    | unix socket
+--------------------+                    v
         |                         +-------------+
         | (recovery)              |    QEMU     |
         v                         +-------------+
+--------------------+                    ^
|                    |                    |
|      OpenStack     |       +--------------------------------------+
|                    |       | VM         | virtio serial device    |
+--------------------+       |            v                         |
                             |       +--------------------+         |
                             |       |   QEMU             |         |
                             |       |   Guest Agent      |         |
                             |       |   ( guest-ping{} ) |         |
                             |       +--------------------+         |
                             |                                      |
                             |         +-------------+              |
                             |       +-------------+ |              |
                             |       |             | |              |
                             |       | Application | |              |
                             |       |             | +              |
                             |       +-------------+                |
                             +--------------------------------------+

VM 心跳和健康检查监控将利用 QEMU 功能 Guest Agent [1]，用于 OpenStack Host 和 Guest VM 之间的传输层通信，以及内置的 guest ping 命令 (guest-ping{})。作为 QEMU 的一部分构建的 QEMU Guest Agent 守护程序安装并运行在 Guest 内部，并实现对发送到 guest 的 QMP 命令的支持。具体来说，QEMU Guest Agent 守护程序连接到 virtio-serial 设备 (/dev/virtio-ports/org.qemu.guest_agent.0)，将输入馈送到 QMP JSON 解析器，并在收到命令时调用生成的 QAPI 分派例程。在 VM 心跳监控的情况下，QEMU Guest Agent 命令“guest-ping”将用作 Host 的心跳挑战请求。

在主机上，OpenStack Nova 已经支持一个镜像属性 hw_qemu_guest_agent，可用于指定 VM 应该使用 QEMU guest agent virto-serial-interface 创建。Masakari VM 心跳 Agent 将通过监控代表 QEMU Guest Agent 虚拟串行接口的套接字标识符的文件来发现启用 hw_qemu_guest_agent 的 VM。

libvirt-qemu 提供了一个 virDomainQemuAgentCommand()，用于向选定的 VM 的 QEMU guest agent 发送命令。此命令打开 unix 套接字到 VM 的 virtio-serial-interface，发送命令，等待接收响应并关闭套接字。如果 unix 套接字被另一个进程打开，即另一个进程正在向同一 VM 发送命令，则命令将失败。

Masakari VM 心跳 Agent 将利用 libvirtd 提供的 virDomainQemuAgentCommand() 来发送心跳挑战请求（即 QEMU Guest Agent 的 guest-ping 命令）到 VM(s)，并将检测到的任何故障报告给 masakari instance-alerter。

主机上的 Masakari VM 心跳 Agent 将在发现 VM 启用 QEMU Guest Agent 通信后立即启动 VM 心跳。但是，为了处理 VM/Guest 的任意启动时间，这可能会延迟 Guest 响应心跳挑战的能力，Masakari VM 心跳 Agent 在从 VM/Guest 收到第一个成功的心跳响应之前，不会启用心跳故障报告。

此功能将在 masakari.conf 中支持一个标志，用于整体启用/禁用内省实例监控。它还将支持用于配置默认心跳周期和默认连续心跳丢失阈值（在声明故障之前）的参数；将来，flavor extraspecs 可以用于 VM 以指定这些值的特定值。

从高级别来看，此心跳监控的范围是 QEMU Guest Agent 在 VM 内部运行。然而，仅仅是心跳消息可以从 Host 到 VM 内部的 QEMU Guest Agent 之间来回传输，本身就验证了许多基本的 Guest Kernel 功能正在工作；例如，Guest OS 没有挂起或失败，QEMU 心跳消息通过基本的 linux socket IO 正确路由等。将来，心跳可以扩展到不仅仅是回复/确认消息……例如，可以对 VM 内部的关键应用程序进行基本的健全性/健康测试。

备选方案¶

可以简单地利用 QEMU/KVM 的虚拟硬件看门狗 [2] 进行实例监控。

然而，VM 心跳监控

通过 instance-alerter 将心跳状态的通知提供给更高级别的云实体，例如 Masakari、Mistral 和/或 Vitrage，
- 这取决于后端，可以导致 VM 自动恢复（Masakari）或 Nova 中 VM 的推导状态更新，并导致 Aodh 事件生成（Vitrage）。
将来可以扩展到提供更高层次的（例如，应用程序级别的）心跳
- 例如，如果 VM 内部运行的应用程序正在回答心跳请求
将来可以扩展到提供不仅仅是心跳，因为应用程序可以使用它来触发各种审计，
将来可以扩展到提供一种机制，用于 VM 内部的应用程序将健康状态/信息报告回 Host / 云。

限制¶

只有支持 QEMU Guest Agent 的 VM 才能通过此提案的功能进行监控。

实现¶

负责人¶

主要负责人: greg-waines

里程碑¶

完成目标里程碑: Rocky-2

工作项¶

计算节点上的 Masakari VM 心跳 Agent
- 发现启用 QEMU Guest Agent 通信的 VM，
- 心跳/健康检查监控的高级逻辑，
- 将故障报告给 masakari instance-alerter。
tox 和/或 tempest 测试套件更新
masakari 文档更新

依赖项¶

需要 VM 安装并运行 QEMU Guest Agent [1]，该 Agent 作为 QEMU 的一部分构建。

参考资料¶

[1] http://wiki.qemu.org/Features/GuestAgent

[2] https://libvirt.org/formatdomain.html#elementsWatchdog

内省实例监控