Openstack实例高可用组件masakari介绍

一、Masakari服务介绍

云客户往往通过使用虚拟机来享受云服务，但是Openstack云系统可能会发生多种类型的故障事件，我们需要确保构建的云系统可以检测并恢复此类事件，虚拟机相关故障事件可能包括：

• 虚拟机崩溃

  如，使用kvm管理虚拟化时，qemu-kvm进程可能会崩溃

• nova-compute服务可能会意外中断或者无响应

• 虚拟化管理工具libvirt程序也可能中断或者无响应

• 计算节点所在的host主机可能会宕机等

我们需要设计方案来满足虚拟机高可用的需求，幸运的 OpenStack 子项目Masakari 帮助我们实现了这一目标，其旨在确保在主机上运行的实例和计算进程的高可用性。

Masakari目前主要提供三种类型的故障事件检测和恢复:

1. 虚拟机崩溃

   如进程挂了，Masakari检测到该错误类型，会通过三步完成虚拟机故障恢复：停止虚拟机、启动虚拟机、确认虚拟机状态为active

2. 计算节点服务进程崩溃

   计算节点通过运行masakari-processmonitor服务检测nova-compute、libvirt等服务，检测到服务异常，将直接重启对应服务，从而保障服务稳定运行

3. 计算节点所在host主机宕机

   通过pacemaker+corosync构建集群环境，检测计算节点主机状态，如果主机状态异常，则使用fence设备关闭该节点，并使用nova.evacuate接口，疏散故障主机上的所有实例到新的计算节点。

二、Masakari服务架构

Masakari服务主要由故障检测和故障恢复两部分组成，其中故障检测由masakari-monitors服务提供，部署在计算节点。 故障恢复则由masakari-api和masakari-engine服务提供，部署在控制节点。 具体如下:

• masakari-api: 运行在控制节点，提供api服务。通过远程过程调用 (RPC) 将 API 请求发送到 masakari-engine 来处理 API 请求，此外还提供了segment的创建、删除，查询等功能。
• masakari-engine: 运行在控制节点，通过以异步方式执行恢复工作流来处理收到的masakari-api发送的通知。
• masakari-instancemonitor : 运行在计算节点，属于masakari-monitor，检测虚拟机进程是否挂掉了。
• masakari-processmonitor: 运行在计算节点，属于masakari-monitor，检测计算服务Nova-compute是否挂了。
• masakari-hostmonitor : 运行在计算节点，属于masakari-monitor，检测计算节点主机是否挂了。
• masakari-introspectiveinstancemonitor：运行在计算节点，属于masakari-monitor，当虚拟机安装了qemu-ga，可用于检测以及启动回复故障进程或服务。
• pacemaker-remote：运行在计算节点，解决corosync/pacemaker的16个节点的限制。

除此之外，Masakari还提供了命令行工具python-masakariclient 模块，用于通过命令行执行 openstack segment管理命令， 以及masakari-dashboard页面展示模块。

这里的segment是高可用区域， 通过将计算节点添加进指定的segment形成高可用计算组，segment内的主机发生故障时，可将该主机上的虚拟机疏散到同segment内的其他可用主机上， 疏散的策略有:

• auto：Nova选择新的计算主机，用于疏散在失败的计算主机上运行的实例
• reserved_host：segment中配置的其中一个主机为保留主机，将用于疏散在失败的计算主机上运行的实例
• auto_priority：首先它会尝试auto恢复方法，如果它失败了，那么它会尝试使用reserved_host恢复方法。
• rh_priority：它与auto_priority恢复方法完全相反，先尝试reserved_host恢复方法，如果失败，则尝试auto方法

另外，虚拟机高可用环境搭建，还需要借助pacemaker+corosync搭建的集群，其目的主要是检测计算节点的主机心跳状态，进而通过构建的fence设备关闭故障节点所在主机host电源。集群构建的相关软件如下：

• pacemaker：资源管理器，负责启动与停止集群服务，处于HA集群中的资源管理、资源代理层
• corosync：消息组件层，管理成员关系、消息与仲裁，为高可用环境提供通讯服务，位于高可用集群架构的底层，为各节点之间提供心跳信息
• resource-agents：资源代理，在节点上接收CRM的调度，对某一资源进行管理的工具，管理工具通常为脚本
• pcs：命令行工具集
• fence-agents：在节点不稳定或无应答时，关闭其电源，为集群提供STONITH功能， 防止集群脑裂，有效保护数据安全

三、故障检测与恢复

针对不同的故障类型，masakari需要做不通的故障处理，其流程图如下

3.1 虚拟机故障

计算节点通过运行masakari-instancemonitor服务，检测虚拟机故障信息。 基本原理为 该服务通过libvirt接口为虚拟机注册不同类型的绑定事件如 libvirt.VIR_DOMAIN_EVENT_ID_LIFECYCLE、libvirt.VIR_DOMAIN_EVENT_ID_IO_ERROR等用以检测虚拟机信息，如果发生故障，将通过注册事件的callback方法发送RPC消息，控制节点的masakari-api 监听指定topic 来获取RPC信息，并交由控制节点的masakari-engine服务来恢复此故障信息， 恢复流程为：调用nova-api 停止虚拟机、调用nova-api 启动虚拟机、调用nova-api 确认虚拟机状态为active 。 从而完成实例故障检测和修复的全流程。

3.2 计算服务故障

计算节点通过运行masakari-processmonitor服务，检测计算服务的运行信息，这里的计算服务，不单单指nova-compute服务，还包括libvirtd、masakari-hostmonitor、sshd等， 其基本原理为使用ps -ef 查看相关进程的状态，如果发生异常，则会重启对应服务。当然，也会发送RPC消息， 最终交由masakari-engine服务来处理故障，这个处理主要是指：禁用该计算节点，以确保计算服务故障期间，新的实例不会被调度到该节点上、 确认计算节点服务已关闭。

3.3 计算节点主机host故障

计算节点通过运行masakari-hostmonitor服务，检测主机host故障信息。实现原理为 计算节点通过pacemaker-remote添加进集群， masakari-hostmonitor服务则通过调用crm_mon或者cibadmin 命令查询计算节点的状态，如果检测到节点OFFINE ，则集群将使用fence命令(这里配置的是IPMI设备)关闭该节点节点电源，并发送RPC信息，最终由控制节点的masakari-engine服务来恢复此故障信息， 恢复流程为：禁用故障主机上的nova-compute服务、获取故障主机上，需要进行疏散的虚拟机信息、使用evacuate命令疏散故障主机上的实例、确认疏散是否完成。

补充: masakari的安装部署以及测试相对复杂，后面会单独发文章进行详细介绍。