CN104090832A - 云计算平台的高可用性支撑装置及方法 - Google Patents
云计算平台的高可用性支撑装置及方法 Download PDFInfo
- Publication number
- CN104090832A CN104090832A CN201410319372.0A CN201410319372A CN104090832A CN 104090832 A CN104090832 A CN 104090832A CN 201410319372 A CN201410319372 A CN 201410319372A CN 104090832 A CN104090832 A CN 104090832A
- Authority
- CN
- China
- Prior art keywords
- hypervisor
- availability
- main frame
- high availability
- cloud computing
- 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.)
- Pending
Links
Landscapes
- Hardware Redundancy (AREA)
Abstract
本发明提供了一种云计算平台的高可用性支撑装置,包括:检测单元,用于检测VM的可用性和hypervisor主机失败的情况;启动单元,用于根据检测结果,对出现故障的VM或者hypersoir进行重启;手动干预单元,用于根据启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。本发明还提供了一种云计算平台的高可用性支撑方法。通过本发明的技术方案,可以在现有的云计算平台的高可用性支撑方式基础上,充分利用单对象类型完成多对象类型的云计算平台的高可用性支撑,建立复杂对象参与的云计算平台的高可用性支撑的通用、统一支撑思路。
Description
技术领域
本发明涉及计算机技术领域,具体地,涉及一种云计算平台的高可用性支撑装置和一种云计算平台的高可用性支撑方法。
背景技术
云管理平台的核心是通过虚拟化整合计算资源、存储资源、网络资源。建立统一的资源管理中心,实现资源、数据库、机房管理等传统数据中心的统一管理,通过云计算技术构建虚拟数据中心,转型为IAAS服务。其根本在于对资源的虚拟化。
因为云计算架构下,涉及多个业务系统及多个虚拟服务,因此对系统的高可用性,负载均衡,数据安全提出了更高的要求。
从传统意义上来讲,UNIX和Linux平台承担着大部分高可用性(HA)的工作。存储层包括RAID阵列、网络层多层网络配置;操作系统包括HA特性,这能确保应用的正常运行。当然,在应用层也包括一些HA工作负载:研发人员在HA特性中加入了对集群的支持功能。
当企业客户迁移至更加虚拟的基础架构,如私有云或虚拟数据中心,HA仍处于基础架构层而非应用层。虚拟层也许包括一些HA支持,但是它仍是基础架构的一部分。
目前,广泛使用的系统高可用性技术核实是负载均衡、主机HA、存储BCV、SRDF、数据库RAC、应用系统应急方案等。基于以上技术,在IT系统中建设了各种高可用性系统,如:双机系统、RAC系统和灾备系统等。这些系统对IT系统的服务保障能力提高了一个等级,但是在IT系统发生重大灾难或者数据库出现崩溃时,或出现重大的业务灾难。以上方案均不能保证兼顾保障较高的RTO和QOS。
如何基于先进的云计算技术,实现更高的RTO及QOS,是目前亟需解决的问题。
因此,需要一种新的云计算平台的高可用性支撑技术,可以在现有的云计算平台的高可用性支撑方式基础上,充分利用单对象类型完成多对象类型的云计算平台的高可用性支撑,建立复杂对象参与的云计算平台的高可用性支撑的通用、统一支撑思路。
发明内容
本发明正是基于上述问题,提出了一种新的云计算平台的高可用性支撑技术,可以在现有的云计算平台的高可用性支撑方式基础上,充分利用单对象类型完成多对象类型的云计算平台的高可用性支撑,建立复杂对象参与的云计算平台的高可用性支撑的通用、统一支撑思路。
有鉴于此,本发明提出了一种云计算平台的高可用性支撑装置,包括:检测单元,用于检测VM的可用性和hypervisor主机失败的情况;启动单元,用于根据所述检测单元的检测结果,对出现故障的VM或者hypersoir进行重启;手动干预单元,用于根据所述启动单元的启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。在该技术方案中,采用云计算虚拟化中对VM的高可用性扩展支持技术,自动发现发生故障的VM,并且自动根据策略进行VM的重启或重建,可以提高虚拟化计算资源在业务系统中的可用能力,适用于在同一个数据中心下VM及hypervisor主机的故障恢复。
在上述技术方案中,优选地,所述检测单元,具体包括:高可用性特性启动模块,用于启用资源的高可用性特性,使该资源成为系统的高可用性管理;监控指标及阈值规划模块,用于定义资源的监控指标,并设置阀值;实时监控模块,用于当应用运行时,监控模块将根据应用监控模板所指定的监控指标,时刻对监控对象进行监控;高可用性机制触发模块,用于当应用的运行状态达到监控指标定义的阀值或失去连接后,触发高可用性机制。在该技术方案中,通过定义监控指标和设置阈值,可以,可以在监控对象达到阈值时触发高可用性,提高系统安全性。
在上述技术方案中,优选地,所述高可用性特性启动模块启用的资源,包括VM及Hypervisor;和/或,所述监控指标及阈值规划模块定义的监控指标,包括VM及Hypervisor的监控指标和监控模块所监控的指标;所述VM及Hypervisor的监控指标包括对监控对象健康状态的重要监控项,所述监控模块所监控的指标包括CPU、内存和并发人数;和/或,所述监控指标及阈值规划模块设置的阈值,包括指标所对应的状态,即达到该状态时,启动自动重置机制。
在上述技术方案中,优选地,所述启动单元,具体包括:VM失败检测模块,用于检测VM失败,即高可用性机制,不断根据预设的时间间隔检测VM状态更改,并检测失败的hypervisor上的虚拟机;在检测到相应的变化时,高可用性机制立即重新启动虚拟机;Hypersior主机故障检测模块,用于检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障,在检测到故障时,根据故障类型重新启动hypervisor主机和特定hypervisor主机上的VM。在该技术方案中,通过引入监控及自动重启机制,对监控数据的统计分析,可以达到资源的可用能力。
在上述技术方案中,优选地,所述Hypersior主机故障检测模块重新启动hypervisor主机和特定hypervisor主机上的VM时根据的故障类型,包括hypervisor主机丢失及连接失败的hypervisor主机。
根据本发明的又一个方面,还提出了一种云计算平台的高可用性支撑方法,包括:步骤202:检测VM的可用性和hypervisor主机失败的情况;步骤204:根据所述步骤202的检测结果,对出现故障的VM或者hypersoir进行重启;步骤206:根据所述步骤204的启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。在该技术方案中,采用云计算虚拟化中对VM的高可用性扩展支持技术,自动发现发生故障的VM,并且自动根据策略进行VM的重启或重建,可以提高虚拟化计算资源在业务系统中的可用能力,适用于在同一个数据中心下VM及hypervisor主机的故障恢复。
在上述技术方案中,优选地,所述步骤202,具体包括:步骤302:启用资源的高可用性特性,使该资源成为系统的高可用性管理;步骤304:定义资源的监控指标,并设置阀值;步骤306:当应用运行时,监控模块将根据应用监控模板所指定的监控指标,时刻对监控对象进行监控;步骤308:当应用的运行状态达到监控指标定义的阀值或失去连接后,触发高可用性机制。在该技术方案中,通过定义监控指标和设置阈值,可以,可以在监控对象达到阈值时触发高可用性,提高系统安全性。
在上述技术方案中,优选地,所述步骤302启用的资源,包括VM及Hypervisor;和/或,所述步骤304定义的监控指标,包括VM及Hypervisor的监控指标和监控模块所监控的指标;所述VM及Hypervisor的监控指标包括对监控对象健康状态的重要监控项,所述监控模块所监控的指标包括CPU、内存和并发人数;和/或,所述步骤304设置的阈值,包括指标所对应的状态,即达到该状态时,启动自动重置机制。
在上述技术方案中,优选地,所述步骤204,具体包括:步骤402:检测VM失败,即高可用性机制,不断根据预设的时间间隔检测VM状态更改,并检测失败的hypervisor上的虚拟机;在检测到相应的变化时,高可用性机制立即重新启动虚拟机;步骤404:检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障,在检测到故障时,根据故障类型重新启动hypervisor主机和特定hypervisor主机上的VM。在该技术方案中,通过引入监控及自动重启机制,对监控数据的统计分析,可以达到资源的可用能力。
在上述技术方案中,优选地,所述步骤404重新启动hypervisor主机和特定hypervisor主机上的VM时根据的故障类型,包括hypervisor主机丢失及连接失败的hypervisor主机。
通过以上技术方案,可以在现有的云计算平台的高可用性支撑方式基础上,充分利用单对象类型完成多对象类型的云计算平台的高可用性支撑,建立复杂对象参与的云计算平台的高可用性支撑的通用、统一支撑思路。
附图说明
图1示出了根据本发明的实施例的云计算平台的高可用性支撑装置的框图;
图2示出了根据本发明的实施例的云计算平台的高可用性支撑方法的流程图;
图3示出了根据本发明的实施例的检测单元的流程图;
图4示出了根据本发明的实施例的启动单元的流程图;
图5示出了根据本发明的实施例的云计算平台的高可用性支撑方法的详细流程图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是,本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明的保护范围并不受下面公开的具体实施例的限制。
图1示出了根据本发明的实施例的云计算平台的高可用性支撑装置的框图。
如图1所示,根据本发明的实施例的服务建模装置100,包括:检测单元102,用于检测VM的可用性和hypervisor主机失败的情况;启动单元104,用于根据检测单元的检测结果,对出现故障的VM或者hypersoir进行重启;手动干预单元106,用于根据启动单元的启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。在该技术方案中,采用云计算虚拟化中对VM的高可用性扩展支持技术,自动发现发生故障的VM,并且自动根据策略进行VM的重启或重建,可以提高虚拟化计算资源在业务系统中的可用能力,适用于在同一个数据中心下VM及hypervisor主机的故障恢复。
在上述技术方案中,优选地,检测单元102,具体包括:高可用性特性启动模块1022,用于启用资源的高可用性特性,使该资源成为系统的高可用性管理;监控指标及阈值规划模块1024,用于定义资源的监控指标,并设置阀值;实时监控模块1026,用于当应用运行时,监控模块将根据应用监控模板所指定的监控指标,时刻对监控对象进行监控;高可用性机制触发模块1028,用于当应用的运行状态达到监控指标定义的阀值或失去连接后,触发高可用性机制。在该技术方案中,通过定义监控指标和设置阈值,可以,可以在监控对象达到阈值时触发高可用性,提高系统安全性。
在上述技术方案中,优选地,高可用性特性启动模块1022启用的资源,包括VM及Hypervisor;和/或,监控指标及阈值规划模块1024定义的监控指标,包括VM及Hypervisor的监控指标和监控模块所监控的指标;VM及Hypervisor的监控指标包括对监控对象健康状态的重要监控项,监控模块所监控的指标包括CPU、内存和并发人数;和/或,监控指标及阈值规划模块1024设置的阈值,包括指标所对应的状态,即达到该状态时,启动自动重置机制。
在上述技术方案中,优选地,启动单元104,具体包括:VM失败检测模块1042,用于检测VM失败,即高可用性机制,不断根据预设的时间间隔检测VM状态更改,并检测失败的hypervisor上的虚拟机;在检测到相应的变化时,高可用性机制立即重新启动虚拟机;Hypersior主机故障检测模块1044,用于检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障,在检测到故障时,根据故障类型重新启动hypervisor主机和特定hypervisor主机上的VM。在该技术方案中,通过引入监控及自动重启机制,对监控数据的统计分析,可以达到资源的可用能力。
在上述技术方案中,优选地,Hypersior主机故障检测模块1044重新启动hypervisor主机和特定hypervisor主机上的VM时根据的故障类型,包括hypervisor主机丢失及连接失败的hypervisor主机。
图2示出了根据本发明的实施例的云计算平台的高可用性支撑方法的流程图。
如图2所示,根据本发明的实施例的云计算平台的高可用性支撑方法,包括:步骤202:检测VM的可用性和hypervisor主机失败的情况;步骤204:根据步骤202的检测结果,对出现故障的VM或者hypersoir进行重启;步骤206:根据步骤204的启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。在该技术方案中,采用云计算虚拟化中对VM的高可用性扩展支持技术,自动发现发生故障的VM,并且自动根据策略进行VM的重启或重建,可以提高虚拟化计算资源在业务系统中的可用能力,适用于在同一个数据中心下VM及hypervisor主机的故障恢复。
在上述技术方案中,优选地,如图3所示,步骤202,具体包括:步骤302:启用资源的高可用性特性,使该资源成为系统的高可用性管理;步骤304:定义资源的监控指标,并设置阀值;步骤306:当应用运行时,监控模块将根据应用监控模板所指定的监控指标,时刻对监控对象进行监控;步骤308:当应用的运行状态达到监控指标定义的阀值或失去连接后,触发高可用性机制。在该技术方案中,通过定义监控指标和设置阈值,可以,可以在监控对象达到阈值时触发高可用性,提高系统安全性。
在上述技术方案中,优选地,步骤302启用的资源,包括VM及Hypervisor;和/或,步骤304定义的监控指标,包括VM及Hypervisor的监控指标和监控模块所监控的指标;VM及Hypervisor的监控指标包括对监控对象健康状态的重要监控项,监控模块所监控的指标包括CPU、内存和并发人数;和/或,步骤304设置的阈值,包括指标所对应的状态,即达到该状态时,启动自动重置机制。
在上述技术方案中,优选地,如图4所示,步骤204,具体包括:步骤402:检测VM失败,即高可用性机制,不断根据预设的时间间隔检测VM状态更改,并检测失败的hypervisor上的虚拟机;在检测到相应的变化时,高可用性机制立即重新启动虚拟机;步骤404:检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障,在检测到故障时,根据故障类型重新启动hypervisor主机和特定hypervisor主机上的VM。在该技术方案中,通过引入监控及自动重启机制,对监控数据的统计分析,可以达到资源的可用能力。
在上述技术方案中,优选地,步骤404重新启动hypervisor主机和特定hypervisor主机上的VM时根据的故障类型,包括hypervisor主机丢失及连接失败的hypervisor主机。
本发明的技术方案,以现有技术存在的缺陷为立足点,希望通过云计算虚拟化的先进便利性,解决传统IT系统中对高可用性支撑的不足,适用于云计算系统中虚拟机的高可用性;提出了一种云计算虚拟化中对VM的高可用性扩展支持技术,自动发现发生故障的VM,并且自动根据策略进行VM的重启或重建;该技术方案主要提高虚拟化计算资源在业务系统中的可用能力,仅适用于在同一个数据中心下VM及hypervisor主机的故障恢复。
本发明的技术方案主要包括以下几个阶段:
⑴ 检测:使用不同的方式来检测VM的可用性和hypervisor主机失败。
⑵ 启动:对出现故障的VM或者hypersoir进行重启。
⑶ 手动干预:当VM不能进行重启时,由系统管理员进行手动干预。
例如,参见图5,本发明的技术方案具体包括以下几个方面:
首先我们需要定义VM及Hypervisor的监控指标,该指标定义了对监控对象健康状态的重要监控项,需要定义了监控模块所监控的指标,例如CPU、内存、并发人数等,并设置阀值。
当应用运行时,监控模块将根据应用监控模板所指定的指标,时刻对监控对象进行监控,当应用的运行状态达到监控指标定义的阀值或失去连接后,将触发高可用性机制。
当触发了高可用性机制后,将根据计算资源,自动向系统发送重启指令。
当重启动作失败时,系统会通知管理员进行手动重启。
通过上述步骤,我们实现了对VM及Hypersior的监控,并提供高可用性机制。
又如,本发明技术方案的具体实现方式如下:
首先,我们需要启用资源高可用性特性,使该资源成为系统的高可用性管理。
其次,我们还需要确定资源的监控指标,以及指标所对应的状态,即达到该状态时,启动自动重置机制。
检测VM失败:高可用性机制不断检测VM状态更改,及检测失败的hypervisor上的虚拟机。状态变更的检测时间间隔执行的默认为1分钟。在检测到相应的变化时,高可用性机制立即重新启动虚拟机。
检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障。在检测到故障时重新启动hypervisor主机,以及特定hypervisor主机上的VM。这种检测必须区分hypervisor主机丢失及连接失败的hypervisor主机。Management主要通过ping命令,进行对hypervisor的监控。
当系统发现自动重启不成功时,将会通知管理员,由管理员进行手动处理。
本发明的技术方案,通过引入监控及自动重启机制,定义了监控指标,通过对监控数据的统计分析,触发高可用性,达到资源的可用能力。整个过程基本不需要人工干预,且能主动快速响应。
相比传统故障监测机制,需要人工的对资源状态进行监控,并且手工完成对资源状态的重置。本发明的技术方案实现了自动监控应用状态,自动完成资源重置 , 满足资源的高可用性,降低企业风险。
以上结合附图详细说明了本发明的技术方案,考虑到相关技术中没有简便的、统一的针对复杂类型云计算平台的高可用性支撑的解决办法。现有的云计算平台的高可用性支撑无法完成有复杂类型参与的云计算平台的高可用性支撑过程。因此,本发明提出了一种云计算平台的高可用性支撑装置和一种云计算平台的高可用性支撑方法,可以在现有的云计算平台的高可用性支撑方式基础上,充分利用单对象类型完成多对象类型的云计算平台的高可用性支撑,建立复杂对象参与的云计算平台的高可用性支撑的通用、统一支撑思路。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种云计算平台的高可用性支撑装置,其特征在于,包括:
检测单元,用于检测VM的可用性和hypervisor主机失败的情况;
启动单元,用于根据所述检测单元的检测结果,对出现故障的VM或者hypersoir进行重启;
手动干预单元,用于根据所述启动单元的启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。
2.根据权利要求1所述的云计算平台的高可用性支撑装置,其特征在于,所述检测单元,具体包括:
高可用性特性启动模块,用于启用资源的高可用性特性,使该资源成为系统的高可用性管理;
监控指标及阈值规划模块,用于定义资源的监控指标,并设置阀值;
实时监控模块,用于当应用运行时,监控模块将根据应用监控模板所指定的监控指标,时刻对监控对象进行监控;
高可用性机制触发模块,用于当应用的运行状态达到监控指标定义的阀值或失去连接后,触发高可用性机制。
3.根据权利要求2所述的云计算平台的高可用性支撑装置,其特征在于,所述高可用性特性启动模块启用的资源,包括VM及Hypervisor;
和/或,
所述监控指标及阈值规划模块定义的监控指标,包括VM及Hypervisor的监控指标和监控模块所监控的指标;所述VM及Hypervisor的监控指标包括对监控对象健康状态的重要监控项,所述监控模块所监控的指标包括CPU、内存和并发人数;
和/或,
所述监控指标及阈值规划模块设置的阈值,包括指标所对应的状态,即达到该状态时,启动自动重置机制。
4.根据权利要求1-3中任一项所述的云计算平台的高可用性支撑装置,其特征在于,所述启动单元,具体包括:
VM失败检测模块,用于检测VM失败,即高可用性机制,不断根据预设的时间间隔检测VM状态更改,并检测失败的hypervisor上的虚拟机;在检测到相应的变化时,高可用性机制立即重新启动虚拟机;
Hypersior主机故障检测模块,用于检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障,在检测到故障时,根据故障类型重新启动hypervisor主机和特定hypervisor主机上的VM。
5.根据权利要求4所述的云计算平台的高可用性支撑装置,其特征在于,所述Hypersior主机故障检测模块重新启动hypervisor主机和特定hypervisor主机上的VM时根据的故障类型,包括hypervisor主机丢失及连接失败的hypervisor主机。
6.一种云计算平台的高可用性支撑方法,其特征在于,包括:
步骤202:检测VM的可用性和hypervisor主机失败的情况;
步骤204:根据所述步骤202的检测结果,对出现故障的VM或者hypersoir进行重启;
步骤206:根据所述步骤204的启动结果,当VM不能进行重启或hypersoir重启失败时,通知系统管理员,由系统管理员进行手动干预。
7.根据权利要求6所述的云计算平台的高可用性支撑方法,其特征在于,所述步骤202,具体包括:
步骤302:启用资源的高可用性特性,使该资源成为系统的高可用性管理;
步骤304:定义资源的监控指标,并设置阀值;
步骤306:当应用运行时,监控模块将根据应用监控模板所指定的监控指标,时刻对监控对象进行监控;
步骤308:当应用的运行状态达到监控指标定义的阀值或失去连接后,触发高可用性机制。
8.根据权利要求7所述的云计算平台的高可用性支撑方法,其特征在于,所述步骤302启用的资源,包括VM及Hypervisor;
和/或,
所述步骤304定义的监控指标,包括VM及Hypervisor的监控指标和监控模块所监控的指标;所述VM及Hypervisor的监控指标包括对监控对象健康状态的重要监控项,所述监控模块所监控的指标包括CPU、内存和并发人数;
和/或,
所述步骤304设置的阈值,包括指标所对应的状态,即达到该状态时,启动自动重置机制。
9.根据权利要求6-8中任一项所述的云计算平台的高可用性支撑方法,其特征在于,所述步骤204,具体包括:
步骤402:检测VM失败,即高可用性机制,不断根据预设的时间间隔检测VM状态更改,并检测失败的hypervisor上的虚拟机;在检测到相应的变化时,高可用性机制立即重新启动虚拟机;
步骤404:检测Hypersior主机故障:高可用性机制检查hypervisor主机的故障,在检测到故障时,根据故障类型重新启动hypervisor主机和特定hypervisor主机上的VM。
10.根据权利要求9所述的云计算平台的高可用性支撑方法,其特征在于,所述步骤404重新启动hypervisor主机和特定hypervisor主机上的VM时根据的故障类型,包括hypervisor主机丢失及连接失败的hypervisor主机。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410319372.0A CN104090832A (zh) | 2014-07-07 | 2014-07-07 | 云计算平台的高可用性支撑装置及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410319372.0A CN104090832A (zh) | 2014-07-07 | 2014-07-07 | 云计算平台的高可用性支撑装置及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104090832A true CN104090832A (zh) | 2014-10-08 |
Family
ID=51638550
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410319372.0A Pending CN104090832A (zh) | 2014-07-07 | 2014-07-07 | 云计算平台的高可用性支撑装置及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104090832A (zh) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080244292A1 (en) * | 2007-03-30 | 2008-10-02 | Alok Kumar | Method and Apparatus to Re-create trust model after sleep state |
CN103139016A (zh) * | 2013-02-19 | 2013-06-05 | 浪潮电子信息产业股份有限公司 | 一种高可用集群资源监控的方法 |
CN103152419A (zh) * | 2013-03-08 | 2013-06-12 | 中标软件有限公司 | 一种云计算平台的高可用集群管理方法 |
CN103559108A (zh) * | 2013-11-11 | 2014-02-05 | 中国科学院信息工程研究所 | 一种基于虚拟化实现主备故障自动恢复的方法及系统 |
-
2014
- 2014-07-07 CN CN201410319372.0A patent/CN104090832A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080244292A1 (en) * | 2007-03-30 | 2008-10-02 | Alok Kumar | Method and Apparatus to Re-create trust model after sleep state |
CN103139016A (zh) * | 2013-02-19 | 2013-06-05 | 浪潮电子信息产业股份有限公司 | 一种高可用集群资源监控的方法 |
CN103152419A (zh) * | 2013-03-08 | 2013-06-12 | 中标软件有限公司 | 一种云计算平台的高可用集群管理方法 |
CN103559108A (zh) * | 2013-11-11 | 2014-02-05 | 中国科学院信息工程研究所 | 一种基于虚拟化实现主备故障自动恢复的方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI746512B (zh) | 實體機器故障分類處理方法、裝置和虛擬機器恢復方法、系統 | |
US8521703B2 (en) | Multiple node/virtual input/output (I/O) server (VIOS) failure recovery in clustered partition mobility | |
US8583773B2 (en) | Autonomous primary node election within a virtual input/output server cluster | |
US9753761B1 (en) | Distributed dynamic federation between multi-connected virtual platform clusters | |
TWI603266B (zh) | 虛擬機器之資源調整方法及系統 | |
US10404795B2 (en) | Virtual machine high availability using shared storage during network isolation | |
US9934105B2 (en) | Fault tolerance for complex distributed computing operations | |
US8949828B2 (en) | Single point, scalable data synchronization for management of a virtual input/output server cluster | |
US8667490B1 (en) | Active/active storage and virtual machine mobility over asynchronous distances | |
US8413144B1 (en) | Providing application-aware high availability of virtual machines | |
US9176834B2 (en) | Tolerating failures using concurrency in a cluster | |
WO2015169199A1 (zh) | 分布式环境下虚拟机异常恢复方法 | |
US8726083B1 (en) | Synchronized taking of snapshot memory images of virtual machines and storage snapshots | |
CN105159798A (zh) | 一种虚拟机的双机热备方法、双机热备管理服务器和系统 | |
CN106528327A (zh) | 一种数据处理方法以及备份服务器 | |
US9529656B2 (en) | Computer recovery method, computer system, and storage medium | |
CN103902401A (zh) | 基于监控的虚拟机容错方法及装置 | |
US20220300384A1 (en) | Enhanced fencing scheme for cluster systems without inherent hardware fencing | |
CN109284169B (zh) | 基于进程虚拟化的大数据平台进程管理方法及计算机设备 | |
CN105743696A (zh) | 一种云计算平台管理方法 | |
CN114363356B (zh) | 数据同步方法、系统、装置、计算机设备和存储介质 | |
US10223402B1 (en) | Multi-site block level write consistency | |
WO2022009438A1 (ja) | サーバメンテナンス制御装置、システム、制御方法及びプログラム | |
CN104090832A (zh) | 云计算平台的高可用性支撑装置及方法 | |
US10365934B1 (en) | Determining and reporting impaired conditions in a multi-tenant web services environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information |
Address after: 100094 Beijing city Haidian District North Road No. 68, UFIDA Software Park Applicant after: Yonyou Network Technology Co., Ltd. Address before: 100094 Beijing city Haidian District North Road No. 68, UFIDA Software Park Applicant before: UFIDA Software Co., Ltd. |
|
COR | Change of bibliographic data | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20141008 |
|
RJ01 | Rejection of invention patent application after publication |