CN109842526A - 一种容灾方法和装置 - Google Patents
一种容灾方法和装置 Download PDFInfo
- Publication number
- CN109842526A CN109842526A CN201910191142.3A CN201910191142A CN109842526A CN 109842526 A CN109842526 A CN 109842526A CN 201910191142 A CN201910191142 A CN 201910191142A CN 109842526 A CN109842526 A CN 109842526A
- Authority
- CN
- China
- Prior art keywords
- vnf
- data center
- disaster
- virtualized infrastructure
- infrastructure manager
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Hardware Redundancy (AREA)
Abstract
本发明的实施例提供一种容灾方法和装置，能够满足各类不同特性的网元业务的容灾需求，提升业务的可靠性。该方法包括：第一虚拟化基础设施管理器获取虚拟网络功能管理器发送的业务容灾参数VNFk，若根据VNFk确定VNF的业务类型为第三方应用，第一虚拟化基础设施管理器向云管平台上报VNF下的业务配置信息；以便于主用数据中心发生整体灾难后，若第一虚拟化基础设施管理器与云管平台的通信中断的时长大于第一预定时长时，云管平台向灾备数据中心的第二虚拟化基础设施管理器下发VNF下的业务配置信息，使得第二虚拟化基础设施管理器创建运行新的虚拟机VM组接管VNF。
Description
技术领域
本发明的实施例涉及计算机领域，尤其涉及一种容灾方法和装置。
背景技术
从国内外的研究情况来看，因为传统通信网元容灾要求高，本身能力强，现有技术在考虑运营商引入了网络功能虚拟化(network function virtualization，NFV)后的容灾机制时，虚拟化后的通信网元容灾的方式仍与传统网元容灾方式的原理基本一致，即采用多个相同的虚拟网元(virtual network function，VNF)跨数据中心(date center，DC)组成一个池的方式，主要容灾工作还是集中在VNF层面自身，即不需要虚拟化基础设施管理器(virtual infrastructure manager，VIM)或其他组件来感知故障和协调资源，网元层本身即可管理多个VNF之间的容灾数据同步，且一旦一个DC中的此类VNF全失效时，则会迅速触发池中可用灾备DC中的同类VNF接管其业务。
随着网络技术的快速更新、运营商新型业务种类的不断丰富，现有技术中并没有提出如何在部署丰富多样的VNF时，虚拟网络功能管理器(virtual network functionmanager，VNFM)根据具体VNF的业务特征来选择出适合此类型的VNF的容灾方式，且除了典型的通信网元外，我们还需要对本身容灾控制能力不足、可靠性要求相对略低的第三方应用的网元的容灾机制进行深入研究。同时，由于没有充分认识到引入NFV技术以后，应合理利用多个组件来加强可靠性，现有技术提出的NFV中的容灾机制没考虑引进成熟的统一云管平台来作为运营商支撑系统的重要组成部分，而是主要通过将两双活DC设为一个集群，通过主用DC和灾备DC之间的心跳检测来判断DC运行是否正常、是否需要启动容灾，因此容易因为脑裂等情况而造成误判，需要人工干预且业务恢复时间长，不利于对不同地理位置的不同数据中心基础设施和虚拟化资源池的管理和容灾控制。
发明内容
本发明的实施例提供一种容灾方法和装置，能够满足各类不同特性的网元业务的容灾需求，提升业务的可靠性。
第一方面，提供一种容灾方法，包括如下步骤：第一虚拟化基础设施管理器获取虚拟网络功能管理器发送的业务容灾参数VNFk，其中，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；若根据所述VNFk确定所述VNF的业务类型为第三方应用，所述第一虚拟化基础设施管理器向云管平台上报所述VNF下的业务配置信息；以便于所述主用数据中心发生整体灾难后，若所述第一虚拟化基础设施管理器与云管平台的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器创建运行新的虚拟机VM组接管所述VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
第二方面，提供一种容灾方法，包括如下步骤：云管平台接收第一虚拟化基础设施管理器上报的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由所述第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；所述主用数据中心发生整体灾难后，所述云管平台确定与所述第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
第三方面，提供一种容灾方法，包括如下步骤：主用数据中心发生整体灾难后，第二虚拟化基础设施管理器接收云管平台发送的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
上述方案中，第一虚拟化基础设施管理器获取虚拟网络功能管理器发送的业务容灾参数VNFk；若根据VNFk确定VNF的业务类型为第三方应用，第一虚拟化基础设施管理器向云管平台上报VNF下的业务配置信息；主用数据中心发生整体灾难后，云管平台确定与第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，云管平台向灾备数据中心的第二虚拟化基础设施管理器下发VNF下的业务配置信息；第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管主用数据中心的VNF，其中，云管平台通过第一虚拟化基础设施管理器与主用数据中心进行通信，云管平台通过第二虚拟化基础设施管理器与灾备数据中心进行通信，主用数据中心的系统架构与灾备数据中心的系统架构相同。首先，本申请在原有的NFV标准框架的基础上引入云管平台对主用数据中心和灾备数据中心进行管理监测，可以实现对不同地理位置的不同数据中心的容灾控制，以及对虚拟化基础设施管理器的管理，避免了通过主用数据中心和灾备数据中心之间的心跳判断主用数据中心的运行情况，从而避免了因脑裂等情况造成的误判，又由于无需人工干预即可完成容灾，因而缩短了业务恢复时间。其次，本申请对VNF进行了分类，提出了本身容灾控制能力不足、可靠性要求相对略低的第三方应用的VNF的容灾机制，改进了现有NFV的标准框架，弥补了管理与编排系统MANO的相关组件在容灾方面的功能缺失，又能满足现在以及未来的云化网络中各种类型的VNF业务的容灾需求，提升了业务的可靠性。
第四方面，提供一种容灾装置，用于主用数据中心的第一虚拟化基础设施管理器，包括：获取模块，用于获取虚拟网络功能管理器发送的业务容灾参数VNFk，其中，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；确定模块，用于若根据所述获取模块获取到的所述VNFk确定所述VNF的业务类型为第三方应用，所述第一虚拟化基础设施管理器向云管平台上报所述VNF下的业务配置信息；以便于所述主用数据中心发生整体灾难后，若所述第一虚拟化基础设施管理器与云管平台的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器创建运行新的虚拟机VM组接管所述VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
第五方面，提供一种容灾装置，用于云管平台或者云管平台的芯片，包括：接收模块，用于接收第一虚拟化基础设施管理器上报的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由所述第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；发送模块，用于所述主用数据中心发生整体灾难后，所述云管平台确定与所述第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，向灾备数据中心的第二虚拟化基础设施管理器下发所述接收模块接收的所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
第六方面，提供一种容灾装置，用于灾备数据中心的第一虚拟化基础设施管理器，包括：接收模块，用于主用数据中心发生整体灾难后，接收云管平台发送的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；处理模块，用于在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
第七方面，提供一种容灾装置，用于主用数据中心的第一虚拟化基础设施管理器，包括通信接口、处理器、存储器、总线；存储器用于存储计算机执行指令，处理器与存储器通过总线连接，当容灾装置运行时，处理器执行存储器存储的计算机执行指令，以使容灾装置执行如上述第一方面的容灾方法。
第八方面，提供一种容灾装置，用于云管平台或者云管平台的芯片，包括通信接口、处理器、存储器、总线；存储器用于存储计算机执行指令，处理器与存储器通过总线连接，当容灾装置运行时，处理器执行存储器存储的计算机执行指令，以使容灾装置执行如上述第二方面的容灾方法。
第九方面，提供一种容灾装置，用于灾备数据中心的第一虚拟化基础设施管理器，包括通信接口、处理器、存储器、总线；存储器用于存储计算机执行指令，处理器与存储器通过总线连接，当容灾装置运行时，处理器执行存储器存储的计算机执行指令，以使容灾装置执行如上述第三方面的容灾方法。
第十方面，提供一种计算机存储介质，包括指令，其特征在于，当指令在计算机上运行时，使得计算机执行如上述的容灾方法。
第十一方面，提供一种计算机程序产品，计算机程序产品包括指令代码，指令代码用于执行如上述的容灾方法。
可以理解地，上述第四方面提供的装置用于第一方面的方法、第五方面提供的装置用于第二方面的方法、第六方面提供的装置用于第三方面的方法、计算机存储介质或计算机程序产品用于存储执行上文所提供的容灾方法，因此，其所能达到的有益效果可参考上文容灾方法以及下文具体实施方式中对应的方案的有益效果，此处不再赘述。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明的实施例提供的一种NFV架构示意图；
图2为本发明的实施例提供的一种容灾系统架构示意图；
图3为本发明的实施例提供的一种容灾方法示意图；
图4为本发明的实施例提供的一种主用数据中心的容灾装置示意图；
图5为本发明的另一实施例提供的一种主用数据中心的容灾装置示意图；
图6为本发明的实施例提供的一种云管平台的容灾装置示意图；
图7为本发明的另一实施例提供的一种云管平台的容灾装置示意图；
图8为本发明的实施例提供的一种灾备数据中心的容灾装置示意图；
图9为本发明的另一实施例提供的一种灾备数据中心的容灾装置示意图
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
NFV是指借助于标准的IT虚拟化技术，将传统的专有硬件设备例如，路由器、防火墙、每英寸点数(dots per inch，DPI)、内容分发网络(content delivery network，CDN)、网络地址转换(network address translation，NAT)等，改为通过采用工业化标准大容量服务器、存储器和交换机来承载各种各样软件化的网络功能(network function，NF)的技术。当前普遍接受的NFV架构为ETSI NFV ISG所定义，具体参照图1所示，包括电信运营支撑系统11，例如运营支持系统或者商业支持系统；虚拟网元层12，具体包括虚拟网元1211，网元管理器1221，虚拟网元1212，网元管理器1222，虚拟网元1213，网元管理器1223；基础设施层13具体包括硬件资源池，虚拟化中间件，虚拟资源池，其中硬件资源池的硬件设备包括计算设备、存储设备、网络设备，虚拟资源池包括虚拟计算资源、虚拟存储资源、虚拟网络资源；管理与编排系统14包括网络功能虚拟化编排器141，虚拟网络功能管理器142，虚拟化的网络功能描述符143，虚拟化基础设施管理器144。其中，管理与编排系统14可以实现对电信运营支撑系统11、虚拟网元层12和基础设施层13的调度管理。管理与编排系统14中的虚拟化基础设施管理器144负责对基础设施层13的软硬件资源进行管理；管理与编排系统14中的虚拟网络功能管理器142负责解析虚拟化的网络功能描述符，和对虚拟网元1211-1213的生命周期管理，虚拟网元1211-1213由一组虚拟机(virtual machine，VM)组成，网元管理器1221-1223负责虚拟网元的配置、故障和告警等管理；管理与编排系统14中的网络功能虚拟化编排器141负责电信运营支撑系统11中的网络服务(network service，NS)的生命周期管理。
在计算机通信领域，灾难定义为：由于人为或自然的原因，造成信息系统运行严重故障或瘫痪，使信息系统支持的业务功能停顿或服务水平不可接受，并且此状态超出一定时间的突发事件。典型的灾难事件包括自然灾难、技术风险、人为因素等。一个完善的容灾机制将保证数据的安全性，提高业务的连续性可靠性，建立容灾机制的根本目的就是为了当灾难发生时，用户仍能享用到不间断的应用服务，并且受损的系统能够在最短的时间内恢复。
在NFV中部署各应用时，通常以数据中心(date center，DC)为单位。一个DC内部署多台服务器等基础设施及多个应用对象和系统。多数运营商建立的每个DC中有一套vim来管理和监控本DC内的基础设施和虚拟资源，DC内包含冗余和备用服务器、存储设备、网络设备、电源和安全设备等并有一套容灾机制来保证DC内部分设备或系统出现故障时快速恢复业务不影响此DC对外提供服务。但一旦整个DC发生地理灾难事故、断电或大范围人为操作错误等造成整个DC瘫痪的重大灾难时，则无法依靠DC内的容灾来保持业务的连续性了，为了避免这种灾难性后果，需要在此DC(可称为主用数据中心)建立之初就同时在相距一定距离的另一处建立与之具有灾备关系的另一个DC(可称为灾备数据中心)，两DC功能相同容量相当，并依靠DC间的容灾机制来保证灾备数据中心能成功接管主用数据中心的业务。
在当前的标准NFV架构与容灾机制下，本申请提供一种容灾系统架构，引入资源统管的组件云管平台对主用数据中心以及灾备数据中心进行统一云管，具体参见图2，包括用户请求21，主用数据中心22，灾备数据中心23，云管平台24。主用数据中心22包括接收到用户请求21时在主用数据中心22中部署的VNF 221，其中VNF 221中包含文件型数据和结构化数据，第一虚拟网络功能管理器222，第一虚拟化基础设施管理器223，第一存储设备224，其中第一存储设备224中包含第一数据库。灾备数据中心23包括在灾备数据中心部署的VNF231，其中VNF 231中包含文件型数据和结构化数据，第二虚拟网络功能管理器232，第二虚拟化基础设施管理器233，第二存储设备234，其中第二存储设备234中包含第二数据库。其中，云管平台24通过第一虚拟化基础设施管理器223与主用数据中心22进行通信，通过第二虚拟化基础设施管理器233与灾备数据中心23进行通信，并对主用数据中心22与灾备数据中心23的资源进行管理。NFV中的网元在创建和运行中会产生多种数据，例如，镜像文件、业务数据、网元整体备份、话单数据、用户签约数据等等，本申请对各种数据的备份采用不同工具进行管理；这些数据按照数据类型划分，可分为结构化数据和文件型数据，文件型数据存储于存储设备，网元中的文件型数据存储在本DC内的存储设备中，由各自DC的基础设施(network function virtualization infrastructure，NFVI)层完成跨DC的数据同步，需要VIM和存储设备进行配合；结构化数据存储于数据库，由各自DC中的数据库配合完成跨DC的数据远程实时同步功能，商用数据库本身均具有成熟的数据同步备份机制，数据库可创建在存储设备中，也可是FTP服务器或其他地方。第一存储设备224可以与第二存储设备234可以建立通信连接；第一数据库可以与第二数据库可以建立通信连接。在主用数据中心22中，第一存储设备224与第一虚拟化基础设施管理器223具有通信连接，第一虚拟化基础设施管理器223与第一虚拟网络功能管理器222具有通信连接，第一虚拟网络功能管理器222与VNF 221具有通信连接。在灾备数据中心23中，第二存储设备234与第二虚拟化基础设施管理器233具有通信连接，第二虚拟化基础设施管理器233与第二虚拟网络功能管理器232具有通信连接，第二虚拟网络功能管理器232与VNF 231具有通信连接。
基于上述容灾系统架构，本申请提供一种容灾方法，参照图3所示，具体包括如下步骤：
301、第一虚拟化基础设施管理器获取虚拟网络功能管理器发送的业务容灾参数VNFk。
其中，VNFk由虚拟网络功能管理器VNFM解析主用数据中心的虚拟网元VNF，根据VNF的虚拟网元描述符VNFD获取。该虚拟网络功能管理器VNFM为主用数据中心的第一虚拟网络功能管理器。
第一虚拟化基础设施管理器，也叫第一VIM，创建并启动VNF下的虚拟机VM组，并将VNF的基础信息上报给云管平台进行存储。
第一VIM根据VNFk确定VNF的业务类型，确定VNFk＝0时，则确定VNF的业务类型为第一类VNF。确定VNFk＝1时，则确定VNF的业务类型为第二类VNF；其中，第一类VNF为虚拟化后的核心通信网元，第二类VNF为第三方应用。第一类VNF可靠性要求高容灾能力强，其容灾机制仍以VNF应用层容灾为主。第二类VNF无法依靠网元层自身来实现容灾，相对第一类VNF，其容灾能力较弱对可靠性要求相对较低，将由多个组件来保证业务的可靠性，需依靠VIM控制NFVI层在主用DC和灾备DC之间进行存储同步以及VM状态的监控，需要依靠云管平台来感知DC级的故障并触发业务切换。
若根据VNFk确定VNF的业务类型为虚拟化后的核心通信网元，主用数据中心部署VNF的同时，在灾备数据中心部署与该VNF相同的VNF，并且主用数据中心部署的VNF与灾备数据中心部署的VNF跨DC组池，相同的VNF自身即可管理控制容灾数据同步和备份并能监控VM组的状态。第二虚拟化基础设施管理器，也叫第二VIM，创建并启动VNF下的虚拟机VM组，并将VNF的基础信息上报给云管平台进行存储。
云管平台通过第一虚拟化基础设施管理器与主用数据中心(主用DC)进行通信，云管平台通过第二虚拟化基础设施管理器与灾备数据中心(灾备DC)进行通信，主用DC的系统架构与灾备DC的系统架构相同。其中，主用DC和灾备DC同时创建，两者相距一定地理距离，具有灾备关系，两个数据中心DC容量一致，性能相当。主用DC的VNF和灾备DC对应的VNF功能相同，配置一样，各数据中心都有多个运行不同网络功能的VNF。收到用户应用请求后，运行作为生产数据中心的主用DC内的VNF，若主用DC发生灾难，主用DC内的VNF失效，作为灾备DC内的VNF将迅速启动以接管主用DC的业务，用户应用请求将由灾备DC的VNF来完成。每个数据中心部署有一套VNFM和VIM，VIM由云管平台统一管理，云管平台不可部署在需要其管理的主用DC或灾备DC内。
302、若根据VNFk确定VNF的业务类型为第三方应用，第一虚拟化基础设施管理器向云管平台上报VNF下的业务配置信息。
其中，业务配置信息是指主用数据中心内VNF下VM组的规格、网络信息、磁盘信息、容灾类型等信息。
主用数据中心的第一存储设备与灾备数据中心的第二存储设备通信；第一存储设备与第二存储设备划分为同样大小的卷，建立同步映射关系；第一存储设备的第一数据库与第二存储设备的第二数据库开启远程实时同步功能，使得灾备数据中心拥有完整的业务容灾数据。
不同于第一类VNF，第二类VNF是按特定客户要求来灵活开通和关闭的业务，通常并不是主用DC和灾备DC部署前就已规划好要创建的业务。第二类VNF在线时间相对第一类VNF较短，数据量也小，创建启动也快，故在主用DC中创建第二类VNF时不需同时占用大量灾备DC中的资源创建运行此类VNF，可等满足容灾触发条件时再快速启动备用DC中的此类业务。
303、云管平台确定与第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，向灾备数据中心的第二虚拟化基础设施管理器下发VNF下的业务配置信息。
当主用DC发生灾难时，第一VIM上运行的VNF下的VM失效，第一VIM与云管平台的通信中断时长超过第一预定时长，云管平台感知到主用DC故障，触发主用DC与灾备DC间的容灾流程，向第二VIM下发VNF下的业务配置信息以及创建指令。
304、第二虚拟化基础设施管理器根据业务配置信息在灾备数据中心完成创建VNF的VM组，并将VM组连接网络，向云管平台发送响应于业务配置信息的通知。
第二VIM根据VNF下的业务配置信息在灾备数据中心配置业务网络，并根据创建指令批量创建VM组，将VM组的各VM挂载到第二存储设备里对应的卷上并连接网络。
当VM组的各VM挂载到第二存储设备里对应的卷上并连接网络成功之后向云管平台发送通知，告知准备完毕。
305、云管平台向第二虚拟化基础设施管理器发送启动指令。
云管平台接收到第二虚拟化基础设施管理器VM组的各VM挂载到第二存储设备里对应的卷上并连接网络成功的通知后，向第二虚拟化基础设施管理器发送启动VNF的指令。
306、第二虚拟化基础设施管理器根据启动指令运行灾备数据中心的VM组的VNF接管主用数据中心中的VNF。
第二虚拟化基础设施管理器接收到云管平台的启动VNF的指令之后，启动灾备数据中心的VNF，运行新创建的VM组接管主用数据中心中的VNF。
若确定VNF的业务类型为虚拟化后的核心通信网元，主用数据中心发生整体灾难，则主用数据中心中的VNF与灾备数据中心中的VNF的通信中断的时长大于第二预定时长时，灾备数据中心中的VNF接管主用数据中心中的VNF。由于主用DC部署的VNF与灾备DC部署的VNF跨DC组池，相同的VNF自身即可管理控制容灾数据同步和备份并能监控VM组的状态。一旦感知到主用DC中的此类VNF全失效时，则会迅速触发池中可用灾备DC中的同类VNF接管其业务。
当主用数据中心的VNF全部切换到灾备数据中心的VNF上之后，灾备数据中心升级为主用数据中心全面接替网络业务。
云管平台向管理系统派工单，通知管理人员主用数据中心发生故障，请求修复。
原主用数据中心的故障修复后，变为灾备数据中心。
上述方案中，第一虚拟化基础设施管理器获取虚拟网络功能管理器发送的业务容灾参数VNFk；若根据VNFk确定VNF的业务类型为第三方应用，第一虚拟化基础设施管理器向云管平台上报VNF下的业务配置信息；主用数据中心发生整体灾难后，云管平台确定与第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，云管平台向灾备数据中心的第二虚拟化基础设施管理器下发VNF下的业务配置信息；第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管主用数据中心的VNF，其中，云管平台通过第一虚拟化基础设施管理器与主用数据中心进行通信，云管平台通过第二虚拟化基础设施管理器与灾备数据中心进行通信，主用数据中心的系统架构与灾备数据中心的系统架构相同。首先，本申请在原有的NFV标准框架的基础上引入云管平台对主用数据中心和灾备数据中心进行管理监测，可以实现对不同地理位置的不同数据中心的容灾控制，以及对虚拟化基础设施管理器的管理，避免了通过主用数据中心和灾备数据中心之间的心跳判断主用数据中心的运行情况，从而避免了因脑裂等情况造成的误判，又由于无需人工干预即可完成容灾，因而缩短了业务恢复时间。其次，本申请对VNF进行了分类，提出了本身容灾控制能力不足、可靠性要求相对略低的第三方应用的VNF的容灾机制，改进了现有NFV的标准框架，弥补了管理与编排系统MANO的相关组件在跨主用数据中心资源池管理和容灾方面的功能缺失，又能满足现在以及未来的云化网络中各种类型的VNF业务的容灾需求，提升了业务的可靠性。
参照图4所示，提供一种容灾装置，用于主用数据中心的第一虚拟化基础设施管理器，包括：
获取模块41，用于获取虚拟网络功能管理器发送的业务容灾参数VNFk，其中，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；确定模块42，用于若根据所述获取模块41获取到的所述VNFk确定所述VNF的业务类型为第三方应用，所述第一虚拟化基础设施管理器向云管平台上报所述VNF下的业务配置信息；以便于所述主用数据中心发生整体灾难后，若所述第一虚拟化基础设施管理器与云管平台的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器创建运行新的虚拟机VM组接管所述VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
可选的，所述确定模块42，具体用于确定所述VNFk＝0时，则确定所述VNF的业务类型为第一类VNF；所述确定模块42，具体用于确定所述VNFk＝1时，则确定所述VNF的业务类型为第二类VNF；所述第一类VNF为虚拟化后的核心通信网元，所述第二类VNF为第三方应用。
可选的，所述确定模块42，还用于若确定所述VNF的业务类型为虚拟化后的核心通信网元，所述主用数据中心发生整体灾难，则所述主用数据中心中的VNF与所述灾备数据中心中的VNF的通信中断的时长大于第二预定时长时，所述灾备数据中心中的VNF接管所述主用数据中心中的VNF。
在采用集成的模块的情况下，容灾装置包括：存储单元、处理单元以及接口单元。处理单元用于对容灾装置的动作进行控制管理。接口单元，用于支持容灾装置与其他设备的信息交互。存储单元，用于存储容灾装置的程序代码和数据。
其中，以处理单元为处理器，存储单元为存储器，接口单元为通信接口为例。其中，容灾装置参照图5中所示，包括通信接口501、处理器502、存储器503和总线504，通信接口501、处理器502通过总线504与存储器503相连。
处理器502可以是一个通用中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
存储器503可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器503用于存储执行本申请方案的应用程序代码，并由处理器502来控制执行。通讯接口501用于与其他设备进行信息交互，例如支持容灾装置与其他设备的信息交互，例如从其他设备获取数据或者向其他设备发送数据。处理器502用于执行存储器503中存储的应用程序代码，从而实现本申请实施例中的方法。
参照图6所示，提供一种容灾装置，用于云管平台或者云管平台的芯片，包括：
接收模块61，用于接收第一虚拟化基础设施管理器上报的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由所述第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；发送模块62，用于所述主用数据中心发生整体灾难后，所述云管平台确定与所述第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，向灾备数据中心的第二虚拟化基础设施管理器下发所述接收模块61接收的所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
可选的，所述接收模块61，还用于接收所述第二虚拟化基础设施管理器发送的响应于所述业务配置信息的通知，其中所述响应于所述业务配置信息的通知用于通知所述云管平台，所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；所述发送模块62，还用于向所述第二虚拟化基础设施管理器发送启动指令，其中所述启动指令用于指示所述第二虚拟化基础设施管理器运行所述灾备数据中心的VM组的VNF接管所述主用数据中心中的VNF。
在采用集成的模块的情况下，容灾装置包括：存储单元、处理单元以及接口单元。处理单元用于对容灾装置的动作进行控制管理。接口单元，用于支持容灾装置与其他设备的信息交互。存储单元，用于存储容灾装置的程序代码和数据。
其中，以处理单元为处理器，存储单元为存储器，接口单元为通信接口为例。其中，容灾装置参照图7中所示，包括通信接口701、处理器702、存储器703和总线704，通信接口701、处理器702通过总线704与存储器703相连。
处理器702可以是一个通用中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
存储器703可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器703用于存储执行本申请方案的应用程序代码，并由处理器702来控制执行。通讯接口701用于与其他设备进行信息交互，例如支持容灾装置与其他设备的信息交互，例如从其他设备获取数据或者向其他设备发送数据。处理器702用于执行存储器703中存储的应用程序代码，从而实现本申请实施例中的方法。
参照图8所示，提供一种容灾装置，用于灾备数据中心的第二虚拟化基础设施管理器，包括：
接收模块81，用于主用数据中心发生整体灾难后，接收云管平台发送的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；处理模块82，用于在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
可选的，所述处理模块82，还用于根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；发送模块83，用于向所述云管平台发送响应于所述业务配置信息的通知，其中所述响应于所述业务配置信息的通知用于通知所述云管平台，所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；所述处理模块82，还用于接收所述云管平台发送的启动指令，根据所述启动指令运行所述灾备数据中心的VM组的VNF接管所述主用数据中心中的VNF。
在采用集成的模块的情况下，容灾装置包括：存储单元、处理单元以及接口单元。处理单元用于对容灾装置的动作进行控制管理。接口单元，用于支持容灾装置与其他设备的信息交互。存储单元，用于存储容灾装置的程序代码和数据。
其中，以处理单元为处理器，存储单元为存储器，接口单元为通信接口为例。其中，容灾装置参照图9中所示，包括通信接口901、处理器902、存储器903和总线904，通信接口901、处理器902通过总线904与存储器903相连。
处理器902可以是一个通用中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
存储器903可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器903用于存储执行本申请方案的应用程序代码，并由处理器902来控制执行。通讯接口901用于与其他设备进行信息交互，例如支持容灾装置与其他设备的信息交互，例如从其他设备获取数据或者向其他设备发送数据。处理器902用于执行存储器903中存储的应用程序代码，从而实现本申请实施例中的方法。
此外，还提供一种计算存储媒体(或介质)，包括在被执行时进行上述实施例中的容灾方法操作的指令。另外，还提供一种计算机程序产品，包括上述计算存储媒体(或介质)。
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，其作用在此不再赘述。
应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文全称:read-only memory，英文简称：ROM)、随机存取存储器(英文全称：random access memory，英文简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。
Claims (19)
1.一种容灾方法，其特征在于，
第一虚拟化基础设施管理器获取虚拟网络功能管理器发送的业务容灾参数VNFk，其中，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；
若根据所述VNFk确定所述VNF的业务类型为第三方应用，所述第一虚拟化基础设施管理器向云管平台上报所述VNF下的业务配置信息；以便于所述主用数据中心发生整体灾难后，若所述第一虚拟化基础设施管理器与云管平台的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器创建运行新的虚拟机VM组接管所述VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
2.根据权利要求1所述的容灾方法，其特征在于，所述根据所述VNFk确定所述VNF的业务类型，包括：
确定所述VNFk＝0时，则确定所述VNF的业务类型为第一类VNF；
确定所述VNFk＝1时，则确定所述VNF的业务类型为第二类VNF；所述第一类VNF为虚拟化后的核心通信网元，所述第二类VNF为第三方应用。
3.根据权利要求1或2所述的容灾方法，其特征在于，
若确定所述VNF的业务类型为虚拟化后的核心通信网元，所述主用数据中心发生整体灾难，则所述主用数据中心中的VNF与所述灾备数据中心中的VNF的通信中断的时长大于第二预定时长时，所述灾备数据中心中的VNF接管所述主用数据中心中的VNF。
4.一种容灾方法，其特征在于，
云管平台接收第一虚拟化基础设施管理器上报的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由所述第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；
所述主用数据中心发生整体灾难后，所述云管平台确定与所述第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
5.根据权利要求4所述的容灾方法，其特征在于，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息之后，还包括：
所述云管平台接收所述第二虚拟化基础设施管理器发送的响应于所述业务配置信息的通知，其中所述响应于所述业务配置信息的通知用于通知所述云管平台，所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；
所述云管平台向所述第二虚拟化基础设施管理器发送启动指令，其中所述启动指令用于指示所述第二虚拟化基础设施管理器运行所述灾备数据中心的VM组的VNF接管所述主用数据中心中的VNF。
6.一种容灾方法，其特征在于，
主用数据中心发生整体灾难后，第二虚拟化基础设施管理器接收云管平台发送的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；
所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
7.根据权利要求6所述的容灾方法，其特征在于，所述第二虚拟化基础设施管理器接收云管平台发送的主用数据中心的VNF下的业务配置信息之后，还包括：
所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；
所述第二虚拟化基础设施管理器向所述云管平台发送响应于所述业务配置信息的通知，其中所述响应于所述业务配置信息的通知用于通知所述云管平台，所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组；
所述第二虚拟化基础设施管理器接收所述云管平台发送的启动指令，根据所述启动指令运行所述灾备数据中心的VM组的VNF接管所述主用数据中心中的VNF。
8.一种容灾装置，用于主用数据中心的第一虚拟化基础设施管理器，其特征在于，
获取模块，用于获取虚拟网络功能管理器发送的业务容灾参数VNFk，其中，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；
确定模块，用于若根据所述获取模块获取到的所述VNFk确定所述VNF的业务类型为第三方应用，所述第一虚拟化基础设施管理器向云管平台上报所述VNF下的业务配置信息；以便于所述主用数据中心发生整体灾难后，若所述第一虚拟化基础设施管理器与云管平台的通信中断的时长大于第一预定时长时，所述云管平台向灾备数据中心的第二虚拟化基础设施管理器下发所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器创建运行新的虚拟机VM组接管所述VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
9.根据权利要求8所述的容灾装置，其特征在于，
所述确定模块，具体用于确定所述VNFk＝0时，则确定所述VNF的业务类型为第一类VNF；
所述确定模块，具体用于确定所述VNFk＝1时，则确定所述VNF的业务类型为第二类VNF；所述第一类VNF为虚拟化后的核心通信网元，所述第二类VNF为第三方应用。
10.根据权利要求8或9所述的容灾装置，其特征在于，
所述确定模块，还用于若确定所述VNF的业务类型为虚拟化后的核心通信网元，所述主用数据中心发生整体灾难，则所述主用数据中心中的VNF与所述灾备数据中心中的VNF的通信中断的时长大于第二预定时长时，所述灾备数据中心中的VNF接管所述主用数据中心中的VNF。
11.一种容灾装置，用于云管平台或者云管平台的芯片，其特征在于，
接收模块，用于接收第一虚拟化基础设施管理器上报的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由所述第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；
发送模块，用于所述主用数据中心发生整体灾难后，所述云管平台确定与所述第一虚拟化基础设施管理器的通信中断的时长大于第一预定时长时，向灾备数据中心的第二虚拟化基础设施管理器下发所述接收模块接收的所述VNF下的业务配置信息，使得所述第二虚拟化基础设施管理器在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
12.根据权利要求11所述的容灾装置，其特征在于，
所述接收模块，还用于接收所述第二虚拟化基础设施管理器发送的响应于所述业务配置信息的通知，其中所述响应于所述业务配置信息的通知用于通知所述云管平台，所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；
所述发送模块，还用于向所述第二虚拟化基础设施管理器发送启动指令，其中所述启动指令用于指示所述第二虚拟化基础设施管理器运行所述灾备数据中心的VM组的VNF接管所述主用数据中心中的VNF。
13.一种容灾装置，用于灾备数据中心的第二虚拟化基础设施管理器，其特征在于，
接收模块，用于主用数据中心发生整体灾难后，接收云管平台发送的主用数据中心的VNF下的业务配置信息；其中，所述VNF的业务类型为第三方应用，所述VNF的业务类型由第一虚拟化基础设施管理器根据虚拟网络功能管理器发送的业务容灾参数VNFk确定，所述VNFk由所述虚拟网络功能管理器解析主用数据中心的虚拟网元VNF，根据所述VNF的虚拟网元描述符获取；
处理模块，用于在灾备数据中心中创建并运行新的虚拟机VM组接管所述主用数据中心的VNF，其中，所述云管平台通过所述第一虚拟化基础设施管理器与所述主用数据中心进行通信，所述云管平台通过所述第二虚拟化基础设施管理器与所述灾备数据中心进行通信，所述主用数据中心的系统架构与所述灾备数据中心的系统架构相同。
14.根据权利要求13所述的容灾装置，其特征在于，
所述处理模块，还用于根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；
发送模块，用于向所述云管平台发送响应于所述业务配置信息的通知，其中所述响应于所述业务配置信息的通知用于通知所述云管平台，所述第二虚拟化基础设施管理器根据所述业务配置信息在所述灾备数据中心完成创建VNF的VM组，并将所述VM组连接网络；
所述处理模块，还用于接收所述云管平台发送的启动指令，根据所述启动指令运行所述灾备数据中心的VM组的VNF接管所述主用数据中心中的VNF。
15.一种容灾装置，用于主用数据中心的第一虚拟化基础设施管理器，其特征在于，包括通信接口、处理器、存储器、总线；所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述容灾装置运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述容灾装置执行如权利要求1-3任一项所述的容灾方法。
16.一种容灾装置，用于云管平台或者云管平台的芯片，其特征在于，包括通信接口、处理器、存储器、总线；所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述容灾装置运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述容灾装置执行如权利要求4或5所述的容灾方法。
17.一种容灾装置，用于灾备数据中心的第二虚拟化基础设施管理器，其特征在于，包括通信接口、处理器、存储器、总线；所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述容灾装置运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述容灾装置执行如权利要求6或7所述的容灾方法。
18.一种计算机存储介质，包括指令，其特征在于，当所述指令在计算机上运行时，使得所述计算机执行如权利要求1-7任一项所述的容灾方法。
19.一种计算机程序产品，其特征在于，所述计算机程序产品包括指令代码，所述指令代码用于执行如权利要求1-7任一项所述的容灾方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910191142.3A CN109842526B (zh) | 2019-03-12 | 2019-03-12 | 一种容灾方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910191142.3A CN109842526B (zh) | 2019-03-12 | 2019-03-12 | 一种容灾方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109842526A true CN109842526A (zh) | 2019-06-04 |
| CN109842526B CN109842526B (zh) | 2021-12-07 |
Family
ID=66885691
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910191142.3A Active CN109842526B (zh) | 2019-03-12 | 2019-03-12 | 一种容灾方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109842526B (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113489607A (zh) * | 2021-06-29 | 2021-10-08 | 杭州海康威视数字技术股份有限公司 | 一种业务处理系统、采集设备和汇聚设备 |
| CN113660131A (zh) * | 2021-10-18 | 2021-11-16 | 武汉绿色网络信息服务有限责任公司 | 虚拟网络功能单元切换的方法、装置、控制器和存储介质 |
| CN113849340A (zh) * | 2021-08-13 | 2021-12-28 | 苏州浪潮智能科技有限公司 | 虚拟化平台与多存储系统的容灾备份对接方法及装置 |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130124712A1 (en) * | 2011-11-10 | 2013-05-16 | Verizon Patent And Licensing Inc. | Elastic cloud networking |
| CN103647849A (zh) * | 2013-12-24 | 2014-03-19 | 华为技术有限公司 | 一种业务迁移方法、装置和一种容灾系统 |
| CN104115447A (zh) * | 2014-04-14 | 2014-10-22 | 华为技术有限公司 | 一种云计算架构下的容灾方案配置方法及装置 |
| CN104137482A (zh) * | 2014-04-14 | 2014-11-05 | 华为技术有限公司 | 一种云计算架构下的容灾数据中心配置方法及装置 |
| CN105577408A (zh) * | 2014-09-25 | 2016-05-11 | 中兴通讯股份有限公司 | 一种vnfm容灾保护的方法、装置和nfvo |
| CN105955824A (zh) * | 2016-04-21 | 2016-09-21 | 华为技术有限公司 | 一种虚拟资源配置方法以及装置 |
| CN106612312A (zh) * | 2015-10-23 | 2017-05-03 | 中兴通讯股份有限公司 | 一种虚拟化数据中心调度系统和方法 |
| CN106878096A (zh) * | 2015-12-10 | 2017-06-20 | 中国电信股份有限公司 | Vnf状态检测通告方法、装置以及系统 |
| CN109218086A (zh) * | 2018-09-05 | 2019-01-15 | 全球能源互联网研究院有限公司 | 一种交换网构建方法与系统 |
-
2019
- 2019-03-12 CN CN201910191142.3A patent/CN109842526B/zh active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130124712A1 (en) * | 2011-11-10 | 2013-05-16 | Verizon Patent And Licensing Inc. | Elastic cloud networking |
| CN103647849A (zh) * | 2013-12-24 | 2014-03-19 | 华为技术有限公司 | 一种业务迁移方法、装置和一种容灾系统 |
| CN104115447A (zh) * | 2014-04-14 | 2014-10-22 | 华为技术有限公司 | 一种云计算架构下的容灾方案配置方法及装置 |
| CN104137482A (zh) * | 2014-04-14 | 2014-11-05 | 华为技术有限公司 | 一种云计算架构下的容灾数据中心配置方法及装置 |
| CN105577408A (zh) * | 2014-09-25 | 2016-05-11 | 中兴通讯股份有限公司 | 一种vnfm容灾保护的方法、装置和nfvo |
| CN106612312A (zh) * | 2015-10-23 | 2017-05-03 | 中兴通讯股份有限公司 | 一种虚拟化数据中心调度系统和方法 |
| CN106878096A (zh) * | 2015-12-10 | 2017-06-20 | 中国电信股份有限公司 | Vnf状态检测通告方法、装置以及系统 |
| CN105955824A (zh) * | 2016-04-21 | 2016-09-21 | 华为技术有限公司 | 一种虚拟资源配置方法以及装置 |
| CN109218086A (zh) * | 2018-09-05 | 2019-01-15 | 全球能源互联网研究院有限公司 | 一种交换网构建方法与系统 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113489607A (zh) * | 2021-06-29 | 2021-10-08 | 杭州海康威视数字技术股份有限公司 | 一种业务处理系统、采集设备和汇聚设备 |
| CN113849340A (zh) * | 2021-08-13 | 2021-12-28 | 苏州浪潮智能科技有限公司 | 虚拟化平台与多存储系统的容灾备份对接方法及装置 |
| CN113849340B (zh) * | 2021-08-13 | 2024-02-27 | 苏州浪潮智能科技有限公司 | 虚拟化平台与多存储系统的容灾备份对接方法及装置 |
| CN113660131A (zh) * | 2021-10-18 | 2021-11-16 | 武汉绿色网络信息服务有限责任公司 | 虚拟网络功能单元切换的方法、装置、控制器和存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109842526B (zh) | 2021-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105760214B (zh) | 一种设备状态及资源信息监测方法、相关设备及系统 | |
| CN105955824B (zh) | 一种虚拟资源配置方法以及装置 | |
| CN102932210B (zh) | 一种PaaS云平台的节点监控方法和系统 | |
| US10999147B2 (en) | Allocating VNFC instances with anti affinity rule to hosts | |
| CN108270726B (zh) | 应用实例部署方法及装置 | |
| CN108304255A (zh) | 分布式任务调度方法及装置、电子设备及可读存储介质 | |
| CN109842526A (zh) | 一种容灾方法和装置 | |
| CN106301876B (zh) | 物理机升级方法、业务迁移方法及装置 | |
| CN100426751C (zh) | 保证集群系统中配置信息一致的方法 | |
| CN105681077A (zh) | 故障处理方法、装置及系统 | |
| EP3806395B1 (en) | Virtual network function (vnf) deployment method and apparatus | |
| CN113886089B (zh) | 一种任务处理方法、装置、系统、设备及介质 | |
| CN108984366A (zh) | 终端的监控处理方法、装置及设备 | |
| CN107122229A (zh) | 一种虚拟机恢复方法及装置 | |
| CN106385330B (zh) | 一种网络功能虚拟化编排器的实现方法及装置 | |
| CN106506186A (zh) | 重建虚拟网络功能的方法和装置 | |
| CN110489225A (zh) | 一种基于消息队列的服务扩容方法、装置及设备 | |
| CN111935244B (zh) | 一种业务请求处理系统及超融合一体机 | |
| CN105324968B (zh) | 可靠性资源的分配方法和装置 | |
| CN109361777A (zh) | 分布式集群节点状态的同步方法、同步系统及相关装置 | |
| CN109446062A (zh) | 云计算服务中的软件调试的方法和装置 | |
| CN108243205A (zh) | 一种用于控制云平台资源分配的方法、设备与系统 | |
| CN104657240B (zh) | 多内核操作系统的失效控制方法及装置 | |
| CN114124803B (zh) | 设备管理方法、装置、电子设备及存储介质 | |
| CN116346834A (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |