CN107179957A - 物理机故障分类处理方法、装置和虚拟机恢复方法、系统 - Google Patents
物理机故障分类处理方法、装置和虚拟机恢复方法、系统 Download PDFInfo
- Publication number
- CN107179957A CN107179957A CN201610136817.0A CN201610136817A CN107179957A CN 107179957 A CN107179957 A CN 107179957A CN 201610136817 A CN201610136817 A CN 201610136817A CN 107179957 A CN107179957 A CN 107179957A
- Authority
- CN
- China
- Prior art keywords
- physical machine
- machine
- physical
- failure
- fault
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
- G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请实施例提供一种集群物理机故障分类处理方法、装置及虚拟机恢复方法、系统。所述物理机故障分类处理方法包括：从物理机故障信息存储中心获取物理机故障信息列表；若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。本申请实施例通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
Description
技术领域
本申请涉及通信技术领域，特别是涉及一种应用于虚拟化集群系统的物理机故障分类处理方法、装置及虚拟机恢复方法、系统。
背景技术
随着计算机技术的迅猛发展，人们开始越来越多的关注如何降低能耗和提高资源利用率，云计算模式应运而生。云计算将所有的计算机抽象成特定的计算资源，然后将这些计算资源提供给用户，而不是像传统那样直接提供一台或多台计算机。云计算模式最大的好处就是用户可以根据自己的需要来申请资源，避免不必要的资源浪费，提高资源利用率。
在云计算环境中，虚拟化集群技术是关键技术之一。虚拟化集群将多台虚拟化服务器组成为一个有机的整体，从而获得很高的计算速度，提升虚拟化系统整体的计算能力。虚拟化集群对多台服务器进行统一管理，通过虚拟化技术将物理资源抽象为存储、计算、网络等各种资源组成大的资源池，通过按需申请资源的方式提供虚拟机给用户。
随着虚拟化集群规模的逐渐扩大，由于集群内物理机软硬件问题导致物理机故障的概率也逐渐增大。物理机故障会直接影响其上所运行的虚拟机服务。为了保证虚拟机业务的正常运行，需要及时发现其所在的物理机故障并迅速处理以恢复虚拟机业务；否则，虚拟机用户会受到物理机故障的影响，无法保证业务的连续性。现有技术可以定时监控物理机状态，当发生物理机故障时，则会对其上的虚拟机进行关机，然后再开机操作；或者是关闭故障物理机，将其上的虚拟机迁移到集群内其他物理机上。
然而，物理机故障通常是由不同的原因而导致的，且物理机故障的现象也会有很多种，而现有技术并未对物理机故障进行精细划分，并未针对性的进行分类处理，因此在实际商业化用途中会存在较多的误判和漏判的情况，从而无法实现物理机故障后其上的虚拟机高可用(High Availability,HA)。
因此，如何更准确、高效、有针对性地进行物理机故障分类修复处理，成为亟需本领域技术人员解决的技术问题。
发明内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种应用于虚拟化集群系统的物理机机故障分类处理方法、装置及虚拟机恢复方法、系统。
本申请公开一种集群物理机故障分类处理方法，包括：
从物理机故障信息存储中心获取物理机故障信息列表；
若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
本申请还公开了一种集群物理机故障分类处理装置，包括：
获取模块，用于从物理机故障信息存储中心获取物理机故障信息列表；
第一处理模块，用于若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
第二处理模块，进一步包括：
关闭处理单元，用于若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；
迁移处理单元，用于通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
本申请还公开了一种虚拟机恢复方法，应用于虚拟化集群系统，所述方法包括：
虚拟化集群系统内的物理机自主检测自身的故障动态；
若自主检测到物理机自身能容错修复的软硬件故障，通过容错方式修复；
若自主检测到物理机自身能重启修复的软硬件故障，通过重启物理机方式修复；
从物理机故障信息存储中心获取物理机故障信息列表；
若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
相应的，本申请公开了一种虚拟机恢复系统，包括：
物理机故障修复装置，应用于虚拟化集群系统内的物理机上自主检测物理机自身的故障动态，若自主检测到物理机自身能容错修复的软硬件故障，通过容错方式修复；若自主检测到物理机自身能重启修复的软硬件故障，通过重启物理机方式修复；
物理机故障信息存储中心，用于将所有上报的物理故障信息汇集成物理机故障信息列表；
物理机故障分类处理装置，用于从所述物理机故障信息存储中心获取物理机故障信息列表，若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令，及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
此外，本申请实施例也同时考虑到大规模云计算集群内发生物理机规模故障情况的可能性，通过判断故障物理机的数量是否构成机房级别，并有针对性的采取不同的修复处理方式。尤其是针对大规模物理机故障的情况，采用人工处理的方式修复，从而有效避免由于故障物理机上的虚拟机的频繁迁移而影响系统性能情况的发生。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请的一种集群物理机故障分类处理方法实施例的步骤流程图；
图2是本申请的另一种集群物理机故障分类处理方法实施例的步骤流程图；
图3是本申请的一种虚拟机恢复方法实施例的步骤流程图；
图4是本申请的另一种虚拟机恢复方法实施例的步骤流程图；
图5是本申请的一种物理机故障修复装置实施例的结构框图；
图6是本申请的一种集群物理机故障分类处理装置实施例的结构框图；
图7是本申请的一种虚拟机恢复系统实施例的结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
为了方便理解本发明实施例，首先在此介绍本发明实施例描述中会涉及的几个要素：
A、云计算
云计算是一种基于互联网技术的相关服务的增加、使用和交付模式，是在所有使用的服务器上实践分布式计算的服务器集群。也就是说，云计算提供了一个虚拟化的按需动态供应硬件、软件和数据集的弹性资源平台。
B、虚拟集群
在云计算平台上进行集群管理就构成了虚拟集群。所谓的虚拟集群就是通过采用虚拟化技术来虚拟出多台计算节点，从而构建出与物理集群相似而且规模巨大的一个集群系统。也就是说，虚拟集群就是将那些协同完成特定任务的多台同构或异构的计算机连接起来的系统。
C、物理机
虚拟集群系统内协同完成特定任务的多台计算机即为集群物理计算机，简称集群物理机。其中，一台物理机上可以模拟出一台或者多台虚拟的计算机。
D、虚拟机
通过虚拟机软件可以在一台物理机上模拟出一台或者多台虚拟的计算机，而这些虚拟机就像真正的计算机那样进行工作，虚拟机上可以安装操作系统和应用程序，虚拟机还可访问网络资源。对于在虚拟机中运行的应用程序而言，虚拟机就像是在真正的计算机中进行工作。
本申请实施例可以应用在大规模的云计算虚拟化集群系统中，可以通过集群系统内的物理机自主检测自身的故障动态，进而对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；而对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
影响虚拟机运行和管理的物理机故障现象可以归纳如下几种：
1、物理机网络不通
其原因主要包括：物理机宕机、网卡异常、上联交换机故障、硬件异常、内核模块异常、物理机重启、网络分布式拒绝服务攻击(Distributed Denial ofService,DDoS)等。
2、物理机丢包
其原因主要包括：物理机负载高、上联网络设备切换、网络DdoS攻击等。
3、物理机硬件系统故障
例如，物理机磁盘、内存、中央处理器(Central Processing Unit，CPU)故障等。
4、物理机软件异常
例如，物理机的文件系统、虚拟化相关模块、操作系统内核模块等操作系统层面的软件异常等。
5、物理机远程访问通道不通
其原因主要包括：网络丢包、系统服务异常、文件系统异常等。
6、物理机性能异常
例如，可能表现为物理机输入输出(Input/Output，I/O)卡顿、负载高等。其原因主要包括：物理机硬件故障、物理机内核模块异常、物理机用户态进程异常等。
可以看出，以上物理机故障的现象并不是一成不变的，而是在一定时间内可以相互转化的，甚至是相关关联、相互交织的。并且，相同的物理机现象其背后的原因可能不一样，因此故障物理机的修复处理方式需要具体区分，例如，对于因网络DDoS攻击而导致的某台物理机网络不通与因物理机宕机而导致的物理机网络不通是需要区别对待的，如果在物理机正遭受网络DDoS攻击时将其上的虚拟机迁移至其他物理机，会产生骨牌效应，导致扩大故障风险，即其他物理机陆续被攻击而不可用，最终可能造成全集群网络设备的泛洪(flooding)，导致全集群物理机故障风险。
基于上述物理机故障现象和异常的深层原因分析，本发明实施例中，可以将物理机故障归纳为如下几类：
A、物理机自身能容错修复的软硬件故障类型
例如，存储数据的磁盘故障、虚拟化相关内核模块异常、存储数据的文件系统异常等。
B、物理机自身能重启修复的软硬件故障类型
例如，根文件系统只读等异常、网卡驱动重启可修复的异常、操作系统内核模块异常等。
C、物理机自身不能修复的软硬件故障类型
例如，物理机宕机、物理机CPU异常、物理机内存异常、物理机电源模块等各类硬件问题异常。
另外，还包括未知原因的故障类型，例如，系统负载类、系统网络类、硬件故障类等。这类故障虽然本质的原因比较难查，但是这类故障的现象却很明确，主要是：物理机网络丢包、物理机管理通道访问异常、物理机性能使用异常。
D、物理机遭受网络攻击而导致物理机故障类型
例如，网络DDoS类型安全攻击，从而造成网络大量丢包甚至网络不通。这类故障的现象主要包括：物理机网络不通、网络丢包、管理通道不通等。
因此，本申请实施例通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。例如，本申请实施例可以在十几分钟内处理完成故障物理机上的虚拟机恢复且该虚拟机的功能具备超过99.95％的商用可用性标准。
实施例一
参照图1，示出了本申请的一种集群物理机故障分类处理方法实施例的步骤流程图，所述物理机故障分类处理方法可以应用于虚拟化集群系统，具体可以包括如下步骤：
步骤210，从物理机故障信息存储中心获取物理机故障信息列表；
需要说明的是，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
步骤220，若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
可以理解的是，在实际应用中，所述集群外部的安全攻击防护中心被触发后，会启动安全清洗程序，例如进行流量清洗等，从而使得故障物理机恢复健康。需要说明的是，对于因网络DDoS攻击而导致的某台物理机网络不通与因物理机宕机而导致的物理机网络不通是需要区别对待的，如果在物理机正遭受网络DDoS攻击时将其上的虚拟机迁移至其他物理机，会产生骨牌效应，导致扩大故障风险，即其他物理机陆续被攻击而不可用，最终可能造成全集群网络设备的泛洪(flooding)，导致全集群物理机故障风险。
步骤230，若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；
优选的，若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块。
需要说明的是，所述的物理机自身不能修复的软硬件故障类型可以包括：物理机宕机、物理机CPU异常、物理机内存异常、物理机电源模块等各类硬件问题异常。这类故障会直接导致物理机不可用，且需要更换硬件模块方可修复，因此，本申请实施例通过从集群中将故障物理机隔离后再对故障物理机进行硬件更换或者维护。
此外，针对物理机自身不能修复的软硬件故障的情况下，传统物理机上的带外管控系统由于硬件故障率和成本问题，通常可用性在90％左右甚至更低，在云计算服务本身至少99.95％的商用可用性要求下，全年的不可用性时长共计262.8分钟，如果一台故障物理机无法得到及时修复，则由于一台物理机故障就会直接导致几十分钟的人工处理时耗，因此，现有技术中的带外管控系统的可用性指标无法匹配商用云计算服务的故障恢复服务等级协议(Service-Level Agreement，SLA)。而本申请实施例提供的技术方案，对传统的带外管控系统进行改进，在带外管理模块可用性达不到商用标准时，可以通过所述集群外部的物理机故障分类处理模块的指令指示故障物理机自主关闭，再由所述集群外部的物理机故障分类处理模块通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；从而大量缩短故障物理机的修复时间，进而提高系统的商用可用性。
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
实施例二
参照图2，示出了本申请的另一种集群物理机故障分类处理方法实施例的步骤流程图，具体可以包括如下步骤：
步骤210，从物理机故障信息存储中心获取物理机故障信息列表；
需要说明的是，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
步骤220，若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
可以理解的是，在实际应用中，所述集群外部的安全攻击防护中心被触发后，会启动安全清洗程序，例如进行流量清洗等，从而使得故障物理机恢复健康。需要说明的是，对于因网络DDoS攻击而导致的某台物理机网络不通与因物理机宕机而导致的物理机网络不通是需要区别对待的，如果在物理机正遭受网络DDoS攻击时将其上的虚拟机迁移至其他物理机，会产生骨牌效应，导致扩大故障风险，即其他物理机陆续被攻击而不可用，最终可能造成全集群网络设备的泛洪(flooding)，导致全集群物理机故障风险。
步骤230，若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；
优选的，若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块。
需要说明的是，所述的物理机自身不能修复的软硬件故障类型可以包括：物理机宕机、物理机CPU异常、物理机内存异常、物理机电源模块等各类硬件问题异常。这类故障会直接导致物理机不可用，且需要更换硬件模块方可修复，因此，本申请实施例通过从集群中将故障物理机隔离后再对故障物理机进行硬件更换或者维护。
此外，针对物理机自身不能修复的软硬件故障的情况下，传统物理机上的带外管控系统由于硬件故障率和成本问题，通常可用性在90％左右甚至更低，在云计算服务本身至少99.95％的商用可用性要求下，全年的不可用性时长共计262.8分钟，如果一台故障物理机无法得到及时修复，则由于一台物理机故障就会直接导致几十分钟的人工处理时耗，因此，现有技术中的带外管控系统的可用性指标无法匹配商用云计算服务的故障恢复服务等级协议(Service-Level Agreement，SLA)。而本申请实施例提供的技术方案，对传统的带外管控系统进行改进，在带外管理模块可用性达不到商用标准时，可以通过所述集群外部的物理机故障分类处理模块的指令指示故障物理机自主关闭，再由所述集群外部的物理机故障分类处理模块通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；从而大量缩短故障物理机的修复时间，进而提高系统的商用可用性。
步骤240，若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间；判断网络不通的物理机数量是否超过预设数量，如果是则通知运营维修人员人工修复；否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上；
其中，所述预设时间可以依据实际情况设定为3分钟、5分钟等适合的时间段。
需要说明的是，在检测到物理机网络完全不通且网络不通持续时间达到预设时间的情况下，本申请实施例需要进一步检查网络不通的故障物理机的数量是否超过一个机柜的物理机数量或者一个交换机下联物理机数量，如果超过，则认为是集群规模性网络故障，则需要采取电话报警通运营维修人员人工修复，而不再自动处理。这是由于对于大规模物理机故障，在进行隔离物理机迁移虚拟机时，会导致大量物理机被关闭，当机房设备(网络设备或者电力设备等)恢复后，还需要再次重启物理机，然后恢复虚拟机，这一系列的操作将直接导致人工处理时间加倍甚至更多，从而大大加大虚拟机的不可用时长。因此，本申请实施例提供的方法，对此种物理机故障类型加以区分处理，可以大量缩短故障物理机的修复时间，从而大大缩短其上的虚拟机不可用的时长，进而提高系统的商用可用性。
优选的，本申请实施例所述方法还可以进一步包括：
步骤250，若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上；
步骤260，若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；
需要说明的是，所述物理机网络不稳定且网络不稳定持续时间达到预设时间的情况主要是一些未知原因造成物理机故障，例如，系统负载类、系统网络类、硬件故障类等。这类故障虽然本质原因比较难查，但是这类故障的现象却很明确，主要是：物理机网络丢包、物理机管理通道访问异常、物理机性能使用异常。对于这类物理机故障，可以采用相同的处理方式，即向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
优选的，在本申请的一个实施例中，通过以下方式确定所述健康物理机：
在所述物理机故障信息列表中匹配所述集群内的所有物理机；
将没有匹配成功的物理机确定为健康物理机。
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
此外，本申请实施例也同时考虑到大规模云计算集群内发生物理机规模故障情况的可能性，通过判断故障物理机的数量是否构成机房级别，并有针对性的采取不同的修复处理方式。尤其是针对大规模物理机故障的情况，采用人工处理的方式修复，从而有效避免由于故障物理机上的虚拟机的频繁迁移而影响系统性能情况的发生。
实施例三
参照图3，示出了本申请的一种虚拟机恢复方法的实施例示意图，具体可以包括如下步骤：
步骤310，虚拟化集群系统内的物理机自主检测自身的故障动态；
优选的，每台物理机可以以固定的时间间隔定期自主检测自身的故障动态，例如每隔30秒自主检测一次。
步骤320，若自主检测到物理机自身能容错修复的软硬件故障，通过容错方式修复；
可以理解的是，本申请实施例所述的物理机自身能容错修复的软硬件故障，可以包括：存储数据的磁盘故障、虚拟化相关内核模块异常、存储数据的文件系统异常等。例如，针对存储数据的磁盘故障，容错修复方式具体是，首先隔离磁盘，然后利用集群分布式存储多份数据的机制，实现该磁盘上数据自动复制至其他健康磁盘上，这样可以有效保证该故障磁盘隔离后不会影响系统稳定运行。同样，针对存储数据的文件系统损坏，也可以通过隔离该文件系统挂载的磁盘达到容错修复的目的。
步骤330，若自主检测到物理机自身能重启修复的软硬件故障，通过重启物理机方式修复；
可以理解的是，本申请实施例所述的物理机自身能修复的软硬件故障，可以包括：根文件系统只读等异常、网卡驱动重启可修复的异常、操作系统内核模块异常等。这类软硬件故障都可以通过重启物理机的方式予以修复。
步骤340，从物理机故障信息存储中心获取物理机故障信息列表；
需要说明的是，由物理机故障分类处理模块从物理机故障信息存储中心获取物理机故障信息列表。所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
步骤350，若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
可以理解的是，在实际应用中，所述集群外部的安全攻击防护中心被触发后，会启动安全清洗程序，例如进行流量清洗等，从而使得故障物理机恢复健康。需要说明的是，对于因网络DDoS攻击而导致的某台物理机网络不通与因物理机宕机而导致的物理机网络不通是需要区别对待的，如果在物理机正遭受网络DDoS攻击时将其上的虚拟机迁移至其他物理机，会产生骨牌效应，导致扩大故障风险，即其他物理机陆续被攻击而不可用，最终可能造成全集群网络设备的泛洪(flooding)，导致全集群物理机故障风险。
步骤360，若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
需要说明的是，所述的物理机自身不能修复的软硬件故障类型可以包括：物理机宕机、物理机CPU异常、物理机内存异常、物理机电源模块等各类硬件问题异常。这类故障会直接导致物理机不可用，且需要更换硬件模块方可修复，因此，本申请实施例通过从集群中将故障物理机隔离后再对故障物理机进行硬件更换或者维护。
此外，针对物理机自身不能修复的软硬件故障的情况下，传统物理机上的带外管控系统由于硬件故障率和成本问题，通常可用性在90％左右甚至更低，在云计算服务本身至少99.95％的商用可用性要求下，全年的不可用性时长共计262.8分钟，如果一台故障物理机无法得到及时修复，则由于一台物理机故障就会直接导致几十分钟的人工处理时耗，因此，现有技术中的带外管控系统的可用性指标无法匹配商用云计算服务的故障恢复服务等级协议(Service-Level Agreement，SLA)。而本申请实施例提供的技术方案，对传统的带外管控系统进行改进，在带外管理模块可用性达不到商用标准时，可以通过所述集群外部的物理机故障分类处理模块的指令指示故障物理机自主关闭，再由所述集群外部的物理机故障分类处理模块通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；从而大量缩短故障物理机的修复时间，进而提高系统的商用可用性。
优选的，本申请实施例所述方法还可以进一步包括：
步骤370，若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间；判断网络不通的物理机数量是否超过预设数量，如果是则通知运营维修人员人工修复；否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
其中，所述预设时间可以依据实际情况设定为3分钟、5分钟等适合的时间段。
需要说明的是，在检测到物理机网络完全不通且网络不通持续时间达到预设时间的情况下，本申请实施例需要进一步检查网络不通的故障物理机的数量是否超过一个机柜的物理机数量或者一个交换机下联物理机数量，如果超过，则认为是集群规模性网络故障，则需要采取电话报警通运营维修人员人工修复，而不再自动处理。这是由于对于大规模物理机故障，在进行隔离物理机迁移虚拟机时，会导致大量物理机被关闭，当机房设备(网络设备或者电力设备等)恢复后，还需要再次重启物理机，然后恢复虚拟机，这一系列的操作将直接导致人工处理时间加倍甚至更多，从而大大加大虚拟机的不可用时长。因此，本申请实施例提供的方法，对此种物理机故障类型加以区分处理，可以大量缩短故障物理机的修复时间，从而大大缩短其上的虚拟机不可用的时长，进而提高系统的商用可用性。
优选的，本申请实施例所述方法还可以进一步包括：
步骤380，若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
优选的，本申请实施例所述方法还可以进一步包括：
步骤390，若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
需要说明的是，所述物理机网络不稳定且网络不稳定持续时间达到预设时间的情况主要是一些未知原因造成物理机故障，例如，系统负载类、系统网络类、硬件故障类等。这类故障虽然本质原因比较难查，但是这类故障的现象却很明确，主要是：物理机网络丢包、物理机管理通道访问异常、物理机性能使用异常。对于这类物理机故障，可以采用相同的处理方式，即向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
优选的，在本申请的一个实施例中，通过以下方式确定所述健康物理机：
在所述物理机故障信息列表中匹配所述集群内的所有物理机；
将没有匹配成功的物理机确定为健康物理机。
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
此外，本申请实施例也同时考虑到大规模云计算集群内发生物理机规模故障情况的可能性，通过判断故障物理机的数量是否构成机房级别，并有针对性的采取不同的修复处理方式。尤其是针对大规模物理机故障的情况，采用人工处理的方式修复，从而有效避免由于故障物理机上的虚拟机的频繁迁移而影响系统性能情况的发生。
实施例四
参照图4，示出了本申请的另一种虚拟机恢复方法的实施例示意图，具体可以包括如下步骤：
物理机故障探测模块每隔30秒检查集群内每台物理机的网络情况，并更新至物理机故障信息存储中心；集群系统内的每台物理机自主检测自身的故障情况，并通过物理机故障收集模块更新至物理机故障信息存储中心。
对于物理机自身能容错修复的软硬件故障的场景，则由物理机自身通过容错方式修复处理；对于物理机自身能重启修复的软硬件故障，则由物理机自身通过重启物理机方式修复处理；如果是物理机自身不能修复的软硬件故障，则进行关机处理。
物理机故障分类处理模块每隔1分钟从物理机故障信息存储中心获取物理机故障信息列表；判断该物理机故障信息列表是否为空，如果是则返回循环；否则继续判断所述物理机故障信息列表中是否有因遭受网络攻击而导致物理机故障的情况，如果有，则触发所述集群外部的安全攻击防护中心处理；否则继续判断在所述物理机故障信息列表中是否有因物理机自身不能修复的软硬件故障的情况，如果有，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；再通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
如果确定所述物理机故障信息列表中没有因遭受网络攻击而导致物理机故障的情况，则继续判断在所述物理机故障信息列表中是否有物理机网络完全不通且网络不通持续时间达到预设时间，例如3分钟；如果有则再判断网络不通的物理机数量是否超过预设数量，例如，故障物理机的数量是否超过一个机柜的物理机数量或者一个交换机下联物理机数量，如果超过，则认为是集群规模性网络故障，则需要采取电话报警通运营维修人员人工修复，而不再自动处理。否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
判断在所述物理机故障信息列表中是否有检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
如果在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
需要说明的是，所述物理机网络不稳定且网络不稳定持续时间达到预设时间的情况主要是一些未知原因造成物理机故障，例如，系统负载类、系统网络类、硬件故障类等。这类故障虽然本质原因比较难查，但是这类故障的现象却很明确，主要是：物理机网络丢包、物理机管理通道访问异常、物理机性能使用异常。对于这类物理机故障，可以采用相同的处理方式。
优选的，在本申请的一个实施例中，通过以下方式确定所述健康物理机：
在所述物理机故障信息列表中匹配所述集群内的所有物理机；
将没有匹配成功的物理机确定为健康物理机。
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
此外，本申请实施例也同时考虑到大规模云计算集群内发生物理机规模故障情况的可能性，通过判断故障物理机的数量是否构成机房级别，并有针对性的采取不同的修复处理方式。尤其是针对大规模物理机故障的情况，采用人工处理的方式修复，从而有效避免由于故障物理机上的虚拟机的频繁迁移而影响系统性能情况的发生。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
实施例五
参照图5，示出了本申请的一种物理机故障修复装置实施例的结构框图，所述物理机故障修复装置500应用于虚拟化集群系统内的物理机上，具体可以包括：自主检测模块(selfChecker)510、自主处理模块(selfHnadler)520；其中：
自主检测模块510具体包括：检测单元511，用于自主检测物理机自身的故障动态；优选的，检测单元511可以以固定的时间间隔定期自主检测物理机自身的故障动态，例如每隔30秒自主检测一次。
自主处理模块520，具体包括：
容错单元521，用于若所述检测单元511检测到物理机自身能容错修复的软硬件故障，则通过容错方式修复；
可以理解的是，本申请实施例所述的物理机自身能容错修复的软硬件故障，可以包括：存储数据的磁盘故障、虚拟化相关内核模块异常、存储数据的文件系统异常等。例如，针对存储数据的磁盘故障，容错修复方式具体是，首先隔离磁盘，然后利用集群分布式存储多份数据的机制，实现该磁盘上数据自动复制至其他健康磁盘上，这样可以有效保证该故障磁盘隔离后不会影响系统稳定运行。同样，针对存储数据的文件系统损坏，也可以通过隔离该文件系统挂载的磁盘达到容错修复的目的。
重启单元522，用于若所述检测单元511检测到物理机自身能重启修复的软硬件故障，则通过重启物理机方式修复。
可以理解的是，本申请实施例所述的物理机自身能重启修复的软硬件故障，可以包括：根文件系统只读等异常、网卡驱动重启可修复的异常、操作系统内核模块异常等。这类软硬件故障都可以通过重启物理机的方式予以修复。
优选的，所述自主处理模块520还可以进一步包括：
关机单元523，用于若所述检测单元511检测到物理机自身不能修复的软硬件故障，则根据所述集群外部的物理机故障分类处理模块的指令或通过所述物理机上的带外管理模块530关闭故障物理机，由所述集群外部的物理机故障分类处理模块通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
需要说明的是，针对物理机自身不能修复的软硬件故障的情况下，传统物理机上的带外管控系统由于硬件故障率和成本问题，通常可用性在90％左右甚至更低，在云计算服务本身至少99.95％的商用可用性要求下，全年的不可用性时长共计262.8分钟，如果一台故障物理机无法得到及时修复，则由于一台物理机故障就会直接导致几十分钟的人工处理时耗，因此，现有技术中的带外管控系统的可用性指标无法匹配商用云计算服务的故障恢复服务等级协议(Service-Level Agreement，SLA)。而本申请实施例提供的技术方案，对传统的带外管控系统进行改进，在带外管理模块530可用性达不到商用标准时，可以通过所述集群外部的物理机故障分类处理模块的指令指示故障物理机自主关闭，再由所述集群外部的物理机故障分类处理模块通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上；从而大量缩短故障物理机的修复时间，进而提高系统的商用可用性。
优选的，所述自主检测模块510还可以进一步包括：
上报单元512，用于当检测单元511自主检测到因遭受网络攻击而导致物理机故障时，通过物理机故障收集模块上报物理机故障信息到物理机故障信息存储中心，由所述集群外部的物理机故障分类处理模块触发所述集群外部的安全攻击防护中心处理。
其中，所述集群外部的安全攻击防护中心被触发后，会启动安全清洗程序，例如进行流量清洗等，从而使得故障物理机恢复健康。需要说明的是，对于因网络DDoS攻击而导致的某台物理机网络不通与因物理机宕机而导致的物理机网络不通是需要区别对待的，如果在物理机正遭受网络DDoS攻击时将其上的虚拟机迁移至其他物理机，会产生骨牌效应，导致扩大故障风险，即其他物理机陆续被攻击而不可用，最终可能造成全集群网络设备的泛洪(flooding)，导致全集群物理机故障风险。
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
实施例六
参照图6，示出了本申请的一种集群物理机故障分类处理装置实施例的结构框图，所述物理机故障分类处理装置600具体可以包括如下模块：
获取模块610，用于从物理机故障信息存储中心获取物理机故障信息列表；需要说明的是，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
第一处理模块620，用于若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
可以理解的是，在实际应用中，所述集群外部的安全攻击防护中心被触发后，会启动安全清洗程序，例如进行流量清洗等，从而使得故障物理机恢复健康。需要说明的是，对于因网络DDoS攻击而导致的某台物理机网络不通与因物理机宕机而导致的物理机网络不通是需要区别对待的，如果在物理机正遭受网络DDoS攻击时将其上的虚拟机迁移至其他物理机，会产生骨牌效应，导致扩大故障风险，即其他物理机陆续被攻击而不可用，最终可能造成全集群网络设备的泛洪(flooding)，导致全集群物理机故障风险。
第二处理模块630，进一步包括：
关闭处理单元，用于若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；优选的，所述指令可以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；
迁移处理单元，用于通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
需要说明的是，所述的物理机自身不能修复的软硬件故障类型可以包括：物理机宕机、物理机CPU异常、物理机内存异常、物理机电源模块等各类硬件问题异常。这类故障会直接导致物理机不可用，且需要更换硬件模块方可修复，因此，本申请实施例通过从集群中将故障物理机隔离后再对故障物理机进行硬件更换或者维护。
优选的，所述物理机故障分类处理装置600还可以进一步包括第三处理模块640，该第三处理模块640具体包括：
通知处理单元，用于若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间，并且网络不通的物理机数量超过一台，则通知运营维修人员人工修复；
迁移处理单元，用于若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间，并且网络不通的物理机数量未超过预设数量，则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
其中，所述预设时间可以依据实际情况设定为3分钟、5分钟等适合的时间段。
需要说明的是，在检测到物理机网络完全不通且网络不通持续时间达到预设时间的情况下，本申请实施例需要进一步检查网络不通的故障物理机的数量是否超过一个机柜的物理机数量或者一个交换机下联物理机数量，如果超过，则认为是集群规模性网络故障，则需要采取电话报警通运营维修人员人工修复，而不再自动处理。这是由于对于大规模物理机故障，在进行隔离物理机迁移虚拟机时，会导致大量物理机被关闭，当机房设备(网络设备或者电力设备等)恢复后，还需要再次重启物理机，然后恢复虚拟机，这一系列的操作将直接导致人工处理时间加倍甚至更多，从而大大加大虚拟机的不可用时长。因此，本申请实施例提供的方法，对此种物理机故障类型加以区分处理，可以大量缩短故障物理机的修复时间，从而大大缩短其上的虚拟机不可用的时长，进而提高系统的商用可用性。
优选的，所述物理机故障分类处理装置600还可以进一步包括第四处理模块650，所述第四处理模块650具体包括：
重启处理单元，用于若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则在确定当前的物理机是健康的情况下，通过虚拟化接口重启所述物理机上的虚拟机；
迁移处理单元，用于若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则在确定当前的物理机是不健康的情况下，通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
优选的，所述物理机故障分类处理装置600还可以进一步包括第五处理模块660，所述第五处理模块660具体包括：
关机处理单元，用于若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；
迁移处理单元，用于通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
需要说明的是，所述物理机网络不稳定且网络不稳定持续时间达到预设时间的情况主要是一些未知原因造成物理机故障，例如，系统负载类、系统网络类、硬件故障类等。这类故障虽然本质原因比较难查，但是这类故障的现象却很明确，主要是：物理机网络丢包、物理机管理通道访问异常、物理机性能使用异常。对于这类物理机故障，可以采用相同的处理方式，即向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
优选的，所述物理机故障分类处理装置600还可以进一步包括：
确定模块670，用于在所述物理机故障信息列表中匹配所述集群内的所有物理机，将没有匹配成功的物理机确定为健康物理机。
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
此外，本申请实施例也同时考虑到大规模云计算集群内发生物理机规模故障情况的可能性，通过判断故障物理机的数量是否构成机房级别，并有针对性的采取不同的修复处理方式。尤其是针对大规模物理机故障的情况，采用人工处理的方式修复，从而有效避免由于故障物理机上的虚拟机的频繁迁移而影响系统性能情况的发生。
实施例七
参照图7，示出了本申请的一种虚拟机恢复系统实施例的架构图，该虚拟机恢复系统包括：物理机故障修复装置710，其应用于虚拟化集群系统700内的每台物理机上；物理机故障分类处理装置720及物理机故障信息存储中心730；其中：
所述物理机故障修复装置710具体可以包括：自主检测模块711、自主处理模块712；其中：自主检测模块711用于自主检测物理机自身的故障动态；自主处理模块712用于若所述自主检测模块711检测到物理机自身能容错修复的软硬件故障，则通过容错方式修复；还用于若自主检测模块711检测到物理机自身能重启修复的软硬件故障，通过重启物理机方式修复。
优选的，所述自主处理模块712还可以用于若所述自主检测模块711检测到物理机自身不能修复的软硬件故障，则根据所述集群外部的物理机故障分类处理模块720的指令或通过所述物理机上的带外管理模块713关闭故障物理机，由所述集群外部的物理机故障分类处理模块720通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
优选的，所述自主检测模块712还可以用于当自主检测模块711自主检测到因遭受网络攻击而导致物理机故障时，通过物理机故障收集模块760上报物理机故障信息到物理机故障信息存储中心730，由所述集群外部的物理机故障分类处理模块720触发所述集群外部的安全攻击防护中心740处理。
需要说明的是，在本申请另一实施例中，该自主检测模块711和自主处理模块712可以是部署在集群每台物理机上的软件模块，在物理机开机时自动启动，该自主检测模块711和自主处理模块712的运行不依赖文件系统，仅仅依赖CPU、内存。
所述物理机故障信息存储中心730，用于将所有上报的物理故障信息汇集成物理机故障信息列表；其中，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块750从故障物理机处探测到并上报给所述物理机故障信息存储中心730的物理机故障信息，及由所述集群外部的物理机故障收集模块760从故障物理机处收集到并上报给所述物理机故障信息存储中心730的物理机故障信息。
所述物理机故障分类处理装置720，用于通过获取模块721从所述物理机故障信息存储中心730获取物理机故障信息列表，若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则通过第一处理模块722触发所述集群外部的安全攻击防护中心740处理；若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则通过第二处理模块723向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块713关闭故障物理机，及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
优选的，所述物理机故障分类处理装置720还可以进一步包括第三处理模块724，用于若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间；判断网络不通的物理机数量是否超过预设数量，如果是则通知运营维修人员人工修复；否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
优选的，所述物理机故障分类处理装置720还可以进一步包括第四处理模块725，用于若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
优选的，所述物理机故障分类处理装置720还可以进一步包括第五处理模块726，用于若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
优选的，所述物理机故障分类处理装置720还可以进一步包括确定模块727，用于在所述物理机故障信息列表中匹配所述集群内的所有物理机，将没有匹配成功的物理机确定为健康物理机。
需要说明的是，所述物理机故障修复装置710以及物理机故障分类处理装置720的具体结构请参见前述实施例的详细说明，此处不再赘述。
需要说明的是，在本申请另一个实施例中，虚拟机恢复系统中的物理机故障分类处理装置720、物理机故障探测模块750、物理机故障收集模块760均为部署在虚拟化集群系统700以外的物理机上的软件模块，其可以各自独立部署在不同的物理机上，也可以合并部署在同一台物理机上。此外，物理机故障信息存储中心730是部署在虚拟化集群系统700以外的一套数据库系统。安全攻击防护中心740可以直接采用现有的安全攻击防护系统。本申请实施例对此不做限制。
本申请实施例，具备以下优点：
本申请实施例可以在大规模的云计算集群中，通过对多种物理机故障场景，进行精细化故障快速、准确的识别，并有针对性的进行分类处理，从而实现快速、高可靠的物理机故障修复处理，以保证其上的虚拟机服务的快速恢复。
进一步的，本申请实施例通过物理机自主检测自身的故障动态，并对物理机自身能修复的物理机故障情况有针对性的进行分类修复处理；对物理机自身不能修复的物理机故障情况，通过集群外部的物理机故障分类处理模块有针对性的进行分类修复处理，从而有效降低物理机故障的误判和漏判情况的发生，更安全、稳定、快速的进行虚拟机自动恢复。
另外，本申请实施例针对物理机自身不能修复的物理机故障情况，除了可以通过故障物理机上的带外管理模块关闭故障物理机之外，还可以通过集群外部的物理机故障分类处理模块，指示故障物理机自主关机，从而弥补带外管理模块调用关机操作的可用性无法达到商用标准的问题，同时也确保自动化物理机隔离的有效性。
此外，本申请实施例也同时考虑到大规模云计算集群内发生物理机规模故障情况的可能性，通过判断故障物理机的数量是否构成机房级别，并有针对性的采取不同的修复处理方式。尤其是针对大规模物理机故障的情况，采用人工处理的方式修复，从而有效避免由于故障物理机上的虚拟机的频繁迁移而影响系统性能情况的发生。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD@ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD@ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种应用于虚拟化集群系统的物理机故障修复方法、装置和集群物理机故障分类处理方法、装置及虚拟机恢复方法、系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均可有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
Claims (32)
1.一种集群物理机故障分类处理方法，其特征在于，包括：
从物理机故障信息存储中心获取物理机故障信息列表；
若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
2.如权利要求1所述的方法，其特征在于，所述方法还包括：
若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间；
判断网络不通的物理机数量是否超过预设数量，如果是则通知运营维修人员人工修复；
否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
3.如权利要求1所述的方法，其特征在于，所述方法还包括：
若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
4.如权利要求1所述的方法，其特征在于，所述方法还包括：
若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
5.如权利要求1所述的方法，其特征在于，所述若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令的步骤包括：
向故障物理机发送关闭故障物理机的指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机。
6.如权利要求1所述的方法，其特征在于，通过以下方式确定所述健康物理机：
在所述物理机故障信息列表中匹配所述集群内的所有物理机；
将没有匹配成功的物理机确定为健康物理机。
7.如权利要求1所述的方法，其特征在于，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
8.一种集群物理机故障分类处理装置，其特征在于，包括：
获取模块，用于从物理机故障信息存储中心获取物理机故障信息列表；
第一处理模块，用于若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
第二处理模块，进一步包括：
关闭处理单元，用于若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；
迁移处理单元，用于通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
9.如权利要求8所述的装置，其特征在于，所述装置还包括第三处理模块，所述第三处理模块包括：
通知处理单元，用于若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间，并且网络不通的物理机数量超过一台，则通知运营维修人员人工修复；
迁移处理单元，用于若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间，并且网络不通的物理机数量未超过预设数量，则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
10.如权利要求8所述的装置，其特征在于，所述装置还包括第四处理模块，所述第四处理模块包括：
重启处理单元，用于若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则在确定当前的物理机是健康的情况下，通过虚拟化接口重启所述物理机上的虚拟机；
迁移处理单元，用于若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则在确定当前的物理机是不健康的情况下，通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
11.如权利要求8所述的装置，其特征在于，所述装置还包括第五处理模块，所述第五处理模块包括：
关机处理单元，用于若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；
迁移处理单元，用于通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
12.如权利要求8-11任一项所述的装置，其特征在于，所述关闭处理单元，用于若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机。
13.如权利要求8-11任一项所述的装置，其特征在于，所述装置还包括：
确定模块，用于在所述物理机故障信息列表中匹配所述集群内的所有物理机，将没有匹配成功的物理机确定为健康物理机。
14.如权利要求8所述的装置，其特征在于，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
15.一种虚拟机恢复方法，其特征在于，应用于虚拟化集群系统，所述方法包括：
虚拟化集群系统内的物理机自主检测自身的故障动态；
若自主检测到物理机自身能容错修复的软硬件故障，通过容错方式修复；
若自主检测到物理机自身能重启修复的软硬件故障，通过重启物理机方式修复；
从物理机故障信息存储中心获取物理机故障信息列表；
若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；
若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
16.如权利要求15所述的方法，其特征在于，所述方法还包括：
若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间；判断网络不通的物理机数量是否超过预设数量，如果是则通知运营维修人员人工修复；否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
17.如权利要求15所述的方法，其特征在于，所述方法还包括：
若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
18.如权利要求15所述的方法，其特征在于，所述方法还包括：
若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
19.如权利要求15所述的方法，其特征在于，通过以下方式确定所述健康物理机：
在所述物理机故障信息列表中匹配所述集群内的所有物理机；
将没有匹配成功的物理机确定为健康物理机。
20.如权利要求15所述的方法，其特征在于，所述从物理机故障信息存储中心获取物理机故障信息列表的步骤包括：
物理机故障分类处理模块从物理机故障信息存储中心获取物理机故障信息列表。
21.如权利要求15所述的方法，其特征在于，所述若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令的步骤包括：
向故障物理机发送关闭故障物理机的指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机。
22.如权利要求15所述的方法，其特征在于，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
23.一种虚拟机恢复系统，其特征在于，所述系统包括：
物理机故障修复装置，应用于虚拟化集群系统内的物理机上自主检测物理机自身的故障动态，若自主检测到物理机自身能容错修复的软硬件故障，通过容错方式修复；若自主检测到物理机自身能重启修复的软硬件故障，通过重启物理机方式修复；
物理机故障信息存储中心，用于将所有上报的物理故障信息汇集成物理机故障信息列表；
物理机故障分类处理装置，用于从所述物理机故障信息存储中心获取物理机故障信息列表，若在所述物理机故障信息列表中检测到因遭受网络攻击而导致物理机故障，则触发所述集群外部的安全攻击防护中心处理；若在所述物理机故障信息列表中检测到因物理机自身不能修复的软硬件故障，则向故障物理机发送关闭故障物理机的指令，及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
24.如权利要求23所述的系统，其特征在于，所述物理机故障分类处理装置还用于：
若在所述物理机故障信息列表中检测到物理机网络完全不通且网络不通持续时间达到预设时间；判断网络不通的物理机数量是否超过预设数量，如果是则通知运营维修人员人工修复；否则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内到其他健康物理机上。
25.如权利要求23所述的系统，其特征在于，所述物理机故障分类处理装置还用于：
若在所述物理机故障信息列表中检测到物理机网络不通但网络不通持续时间未达到预设时间后网络又恢复正常，且确定物理机网络不通是物理机重启所导致的，则判断当前的物理机是否健康，如果健康则通过虚拟化接口重启所述物理机上的虚拟机，如果不健康则通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群内其他健康物理机上。
26.如权利要求23所述的系统，其特征在于，所述物理机故障分类处理装置还用于：
若在所述物理机故障信息列表中检测到物理机网络不稳定且网络不稳定持续时间达到预设时间，则向故障物理机发送指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机；及通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
27.如权利要求23所述的系统，其特征在于，所述物理机故障分类处理装置还用于：
在所述物理机故障信息列表中匹配所述集群内的所有物理机，将没有匹配成功的物理机确定为健康物理机。
28.如权利要求23所述的系统，其特征在于，所述物理机故障分类处理装置还用于：
向故障物理机发送关闭故障物理机的指令以指示所述故障物理机自主关闭故障物理机或通过所述物理机上的带外管理模块关闭故障物理机。
29.如权利要求23所述的系统，其特征在于，所述物理机故障信息列表包括：由所述集群外部的物理机故障探测模块从故障物理机处探测到并上报给所述物理机故障信息存储中心的物理机故障信息，及由所述集群外部的物理机故障收集模块从故障物理机处收集到并上报给所述物理机故障信息存储中心的物理机故障信息。
30.如权利要求23所述的系统，其特征在于，所述物理机故障修复装置包括：
自主检测模块，包括：
检测单元，用于自主检测物理机自身的故障动态；
自主处理模块，包括：
容错单元，用于若所述检测单元检测到物理机自身能容错修复的软硬件故障，则通过容错方式修复；
重启单元，用于若所述检测单元检测到物理机自身能重启修复的软硬件故障，则通过重启物理机方式修复。
31.如权利要求30所述的系统，其特征在于，所述自主处理模块还包括：
关机单元，用于若所述检测单元检测到物理机自身不能修复的软硬件故障，则根据所述集群外部的物理机故障分类处理模块的指令或通过所述物理机上的带外管理模块关闭故障物理机，由所述集群外部的物理机故障分类处理模块通过虚拟化接口迁移所述故障物理机上的虚拟机到所述集群系统内其他健康物理机上。
32.如权利要求30所述的系统，其特征在于，所述自主检测模块还包括：
上报单元，用于当自主检测模块自主检测到因遭受网络攻击而导致物理机故障时，通过物理机故障收集模块上报物理机故障信息到物理机故障信息存储中心，由所述集群外部的物理机故障分类处理模块触发所述集群外部的安全攻击防护中心处理。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610136817.0A CN107179957B (zh) | 2016-03-10 | 2016-03-10 | 物理机故障分类处理方法、装置和虚拟机恢复方法、系统 |
| TW106104781A TWI746512B (zh) | 2016-03-10 | 2017-02-14 | 實體機器故障分類處理方法、裝置和虛擬機器恢復方法、系統 |
| PCT/CN2017/074618 WO2017152763A1 (zh) | 2016-03-10 | 2017-02-23 | 物理机故障分类处理方法、装置和虚拟机恢复方法、系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610136817.0A CN107179957B (zh) | 2016-03-10 | 2016-03-10 | 物理机故障分类处理方法、装置和虚拟机恢复方法、系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107179957A true CN107179957A (zh) | 2017-09-19 |
| CN107179957B CN107179957B (zh) | 2020-08-25 |
Family
ID=59790073
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610136817.0A Active CN107179957B (zh) | 2016-03-10 | 2016-03-10 | 物理机故障分类处理方法、装置和虚拟机恢复方法、系统 |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN107179957B (zh) |
| TW (1) | TWI746512B (zh) |
| WO (1) | WO2017152763A1 (zh) |
Cited By (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108062471A (zh) * | 2017-12-19 | 2018-05-22 | 龙岩学院 | 一种云计算网络运行过程中的风险处理方法及设备 |
| CN108153618A (zh) * | 2017-12-22 | 2018-06-12 | 国网浙江杭州市萧山区供电有限公司 | 硬盘数据恢复方法、装置及硬盘数据恢复设备 |
| CN108763039A (zh) * | 2018-04-02 | 2018-11-06 | 阿里巴巴集团控股有限公司 | 一种业务故障模拟方法、装置及设备 |
| CN109587331A (zh) * | 2018-11-26 | 2019-04-05 | 广州微算互联信息技术有限公司 | 云手机故障自动修复的方法与系统 |
| CN109614260A (zh) * | 2018-11-28 | 2019-04-12 | 北京小米移动软件有限公司 | 通信故障判断方法、装置和存储介质 |
| CN110247821A (zh) * | 2019-06-04 | 2019-09-17 | 平安科技（深圳）有限公司 | 一种故障检测方法及相关设备 |
| CN110262917A (zh) * | 2019-05-15 | 2019-09-20 | 平安科技（深圳）有限公司 | 宿主机自愈方法、装置、计算机设备及存储介质 |
| CN110377396A (zh) * | 2019-07-04 | 2019-10-25 | 深圳先进技术研究院 | 一种虚拟机自动迁移方法、系统及电子设备 |
| CN111176795A (zh) * | 2020-01-09 | 2020-05-19 | 武汉思普崚技术有限公司 | 一种分布式虚拟网络的动态迁移方法及系统 |
| CN111212079A (zh) * | 2020-01-09 | 2020-05-29 | 武汉思普崚技术有限公司 | 一种基于业务的微隔离流量牵引方法及系统 |
| CN111224989A (zh) * | 2020-01-09 | 2020-06-02 | 武汉思普崚技术有限公司 | 一种虚拟微隔离网络的攻击面防护方法及系统 |
| CN111224990A (zh) * | 2020-01-09 | 2020-06-02 | 武汉思普崚技术有限公司 | 一种分布式微隔离网络的流量牵引方法及系统 |
| CN111258711A (zh) * | 2020-01-09 | 2020-06-09 | 武汉思普崚技术有限公司 | 一种多协议的网络微隔离方法及系统 |
| CN111262841A (zh) * | 2020-01-09 | 2020-06-09 | 武汉思普崚技术有限公司 | 一种虚拟微隔离网络的资源调度方法及系统 |
| CN111262840A (zh) * | 2020-01-09 | 2020-06-09 | 武汉思普崚技术有限公司 | 一种虚拟网络的攻击面转移方法及系统 |
| CN111277568A (zh) * | 2020-01-09 | 2020-06-12 | 武汉思普崚技术有限公司 | 一种分布式虚拟网络的隔离攻击方法及系统 |
| CN111273995A (zh) * | 2020-01-09 | 2020-06-12 | 武汉思普崚技术有限公司 | 一种虚拟微隔离网络的安全调度方法及系统 |
| CN111399978A (zh) * | 2020-03-02 | 2020-07-10 | 中铁信弘远(北京)软件科技有限责任公司 | 一种基于OpenStack的故障迁移系统及迁移方法 |
| CN111796959A (zh) * | 2020-06-30 | 2020-10-20 | 中国工商银行股份有限公司 | 宿主机容器自愈方法、装置及系统 |
| CN112165495A (zh) * | 2020-10-13 | 2021-01-01 | 北京计算机技术及应用研究所 | 一种基于超融合架构防DDoS攻击方法、装置及超融合集群 |
| CN113157476A (zh) * | 2021-04-10 | 2021-07-23 | 作业帮教育科技（北京）有限公司 | 虚拟云环境中显卡故障的处理方法及装置 |
| CN114780272A (zh) * | 2022-04-18 | 2022-07-22 | 北京亚康万玮信息技术股份有限公司 | 基于共享存储和虚拟化的智能故障自愈调度方法和装置 |
| CN114884836A (zh) * | 2022-04-28 | 2022-08-09 | 济南浪潮数据技术有限公司 | 一种虚拟机高可用方法、装置及介质 |
| CN115484267A (zh) * | 2022-09-15 | 2022-12-16 | 中国联合网络通信集团有限公司 | 多集群部署处理方法、装置、电子设备和存储介质 |
| CN116074184A (zh) * | 2023-03-21 | 2023-05-05 | 云南莱瑞科技有限公司 | 一种电力调度中心网络故障预警系统 |
| US11693694B2 (en) | 2021-03-29 | 2023-07-04 | Red Hat, Inc. | Migrating quantum services from quantum computing devices to quantum simulators |
| CN116401009A (zh) * | 2023-03-28 | 2023-07-07 | 北京益安在线科技股份有限公司 | 一种基于kvm虚拟化的智能管理系统 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI686696B (zh) | 2018-08-14 | 2020-03-01 | 財團法人工業技術研究院 | 計算節點及其失效偵測方法與雲端資料處理系統 |
| CN109144765B (zh) * | 2018-08-21 | 2024-02-02 | 平安科技（深圳）有限公司 | 报表生成方法、装置、计算机设备及存储介质 |
| CN111666170B (zh) * | 2020-05-29 | 2024-04-12 | 中国工商银行股份有限公司 | 基于分布式框架的故障节点处理方法及装置 |
| CN112148485A (zh) * | 2020-09-16 | 2020-12-29 | 杭州安恒信息技术股份有限公司 | 超融合平台故障恢复方法、装置、电子装置和存储介质 |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102629224A (zh) * | 2012-04-26 | 2012-08-08 | 广东电子工业研究院有限公司 | 一种基于云平台的一体化数据容灾方法及其装置 |
| CN102984739A (zh) * | 2011-09-07 | 2013-03-20 | 中兴通讯股份有限公司 | 故障信息处理方法及装置 |
| CN103152419A (zh) * | 2013-03-08 | 2013-06-12 | 中标软件有限公司 | 一种云计算平台的高可用集群管理方法 |
| CN103167004A (zh) * | 2011-12-15 | 2013-06-19 | 中国移动通信集团上海有限公司 | 云平台主机系统故障修复方法及云平台前端控制服务器 |
| US20140019621A1 (en) * | 2012-07-16 | 2014-01-16 | Ntt Docomo, Inc. | Hierarchical system for managing a plurality of virtual machines, method and computer program |
| CN103607296A (zh) * | 2013-11-01 | 2014-02-26 | 杭州华三通信技术有限公司 | 一种虚拟机故障处理方法和设备 |
| CN104392175A (zh) * | 2014-11-26 | 2015-03-04 | 华为技术有限公司 | 一种云计算系统中云应用攻击行为处理方法、装置及系统 |
| CN105103132A (zh) * | 2013-01-15 | 2015-11-25 | 微软技术许可有限责任公司 | 在升级期间修复云服务 |
| WO2016013199A1 (ja) * | 2014-07-22 | 2016-01-28 | 日本電気株式会社 | 仮想化基盤管理装置、仮想化基盤管理システム、仮想化基盤管理方法、及び、仮想化基盤管理プログラムが記録された記録媒体 |
| CN105306225A (zh) * | 2015-11-03 | 2016-02-03 | 国云科技股份有限公司 | 一种基于Openstack的物理机远程关机方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5949759A (en) * | 1995-12-20 | 1999-09-07 | International Business Machines Corporation | Fault correlation system and method in packet switching networks |
| CN102012789B (zh) * | 2009-09-07 | 2014-03-12 | 云端容灾有限公司 | 集中管理式备份容灾系统 |
| US8524457B2 (en) * | 2009-09-22 | 2013-09-03 | William Patterson | Method for the selection of specific affinity binders by homogeneous noncompetitive assay |
| CN102394774B (zh) * | 2011-10-31 | 2014-03-26 | 广东电子工业研究院有限公司 | 一种云计算操作系统的控制器服务状态监控和故障恢复方法 |
| CN103095506A (zh) * | 2013-02-06 | 2013-05-08 | 浪潮电子信息产业股份有限公司 | 一种云环境下基于设备健康状态的资源调整方法 |
-
2016
- 2016-03-10 CN CN201610136817.0A patent/CN107179957B/zh active Active
-
2017
- 2017-02-14 TW TW106104781A patent/TWI746512B/zh active
- 2017-02-23 WO PCT/CN2017/074618 patent/WO2017152763A1/zh active Application Filing
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102984739A (zh) * | 2011-09-07 | 2013-03-20 | 中兴通讯股份有限公司 | 故障信息处理方法及装置 |
| CN103167004A (zh) * | 2011-12-15 | 2013-06-19 | 中国移动通信集团上海有限公司 | 云平台主机系统故障修复方法及云平台前端控制服务器 |
| CN102629224A (zh) * | 2012-04-26 | 2012-08-08 | 广东电子工业研究院有限公司 | 一种基于云平台的一体化数据容灾方法及其装置 |
| US20140019621A1 (en) * | 2012-07-16 | 2014-01-16 | Ntt Docomo, Inc. | Hierarchical system for managing a plurality of virtual machines, method and computer program |
| CN105103132A (zh) * | 2013-01-15 | 2015-11-25 | 微软技术许可有限责任公司 | 在升级期间修复云服务 |
| CN103152419A (zh) * | 2013-03-08 | 2013-06-12 | 中标软件有限公司 | 一种云计算平台的高可用集群管理方法 |
| CN103607296A (zh) * | 2013-11-01 | 2014-02-26 | 杭州华三通信技术有限公司 | 一种虚拟机故障处理方法和设备 |
| WO2016013199A1 (ja) * | 2014-07-22 | 2016-01-28 | 日本電気株式会社 | 仮想化基盤管理装置、仮想化基盤管理システム、仮想化基盤管理方法、及び、仮想化基盤管理プログラムが記録された記録媒体 |
| CN104392175A (zh) * | 2014-11-26 | 2015-03-04 | 华为技术有限公司 | 一种云计算系统中云应用攻击行为处理方法、装置及系统 |
| CN105306225A (zh) * | 2015-11-03 | 2016-02-03 | 国云科技股份有限公司 | 一种基于Openstack的物理机远程关机方法 |
Non-Patent Citations (1)
| Title |
|---|
| 武义涵等: "一种基于模型的云计算容错机制开发方法", 《计算机研究与发展》 * |
Cited By (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108062471A (zh) * | 2017-12-19 | 2018-05-22 | 龙岩学院 | 一种云计算网络运行过程中的风险处理方法及设备 |
| CN108062471B (zh) * | 2017-12-19 | 2021-07-20 | 龙岩学院 | 一种云计算网络运行过程中的风险处理方法及设备 |
| CN108153618A (zh) * | 2017-12-22 | 2018-06-12 | 国网浙江杭州市萧山区供电有限公司 | 硬盘数据恢复方法、装置及硬盘数据恢复设备 |
| CN108153618B (zh) * | 2017-12-22 | 2021-12-03 | 国网浙江杭州市萧山区供电有限公司 | 硬盘数据恢复方法、装置及硬盘数据恢复设备 |
| CN108763039A (zh) * | 2018-04-02 | 2018-11-06 | 阿里巴巴集团控股有限公司 | 一种业务故障模拟方法、装置及设备 |
| CN109587331A (zh) * | 2018-11-26 | 2019-04-05 | 广州微算互联信息技术有限公司 | 云手机故障自动修复的方法与系统 |
| CN109587331B (zh) * | 2018-11-26 | 2021-02-02 | 广州微算互联信息技术有限公司 | 云手机故障自动修复的方法与系统 |
| CN109614260A (zh) * | 2018-11-28 | 2019-04-12 | 北京小米移动软件有限公司 | 通信故障判断方法、装置和存储介质 |
| CN110262917A (zh) * | 2019-05-15 | 2019-09-20 | 平安科技（深圳）有限公司 | 宿主机自愈方法、装置、计算机设备及存储介质 |
| CN110247821A (zh) * | 2019-06-04 | 2019-09-17 | 平安科技（深圳）有限公司 | 一种故障检测方法及相关设备 |
| CN110247821B (zh) * | 2019-06-04 | 2022-10-18 | 平安科技（深圳）有限公司 | 一种故障检测方法及相关设备 |
| CN110377396A (zh) * | 2019-07-04 | 2019-10-25 | 深圳先进技术研究院 | 一种虚拟机自动迁移方法、系统及电子设备 |
| CN111273995A (zh) * | 2020-01-09 | 2020-06-12 | 武汉思普崚技术有限公司 | 一种虚拟微隔离网络的安全调度方法及系统 |
| CN111212079A (zh) * | 2020-01-09 | 2020-05-29 | 武汉思普崚技术有限公司 | 一种基于业务的微隔离流量牵引方法及系统 |
| CN111262840A (zh) * | 2020-01-09 | 2020-06-09 | 武汉思普崚技术有限公司 | 一种虚拟网络的攻击面转移方法及系统 |
| CN111277568A (zh) * | 2020-01-09 | 2020-06-12 | 武汉思普崚技术有限公司 | 一种分布式虚拟网络的隔离攻击方法及系统 |
| CN111258711A (zh) * | 2020-01-09 | 2020-06-09 | 武汉思普崚技术有限公司 | 一种多协议的网络微隔离方法及系统 |
| CN111262841A (zh) * | 2020-01-09 | 2020-06-09 | 武汉思普崚技术有限公司 | 一种虚拟微隔离网络的资源调度方法及系统 |
| CN111176795A (zh) * | 2020-01-09 | 2020-05-19 | 武汉思普崚技术有限公司 | 一种分布式虚拟网络的动态迁移方法及系统 |
| CN111224990A (zh) * | 2020-01-09 | 2020-06-02 | 武汉思普崚技术有限公司 | 一种分布式微隔离网络的流量牵引方法及系统 |
| CN111224989A (zh) * | 2020-01-09 | 2020-06-02 | 武汉思普崚技术有限公司 | 一种虚拟微隔离网络的攻击面防护方法及系统 |
| CN111176795B (zh) * | 2020-01-09 | 2022-05-03 | 武汉思普崚技术有限公司 | 一种分布式虚拟网络的动态迁移方法及系统 |
| CN111399978A (zh) * | 2020-03-02 | 2020-07-10 | 中铁信弘远(北京)软件科技有限责任公司 | 一种基于OpenStack的故障迁移系统及迁移方法 |
| CN111796959A (zh) * | 2020-06-30 | 2020-10-20 | 中国工商银行股份有限公司 | 宿主机容器自愈方法、装置及系统 |
| CN111796959B (zh) * | 2020-06-30 | 2023-08-08 | 中国工商银行股份有限公司 | 宿主机容器自愈方法、装置及系统 |
| CN112165495A (zh) * | 2020-10-13 | 2021-01-01 | 北京计算机技术及应用研究所 | 一种基于超融合架构防DDoS攻击方法、装置及超融合集群 |
| US11693694B2 (en) | 2021-03-29 | 2023-07-04 | Red Hat, Inc. | Migrating quantum services from quantum computing devices to quantum simulators |
| CN113157476A (zh) * | 2021-04-10 | 2021-07-23 | 作业帮教育科技（北京）有限公司 | 虚拟云环境中显卡故障的处理方法及装置 |
| CN114780272A (zh) * | 2022-04-18 | 2022-07-22 | 北京亚康万玮信息技术股份有限公司 | 基于共享存储和虚拟化的智能故障自愈调度方法和装置 |
| CN114780272B (zh) * | 2022-04-18 | 2023-03-17 | 北京亚康万玮信息技术股份有限公司 | 基于共享存储和虚拟化的智能故障自愈调度方法和装置 |
| CN114884836A (zh) * | 2022-04-28 | 2022-08-09 | 济南浪潮数据技术有限公司 | 一种虚拟机高可用方法、装置及介质 |
| CN115484267A (zh) * | 2022-09-15 | 2022-12-16 | 中国联合网络通信集团有限公司 | 多集群部署处理方法、装置、电子设备和存储介质 |
| CN116074184A (zh) * | 2023-03-21 | 2023-05-05 | 云南莱瑞科技有限公司 | 一种电力调度中心网络故障预警系统 |
| CN116401009A (zh) * | 2023-03-28 | 2023-07-07 | 北京益安在线科技股份有限公司 | 一种基于kvm虚拟化的智能管理系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2017152763A1 (zh) | 2017-09-14 |
| TWI746512B (zh) | 2021-11-21 |
| CN107179957B (zh) | 2020-08-25 |
| TW201738747A (zh) | 2017-11-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107179957A (zh) | 物理机故障分类处理方法、装置和虚拟机恢复方法、系统 | |
| US7975165B2 (en) | Management of information technology risk using virtual infrastructures | |
| Chen et al. | Towards intelligent incident management: why we need it and how we make it | |
| CN103440160B (zh) | 虚拟机恢复方法和虚拟机迁移方法以及装置与系统 | |
| Nguyen et al. | Availability modeling and analysis of a data center for disaster tolerance | |
| CN104685830B (zh) | 故障管理的方法、实体和系统 | |
| Notaro et al. | A survey of aiops methods for failure management | |
| CN105187249B (zh) | 一种故障恢复方法及装置 | |
| CN105024879B (zh) | 虚拟机故障检测、恢复系统及虚拟机检测、恢复、启动方法 | |
| Araujo et al. | Software aging issues on the eucalyptus cloud computing infrastructure | |
| US9734015B2 (en) | Pre-boot self-healing and adaptive fault isolation | |
| CN106850260A (zh) | 一种虚拟化资源管理平台的部署方法和装置 | |
| Endo et al. | Minimizing and managing cloud failures | |
| CN103812699A (zh) | 基于云计算的监控管理系统 | |
| US8977895B2 (en) | Multi-core diagnostics and repair using firmware and spare cores | |
| CN105005509B (zh) | 一种基于运行时模型的云计算容错机制配置方法 | |
| Nguyen et al. | A comprehensive availability modeling and analysis of a virtualized servers system using stochastic reward nets | |
| CN106789306A (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
| CN104570831A (zh) | 过程控制系统和方法 | |
| CN108199901A (zh) | 硬件报修方法、系统、设备、硬件管理服务器与存储介质 | |
| Di Martino et al. | Measuring the resiliency of extreme-scale computing environments | |
| Nguyen et al. | A comprehensive sensitivity analysis of a data center network with server virtualization for business continuity | |
| Fadaei Tehrani et al. | A threshold sensitive failure prediction method using support vector machine | |
| Kikuchi et al. | Evaluation of operational vulnerability in cloud service management using model checking | |
| Matos et al. | Evaluation of a disaster recovery solution through fault injection experiments |
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 | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230529 Address after: Room 1-2-A06, Yungu Park, No. 1008 Dengcai Street, Sandun Town, Xihu District, Hangzhou City, Zhejiang Province Patentee after: Aliyun Computing Co.,Ltd. Address before: Box 847, four, Grand Cayman capital, Cayman Islands, UK Patentee before: ALIBABA GROUP HOLDING Ltd. |
|
| TR01 | Transfer of patent right |