CN106817238A - 虚拟机修复方法、虚拟机装置、系统及业务功能网元 - Google Patents

虚拟机修复方法、虚拟机装置、系统及业务功能网元 Download PDF

Info

Publication number
CN106817238A
CN106817238A CN201510863669.8A CN201510863669A CN106817238A CN 106817238 A CN106817238 A CN 106817238A CN 201510863669 A CN201510863669 A CN 201510863669A CN 106817238 A CN106817238 A CN 106817238A
Authority
CN
China
Prior art keywords
virtual machine
virtual
standby
host
repair method
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.)
Withdrawn
Application number
CN201510863669.8A
Other languages
English (en)
Inventor
张川
虞振峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201510863669.8A priority Critical patent/CN106817238A/zh
Priority to PCT/CN2016/104293 priority patent/WO2017092539A1/zh
Publication of CN106817238A publication Critical patent/CN106817238A/zh
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种虚拟机修复方法、虚拟机装置、系统及业务功能网元,通过双虚拟机中的第一虚拟机装置对第二虚拟机装置是否产生需要进行虚拟机修复的目标告警进行检测,而不是仅依靠管理节点,通过这种双机系统内部的自侦测方式可以及时发现双虚拟机中的内部故障;且在第一主虚拟机检测到第二虚拟机装置产生目标告警时,则直接发起对备虚拟机的修改,而不是将告警逐级发给上层的管理节点,再等管理节点重新分析后下发修改指令,解除了对上层管理节点的依赖,可靠性更好,且故障修复效率更高,方式更为灵活有效。

Description

