防脑裂的OpenStack虚拟机高可用计算节点装置及管理方法与流程

本发明涉及云计算领域，具体涉及防脑裂的openstack虚拟机高可用计算节点装置及管理方法，属于计算机领域。

背景技术：

随着云技术方案的成熟，基于openstack的云计算平台也越来越广泛应用到各种领域，大量的业务系统被移植到云平台提供服务。其中，虚拟机高可用即ha(highavailability)功能，作为虚拟化平台重要特性引入云环境，在当前环境交互中已经愈发重要。该功能用于当物理主机出现故障时来自动恢复正在运行的虚拟机，在提升云平台可靠性的同时，也能够大大提升整个平台的可维护性。

但是，在原生openstack中，却并未提供完整的ha解决方案：

一方面，负责计算功能管理的nova模块中，仅提供了evacuate接口用于主机故障时将虚拟机疏散到其他节点，但模块本身缺少对ha的调度管理功能；

另一方面，专门处理ha的子开源项目masakari才刚刚从openstack孵化项目成为正式项目，项目本身成熟度依然很低，仅能完成少数场景下的ha恢复，尚无法支持商用。

此外，一些厂商也提供了各自的高可用方案，比如美国redhat公司提供的方案，是通过pacemaker软件来实现ha及fencing(隔离)功能。整个方案需要依赖ipmi平面与硬件狗，且只能处理主机监听网络异常等简单场景，无法处理和区分计算节点上其他网络平面(如管理网络平面、业务网络平面、存储网络平面等)故障的复杂场景。

技术实现要素：

本发明提供一种防脑裂的openstack虚拟机高可用计算节点装置，与共享存储装置连接进行存储，通过管理网络和管理端装置连接，该计算节点装置除安装有云计算虚拟机vm程序之外，还具有：

nova-computer计算机模块，用于直接响应管理端装置各管理进程来控制虚拟机vm的运行状态，并与hypervisorapi进行通信；

libvirt管理模块，用于在kvm上提供标准的hypervisorapi接口的管理进程；

lock管理模块，与libvirt管理模块配合，用于对共享存储装置的的锁心跳进行更新和监控；以及

高可用计算节点模块，至少用于将锁心跳上报给管理端装置，

其中，hastack-agcnt管理模块运行包括以下操作的方法：

操作c-1，当虚拟机vm持续更新并存储锁心跳时，若写入正常则无需处理，否则一旦锁心跳写入异常，则转到操作c-2；

操作c-2，lock管理模块向管理端装置上报存储异常事件，并等待管理端装置反馈处理结果；

操作c-3，若管理端装置在规定时间内返回了处理结果，则转到操作c-5，否则转到操作c-4；

操作c-4，若管理端装置未在规定时间内返回处理结果，则lock管理模块执行fencing隔离操作，即kill关闭该计算节点装置的云计算虚拟机vm程序；

操作c-5，lock管理模块按照管理端装置返回的处理结果，判断是否需要fencing。

本发明提供的计算节点装置，还可以具有这样的特征：

其中，lock管理模块的进程重启后恢复的过程包括以下操作：

操作d-1，在libvirt管理模块启动时，通过lock管理模块注册并获取锁心跳，如注册失败则转到s2；

操作d-2，一旦锁心跳注册失败，则kill关闭该计算节点装置的云计算虚拟机vm程序；

操作d-3，libvirt管理模块记录所有被kill关闭云计算虚拟机vm程序的计算节点装置，并记录在fencinglog即隔离日志文件中；

操作d-4，定期检查fencinglog文件，发现有更新则转到操作d-5；

操作d-5，向管理端装置上报所有计算节点装置的fencinglog文件，若上报失败，则此次处理结束，留待下次上报；否则，上报给管理端装置后，由管理端装置发出指示进行恢复。

本发明提供的计算节点装置，还可以具有这样的特征：

其中，在上报给管理端装置后，管理端装置进行以下的具体操作：

操作d-6，管理端装置收到agent计算节点装置上报的fencinglog文件，判断是否要进行自动处理，若自动处理转向操作d-8，若无需自动处理，转向操作d-7；

操作d-7，管理端装置告警待由人工处理；

操作d-8，管理端装置自动处理被fencing的云计算虚拟机vm程序，调用nova接口控制云计算虚拟机vm程序再次恢复运行。

本发明提供的计算节点装置，还可以具有这样的特征：

其中，共享存储装置为cephfs或nfs文件管理程序管理运行。

本发明提供的计算节点装置，还可以具有这样的特征：

其中，管理网络包括：

管理网络平面，用于对接管理端装置，用于提供管理服务；

存储网络平面，用于对接后端的共享存储装置，用于提供存储服务；

业务网络平面，用于对接计算节点装置，用于提供云计算虚拟机vm的访问服务。

本发明提供的计算节点装置，还可以具有这样的特征：

其中，云计算虚拟机vm程序具有vmguestos操作系统，该操作系统在fencing后进行以下的恢复操作：

操作e-1，vmguestos中的qga与计算节点装置的高可用计算节点模块持续保持锁心跳，当云计算虚拟机vm程序出现故障时，转到操作e-2；

操作e-2，当高可用计算节点模块接收到异常事件的报告时，上报给管理端装置；

操作e-3，管理端装置收到异常事件的报告后，直接调用nova接口控制云计算虚拟机vm程序再次恢复运行。

本发明提供的计算节点装置，还可以具有这样的特征：

其中，故障包括云计算虚拟机vm程序运行所在的计算节点装置蓝屏或卡死、死机。

本发明还提供一种防脑裂的openstack虚拟机高可用的计算节点装置的管理方法，包括以下操作：

操作c-1，当虚拟机vm持续更新并存储锁心跳时，若写入正常则无需处理，否则一旦锁心跳写入异常，则转到操作c-2；

操作c-2，lock管理模块向管理端装置上报存储异常事件，并等待管理端装置反馈处理结果；

操作c-3，若管理端装置在规定时间内返回了处理结果，则转到操作c-5，否则转到操作c-4；

操作c-4，若管理端装置未在规定时间内返回处理结果，则lock管理模块执行fencing操作，即kill关闭该计算节点装置的云计算虚拟机vm程序；

操作c-5，lock管理模块按照管理端装置返回的处理结果，判断是否需要fencing。

本发明提供的管理方法，还可以具有这样的特征：

其中，lock管理模块的进程重启后恢复的过程包括以下操作：

操作d-1，在libvirt管理模块启动时，通过lock管理模块注册并获取锁心跳，如注册失败则转到s2；

操作d-2，一旦锁心跳注册失败，则kill关闭该计算节点装置的云计算虚拟机vm程序；

操作d-3，libvirt管理模块记录所有被kill关闭云计算虚拟机vm程序的计算节点装置，并记录在fencinglog文件中；

操作d-4，定期检查fencinglog文件，发现有更新则转到操作d-5；

操作d-5，向管理端装置上报所有计算节点装置的fencinglog文件，若上报失败，则此次处理结束，留待下次上报；否则，上报给管理端装置后，由管理端装置发出指示进行恢复。

本发明提供的管理方法，还可以具有这样的特征：

云计算虚拟机vm程序具有vmguestos操作系统，该操作系统在fencing后进行以下的恢复操作：

操作e-1，vmguestos中的qga与计算节点装置的高可用计算节点模块持续保持锁心跳，当云计算虚拟机vm程序出现故障时，转到操作e-2；

操作e-2，当高可用计算节点模块接收到异常事件的报告时，上报给管理端装置；

操作e-3，管理端装置收到异常事件的报告后，直接调用nova接口控制云计算虚拟机vm程序再次恢复运行。

发明的作用和效果

根据发明所提供的防脑裂的openstack虚拟机高可用计算节点装置，因为具有高可用计算节点模块，其能够运行c-1到c-5的一系列操作，实时更新并存储lock分布式读写锁的锁心跳，并将更新时的写入的故障情况实时的上报给管理端装置，根据管理端装置的处理结果进行操作：是否fencing隔离或关闭该计算节点装置的云计算虚拟机vm程序，从而将lock分布式读写锁的锁保护力度，由计算节点装置的主机级别细化到虚拟机vm级别，能够针对单个虚拟机进行并发读写保护。

附图说明

图1是本发明的实施例中防脑裂的openstack虚拟机高可用系统的结构示意图；

图2是本发明的实施例中防脑裂的openstack虚拟机高可用管理端装置的高可用管理方法的流程示意图；

图3是本发明的实施例中防脑裂的openstack虚拟机高可用管理端装置的高可用模块进行fencing的流程示意图；

图4是本发明的实施例中防脑裂的openstack虚拟机高可用计算节点装置的高可用管理方法的流程示意图；

图5是本发明的实施例中防脑裂的openstack虚拟机高可用计算节点装置的lock管理模块的进程重启后恢复的过程示意图；以及

图6是本发明的实施例中防脑裂的openstack虚拟机高可用计算节点装置的云计算虚拟机vm程序在fencing后进行恢复操作的步骤示意图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，以下实施例结合附图对本发明防脑裂的openstack虚拟机高可用计算节点装置及管理方法作具体阐述。

英文缩写和技术专有名称解释

vm，virtualmachine即虚拟机，指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。

openstack，openstack是一个开源的云计算管理平台项目，由nasa(美国国家航空航天局)和rackspace合作研发并发起的，以apache许可证授权的自由软件和开放源代码项目。

nova，openstack项目中的计算资源管理组件，包含nova-api、nova-scheduler、nova-conductor、nova-compute等进程。作为整个openstack项目的核心计算控制器，用于实现对用户虚拟机实例的生命周期管理来提供虚拟服务，提供诸如虚拟机创建、开机、关机、挂起、暂停、调整、迁移、重启、销毁等虚拟机vm的生命周期进行操作，以及配置cpu、内存规格，集群调度等功能。

nova-api，nova对外提供的交互接口，消息处理入口。管理者可以通过这个接口来管理内部基础设施，也可以通过这个接口向用户提供服务。当接收到请求后，经过基本校验后，它会将各请求通过消息队列发送到下一个模块去。

nova-scheduler，主要完成nova中各虚拟机实例的调度工作。能够根据诸如cpu构架、主机的内存、负载、是否具备某种硬件要求等条件，将各实例调度分配到合适的节点上。

nova-conductor，nova内部用于长任务的处理者。主要处理诸如虚拟机实例的创建、迁移等耗时较长的任务的跟踪管理。此外还负责数据库的访问权限控制，避免nova-compute直接访问数据库。

nova-computer，位于计算节点上，是虚拟机生命周期管理操作的真正执行者。通过消息队列接收请求，响应控制节点各管理进程，直接负责与hypervisor进行各种通信。

novacontroller，一种角色定义或称呼。一般指代包括nova-api、nova-conductor、nova-scheduler等主要负责处理虚拟机管理操作的nova各进程；一般会被部署在被称为管理节点的独立节点上，不与nova-compute所在的计算节点部署在一起。

hastack，采用c-s结构提供ha功能的两个自研组件之一，位于server端。作为ha管理的大脑，用来管理全局的ha行为，其功能由高可用模块执行。

hastack-agent，采用c-s结构提供ha功能的两个自研组件之一，位于agent端。主要负责挂载共享目录，上报本节点心跳状态与vmfencing事件；并配合hastack完成部分ha动作的管理，其功能由高可用计算节点模块。

api，applicationprogramminginterface，应用编程接口。组件通过api将内核暴露出去，供外界访问调用。

hypervisor，是一种运行在物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享一套基础物理硬件，因此也可以看作是虚拟环境中的“元”操作系统。作为平台硬件和操作系统的抽象，它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器(virtualmachinemonitor)。hypervisor是所有虚拟化技术的核心。非中断地支持多工作负载迁移的能力是hypervisor的基本功能。当服务器启动并执行hypervisor时，它会给每一台虚拟机分配适量的内存、cpu、网络和磁盘，并加载所有虚拟机的客户操作系统。

kvm，kernel-basedvirtualmachine，是一个开源的系统虚拟化模块，是基于硬件的完全虚拟化，主要提供基于内核的虚拟机。

libvirt，在kvm之上提供标准的hypervisorapi接口的管理进程。

lock模块，用于提供分布式读写锁，来控制和管理对同一存储的并发写入。该模块与libvirt配合，在共享存储上完成各锁资源的心跳更新与注册。

etcd，高可用的分布式键值(key-value)数据库,由go语言实现，通过一致性算法来保证强一致性。在本方案中作为集群软件，主要用来提供以下两点功能：一是组建三平面集群，感知全局健康状态供ha决策；二是作为hastack与hastack-agent间的信息桥梁。

consul，hashicorp公司推出的开源工具,用于实现分布式系统的服务发现与配置。在本方案中作为集群软件，起到三平面检测及hastack与hastack-agent间信息桥梁的作用。

ceph，一种为优秀的性能、可靠性和可扩展性而设计的统一的分布式存储软件。

cephfs，基于ceph存储提供的分布式文件系统。在本方案中，主要用来存储各种lock模块的锁文件。

nfs，即网络文件系统，它允许网络中的计算机之间通过tcp/ip网络共享文件或目录。nfs服务器可以允许nfs客户端将远端nfs服务器端的共享目录挂载到本地的nfs客户端中。在nfs的应用中，本地nfs的客户端应用可以透明地读写位于远端nfs服务器上的文件，就像访问本地的磁盘分区和目录一样。

fencing：指在分布式领域，当部分资源状态不确定时，出于数据保护避免脑裂的目的，采用的将可疑资源进行隔离关闭的处理方式。

guestos：guest在虚拟化领域，用来指代被虚拟出来的系统，也就是运行了软件(例如操作系统)的虚拟机示例。guestos即虚拟机用的操作系统。

qga：是qemu(模拟器)-guest(访客)-agent(代理端)的简称，是一个运行在虚拟机内部的普通应用程序，即是在虚拟机上增加一个串口与主机进行socket通信，来实现一种宿主机和虚拟机vm进行交互的方式。

实施例1

如图1所示，防脑裂的openstack虚拟机高可用系统，包括管理端装置100、管理网络200、计算节点装置300以及共享存储装置400。

其中，至少两个管理端装置之间通过管理网络进行通信而组成管理集群110。

管理端装置与计算节点装置通过管理网络通信连接。

计算节点装置与共享存储装置连接。

具体的如图1所示，这里以三个管理端装置100(即图中的控制节点a、b、c)、三个计算节点装置300(即图中的计算节点a、b、c)和一个共享存储装置400为例进行说明。

实施例中，三个计算节点装置300都和一个共享存储装置400连接，即三个计算节点装置300共享一个共享存储装置400。

每个管理端装置100包括nova控制模块101、集群管理模块102、高可用模块103。

nova控制模块101，即图中的novacontroller，包括nova原生的虚拟机vm管理进程，用于对虚拟机vm的生命周期进行管理操作。

集群管理模块102，即图中的etcd，用于收集集群的运行状况信息。

高可用模块103，即图中的hastack,用于对所有的计算节点装置进行高可用管理。

管理网络200被划分为三大网络平面，分别是管理网络平面201、存储网络平面202、业务网络平面203。

管理网络平面201，用于对接管理端装置，用于提供管理服务。

存储网络平面202，用于对接后端的共享存储装置，用于提供存储服务。

业务网络平面203，用于对接计算节点装置，用于提供云计算虚拟机vm的访问服务。

所有的节点都连接在三大平面上，集群管理模块102，即图中的etcd分别对应各个平面组建对应的集群。

每个计算节点装置300除安装有云计算虚拟机vm程序301，即图中的vm之外，还具有nova-computer计算机模块302、libvirt管理模块303、lock管理模块304、高可用计算节点模块305。

nova-computer计算机模块302，即图中的nova-compute，用于直接响应管理端装置各管理进程来控制云计算虚拟机vm的运行状态，并与hypervisorapi进行通信。

libvirt管理模块303，即图中libvirt，用于在kvm上提供标准的hypervisorapi接口的管理进程。

lock管理模块304，即图中的lock，与libvirt管理模块配合，用于对共享存储装置的的锁心跳进行更新和监控。

高可用计算节点模块305，即图中的hastack-agent，至少用于将锁心跳上报给管理端装置。

以下对管理端装置100、计算节点装置300中涉及的openstack虚拟机的云计算虚拟机nova的各个组件和服务进行解释。

nova-controller，由nova控制模块101来运行，包括nova-api、nova-conductor或nova-scheduler等虚拟机管理进程，设置在管理端装置100中，主要用来对虚拟机vm的生命周期进行管理操作。

hastack，由高可用模块103来运行，设置在管理端装置100中，用来管理全局的ha行为。

集群软件，由集群管理模块102来运行，使用的软件包括etcd、consul等，本实施例使用etcd。与hastack组件结合使用，设置在管理端装置100中，用于感知整个集群的健康状态供ha决策，且作为高可用模块103与高可用计算节点模块305间的信息桥梁。

nova-compute，原生nova进程，由nova-computer计算机模块302运行就，设置在计算节点装置300中，用于响应控制节点各管理进程，是虚拟机生命周期管理操作的真正执行者，直接负责与hypervisor进行各种通信。

hastack-agent，与nova-compute进程结合使用，由高可用计算节点模块305运行，设置在计算节点装置300中，主要负责挂载共享目录，上报本节点锁心跳状态，并配合hastack组件完成部分ha动作的管理功能。

libvirt，设置在计算节点装置300中，由libvirt管理模块303运行，在kvm之上提供标准的hypervisorapi接口的管理进程。

lock，由lock管理模块304运行，设置在计算节点装置300中，与libvirt组件配合，位于共享存储装置500的架构上层，完成各种锁心跳的更新与监控。用于提供分布式读写锁，来控制和管理对同一存储的并发写入。本实施例中创新的lock模块，是参考原生lock功能而新发明的分布式读写锁管理器。也可根据需要，使用原生lock模块，或对原生lock进行适应性二次开发。共享存储系统，由共享存储装置400运行，采用的软件程序包括cephfs、nfs，提供共享文件系统存储。

如图4所示，由于底层的共享存储装置400的存储故障会导致lock的锁心跳无法按时写入，此时需要hastack-agent与hastack之间确认是否需执行fencing，此时就需要高可用计算节点模块运行包括以下操作的方法：

操作c-1，当云计算虚拟机vm持续更新并存储锁心跳时，若写入正常则无需处理，否则一旦锁心跳写入异常，则转到操作c-2。

具体就是，在计算节点装置上，虚拟机vm持续更新lock的锁心跳并存储；若存储中写入正常则无需处理；否则一旦锁心跳写入异常超过预定时间，则转到操作c-2。

操作c-2，lock管理模块向管理端装置上报存储异常事件，并等待管理端装置反馈处理结果。

具体就是，lock通知hastack-agent，向hastack上报底层存储异常事件，并等待hastack提供处理结果。

操作c-3，若管理端装置在规定时间内返回了处理结果，则转到操作c-5，否则转到操作c-4。

具体就是，若hastack在预定时间内返回了处理意见，则转到操作c-5；否则转到操作c-4。

操作c-4，若管理端装置未在规定时间内返回处理结果，则lock管理模块执行fencing操作，即kill关闭该计算节点装置的云计算虚拟机vm程序。

具体就是，一旦hastack未按时返回结果，则lock就按照默认设定执行fencing操作，即kill掉该计算节点上运行的所有虚拟机vm。

操作c-5，lock管理模块按照管理端装置返回的处理结果，判断是否需要fencing。

实施例2

在实施例1的基础上，如图5所示，由于lock大量数据是存储在内存中的，未做持久化。因此如果lock模块/进程异常重启后，原来所有挂载在锁空间下的所有资源均会被清空，这种情况会导致原虚拟机vm全部脱管，此时需要由lock管理模块进程重启后恢复，该恢复过程包括以下操作：

操作d-1，在libvirt管理模块启动时，通过lock管理模块注册并获取锁心跳，如注册失败则转到操作d-2。

具体就是，libvirt在启动时通过lock注册并获取锁心跳，一旦失败则转到操作d-2。

操作d-2，一旦锁心跳注册失败，则kill关闭该计算节点装置的云计算虚拟机vm程序。

操作d-3，libvirt管理模块记录所有被kill关闭云计算虚拟机vm程序的计算节点装置，并记录在fencinglog(隔离日志)文件中。

操作d-4，定期检查fencinglog文件，发现有更新则转到操作d-5。

具体就是，hastack-agent定期检查节点上的fencinglog，一旦发现有更新则转到操作d-5。

操作d-5，向管理端装置上报所有计算节点装置的fencinglog文件，若上报失败，则此次处理结束，留待下次上报；否则，上报给管理端装置后，由管理端装置发出指示进行恢复。

具体就是，hastack-agent向hastack上报所有fencinglog，若上报失败，则此次处理结束，留待下次上报。

实施例3

在实施例1或2的基础上，其中，在上报给管理端装置后，管理端装置进行以下的具体操作：

操作d-6，管理端装置收到agent计算节点装置上报的fencinglog文件，判断是否要进行自动处理，若自动处理转向操作d-8，若无需自动处理，转向操作d-7。

具体就是，hastack收到agent上报的fencinglog，根据提前配置好的处理开关，确定是否要进行自动处理：若自动处理转向操作d-8，若无需自动处理，转向操作d-7。

操作d-7，管理端装置告警待由人工处理。

具体就是，hastack不自动恢复所有fencing虚拟机，只上报告警，交由后续管理员手动恢复。

操作d-8，管理端装置自动处理被fencing的云计算虚拟机vm程序，调用nova接口控制云计算虚拟机vm程序再次恢复运行。

具体就是，hastack需要自动处理fencing虚拟机，会逐个调用nova接口触发ha恢复流程。

实施例4

进一步的，在上述实施例1-3的基础上，云计算虚拟机vm程序具有vmguestos操作系统，该操作系统在fencing后进行以下的恢复操作：

操作e-1，vmguestos中的qga与计算节点装置的高可用计算节点模块持续保持锁心跳，当云计算虚拟机vm程序出现故障时，转到操作e-2。

具体就是，vmguestos中的qga会与计算节点的hastack-agent持续保持心跳，一旦当虚拟机内蓝屏或卡死时，转到操作e-2。

操作e-2，当高可用计算节点模块接收到异常事件的报告时，上报给管理端装置。

具体就是，当hastack-agent接收到异常事件时，会立即上报给hastack。

操作e-3，管理端装置收到异常事件的报告后，直接调用nova接口控制云计算虚拟机vm程序再次恢复运行。

具体就是，hastack收到虚拟机vm内部异常事件后，直接向nova下发ha命令，触发ha恢复。

实施例5

在上述实施例1-4的基础上，如图2所示，高可用模块103运行高可用管理的方法，该方法包括以下操作：

操作a-1，通过集群管理模块收集的运行状况信息检查集群状态是否正常，如果异常，则触发集群异常告警并结束，如果正常，则转到操作a-2。

具体就是hastack检查集群状态是否正常，如果异常，则触发集群异常告警，结束此轮检查；如果正常，则转到操作a-2。

操作a-2，检查各个计算节点装置通过管理网络上报的状态，如果正常，则此轮检查终止，否则转到下一步操作a-3。

具体就是，hastack检查各节点通过hastack-agent上报的管理网络三平面状态，如果均正常，则此轮检查终止；否则转到操作a-3。

操作a-3，根据每个计算节点装置通过管理网络上报的异常状态，逐个判断是否需要进行处理，如果无需处理，则该计算节点装置异常处理结束，转回上一步操作a-2；否则转到下一步操作a-4。

具体就是，hastack逐个处理有异常的节点，根据各节点具体是哪个网络平面中断，比对ha策略矩阵，确定后续处理策略；如果无需处理，则该节点异常处理结束，转回操作a-3；否则，如果需要后续处理，则转到操作a-4。

操作a-4，对于需要处理的异常状态的计算节点装置，检查与之连接的共享存储装置的状态，当共享存储装置异常时，通过nova控制模块控制该计算节点装置上运行的云计算虚拟机vm程序不运行，并结束，否则，转到下一步操作a-5。

具体就是，hastack检查共享存储装置400的工作状态，如果共享存储装置400此时异常则不能触发ha，即云计算虚拟机vm不运行。此轮处理结束；否则，若存储正常则转到操作a-5。

操作a-5，向所连接的共享存储装置状态正常的计算节点装置下发fencing请求，fencing即kill关闭该节点的云计算虚拟机vm程序。

操作a-6，向nova控制模块下发命令，触发该计算节点装置上运行的云计算虚拟机vm程序运行。

实施例6

在实施例1-5的基础上，如图3所示，当管理端装置100向所连接的共享存储装置状态正常的计算节点装置下发fencing请求后，hastack需根据环境现状确实如何响应底层hastack-agent端上报的存储中断事件，为此高可用模块还运行以下操作：

操作b-1，持续监听计算节点装置上报的fencing事件，一旦收到消息则转到操作b-2。

具体就是，hastack持续监听hastack-agent上报的fencing事件，一旦收到消息则转到操作b-2。

操作b-2，通过集群管理模块收集的运行状况信息检查集群状态是否正常，如果异常，则触发集群异常告警并结束，如果正常，则转到操作b-3。

具体就是，hastack检查集群状态是否正常，如果异常，则触发集群异常告警，结束此轮检查；如果正常，则转到操作b-3。

操作b-3，检查各个计算节点装置通过管理网络上报的网络状态，如果正常，则此轮检查终止，否则转到操作b-4。

具体就是，hastack检查各节点通过hastack-agent上报的管理网络三平面状态。

操作b-4，根据每个计算节点装置通过管理网络上报的异常状态，判断是否需要进行处理，如果无需处理，则进行操作b-6；否则转到操作b-5。

hastack逐个处理有异常的节点，根据各节点具体中断类型，比对ha策略矩阵，确定后续fencing处理策略；如果无需处理，则转到操作b-6；否则若需要后续处理，则转到操作b-5。

操作b-5，对于需要处理的异常状态的计算节点装置，检查与之连接的共享存储装置的状态，当共享存储装置异常时，无需fencing并转到操作b-6，并结束，否则，转到操作b-7。

具体就是，hastack检查存储状态，若存储异常则无需fencing，转到操作b-6；否则转到操作b-7。

操作b-6，针对无需fencing的场景，向对应的计算节点装置下发停止fencing请求。

具体就是，针对无需fencing的场景，hastack向hastack-agent下发停止fencing请求。

操作b-7，针对需要fencing的场景，向对应的计算节点装置下发执行fencing请求。

具体就是，针对需要fencing的场景，hastack向hastack-agent下发执行fencing请求。

实施例7

如图4所示，本实施例提供一种防脑裂的openstack虚拟机高可用的计算节点装置的管理方法，包括以下操作：

操作c-1，当虚拟机vm持续更新并存储锁心跳时，若写入正常则无需处理，否则一旦锁心跳写入异常，则转到操作c-2；

操作c-2，lock管理模块向管理端装置上报存储异常事件，并等待管理端装置反馈处理结果；

操作c-3，若管理端装置在规定时间内返回了处理结果，则转到操作c-5，否则转到操作c-4；

操作c-4，若管理端装置未在规定时间内返回处理结果，则lock管理模块执行fencing操作，即kill关闭该计算节点装置的云计算虚拟机vm程序；

操作c-5，lock管理模块按照管理端装置返回的处理结果，判断是否需要fencing。

实施例8

在实施例7的基础上，lock管理模块的进程重启后恢复的过程包括以下操作：

操作d-1，在libvirt管理模块启动时，通过lock管理模块注册并获取锁心跳，如注册失败则转到s2；

操作d-2，一旦锁心跳注册失败，则kill关闭该计算节点装置的云计算虚拟机vm程序；

操作d-3，libvirt管理模块记录所有被kill关闭或隔离的云计算虚拟机vm程序的计算节点装置，并记录在fencinglog文件中；

操作d-4，定期检查fencinglog文件，发现有更新则转到操作d-5；

操作d-5，向管理端装置上报所有计算节点装置的fencinglog文件，若上报失败，则此次处理结束，留待下次上报；否则，上报给管理端装置后，由管理端装置发出指示进行恢复。

实施例9

在实施例7、8的基础上，在fencing后进行以下的恢复操作：

操作e-1，vmguestos中的qga与计算节点装置的高可用计算节点模块持续保持锁心跳，当云计算虚拟机vm程序出现故障时，转到操作e-2；

操作e-2，当高可用计算节点模块接收到异常事件的报告时，上报给管理端装置；

操作e-3，管理端装置收到异常事件的报告后，直接调用nova接口控制云计算虚拟机vm程序再次恢复运行。

故障包括云计算虚拟机vm程序运行所在的计算节点装置蓝屏或卡死、死机。

实施例10

如图2所示，本实施例提供一种防脑裂的openstack虚拟机高可用的管理端装置的管理方法，包括以下操作：

操作a-1，通过收集的运行状况信息检查集群状态是否正常，如果异常，则触发集群异常告警并结束，如果正常，则转到操作a-2；

操作a-2，检查各个计算节点装置通过管理网络上报的状态，如果正常，则此轮检查终止，否则转到下一步操作a-3；

操作a-3，根据每个计算节点装置通过管理网络上报的异常状态，逐个判断是否需要进行处理，如果无需处理，则该计算节点装置异常处理结束，转回上一步操作a-2；否则转到下一步操作a-4；

操作a-4，对于需要处理的异常状态的计算节点装置，检查与之连接的共享存储装置的状态，当共享存储装置异常时，通过nova控制模块控制该计算节点装置上运行的云计算虚拟机vm程序不运行，并结束，否则，转到下一步操作a-5；

操作a-5，向所连接的共享存储装置状态正常的计算节点装置下发fencing请求；

操作a-6，向nova控制模块下发命令，触发该计算节点装置上运行的云计算虚拟机vm程序运行。

实施例11

在实施例10提供的方法的基础上，如图3所示，当向所连接的共享存储装置状态正常的计算节点装置下发fencing请求后，还运行以下操作：

操作b-1，持续监听计算节点装置上报的fencing事件，一旦收到消息则转到操作b-2；

操作b-2，通过收集的运行状况信息检查集群状态是否正常，如果异常，则触发集群异常告警并结束，如果正常，则转到操作b-3；

操作b-3，检查各个计算节点装置通过管理网络上报的网络状态，如果正常，则此轮检查终止，否则转到操作b-4；

操作b-4，根据每个计算节点装置通过管理网络上报的异常状态，判断是否需要进行处理，如果无需处理，则进行操作b-6；否则转到操作b-5；

操作b-5，对于需要处理的异常状态的计算节点装置，检查与之连接的共享存储装置的状态，当共享存储装置异常时，无需fencing并转到操作b-6，并结束，否则，转到操作b-7；

操作b-6，针对无需fencing的场景，向对应的计算节点装置下发停止fencing请求；

操作b-7，针对需要fencing的场景，向对应的计算节点装置下发执行fencing请求。

实施例的作用与效果

本发明基于原生openstack版本进行了二次开发，通过对几种关键技术进行整合，在openstack外围自主开发了一套独立的防脑裂的openstack虚拟机高可用系统。摆脱了传统ha方案中对ipmi平面探测/硬件狗等依赖，实现了电信级可靠性的完整虚拟机高可用(ha)技术方，为此本发明中提供了一种改进的防脑裂的openstack虚拟机高可用计算节点装置及管理方法，用于实现计算节点装置即作为agent的计算节点的高可用性。

在云计算系统中，脑裂(split-brain)，指在一个高可用(ha)系统中，当联系着的两个控制节点或计算节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏，通过本发明的改进所提供的改进的防脑裂的openstack虚拟机高可用计算节点装置及管理方法即可以解决这个问题。

根据实施例所提供的防脑裂的openstack虚拟机高可用计算节点装置，因为具有高可用计算节点模块，其能够运行c-1到c-5的一系列操作，实时更新并存储lock的锁心跳，并将更新时的写入的故障情况实时的上报给管理端装置，根据管理端装置的处理结果进行操作：是否fencing关闭该计算节点装置的云计算虚拟机vm程序，从而将lock分布式读写锁的锁保护力度，由计算节点装置的主机级别细化到虚拟机vm级别，能够针对单个虚拟机进行并发读写保护。

通过锁心跳来禁止多个虚拟机同时写磁盘，从根本上解决“脑裂”的发生。

将lock的锁保护力度，由计算节点装置的主机级别细化到虚拟机vm级别，能够针对单个虚拟机进行并发读写保护。

通过自主发明的全流程的vmfencing保护机制，防止由于共享存储装置异常等故障影响底层锁心跳而导致的虚拟机被异常终止。

过程中，采用异步通知机制，解决lock重启导致的havm的脱管问题，实现了自动恢复。

进一步，独立于原生openstack，自主开发的hastack服务，用于管理ha整个调度，hastack通过集成etcd及qga，实现了对下层全主机的管理网络三平面(管理网络平面、业务网络平面、存储网络平面)的健康状态，及虚拟机vm内部运行状态的精确感知：

1.通过调整心跳打点周期与消息来快速确认计算节点装置物理平面的各故障点，提供高精度的判断依据供hastack决策。

2.针对单个计算节点装置管理网络三平面三平面的各类异常，通过可配置的ha故障对应处理的方案，支持用户对对应的方案进行自设置的定制化ha恢复策略。

3.通过集成qga来进行虚拟机vm健康监测，一旦发生虚拟机vm内部蓝屏、卡死等故障则立刻触发ha恢复，实现自愈。

4.针对各种集群、存储、网络连线异常，均添加了相应的保护机制。

上述实施方式为本发明的优选案例，并不用来限制本发明的保护范围。