WO2020108443A1 - 一种虚拟化管理方法及装置 - Google Patents

一种虚拟化管理方法及装置 Download PDF

Info

Publication number
WO2020108443A1
WO2020108443A1 PCT/CN2019/120707 CN2019120707W WO2020108443A1 WO 2020108443 A1 WO2020108443 A1 WO 2020108443A1 CN 2019120707 W CN2019120707 W CN 2019120707W WO 2020108443 A1 WO2020108443 A1 WO 2020108443A1
Authority
WO
WIPO (PCT)
Prior art keywords
vnf
template
information
vim
vnfm
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.)
Ceased
Application number
PCT/CN2019/120707
Other languages
English (en)
French (fr)
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 EP19890401.3A priority Critical patent/EP3883183A4/en
Publication of WO2020108443A1 publication Critical patent/WO2020108443A1/zh
Priority to US17/333,417 priority patent/US12035231B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H04L41/0843—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on generic templates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/342—Signalling channels for network management communication between virtual entities, e.g. orchestrators, SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5096—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to distributed or central networked applications

Definitions

  • the present application relates to the field of virtualized networks, and in particular to a method and device for virtualized management supporting multiple platforms.
  • Network function virtualization is a technology that uses common hardware devices and virtualization technologies to carry the functions of dedicated devices in traditional networks. This technology can reduce the expensive cost of deploying special equipment. Through the decoupling between hardware and software, the function of network devices no longer depends on dedicated hardware. Using the characteristics of cloud computing, resources can be flexibly shared to achieve rapid development and deployment of new services. At the same time, it can also be automatically deployed, elastically scaled, fault isolated, and self-healing based on actual business needs.
  • the party that initiates the virtualization request is generally called the service requester; and the party that can receive the virtualization request and perform virtualization processing on the corresponding service according to the request is generally called the provider of the virtualization service.
  • the service requester first needs to submit the description information of the service to the service provider, such as a virtual network function descriptor (virtual network function descriptor, VNFD). It contains the virtual resource information required to deploy the virtual network function (VNF), including information such as computing, storage, and network.
  • VNF virtual network function descriptor
  • TOSCA cloud application topology and orchestration specifications
  • OASIS Organization for Structured Information Standards
  • the business deployment package contains at least one business deployment description file, and the file will also contain definitions of some elements that will be used.
  • the ServiceTemplate file is included, and the ServiceTemplate will contain definitions such as NodeType, RelationshipType, and Policies.
  • VIM virtualised infrastructure managers
  • OpenStack open-source cloud computing management platform
  • Azure Amazon's Amazon web service AWS
  • Azure Microsoft's cloud computing platform Azure
  • VIM platforms all provide native deployment templates, and the deployment templates provided by different VIMs have different syntax and resource definitions.
  • the HOT template language provided by Openstack the EC2 template language provided by AWS
  • the ARM template language provided by Azure the deployment template based on the YAML language provided by the container management platform kubernates.
  • the NFV-defined TOSCA-based VNFD deployment template is only well supported on the Openstack-based VIM platform, mainly because the TOSCA template language and OpenStack's HOT template language both use YAML, and the syntax is similar and the resource definition is also very good. similar. OpenStack also provides an open source TOSCA-heat translator project that can easily convert TOSCA template language into HOT template language.
  • VIM adopts other platforms, such as Azure, AWS, or needs to deploy VNF in a container using the kubernates platform
  • the TOSCA defined by NFV can not meet the requirements of the VNFD template, and VNF cannot be deployed on these VIM platforms. .
  • the embodiments of the present application provide a virtualization management method and device, which can effectively solve the cross-platform deployment of applications.
  • the cross-platform business deployment is placed in the same deployment template, and the unified template can be used for business Make the right deployment to support multiple resource platforms.
  • a virtualization management method includes: a virtual network function manager VNFM receives a first instantiation request message of a virtualized network function VNF sent by a service coordinator SO or a network function virtualization orchestrator NFVO,
  • the first instantiation request message includes the VNF logo and the virtual infrastructure manager VIM information.
  • the VIM information includes the VIM type and the supported template language; the VNFM obtains the VNF data package according to the VNF logo; when it is determined that the template language supported by the VIM information is the first template For language, VNFM obtains the first VNF sub-information consistent with the VIM type and the first template language from the template information.
  • the first VNF sub-information is used to deploy VNF; the template information is included in the VNFD descriptor file VNFD ; VNFM sends the first VNF sub-information to the multi-cloud platform for the multi-cloud platform to deploy VNF on the VIM corresponding to the VIM type.
  • the method further includes: when it is determined that the template language supported by the VIM information is the second template language, the VNFM parses the VNFD of the VNF data packet, and generates a resource request according to the parsed result, and the resource request includes the second VNF sub Information, the second VNF sub-information is used to deploy VNF; VNFM sends a resource request to the multi-cloud platform for the multi-cloud platform to deploy VNF on the VIM corresponding to the VIM type.
  • the VNF data package includes a metadata file in the second template language, and the metadata file includes the indication parameter;
  • VNFM parsing the VNFD of the VNF data package includes: the first service template indicated by the VNFM parsing indication parameter, the first A service template is included in the VNFD of the VNF data packet.
  • the first service template includes a first identifier
  • the first service template indicated by the VNFM parsing indication parameter includes: the VNFM parsing the first service template and the second service template indicated by the first identifier.
  • the VNFD includes at least one node template, and each node template includes template information.
  • a virtualization management method includes: receiving a second instantiation request message of a virtualized network function VNF, the second instantiation request including a VNF identifier; determining a virtual infrastructure manager VIM type; The first instantiation request message of the VNF is sent.
  • the first instantiation request message includes the VNF identifier and VIM information.
  • the VIM information includes the VIM type and the supported template language. The first instantiation request message is used by the VNFM to perform VNF deployment.
  • a virtual network function manager including: a receiving module for receiving a first instantiation request message of a virtualized network function VNF sent by a service coordinator SO or a network function virtualization orchestrator NFVO, and An instantiation request message includes the VNF identification and VIM information of the virtual infrastructure manager.
  • the VIM information includes the VIM type and the supported template language; the acquisition module is used to acquire the VNF data package according to the VNF identification; the determination module is used to determine the VIM information When the supported template language is the first template language, VNFM obtains the first VNF sub-information consistent with the VIM type and the first template language from the template information, and the first VNF sub-information is used to deploy VNF; where the template information is included in the VNF In the descriptor file VNFD of the data packet; the sending module is used to send the first VNF sub-information to the multi-cloud platform, which is used by the multi-cloud platform to deploy the VNF on the VIM corresponding to the VIM type.
  • the determining module is further configured to: when determining that the template language supported by the VIM information is the second template language, parse the VNFD of the VNF data packet, and generate a resource request according to the parsed result, the resource request includes the second VNF Sub-information, the second VNF sub-information is used to deploy VNF; the sending module is also used to send a resource request to the multi-cloud platform, which is used by the multi-cloud platform to deploy VNF on the VIM corresponding to the VIM type.
  • the VNF data package includes a metadata file in the second template language, and the metadata file includes the indication parameter; the determining module parses the VNFD of the VNF data package, including: determining the module parses the first service template indicated by the indication parameter , The first service template is included in the VNFD of the VNF data packet.
  • the first service template includes a first identifier; and the determination module parses the first service template indicated by the indication parameter, including: the determination module parses the first service template and the second service template indicated by the first identifier.
  • the VNFD includes at least one node template, and each node template includes template information.
  • a virtualization management device being a service coordinator SO or a network function virtualization orchestrator NFVO, including: a receiving module for receiving a second instantiation request message of a virtualized network function VNF ,
  • the second instantiation request includes the VNF identifier;
  • the determination module is used to determine the virtual infrastructure manager VIM type;
  • the sending module is used to send the first instance request message of the VNF to the virtual network function manager VNFM, the first instantiation
  • the request message includes the VNF identification and VIM information.
  • the VIM information includes the VIM type and the supported template language.
  • the first instantiation request message is used by the VNFM to perform VNF deployment.
  • a system includes the virtual network function manager of the third aspect and the service coordinator of the fourth aspect.
  • a computer-readable storage medium storing a program, characterized in that the program includes instructions, which when executed by the terminal, cause the terminal to perform the method of the first aspect and the second aspect.
  • a computer program product containing instructions, which when executed on a computer, causes the computer to perform the method of the first aspect and the second aspect.
  • the present application discloses a virtualization management method and device by adding template information for different VIM platforms to VNFD, where the template information includes multiple different VNF sub-information for deploying VNF on different VIM platforms. Therefore, for cross-platform business deployment, its deployment information can be placed in a VNFD to support multiple resource platforms, thereby effectively solving cross-platform deployment of applications.
  • FIG. 1 is a schematic diagram of an NFV system architecture provided by an embodiment of this application.
  • FIG. 2 is a flowchart of a virtualization management method provided by an embodiment of this application.
  • FIG. 3 is a flowchart of another virtualization management method provided by an embodiment of this application.
  • FIG. 4 is a flowchart of yet another virtualization management method provided by an embodiment of this application.
  • FIG. 5 is a schematic diagram of a virtualization management device provided by an embodiment of this application.
  • FIG. 6 is a schematic diagram of another virtualization management device provided by an embodiment of the present application.
  • FIG. 1 is a schematic diagram of an NFV system architecture provided by an embodiment of this application.
  • the NFV system architecture 100 includes operations support system and business support system (operations support system and business support system (OSS/BSS) 110, network function virtualization orchestrator (NFVO) 120, virtual network function management Virtual (network) function manager (VNFM) 130, virtual infrastructure manager VIM 140, equipment management system (EMP) 150, virtualized network function VNF 160 and network function virtualized infrastructure (network function functions virtualization infrastructure, NFVI) ) 170.
  • operations support system and business support system (operations support system and business support system (OSS/BSS) 110, network function virtualization orchestrator (NFVO) 120, virtual network function management Virtual (network) function manager (VNFM) 130, virtual infrastructure manager VIM 140, equipment management system (EMP) 150, virtualized network function VNF 160 and network function virtualized infrastructure (network function functions virtualization infrastructure, NFVI) ) 170.
  • OSS/BSS operations support system and business support system
  • NFVO network function virtualization orchestrator
  • VNFM virtual network function management Virtual (network)
  • OSS/BSS110 supports various end-to-end telecommunications services.
  • the management functions supported by the OSS include: network configuration, service provision, and fault management.
  • the business support system BSS processes orders, payment, revenue, etc., and supports product management, order management, revenue management, and customer management.
  • NFVO120 is mainly responsible for handling the life cycle management of virtualization services, as well as the allocation and scheduling of virtual infrastructure and virtual resources in NFVI.
  • NFVO 120 can communicate with one or more VNFMs 130 to perform resource related requests.
  • NFVO120 sends configuration information to VNFM130 to collect VNF160 status information.
  • NFVO120 can also communicate with VIM 106 for resource allocation, and/or reservation, and exchange of virtualized hardware resource configuration and status information.
  • VNFM 130 is responsible for the lifecycle management of one or more VNFs 160, such as instantiating, updating, querying, scaling, and terminating VNF160.
  • VNFM130 can communicate with VNF160 to complete VNF lifecycle management and exchange configuration and status information.
  • VIM 140 is used to control and manage the interaction of VNF160 with computing hardware, storage hardware, network hardware, virtual computing (virtual computing), virtual storage, and virtual networks.
  • VIM 140 performs resource management functions, including management of infrastructure resources, allocation and operation functions. Among them, allocating, for example, adding resources to virtual containers, etc., and running functions, such as collecting NFVI failure information.
  • VNFM 130 and VIM140 can communicate with each other to request resource allocation, exchange virtualized hardware resource configuration and status information, etc.
  • EM150 is a system used to configure and manage equipment in traditional telecommunications systems. In the architecture of NFV100, EM150 can also be used to configure and manage VNF160, and initiate lifecycle management operations such as instantiation of new VNF to VNFM130. Among them, the EM 150 may include multiple EMs, such as: equipment management system 1, equipment management system 2, and so on.
  • VNF 160 is a virtual network function, and there can be multiple different types of VNF, such as virtual network function 1, virtual network function 2, and so on.
  • NFVI 170 is the infrastructure layer of NFV, which includes hardware components, software components, or a combination of the two to establish a virtualized environment where VNF160 can be deployed, managed, and implemented.
  • the hardware resources and virtualization layer are used to provide VNF160 with virtualization resources, such as virtual machines and other forms of virtual containers.
  • Hardware resources include computing hardware, storage hardware, and network hardware. As an embodiment, resources of computing hardware and storage hardware may be concentrated together.
  • the virtualization layer in NFVI 170 can abstract hardware resources and decouple VNF160 from the underlying physical network layer.
  • cloudify deployment platform cloudify provides several different plug-ins (plugins), so that it can be connected to different VIM platforms to implement deployment applications on different VIM platforms.
  • the plugins currently provided by cloudify include Aria plugin, Azure plugin, Openstack plugin, Vsphere plugin, AWS plugin, etc. If cloudify is deployed on VNFM or NFVO, it can theoretically provide NFV with support for multiple VIMs, including platforms such as Openstack, Aria, Azure, Vsphere, and AWS.
  • VNFD files for different platforms.
  • openstack-blueprint.yaml is a VNFD file for openstack platform
  • azure-blueprint.yaml is a VNFD file for Azure platform
  • aws-blueprint.yaml is a VNFD file for AWS platform.
  • the usual practice is to use the deployment template language supported by the designated VIM platform for application template design.
  • the OpenStack platform uses HOT templates for design
  • AWS uses EC2 templates for design
  • Azure uses ARM templates for design. Then send the pre-designed deployment template to the corresponding VIM platform, and carry the required deployment parameters in the request to complete the application deployment.
  • cloudify When using cloudify, if users want to deploy applications on the specified VIM platform, they need to use the TOSCA model defined by cloudify to design applications, and for different VIM platforms, cloudify provides different TOSCA templates.
  • VIM uses the OpenStack platform
  • the TOSCA model provided by cloudify is:
  • cloudify After the application template designed with this model is sent to the cloudify platform, cloudify will parse the template according to the corresponding definition and convert the parsed result into a resource application request of the Openstack platform.
  • cloudify.aws.nodes.Interface (representing virtual port resources) and so on, for specific definitions, please refer to https://github.com/cloudify-cosmo/cloudify-aws-plugin/releases/download/1.5.1.2/plugin.yaml.
  • the TOSCA model definition for different VIM platforms is very different, mainly because the definition of resources by different VIMs is different.
  • the cloudify platform does not effectively reduce the user's design workload, but instead needs to learn the TOSCA model of the specified VIM defined by cloudify, which cannot be used for the VIM native model.
  • TOSCA As a more widely used business deployment template, TOSCA also has a large proportion in the industry.
  • the European Telecommunication Standardization Association also uses the TOSCA template language for the VNFD model defined by the NFV specification.
  • cloudify provides a plugin-based way to support the deployment of applications on a variety of different VIM platforms, it needs to design different TOSCA models for different VIM platforms. The entire process makes the user's learning cost too high, and needs to master multiple TOSCA models to use. And the above TOSCA model can only rely on the cloudify platform for analysis. Because this model is strongly related to VIM, and differs greatly from the model defined by ETSI NFV, the current VNFM or NFVO transformation work will be very large.
  • the cloudify platform needs to convert the TOSCA model into the resource call API of the corresponding VIM platform or the native deployment template on the corresponding VIM platform during deployment. Implement deployment applications.
  • the embodiments of the present application provide a virtualization management method.
  • a unified template VNFD can be used to complete deployment for different VIM platforms. And there is no need to design different TOSCA models for different VIM platforms, thereby reducing the learning cost of users.
  • FIG. 2 is a flowchart of a virtualization management method provided by an embodiment of the present application.
  • a virtualization management method including the following steps:
  • Step 210 The service coordinator SO or the virtual network function manager NFVO sends the first instantiation request message of the virtualized network function VNF to the VNFM.
  • the first instantiation request message includes the VNF identifier and the virtual infrastructure manager VIM information, VIM
  • the information includes the VIM type and the supported template language.
  • the first instantiation request sent by the service coordinator (service orchestrator, SO) or the virtual network function manager NFVO to the VNFM includes the VNF identifier and VIM information to be deployed.
  • the VNF identifier may be a VNF package ID.
  • the VIM information includes the type of VIM to be deployed and the deployment template language supported by the VIM type.
  • Step 220 The VNFM obtains the VNF data packet according to the VNF identifier.
  • the VNFM receives the first instantiation request message sent by the SO or NFVO, and obtains the VNF data package package according to the VNF package ID. VNFM obtains VNFpackage from the database according to the VNF package ID in the request.
  • the above database may be a service design module (SDC) in an open management platform (ONAP) for automatic management and orchestration.
  • SDC service design module
  • ONAP open management platform
  • the file includes parameters such as Entry-Definitions. Among them, the Entry-Definitions parameter indicates the address and file name of the first VNFD TOSCA service template file to be analyzed.
  • VNFD may be composed of multiple TOSCA service templates. A more specific example is given below.
  • VNFD TOSCA service template can be:
  • the SunshineDB under node_templates in the service template describes some basic information of this VNF.
  • the description address descriptor_id of the VNF the application provider provider, the application name product_name, and other information.
  • Step 230 When it is determined that the template language supported by the VIM information is the first template language, the VNFM obtains first VNF sub-information consistent with the VIM type and the first template language from the template information, and the first VNF sub-information is used to deploy the VNF.
  • the template information is included in the descriptor file VNFD of the VNF data packet.
  • the first language may be any template language other than TOSCA, such as ARM, EC2, and so on.
  • VNFM obtains the first VNF consistent with the VIM type and the first template language from the template information in the VNFD TOSCA service template mentioned above Sub-information.
  • the template language may be the artifacts in the above VNFD TOSCA service template example. In artifacts, you can design the VIM template information of other template languages that you need to use in advance according to your needs. In one example, artifacts contain multiple different VNF sub-information.
  • naming in other formats is also allowed.
  • the type() of vim_specific_template_1 is tosca.artifacts.nfv.Azure, which indicates that the artifacts are templates for the Azure type, and the file is the storage location of the artifacts in the VNF package.
  • the suffix .arm indicates that the template language of the artifacts is arm.
  • vim_specific_template_2 is tosca.artifacts.nfv.AWS, which indicates that the artifacts are templates for AWS types, and file is the storage location of the artifacts in the VNF package, where the suffix .arm indicates the template language of the artifacts It's EC2.
  • the VIM information includes the VIM type, such as VIM: Azure; and the supported template language, such as Format: arm.
  • VIM information find the corresponding artifacts in the VNFD TOSCA service template and the corresponding first VNF sub-information in the artifacts, such as the corresponding vnfd_for_Azure.arm file in VNF_package/vnfd_for_Azure.arm.
  • VNFD can be applied to the deployment of multiple different VIM platforms, cross-platform deployment of applications is solved, and support for multiple resource platforms is realized.
  • Step 240 The VNFM sends the first VNF sub-information to the multi-cloud platform for the multi-cloud platform to deploy the VNF on the VIM corresponding to the VIM type.
  • the first VNF sub-information is the above-mentioned vnfd_for_Azure.arm file.
  • the VNFM sends the vnfd_for_Azure.arm file directly to the multi-cloud platform for the multi-cloud platform to deploy VNF on the Azure-type VIM platform.
  • the VNFD includes at least one node template, and each node template includes template information.
  • each node template includes template information.
  • another improvement is given for the VNFD TOSCA service template in the VNF package.
  • the TOSCA service template remains unchanged, that is, the top-level TOSCA service template remains unchanged.
  • Modify the service template related to deployment deployment preference that is, modify it in the lower-level service template.
  • the lower level TOSCA service template can be:
  • each node template node which is used to indicate the template information of the specific VIM of each node.
  • the corresponding VIM template information of each node is found.
  • the VIM information of the node in the request is:
  • the VNF sub-information corresponding to the compute node is the compute_for_Azure.arm file indicated by the address of VNF_package/compute_for_Azure.arm;
  • the VNF sub-information corresponding to the storage node is the storage_for_Azure.arm file indicated by the address of VNF_package/storage_for_Azure.arm;
  • step 240 the sub-information is sent to the multi-cloud multi-cloud platform, and the multi-cloud sends the VNF sub-information of each node to the corresponding VIM platform to deploy the VNF, that is, deploy the VNF on the Azure platform.
  • FIG. 3 is a flowchart of another virtualization management method provided by an embodiment of the present application.
  • FIG. 3 As shown in FIG. 3, another virtualization management method is provided, including the following steps:
  • Step 210 The service coordinator SO or the virtual network function manager NFVO sends the first instantiation request message of the virtualized network function VNF to the VNFM.
  • the first instantiation request message includes the VNF identifier and the virtual infrastructure manager VIM information
  • the information includes the VIM type and the supported template language.
  • Step 220 The VNFM obtains the VNF data packet according to the VNF identifier.
  • steps 210 and 220 are the same as steps 210 and 220 in FIG. 2, and for convenience of description, they are not repeated here.
  • Step 250 when it is determined that the template language supported by the VIM information is the second template language, the VNFM parses the VNFD of the VNF data packet and generates a resource request according to the parsed result.
  • the resource request includes the second VNF sub-information, and the second VNF sub-information is used to Deploy VNF.
  • the VNF data package includes a metadata file in a second template language, and the metadata file includes an indication parameter; parsing the VNFD of the VNF data package includes: parsing the first service template indicated by the indication parameter, the first service The template is included in the VNFD of the VNF packet.
  • the second template language may be the TOSCA template language.
  • the VIM information in the first instantiation request may be:
  • the service template indicated by the entry parameter Definition-Definitions in the VNF data packet is parsed.
  • the first service template refers to the service template indicated by the indication parameter, for example, the top-level TOSCA service template indicated by Entry-Definitions may also be other service templates indicated by other indication parameters.
  • it may be VNFD TOSCA service template, for example.
  • the VNFM directly parses the rest except artifacts. Because the SunshineDB under node_templates in the rest of the section describes some basic information about this VNF.
  • the description address descriptor_id of the VNF the application provider provider, the application name product_name, and other information.
  • the information contained in the VNFD is converted into a corresponding resource request, and the resource request includes the second VNF sub-information.
  • the second VNF sub-information includes all the resource information and the calling request parsed out to deploy the VNF, which are used for subsequent deployment of the VNF. In one example, it can include calls to resources such as computing, storage, and networking.
  • the first service template may further include a first identification; parsing the first service template indicated by the parameter includes: parsing the first service template and the second service template indicated by the first identification.
  • the first identifier may be the deployment preference identifier flavour_id in the VNFD TOSCA service template example in step 220 of FIG. 2, and the deployment preference identifier is described by another TOSCA service template.
  • Step 260 Send the resource request to the multi-cloud platform for the multi-cloud platform to deploy VNF on the VIM corresponding to the VIM type.
  • the VNFM sends the local VNF sub-information parsed in step 250 to the multi-cloud platform for the multi-cloud platform to deploy VNF on the corresponding Openstack platform.
  • the VIM information in the received first instantiation request may be:
  • the resource request includes the second VNF sub-information corresponding to each node.
  • the second VNF sub-information includes all the resource information and the calling request parsed out to deploy the VNF, which are used for subsequent deployment of the VNF. In one example, it can include calls to computing, storage, network and other resources.
  • step 210 of FIGS. 2 and 3 the method further includes the following steps, as shown in FIG. 4,
  • Step 410 Receive a second instantiation request message of a virtualized network function VNF, where the second instantiation request includes a VNF identifier.
  • the SO or NFVO receives the second instantiation request of the VNF, and the second instantiation request includes the VNF package ID of the VNF deployment.
  • step 420 the virtual infrastructure manager VIM type is determined.
  • the VNF may be deployed on the data center of that type according to the deployment strategy of ONAP.
  • different types of data centers correspond to different types of VIM.
  • the deployment strategy of ONAP may be the current resource utilization of VIM.
  • the VIM type determined in step 420 and the template language supported by the VIM type may be:
  • FIG. 5 is a schematic diagram of a virtualization management device provided by an embodiment of the present application.
  • a virtual network function manager 500 including: a receiving module 510, an obtaining module 520, a determining module 530, and a sending module 540.
  • the receiving module 510 is configured to receive the first instantiation request message of the virtualized network function VNF sent by the service coordinator SO or the virtual network function manager NFVO.
  • the first instantiation request message includes the VNF identifier and the virtual infrastructure manager VIM information , VIM information includes VIM types and supported template languages.
  • the obtaining module 520 is used to obtain a VNF data packet according to the VNF identifier.
  • the determining module 530 is configured to, when determining that the template language supported by the VIM information is the first template language, the VNFM obtains the first VNF sub-information consistent with the VIM type and the first template language from the template information, and the first VNF sub-information is used to Deploy VNF; the template information is included in the VNFD descriptor file VNFD.
  • the sending module 540 is configured to send the first VNF sub-information to the multi-cloud platform for deploying the VNF on the VIM corresponding to the VIM type.
  • the determining module 530 is further configured to: when determining that the template language supported by the VIM information is the second template language, parse the VNFD of the VNF data packet, and generate a resource request according to the parsed result, the resource request includes the second VNF sub-information, the second VNF sub-information is used to deploy VNF.
  • the sending module 540 is also used to send a resource request to the multi-cloud platform for the multi-cloud platform to deploy VNF on the VIM corresponding to the VIM type.
  • the VNF data package includes a metadata file of the second template language, and the metadata file includes the indication parameter; the determination module 530 parses the VNFD of the VNF data package, including: the determination module 530 parses the first indicated by the indication parameter Service template.
  • the first service template is included in the VNFD of the VNF data packet.
  • the first service template includes a first identification; the determination module 530 parses the first service template indicated by the indication parameter, including: the determination module 530 parses the first service template and the second service template indicated by the first identification .
  • the VNFD includes at least one node template, and each node template includes template information.
  • FIG. 6 is a schematic diagram of another virtualization management device provided by an embodiment of the present application.
  • a virtualization management device 600 which may be SO or NFVO.
  • the device includes: a receiving module 610, a determining module 620, and a sending module 630.
  • the receiving module 610 is configured to receive a second instantiation request message of a virtualized network function VNF, where the second instantiation request includes a VNF identifier.
  • the determining module 620 is used to determine the virtual infrastructure manager VIM type.
  • the sending module 630 is configured to send the first instantiation request message of the VNF to the virtual network function manager VNFM.
  • the first instantiation request message includes the VNF identification and VIM information.
  • the VIM information includes the VIM type and the supported template language. The first instance The request message is used by VNFM to perform VNF deployment.
  • This application adds template information for different VIM platforms to the VNFD, where the template information contains multiple different VNF sub-information for deploying VNF on different VIM platforms. Therefore, for cross-platform business deployment, the deployment information can be placed in a VNFD to support multiple resource platforms, thereby effectively solving the cross-platform deployment of applications.
  • non-transitory English: non-transitory
  • media such as random access memory, read-only memory, flash memory, hard disk, solid state drive, magnetic tape (English: magnetic tape), floppy disk (English: floppy disk), optical disk (English: optical disc) And any combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例涉及一种虚拟化管理方法，方法包括：VNFM接收SO或NFVO发送的VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和VIM信息，VIM信息包括VIM类型和支持的模板语言。VNFM根据VNF标识获取VNF数据包；当确定VIM信息支持的模板语言为第一模板语言时，VNFM从模板信息中获取与第一模板语言一致的第一VNF子信息，第一VNF子信息用于部署VNF。其中，模板信息包括在VNF数据包的VNFD中。VNFM向多云平台发送第一VNF子信息，用于多云平台在对应的VIM上部署VNF。通过在VNFD中增加模板信息，从而实现对多个资源平台的支持。

Description

一种虚拟化管理方法及装置 技术领域
本申请涉及虚拟化网络领域，尤其涉及一种支持多平台的虚拟化管理方法及装置。
背景技术
网络功能虚拟化(network function virtualization，NFV)是通过使用通用的硬件设备及虚拟化技术，来承载传统网络中专用设备的功能的技术。该技术可以降低因为部署专用设备带来的昂贵成本。通过软硬件之间的解耦，使得网络设备功能不再依赖于专用的硬件。利用了云计算的特点，使得资源可以灵活的共享，以实现新业务的快速开发和部署。同时，还可基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。在NFV中，发起虚拟化请求的一方一般称为业务请求方；而能够接收虚拟化请求，并根据请求对相应业务进行虚拟化处理的一方，一般称为虚拟化业务的提供方。
业务请求方首先需要向业务提供方提交该业务的描述信息，比如一个虚拟网络功能的描述符(virtual network function descriptor，VNFD)。其中包含部署该虚拟网络功能(virtual network function，VNF)需要的虚拟资源信息，例如包括计算，存储，网络等信息。
NFV采用云应用程序的拓扑和编排规范(topology and orchestration specification for cloud applications，TOSCA)语言定义VNFD模板。TOSCA是结构化信息标准促进组织(organization for the advancement of structured information standards，OASIS)制定的描述云计算应用的拓扑和运维流程的模板语言。其中，业务部署包至少包含一个业务部署描述文件，以及文件中还会包含一些会用到的元素的定义。例如包含ServiceTemplate文件，以及ServiceTemplate里会包含例如NodeType，RelationshipType，Policies的定义等。
但是目前虚拟基础设施管理器(virtualised infrastructure manager，VIM)有很多种，比如基于开源的云计算管理平台OpenStack，亚马逊的亚马逊WEB服务AWS，微软的云计算平台Azure等。这些VIM平台都提供有原生的部署模板，不同VIM提供的部署模板在语法和资源定义上也不相同。例如Openstack提供的HOT模板语言，AWS提供的EC2模板语言,Azure提供的ARM模板语言，还有基于容器管理的平台kubernates提供基于YAML语言的部署模板等。
目前NFV定义的基于TOSCA的VNFD部署模板只在基于Openstack的VIM平台上有较好的支持，主要因为TOSCA模板语言和OpenStack的HOT模板语言都采用YAML，而且语法比较类似，在资源定义上也很相似。OpenStack也提供有开源的TOSCA-heat translator项目可以方便的将TOSCA模板语言转换成HOT模板语言。但是当VIM采用其他平台，比如Azure，AWS，或是需要将VNF部署在容器中使用kubernates平台的时候，采用NFV定义的TOSCA VNFD模板就不能满足要求的，无 法将VNF部署在这些VIM平台上了。
发明内容
本申请实施例提供了一种虚拟化管理方法及装置，可以有效解决应用的跨平台部署，采用跨平台的业务部署放在同一个部署模板里，可以根据不同平台的要求用统一的模板对业务做出正确的部署，实现对多个资源平台的支持。
第一方面，提供了一种虚拟化管理方法，方法包括：虚拟网络功能管理器VNFM接收服务协调器SO或网络功能虚拟化编排器NFVO发送的虚拟化网络功能VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，VIM信息包括VIM类型以及支持的模板语言；VNFM根据VNF标识获取VNF数据包；当确定VIM信息支持的模板语言为第一模板语言时，VNFM从模板信息中获取与VIM类型和第一模板语言一致的第一VNF子信息，第一VNF子信息用于部署VNF；其中，模板信息包括在VNF数据包的描述符文件VNFD中；VNFM向多云平台发送第一VNF子信息，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个可能的实施方式中，方法还包括：当确定VIM信息支持的模板语言为第二模板语言时，VNFM解析VNF数据包的VNFD，并根据解析结果生成资源请求，资源请求包括第二VNF子信息，第二VNF子信息用于部署VNF；VNFM向多云平台发送资源请求，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个可能的实施方式中，VNF数据包包括第二模板语言的元数据文件，元数据文件包括指示参数；VNFM解析VNF数据包的VNFD，包括：VNFM解析指示参数指示的第一业务模板，第一业务模板包含于VNF数据包的VNFD中。
在一个可能的实施方式中，第一业务模板包括第一标识；VNFM解析指示参数指示的第一业务模板，包括：VNFM解析第一业务模板与第一标识指示的第二业务模板。
在一个可能的实施方式中，VNFD包括至少一个节点模板，每个节点模板包括模板信息。
第二方面，提供了一种虚拟化管理方法，方法包括：接收虚拟化网络功能VNF的第二实例化请求消息，第二实例化请求包括VNF标识；确定虚拟基础设施管理器VIM类型；向VNFM发送VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和VIM信息，VIM信息包括VIM类型以及支持的模板语言，第一实例化请求消息用于VNFM执行VNF的部署。
第三方面，提供了一种虚拟网络功能管理器，包括：接收模块，用于接收服务协调器SO或网络功能虚拟化编排器NFVO发送的虚拟化网络功能VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，VIM信息包括VIM类型以及支持的模板语言；获取模块，用于根据VNF标识获取VNF数据包；确定模块，用于当确定VIM信息支持的模板语言为第一模板语言时，VNFM从模板信息中获取与VIM类型和第一模板语言一致的第一VNF子信息，第一VNF子信息用于部署VNF；其中，模板信息包括在VNF数据包的描述符文件VNFD中；发送模块，用于向多云平台发送第一VNF子信息，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个可能的实施方式中，确定模块还用于：当确定VIM信息支持的模板语言为第二模板语言时，解析VNF数据包的VNFD，并根据解析结果生成资源请求，资源请求包括第二VNF子信息，第二VNF子信息用于部署VNF；发送模块，还用于向多云平台发送资源请求，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个可能的实施方式中，VNF数据包包括第二模板语言的元数据文件，元数据文件包括指示参数；确定模块解析VNF数据包的VNFD，包括：确定模块解析指示参数指示的第一业务模板，第一业务模板包含于VNF数据包的VNFD中。
在一个可能的实施方式中，第一业务模板包括第一标识；确定模块解析指示参数指示的第一业务模板，包括：确定模块解析第一业务模板与第一标识指示的第二业务模板。
在一个可能的实施方式中，VNFD包括至少一个节点模板，每个节点模板包括模板信息。
第四方面，提供了一种虚拟化管理装置，所述装置为服务协调器SO或网络功能虚拟化编排器NFVO，包括：接收模块，用于接收虚拟化网络功能VNF的第二实例化请求消息，第二实例化请求包括VNF标识；确定模块，用于确定虚拟基础设施管理器VIM类型；发送模块，用于向虚拟网络功能管理器VNFM发送VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和VIM信息，VIM信息包括VIM类型以及支持的模板语言，第一实例化请求消息用于VNFM执行VNF的部署。
第五方面，提供了一种系统，系统包括第三方面的虚拟网络功能管理器和第四方面的服务协调器。
第六方面，提供了一种存储程序的计算机可读存储介质，其特征在于，程序包括指令，指令当被终端执行时，使终端执行第一方面和第二方面的方法。
第七方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行第一方面和第二方面的方法。
本申请公开了一种虚拟化管理方法及装置，通过在VNFD中增加针对不同VIM平台的模板信息，其中模板信息包含有针对在不同VIM平台上部署VNF的多个不同VNF子信息。从而针对跨平台的业务部署，可以将其部署信息放在一个VNFD中，实现对多个资源平台的支持，从而有效解决应用的跨平台部署。
附图说明
图1为本申请实施例提供的一种NFV系统架构示意图；
图2为本申请实施例提供的一种虚拟化管理方法流程图；
图3为本申请实施例提供的另一种虚拟化管理方法流程图；
图4为本申请实施例提供的再一种虚拟化管理方法流程图；
图5为本申请实施例提供的一种虚拟化管理装置示意图；
图6为本申请实施例提供的另一种虚拟化管理装置示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
本申请应用在网络功能虚拟化系统中，如图1所示，图1为本申请实施例提供的一种NFV系统架构示意图。
在NFV系统架构100中，包括运营支持系统和业务支持系统(operations support system and business support system，OSS/BSS)110、网络功能虚拟化编排器(network functions virtualization orchestrator，NFVO)120、虚拟网络功能管理器(virtual network function manager，VNFM)130、虚拟基础设施管理器VIM 140、设备管理系统(equipment management，EM)150、虚拟化网络功能VNF 160和网络功能虚拟化基础设施(network functions virtualization infrastructure，NFVI)170。
其中，OSS/BSS110支持各种端到端的电信业务。运营支持系统OSS支持的管理功能包括：网络配置，业务提供，故障管理等。业务支持系统BSS处理订单，付费，收入等，支持产品管理，订单管理，收益管理及客户管理。
NFVO120主要负责处理虚拟化业务的生命周期管理，以及虚拟基础设施及NFVI中虚拟资源的分配和调度等。NFVO120可以与一个或多个VNFM130通信，以执行资源相关请求。NFVO120发送配置信息给VNFM130，从而收集VNF160的状态信息。另外，NFVO120也可与VIM 106进行通信，用于执行资源分配、和/或预留、交换虚拟化硬件资源配置和状态信息。
VNFM 130负责一个或多个VNF 160的生命周期管理，比如实例化(instantiating)、更新(updating)、查询、弹性伸缩(scaling)和终止(terminating)VNF160。VNFM130可以与VNF160通信，从而完成VNF生命周期管理及交换配置和状态信息。在NFV 100的架构中，VNFM 130可以有多个，负责对不同类型的VNF 160进行生命周期管理。
VIM 140用于控制和管理VNF160与计算硬件、存储硬件、网络硬件、虚拟计算(virtual computing)、虚拟存储和虚拟网络的交互。例如VIM 140执行资源管理功能，包括管理基础设施资源、分配及运行功能。其中，分配例如增加资源给虚拟容器等，运行功能例如收集NFVI故障信息等。VNFM 130及VIM140可以相互通信，进行请求资源分配、交换虚拟化硬件资源配置和状态信息等。
EM150是传统电信系统中用于对设备进行配置、管理的系统。在NFV 100的架构中，EM150也可以用于对VNF 160进行配置和管理，以及向VNFM 130发起新的VNF的实例化等生命周期管理操作。其中，EM 150中可以包括多个EM，例如：设备管理系统1、设备管理系统2等。
VNF 160即虚拟网络功能，可以有多个不同类型的VNF，如虚拟网络功能1、虚拟网络功能2等。
NFVI 170即NFV的基础设施层，包含了硬件部件、软件部件或两者组合，以建立可以部署、管理及实现VNF160的虚拟化环境。硬件资源和虚拟化层用于为VNF160提供虚拟化资源，例如虚拟机和其他形式的虚拟容器。硬件资源包括计算(computing)硬件、存储硬件和网络硬件等。作为一种实施方式，计算硬件和存储硬件的资源可以集中在一起。NFVI 170中的虚拟化层可以抽象硬件资源，解耦VNF160与底层的物理网络层。
针对当前NFV定义的基于TOSCA的VNFD部署模板，存在着这样的一种基于TOSCA语言的云应用部署平台，例如云应用部署平台cloudify。cloudify通过提供一 些不同的插件(plugin)，从而使其能和不同的VIM平台对接，实现在不同VIM平台上进行部署应用。目前cloudify提供的插件有Aria plugin、Azure plugin、Openstack plugin、Vsphere plugin和AWS plugin等等。如果将cloudify部署在VNFM或NFVO上，理论上可以为NFV提供对多种VIM的支持，例如包括Openstack、Aria、Azure、Vsphere和AWS等平台。
在cloudify平台架构中，针对不同的VIM平台，定义了不同的TOSCA类型对虚拟资源进行建模。也就是对于同一个应用来说，对于不同的VIM平台需要设计多个VNFD模板来支持该应用的部署。
比如对于一个待部署应用如果采用Cloudify的方案，其VNF数据包中包括了对于不同平台的VNFD文件。例如openstack-blueprint.yaml是用于openstack平台的VNFD文件；azure-blueprint.yaml是用于Azure平台的VNFD文件；aws-blueprint.yaml是用于AWS平台的VNFD文件。
当不采用cloudify时，当用户需要在指定在VIM平台上部署应用，通常的做法是采用指定的VIM平台支持的部署模板语言进行应用模板设计。例如OpenStack平台采用HOT模板进行设计，AWS采用EC2模板进行设计，Azure采用ARM模板进行设计等。然后再将预先设计好的部署模板发送至相应的VIM平台，并在发送请求中携带需要的部署参数，从而完成应用的部署。
而当采用cloudify时，用户如果希望在指定的VIM平台的部署应用，则需要采用cloudify定义的TOSCA模型设计应用，而对于不同的VIM平台，cloudify提供不同的TOSCA模板。例如VIM采用OpenStack平台，cloudify提供的TOSCA模型为：
cloudify.openstack.nodes.Server(代表虚拟机资源)
cloudify.openstack.nodes.Subnet(代表虚拟子网资源)
cloudify.openstack.nodes.SecurityGroup(代表安全组资源)
cloudify.openstack.nodes.Router(代表虚拟路由器资源)
cloudify.openstack.nodes.Network(代表虚拟网络资源)
cloudify.openstack.nodes.Volume(代表虚拟存储资源)
cloudify.openstack.nova_net.nodes.FloatingIP(代表浮动IP资源)等等。具体定义可以参看https://raw.githubusercontent.com/cloudify-cosmo/cloudify-openstack-plugin/2.6.0/plugin.yaml。
当采用该模型设计的应用模板发送到cloudify平台后，cloudify会根据相应的定义对模板进行解析，并将解析的结果转换成Openstack平台的资源申请请求。
在其他平台的步骤类似，例如在AWS上部署，则需要采用cloudify定义的AWS的TOSCA模型设计应用，例如：
cloudify.aws.nodes.Instance(代表虚拟机资源)
cloudify.aws.nodes.SecurityGroup(代表虚拟安全组资源)
cloudify.aws.nodes.Volume(代表虚拟存储资源)
cloudify.aws.nodes.VPC(代表虚拟网络资源)
cloudify.aws.nodes.Subnet(代表虚拟子网资源)
cloudify.aws.nodes.Interface(代表虚拟端口资源)等等，具体定义可以参看 https://github.com/cloudify-cosmo/cloudify-aws-plugin/releases/download/1.5.1.2/plugin.yaml。
对于不同的VIM平台定义的TOSCA模型差异是很大的，主要是因为不同VIM对资源的定义本身存在差异。从以上模型可以看出，cloudify平台并没有有效减少用户的设计工作量，反而需要再学习cloudify定义的指定VIM的TOSCA模型，针对VIM原生模型则无法使用。
TOSCA作为目前更加广泛使用的业务部署模板，在行业内也有较大的使用比例。欧洲电信标准化协会对NFV规范所定义的VNFD模型也是采用的TOSCA模板语言。cloudify虽然提供了基于plugin插件的方式来支持在多种不同的VIM平台上部署应用，但是需要针对不同的VIM平台设计出不同的TOSCA模型。整个过程使得使用者的学习成本过高，需要掌握多个TOSCA模型进行使用。而且上述TOSCA模型只能依靠cloudify平台进行解析。由于该模型与VIM是强相关的，和ETSI NFV定义的模型差异较大，对当前的VNFM或者NFVO改造工作会很大。此外由于对应的VIM平台还不能直接解析该TOSCA模板，所以在部署时cloudify平台需要将该TOSCA模型转换成对应VIM平台的资源调用API，或者转换成对应的VIM平台上的原生部署模板，才能最终实现部署应用。
上述问题明显增加了部署VNF的使用成本，同时造成了无法部署跨越不同VIM平台的VNF。为此本申请实施例提供了一种虚拟化管理方法。
本申请实施例通过在VNFD中增加针对不同VIM平台的模板信息，从而使得在部署跨平台的VNF时，使用统一模板的VNFD即可完成针对不同VIM平台的部署。并且不需要针对不同的VIM平台设计出不同的TOSCA模型，从而降低了使用者的学习成本。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
图2为本申请实施例提供的一种虚拟化管理方法流程图。
如图2所示，提供了一种虚拟化管理方法，包括以下步骤：
步骤210，服务协调器SO或虚拟网络功能管理器NFVO向VNFM发送的虚拟化网络功能VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，VIM信息包括VIM类型以及支持的模板语言。
服务协调器(service orchestrator，SO)或虚拟网络功能管理器NFVO向VNFM发送的第一实例化请求，该实例化请求中包括了需要部署的VNF标识以及VIM信息。其中，VNF标识可以是VNF package ID。VIM信息中包含有需要部署的VIM类型以及该VIM类型所支持的部署模板语言。
步骤220，VNFM根据VNF标识获取VNF数据包。
VNFM接收SO或NFVO发送的第一实例化请求消息，根据VNF package ID获取到VNF数据包package。VNFM根据请求中的VNF package ID向数据库获取VNFpackage。在一个例子中，上述数据库可以是自动化管理与编排开源平台(open network automation platform，ONAP)中的业务设计模块(service design and creation，SDC)。首先解析VNF package中TOSCA-Metadata文件夹目录下的TOSCA.meta文件。该文件中包括Entry-Definitions等参数。其中，Entry-Definitions参数所指示这最先需要解 析的业务模板VNFD TOSCA service template文件的地址以及文件名。在另一个例子中VNFD可以由多个TOSCA service template组成。下面给出一个更为具体的示例，VNFD TOSCA service template具体的可以是：
Figure PCTCN2019120707-appb-000001
如上述代码所示，其中在service template中node_templates下的SunshineDB，描述了这个VNF的一些基本信息。例如该VNF的描述地址descriptor_id、应用提供方provider、应用名称product_name等等信息。
步骤230，当确定VIM信息支持的模板语言为第一模板语言时，VNFM从模板信息中获取与VIM类型和第一模板语言一致的第一VNF子信息，第一VNF子信息用于部署VNF。其中，模板信息包括在VNF数据包的描述符文件VNFD中。
在一个例子中，第一语言可以是除TOSCA之外的任何其他模板语言，例如ARM、EC2等。当确定VIM信息中所支持的模板语言不是TOSCA，即ARM或EC2等模板语言时，VNFM从是上述VNFD TOSCA service template中的模板信息中获取获取与 VIM类型和第一模板语言一致的第一VNF子信息。其中，模板语言可以是上述VNFD TOSCA service template示例中的artifacts。在artifacts中，可以根据需求提前设计好需要用到的其他模板语言的VIM模板信息。在一个例子中，artifacts中包含多个不同的VNF子信息。例如vim_specific_template_1和vim_specific_template_2。在该实施例中，采用其他格式的命名也是可以允许的。其中vim_specific_template_1的类型type()为tosca.artifacts.nfv.Azure，即表明该artifacts是用于Azure类型的模板，文件(file)是该artifacts在VNF package中的存放位置。其中后缀.arm即表明该artifacts的模板语言是arm的。同理，vim_specific_template_2的type为tosca.artifacts.nfv.AWS，即表明该artifacts是用于AWS类型的模板，file是该artifacts在VNF package中的存放位置，其中后缀.arm表明了该artifacts的模板语言是EC2的。
在一个例子中，VIM信息包括VIM类型，例如VIM：Azure；以及支持的模板语言，例如Format：arm。
根据上述VIM信息找到上述VNFD TOSCA service template中对应的artifacts，以及artifacts中对应的第一VNF子信息，例如VNF_package/vnfd_for_Azure.arm中对应的vnfd_for_Azure.arm文件。
通过在该实施例中增加artifacts的描述，可以解决在一个VNFD中可以适用于多个不同VIM平台的部署，解决了应用的跨平台部署，实现对多个资源平台的支持。
步骤240，VNFM向多云平台发送第一VNF子信息，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个例子中，第一VNF子信息是上述vnfd_for_Azure.arm文件，当VNFM确定了后，VNFM将vnfd_for_Azure.arm文件直接发送给多云平台，用于多云平台在Azure类型的VIM平台上进行部署VNF。
在一个实施例中，VNFD包括至少一个节点模板，每个节点模板包括模板信息。在一个例子中，针对VNF package中的VNFD TOSCA service template给出了另一种改进。对于TOSCA.meta文件中Entry-Definitions指示的VNFD TOSCA service template保持不变，即对top-level TOSCA service template保持不变。对部署喜好deployment flavour相关的service template进行修改，即在lower-level service template中进行修改。下面给出一个更为具体的示例，lower level TOSCA service template具体的可以是：
Figure PCTCN2019120707-appb-000002
Figure PCTCN2019120707-appb-000003
Figure PCTCN2019120707-appb-000004
在上述示例中，在每个节点模板node template中都增加artifacts的描述，用于指示每个节点的特定VIM的模板信息。在本实施例中，根据步骤210～步骤230中一样，根据第一实例化请求中的VIM信息，找出对应的每个节点的VIM的模板信息。当确定该节点的VIM信息支持的模板语言为第一模板语言时，则从该节点的模板信息artifacts中获取与VIM类型和第一模板语言一致的第一VNF子信息。在一个例子中，例如请求中该节点的VIM信息是：
VIM：Azure
Format：arm
则根据上述VIM信息找到lower lever service template中每个node template对应的artifact。即compute节点对应的VNF子信息是VNF_package/compute_for_Azure.arm地址指示的compute_for_Azure.arm文件；storage节点对应的VNF子信息是VNF_package/storage_for_Azure.arm地址指示的storage_for_Azure.arm文件；CP节点对应的VNF子信息是VNF_package/cp_for_Azure.arm地址指示的cp_for_Azure.arm文件。然后通过步骤240将这些子信息发给多云平台multi-cloud，并由multi-cloud发送将上述各个节点的VNF子信息发送给对应的VIM平台上部署该VNF，即在Azure平台上部署该VNF。
通过本申请提供的虚拟化管理方法可以有效解决应用的跨平台部署，采用统一的部署模板，在上层管理平台统一的情况下，实现对多个资源平台的支持。
图3为本申请实施例提供的另一种虚拟化管理方法流程图。
如图3所示，提供了另一种虚拟化管理方法，包括以下步骤：
步骤210，服务协调器SO或虚拟网络功能管理器NFVO向VNFM发送的虚拟化网络功能VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，VIM信息包括VIM类型以及支持的模板语言。
步骤220，VNFM根据VNF标识获取VNF数据包。
本领域技术人员应当注意，上述步骤210和步骤220与图2中步骤210和步骤220一致，为方便描述，在此不再赘述。
步骤250，当确定VIM信息支持的模板语言为第二模板语言时，VNFM解析VNF数据包的VNFD，并根据解析结果生成资源请求，资源请求包括第二VNF子信息，第二VNF子信息用于部署VNF。
在一个实施例中，VNF数据包包括第二模板语言的元数据文件，所述元数据文件包括指示参数；解析VNF数据包的VNFD，包括：解析指示参数指示的第一业务模板，第一业务模板包含于VNF数据包的VNFD中。
在一个实例中，第二模板语言可以的TOSCA模板语言。例如第一实例化请求中的VIM信息可以是：
VIM：Openstack
Format：TOSCA
当确定VIM信息支持的模板语言是TOSCA模板语言时，解析VNF数据包中的指示参数Entry-Definitions指示的业务模板。本领域人员应当注意，第一业务模板指代的是指示参数指示的业务模板，例如可用是Entry-Definitions指示的top-level TOSCA service template也可以是其他指示参数指示的其他业务模板。在本实例中，例如可以是VNFD TOSCA service template。在上述图2步骤220的VNFD TOSCA service template示例中，VNFM直接解析除artifacts的其余部分。因为在其余部分中node_templates下的SunshineDB，描述了这个VNF的一些基本信息。例如该VNF的描述地址descriptor_id、应用提供方provider、应用名称product_name等等信息。然后将VNFD中所包含的信息转换成对应的资源请求，该资源请求中包括第二VNF子信息。其中第二VNF子信息包括了上述解析出的部署该VNF的所有资源信息以及调用请求，用于后续对VNF进行部署。在一个例子中可以包括对计算，存储，网络等资源 的调用。
在另一个实例中，第一业务模板还可以包括第一标识；解析指示参数指示的第一业务模板，包括：解析第一业务模板与第一标识指示的第二业务模板。例如，第一标识可以是图2步骤220的VNFD TOSCA service template示例中的部署喜好标识flavour_id，该部署喜好标识用另一个TOSCA service template描述。本领域人员应当注意，一个VNFD中可以有多个部署喜好，每个部署喜好用一个单独的TOSCA service template来进行描述。然后针对每个业务模板进行解析得相应的第二VNF子信息。
步骤260，向多云平台发送所述资源请求，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个示例中，VNFM将步骤250解析得到的地儿VNF子信息发送至多云平台，用于多云平台在对应的Openstack平台上部署VNF。
在另一个示例中，例如图2步骤220中对于lower-level service template的修改。例如接收的第一实例化请求中的VIM信息可以是：
VIM：Openstack
Format：TOSCA
则忽略每个节点模板中的artifacts，直接根据节点模板中的其余描述将VNFD中所包含的信息转换成Openstack平台对应的资源请求。该资源请求中包括各个节点对应的第二VNF子信息。其中第二VNF子信息包括了上述解析出的部署该VNF的所有资源信息以及调用请求，用于后续对VNF进行部署。在一个例子中可以包括对计算，存储，网络等资源的调用。
在图2和图3的步骤210之前，该方法还包括以下步骤，如图4所示，
步骤410，接收虚拟化网络功能VNF的第二实例化请求消息，第二实例化请求包括VNF标识。
在一个实施例中，SO或NFVO接收了VNF的第二实例化请求，该第二实例化请求中包含有部署该VNF的VNF package ID。
步骤420，确定虚拟基础设施管理器VIM类型。
在一个实施例中，可以根据ONAP的部署策略，选择在那种类型的数据中心上部署该VNF。其中，不同类型的数据中心对应着不同类型的VIM。在一个示例中，ONAP的部署策略可以是当前VIM的资源利用情况。
在一个示例中，步骤420确定的VIM类型以及该VIM类型所支持的模板语言可以是：
VIM：Openstack
Format:TOSCA
或者是
VIM：Azure
Format：ARM
本领域人员应当注意，上述提供的仅仅是确定的VIM类型以及该VIM类型所支持的模板语言的几种可能的形式，但并不限于此，任何可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。
图5为本申请实施例提供的一种虚拟化管理装置示意图。
如图5所示，提供了一种虚拟网络功能管理器500，包括：接收模块510、获取模块520、确定模块530以及发送模块540。接收模块510，用于接收服务协调器SO或虚拟网络功能管理器NFVO发送的虚拟化网络功能VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，VIM信息包括VIM类型以及支持的模板语言。获取模块520，用于根据VNF标识获取VNF数据包。确定模块530，用于当确定VIM信息支持的模板语言为第一模板语言时，VNFM从模板信息中获取与VIM类型和第一模板语言一致的第一VNF子信息，第一VNF子信息用于部署VNF；其中，模板信息包括在VNF数据包的描述符文件VNFD中。发送模块540，用于向多云平台发送第一VNF子信息，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个可能的实施方式中，确定模块530还用于：当确定VIM信息支持的模板语言为第二模板语言时，解析VNF数据包的VNFD，并根据解析结果生成资源请求，资源请求包括第二VNF子信息，第二VNF子信息用于部署VNF。发送模块540还用于向多云平台发送资源请求，用于多云平台在VIM类型对应的VIM上部署VNF。
在一个可能的实施方式中，VNF数据包包括第二模板语言的元数据文件，元数据文件包括指示参数；确定模块530解析VNF数据包的VNFD，包括：确定模块530解析指示参数指示的第一业务模板，第一业务模板包含于VNF数据包的VNFD中。
在一个可能的实施方式中，第一业务模板包括第一标识；确定模块530解析指示参数指示的第一业务模板，包括：确定模块530解析第一业务模板与第一标识指示的第二业务模板。
在一个可能的实施方式中，VNFD包括至少一个节点模板，每个节点模板包括模板信息。
图6为本申请实施例提供的另一种虚拟化管理装置示意图。
如图6所示，提供了一种虚拟化管理装置600，该装置可以是SO，也可以是NFVO。该装置包括：接收模块610、确定模块620以及发送模块630。接收模块610，用于接收虚拟化网络功能VNF的第二实例化请求消息，第二实例化请求包括VNF标识。确定模块620，用于确定虚拟基础设施管理器VIM类型。发送模块630，用于向虚拟网络功能管理器VNFM发送VNF的第一实例化请求消息，第一实例化请求消息包括VNF标识和VIM信息，VIM信息包括VIM类型以及支持的模板语言，第一实例化请求消息用于VNFM执行VNF的部署。
本申请通过在VNFD中增加针对不同VIM平台的模板信息，其中模板信息包含有针对在不同VIM平台上部署VNF的多个不同VNF子信息。从而对跨平台的业务部署，可以将其部署信息放在一个VNFD中，实现对多个资源平台的支持，从而有效解决应用的跨平台部署。
本领域普通技术人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的 特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令处理器完成，所述的程序可以存储于计算机可读存储介质中，所述存储介质是非短暂性(英文：non-transitory)介质，例如随机存取存储器，只读存储器，快闪存储器，硬盘，固态硬盘，磁带(英文：magnetic tape)，软盘(英文：floppy disk)，光盘(英文：optical disc)及其任意组合。
以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (15)

  1. 一种虚拟化管理方法，其特征在于，所述方法包括：
    虚拟网络功能管理器VNFM接收服务协调器SO或网络功能虚拟化编排器NFVO发送的虚拟化网络功能VNF的第一实例化请求消息，所述第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，所述VIM信息包括VIM类型以及支持的模板语言；
    所述VNFM根据所述VNF标识获取VNF数据包；
    当确定所述VIM信息支持的模板语言为第一模板语言时，所述VNFM从模板信息中获取与所述VIM类型和所述第一模板语言一致的第一VNF子信息，所述第一VNF子信息用于部署VNF；其中，所述模板信息包括在所述VNF数据包的描述符文件VNFD中；
    所述VNFM向多云平台发送所述第一VNF子信息，用于所述多云平台在所述VIM类型对应的VIM上部署VNF。
  2. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    当确定所述VIM信息支持的模板语言为第二模板语言时，所述VNFM解析所述VNF数据包的VNFD，并根据解析结果生成资源请求，所述资源请求包括第二VNF子信息，所述第二VNF子信息用于部署VNF；
    所述VNFM向多云平台发送所述资源请求，用于所述多云平台在所述VIM类型对应的VIM上部署VNF。
  3. 如权利要求2所述的方法，其特征在于，所述VNF数据包包括第二模板语言的元数据文件，所述元数据文件包括指示参数；所述VNFM解析所述VNF数据包的VNFD，包括：
    所述VNFM解析所述指示参数指示的第一业务模板，所述第一业务模板包含于所述VNF数据包的VNFD中。
  4. 如权利要求2所述的方法，其特征在于，所述第一业务模板包括第一标识；所述VNFM解析所述指示参数指示的第一业务模板，包括：
    所述VNFM解析所述第一业务模板与所述第一标识指示的第二业务模板。
  5. 如权利要求1所述的方法，其特征在于，所述VNFD包括至少一个节点模板，每个所述节点模板包括所述模板信息。
  6. 一种虚拟化管理方法，其特征在于，所述方法包括：
    接收虚拟化网络功能VNF的第二实例化请求消息，所述第二实例化请求包括VNF标识；
    确定虚拟基础设施管理器VIM类型；
    向VNFM发送VNF的第一实例化请求消息，所述第一实例化请求消息包括VNF标识和VIM信息，所述VIM信息包括VIM类型以及支持的模板语言，所述第一实例化请求消息用于所述VNFM执行VNF的部署。
  7. 一种虚拟网络功能管理器，其特征在于，包括：
    接收模块，用于接收服务协调器SO或网络功能虚拟化编排器NFVO发送的虚拟化网络功能VNF的第一实例化请求消息，所述第一实例化请求消息包括VNF标识和虚拟基础设施管理器VIM信息，所述VIM信息包括VIM类型以及支持的模板语言；
    获取模块，用于根据所述VNF标识获取VNF数据包；
    确定模块，用于当确定所述VIM信息支持的模板语言为第一模板语言时，所述VNFM从模板信息中获取与所述VIM类型和所述第一模板语言一致的第一VNF子信息，所述第一VNF子信息用于部署VNF；其中，所述模板信息包括在所述VNF数据包的描述符文件VNFD中；
    发送模块，用于向多云平台发送所述第一VNF子信息，用于所述多云平台在所述VIM类型对应的VIM上部署VNF。
  8. 如权利要求7所述的虚拟网络功能管理器，其特征在于，所述确定模块还用于：
    当确定所述VIM信息支持的模板语言为第二模板语言时，解析所述VNF数据包的VNFD，并根据解析结果生成资源请求，所述资源请求包括第二VNF子信息，所述第二VNF子信息用于部署VNF；
    所述发送模块，还用于向多云平台发送所述资源请求，用于所述多云平台在所述VIM类型对应的VIM上部署VNF。
  9. 如权利要求8所述的虚拟网络功能管理器，其特征在于，所述VNF数据包包括第二模板语言的元数据文件，所述元数据文件包括指示参数；所述确定模块解析所述VNF数据包的VNFD，包括：
    所述确定模块解析确定模块所述指示参数指示的第一业务模板，所述第一业务模板包含于所述VNF数据包的VNFD中。
  10. 如权利要求8所述的虚拟网络功能管理器，其特征在于，所述第一业务模板包括第一标识；所述确定模块解析所述指示参数指示的第一业务模板，包括：
    所述确定模块解析所述第一业务模板与所述第一标识指示的第二业务模板。
  11. 如权利要求7所述的虚拟网络功能管理器，其特征在于，所述VNFD包括至少一个节点模板，每个所述节点模板包括所述模板信息。
  12. 一种虚拟化管理装置，其特征在于，包括：
    接收模块，用于接收虚拟化网络功能VNF的第二实例化请求消息，所述第二实例化请求包括VNF标识；
    确定模块，用于确定虚拟基础设施管理器VIM类型；
    发送模块，用于向虚拟网络功能管理器VNFM发送VNF的第一实例化请求消息，所述第一实例化请求消息包括VNF标识和VIM信息，所述VIM信息包括VIM类型以及支持的模板语言，所述第一实例化请求消息用于所述VNFM执行VNF的部署。
  13. 一种系统，其特征在于，所述系统包括权利要求7至11任一项所述的虚拟网络功能管理器和权利要求12所述的服务协调器。
  14. 一种存储程序的计算机可读存储介质，其特征在于，所述程序包括指令，所 述指令当被终端执行时，使所述终端执行根据权利要求1-6任一所述的方法。
  15. 一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如权利要求1-6任一所述的方法。
PCT/CN2019/120707 2018-11-29 2019-11-25 一种虚拟化管理方法及装置 Ceased WO2020108443A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19890401.3A EP3883183A4 (en) 2018-11-29 2019-11-25 Virtualization management method and device
US17/333,417 US12035231B2 (en) 2018-11-29 2021-05-28 Virtualization management method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811445643.1A CN111245634B (zh) 2018-11-29 2018-11-29 一种虚拟化管理方法及装置
CN201811445643.1 2018-11-29

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/333,417 Continuation US12035231B2 (en) 2018-11-29 2021-05-28 Virtualization management method and apparatus

Publications (1)

Publication Number Publication Date
WO2020108443A1 true WO2020108443A1 (zh) 2020-06-04

Family

ID=70853751

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/120707 Ceased WO2020108443A1 (zh) 2018-11-29 2019-11-25 一种虚拟化管理方法及装置

Country Status (4)

Country Link
US (1) US12035231B2 (zh)
EP (1) EP3883183A4 (zh)
CN (1) CN111245634B (zh)
WO (1) WO2020108443A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102486236B1 (ko) * 2017-12-26 2023-01-09 삼성전자주식회사 무선 통신 시스템에서 네트워크 기능 가상화를 위한 장치 및 방법
US10855757B2 (en) * 2018-12-19 2020-12-01 At&T Intellectual Property I, L.P. High availability and high utilization cloud data center architecture for supporting telecommunications services
US20210326157A1 (en) * 2020-04-15 2021-10-21 Open Invention Network Llc Onboarding a vnf with a multi-vnfc vdu
CN114978912B (zh) * 2021-02-23 2025-01-28 中国电信股份有限公司 资源授权方法、nfvo、网络系统以及存储介质
US11431563B1 (en) * 2021-07-27 2022-08-30 Vmware, Inc. Intelligent management of cloud infrastructures using a cloud management platform
US11755301B2 (en) 2021-07-27 2023-09-12 Vmware, Inc. Deployment of cloud infrastructures using a cloud management platform
US11755317B2 (en) * 2021-10-15 2023-09-12 Salesforce, Inc. Extensible platform as a service platform for use by multiple enterprises
WO2023104353A1 (en) * 2021-12-10 2023-06-15 Telefonaktiebolaget Lm Ericsson (Publ) Configurable support for generic virtualized infrastructure manager resources
CN114371914A (zh) * 2022-01-10 2022-04-19 杭州博盾习言科技有限公司 容器ip地址配置方法、装置、存储介质及电子设备
CN115484171B (zh) * 2022-09-16 2024-07-23 江苏润开鸿数字科技有限公司 基于虚拟机与容器融合的网络拓扑创建方法
CN117081945B (zh) * 2023-10-12 2024-01-09 南京中科境远科技有限公司 核心网切片子网实例部署方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106533935A (zh) * 2015-09-14 2017-03-22 华为技术有限公司 一种在云计算系统中获取业务链信息的方法和装置
CN106921977A (zh) * 2015-12-26 2017-07-04 华为技术有限公司 一种基于业务流的服务质量规划方法、装置及系统
WO2017185922A1 (zh) * 2016-04-29 2017-11-02 华为技术有限公司 一种业务部署方法、装置以及网元

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101932872B1 (ko) * 2015-01-23 2019-03-15 닛본 덴끼 가부시끼가이샤 네트워크 기능들 가상화의 관리 및 오케스트레이션을 위한 방법, 디바이스, 및 프로그램
JP6819296B2 (ja) * 2015-01-28 2021-01-27 日本電気株式会社 仮想化管理・オーケストレーション装置、仮想化管理・オーケストレーション方法、および、プログラム
US10129206B2 (en) * 2015-06-05 2018-11-13 Cisco Technology, Inc. Addressing and managing an internal network of a virtual branch node
CN105429806B (zh) * 2015-12-24 2019-06-11 武汉邮电科学研究院 一种基于数据驱动的网络功能虚拟化的装置及方法
KR20180110095A (ko) * 2016-02-08 2018-10-08 노키아 솔루션스 앤드 네트웍스 오와이 네트워크 가상화 시나리오들의 자원 배치 제어
US10037536B2 (en) * 2016-02-13 2018-07-31 At&T Intellectual Property I, L.P. Method and apparatus for autonomous services composition
CN108781166A (zh) * 2016-04-27 2018-11-09 华为技术有限公司 Vnfm的确定方法和网络功能虚拟化编排器
WO2018033878A1 (en) * 2016-08-18 2018-02-22 Telefonaktiebolaget Lm Ericsson (Publ) A network service design and deployment process for nfv systems
CN108024256B (zh) * 2016-11-03 2020-04-03 华为技术有限公司 一种收缩网络切片实例的方法、装置和系统
CN108234158B (zh) * 2016-12-14 2021-04-20 中国电信股份有限公司 Vnf的建立方法、nfvo以及网络系统
CN109151077B (zh) * 2018-10-31 2020-04-07 电子科技大学 一种基于目标导向的计算卸载方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106533935A (zh) * 2015-09-14 2017-03-22 华为技术有限公司 一种在云计算系统中获取业务链信息的方法和装置
CN106921977A (zh) * 2015-12-26 2017-07-04 华为技术有限公司 一种基于业务流的服务质量规划方法、装置及系统
WO2017185922A1 (zh) * 2016-04-29 2017-11-02 华为技术有限公司 一种业务部署方法、装置以及网元

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3883183A4 *

Also Published As

Publication number Publication date
CN111245634B (zh) 2021-05-18
EP3883183A1 (en) 2021-09-22
EP3883183A4 (en) 2021-12-29
CN111245634A (zh) 2020-06-05
US12035231B2 (en) 2024-07-09
US20210289435A1 (en) 2021-09-16

Similar Documents

Publication Publication Date Title
US12035231B2 (en) Virtualization management method and apparatus
US11588675B2 (en) Systems and methods for selectively implementing services on virtual machines and containers
US10432460B2 (en) Network service scaling method and apparatus
JP6834033B2 (ja) ネットワークスライス管理方法、ユニット、及びシステム
EP3471342A1 (en) Method and device for service deployment in virtualized network
WO2019184967A1 (zh) 一种网络切片的部署方法及装置
CN107222324B (zh) 网络服务的业务配置方法和装置
CN107332750A (zh) 一种业务部署方法、装置以及网元
WO2017080391A1 (zh) 一种网络服务部署方法和装置
US20230261950A1 (en) Method of container cluster management and system thereof
US12056094B2 (en) Method and apparatus for deploying virtualised network function
US11683222B2 (en) Virtual network function VNF deployment method and apparatus
WO2021088444A1 (zh) 实例化ns的方法及nfvo
US11888696B2 (en) VNF instantiation method and apparatus
US20250293933A1 (en) Instantiation method and apparatus for virtualised network function vnf
CN112889247B (zh) Vnf服务实例化方法及装置
US20230409371A1 (en) Method for creating network service ns and related apparatus
US20230105269A1 (en) Virtualized network service deployment method and apparatus
WO2021129868A1 (zh) 网络服务实例化的方法及网络功能虚拟化编排器
CN117201336A (zh) 一种边缘用户服务切片生成方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19890401

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019890401

Country of ref document: EP

Effective date: 20210614