虚拟机修复方法、虚拟机装置、系统及业务功能网元
技术领域
本发明涉及通信领域,具体涉及一种虚拟机修复方法、虚拟机装置、系统及业务功能网元。
背景技术
计算机/通讯虚拟化领域中,特别是电信NFV(Network FunctionVirtualization,网络功能虚拟化)协议架构中,通常使用双机(主、备虚拟机)方式创建一个VNF(Virtualized Network Function,虚拟的网络功能)实例实现容灾备份。在管理节点上,双机VNF实例作为一个功能节点呈现,管理节点对双机VNF实例的故障进行监控并告警,只有当双机VNF实例中主、备虚拟机都异常的时候才产生致命告警,并且在告警后只能使用手工方式重启或重生业务实例的方式完成故障修复,但是,当双机VNF实例发生双机系统内部故障和业务功能故障时,由于双机VNF实例所在虚拟机仍处于工作状态,管理节点无法发现此故障(备虚拟机故障时,主虚拟机状态正常,VNF实例正常;主虚拟机故障时,实时倒换到备机后状态正常,VNF实例正常;业务功能故障时,不影响虚拟机对外状态,VNF实例正常),更不可能自动修复。因此,当管理节点发现双机VNF实例故障时,必然是主、备虚拟机都已故障,已经造成了业务中断,可见,使用双机部署VNF实例进行容灾保护的机制不够健全,系统可靠性不足。另外,在其他虚拟化领域中,对于虚拟机层的故障通常是以告警方式上报上级管理节点,由上级管理节点对上报的虚拟机告警进行区分。对于致命故障产生的告警,需要对虚拟机进行重生或重启才能使故障修复,而重生或重启的指令则是通过上层管理节点决策发出,在这种至上而下的管理模式下,管理节点和业务功能节点(也即业务功能网元)之间需要制定特殊的软件接口规范。这样对系统的开放性是一种破坏,对于不符合约定接口规范的虚拟机就无法接入,且由上层管理节点决策通过特定的软件接口规范下发重修指令并不够及时,降低了故障修复的效率。
发明内容
本发明要解决的主要技术问题是,提供一种虚拟机修复方法、虚拟机装置、系统及业务功能网元,解决现有管理节点不能及时发现双虚拟机内部故障,以及发现故障后修复效率低的问题。
为解决上述技术问题,本发明提供一种虚拟机修复方法,包括:
双虚拟机中的第一虚拟机装置检测到第二虚拟机装置产生需要进行虚拟机修复的目标告警;
所述第一虚拟机装置发起对所述第二虚拟机装置进行修复。
在本发明的一种实施例中,所述第一虚拟机装置检测到第二虚拟机装置产生目标告警包括:
所述第一虚拟机装置接收到所述第二虚拟机装置在异常中断故障时发送的故障通知;
所述第一虚拟机装置根据所述故障通知判定所述第二虚拟机装置产生目标告警。
在本发明的一种实施例中,所述第一虚拟机装置检测第二虚拟机装置产生目标告警之前,包括:
所述第一虚拟机装置由备虚拟机切换为主虚拟机,所述第二虚拟机装置由主虚拟机切换为备虚拟机。
在本发明的一种实施例中,所述第一虚拟机装置检测第二虚拟机装置产生目标告警包括:
所述第一虚拟机装置由备虚拟机切换为主虚拟机后,检测所述第二虚拟机装置是否正常,如否,则判定所述第二虚拟机装置产生目标告警。
在本发明的一种实施例中,所述目标故障包括异常中断故障和致命业务功能异常中的至少一种。
在本发明的一种实施例中,述第一虚拟机装置检测所述第二虚拟机装置是否正常包括:检测所述第二虚拟机装置是否在位或状态是否异常。
在本发明的一种实施例中,所述第一虚拟机装置发起对所述第二虚拟机装置进行修复包括:
所述第一虚拟机装置发起重启所述第二虚拟机装置的重启流程或发起对所述第二虚拟机装置进行重生的流程。
在本发明的一种实施例中,所述第一虚拟机装置发起对所述第二虚拟机装置进行重生的流程之前,包括:判断当前是否存在未处理的虚拟机重生流程,如是,则延迟预设时长后再发起,或对所述目标告警进行重新检测。
在本发明的一种实施例中,所述第一虚拟机装置发起对所述第二虚拟机装置进行重生的流程包括:
所述第一虚拟机装置向虚拟机管理节点发送删除所述第二虚拟机装置的删除指令;
所述第一虚拟机装置在所述第二虚拟机装置删除后,根据预设重生策略选择以所述第二虚拟机装置原资源设置或以调整后的第二虚拟机装置资源设置向所述虚拟机管理节点发送虚拟机创建指令。
在本发明的一种实施例中,所述第一虚拟机装置以调整后的第二虚拟机装置资源设置向所述虚拟机管理节点发送虚拟机创建指令时,还包括:
所述第一虚拟机装置在新第二虚拟机装置创建好之后发起主备切换,将所述新第二虚拟机装置切换为主虚拟机,自身切换为备虚拟机;
所述新第二虚拟机装置向所述虚拟机管理节点发送删除所述第一虚拟机装置的删除指令;
所述新第二虚拟机装置在所述第一虚拟机装置删除后,以自身的资源设置向所述虚拟机管理节点发送虚拟机创建指令。
为了解决上述问题,本发明还提供了一种第一虚拟机装置,包括告警检测模块和虚拟机修复模块;
所述告警检测模块用于检测第二虚拟机装置是否产生需要进行虚拟机修复的目标告警;
所述虚拟机修复模块用于在所述告警检测模块检测结果为是时,发起对所述第二虚拟机装置进行修复。
在本发明的一种实施例中,所述告警检测模块包括第一告警检测子模块,用于接收所述第二虚拟机装置在异常中断故障时发送的故障通知时,判定所述第二虚拟机装置产生目标告警。
在本发明的一种实施例中,所述第一虚拟机装置还包括主备切换模块,用于在所述第二虚拟机装置在产生故障时发起主备切换时,将所述第一虚拟机装置切换为主虚拟机。
在本发明的一种实施例中,所述告警检测模块包括第二告警检测子模块,用于在所述第一虚拟机装置切换为主虚拟机后,检测所述第二虚拟机装置是否正常,如否,则判定所述第二虚拟机装置产生目标告警。
在本发明的一种实施例中,所述虚拟机修复模块包括重启子模块或重生子模块;
所述重启子模块用于在所述告警检测模块检测结果为是时,发起重启所述第二虚拟机装置的重启流程;
所述重生子模块用于在所述告警检测模块检测结果为是时,发起对所述第二虚拟机装置进行重生的流程。
在本发明的一种实施例中,所述虚拟机修复模块包括重生子模块时,所述重生子模块包括重生发起单元以及重建单元;
所述重生发起单元用于向虚拟机管理节点发送删除所述第二虚拟机装置的删除指令;
所述重建单元用于在所述第二虚拟机装置删除后,根据预设重生策略选择以所述第二虚拟机装置原资源设置或以调整后的第二虚拟机装置资源设置向所述虚拟机管理节点发送虚拟机创建指令。
为了解决上述问题,本发明还提供了一种虚拟机系统,包括第二虚拟机装置和如上所述的第二虚拟机装置;
所述第一虚拟机装置用于检测到第二虚拟机装置产生需要进行虚拟机修复的目标告警时,发起对所述第二虚拟机装置进行修复。
为了解决上述问题,本发明还提供了一种业务功能网元,包括如上所述的虚拟机系统。
本发明的有益效果是:
本发明提供的虚拟机修复方法、虚拟机装置、系统及业务功能网元,通过双虚拟机中的第一虚拟机装置对第二虚拟机装置是否产生需要进行虚拟机修复的目标告警进行检测,而不是仅依靠管理节点,通过这种双机系统内部的自侦测方式可以及时发现双虚拟机中的内部故障;且在第一主虚拟机检测到第二虚拟机装置产生目标告警时,则直接发起对备虚拟机的修改,而不是将告警逐级发给上层的管理节点,再等管理节点重新分析后下发修改指令,解除了对上层管理节点的依赖,可靠性更好,且故障修复效率更高,方式更为灵活有效。
附图说明
图1为本发明实施例一提供的虚拟机修复方法流程示意图;
图2为本发明实施例一提供的虚拟机重生流程发起示意图;
图3为本发明实施例一提供的调整资源设置时进行重生的流程示意图;
图4为本发明实施例二提供的虚拟机系统结构示意图;
图5为本发明实施例二提供的第一虚拟机装置结构示意图;
图6为本发明实施例二提供的第一虚拟机装置的另一结构示意图;
图7为本发明实施例三提供的主机业务功能异常时进行重生的流程示意图;
图8为本发明实施例三提供的主机异常中断时进行重生的流程示意图;
图9为本发明实施例三提供的备机异常中断时进行重生的流程示意图。
具体实施方式
本发明通过双虚拟机中的自侦测可以及时发现双虚拟机中的内部故障;且在第一虚拟机装置检测到第二虚拟机装置产生目标告警时,则直接发起对第二虚拟机装置的修改,解除了对上层管理节点的依赖,可靠性更高,且故障修复效率更高,方式更为灵活有效。下面通过具体实施方式结合附图对本发明作进一步详细说明。
实施例一:
请参见图1所示,本实施例中的虚拟机修复方法包括:
步骤101:双虚拟机中的第一虚拟机装置检测到第二虚拟机装置产生需要进行虚拟机修复的目标告警;
步骤102:第一虚拟机装置发起对第二虚拟机装置进行修复。
应当理解的是,本实施例中第一虚拟机装置和第二虚拟机装置的主备倒换关系是可动态变化的,第一虚拟机装置作为备虚拟机,第二虚拟机装置作为主虚拟机时,第二虚拟机装置也即可执行第一虚拟机装置的所有功能,包括但不限于告警检测、虚拟机修复等功能。第一虚拟机装置具有第二虚拟机装置的所有功能,包括告警上报以及利用第三方监测模块进行故障检测等功能。
上述步骤101中,第一虚拟机装置检测到第二虚拟机装置产生目标告警的情况至少包含以下几种。
情况一:步骤101中的第一虚拟机装置为主虚拟机且在正常工作过程中,作为备虚拟机的第二虚拟机装置出现异常中断故障,此时第一虚拟机装置会接收到第二虚拟机装置发送的故障通知,从而判断并记录该第二虚拟机装置产生了目标告警。本实施例中,第二虚拟机装置可通过自身的故障侦测单元检测到出现异常中断故障,其向第一虚拟机装置发送的故障通知可以为SNMP(SimpleNetwork Management Protocol,简单网络管理协议)Trap消息,处于正常工作状态的第一虚拟机装置接收到该SNMP Trap消息后,即可将此异常记未出现致命故障。应当理解的是,本实施例中第二虚拟机装置的异常中断故障也可采用或结合其他第三方监测模块进行监测。
情况二:步骤101中的第一虚拟机装置之前为备虚拟机,现由备虚拟机切换为主虚拟机;第二虚拟机装置则原为主虚拟机,产生需要进行主、备切换的故障发起主备切换,由主虚拟机切换为备虚拟机。第一虚拟机装置切换为主虚拟机后,检测第二虚拟机装置(也即原主虚拟机)是否正常,如否,则判定该第二虚拟机装置产生目标告警。
本实施例中,主虚拟机产生的需要进行主备切换的故障包括异常中断故障和致命业务功能异常中的至少一种;下面分别为以异常中断故障和致命业务功能异常进行示例说明。
原主虚拟机(也即第二虚拟机装置)出现异常中断故障时,进行主备切换,切换为第二虚拟机装置,同时向原备虚拟机(也即切换后的第一虚拟机装置)发送故障通知;由于此时切换后的第一虚拟机装置还未完全启动,因此接收不到该故障通知,在其启动后,再对第二虚拟机装置(也即原主虚拟机)进行检测看其是否正常,此处检测其是否正常包括但不限于检测其是否在位和/或状态是否异常,例如当检测到不在位或状态异常时,则判断其不正常,记录该第二虚拟机装置产生目标告警。本实施例中,第二虚拟机也可通过自身的故障侦测单元检测到出现异常中断故障,向切换为主虚拟机的第一虚拟机装置发送的故障通知也可以为SNMP Trap消息。应当理解的是,本实施例中第二虚拟机装置的异常中断故障也可采用或结合其他第三方监测模块进行监测。
原主虚拟机(也即第二虚拟机装置)出现致命业务功能异常(包括但不限于业务进程状态异常(如出现业务关键进程丢失)、虚拟机资源故障、网络资源故障等)时,进行主备切换,切换为第二虚拟机装置。原备虚拟机(也即切换后的第一虚拟机装置)启动后,对第二虚拟机装置(也即原主虚拟机)进行检测看其是否正常,此处检测其是否正常也包括但不限于检测其是否在位和/或状态是否异常,例如当检测到不在位或状态异常时,则判断其不正常,记录该第二虚拟机装置产生目标告警。本实施例中,原主虚拟机可通过自身的业务功能轮询检测单元检测是否出现致命业务功能异常,也可采用或结合其他第三方监测模块进行监测。
步骤102中,第一虚拟机装置发起第二虚拟机装置修复包括:第一虚拟机装置发起重启第二虚拟机装置的重启流程或发起对第二虚拟机装置进行重生的流程。
第一虚拟机装置发起重启第二虚拟机装置的重启流程时,可通过向虚拟机管理节点发起相应的重启指令,经虚拟机管理节点实现对第二虚拟机装置的重启;也可以在双虚拟机内部通过相应的重启指令完成第二虚拟机装置的重启,而不经过虚拟机管理节点。
第一虚拟机装置发起对第二虚拟机装置进行重生时,请参见图2所示,包括:
步骤201:第一虚拟机装置向虚拟机管理节点发送删除第二虚拟机装置的删除指令;
步骤202:第一虚拟机装置在第二虚拟机装置删除后,根据预设重生策略选择以第二虚拟机装置原资源设置或以调整后的第二虚拟机装置资源设置向虚拟机管理节点发送虚拟机创建指令完成第二虚拟机装置的重建。
本实施例中的预设重生策略可根据虚拟机所在的业务功能网元自身决策,因此更为灵活,且扩展性更强。例如可具体根据业务功能网元自身的类型等进行决策。
上述步骤202中,第一虚拟机装置根据当前业务需要等因素以调整后的第二虚拟机装置资源设置向虚拟机管理节点发送虚拟机创建指令时,请参见图3所示,还包括:
步骤301:第一虚拟机装置在新第二虚拟机装置创建好之后发起主备切换(该主备切换时该第一虚拟机装置与新第二虚拟机装置的资源不同导致的),将新第二虚拟机装置切换为主虚拟机,自身切换为待删除备虚拟机;
步骤302:新第二虚拟机装置向虚拟机管理节点发送删除待删除第一虚拟机装置的删除指令;
步骤303:新第二虚拟机装置在待删除虚拟机删除后,以与自身的资源相同的设置向虚拟机管理节点发送虚拟机创建指令;至此,重建流程才完成。
另外,本实施例中,虚拟机的重生功能可通过开关控制。
同时由于虚拟机重生请求具有唯一性,对于系统中可能出现的频繁目标告警可以采用相应的机制保护虚拟机重生的唯一完整性。因此本实施例中的第一虚拟机装置发起对第二虚拟机装置进行重生的流程之前,包括:判断当前是否还存在未处理的虚拟机重生流程,如是,则延迟预设时长后再发起,或对目标告警进行重新检测。
可见,本实施例中虚拟机系统的内部故障可通过虚拟机自侦测发现,且虚拟机的重生也可有虚拟机自身发起,脱离了对管理节点的依赖,对管理节点的其他容灾技术进行补充。另外,虚拟机的重生也可由虚拟机所在业务功能网元自身决策,更为方便灵活,且扩展性更好。
实施例二:
本实施例提供了一种虚拟机系统,请参见图4所示,包括双虚拟机,双虚拟机包括第一虚拟机装置1和第二虚拟机装置2,第一虚拟机装置1用于检测到第二虚拟机装置2产生目标告警时,发起第二虚拟机装置2修复;该目标告警是指需要对虚拟机进行修复的告警。
本实施例中的双虚拟机装置上都可设置故障检测模块、告警检测模块以及虚拟机修复模块;故障检测模块用于通过自身或第三方监测模块实现故障的检测;告警模块用于发现目标告警,并触发虚拟机修复模块进行虚拟机修复。下面以第一虚拟机装置1的具体结构结合产生目标告警的几种情况进行示例说明。
请参见图5所示,第一虚拟机装置1具体包括告警检测模块11和虚拟机修复模块12;
告警检测模块11用于检测第二虚拟机装置是否产生需要进行虚拟机修复的目标告警;
虚拟机修复模块12用于在告警检测模块11检测结果为是时,发起对第二虚拟机装置进行修复。
告警检测模块11包括第一告警检测子模块111,用于在第一虚拟机装置1为主虚拟机,且在正常工作过程中,为备虚拟机的第二虚拟机装置2出现异常中断故障时,接收第二虚拟机装置2发送的故障通知,从而发现该第二虚拟机装置产生了目标告警。本实施例中,第二虚拟机装置2可通过自身的故障侦测单元检测到出现异常中断故障,也即故障检测模块包括故障侦测单元,其向第一虚拟机装置1发送的故障通知可以为SNMP(Simple Network ManagementProtocol,简单网络管理协议)Trap消息,处于正常工作状态的第一虚拟机装置1的告警模块接收到该SNMP Trap消息后,即可将此异常记未出现致命故障。应当理解的是,本实施例中第二虚拟机装置2的异常中断故障也可采用或结合其他第三方监测模块进行监测,在监测到故障后通知其故障检测模块。
告警检测模块11还可包括第二告警检测子模块112。第一虚拟机装1为原备虚拟机,其具有主备切换模块,第二虚拟机装置2则为原主虚拟机;第二虚拟机装置2在产生需要进行主备切换的故障时发起主备切换,第二虚拟机装置2切换为备虚拟机,第一虚拟机装置1的主备切换模块将第一虚拟机装置1切换为主虚拟机。第一虚拟机装置1切换为主虚拟机后,其第二告警检测子模块112主动检测第二虚拟机装置2(也即原主虚拟机)是否正常,如否,则判定该第二虚拟机装置产生目标告警。
本实施例中,原第一虚拟机装置1产生的致命故障包括异常中断故障和致命业务功能异常中的至少一种;下面分别为以异常中断故障和致命业务功能异常进行示例说明。
原主虚拟机(即第二虚拟机装置2)出现异常中断故障时,进行主备切换,切换为作为备虚拟机的第二虚拟机装置2,同时向原备虚拟机(也即切换后的第一虚拟机装置1)发送故障通知;由于此时切换后的第一虚拟机装置1还未完全启动,因此其第二告警检测子模块112接收不到该故障通知,在其启动后,其第二告警检测子模块112再对第二虚拟机装置2(也即原主虚拟机)进行检测看其是否正常,此处检测其是否正常包括但不限于检测其是否在位和/或状态是否异常,例如当检测到不在位或状态异常时,则判断其不正常,记录该第二虚拟机装置2产生目标告警。本实施例中,原主虚拟机也可自身故障检测模块包括的故障侦测单元检测到出现异常中断故障,其向切换后的第一虚拟机装置1发送的故障通知也可以为SNMP Trap消息。应当理解的是,本实施例中原虚拟机的异常中断故障也可采用或结合其他第三方监测模块进行监测,然后将监测结果发给故障检测模块。
原主虚拟机(即第二虚拟机装置2)出现致命业务功能异常(包括但不限于业务进程状态异常(如出现业务关键进程丢失)、虚拟机资源故障、网络资源故障等)时,进行主备切换,切换为备虚拟机。原备虚拟机(也即切换后的第一虚拟机装置1)启动后,其第二告警检测子模块112主动对第二虚拟机装置2(也即原主虚拟机)进行检测看其是否正常,此处检测其是否正常也包括但不限于检测其是否在位和/或状态是否异常,例如当检测到不在位或状态异常时,则判断其不正常,记录该第二虚拟机装置2产生目标告警。本实施例中,原主虚拟机可通过自身故障检测模块的业务功能轮询检测单元检测是否出现致命业务功能异常,也可采用或结合其他第三方监测模块进行监测;将监测结果发给故障检测模块。
可见,本实施例中第一虚拟机装置和1第二虚拟机装置2中的故障检测模块可包括虚拟机自身的故障侦测单元和业务功能轮询检测单元,也可通过接受第三方监测模块发送的监测结果得到是否产生目标告警。且应当理解的是,本实施例中的故障检测模块还可用于检测其他类型的告警,并将告警发给告警模块,告警模块则可对收到的告警进行不同级别的筛选和处理;例如对于筛选出的目标告警,则触发虚拟机修复模块进行虚拟机修复。
请参见图6所示,第一虚拟机装置1的虚拟机修复模块12包括重启子模块121或重生子模块122;
重启子模块121用于在告警检测模块11检测结果为是时,发起重启第二虚拟机装置2的重启流程;
重生子模块122用于在告警检测模块11检测结果为是时,发起对第二虚拟机装置2进行重生的流程。
第一虚拟机装置1的重启子模块121发起重启第二虚拟机装置2的重启流程时,可通过向虚拟机管理节点发起相应的重启指令,经虚拟机管理节点实现对第二虚拟机装置2的重启;也可以在双虚拟机内部通过相应的重启指令完成第二虚拟机装置2的重启,而不经过虚拟机管理节点。
第一虚拟机装置1的重生子模块122包括重生发起单元1221以及重建单元1222;
重生发起单元1221用于向虚拟机管理节点发送删除所述第二虚拟机装置2的删除指令;
重建单元1222用于在第二虚拟机装置2删除后,根据预设重生策略选择以第二虚拟机装置2原资源设置或以调整后的第二虚拟机装置2资源设置向虚拟机管理节点发送虚拟机创建指令。
本实施例中的预设重生策略可根据虚拟机所在的业务功能网元自身决策,因此更为灵活,且扩展性更强。例如可具体根据业务功能网元自身的类型等进行决策。
虚拟机修复模块12的重建单元1222根据当前业务需要等因素以调整后的第二虚拟机装置资源设置向虚拟机管理节点发送虚拟机创建指令时,还包括:
第一虚拟机装置1在新第二虚拟机装置创建好之后发起主备切换(该主备切换时该第一虚拟机装置与新第二虚拟机装置的资源不同导致的),将新第二虚拟机装置切换为主虚拟机,自身切换为待删除的虚拟机;
新第二虚拟机装置的虚拟机修复模块向虚拟机管理节点发送删除待删除第一虚拟机装置的删除指令;
新第二虚拟机装置的虚拟机修复模块在待删除的第一虚拟机装置1删除后,以与自身的资源相同的设置向虚拟机管理节点发送虚拟机创建指令;至此,重建流程才完成。
另外,本实施例中,虚拟机的虚拟机修复模块12可通过开关控制。
同时由于虚拟机重生请求具有唯一性,对于系统中可能出现的频繁目标告警可以采用相应的机制保护虚拟机重生的唯一完整性。因此本实施例中的第一虚拟机装置的虚拟机修复模块12发起对第二虚拟机装置进行重生的流程之前,包括:判断之前是否还存在未处理的虚拟机重生流程,如是,则延迟预设时长后再发起,或对目标告警进行重新检测。
应当理解的是,本实施例中第一虚拟机装置1和第二虚拟机装置2的主备倒换关系是可动态变化的,第一虚拟机装置1作为备虚拟机,第二虚拟机装置2作为主虚拟机时,第二虚拟机装置2也即可执行上述第一虚拟机装置1的所有功能,包括但不限于告警检测、虚拟机修复等功能。第一虚拟机装置1具有上述第二虚拟机装置2的所有功能,包括告警上报以及利用第三方监测模块进行故障检测等功能。
本实施例中虚拟机系统的内部故障可通过虚拟机自侦测发现,且虚拟机的重生也可有虚拟机自身发起,虚拟机的重生也可由虚拟机所在业务功能网元自身决策,可脱离对管理节点的依赖,更为方便灵活、可靠,且扩展性更好。
实施例三:
为了更好的理解本发明,本实施例以电信NFV协议规范下的几种使用实例对本发明做进一步示例说明。
请参见图7所示,该图所示为利用本发明实现电信NFV协议架构下,采用双机部署的VNF实例在业务功能异常后重生自愈,包括以下步骤:
步骤701:主虚拟机A轮询检测业务进程,当发现关键业务进程丢失时,进行主备机切换,将主虚拟机切换为虚拟机B;
步骤702:切换后的主虚拟机B启动并检测虚拟机A状态,如果虚拟机A不在位或状态异常,产生致命告警;
步骤703:主虚拟机B发现该致命告警后,向管理节点发起删除虚拟机A;
步骤704:主虚拟机B在虚拟机A删除成功后,根据所在业务功能节点对于该告警类型对应的重生策略,以原虚拟机A的资源设置,发起新虚拟机(简称C)的重新创建;
步骤705:新虚拟机C创建成功后启动,从主虚拟机B上同步业务数据,成为新的备机。
在上述步骤704中,主虚拟机B以调整后的虚拟机A的资源设置,发起新虚拟机(简称C)的重新创建时,在步骤705中新虚拟机C创建成功后启动后,主虚拟机B进行主备切换,将主虚拟机切换为虚拟机C,自己切换为备虚拟机B;然后主虚拟机C向管理节点发起删除虚拟机B,在虚拟机B删除成功后,以自身的资源设置,发起新虚拟机(简称D)的重新创建;新虚拟机D创建成功后启动,从主虚拟机C上同步业务数据,成为新的备机。
请参见图8所示,该图所示为利用本发明实现电信NFV协议架构下,采用双机部署的VNF实例主机异常中断后重生自愈,包括以下步骤:
步骤801:主虚拟机A在出现异常中断故障时,进行主备机切换,将主虚拟机切换为虚拟机B;
步骤802:切换后的主虚拟机B启动并检测备虚拟机A状态,如果备虚拟机A不在位或状态异常,产生致命告警;
步骤803:主虚拟机B发现该致命告警后,向管理节点发起删除备虚拟机A;
步骤804:备虚拟机A删除成功后,根据该告警类型对应的重生策略,以原虚拟机A的资源设置,发起新虚拟机C的创建;
步骤805:新虚拟机C创建成功后启动,从主虚拟机B上同步业务数据,成为新的备虚拟机。
请参见图9所示,该图所示为利用本发明实现电信NFV协议架构下,采用双机部署的VNF实例备虚拟机异常中断后重生自愈,包括以下步骤:
步骤901:备虚拟机B在出现异常中断故障时,向主虚拟机A发送故障通知;
步骤902:主虚拟机A发现该故障通知记录致命告警后,向管理节点发起删除备虚拟机B;
步骤903:备虚拟机B删除成功后,根据该告警类型对应的重生策略,以原虚拟机B的资源设置,发起新虚拟机C的创建;
步骤904:新虚拟机C创建成功后启动,从主虚拟机A上同步业务数据,成为新的备虚拟机。
显然,本领域的技术人员应该明白,上述本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以,本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。

Claims (18)

1.一种虚拟机修复方法,其特征在于,包括:
双虚拟机中的第一虚拟机装置检测到第二虚拟机装置产生需要进行虚拟机修复的目标告警;
所述第一虚拟机装置发起对所述第二虚拟机装置进行修复。
2.如权利要求1所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置检测到第二虚拟机装置产生目标告警包括:
所述第一虚拟机装置接收到所述第二虚拟机装置在异常中断故障时发送的故障通知;
所述第一虚拟机装置根据所述故障通知判定所述第二虚拟机装置产生目标告警。
3.如权利要求1所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置检测第二虚拟机装置产生目标告警之前,包括:
所述第一虚拟机装置由备虚拟机切换为主虚拟机,所述第二虚拟机装置由主虚拟机切换为备虚拟机。
4.如权利要求3所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置检测第二虚拟机装置产生目标告警包括:
所述第一虚拟机装置由备虚拟机切换为主虚拟机后,检测所述第二虚拟机装置是否正常,如否,则判定所述第二虚拟机装置产生目标告警。
5.如权利要求3所述的虚拟机修复方法,其特征在于,所述目标故障包括异常中断故障和致命业务功能异常中的至少一种。
6.如权利要求4所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置检测所述第二虚拟机装置是否正常包括:检测所述第二虚拟机装置是否在位或状态是否异常。
7.如权利要求1-6任一项所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置发起对所述第二虚拟机装置进行修复包括:
所述第一虚拟机装置发起重启所述第二虚拟机装置的重启流程或发起对所述第二虚拟机装置进行重生的流程。
8.如权利要求7所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置发起对所述第二虚拟机装置进行重生的流程之前,包括:判断当前是否存在未处理的虚拟机重生流程,如是,则延迟预设时长后再发起,或对所述目标告警进行重新检测。
9.如权利要求7所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置发起对所述第二虚拟机装置进行重生的流程包括:
所述第一虚拟机装置向虚拟机管理节点发送删除所述第二虚拟机装置的删除指令;
所述第一虚拟机装置在所述第二虚拟机装置删除后,根据预设重生策略选择以所述第二虚拟机装置原资源设置或以调整后的第二虚拟机装置资源设置向所述虚拟机管理节点发送虚拟机创建指令。
10.如权利要求9所述的虚拟机修复方法,其特征在于,所述第一虚拟机装置以调整后的第二虚拟机装置资源设置向所述虚拟机管理节点发送虚拟机创建指令时,还包括:
所述第一虚拟机装置在新第二虚拟机装置创建好之后发起主备切换,将所述新第二虚拟机装置切换为主虚拟机,自身切换为备虚拟机;
所述新第二虚拟机装置向所述虚拟机管理节点发送删除所述第一虚拟机装置的删除指令;
所述新第二虚拟机装置在所述第一虚拟机装置删除后,以自身的资源设置向所述虚拟机管理节点发送虚拟机创建指令。
11.一种第一虚拟机装置,其特征在于,包括告警检测模块和虚拟机修复模块;
所述告警检测模块用于检测第二虚拟机装置是否产生需要进行虚拟机修复的目标告警;
所述虚拟机修复模块用于在所述告警检测模块检测结果为是时,发起对所述第二虚拟机装置进行修复。
12.如权利要求11所述的第一虚拟机装置,其特征在于,所述告警检测模块包括第一告警检测子模块,用于接收所述第二虚拟机装置在异常中断故障时发送的故障通知时,判定所述第二虚拟机装置产生目标告警。
13.如权利要求11所述的第一虚拟机装置,其特征在于,所述第一虚拟机装置还包括主备切换模块,用于在所述第二虚拟机装置在产生故障时发起主备切换时,将所述第一虚拟机装置切换为主虚拟机。
14.如权利要求13所述的第一虚拟机装置,其特征在于,所述告警检测模块包括第二告警检测子模块,用于在所述第一虚拟机装置切换为主虚拟机后,检测所述第二虚拟机装置是否正常,如否,则判定所述第二虚拟机装置产生目标告警。
15.如权利要求11-14任一项所述的第一虚拟机装置,其特征在于,所述虚拟机修复模块包括重启子模块或重生子模块;
所述重启子模块用于在所述告警检测模块检测结果为是时,发起重启所述第二虚拟机装置的重启流程;
所述重生子模块用于在所述告警检测模块检测结果为是时,发起对所述第二虚拟机装置进行重生的流程。
16.如权利要求15所述的第一虚拟机装置,其特征在于,所述虚拟机修复模块包括重生子模块时,所述重生子模块包括重生发起单元以及重建单元;
所述重生发起单元用于向虚拟机管理节点发送删除所述第二虚拟机装置的删除指令;
所述重建单元用于在所述第二虚拟机装置删除后,根据预设重生策略选择以所述第二虚拟机装置原资源设置或以调整后的第二虚拟机装置资源设置向所述虚拟机管理节点发送虚拟机创建指令。
17.一种虚拟机系统,其特征在于,包括第二虚拟机装置和如权利要求11-16任一项所述的第二虚拟机装置;
所述第一虚拟机装置用于检测到第二虚拟机装置产生需要进行虚拟机修复的目标告警时,发起对所述第二虚拟机装置进行修复。
18.一种业务功能网元,其特征在于,包括如权利要求17所述的虚拟机系统。
CN201510863669.8A 2015-11-30 2015-11-30 虚拟机修复方法、虚拟机装置、系统及业务功能网元 Withdrawn CN106817238A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201510863669.8A CN106817238A (zh) 2015-11-30 2015-11-30 虚拟机修复方法、虚拟机装置、系统及业务功能网元
PCT/CN2016/104293 WO2017092539A1 (zh) 2015-11-30 2016-11-02 虚拟机修复方法、虚拟机装置、系统及业务功能网元

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510863669.8A CN106817238A (zh) 2015-11-30 2015-11-30 虚拟机修复方法、虚拟机装置、系统及业务功能网元

Publications (1)

Publication Number Publication Date
CN106817238A true CN106817238A (zh) 2017-06-09

Family

ID=58796250

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510863669.8A Withdrawn CN106817238A (zh) 2015-11-30 2015-11-30 虚拟机修复方法、虚拟机装置、系统及业务功能网元

Country Status (2)

Country Link
CN (1) CN106817238A (zh)
WO (1) WO2017092539A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020103627A1 (zh) * 2018-11-21 2020-05-28 中兴通讯股份有限公司 一种基于虚机容灾的业务自愈方法、设备和存储介质
CN115396278A (zh) * 2022-08-11 2022-11-25 西安雷风电子科技有限公司 一种系统异常处理方法及装置
US11803452B2 (en) * 2019-02-14 2023-10-31 Nippon Telegraph And Telephone Corporation Duplexed operation system and method therefor

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101895540A (zh) * 2010-07-12 2010-11-24 中兴通讯股份有限公司 用于应用服务进程守护的系统和方法
CN102801806A (zh) * 2012-08-10 2012-11-28 薛海强 一种云计算系统及云计算资源管理方法
CN103019849A (zh) * 2012-12-31 2013-04-03 无锡城市云计算中心有限公司 云计算环境下的虚拟机管理方法
CN104572241A (zh) * 2013-10-18 2015-04-29 南京中兴新软件有限责任公司 应用程序的切换方法及装置、系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102110217B (zh) * 2009-12-28 2013-07-24 北京安码科技有限公司 一种通过虚拟机岗位轮换实现自动修复的方法
CN102708027B (zh) * 2012-05-11 2015-08-12 中兴通讯股份有限公司 一种避免通信设备运行中断的方法及系统
CN102917064B (zh) * 2012-10-23 2015-09-02 广州杰赛科技股份有限公司 基于私有云计算平台的双机热备方法
CN103838593B (zh) * 2012-11-22 2020-04-03 华为技术有限公司 恢复虚拟机的方法、系统及控制器、服务器、寄宿主机
CN103152419B (zh) * 2013-03-08 2016-04-20 中标软件有限公司 一种云计算平台的高可用集群管理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101895540A (zh) * 2010-07-12 2010-11-24 中兴通讯股份有限公司 用于应用服务进程守护的系统和方法
CN102801806A (zh) * 2012-08-10 2012-11-28 薛海强 一种云计算系统及云计算资源管理方法
CN103019849A (zh) * 2012-12-31 2013-04-03 无锡城市云计算中心有限公司 云计算环境下的虚拟机管理方法
CN104572241A (zh) * 2013-10-18 2015-04-29 南京中兴新软件有限责任公司 应用程序的切换方法及装置、系统

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020103627A1 (zh) * 2018-11-21 2020-05-28 中兴通讯股份有限公司 一种基于虚机容灾的业务自愈方法、设备和存储介质
US11803452B2 (en) * 2019-02-14 2023-10-31 Nippon Telegraph And Telephone Corporation Duplexed operation system and method therefor
CN115396278A (zh) * 2022-08-11 2022-11-25 西安雷风电子科技有限公司 一种系统异常处理方法及装置

Also Published As

Publication number Publication date
WO2017092539A1 (zh) 2017-06-08

Similar Documents

Publication Publication Date Title
US9684574B2 (en) Method and system for implementing remote disaster recovery switching of service delivery platform
CN105187249B (zh) 一种故障恢复方法及装置
CN105790980B (zh) 一种故障修复方法及装置
CN112181660A (zh) 一种基于服务器集群的高可用方法
CN102231677B (zh) Iptv系统中一种基于双中心容灾的切换方法及其装置
CN103731312A (zh) 对远程方法调用的服务进行故障检查的方法和装置
CN105302661A (zh) 一种实现虚拟化管理平台高可用的系统和方法
CN110673981B (zh) 故障恢复方法、装置和系统
CN109726046A (zh) 机房切换方法及切换装置
CN101237315A (zh) 一种用于双控高可用系统的同步检测和故障隔离方法
CN109905275A (zh) 一种基于sdn分层架构的控制平面故障检测与处理方法
CN106817238A (zh) 虚拟机修复方法、虚拟机装置、系统及业务功能网元
CN105071968A (zh) 一种通信设备的业务面和控制面的隐性故障修复方法和装置
CN111212127A (zh) 一种存储集群及业务数据的维护方法、装置和存储介质
CN101989933A (zh) 一种故障检测的方法和系统
CN106294795A (zh) 一种数据库切换方法及系统
CN103812697B (zh) 一种分布式通信网络的异地容灾方法和系统
CN116185697B (zh) 容器集群管理方法、装置、系统、电子设备及存储介质
CN109104325A (zh) 基于CANopen协议的列车网络数据传输方法、系统及其装置
CN104125079A (zh) 一种确定双机热备份配置信息的方法及装置
CN113438111A (zh) 基于Raft分布式恢复RabbitMQ网络分区的方法及应用
CN117435405A (zh) 双机热备和故障切换系统和方法
CN102081621A (zh) 一种确定数据库生产系统容灾切换的方法和装置
CN103532748B (zh) 一种drbd脑裂的处理方法及装置
WO2014176969A1 (zh) 一种自动容灾切换方法及装置

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
WW01 Invention patent application withdrawn after publication
WW01 Invention patent application withdrawn after publication

Application publication date: 20170609