CN111526168B - 一种网络功能虚拟化nfv架构的调度管理方法及装置 - Google Patents

一种网络功能虚拟化nfv架构的调度管理方法及装置 Download PDF

Info

Publication number
CN111526168B
CN111526168B CN201910104725.8A CN201910104725A CN111526168B CN 111526168 B CN111526168 B CN 111526168B CN 201910104725 A CN201910104725 A CN 201910104725A CN 111526168 B CN111526168 B CN 111526168B
Authority
CN
China
Prior art keywords
host
pod
instruction
scheduling management
tag
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910104725.8A
Other languages
English (en)
Other versions
CN111526168A (zh
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201910104725.8A priority Critical patent/CN111526168B/zh
Priority to PCT/CN2019/129247 priority patent/WO2020155987A1/zh
Publication of CN111526168A publication Critical patent/CN111526168A/zh
Application granted granted Critical
Publication of CN111526168B publication Critical patent/CN111526168B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Landscapes

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

Abstract

本申请实施例公开一种网络功能虚拟化NFV架构的调度管理方法及装置,该方法中,调度管理设备首先根据各个VM所属的HOST,为VM设置相应的VM标签,通过VM的VM标签,能够实现对VM的划分,这种情况下,位于同一个HOST内的VM为同一类型;然后,调度管理设备在确定第一VM从第一HOST迁移至第二HOST之后,将所述第一VM的VM标签更新为所述第二HOST,再触发NFV架构中的调度器,所述调度器确定第一VM中的第一Pod是否符合部署需求,若不符合,则调度器会将第一Pod调度至第一HOST的第二VM中,从而在第一VM发生迁移之后,仍然使第一Pod部署在第一HOST中,满足第一Pod的部署需求,从而满足Pod在HOST的调度需求。

Description

一种网络功能虚拟化NFV架构的调度管理方法及装置
技术领域
本申请涉及通信技术领域,具体涉及一种网络功能虚拟化NFV架构的调度管理方法及装置。
背景技术
网络功能虚拟化(network functions virtualization,NFV)是由欧洲电信标准化协会(European telecommunications standards institute,ETSI)从网络运营商的角度出发提出的一种软件和硬件分离的架构,目标是基于现代化的虚拟化技术,采用通用硬件,例如业界标准的大容量服务器、存储和交换机等,承载多种网络软件功能,实现软件的灵活加载。
NFV架构如图1所示,参见图1,在NFV架构中所涉及到的网元包括:虚拟化的网络功能管理器(VNF manager,VNFM)、虚拟化基础设施管理器(virtualised infrastructuremanager,VIM)、平台即服务(platform as a service,PaaS)、网络功能虚拟化基础设施层(Network Functions Virtualization Infrastructure,NFVI)和最小部署单元Pod。其中,VNFM的主要功能是实现对VNF的生命周期管理,如部署/扩容/缩容/下线等自动化能力;VNFM根据模板及VNF容量需求,分解出对虚拟机等虚拟资源的需求,能够与VIM等配合完成VNF的实例化;VIM的主要功能是实现对整个基础设施层资源(例如计算、存储、网络资源)的管理和监控;VNFM和VIM共同构成NFV管理的模块,并且,能够与PaaS进行交互;PaaS是将服务器平台作为一种服务提供的商业模式,在PaaS中设置有调度器(例如Google开源的容器编排引擎Kubernetes),该调度器用于为容器化的应用提供资源调度、部署运行和扩缩容等功能;NFVI用于对NFV的基础设施建设,在NFVI中可以包括虚拟计算(Virtual Computing)、虚拟存储(Virtual Storage)、虚拟网络(Virtual Network)、虚拟化层(VirtualisationLayer)和硬件资源(Hardware resources);VNF用于承担虚拟化的功能。Pod是PaaS中的调度器创建、调度和管理的最小单位,运行在虚拟机(Virtual Machine,VM)内;另外,VM被部署在主机(HOST)内,即VM为Pod的父节点,而HOST为Pod的父父节点。
为了应对各种应用场景,NFV架构支持对Pod进行亲和性/反亲和性的调度,Pod亲和性的调度指的是将相同类型的Pod部署在相同的VM中,Pod反亲和性的调度指的是将相同或不同类型的各个Pod部署在不同的VM中。其中,对Pod进行亲和性的调度,即将相同类型的Pod部署在不同VM中,能够减少宕机影响,对Pod进行反亲和性的调度,即将不同类型的Pod部署在不同VM中,能够避免不同类型的Pod之间的干扰。
目前对Pod进行的亲和性/反亲和性的调度时,预先为不同VM分别设置相应的标签,通过标签对VM进行划分,然后根据VM的标签确定Pod所需部署的VM。例如,当需要对Pod进行亲和性的调度,将各个相同类型的Pod部署在同一个VM时,可为该VM设置目标标签,将各个相同类型的Pod部署在目标标签对应的VM中,从而使各个相同类型的Pod均部署在目标标签对应的VM中,实现Pod的亲和性的调度;当需要对Pod进行反亲和性的调度,将各个Pod部署在不同的VM时,可为不同VM设置不同的标签,在部署Pod的过程中,当确定某一标签对应的VM中已部署有Pod时,则将待部署的Pod部署在其他标签对应的VM中,从而将各个Pod部署在不同的VM中,实现Pod的反亲和性调度。
但是,发明人在本申请的研究过程中发现,现有技术只能实现Pod在VM级别的调度,即只能将某一种类型的Pod部署在特定类型的VM内,有些应用场景下,需要实现Pod在HOST级别的调度,但现有技术无法满足Pod在HOST的调度需求,即通过现有技术,无法将某一Pod只部署在特定的HOST内。
发明内容
为了解决现有技术无法满足Pod在HOST的调度需求的问题,本申请实施例公开一种网络功能虚拟化NFV架构的调度管理方法及装置。
第一方面,本申请实施例公开一种网络功能虚拟化NFV架构的调度管理方法,包括:
NFV架构中的调度管理设备获取各个虚拟机VM所属的主机HOST,并为所述VM设置相应的VM标签,所述VM标签包括所述VM所属的HOST的信息;
所述调度管理设备在确定第一VM从第一HOST迁移至第二HOST之后,根据所述第一VM迁移后所属的HOST,更新所述第一VM的VM标签;
所述调度管理设备触发所述NFV架构中的调度器,所述调度器用于当根据所述第一VM更新后的VM标签,确定所述第一VM中的第一最小部署单元Pod不符合部署需求时,将所述第一Pod调度至所述第一HOST的第二VM中。
通过本申请实施例公开的方案,能够使某一种Pod部署在特定的HOST中,从而满足Pod在HOST的调度需求,解决现有技术的问题。
一种可选的设计中,所述调度管理设备通过所述NFV架构中的虚拟化基础设施管理器VIM反馈的VM创建成功信息,获取各个VM所属的主机HOST;
和/或,所述调度管理设备通过所述VIM反馈的VM迁移完成信息,确定所述第一VM从第一HOST迁移至第二HOST。
一种可选的设计中,所述调度管理设备为虚拟化的网络功能管理器VNFM;
或者,所述调度管理设备为内置有所述调度器的平台即服务模块PaaS。
一种可选的设计中,当所述调度管理设备为VNFM时,所述调度管理设备触发所述NFV架构中的调度器,包括:
所述VNFM将所述第一VM的VM标签变更信息传输至所述NFV架构中的PaaS,通过所述第一VM的VM标签变更信息触发所述PaaS内置的所述调度器;
当所述调度管理设备为PaaS时,所述调度管理设备触发所述NFV架构中的调度器,包括:
所述PaaS确定所述第一VM的VM标签发生变化之后,触发内置的所述调度器。
一种可选的设计中,当所述调度管理设备为VNFM时,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述VNFM将所述VM与VM标签的对应关系传输至所述PaaS。
PaaS能够获取VM与VM标签的对应关系,从而能够根据该对比关系确定各个VM的VM标签,并在接收到VNFM传输的第一VM的VM标签变更信息之后,根据所述第一VM的VM标签变更信息,判断第一VM的VM标签是否发生变更。
一种可选的设计中,在所述调度管理设备为所述VM设置相应的VM标签之前,还包括:
所述调度管理设备向VIM下发创建第一VM和第二VM的指令,所述VIM用于在接收到所述指令之后,创建第一VM和第二VM,并在创建成功后,向所述调度管理设备反馈第一VM和第二VM的创建成功消息。
当需要创建VM时,NFV架构中的调度管理设备等会向NFV架构中的VIM下发创建VM的指令,以使VIM根据该指令创建相应的VM,并且,在VM创建成功之后,VIM会向调度管理设备反馈相应的VM创建成功消息,从而能够实现第一VM和第二VM的创建,以及使调度管理设备获取第一VM和第二VM的创建成功消息。
在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述调度管理设备下发创建第一Pod的指令,所述创建第一Pod的指令中包括所述第一Pod对应的HOST的信息。
当需要在第一HOST中部署第一Pod时,可在创建第一Pod的指令中设置第一HOST的信息,第一HOST中的第一VM接收到创建第一Pod的指令之后,确定自身的VM标签中包括的HOST的信息,与创建第一Pod的指令中包括的HOST的信息相同,则创建部署在自身的第一Pod,从而能够在第一VM中创建第一Pod。
一种可选的设计中,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述调度管理设备向VIM下发创建第三VM和第四VM的指令,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,所述VIM用于根据所述创建第三VM和第四VM的指令,在不同的HOST中分别创建第三VM和第四VM;
所述调度管理设备向所述调度器下发创建第二Pod的指令,所述调度器用于在接收到所述创建第二Pod的指令之后,当确定第二Pod与所述第三VM中的第三Pod具有强反亲和性时,在所述第四VM中创建所述第二Pod。
由于第二Pod与第三Pod具有强反亲和性,因此需要将第二Pod与第三Pod部署在不同的VM中,这种情况下,通过上述步骤,当第三VM中部署有第三Pod时,则将第二Pod部署至第四VM中,从而能够保障第二Pod与第三Pod之间的强反亲和性。
一种可选的设计中,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
当需要创建第一类型的VM时,所述调度管理设备根据预先设定的所述第一类型的VM在同一HOST的数量限制,生成创建第一类型的VM的指令;
所述创建第一类型的VM的指令中包含所述第一类型的VM的数量限制,所述创建第一类型的VM的指令用于指示在同一HOST中,所创建的第一类型的VM的数量不大于所述数量限制。
通过上述步骤,能够保障在同一个HOST中创建的第一类型的VM的数量不超过所述数量限制。
第二方面,本申请实施例公开一种网络功能虚拟化NFV架构的调度装置,应用于调度管理设备中,包括:
收发单元,用于获取各个虚拟机VM所属的主机HOST;
处理单元,用于为所述VM设置相应的VM标签,所述VM标签包括所述VM所属的HOST的信息,在确定第一VM从第一HOST迁移至第二HOST之后,根据所述第一VM迁移后所属的HOST,更新所述第一VM的VM标签,并且,触发所述NFV架构中的调度器,所述调度器用于当根据所述第一VM更新后的VM标签,确定所述第一VM中的第一最小部署单元Pod不符合部署需求时,将所述第一Pod调度至所述第一HOST的第二VM中。
一种可选的设计中,所述处理单元用于通过所述NFV架构中的虚拟化基础设施管理器VIM反馈的VM创建成功信息,获取各个VM所属的主机HOST;
和/或,所述处理单元用于通过所述VIM反馈的VM迁移完成信息,确定所述第一VM从第一HOST迁移至第二HOST。
一种可选的设计中,本申请实施例公开所述调度管理设备为虚拟化的网络功能管理器VNFM;
或者,所述调度管理设备为内置有所述调度器的平台即服务模块PaaS。
一种可选的设计中,本申请实施例公开当所述调度管理设备为VNFM时,所述处理单元用于将所述第一VM的VM标签变更信息传输至所述NFV架构中的PaaS,通过所述第一VM的VM标签变更信息触发所述PaaS内置的所述调度器;
当所述调度管理设备为PaaS时,所述处理单元用于确定所述第一VM的VM标签发生变化之后,触发内置的所述调度器。
一种可选的设计中,本申请实施例公开当所述调度管理设备为VNFM时,在所述处理单元为所述VM设置相应的VM标签之后,所述收发单元还用于将所述VM与VM标签的对应关系传输至所述PaaS。
一种可选的设计中,本申请实施例公开在为所述VM设置相应的VM标签之前,所述处理单元还用于通过所述收发单元,向VIM下发创建第一VM和第二VM的指令,所述VIM用于在接收到所述指令之后,创建第一VM和第二VM,并在创建成功后,向所述调度管理设备反馈第一VM和第二VM的创建成功消息;
在为所述VM设置相应的VM标签之后,所述处理单元还用于通过所述收发单元,下发创建第一Pod的指令,所述创建第一Pod的指令中包括所述第一Pod对应的HOST的信息。
一种可选的设计中,本申请实施例公开在所述处理单元为所述VM设置相应的VM标签之后,所述处理单元还用于通过所述收发单元,向VIM下发创建第三VM和第四VM的指令,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,所述VIM用于根据所述创建第三VM和第四VM的指令,在不同的HOST中分别创建第三VM和第四VM;
所述处理单元还用于通过所述收发单元,向所述调度器下发创建第二Pod的指令,所述调度器用于在接收到所述创建第二Pod的指令之后,当确定第二Pod与所述第三VM中的第三Pod具有强反亲和性时,在所述第四VM中创建所述第二Pod。
一种可选的设计中,本申请实施例公开在为所述VM设置相应的VM标签之后,当需要创建第一类型的VM时,所述处理单元还用于,根据预先设定的所述第一类型的VM在同一HOST的数量限制,生成创建第一类型的VM的指令;
所述创建第一类型的VM的指令中包含所述第一类型的VM的数量限制,所述创建第一类型的VM的指令用于指示在同一HOST中,所创建的第一类型的VM的数量不大于所述数量限制。
第三方面,本申请实施例公开一种网络功能虚拟化NFV架构的调度管理设备,包括:
处理器和存储器;
其中,所述存储器,用于存储程序指令;
所述处理器,用于调用并执行所述存储器中存储的程序指令,以使所述调度管理设备执行执行第一方面,或第一方面的任意一种可能的设计中的方法。
第四方面,本申请实施例公开一种计算机可读介质,包括指令,当其在计算机上运行时,使得计算机执行第一方面,或第一方面的任意一种可能的设计中的方法。
本申请实施例公开的调度管理方法中,调度管理设备首先根据各个VM所属的HOST,为VM设置相应的VM标签,通过VM的VM标签,能够实现对VM的划分,这种情况下,位于同一个HOST内的VM为同一类型;然后,调度管理设备在确定第一VM从第一HOST迁移至第二HOST之后,将所述第一VM的VM标签更新为所述第二HOST,再触发NFV架构中的调度器,所述调度器确定第一VM中的第一Pod是否符合部署需求,若不符合,则调度器会将第一Pod调度至第一HOST的第二VM中,从而在第一VM发生迁移之后,仍然使第一Pod部署在第一HOST中,满足第一Pod的部署需求。
在现有技术中,只能将某一种Pod部署在特定类型的VM中,无法满足Pod在HOST的调度需求。而通过本申请实施例公开的方案,能够使某一种Pod部署在特定的HOST中,从而满足Pod在HOST的调度需求,解决现有技术的问题。
附图说明
为了更清楚地说明本申请的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例应用的一种NFV的架构示意图;
图2为本申请实施例公开的一种NFV架构的调度管理方法的工作流程示意图;
图3为本申请实施例公开的一种NFV架构的调度管理方法中,Pod部署的示意图;
图4为本申请实施例公开的NFV架构的调度管理方法中,一种NFV架构中各个网元的信息交互示意图;
图5为本申请实施例公开的NFV架构的调度管理方法中,又一种NFV架构中各个网元的信息交互示意图;
图6为本申请实施例公开的又一种NFV架构的调度管理方法的工作流程示意图;
图7为本申请实施例公开的NFV架构的调度管理方法中,又一种NFV架构中各个网元的信息交互示意图;
图8为本申请实施例公开的一种NFV架构的调度管理装置的结构示意图;
图9为本申请实施例公开的一种NFV架构的调度管理设备的结构示意图。
具体实施方式
为了解决现有技术无法满足Pod在HOST的调度需求的问题,本申请实施例公开一种网络功能虚拟化NFV架构的调度管理方法及装置,其中,本申请实施例公开的方案,可应用于图1所示的NFV架构中。
为了明确本申请实施例公开的方案,以下分别通过各个实施例公开本申请的方案。
本申请第一实施例公开一种网络功能虚拟化NFV架构的调度管理方法,参见图2所示的工作流程示意图,所述网络功能虚拟化NFV架构的调度管理方法包括以下步骤:
步骤S11、NFV架构中的调度管理设备获取各个虚拟机VM所属的主机HOST,并为所述VM设置相应的VM标签,所述VM标签包括所述VM所属的HOST的信息。
其中,HOST为VM的父节点,也就是说,VM设置在HOST中,一个HOST中可设置一个或多个VM。
在NFV架构中,可由VIM创建VM。这种情况下,当需要创建VM时,NFV架构中的调度管理设备向VIM发送VM创建指令,VIM在接收到VM创建指令之后,在HOST中创建VM。
另外,在完成VM的创建之后,VIM可向调度管理设备反馈VM所属的HOST,从而能够使调度管理设备获取到各个VM所属的HOST,并据此为所述VM设置相应的VM标签。其中,VM标签中包括的HOST信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该HOST信息可以为HOST在NFV架构中的网元编号、地址信息或身份标识等。
步骤S12、所述调度管理设备在确定第一VM从第一HOST迁移至第二HOST之后,根据所述第一VM迁移后所属的HOST,更新所述第一VM的VM标签。这种情况下,更新后的VM标签中包括的HOST信息为第二HOST的信息。
VM在被创建之后,还可能会发生迁移,例如,当第一HOST中的VM发生故障时,该VM可迁移至第二HOST中。
另外,VM在迁移至新的HOST之后,VIM还可将VM所迁移的新的HOST反馈至调度管理设备,从而能够使调度管理设备确定各个VM是否发生迁移,以及VM在迁移前后所属的HOST。
步骤S13、所述调度管理设备触发所述NFV架构中的调度器,所述调度器用于当根据所述第一VM更新后的VM标签,确定所述第一VM中的第一最小部署单元Pod不符合部署需求时,将所述第一Pod调度至所述第一HOST的第二VM中。
其中,所述调度器可以设置在NFV架构中的PaaS中,例如,该调度器可以为PaaS中设置的Google开源的容器编排引擎Kubernetes。
所述调度管理设备在更新第一VM的VM标签之后,触发调度器。所述调度器被触发之后,根据所述第一VM更新后的VM标签,确定第一VM中的第一最小部署单元Pod是否符合部署需求。其中,调度器确定第一Pod是否符合部署需求时,是根据第一Pod的亲和性/反亲和性的需求。如果第一Pod的亲和性/反亲和性的需求表明,第一Pod需要设置在第一HOST的VM中,则根据第一VM更新后的VM标签,调度器会确定第一Pod部署在第二HOST中,进一步确定第一Pod不符合部署需求,从而将第一Pod调度至第一HOST的第二VM中。由于第二VM设置在第一HOST中,则第二VM的VM标签为第一HOST,在第一Pod被调度至第二VM中之后,可以满足第一Pod的亲和性/反亲和性的需求,从而使第一Pod部署在第一HOST,满足第一Pod的部署需求。
本申请实施例公开的调度管理方法中,调度管理设备首先根据各个VM所属的HOST,为VM设置相应的VM标签,通过VM的VM标签,能够实现对VM的划分,这种情况下,位于同一个HOST内的VM为同一类型;然后,调度管理设备在确定第一VM从第一HOST迁移至第二HOST之后,将所述第一VM的VM标签更新为所述第二HOST,再触发NFV架构中的调度器,所述调度器确定第一VM中的第一Pod是否符合部署需求,若不符合,则调度器会将第一Pod调度至第一HOST的第二VM中,从而在第一VM发生迁移之后,仍然使第一Pod部署在第一HOST中,满足第一Pod的部署需求。
在现有技术中,只能将某一种Pod部署在特定类型的VM中,无法满足Pod在HOST的调度需求。而通过本申请实施例公开的方案,能够使某一种Pod部署在特定的HOST中,从而满足Pod在HOST的调度需求,解决现有技术的问题。
为了明确本申请实施例所满足的调度需求,可参见图3所示的Pod部署的示意图。在图3中,设置有第一HOST和第二HOST,其中,在迁移前,第一VM和第二VM均设置在第一HOST中,则第一VM和第二VM的VM标签均包括第一HOST的信息,并且,第一VM中设置有第一Pod,第二HOST中设置有第三VM,则第三VM的VM标签包括第二HOST的信息。第一VM迁移至第二HOST之后,第一VM的VM标签更新为包括第二HOST的信息,这种情况下,调度器会对第一Pod进行调度,使第一Pod被调度至第一HOST的第二VM中,从而使第一Pod仍然部署在第一HOST中。
另外,在本申请实施例中,通过VM标签对VM进行划分,调度器根据VM的VM标签,确定第一VM中的第一Pod是否符合部署需求并对第一Pod进行调度,使第一Pod部署在特定类型的VM中。该操作可通过以下几种方式实现:
在第一种方式中,在Pod的配置文件中设置该Pod的节点选择属性(即nodeSelector属性),该节点选择属性用于指示Pod可以部署在具有哪些标签的VM中。当Pod部署在节点选择属性指示的标签所对应的VM中时,则调度器确定该Pod符合部署需求,当Pod未部署在节点选择属性指示的标签所对应的VM中时,则调度器确定该Pod不符合部署需求,并对该Pod进行调度,从而使该Pod能够部署在节点选择属性所指示的特定类型的VM中,即使第一Pod部署在特定类型的VM中。
例如,当第一Pod的配置文件中,设置第一Pod的节点选择属性为具有第一VM标签的VM,并且第一VM标签为包括第一HOST的信息的标签时,则第一Pod部署在第一HOST的VM中时,第一Pod满足部署需求。这种情况下,调度器通过查询第一Pod的配置文件,获取第一Pod的节点选择属性,当第一Pod部署在第一VM中,且第一VM未发生迁移时,第一Pod对应的VM标签指示第一Pod部署在第一HOST的VM中,则第一Pod满足部署需求。当随着第一VM的迁移,第一Pod也被迁移至第二HOST时,调度器根据第一VM更新后的VM标签,可确定第一Pod部署在第二HOST的VM中,即第一Pod不再满足部署需求,这种情况下,调度器将第一Pod调度至第一HOST的第二VM中,以使第一Pod符合部署需求。通过该方式,能够使第一Pod始终部署在第一HOST的VM中。
第二种方式依据的是Pod的节点亲和性(即nodeAffinity)调度策略,在nodeAffinity调度策略中,可在Pod配置文件中设置多种类型的调度信息,以实现对Pod的调度。其中一种类型的调度信息表示在首次调度时,VM必须满足某些条件,才能在该VM中部署Pod;另一种类型的调度信息表示在Pod的运行过程中,如果Pod所在VM的属性信息(该属性信息可以为VM的标签)发生改变,该Pod会从该VM中调度至其他VM;另一种类型的信息表示在Pod的运行过程中,如果Pod所在VM的属性信息(该属性信息可以为VM的标签)发生改变,Pod可在该VM中继续运行;另一种类型的信息表示在Pod的运行过程中,如果Pod所在VM的属性信息(该属性信息可以为VM的标签)发生改变,Pod不一定从该VM中调度至其他VM。
当调度器通过nodeAffinity调度策略实现对第一Pod的调度时,可在第一Pod的配置文件中设置相应信息,该信息指示第一Pod所在VM的VM标签发生改变时,第一Pod会从该VM中调度至其他VM。这种情况下,当随着第一VM的迁移,第一Pod也被迁移至第二HOST时,调度器通过nodeAffinity调度策略,确定第一Pod不符合部署需求,从而将第一Pod调度至第一HOST的第二VM中,以使第一Pod符合部署需求。通过该方式,能够使第一Pod始终部署在第一HOST的VM中。
进一步的,在本申请实施例中,所述调度管理设备通过所述NFV架构中的虚拟化基础设施管理器VIM反馈的VM创建成功信息,获取各个VM所属的主机HOST。
其中,VIM用于在接收到VM创建指令之后,在HOST中创建VM。在完成VM的创建之后,VIM向调度管理设备反馈VM创建成功信息,VM创建成功信息中包含各个VM所属的HOST的相关信息,该相关信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为HOST的地址信息或身份标识等,从而使调度管理设备确定各个VM所属的HOST,并根据各个VM所属的HOST,为VM设置相应的VM标签,所述VM标签中包括所述VM所属的HOST的信息。
和/或,在本申请实施例中,所述调度管理设备通过所述VIM反馈的VM迁移完成信息,确定所述第一VM从第一HOST迁移至第二HOST。
其中,在NFV架构中的VM完成迁移之后,VIM会向调度管理设备反馈迁移完成信息,该迁移完成信息中包括发生迁移的VM的相关信息以及迁移后所属的HOST的相关信息,VM的相关信息为能够确定VM身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为VM的地址信息或身份标识等,HOST的相关信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为HOST的地址信息或身份标识等。调度管理设备在接收到该迁移完成信息之后,能够确定发生迁移的VM,以及该VM迁移后所属的HOST。
这种情况下,在第一VM从第一HOST迁移至第二HOST之后,VIM反馈的迁移完成信息中包括第一VM的相关信息以及第二HOST的相关信息,从而能够使调度管理设备确定第一VM从第一HOST迁移至第二HOST。
进一步的,在NFV架构中,往往包含多种网元,相应的,所述调度管理设备可为不同类型的网元。在其中一种可行的实施方式中,所述调度管理设备为虚拟化的网络功能管理器VNFM,或者,在另一种可行的实施方式中,所述调度管理设备为内置有所述调度器的平台即服务模块PaaS。
其中,当所述调度管理设备为VNFM时,所述调度管理设备触发所述NFV架构中的调度器,包括:
所述VNFM将所述第一VM的VM标签变更信息传输至所述NFV架构中的PaaS,通过所述第一VM的VM标签变更信息触发所述PaaS内置的所述调度器。
当所述调度管理设备为VNFM时,VNFM在更新第一VM的VM标签之后,向PaaS传输第一VM的VM标签变更信息,所述第一VM的VM标签变更信息中,包含第一VM变更后的VM标签。PaaS在接收到所述第一VM的VM标签变更信息之后,确定第一VM的VM标签是否发生变化,并在确定发生变化的情况下,驱动自身内置的调度器,该调度器根据第一VM更新后的VM标签,确定第一Pod是否符合部署需求,并在确定不符合部署需求时,将第一Pod调度至所述第一HOST的第二VM中。
另外,当所述调度管理设备为PaaS时,所述调度管理设备触发所述NFV架构中的调度器,包括:
所述PaaS确定所述第一VM的VM标签发生变化之后,触发内置的所述调度器。
当所述调度管理设备为PaaS时,PaaS确定第一VM的VM标签是否发生变化,当确定第一VM的VM标签发生变化时,PaaS会触发自身内置的调度器,该调度器根据第一VM更新后的VM标签,确定第一Pod是否符合部署需求,并在确定不符合部署需求时,将第一Pod调度至所述第一HOST的第二VM中。
进一步的,在本申请实施例公开的方法中,当所述调度管理设备为VNFM时,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述VNFM将所述VM与VM标签的对应关系传输至所述PaaS。
这种情况下,PaaS能够获取VM与VM标签的对应关系,从而能够根据该对比关系确定各个VM的VM标签,并在接收到VNFM传输的第一VM的VM标签变更信息之后,根据所述第一VM的VM标签变更信息,判断第一VM的VM标签是否发生变更。
例如,当调度管理设备为VNFM时,VNFM在确定第一VM所属的HOST为第一HOST之后,为第一VM设置的VM标签包括第一HOST的信息,并将第一VM与其VM标签的对应关系传输至PaaS。在第一VM从第一HOST迁移至第二HOST之后,VNFM向PaaS传输第一VM的VM标签变更信息,所述第一VM的VM标签变更信息中包括第一VM迁移后所属的HOST(即第二HOST)的信息。PaaS在接收到第一VM的VM标签变更信息之后,确定第一VM当前的VM标签包括第二HOST的信息,从而可以确定第一VM的VM标签发生变更。
进一步的,在本申请实施例中,在所述调度管理设备为所述VM设置相应的VM标签之前,还包括以下操作:
所述调度管理设备向VIM下发创建第一VM和第二VM的指令,所述VIM用于在接收到所述指令之后,创建第一VM和第二VM,并在创建成功后,向所述调度管理设备反馈第一VM和第二VM的创建成功消息。
当需要创建VM时,NFV架构中的调度管理设备等会向NFV架构中的VIM下发创建VM的指令,以使VIM根据该指令创建相应的VM,并且,在VM创建成功之后,VIM会向调度管理设备反馈相应的VM创建成功消息。
在所述创建VM的指令中,可包括需创建的VM所属的HOST信息,例如,当需要在第一HOST中创建第一VM时,创建第一VM的指令中可包括第一HOST的信息,这种情况下,VIM接收到创建第一VM的指令之后,可确定需要在第一HOST中创建第一VM。
另外,在所述创建VM的指令中,还可包括需创建的VM的相关参数,该相关参数可以包括该VM对中央处理器(Central Processing Unit,CPU)资源的需求,和/或对内存资源的需求,和/或亲和性和反亲和性的需求等。这种情况下,VIM会基于所述创建VM的指令中包括的需创建的VM的相关参数,查找合适的HOST,并在合适的HOST创建该VM。
其中,该调度管理设备可以为VNFM或PaaS。当该调度管理设备为VNFM时,VNFM下发创建VM的指令,并且,VIM向VNFM反馈VM创建成功消息;当该调度管理设备为PaaS时,PaaS下发创建VM的指令,并且,VIM向PaaS反馈VM创建成功消息。
另外,除了调度管理设备以外,还可以由NFV架构中的其他网元生成并下发创建VM的指令,例如,当该调度管理设备为PaaS时,可由VNFM生成并下发创建VM的指令。
进一步的,在本申请实施例中,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述调度管理设备下发创建第一Pod的指令,所述创建第一Pod的指令中包括所述第一Pod对应的HOST的信息。
在接收到创建第一Pod的指令之后,VM会确定自身的VM标签中所包括的HOST的信息,是否与创建第一Pod的指令中包括的HOST的信息是否相同,如果相同,则该VM会创建部署与自身的第一Pod。
在本申请实施例中,当需要在第一HOST中部署第一Pod时,可在创建第一Pod的指令中设置第一HOST的信息。这种情况下,第一HOST中的第一VM接收到创建第一Pod的指令之后,确定自身的VM标签中包括的HOST的信息,与创建第一Pod的指令中包括的HOST的信息相同,则创建部署在自身的第一Pod。
其中,当调度管理设备为VNFM时,VNFM通常将创建Pod的指令下发至PaaS,PaaS在接收到该指令之后,可根据创建Pod的指令中的HOST的信息,确定相应的VM,并在该VM中创建Pod。例如,若创建Pod的指令中包括第一HOST的信息,则PaaS会在第一HOST中的VM中创建该Pod。
本申请的上述实施例描述了本申请的调度管理方法中,调度管理设备所需要执行的操作。为了明确NFV架构中各个网元的交互过程,本申请实施例公开图4。
在图4所示的应用场景中,调度管理设备为VNFM,参见图4所示的信息交互示意图,NFV架构中各个网元的交互过程包括以下步骤:
步骤S21、VNFM向VIM下发创建第一VM和第二VM的指令,以使VIM根据该指令创建相应的第一VM和第二VM。
在创建VM的指令中,可包括需创建的VM所属的HOST信息,例如,当需要在第一HOST中创建第一VM时,创建第一VM的指令中可包括第一HOST的信息,这种情况下,VIM接收到创建第一VM的指令之后,可确定需要在第一HOST中创建第一VM。
另外,在所述创建VM的指令中,还可包括需创建的VM的相关参数,该相关参数可以包括该VM对中央处理器(Central Processing Unit,CPU)资源的需求,和/或对内存资源的需求,和/或亲和性和反亲和性的需求等。这种情况下,VIM会基于所述创建VM的指令中包括的需创建的VM的相关参数,查找合适的HOST,并在合适的HOST创建该VM。
在本申请实施例中,若需要在第一HOST中创建第一VM和第二VM,则所述第一VM和第二创建VM的指令可包括第一VM和第二VM所属的HOST(即第一HOST)的相关信息,以便VIM在第一HOST中创建第一VM和第二VM。
或者,所述创建第一VM和第二VM的指令分别包括第一VM和第二VM的相关参数,当VIM根据第一VM和第二VM的相关参数,确定第一HOST满足第一VM和第二VM的创建条件时,会在第一HOST中创建第一VM和第二VM。
步骤S22、所述VIM接收到创建第一VM的指令之后,确定用于创建第一VM的第一HOST,并在第一HOST中创建第一VM。
步骤S23、所述VIM接收到创建第二VM的指令之后,确定能够创建第二VM的第一HOST,并在第一HOST中创建第二VM。
其中,在实际执行过程中,步骤S22和步骤S23的先后执行顺序并无严格规定,例如,还可以先执行步骤S23的操作,然后再执行步骤S22的操作。
步骤S24、在第一VM和第二VM创建成功之后,VIM向VNFM发送VM创建成功信息,该VM创建成功信息中包含第一VM和第二VM分别所属的HOST的相关信息。
步骤S25、VNFM根据第一VM和第二VM分别所属的HOST的相关信息,为第一VM和第二VM设置相应的VM标签,即为第一VM设置的VM标签包括第一HOST的信息,为第二VM设置的VM标签包括第一HOST的信息。
步骤S26、VNFM向PaaS传输VM纳管请求,以使PaaS对第一VM和第二VM进行纳管,该VM纳管请求中可以包括第一VM和第二VM分别与自身的VM标签的对应关系。或者,还可以单独产生一条通知消息,在该通知消息中包括第一VM和第二VM分别与自身的VM标签的对应关系,并向PaaS传输该通知消息。
通过该步骤,能够使PaaS纳管第一VM和第二VM,并且获取第一VM和第二VM分别与VM标签的对应关系。
步骤S27、PaaS接收到VNFM传输的VM纳管请求之后,对第一VM和第二VM进行纳管操作。
其中,在进行纳管操作时,PaaS可在第一VM和第二VM上分别部署相应的进程/组件,从而纳管第一VM和第二VM。另外,PaaS在接收到第一VM和第二VM分别与自身的VM标签的对应关系之后,还会保存该对应关系。
上述步骤S21至步骤S27为VM的准备阶段,通过该阶段,能够创建第一VM和第二VM,并且VNFM为第一VM和第二VM设置相应的VM标签,并且由PaaS纳管该第一VM和第二VM,以及使PaaS获取第一VM和第二VM分别与自身的VM标签的对应关系。
步骤S28、VNFM向PaaS下发创建Pod的指令,所述创建Pod的指令中包括所述第一Pod对应的HOST的信息。
其中,当需要在第一HOST中创建第一Pod时,所述VNFM向PaaS下发创建第一Pod的指令,创建第一Pod的指令中的包括第一HOST的信息。
步骤S29、Paas接收到创建Pod的指令后,根据该指令中的HOST的信息,确定相应的HOST,并在该HOST中选择合适的VM,再向该VM下发创建Pod的指示。
其中,当所述创建Pod的指令中的HOST的信息为第一HOST时,可在第一HOST的第一VM中创建第一Pod,则Paas会向第一VM下发创建第一Pod的指示。
步骤S30、第一VM接收到创建第一Pod的指示之后,根据该指示创建第一Pod,并启动运行第一Pod。
上述步骤S28至步骤S30为Pod的创建启动阶段,通过该阶段,能够在第一VM中创建第一Pod。
步骤S31、VIM检测到第一VM满足迁移条件之后,对第一VM进行迁移。
其中,VIM检测到第一VM发生需要迁移的故障时,通常认为第一VM满足迁移条件。或者,当VIM检测到第一VM所在的HOST(即第一HOST)无法满足第一VM的运行需求(例如第一HOST发生故障等)时,也会认为第一VM满足迁移条件。
步骤S32、VIM在感应到第一VM完成迁移操作之后,向VNFM反馈迁移完成信息。
该迁移完成信息中包括发生迁移的VM(即第一VM)的相关信息以及迁移后所属的HOST(即第二HOST)的相关信息,VM的相关信息为能够确定VM身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为VM的地址信息或身份标识等,HOST的相关信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为HOST的地址信息或身份标识等。VNFM在接收到该迁移完成信息之后,能够确定发生迁移的VM,以及该VM迁移后所属的HOST。
步骤S33、VNFM更新所述第一VM的VM标签,更新后的VM标签包括第二HOST的信息。
步骤S34、VNFM将所述第一VM的VM标签变更信息传输至PaaS,所述第一VM的VM标签变更信息中包含第一VM更新后的VM标签。
步骤S35、PaaS接收到所述第一VM的VM标签变更信息之后,确定第一VM的VM标签发生变更,从而触发自身内置的调度器。该调取器根据第一VM更新后的VM标签,判断第一Pod是否符合部署需求,当确定第一Pod不符合部署需求时,则该调度器将第一Pod调度至第一HOST的第二VM中。
步骤S36、第一Pod被调度至第二VM中之后,第二VM根据PaaS下发的第一Pod的相关信息,启动第一Pod,使第一Pod正常运行。
上述的步骤S31至步骤S36为Pod的调度阶段。在该阶段中,Pod所在的VM发生迁移时,仍然能够被调度到相应VM中,满足Pod在HOST级别的调度需求。
上述的图4以及步骤S21至步骤S37,公开了调度管理设备为VNFM的情况下,NFV架构中各个网元的交互过程。另外,调度管理设备还可以为NFV架构中的PaaS。当调度管理设备为PaaS时,参见图5所示的信息交互示意图,NFV架构中各个网元的交互过程包括以下步骤:
步骤S41、PaaS向VIM下发创建第一VM和第二VM的指令,以使VIM根据该指令创建相应的第一VM和第二VM。
在创建VM的指令中,可包括需创建的VM所属的HOST信息,例如,当需要在第一HOST中创建第一VM时,创建第一VM的指令中可包括第一HOST的信息,这种情况下,VIM接收到创建第一VM的指令之后,可确定需要在第一HOST中创建第一VM。
另外,在所述创建VM的指令中,还可包括需创建的VM的相关参数,该相关参数可以包括该VM对CPU资源的需求,和/或对内存资源的需求,和/或亲和性和反亲和性的需求等。这种情况下,VIM会基于所述创建VM的指令中包括的需创建的VM的相关参数,查找合适的HOST,并在合适的HOST创建该VM。
在本申请实施例中,若需要在第一HOST中创建第一VM和第二VM,则所述创建第一VM和第二VM的指令可包括第一VM和第二VM所属的HOST(即第一HOST)的相关信息,以便VIM在第一HOST中创建第一VM和第二VM。
或者,所述创建第一VM和第二VM的指令分别包括第一VM和第二VM的相关参数,当VIM根据第一VM和第二VM的相关参数,确定第一HOST满足第一VM和第二VM的创建条件时,会在第一HOST中创建第一VM和第二VM。
步骤S42、所述VIM接收到创建第一VM的指令之后,确定用于创建第一VM的第一HOST,并在第一HOST中创建第一VM。
步骤S43、所述VIM接收到创建第二VM的指令之后,确定能够创建第二VM的第一HOST,并在第一HOST中创建第二VM。
其中,在实际执行过程中,步骤S42和步骤S43的先后执行顺序并无严格规定,例如,还可以先执行步骤S43的操作,然后再执行步骤S42的操作。
步骤S44、在第一VM和第二VM创建成功之后,VIM向PaaS发送VM创建成功信息,该VM创建成功信息中包含第一VM和第二VM分别所属的HOST的相关信息。
步骤S45、PaaS根据第一VM和第二VM分别所属的HOST的相关信息,为第一VM和第二VM设置相应的VM标签,即为第一VM设置的VM标签包括第一HOST的信息,为第二VM设置的VM标签包括第一HOST的信息。
步骤S46、PaaS对第一VM和第二VM进行纳管操作。
其中,在进行纳管操作时,PaaS可在第一VM和第二VM上分别部署相应的进程/组件,从而纳管第一VM和第二VM。
其中,在实际执行过程中,步骤S45和步骤S46的先后执行顺序并无严格规定,例如,还可以先执行步骤S46的操作,然后再执行步骤S45的操作。
上述步骤S41至步骤S46为VM的准备阶段,通过该阶段,能够创建第一VM和第二VM,并且PaaS为第一VM和第二VM设置相应的VM标签,以及使PaaS获取第一VM和第二VM分别与自身的VM标签的对应关系,并且由PaaS纳管该第一VM和第二VM。
步骤S47、Paas向VM下发创建Pod的指令。
其中,Paas可确定待创建的Pod对应的HOST,并根据各个VM的VM标签,确定该HOST内部署的VM,在该HOST内部署的VM中选择合适的VM,再向该VM下发创建Pod的指示。
其中,当需要在第一HOST中创建Pod时,待创建的Pod对应的HOST即为第一HOST,这种情况下,可在第一HOST的第一VM中创建第一Pod,则PaaS会向第一VM下发创建第一Pod的指令。
步骤S48、第一VM接收到创建第一Pod的指令之后,根据该指令创建第一Pod,并启动运行第一Pod。
上述步骤S47至步骤S48为Pod的创建启动阶段,通过该阶段,能够在第一VM中创建第一Pod。
步骤S49、VIM检测到第一VM满足迁移条件之后,对第一VM进行迁移。
其中,VIM检测到第一VM发生需要迁移的故障时,通常认为第一VM满足迁移条件。或者,当VIM检测到第一VM所在的HOST(即第一HOST)无法满足第一VM的运行需求(例如第一HOST发生故障等)时,也会认为第一VM满足迁移条件。
步骤S50、VIM在感应到第一VM完成迁移操作之后,向PaaS反馈迁移完成信息。
该迁移完成信息中包括发生迁移的VM(即第一VM)的相关信息以及迁移后所属的HOST(即第二HOST)的相关信息,VM的相关信息为能够确定VM身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为VM的地址信息或身份标识等,HOST的相关信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为HOST的地址信息或身份标识等。PaaS在接收到该迁移完成信息之后,能够确定发生迁移的VM,以及该VM迁移后所属的HOST。
步骤S51、PaaS更新所述第一VM的VM标签,更新后的VM标签包括第二HOST的信息。
步骤S52、在更新所述第一VM的VM标签之后,PaaS触发自身内置的调度器。该调取器根据第一VM更新后的VM标签,判断第一Pod是否符合部署需求,当确定第一Pod不符合部署需求时,则该调度器将第一Pod调度至第一HOST的第二VM中。
步骤S53、第一Pod被调度至第二VM中之后,第二VM根据PaaS下发的第一Pod的相关信息,启动第一Pod,使第一Pod正常运行。
上述的步骤S49至步骤S53为Pod的调度阶段。在该阶段中,Pod所在的VM发生迁移时,仍然能够被调度到相应VM中,满足Pod在HOST级别的调度需求。
上述的图5以及步骤S41至步骤S53,公开了调度管理设备为PaaS的情况下,NFV架构中各个网元的交互过程。该实施例中,由PaaS执行生成创建VM的指令、设置VM的标签以及更新VM标签等多项操作,该交互过程中,无需VNFM参与。
另外,如果NFV架构中同时设置了VNFM和PaaS,并且由PaaS作为调度管理设备时,还可以由VNFM生成创建VM的指令。这种情况下,NFV架构中各个网元的交互过程可包括如下步骤:
VNFM生成创建第一VM和第二VM的指令,并向VIM下发所述创建第一VM和第二VM的指令,用于指示创建第一VM和第二VM;
接收到创建第一VM和第二VM的指令之后,VIM根据该指令,创建相应的第一VM和第二VM,并在完成创建之后,向VNFM反馈VM创建成功消息;
VNFM在接收到VM创建成功消息之后,向PaaS传输VM纳管请求,用于指示PaaS对第一VM和第二VM进行纳管,或者,VNFM不仅向PaaS传输VM纳管请求,还会向PaaS传输VM创建通知消息,用于通知PaaS当前创建有第一VM和第二VM;
PaaS在接收到VM纳管请求之后,对第一VM和第二VM进行纳管,并且,基于VM纳管请求或VM创建通知消息,PaaS能够确定当前创建有第一VM和第二VM,并为第一VM和第二VM设置相应的VM标签;
当需要创建第一Pod时,VNFM或PaaS生成创建第一Pod的指令,并将该指令传输至第一VM;
第一VM在接收到创建第一Pod的指令之后,创建第一Pod,并启动运行所述第一Pod;
VIM检测到第一VM满足迁移条件之后,对第一VM进行迁移;
VIM在感应到第一VM完成迁移操作之后,可向PaaS传输迁移完成信息,或者,VIM可向VNFM传输迁移完成信息,VNFM再将迁移完成信息转发至PaaS,以使PaaS确定第一VM发生迁移;
PaaS在确定第一VM发生迁移之后,更新所述第一VM的VM标签,更新后的VM标签包括第二HOST的信息,其中,第二HOST即为第一VM迁移之后所在的HOST。
在更新所述第一VM的VM标签之后,PaaS触发自身内置的调度器。该调取器根据第一VM更新后的VM标签,判断第一Pod是否符合部署需求,当确定第一Pod不符合部署需求时,则该调度器将第一Pod调度至第一HOST的第二VM中。
第一Pod被调度至第二VM中之后,第二VM根据PaaS下发的第一Pod的相关信息,启动第一Pod,使第一Pod正常运行。
上述步骤中,公开了NFV架构中同时设置有VNFM和PaaS,并且由PaaS作为调度管理设备的情况下,NFV架构中各个网元的交互过程。该交互过程中,由PaaS执行设置VM标签、更新VM标签以及触发调度器等操作,并由NFVM执行创建VM指令等操作。
进一步的,本申请还公开另一实施例,参见图6,该实施例中,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括以下步骤:
步骤S61、所述调度管理设备向VIM下发创建第三VM和第四VM的指令。
所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,所述VIM用于根据所述创建第三VM和第四VM的指令,在不同的HOST中分别创建第三VM和第四VM。
本申请实施例中,调度管理设备向NFV架构中的VIM下发创建第三VM和第四VM的指令,以便VIM接收到该指令之后,创建第三VM和第四VM。
其中,反亲和性包括强反亲和性和弱反亲和性。具有强反亲和性的两个网元在部署时,不能部署在同一个父节点中。而具有弱反亲和性的两个网元在部署时,尽量部署在不同的父节点中,如果在当前的NFV架构下,将具有弱反亲和性的两个网元部署在不同的父节点较为困难,可将这两个网元部署在同一父节点中。
由于在本申请实施例中,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,则VIM在接收到所述创建第三VM和第四VM的指令,会将第三VM和第四VM分别创建在不同的HOST中,以保障第三VM和第四VM的强反亲和性部署。
步骤S62、所述调度管理设备向所述调度器下发创建第二Pod的指令,所述调度器用于在接收到所述创建第二Pod的指令之后,当确定第二Pod与所述第三VM中的第三Pod具有强反亲和性时,在所述第四VM中创建所述第二Pod。
由于在本申请实施例中,第二Pod与第三Pod具有强反亲和性,则需要将第二Pod与第三Pod部署在不同的VM中,这种情况下,当第三VM中部署有第三Pod时,则将第二Pod部署至第四VM中,从而保障第二Pod与第三Pod之间的强反亲和性。
通过步骤S61至步骤S62公开的方案,能够在两种Pod具有反亲和性的情况下,不在同一VM部署这两种Pod,从VM级别和Pod级别保障Pod的反亲和性部署。
另外,在本申请实施例中,调度管理设备为虚拟化的网络功能管理器VNFM,其中,在VNFM中设置虚拟化的网络功能模块描述符(virtualised network functiondescriptor,VNFD)模块,在VNFD模板中,可设置不同VM之间的强反亲和性。
例如,在VNFD模块中,可设置在某一个HOST中创建VM的数量的最大值,当HOST中创建的VM的数量达到该最大值,则不在该HOST中创建新的VM,而是将新的VM创建至其他HOST中,从而保障该HOST的VM与新创建的VM之间的强反亲和性。在本申请实施例中,将部署有第三VM的HOST作为第三HOST,则在VNFD模板中,可设置第三HOST中创建的VM的数量的最大值为1,这种情况下,则在第三HOST中只创建第三VM,而将第四VM创建在其他的HOST中,从而保障第三VM和第四VM之间的强反亲和性。
另外,调度器可依据Pod的亲和性(即PodAffinity)调度策略和Pod的反亲和性(即PodantiAffinity)调度策略,确定两个Pod之间是否具有亲和性和反亲和性。其中,PodAffinity调度策略用于规定某一Pod可以和哪些Pod部署在同一VM中,PodantiAffinity调度策略用于规定某一Pod不可以和哪些Pod部署在同一VM中。
这种情况下,在Pod的配置文件中设置多种类型的部署信息,以便调度器根据该配置文件确定不同Pod之间的亲和性和反亲和性。例如,在某一种类型的部署信息中,要求Pod在首次部署过程中,需要VM满足一定规则,如果不满足,则该Pod不能被部署至该VM中,这一类型的部署信息用于满足Pod的强反亲和性的需求;在另一种类型的部署信息中,要求Pod在首次部署期间,VM尽量满足一定规则,如果不满足,则该Pod也有可能被调度至该VM中,这一类型的部署信息用于满足Pod的弱反亲和性的需求;在另一种类型的部署信息中,要求Pod在首次部署期间,在首次调度期间要求满足一定规则,如果VM不能满足规则,则Pod不能被调度到该VM上,如果VM满足该规则,则Pod被调度至该VM中,并且,在之后的运行过程中,VM不再满足该规则,需要重新调度该Pod,以使Pod部署至满足该规则的VM中。
在本申请实施例中,为了满足第二Pod与第三Pod之间的强反亲和性,可在第二Pod的配置文件设置相应的部署信息,该部署信息表示当VM未部署第三Pod的情况下,确定VM满足部署第二Pod的规则。这种情况下,当调度器通过查询第二Pod的配置文件,获取该部署信息,并且确定第三VM中部署有第三Pod时,则不会在第三VM中部署第二Pod,而是将第二Pod调度至未部署有第三Pod的第四VM中。
进一步的,为了明确上述实施例中,NFV架构中的各个网元的信息交互过程,公开图7,参见图7所示的信息交互示意图,该信息交互过程包括以下步骤:
步骤S71、VNFM向VIM下发创建第三VM和第四VM的指令,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性。
步骤S72、VIM接收到所述创建第三VM和第四VM的指令之后,在第三HOST中创建第三VM。
步骤S73、VIM创建第四VM,由于所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,且第三VM被创建在第三HOST中,则VIM将第四VM创建在第四HOST中。
步骤S74、VIM向VNFM反馈VM创建成功信息。
步骤S75、VNFM向PaaS传输VM纳管请求,以使PaaS对第三VM和第四VM进行纳管。
步骤S76、PaaS接收到VNFM传输的VM纳管请求之后,对第三VM和第四VM进行纳管操作。
其中,在进行纳管操作时,PaaS可在第三VM和第四VM上分别部署相应的进程/组件,从而纳管第三VM和第四VM。
步骤S77、VNFM向PaaS下发创建第三Pod的指令。
步骤S78、Paas接收到创建第三Pod的指令后,向第三VM下发创建第三Pod的指示。
步骤S79、第三VM接收到创建第三Pod的指示之后,根据该指示创建第三Pod,并启动运行第三Pod。
步骤S80、VNFM向PaaS下发创建第二Pod的指令。
步骤S81、PaaS在接收到所述创建第二Pod的指令之后,确定第二Pod与第三VM中的第三Pod具有强反亲和性,则确定需要在第四VM中创建第二Pod,并向第四VM下发创建第二Pod的指示。
步骤S82、第四VM接收到创建第二Pod的指示之后,根据该指示创建第二Pod,并启动运行第二Pod。
进一步的,有些应用场景下,需要控制HOST内允许部署的某类VM的数量。为了满足这一需求,本申请公开另一实施例中,该实施例中,所述调度管理设备为虚拟化的网络功能管理器VNFM,包括以下步骤:
当需要创建第一类型的VM时,所述调度管理设备根据预先设定的所述第一类型的VM在同一HOST的数量限制,生成创建第一类型的VM的指令。
所述创建第一类型的VM的指令中包含所述第一类型的VM的数量限制,所述创建第一类型的VM的指令用于指示在同一HOST中,所创建的第一类型的VM的数量不大于所述数量限制。
该实施例中,VM的类型通过预先为VM设置的标签划分,该标签可以为包括VM所属的HOST的信息的VM标签,即通过为VM所属的HOST将VM划分为不同类型。或者,当存在其他分类需求时,预先为VM设置的标签还可以为包括其他信息的标签,以实现对VM类型的划分。
上述步骤中,VM通过自身的标签进行划分,其中标签相同的VM为同一类型,当对第一类型的VM的数量限制为m(m为正整数)时,所述创建第一类型的VM的指令用于指示在同一个HOST中,创建的第一类型的VM的数量不能超过m个,即在同一个HOST中,创建的第一类型的VM的数量最多为m个。
PaaS在接收到所述创建第一类型的VM的指令之后,根据该指令的指示创建第一类型的VM,以保障在同一个HOST中创建的第一类型的VM的数量最多为m个。
其中,在VNFM中设置有VNFD模板,当所述调度管理设备为VNFM时,在一种可行的实现方式中,可在VNFD模板中预先设定第一类型的VM在同一HOST的数量限制。
通过该步骤,能够控制HOST内允许部署的某一种类型的VM的数量。
进一步的,在本申请实施例中,还可以控制VM内允许部署的同一类型的Pod的数量。这种情况下,预先在VNFM中设置各类型的Pod在同一VM的数量限制。当需要创建某一Pod时,VNFM生成创建Pod的指令,该指令中包括该Pod在同一VM的数量限制。
例如,当需要在某一VM中创建第一类型的Pod,并且第一类型的Pod在该VM中的数量限制为n(n为正整数)时,所述创建第类型的Pod的指令用于在同一个VM中,创建的第一类型的Pod的数量不能超过n个,即在同一个VM中,创建的第一类型的Pod的数量最多为n个。
PaaS在接收到所述创建第一类型的Pod的指令之后,根据该指令的指示创建第一类型的Pod,以保障在同一个VM中创建的第一类型的Pod的数量最多为n个。
其中,在VNFM中设置有VNFD模板,当所述调度管理设备为VNFM时,在一种可行的实现方式中,可在VNFD模板中预先设定第一类型的VM在同一VM的数量限制。
通过该步骤,能够控制VM内允许部署的某一种类型的Pod的数量。
进一步的,上述方案还可以进一步控制同一HOST内允许部署的某一类型的Pod的数量。例如,当通过上述方案控制HOST内允许部署的第一VM的数量最多为m个,并且控制第一VM中允许部署的第一Pod的数量最多为n个,则该HOST内部署的第一Pod的数量不大于(m*n)个,从而控制HOST内允许部署的某一类型的Pod的数量。
与上述网络功能虚拟化NFV架构的调度管理方法相对应的,在本申请另一实施例中,还公开一种网络功能虚拟化NFV架构的调度装置。参见图8所示的结构示意图,本申请实施例公开的网络功能虚拟化NFV架构的调度装置包括:
收发单元110,用于获取各个虚拟机VM所属的主机HOST;
处理单元120,用于为所述VM设置相应的VM标签,所述VM标签包括所述VM所属的HOST的信息,在确定第一VM从第一HOST迁移至第二HOST之后,根据所述第一VM迁移后所属的HOST,更新所述第一VM的VM标签,并且,触发所述NFV架构中的调度器,所述调度器用于当根据所述第一VM更新后的VM标签,确定所述第一VM中的第一最小部署单元Pod不符合部署需求时,将所述第一Pod调度至所述第一HOST的第二VM中。
其中,所述调度器可以设置在NFV架构中的PaaS中,例如,该调度器可以为PaaS中设置的Google开源的容器编排引擎Kubernetes。
所述调度管理设备在更新第一VM的VM标签之后,触发调度器。所述调度器被触发之后,根据所述第一VM更新后的VM标签,确定第一VM中的第一最小部署单元Pod是否符合部署需求。其中,调度器确定第一Pod是否符合部署需求时,是根据第一Pod的亲和性/反亲和性的需求。如果第一Pod的亲和性/反亲和性的需求表明,第一Pod需要设置在第一HOST的VM中,则根据第一VM更新后的VM标签,调度器会确定第一Pod部署在第二HOST中,进一步确定第一Pod不符合部署需求,从而将第一Pod调度至第一HOST的第二VM中。由于第二VM设置在第一HOST中,则第二VM的VM标签为第一HOST,在第一Pod被调度至第二VM中之后,可以满足第一Pod的亲和性/反亲和性的需求,从而使第一Pod部署在第一HOST,满足第一Pod的部署需求。
本申请实施例公开的调度管理装置中,能够根据各个VM所属的HOST,为VM设置相应的VM标签,通过VM的VM标签,实现对VM的划分,这种情况下,位于同一个HOST内的VM为同一类型;然后,在确定第一VM从第一HOST迁移至第二HOST之后,将所述第一VM的VM标签更新为所述第二HOST,再触发NFV架构中的调度器,所述调度器确定第一VM中的第一Pod是否符合部署需求,若不符合,则调度器会将第一Pod调度至第一HOST的第二VM中,从而在第一VM发生迁移之后,仍然使第一Pod部署在第一HOST中,满足第一Pod的部署需求。
在现有技术中,只能将某一种Pod部署在特定类型的VM中,无法满足Pod在HOST的调度需求。而通过本申请实施例公开的方案,能够使某一种Pod部署在特定的HOST中,从而满足Pod在HOST的调度需求,解决现有技术的问题。
进一步的,在本申请实施例中,所述处理单元用于通过所述NFV架构中的虚拟化基础设施管理器VIM反馈的VM创建成功信息,获取各个VM所属的主机HOST。
其中,VIM用于在接收到VM创建指令之后,在HOST中创建VM。在完成VM的创建之后,VIM向调度管理设备反馈VM创建成功信息,VM创建成功信息中包含各个VM所属的HOST的相关信息,该相关信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为HOST的地址信息或身份标识等,从而使调度管理设备确定各个VM所属的HOST,并根据各个VM所属的HOST,为VM设置相应的VM标签,所述VM标签中包括所述VM所属的HOST的信息。
和/或,在本申请实施例中,所述处理单元用于通过所述VIM反馈的VM迁移完成信息,确定所述第一VM从第一HOST迁移至第二HOST。
其中,在NFV架构中的VM完成迁移之后,VIM会向调度管理设备反馈迁移完成信息,该迁移完成信息中包括发生迁移的VM的相关信息以及迁移后所属的HOST的相关信息,VM的相关信息为能够确定VM身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为VM的地址信息或身份标识等,HOST的相关信息为能够确定HOST身份,且在NFV架构中具有唯一性的信息,例如,该相关信息可以为HOST的地址信息或身份标识等。调度管理设备在接收到该迁移完成信息之后,能够确定发生迁移的VM,以及该VM迁移后所属的HOST。
进一步的,在NFV架构中,往往包含多种网元,相应的,所述调度管理设备可为不同类型的网元。在其中一种可行的实施方式中,所述调度管理设备为虚拟化的网络功能管理器VNFM,或者,在另一种可行的实施方式中,所述调度管理设备为内置有所述调度器的平台即服务模块PaaS。
其中,当所述调度管理设备为VNFM时,所述处理单元用于将所述第一VM的VM标签变更信息传输至所述NFV架构中的PaaS,通过所述第一VM的VM标签变更信息触发所述PaaS内置的所述调度器;
当所述调度管理设备为PaaS时,所述处理单元用于确定所述第一VM的VM标签发生变化之后,触发内置的所述调度器。
进一步的,当所述调度管理设备为VNFM时,在所述处理单元为所述VM设置相应的VM标签之后,所述收发单元还用于将所述VM与VM标签的对应关系传输至所述PaaS。
这种情况下,PaaS能够获取VM与VM标签的对应关系,从而能够根据该对比关系确定各个VM的VM标签,并在接收到VNFM传输的第一VM的VM标签变更信息之后,根据所述第一VM的VM标签变更信息,判断第一VM的VM标签是否发生变更。
进一步的,在为所述VM设置相应的VM标签之前,所述处理单元还用于通过所述收发单元,向VIM下发创建第一VM和第二VM的指令,所述VIM用于在接收到所述指令之后,创建第一VM和第二VM,并在创建成功后,向所述调度管理设备反馈第一VM和第二VM的创建成功消息;
当需要创建VM时,NFV架构中的调度管理设备等会向NFV架构中的VIM下发创建VM的指令,以使VIM根据该指令创建相应的VM,并且,在VM创建成功之后,VIM会向调度管理设备反馈相应的VM创建成功消息。
在为所述VM设置相应的VM标签之后,所述处理单元还用于通过所述收发单元,下发创建第一Pod的指令,所述创建第一Pod的指令中包括所述第一Pod对应的HOST的信息。
在接收到创建第一Pod的指令之后,VM会确定自身的VM标签中所包括的HOST的信息,是否与创建第一Pod的指令中包括的HOST的信息是否相同,如果相同,则该VM会创建部署与自身的第一Pod。
进一步的,在所述处理单元为所述VM设置相应的VM标签之后,所述处理单元还用于通过所述收发单元,向VIM下发创建第三VM和第四VM的指令,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,所述VIM用于根据所述创建第三VM和第四VM的指令,在不同的HOST中分别创建第三VM和第四VM;
所述处理单元还用于通过所述收发单元,向所述调度器下发创建第二Pod的指令,所述调度器用于在接收到所述创建第二Pod的指令之后,当确定第二Pod与所述第三VM中的第三Pod具有强反亲和性时,在所述第四VM中创建所述第二Pod。
其中,反亲和性包括强反亲和性和弱反亲和性。具有强反亲和性的两个网元在部署时,不能部署在同一个父节点中。而具有弱反亲和性的两个网元在部署时,尽量部署在不同的父节点中,如果在当前的NFV架构下,将具有弱反亲和性的两个网元部署在不同的父节点较为困难,可将这两个网元部署在同一父节点中。
由于在本申请实施例中,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,则VIM在接收到所述创建第三VM和第四VM的指令,会将第三VM和第四VM分别创建在不同的HOST中,以保障第三VM和第四VM的强反亲和性部署。
由于在本申请实施例中,第二Pod与第三Pod具有强反亲和性,则需要将第二Pod与第三Pod部署在不同的VM中,这种情况下,当第三VM中部署有第三Pod时,则将第二Pod部署至第四VM中,从而保障第二Pod与第三Pod之间的强反亲和性。
进一步的,在为所述VM设置相应的VM标签之后,当需要创建第一类型的VM时,所述处理单元还用于,根据预先设定的所述第一类型的VM在同一HOST的数量限制,生成创建第一类型的VM的指令;
所述创建第一类型的VM的指令中包含所述第一类型的VM的数量限制,所述创建第一类型的VM的指令用于指示在同一HOST中,所创建的第一类型的VM的数量不大于所述数量限制。
该实施例中,VM的类型通过预先为VM设置的标签划分,该标签可以为包括VM所属的HOST的信息的VM标签,即通过为VM所属的HOST将VM划分为不同类型。或者,当存在其他分类需求时,预先为VM设置的标签还可以为包括其他信息的标签,以实现对VM类型的划分。
通过本实施例,能够控制HOST内允许部署的某一种类型的VM的数量。
进一步的,上述方案还可以进一步控制同一HOST内允许部署的某一类型的Pod的数量。例如,当通过上述方案控制HOST内允许部署的第一VM的数量最多为m个,并且控制第一VM中允许部署的第一Pod的数量最多为n个,则该HOST内部署的第一Pod的数量不大于(m*n)个,从而控制HOST内允许部署的某一类型的Pod的数量。
与上述网络功能虚拟化NFV架构的调度管理方法相对应的,在本申请另一实施例中,还公开一种网络功能虚拟化NFV架构的调度管理设备。参见图9所示的结构示意图,所述网络功能虚拟化NFV架构的调度管理设备包括:
处理器1101和存储器,
其中,所述存储器,用于存储程序指令;
所述处理器,用于调用并执行所述存储器中存储的程序指令,以使所述调度管理设备执行图2至图6对应的实施例中的全部或部分步骤。
进一步的,该设备还可以包括:该网络设备包括:收发器1102和总线1103,所述存储器包括随机存取存储器1104和只读存储器1105。
其中,处理器通过总线分别耦接收发器、随机存取存储器以及只读存储器。其中,当需要运行该网络设备时,通过固化在只读存储器中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动,引导该设备进入正常运行状态。在该设备进入正常运行状态后,在随机存取存储器中运行应用程序和操作系统,从而使所述调度管理设备执行图2至图6对应的实施例中的全部或部分步骤。
本发明实施例的网络设备可对应于上述图2至图6所对应的实施例中的NFV架构的调度管理设备,并且,该调度管理设备中的处理器等可以实现图2至图6所对应的实施例中的调度管理设备所具有的功能和/或所实施的各种步骤和方法,为了简洁,在此不再赘述。
需要说明的是,本实施例也可以基于通用的物理服务器结合网络功能虚拟化(英文:Network Function Virtualization,NFV)技术实现的网络设备,所述网络设备为虚拟网络设备(如,虚拟主机、虚拟路由器或虚拟交换机)。所述虚拟网络设备可以是运行有用于发送通告报文功能的程序的虚拟机(英文:Virtual Machine,VM),所述虚拟机部署在硬件设备上(例如,物理服务器)。虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。本领域技术人员通过阅读本申请即可在通用物理服务器上虚拟出具有上述功能的多个网络设备。此处不再赘述。
具体实现中,本申请实施例还提供一种计算机可读介质,该计算机可读介质包括指令。其中,设置在任意设备中计算机可读介质其在计算机上运行时,可实施包括图2至图6对应的实施例中的全部或部分步骤。所述计算机可读介质的存储介质可为磁碟、光盘、只读存储记忆体(英文:read-only memory,简称:ROM)或随机存储记忆体(英文:random accessmemory,简称:RAM)等。
本领域技术任何还可以了解到本申请实施例列出的各种说明性逻辑块(illustrative logical block)和步骤(step)可以通过电子硬件、电脑软件,或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用,可以使用各种方法实现所述的功能,但这种实现不应被理解为超出本申请实施例保护的范围。
本申请实施例中所描述的各种说明性的逻辑单元和电路可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列(FPGA)或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地,存储媒介可以与处理器连接,以使得处理器可以从存储媒介中读取信息,并可以向存储媒介存写信息。可选地,存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中,ASIC可以设置于UE中。可选地,处理器和存储媒介也可以设置于UE中的不同的部件中。
应理解,在本申请的各种实施例中,各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
本说明书的各个部分均采用递进的方式进行描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点介绍的都是与其他实施例不同之处。尤其,对于装置和系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例部分的说明即可。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其,对于……实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例中的说明即可。
以上所述的本发明实施方式并不构成对本发明保护范围的限定。

Claims (18)

1.一种网络功能虚拟化NFV架构的调度管理方法,其特征在于,包括:
NFV架构中的调度管理设备获取各个虚拟机VM所属的主机HOST,并为所述VM设置相应的VM标签,所述VM标签包括所述VM所属的HOST的信息;
所述调度管理设备在确定第一VM从第一HOST迁移至第二HOST之后,根据所述第一VM迁移后所属的HOST,更新所述第一VM的VM标签;
所述调度管理设备触发所述NFV架构中的调度器,所述调度器用于当根据所述第一VM更新后的VM标签,确定所述第一VM中的第一最小部署单元Pod不符合部署需求时,将所述第一Pod调度至所述第一HOST的第二VM中。
2.根据权利要求1所述的方法,其特征在于,
所述调度管理设备通过所述NFV架构中的虚拟化基础设施管理器VIM反馈的VM创建成功信息,获取各个VM所属的主机HOST;
和/或,
所述调度管理设备通过所述VIM反馈的VM迁移完成信息,确定所述第一VM从第一HOST迁移至第二HOST。
3.根据权利要求1或2所述的方法,其特征在于,
所述调度管理设备为虚拟化的网络功能管理器VNFM;
或者,所述调度管理设备为内置有所述调度器的平台即服务模块PaaS。
4.根据权利要求3所述的方法,其特征在于,
当所述调度管理设备为VNFM时,所述调度管理设备触发所述NFV架构中的调度器,包括:
所述VNFM将所述第一VM的VM标签变更信息传输至所述NFV架构中的PaaS,通过所述第一VM的VM标签变更信息触发所述PaaS内置的所述调度器;
当所述调度管理设备为PaaS时,所述调度管理设备触发所述NFV架构中的调度器,包括:
所述PaaS确定所述第一VM的VM标签发生变化之后,触发内置的所述调度器。
5.根据权利要求3所述的方法,其特征在于,当所述调度管理设备为VNFM时,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述VNFM将所述VM与VM标签的对应关系传输至所述PaaS。
6.根据权利要求1或2所述的方法,其特征在于,
在所述调度管理设备为所述VM设置相应的VM标签之前,还包括:
所述调度管理设备向VIM下发创建第一VM和第二VM的指令,所述VIM用于在接收到所述指令之后,创建第一VM和第二VM,并在创建成功后,向所述调度管理设备反馈第一VM和第二VM的创建成功消息;
在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述调度管理设备下发创建第一Pod的指令,所述创建第一Pod的指令中包括所述第一Pod对应的HOST的信息。
7.根据权利要求1或2所述的方法,其特征在于,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
所述调度管理设备向VIM下发创建第三VM和第四VM的指令,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,所述VIM用于根据所述创建第三VM和第四VM的指令,在不同的HOST中分别创建第三VM和第四VM;
所述调度管理设备向所述调度器下发创建第二Pod的指令,所述调度器用于在接收到所述创建第二Pod的指令之后,当确定第二Pod与所述第三VM中的第三Pod具有强反亲和性时,在所述第四VM中创建所述第二Pod。
8.根据权利要求1或2所述的方法,其特征在于,在所述调度管理设备为所述VM设置相应的VM标签之后,还包括:
当需要创建第一类型的VM时,所述调度管理设备根据预先设定的所述第一类型的VM在同一HOST的数量限制,生成创建第一类型的VM的指令;
所述创建第一类型的VM的指令中包含所述第一类型的VM的数量限制,所述创建第一类型的VM的指令用于指示在同一HOST中,所创建的第一类型的VM的数量不大于所述数量限制。
9.一种网络功能虚拟化NFV架构的调度装置,其特征在于,应用于调度管理设备中,包括:
收发单元,用于获取各个虚拟机VM所属的主机HOST;
处理单元,用于为所述VM设置相应的VM标签,所述VM标签包括所述VM所属的HOST的信息,在确定第一VM从第一HOST迁移至第二HOST之后,根据所述第一VM迁移后所属的HOST,更新所述第一VM的VM标签,并且,触发所述NFV架构中的调度器,所述调度器用于当根据所述第一VM更新后的VM标签,确定所述第一VM中的第一最小部署单元Pod不符合部署需求时,将所述第一Pod调度至所述第一HOST的第二VM中。
10.根据权利要求9所述的装置,其特征在于,
所述处理单元用于通过所述NFV架构中的虚拟化基础设施管理器VIM反馈的VM创建成功信息,获取各个VM所属的主机HOST;
和/或,
所述处理单元用于通过所述VIM反馈的VM迁移完成信息,确定所述第一VM从第一HOST迁移至第二HOST。
11.根据权利要求9或10所述的装置,其特征在于,
所述调度管理设备为虚拟化的网络功能管理器VNFM;
或者,所述调度管理设备为内置有所述调度器的平台即服务模块PaaS。
12.根据权利要求11所述的装置,其特征在于,
当所述调度管理设备为VNFM时,所述处理单元用于将所述第一VM的VM标签变更信息传输至所述NFV架构中的PaaS,通过所述第一VM的VM标签变更信息触发所述PaaS内置的所述调度器;
当所述调度管理设备为PaaS时,所述处理单元用于确定所述第一VM的VM标签发生变化之后,触发内置的所述调度器。
13.根据权利要求10所述的装置,其特征在于,当所述调度管理设备为VNFM时,在所述处理单元为所述VM设置相应的VM标签之后,所述收发单元还用于将所述VM与VM标签的对应关系传输至PaaS。
14.根据权利要求10所述的装置,其特征在于,
在为所述VM设置相应的VM标签之前,所述处理单元还用于通过所述收发单元,向VIM下发创建第一VM和第二VM的指令,所述VIM用于在接收到所述指令之后,创建第一VM和第二VM,并在创建成功后,向所述调度管理设备反馈第一VM和第二VM的创建成功消息;
在为所述VM设置相应的VM标签之后,所述处理单元还用于通过所述收发单元,下发创建第一Pod的指令,所述创建第一Pod的指令中包括所述第一Pod对应的HOST的信息。
15.根据权利要求10所述的装置,其特征在于,
在所述处理单元为所述VM设置相应的VM标签之后,所述处理单元还用于通过所述收发单元,向VIM下发创建第三VM和第四VM的指令,所述创建第三VM和第四VM的指令中指示所述第三VM和第四VM之间具有强反亲和性,所述VIM用于根据所述创建第三VM和第四VM的指令,在不同的HOST中分别创建第三VM和第四VM;
所述处理单元还用于通过所述收发单元,向所述调度器下发创建第二Pod的指令,所述调度器用于在接收到所述创建第二Pod的指令之后,当确定第二Pod与所述第三VM中的第三Pod具有强反亲和性时,在所述第四VM中创建所述第二Pod。
16.根据权利要求10所述的装置,其特征在于,
在为所述VM设置相应的VM标签之后,当需要创建第一类型的VM时,所述处理单元还用于,根据预先设定的所述第一类型的VM在同一HOST的数量限制,生成创建第一类型的VM的指令;
所述创建第一类型的VM的指令中包含所述第一类型的VM的数量限制,所述创建第一类型的VM的指令用于指示在同一HOST中,所创建的第一类型的VM的数量不大于所述数量限制。
17.一种网络功能虚拟化NFV架构的调度管理设备,其特征在于,包括:
处理器和存储器;
其中,所述存储器,用于存储程序指令;
所述处理器,用于调用并执行所述存储器中存储的程序指令,以使所述调度管理设备执行权利要求1至权利要求8任一项所述的方法。
18.一种计算机可读介质,包括指令,当其在计算机上运行时,使得计算机执行如权利要求1至权利要求8中任意一项所述的方法。
CN201910104725.8A 2019-02-01 2019-02-01 一种网络功能虚拟化nfv架构的调度管理方法及装置 Active CN111526168B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201910104725.8A CN111526168B (zh) 2019-02-01 2019-02-01 一种网络功能虚拟化nfv架构的调度管理方法及装置
PCT/CN2019/129247 WO2020155987A1 (zh) 2019-02-01 2019-12-27 一种网络功能虚拟化nfv架构的调度管理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910104725.8A CN111526168B (zh) 2019-02-01 2019-02-01 一种网络功能虚拟化nfv架构的调度管理方法及装置

Publications (2)

Publication Number Publication Date
CN111526168A CN111526168A (zh) 2020-08-11
CN111526168B true CN111526168B (zh) 2021-09-07

Family

ID=71841593

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910104725.8A Active CN111526168B (zh) 2019-02-01 2019-02-01 一种网络功能虚拟化nfv架构的调度管理方法及装置

Country Status (2)

Country Link
CN (1) CN111526168B (zh)
WO (1) WO2020155987A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112799775B (zh) * 2020-12-29 2024-05-14 杭州涂鸦信息技术有限公司 一种节点属性传递方法以及相关装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103617070A (zh) * 2013-11-27 2014-03-05 华为技术有限公司 虚拟机迁移方法及装置
CN109032806A (zh) * 2018-07-30 2018-12-18 华为技术有限公司 容器的服务调度方法和装置
US10191778B1 (en) * 2015-11-16 2019-01-29 Turbonomic, Inc. Systems, apparatus and methods for management of software containers

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10282222B2 (en) * 2014-10-13 2019-05-07 Vmware, Inc. Cloud virtual machine defragmentation for hybrid cloud infrastructure
CN105376303B (zh) * 2015-10-23 2018-11-06 深圳前海达闼云端智能科技有限公司 一种Docker实现系统及其通信方法
CN105354076B (zh) * 2015-10-23 2019-01-25 北京云端光科技术有限公司 一种应用部署方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103617070A (zh) * 2013-11-27 2014-03-05 华为技术有限公司 虚拟机迁移方法及装置
US10191778B1 (en) * 2015-11-16 2019-01-29 Turbonomic, Inc. Systems, apparatus and methods for management of software containers
CN109032806A (zh) * 2018-07-30 2018-12-18 华为技术有限公司 容器的服务调度方法和装置

Also Published As

Publication number Publication date
WO2020155987A1 (zh) 2020-08-06
CN111526168A (zh) 2020-08-11

Similar Documents

Publication Publication Date Title
JP6819296B2 (ja) 仮想化管理・オーケストレーション装置、仮想化管理・オーケストレーション方法、および、プログラム
EP3200393B1 (en) Method and device for virtual network function management
US20190052528A1 (en) Network function virtualization management orchestration apparatus, method
WO2018032770A1 (zh) 一种应用组件部署方法及部署节点
US10742502B2 (en) Software modification initiation method, and metadata release method and apparatus
JP6658882B2 (ja) 制御装置、vnf配置先選択方法及びプログラム
US20170085419A1 (en) System and method for deploying an application
CN106790092B (zh) 远程过程调用服务端控制系统及方法
CN110661647A (zh) 一种生命周期管理方法及装置
US11909603B2 (en) Priority based resource management in a network functions virtualization (NFV) environment
CN111324571A (zh) 一种容器集群管理方法、装置及系统
CN109688191B (zh) 流量调度方法及通信装置
WO2023045467A1 (zh) 容器cpu资源调度与隔离方法和装置、存储介质及电子设备
EP3442201B1 (en) Cloud platform construction method and cloud platform
CN107534577B (zh) 一种网络业务实例化的方法及设备
US11074103B2 (en) Scheduling method and scheduling device
CN111399968B (zh) 一种基于容器的虚拟资源管理方法、装置及系统
CN111274033A (zh) 一种资源部署方法、装置、服务器以及存储介质
CN111526168B (zh) 一种网络功能虚拟化nfv架构的调度管理方法及装置
CN113986539A (zh) 实现pod固定IP的方法、装置、电子设备和可读存储介质
CN112015515B (zh) 一种虚拟网络功能的实例化方法及装置
CN111221620B (zh) 存储方法、装置及存储介质
CN107819598A (zh) 一种管理网络功能节点的方法及装置
CN110351104A (zh) 一种vim选择方法及装置
CN114675940A (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