CN109634716B - 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 - Google Patents
防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 Download PDFInfo
- Publication number
- CN109634716B CN109634716B CN201811475904.4A CN201811475904A CN109634716B CN 109634716 B CN109634716 B CN 109634716B CN 201811475904 A CN201811475904 A CN 201811475904A CN 109634716 B CN109634716 B CN 109634716B
- Authority
- CN
- China
- Prior art keywords
- management
- computing node
- node device
- state
- virtual machine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Hardware Redundancy (AREA)
Abstract
防脑裂的OpenStack虚拟机高可用管理端装置,包括:Nova模块;集群管理模块;以及高可用模块,高可用模块运行高可用管理的方法,包括:检查集群状态是否正常,如果异常,则告警并结束,如果正常下一步;检查各个计算节点装置通过管理网络上报的状态,如果正常终止,否则转到下一步;根据异常状态,逐个判断是否需要进行处理,无需处理则结束转回上一步,否则转到下一步;对于需要处理的异常状态的计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,控制该计算节点装置上运行的云计算虚拟机VM程序不运行并结束,否则转到下一步;下发Fencing请求;下发命令,触发该计算节点装置上运行的云计算虚拟机VM程序运行。
Description
技术领域
本发明涉及云计算领域,具体涉及防脑裂的OpenStack虚拟机高可用管理端装置及管理方法,属于计算机领域。
背景技术
随着云技术方案的成熟,基于OpenStack的云计算平台也越来越广泛应用到各种领域,大量的业务系统被移植到云平台提供服务。其中,虚拟机高可用即HA(Highavailability)功能,作为虚拟化平台重要特性引入云环境,在当前环境交互中已经愈发重要。该功能用于当物理主机出现故障时来自动恢复正在运行的虚拟机,在提升云平台可靠性的同时,也能够大大提升整个平台的可维护性。
但是,在原生OpenStack中,却并未提供完整的HA解决方案:
一方面,负责计算功能管理的Nova模块中,仅提供了Evacuate接口用于主机故障时将虚拟机疏散到其他节点,但模块本身缺少对HA的调度管理功能;
另一方面,专门处理HA的子开源项目Masakari才刚刚从OpenStack孵化项目成为正式项目,项目本身成熟度依然很低,仅能完成少数场景下的HA恢复,尚无法支持商用。
此外,一些厂商也提供了各自的高可用方案,比如美国Red hat公司提供的方案,是通过Pacemaker软件来实现HA及Fencing(隔离)功能。整个方案需要依赖IPMI平面与硬件狗,且只能处理主机监听网络异常等简单场景,无法处理和区分计算节点上其他网络平面(如管理网络平面、业务网络平面、存储网络平面等)故障的复杂场景。
发明内容
本发明提供一种防脑裂的OpenStack虚拟机高可用管理端装置,通过管理网络和连接有共享存储装置的计算节点装置连接,该计算节点装置安装有虚拟机VM,其特征在于:
至少两个管理端装置之间能通过管理网络进行通信而组成管理集群,
每个管理端装置包括:
Nova模块,包括Nova原生的虚拟机VM管理进程,用于对虚拟机VM的生命周期进行管理操作;
集群管理模块,用于收集集群的运行状况信息;以及
高可用模块,用于对所有的计算节点装置进行高可用管理,
其中,高可用模块运行高可用管理的方法,该方法包括以下操作:
操作A-1,通过集群管理模块收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作A-2;
操作A-2,检查各个计算节点装置通过管理网络上报的状态,如果正常,则此轮检查终止,否则转到下一步操作A-3;
操作A-3,根据每个计算节点装置通过管理网络上报的异常状态,逐个判断是否需要进行处理,如果无需处理,则该计算节点装置异常处理结束,转回上一步操作A-2;否则转到下一步操作A-4;
操作A-4,对于需要处理的异常状态的计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,通过Nova模块控制该计算节点装置上运行的虚拟机VM不运行,并结束,否则,转到下一步操作A-5;
操作A-5,向所连接的共享存储装置状态正常的计算节点装置下发隔离请求,隔离fencing即隔离关闭该节点的虚拟机VM;
操作A-6,向Nova模块下发命令,触发该计算节点装置上运行的虚拟机VM运行。
本发明提供的管理端装置,还可以具有这样的特征:
其中,当管理端装置向所连接的共享存储装置状态正常的计算节点装置下发关闭请求后,高可用模块还运行以下操作:
操作B-1,持续监听计算节点装置上报的关闭事件,一旦收到消息则转到操作B-2;
操作B-2,通过集群管理模块收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作B-3;
操作B-3,检查各个计算节点装置通过管理网络上报的网络状态,如果正常,则此轮检查终止,否则转到操作B-4;
操作B-4,根据每个计算节点装置通过管理网络上报的异常状态,判断是否需要进行处理,如果无需处理,则进行操作B-6;否则转到操作B-5;
操作B-5,对于需要处理的异常状态的计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,无需关闭并转到操作B-6,并结束,否则,转到操作B-7;
操作B-6,针对无需关闭的场景,向对应的计算节点装置下发停止关闭请求;
操作B-7,针对需要关闭的场景,向对应的计算节点装置下发执行关闭请求。
本发明提供的管理端装置,还可以具有这样的特征:
其中,云计算虚拟机VM管理进程包括Nova-api、Nova-conductor或Nova-scheduler。
本发明提供的管理端装置,还可以具有这样的特征:
其中,集群管理模块包括Etcd或Consul。
本发明提供的管理端装置,还可以具有这样的特征:
其中,共享存储装置为CephFS或NFS文件管理程序管理运行。
本发明提供的管理端装置,还可以具有这样的特征:
其中,管理网络包括:
管理网络平面,用于对接管理端装置,用于提供管理服务;
存储网络平面,用于对接后端的共享存储装置,用于提供存储服务;
业务网络平面,用于对接计算节点装置,用于提供云计算虚拟机VM的访问服务。
本发明提供的管理端装置,还可以具有这样的特征:
其中,当管理网络的管理网络平面、存储网络平面以及业务网络平面均正常时,操作A-2中计算节点装置通过管理网络上报的网络状态才判断为正常,否则根据异常的计算节点装置的具体中断类型是管理网络平面、存储网络平面以及业务网络平面中的哪一种或几种进行相应的处理。
本发明提供的管理端装置,还可以具有这样的特征:
其中,其中,管理网络包括:
管理网络平面,用于对接管理端装置,用于提供管理服务;
存储网络平面,用于对接后端的共享存储装置,用于提供存储服务;
业务网络平面,用于对接计算节点装置,用于提供虚拟机VM的访问服务,
对应的,当管理网络的管理网络平面、存储网络平面以及业务网络平面均正常时,操作B-3中计算节点装置通过管理网络上报的网络状态才判断为正常,否则根据异常的计算节点装置的具体中断类型是管理网络平面、存储网络平面以及业务网络平面中的哪一种或几种进行相应的关闭处理。
本发明还提供一种防脑裂的OpenStack虚拟机高可用的管理端装置的管理方法,包括以下操作:
操作A-1,通过收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作A-2;
操作A-2,检查各个所述计算节点装置通过管理网络上报的状态,如果正常,则此轮检查终止,否则转到下一步操作A-3;
操作A-3,根据每个所述计算节点装置通过管理网络上报的异常状态,逐个判断是否需要进行处理,如果无需处理,则该计算节点装置异常处理结束,转回上一步操作A-2;否则转到下一步操作A-4;
操作A-4,对于需要处理的异常状态的所述计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,通过所述Nova模块控制该计算节点装置上运行的所述虚拟机VM不运行,并结束,否则,转到下一步操作A-5;
操作A-5,向所连接的共享存储装置状态正常的所述计算节点装置下发隔离请求;
操作A-6,向所述Nova模块下发命令,触发该计算节点装置上运行的所述虚拟机VM运行。
本发明提供的管理方法,还可以具有这样的特征:
其中,向所连接的共享存储装置状态正常的计算节点装置下发关闭请求后,还运行以下操作:
操作B-1,持续监听所述计算节点装置上报的隔离事件,一旦收到消息则转到操作B-2;
操作B-2,通过收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作B-3;
操作B-3,检查各个所述计算节点装置通过管理网络上报的网络状态,如果正常,则此轮检查终止,否则转到操作B-4;
操作B-4,根据每个所述计算节点装置通过管理网络上报的异常状态,判断是否需要进行处理,如果无需处理,则进行操作B-6;否则转到操作B-5;
操作B-5,对于需要处理的异常状态的所述计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,无需隔离并转到操作B-6,并结束,否则,转到操作B-7;
操作B-6,针对无需隔离的场景,向对应的所述计算节点装置下发停止隔离请求;
操作B-7,针对需要隔离的场景,向对应的所述计算节点装置下发执行隔离请求。
发明的作用和效果
根据本发明提供的防脑裂的OpenStack虚拟机高可用管理端装置,因为具有高可用模块,其能够运行高可用管理的方法,通过A-1到A-6的一系列操作,实时检测连接的计算节点装置以及共享存储装置的状态,根据获知的异常状态的类型:计算节点装置的异常还是共享存储装置的异常,具体的是管理网络中的管理网络平面、存储网络平面、业务网络平面哪一部分的异常,并判断后决定是否进行Fencing隔离操作来关闭对应出现异常的计算节点装置的虚拟机VM,从而保证系统中的计算节点装置的虚拟机VM的高可用性。
附图说明
图1是本发明的实施例中防脑裂的OpenStack虚拟机高可用系统的结构示意图;
图2是本发明的实施例中防脑裂的OpenStack虚拟机高可用管理端装置的高可用管理方法的流程示意图;
图3是本发明的实施例中防脑裂的OpenStack虚拟机高可用管理端装置的高可用模块进行Fencing的流程示意图;
图4是本发明的实施例中防脑裂的OpenStack虚拟机高可用计算节点装置的高可用管理方法的流程示意图;
图5是本发明的实施例中防脑裂的OpenStack虚拟机高可用计算节点装置的Lock管理模块的进程重启后恢复的过程示意图;以及
图6是本发明的实施例中防脑裂的OpenStack虚拟机高可用计算节点装置的虚拟机VM在Fencing后进行恢复操作的步骤示意图。
具体实施方式
为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解,以下实施例结合附图对防脑裂的OpenStack虚拟机高可用管理端装置及管理方法作具体阐述。
英文缩写和技术专有名称解释
VM,Virtual Machine即虚拟机,指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。
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-compute,位于计算节点上,是虚拟机生命周期管理操作的真正执行者。通过消息队列接收请求,响应控制节点各管理进程,直接负责与Hypervisor进行各种通信。
Nova controller,一种角色定义或称呼。一般指代包括Nova-api、nova-conductor、nova-scheduler等主要负责处理虚拟机管理操作的Nova各进程;一般会被部署在被称为管理节点的独立节点上,不与nova-compute所在的计算节点部署在一起。
FitOS,烽火集成,申请人自己开发的基于OpenStack的商用产品的代称,显然,其所有的功能也可以使用原生的OpenStack来实现。
HaStack,FitOS中采用C-S结构提供HA功能的两个自研组件之一,位于Server端。作为HA管理的大脑,用来管理全局的HA行为,其功能由高可用模块执行。
HaStack-agent,FitOS中采用C-S结构提供HA功能的两个自研组件之一,位于Agent端。主要负责挂载共享目录,上报本节点心跳状态与VM Fencing事件;并配合HaStack完成部分HA动作的管理,其功能由高可用计算节点模块。
API,Application Programming Interface,应用编程接口。组件通过API将内核暴露出去,供外界访问调用。
Hypervisor,是一种运行在物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享一套基础物理硬件,因此也可以看作是虚拟环境中的“元”操作系统。作为平台硬件和操作系统的抽象,它可以协调访问服务器上的所有物理设备和虚拟机,也叫虚拟机监视器(Virtual Machine Monitor)。Hypervisor是所有虚拟化技术的核心。非中断地支持多工作负载迁移的能力是Hypervisor的基本功能。当服务器启动并执行Hypervisor时,它会给每一台虚拟机分配适量的内存、CPU、网络和磁盘,并加载所有虚拟机的客户操作系统。
KVM,Kernel-based Virtual Machine,是一个开源的系统虚拟化模块,是基于硬件的完全虚拟化,主要提供基于内核的虚拟机。
Libvirt,在KVM之上提供标准的Hypervisor API接口的管理进程。
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,即图中的Nova controller,包括Nova原生的虚拟机VM管理进程,用于对虚拟机VM的生命周期进行管理操作。
集群管理模块102,即图中的Etcd,用于收集集群的运行状况信息。
高可用模块103,即图中的FitOS HaStack,用于对所有的计算节点装置进行高可用管理。
管理网络200被划分为三大网络平面,分别是管理网络平面201、存储网络平面202、业务网络平面203。
管理网络平面201,用于对接管理端装置,用于提供管理服务。
存储网络平面202,用于对接后端的共享存储装置,用于提供存储服务。
业务网络平面203,用于对接计算节点装置,用于提供云计算虚拟机VM的访问服务。
所有的节点都连接在三大平面上,集群管理模块102,即图中的Etcd分别对应各个平面组建对应的集群。
每个计算节点装置300除安装有虚拟机VM301,即图中的VM之外,还具有Nova-compute计算机模块302、Libvirt管理模块303、Lock管理模块304、高可用计算节点模块305。
Nova-compute计算机模块302,即图中的Nova-compute,用于直接响应管理端装置各管理进程来控制云计算虚拟机VM的运行状态,并与Hypervisor API进行通信。
Libvirt管理模块303,即图中Libvirt,用于在KVM上提供标准的Hypervisor API接口的管理进程。
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-compute计算机模块302运行就,设置在计算节点装置300中,用于响应控制节点各管理进程,是虚拟机生命周期管理操作的真正执行者,直接负责与Hypervisor进行各种通信。
HaStack-agent,本发明创新的组件,与nova-compute进程结合使用,由高可用计算节点模块305运行,设置在计算节点装置300中,主要负责挂载共享目录,上报本节点锁心跳状态,并配合HaStack组件完成部分HA动作的管理功能。
Libvirt,设置在计算节点装置300中,由Libvirt管理模块303运行,在虚拟机VM之上提供标准的Hypervisor API接口的管理进程。
Lock,由Lock管理模块304运行,设置在计算节点装置300中,与libvirt组件配合,位于共享存储装置500的架构上层,完成各种锁心跳的更新与监控。用于提供分布式读写锁,来控制和管理对同一存储的并发写入。本实施例中创新的Lock模块,是参考原生Lock功能而新发明的分布式读写锁管理器。也可根据需要,使用原生Lock模块,或对原生Lock进行适应性二次开发。
共享存储系统,由共享存储装置400运行,采用的软件程序包括CephFS、NFS,提供共享文件系统存储。
如图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运行。
实施例2
在实施例1-2的基础上,如图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请求。
实施例3
在实施例1的基础上,如图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。
实施例4
在实施例1-3的基础上,如图5所示,由于Lock大量数据是存储在内存中的,未做持久化。因此如果Lock模块/进程异常重启后,原来所有挂载在锁空间下的所有资源均会被清空,这种情况会导致原虚拟机VM全部脱管,此时需要由Lock管理模块进程重启后恢复,该恢复过程包括以下操作:
操作D-1,在Libvirt管理模块启动时,通过Lock管理模块注册并获取锁心跳,如注册失败则转到操作D-2。
具体就是,Libvirt在启动时通过Lock注册并获取锁心跳,一旦失败则转到操作D-2。
操作D-2,一旦锁心跳注册失败,则kill关闭该计算节点装置的虚拟机VM。
操作D-3,Libvirt管理模块记录所有被kill关闭虚拟机VM的计算节点装置,并记录在Fencing log文件中。
操作D-4,定期检查Fencing log文件,发现有更新则转到操作D-5。
具体就是,HaStack-agent定期检查节点上的Fencing log,一旦发现有更新则转到操作D-5。
操作D-5,向管理端装置上报所有计算节点装置的Fencing log文件,若上报失败,则此次处理结束,留待下次上报;否则,上报给管理端装置后,由管理端装置发出指示进行恢复。
具体就是,HaStack-agent向HaStack上报所有Fencing log,若上报失败,则此次处理结束,留待下次上报。
实施例5
在实施例4的基础上,其中,在上报给管理端装置后,管理端装置进行以下的具体操作:
操作D-6,管理端装置收到agent计算节点装置上报的Fencing log文件,判断是否要进行自动处理,若自动处理转向操作D-8,若无需自动处理,转向操作D-7。
具体就是,HaStack收到agent上报的Fencing log,根据提前配置好的处理开关,确定是否要进行自动处理:若自动处理转向操作D-8,若无需自动处理,转向操作D-7。
操作D-7,管理端装置告警待由人工处理。
具体就是,HaStack不自动恢复所有Fencing虚拟机,只上报告警,交由后续管理员手动恢复。
操作D-8,管理端装置自动处理被Fencing的虚拟机VM,调用Nova接口控制虚拟机VM再次恢复运行。
具体就是,HaStack需要自动处理Fencing虚拟机,会逐个调用Nova接口触发HA恢复流程。
实施例6
进一步的,在上述实施例1-5的基础上,虚拟机VM具有VM GuestOS操作系统,该操作系统在Fencing后进行以下的恢复操作:
操作E-1,VM GuestOS中的Qga与计算节点装置的高可用计算节点模块持续保持锁心跳,当虚拟机VM出现故障时,转到操作E-2。
具体就是,VM GuestOS中的Qga会与计算节点的HaStack-agent持续保持心跳,一旦当虚拟机内蓝屏或卡死时,转到操作E-2。
操作E-2,当高可用计算节点模块接收到异常事件的报告时,上报给管理端装置。
具体就是,当HaStack-agent接收到异常事件时,会立即上报给HaStack。
操作E-3,管理端装置收到异常事件的报告后,直接调用Nova接口控制虚拟机VM再次恢复运行。
具体就是,HaStack收到虚拟机VM内部异常事件后,直接向Nova下发HA命令,触发HA恢复。
实施例7
如图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运行。
实施例8
在实施例7提供的方法的基础上,如图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请求。
实施例9
如图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。
实施例10
在实施例9的基础上,Lock管理模块的进程重启后恢复的过程包括以下操作:
操作D-1,在Libvirt管理模块启动时,通过Lock管理模块注册并获取锁心跳,如注册失败则转到S2;
操作D-2,一旦锁心跳注册失败,则kill关闭该计算节点装置的虚拟机VM;
操作D-3,Libvirt管理模块记录所有被kill关闭虚拟机VM的计算节点装置,并记录在Fencing log文件中;
操作D-4,定期检查Fencing log文件,发现有更新则转到操作D-5;
操作D-5,向管理端装置上报所有计算节点装置的Fencing log文件,若上报失败,则此次处理结束,留待下次上报;否则,上报给管理端装置后,由管理端装置发出指示进行恢复。
实施例11
在实施例9、10的基础上,在Fencing后进行以下的恢复操作:
操作E-1,VM GuestOS中的Qga与计算节点装置的高可用计算节点模块持续保持锁心跳,当虚拟机VM出现故障时,转到操作E-2;
操作E-2,当高可用计算节点模块接收到异常事件的报告时,上报给管理端装置;
操作E-3,管理端装置收到异常事件的报告后,直接调用Nova接口控制虚拟机VM再次恢复运行。
故障包括虚拟机VM运行所在的计算节点装置蓝屏或卡死、死机。
实施例的作用与效果
本发明基于原生OpenStack版本进行了二次开发,通过对几种关键技术进行整合,在OpenStack外围自主开发了一套独立的防脑裂的OpenStack虚拟机高可用系统。摆脱了传统HA方案中对IPMI平面探测/硬件狗等依赖,实现了电信级可靠性的完整虚拟机高可用(HA)技术方,为此本发明中提供了一种改进的防脑裂的OpenStack虚拟机高可用管理端装置及管理方法,用于实现管理端装置即作为server服务器的控制节点的高可用性。
在云计算系统中,脑裂(split-brain),指在一个高可用(HA)系统中,当联系着的两个控制节点或计算节点断开联系时,本来为一个整体的系统,分裂为两个独立节点,这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏,通过本发明的改进所提供的改进的防脑裂的OpenStack虚拟机高可用管理端装置及管理方法即可以解决这个问题。
根据实施例提供的防脑裂的OpenStack虚拟机高可用管理端装置,因为具有高可用模块,其能够运行高可用管理的方法,通过A-1到A-6的一系列操作,实时检测连接的计算节点装置以及共享存储装置的状态,根据获知的异常状态的类型:计算节点装置的异常还是共享存储装置的异常,具体的是管理网络中的管理网络平面、存储网络平面、业务网络平面哪一部分的异常,并判断后决定是否进行Fencing操作来关闭对应出现异常的计算节点装置的虚拟机VM,从而保证系统中的计算节点装置的虚拟机VM的高可用性。
通过锁心跳来禁止多个虚拟机同时写磁盘,从根本上解决“脑裂”的发生。
将Lock分布式读写锁的锁保护力度,由计算节点装置的主机级别细化到虚拟机VM级别,能够针对单个虚拟机进行并发读写保护。
通过自主发明的全流程的VM Fencing保护机制,防止由于共享存储装置异常等故障影响底层锁心跳而导致的虚拟机被异常终止。
过程中,采用异步通知机制,解决Lock重启导致的HA VM的脱管问题,实现了自动恢复。
进一步,独立于原生OpenStack,自主开发的HaStack服务,用于管理HA整个调度,HaStack通过集成Etcd及Qga,实现了对下层全主机的管理网络三平面(管理网络平面、业务网络平面、存储网络平面)的健康状态,及虚拟机VM内部运行状态的精确感知:
1.通过调整心跳打点周期与消息来快速确认计算节点装置物理平面的各故障点,提供高精度的判断依据供HaStack决策。
2.针对单个计算节点装置管理网络三平面的各类异常,通过可配置的HA故障对应处理的方案,支持用户对对应的方案进行自设置的定制化HA恢复策略。
3.通过集成Qga来进行虚拟机VM健康监测,一旦发生虚拟机VM内部蓝屏、卡死等故障则立刻触发HA恢复,实现自愈。
4.针对各种集群、存储、网络连线异常,均添加了相应的保护机制。
上述实施方式为本发明的优选案例,并不用来限制本发明的保护范围。
Claims (8)
1.一种防脑裂的OpenStack虚拟机高可用管理端装置,通过管理网络和连接有共享存储装置的计算节点装置连接,该计算节点装置安装有虚拟机VM,其特征在于:
至少两个所述管理端装置之间能通过管理网络进行通信而组成管理集群,
每个管理端装置包括:
Nova模块,包括Nova原生的虚拟机VM管理进程,用于对虚拟机VM的生命周期进行管理操作;
集群管理模块,用于收集所述集群的运行状况信息;以及
高可用模块,用于对所有的所述计算节点装置进行高可用管理,
其中,所述高可用模块运行高可用管理的方法,该方法包括以下操作:
操作A-1,通过所述集群管理模块收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作A-2;
操作A-2,检查各个所述计算节点装置通过管理网络上报的状态,如果正常,则此轮检查终止,否则转到下一步操作A-3;
操作A-3,根据每个所述计算节点装置通过管理网络上报的异常状态,逐个判断是否需要进行处理,如果无需处理,则该计算节点装置异常处理结束,转回上一步操作A-2;否则转到下一步操作A-4;
操作A-4,对于需要处理的异常状态的所述计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,通过所述Nova模块控制该计算节点装置上运行的所述虚拟机VM不运行,并结束,否则,转到下一步操作A-5;
操作A-5,向所连接的共享存储装置状态正常的所述计算节点装置下发隔离请求;
操作A-6,向所述Nova模块下发命令,触发该计算节点装置上运行的所述虚拟机VM运行;
其中,当管理端装置向所连接的共享存储装置状态正常的所述计算节点装置下发隔离请求后,所述高可用模块还运行以下操作:
操作B-1,持续监听所述计算节点装置上报的隔离事件,一旦收到消息则转到操作B-2;
操作B-2,通过所述集群管理模块收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作B-3;
操作B-3,检查各个所述计算节点装置通过管理网络上报的网络状态,如果正常,则此轮检查终止,否则转到操作B-4;
操作B-4,根据每个所述计算节点装置通过管理网络上报的异常状态,判断是否需要进行处理,如果无需处理,则进行操作B-6;否则转到操作B-5;
操作B-5,对于需要处理的异常状态的所述计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,无需隔离并转到操作B-6,并结束,否则,转到操作B-7;
操作B-6,针对无需隔离的场景,向对应的所述计算节点装置下发停止隔离请求;
操作B-7,针对需要隔离的场景,向对应的所述计算节点装置下发执行隔离请求。
2.根据权利要求1所述的管理端装置,其特征在于:
其中,所述虚拟机VM管理进程包括Nova-api、Nova-conductor或Nova-scheduler。
3.根据权利要求1所述的管理端装置,其特征在于:
其中,所述集群管理模块包括Etcd或Consul。
4.根据权利要求1所述的管理端装置,其特征在于:
其中,所述共享存储装置为CephFS或NFS文件管理程序管理运行。
5.根据权利要求1所述的管理端装置,其特征在于:
其中,所述管理网络包括:
管理网络平面,用于对接所述管理端装置,用于提供管理服务;
存储网络平面,用于对接后端的所述共享存储装置,用于提供存储服务;
业务网络平面,用于对接所述计算节点装置,用于提供云计算虚拟机VM的访问服务。
6.根据权利要求5所述的管理端装置,其特征在于:
其中,当所述管理网络的管理网络平面、存储网络平面以及业务网络平面均正常时,操作A-2中所述计算节点装置通过管理网络上报的网络状态才判断为正常,否则根据异常的所述计算节点装置的具体中断类型是管理网络平面、存储网络平面以及业务网络平面中的哪一种或几种进行相应的处理。
7.根据权利要求1所述的管理端装置,其特征在于:
其中,其中,所述管理网络包括:
管理网络平面,用于对接所述管理端装置,用于提供管理服务;
存储网络平面,用于对接后端的所述共享存储装置,用于提供存储服务;
业务网络平面,用于对接所述计算节点装置,用于提供虚拟机VM的访问服务,
对应的,当所述管理网络的管理网络平面、存储网络平面以及业务网络平面均正常时,操作B-3中所述计算节点装置通过管理网络上报的网络状态才判断为正常,否则根据异常的所述计算节点装置的具体中断类型是管理网络平面、存储网络平面以及业务网络平面中的哪一种或几种进行相应的隔离处理。
8.防脑裂的OpenStack虚拟机高可用的管理端装置的管理方法,包括以下操作:
操作A-1,通过收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作A-2;
操作A-2,检查各个计算节点装置通过管理网络上报的状态,如果正常,则此轮检查终止,否则转到下一步操作A-3;
操作A-3,根据每个所述计算节点装置通过管理网络上报的异常状态,逐个判断是否需要进行处理,如果无需处理,则该计算节点装置异常处理结束,转回上一步操作A-2;否则转到下一步操作A-4;
操作A-4,对于需要处理的异常状态的所述计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,通过Nova模块控制该计算节点装置上运行的虚拟机VM不运行,并结束,否则,转到下一步操作A-5;
操作A-5,向所连接的共享存储装置状态正常的所述计算节点装置下发隔离请求;
操作A-6,向所述Nova模块下发命令,触发该计算节点装置上运行的所述虚拟机VM运行;
其中,向所连接的共享存储装置状态正常的所述计算节点装置下发隔离请求后,还运行以下操作:
操作B-1,持续监听所述计算节点装置上报的隔离事件,一旦收到消息则转到操作B-2;
操作B-2,通过收集的运行状况信息检查集群状态是否正常,如果异常,则触发集群异常告警并结束,如果正常,则转到操作B-3;
操作B-3,检查各个所述计算节点装置通过管理网络上报的网络状态,如果正常,则此轮检查终止,否则转到操作B-4;
操作B-4,根据每个所述计算节点装置通过管理网络上报的异常状态,判断是否需要进行处理,如果无需处理,则进行操作B-6;否则转到操作B-5;
操作B-5,对于需要处理的异常状态的所述计算节点装置,检查与之连接的共享存储装置的状态,当共享存储装置异常时,无需隔离并转到操作B-6,并结束,否则,转到操作B-7;
操作B-6,针对无需隔离的场景,向对应的所述计算节点装置下发停止隔离请求;
操作B-7,针对需要隔离的场景,向对应的所述计算节点装置下发执行隔离请求。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811475904.4A CN109634716B (zh) | 2018-12-04 | 2018-12-04 | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 |
PCT/CN2018/121648 WO2020113668A1 (zh) | 2018-12-04 | 2018-12-18 | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 |
BR112020004404-0A BR112020004404A2 (pt) | 2018-12-04 | 2018-12-18 | dispositivo terminal de gerenciamento de alta disponibilidade, e, método de gerenciamento de um dispositivo terminal de gerenciamento. |
PH12020550049A PH12020550049A1 (en) | 2018-12-04 | 2020-02-07 | High-availability management end device and management method of OpenStack virtual machine for preventing split-brain |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811475904.4A CN109634716B (zh) | 2018-12-04 | 2018-12-04 | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109634716A CN109634716A (zh) | 2019-04-16 |
CN109634716B true CN109634716B (zh) | 2021-02-09 |
Family
ID=66071111
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811475904.4A Active CN109634716B (zh) | 2018-12-04 | 2018-12-04 | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 |
Country Status (4)
Country | Link |
---|---|
CN (1) | CN109634716B (zh) |
BR (1) | BR112020004404A2 (zh) |
PH (1) | PH12020550049A1 (zh) |
WO (1) | WO2020113668A1 (zh) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110134518B (zh) * | 2019-05-21 | 2023-09-01 | 浪潮软件集团有限公司 | 一种提高大数据集群多节点应用高可用性的方法及系统 |
CN110297690A (zh) * | 2019-06-28 | 2019-10-01 | 深圳前海微众银行股份有限公司 | 基于云计算的虚拟机使用方法、装置、设备及可读存储介质 |
CN112398668B (zh) * | 2019-08-14 | 2022-08-23 | 北京东土科技股份有限公司 | 一种基于IaaS集群的云平台和节点的切换方法 |
CN110825487B (zh) * | 2019-09-19 | 2022-07-15 | 烽火通信科技股份有限公司 | 一种虚拟机防脑裂的管理方法及主服务器 |
CN111212127A (zh) * | 2019-12-29 | 2020-05-29 | 浪潮电子信息产业股份有限公司 | 一种存储集群及业务数据的维护方法、装置和存储介质 |
CN111240895A (zh) * | 2019-12-31 | 2020-06-05 | 深圳证券通信有限公司 | 一种面向OpenStack的节点批量备份系统的方法 |
CN113821301A (zh) * | 2021-08-29 | 2021-12-21 | 济南浪潮数据技术有限公司 | 一种虚拟机开启方法、系统、存储介质及设备 |
CN113535336A (zh) * | 2021-09-16 | 2021-10-22 | 深圳创新科技术有限公司 | 一种Cloudstack在国产服务器的部署运行方法及装置 |
CN114090184B (zh) * | 2021-11-26 | 2022-11-29 | 中电信数智科技有限公司 | 一种虚拟化集群高可用性的实现方法和设备 |
CN115811461B (zh) * | 2023-02-08 | 2023-04-28 | 湖南国科亿存信息科技有限公司 | San共享存储集群脑裂预防处理方法、装置及电子设备 |
CN116382850B (zh) * | 2023-04-10 | 2023-11-07 | 北京志凌海纳科技有限公司 | 一种利用多存储心跳检测的虚拟机高可用管理装置及系统 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8874954B1 (en) * | 2012-10-19 | 2014-10-28 | Symantec Corporation | Compatibility of high availability clusters supporting application failover with shared storage in a virtualization environment without sacrificing on virtualization features |
CN103684941B (zh) * | 2013-11-23 | 2018-01-16 | 广东中兴新支点技术有限公司 | 基于仲裁服务器的集群裂脑预防方法和装置 |
CN104253860B (zh) * | 2014-09-11 | 2017-08-08 | 武汉噢易云计算股份有限公司 | 一种基于共享存储消息队列的虚拟机高可用实现方法 |
CN107239383A (zh) * | 2017-06-28 | 2017-10-10 | 郑州云海信息技术有限公司 | 一种OpenStack虚拟机的故障监控方法及装置 |
CN107885576A (zh) * | 2017-10-16 | 2018-04-06 | 北京易讯通信息技术股份有限公司 | 一种基于OpenStack的私有云中虚拟机HA的方法 |
-
2018
- 2018-12-04 CN CN201811475904.4A patent/CN109634716B/zh active Active
- 2018-12-18 BR BR112020004404-0A patent/BR112020004404A2/pt not_active IP Right Cessation
- 2018-12-18 WO PCT/CN2018/121648 patent/WO2020113668A1/zh active Application Filing
-
2020
- 2020-02-07 PH PH12020550049A patent/PH12020550049A1/en unknown
Also Published As
Publication number | Publication date |
---|---|
CN109634716A (zh) | 2019-04-16 |
PH12020550049A1 (en) | 2020-10-12 |
WO2020113668A1 (zh) | 2020-06-11 |
BR112020004404A2 (pt) | 2021-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109634716B (zh) | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 | |
CN109684032B (zh) | 防脑裂的OpenStack虚拟机高可用计算节点装置及管理方法 | |
CN109614201B (zh) | 防脑裂的OpenStack虚拟机高可用系统 | |
US11288130B2 (en) | Container-based application data protection method and system | |
US10621005B2 (en) | Systems and methods for providing zero down time and scalability in orchestration cloud services | |
US11108859B2 (en) | Intelligent backup and recovery of cloud computing environment | |
US11216220B2 (en) | Resolving failed or hanging mount points in a clustered storage solution for containers | |
US10509686B2 (en) | Distributable computational units in a continuous computing fabric environment | |
US8874954B1 (en) | Compatibility of high availability clusters supporting application failover with shared storage in a virtualization environment without sacrificing on virtualization features | |
US9652326B1 (en) | Instance migration for rapid recovery from correlated failures | |
US11706080B2 (en) | Providing dynamic serviceability for software-defined data centers | |
US9703651B2 (en) | Providing availability of an agent virtual computing instance during a storage failure | |
US20220269414A1 (en) | Snapshotting a containerized application | |
US8990608B1 (en) | Failover of applications between isolated user space instances on a single instance of an operating system | |
EP3591530B1 (en) | Intelligent backup and recovery of cloud computing environment | |
US20180157513A1 (en) | Identifying entities in a virtualization environment | |
US20150067401A1 (en) | Computer recovery method, computer system, and storage medium | |
JP6828558B2 (ja) | 管理装置、管理方法及び管理プログラム | |
US10454773B2 (en) | Virtual machine mobility | |
RU2788309C1 (ru) | Способ централизованного реагирования на отказ сети или отказ сервера в кластере высокой доступности и восстановления виртуальной машины в кластере высокой доступности и система, реализующая данный способ | |
US20240289027A1 (en) | Automated SSD Recovery | |
JP2022007301A (ja) | 復旧制御装置及び復旧制御方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |