CN111835679B

CN111835679B - Tenant resource management method and device under multi-tenant scene

Info

Publication number: CN111835679B
Application number: CN201910313602.5A
Authority: CN
Inventors: 杨旭
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-04-18
Filing date: 2019-04-18
Publication date: 2022-03-25
Anticipated expiration: 2039-04-18
Also published as: CN111835679A; WO2020211652A1

Abstract

The embodiment of the application provides a tenant resource management method and device under a multi-tenant scene. The tenant resource management method under the multi-tenant scene provided by the embodiment of the application comprises the following steps: the VNFM receives a tenant resource increasing request sent by the NFVO, wherein the tenant resource increasing request comprises the number of resources required to be increased by the tenant; the VNFM determines resources allocated to the tenants according to the number of the resources required to be increased by the tenants and the number of the idle resources in the resource pool; the VNFM sends a node allocation request to the CaaS Mgr used by the tenant, wherein the node allocation request comprises identification information of resources allocated to the tenant; the VNFM receives first feedback information sent by the CaaS Mgr. The method and the system realize the management function of multiple CaaS tenants in the MANO management system, and meet the isolation of applications of different tenants under the multi-tenant scene.

Description

Tenant resource management method and device under multi-tenant scene

Technical Field

The present application relates to resource virtualization technologies, and in particular, to a tenant resource management method and apparatus in a multi-tenant scenario.

Background

Multi-tenant (multi-tenant) is a common concept in operation and maintenance management in the cloud computing field, and its main purpose is to guarantee isolation of data for each user in an environment where multiple users share a platform or infrastructure. In cloud computing, a tenant generally refers to a customer of a system or platform, and a series of data created and used by the customer, such as accounts, statistics, user data, customized application environments and used computing resources, network resources, storage resources, and the like. Because the system or the platform can serve multiple tenants simultaneously, the service provider needs to ensure that the multiple tenants do not affect each other, and ensure the data security of each tenant, and the data is not acquired by other tenants or even tampered.

The Service provider may use different technologies to cut application program environments and data of tenants, including a Container as a Service (CaaS) technology, where a Container (Container) is an operating system-level virtualization technology, and generally adopts a Virtual Machine (VM) Container manner, that is, a virtual Machine is deployed first, and then a Container is deployed on the virtual Machine, so that isolation between different Container applications is achieved through the virtual Machine, and security is guaranteed.

However, if the virtual machine is used as a resource pool to be shared between different containers, the purpose of implementing isolation between different container applications through the virtual machine in a multi-tenant scenario cannot be met, and isolation and security of tenants cannot be ensured. .

Disclosure of Invention

The application provides a tenant resource management method and device under a multi-tenant scene, so that the management function of multiple CaaS tenants in an MANO management system is realized, and the application isolation of different tenants under the multi-tenant scene is met.

In a first aspect, the present application provides a tenant resource management method in a multi-tenant scenario, where an execution subject of the method is a VNFM, and the method includes: the VNFM receives a tenant resource adding request sent by the NFVO, wherein the tenant resource adding request comprises the number of resources required to be added by the tenant; the VNFM determines resources allocated to the tenant according to the number of the resources requested to be added by the tenant and the number of free resources in a resource pool; the VNFM sends a node allocation request to a CaaS Mgr used by the tenant, wherein the node allocation request comprises identification information of the resource allocated to the tenant; and the VNFM receives first feedback information sent by the CaaS Mgr.

In a possible implementation manner, after the VNFM receives the first feedback information sent by the CaaS Mgr, the method further includes: the VNFM updates the resource record information of the tenant according to the first feedback information; or, the VNFM transparently transmits the first feedback information to the NFVO.

In a possible implementation manner, after the VNFM receives a tenant resource addition request sent by the NFVO, the method further includes: the VNFM determines whether new resources need to be created or not according to the number of resources required to be added by the tenant and the number of free resources in the resource pool; if a new virtual machine needs to be created, the VNFM sends a resource creation request to the VIM; the VNFM receives second feedback information sent by the VIM, wherein the second feedback information comprises identification information of resources newly created by the VIM; the VNFM includes the newly created resource in the resource pool.

In a possible implementation manner, the tenant resource addition request further includes identification information of the tenant; the node allocation request further includes identification information of the tenant.

In a possible implementation manner, before the VNFM receives the tenant resource addition request sent by the NFVO, the method further includes: the VNFM receives a tenant creating request sent by the NFVO, wherein the tenant creating request comprises identity information of the tenant; the VNFM creates resource record information of the tenant, the resource record information of the tenant including identity information of the tenant.

In a possible implementation manner, the tenant resource addition request further includes identification information of the tenant; after the VNFM receives the tenant resource addition request sent by the NFVO, the method further includes: and the VNFM determines CaaS Mgr used by the tenant according to the identification information of the tenant.

In a possible implementation manner, before the VNFM receives the tenant resource addition request sent by the NFVO, the method further includes: the VNFM receives a tenant creating request sent by the NFVO, wherein the tenant creating request comprises identity information of the tenant and identification information of CaaS Mgr used by the tenant; the VNFM establishes resource record information of the tenant, and the resource record information of the tenant comprises identity information of the tenant and identification information of CaaS Mgr used by the tenant.

In a possible implementation manner, after the VNFM receives the tenant creation request sent by the NFVO, the method further includes: the VNFM is communicated with the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant to determine whether the CaaS Mgr is available; the VNFM creates resource record information of the tenant, including: and if the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant is available, the VNFM creates the resource record information of the tenant.

In this embodiment, a multi-tenant concept is introduced into the MANO management system and the CaaS Mgr platform, a resource pool is managed and divided according to tenants, and tenants are created and tenant resources are added by adding a tenant management interface, so that the management function of the multi-CaaS tenants in the MANO management system is realized, and the application isolation of different tenants in a multi-tenant scene is satisfied.

In a second aspect, the present application provides a tenant resource management method in a multi-tenant scenario, including: the VNFM receives a tenant resource release request sent by the NFVO, wherein the tenant resource release request comprises the quantity of resources requested to be released; the VNFM determines resources to be released according to the quantity of the resources requested to be released; the VNFM sends a node release request to a CaaS Mgr used by the tenant, wherein the node release request comprises identification information of the resource to be released; and the VNFM receives third feedback information sent by the CaaS Mgr.

In a possible implementation manner, after the VNFM receives the third feedback information sent by the CaaS Mgr, the method further includes: the VNFM updates the resource record information of the tenant according to the third feedback information; or, the VNFM transparently transmits the third feedback information to the NFVO.

In a possible implementation manner, the tenant resource release request further includes identification information of the tenant; the node release request further includes identification information of the tenant.

In a possible implementation manner, the tenant resource release request further includes identification information of the tenant; after the VNFM receives the tenant resource release request sent by the NFVO, the method further includes: and the VNFM determines CaaS Mgr used by the tenant according to the identification information of the tenant.

In a possible implementation manner, after the VNFM receives the third feedback information sent by the CaaS Mgr, the method further includes: the VNFM receives a tenant deleting request sent by the NFVO, wherein the tenant deleting request comprises identification information of the tenant; the VNFM determines whether the resources of the tenant are completely released according to the resource record information of the tenant; and if the resources of the tenant are completely released, the VNFM deletes the resource record information of the tenant.

In this embodiment, a multi-tenant concept is introduced into the MANO management system and the CaaS Mgr platform, a resource pool is managed and divided according to tenants, and tenant resources are released and tenants are deleted by adding a tenant management interface, so that the management function of multi-CaaS tenants in the MANO management system is realized, and the application isolation of different tenants in a multi-tenant scene is satisfied.

In a third aspect, the present application provides a tenant resource management method in a multi-tenant scenario, where an execution subject of the method is CaaS Mgr, and the method includes: receiving a node allocation request sent by a VNFM, wherein the node allocation request comprises identification information of resources allocated to tenants; allocating the resources allocated to the tenants; sending first feedback information to the VNFM.

In one possible implementation, the node allocation request further includes identification information of the tenant.

In a fourth aspect, the present application provides a tenant resource management method in a multi-tenant scenario, where an execution subject of the method is CaaS Mgr, and the method includes: receiving a node release request sent by a VNFM, wherein the node release request comprises identification information of the resource to be released; releasing the resource to be released back to a resource pool; sending third feedback information to the VNFM.

In a possible implementation manner, the node release request further includes identification information of the tenant.

In a possible implementation manner, before releasing the resource to be released back to the resource pool, the method further includes: judging whether the resources to be released bear the services of other tenants or not; if the resources to be released bear the services of other tenants, migrating the services of the other tenants to other resources; the releasing the resource to be released back to the resource pool comprises: and releasing the resources to be released back to the resource pool after the resources to be released are idle.

In a fifth aspect, the present application provides a tenant resource management method in a multi-tenant scenario, where an execution subject of the method is NFVO, and the method includes: receiving a tenant creating request sent by an OSS, wherein the tenant creating request comprises the name of the tenant; creating resource record information of the tenant, wherein the resource record information of the tenant comprises the name of the tenant.

In a possible implementation manner, the tenant creation request further includes identification information of a CaaS Mgr used by the tenant; the resource record information of the tenant also comprises the identification information of the CaaS Mgr used by the tenant.

In a sixth aspect, the present application provides a tenant resource management method in a multi-tenant scenario, where an execution subject of the method is NFVO, and the method includes: receiving a tenant deleting request sent by an OSS, wherein the tenant deleting request comprises identification information of the tenant; determining whether resources of the tenant are completely released according to the resource record information of the tenant; and if the resources of the tenant are completely released, deleting the resource record information of the tenant.

In a seventh aspect, the present application provides a VNFM, comprising: the system comprises a receiving module, a sending module and a processing module, wherein the receiving module is used for receiving a tenant resource increasing request sent by NFVO, and the tenant resource increasing request comprises the number of resources required to be increased by a tenant; the processing module is used for determining resources allocated to the tenant according to the number of the resources requested to be added by the tenant and the number of the idle resources in the resource pool; a sending module, configured to send a node allocation request to the CaaS Mgr used by the tenant, where the node allocation request includes identification information of the resource allocated to the tenant; the receiving module is further configured to receive first feedback information sent by the caaS Mgr.

In a possible implementation manner, the processing module is further configured to update resource record information of the tenant according to the first feedback information; or, the sending module is further configured to transparently transmit the first feedback information to the NFVO.

In a possible implementation manner, the processing module is further configured to determine whether a new resource needs to be created according to the number of resources requested to be added by the tenant and the number of free resources in the resource pool; if a new virtual machine needs to be created, the sending module is further configured to send a resource creation request to the VIM; the receiving module is further configured to receive second feedback information sent by the VIM, where the second feedback information includes identification information of a resource newly created by the VIM; the processing module is further configured to incorporate the newly created resource into the resource pool.

In a possible implementation manner, the receiving module is further configured to receive a tenant creating request sent by the NFVO, where the tenant creating request includes identity information of the tenant; the processing module is further configured to create resource record information of the tenant, where the resource record information of the tenant includes identity information of the tenant.

In a possible implementation manner, the tenant resource addition request further includes identification information of the tenant; the processing module is further configured to determine, according to the identification information of the tenant, the CaaS Mgr used by the tenant.

In a possible implementation manner, the receiving module is further configured to receive a tenant creating request sent by the NFVO, where the tenant creating request includes identity information of the tenant and identification information of CaaS Mgr used by the tenant; the processing module is further configured to create resource record information of the tenant, where the resource record information of the tenant includes identity information of the tenant and identification information of the CaaS Mgr used by the tenant.

In a possible implementation manner, the processing module is further configured to communicate with the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant to determine whether the CaaS Mgr is available; and if the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant is available, creating resource record information of the tenant.

In a possible implementation manner, the receiving module is further configured to receive a tenant resource release request sent by a network function virtualization orchestrator NFVO, where the tenant resource release request includes a quantity of resources requested to be released; the processing module is further configured to determine resources to be released according to the quantity of the resources requested to be released; the sending module is further configured to send a node release request to a container as a service manager, CaaS Mgr, used by the tenant, where the node release request includes identification information of the resource to be released; the receiving module is further configured to receive third feedback information sent by the caaS Mgr.

In a possible implementation manner, the processing module is further configured to update resource record information of the tenant according to the third feedback information; or, the sending module is further configured to transparently transmit the third feedback information to the NFVO.

In a possible implementation manner, the tenant resource release request further includes identification information of the tenant; the processing module is further configured to determine, according to the identification information of the tenant, the CaaS Mgr used by the tenant.

In a possible implementation manner, the receiving module is further configured to receive a tenant deleting request sent by the NFVO, where the tenant deleting request includes identification information of the tenant; the processing module is further configured to determine whether resources of the tenant have been completely released according to the resource record information of the tenant; and if the resources of the tenant are completely released, deleting the resource record information of the tenant.

In an eighth aspect, the present application provides a CaaS Mgr, comprising: a receiving module, configured to receive a node allocation request sent by a VNFM, where the node allocation request includes identification information of a resource allocated to a tenant; the processing module is used for allocating the resources allocated to the tenants; a sending module, configured to send first feedback information to the VNFM.

In a possible implementation manner, the receiving module is further configured to receive a node release request sent by a VNFM, where the node release request includes identification information of the resource to be released; the processing module is further configured to release the resource to be released back to a resource pool; the sending module is further configured to send third feedback information to the VNFM.

In a possible implementation manner, the processing module is further configured to determine whether the resource to be released carries services of other tenants; if the resources to be released bear the services of other tenants, migrating the services of the other tenants to other resources; and releasing the resources to be released back to the resource pool after the resources to be released are idle.

In a ninth aspect, the present application provides an NFVO, comprising: the system comprises a receiving module, a sending module and a processing module, wherein the receiving module is used for receiving a tenant creating request sent by an OSS, and the tenant creating request comprises the name of the tenant; and the processing module is used for creating the resource record information of the tenant, and the resource record information of the tenant comprises the name of the tenant.

In a possible implementation manner, the receiving module is further configured to receive a tenant deleting request sent by an OSS, where the tenant deleting request includes identification information of the tenant; the processing module is further configured to determine whether resources of the tenant have been completely released according to the resource record information of the tenant; and if the resources of the tenant are completely released, deleting the resource record information of the tenant.

In a tenth aspect, the present application provides a tenant resource management method in a multi-tenant scenario, including: the NFVO sends a tenant creating request to the VNFM, wherein the tenant creating request comprises identity information of the tenant; the VNFM creates resource record information of the tenant, the resource record information of the tenant including identity information of the tenant. The NFVO sends a tenant resource adding request to the VNFM, wherein the tenant resource adding request comprises the number of resources required to be added by the tenant; the VNFM determines resources allocated to the tenants according to the number of the resources required to be increased by the tenants and the number of the idle resources in the resource pool; the VNFM sends a node allocation request to the CaaS Mgr used by the tenant, wherein the node allocation request comprises identification information of resources allocated to the tenant; the CaaS Mgr allocates resources allocated to the tenants; the CaaS Mgr sends first feedback information to the VNFM; and the VNFM updates the resource record information of the tenant according to the first feedback information, and adds the resource allocated to the tenant into the resource record information of the tenant.

In this embodiment, a multi-tenant concept is introduced into the MANO management system and the CaaS Mgr platform, a resource pool is managed and divided according to tenants, tenant record information is created and maintained by the VNFM by adding a tenant management interface, and tenant resources are added, so that a management function of multiple CaaS tenants in the MANO management system is realized, and application isolation of different tenants in a multi-tenant scenario is satisfied.

In an eleventh aspect, the present application provides a tenant resource management method in a multi-tenant scenario, including: the NFVO creates resource record information of the tenant according to a tenant creating request sent by the OSS, wherein the resource record information of the tenant comprises identity information of the tenant. The NFVO sends a tenant resource adding request to the VNFM, wherein the tenant resource adding request comprises the number of resources required to be added by the tenant; the VNFM determines resources allocated to the tenants according to the number of the resources required to be increased by the tenants and the number of the idle resources in the resource pool; the VNFM sends a node allocation request to the CaaS Mgr used by the tenant, wherein the node allocation request comprises identification information of resources allocated to the tenant; the CaaS Mgr allocates resources allocated to the tenants; the CaaS Mgr sends first feedback information to the VNFM; the VNFM sends first feedback information to the NFVO; and the NFVO updates the resource record information of the tenant according to the first feedback information, and adds the resource allocated to the tenant into the resource record information of the tenant.

In this embodiment, a multi-tenant concept is introduced into an MANO management system and a CaaS Mgr platform, a resource pool is managed and divided according to tenants, tenant record information is created and maintained by NFVO by adding a tenant management interface, tenant resources are added by VNFM, a management function of multiple CaaS tenants in the MANO management system is realized, and application isolation of different tenants in a multi-tenant scenario is satisfied.

In a twelfth aspect, the present application provides a tenant resource management system in a multi-tenant scenario, where the system includes: VNFM according to any one of the seventh aspects, CaaS Mgr according to any one of the eighth aspects, and NFVO according to any one of the ninth aspects. The NFVO provides a tenant management interface to the outside, and the NFVO can be connected with the OSS through the tenant management interface to realize functions of creating/deleting tenants, adding/deleting/inquiring tenant resources and the like. And according to the positioning of the VNFM, namely if the VNFM manages CaaS tenants, the NFVO transparently transmits all tenant management related requests to the VNFM through the tenant management interface, and if the VNFM does not manage the CaaS tenants and only executes related resource management, the NFVO sends tenant resource adding/deleting/inquiring requests to the VNFM through the tenant management interface. A node management interface is provided between the VNFM and the CaaS Mgr, and is used to manage a newly added resource into the CaaS Mgr or request the CaaS Mgr to delete information of a resource to be deleted before and after a related resource management operation is performed (for example, a virtual machine is created/deleted). Based on the tenant resource management system under the multi-tenant scene provided by the application, the tenant resource management method comprises two conditions: the first is that different tenants share the CaaS Mgr, for example, the entire MANO management system uses a common CaaS Mgr, different network elements represent different tenants, all network elements share the same CaaS Mgr, and isolation between tenants is achieved through different network elements. In this case, the VNFM needs to carry identification information (for example, tenant ID) of the tenant in communication with the CaaS Mgr, and is used to notify the CaaS Mgr to perform container management according to the tenant. The second method is that different tenants use different CaaS Mgr, for example, vendors represent tenants, and network elements of each vendor only use CaaS Mgr provided by the vendor, and isolation between tenants is achieved through different CaaS Mgr. In this case, the VNFM identifies the corresponding CaaS Mgr according to the identification information of the tenant, and there is no need to additionally provide the identification information of the tenant in communication with the CaaS Mgr.

In this embodiment, a multi-tenant concept is introduced into an MANO management system and a CaaS Mgr platform, a resource pool is managed and divided according to tenants, and by adding a tenant management interface, a tenant is created and added or released and deleted, so that the management function of the multi-CaaS tenant in the MANO management system is realized, and the isolation of applications of different tenants in a multi-tenant scene is satisfied.

In a thirteenth aspect, the present application provides a virtual network element device, including:

one or more processors;

a memory for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method as in any one of the first to sixth aspects above.

In a fourteenth aspect, the present application provides a computer readable storage medium having stored thereon instructions for performing the method of any of the first to sixth aspects described above, when the instructions are run on a computer.

In a fifteenth aspect, the present application provides a computer program for performing the method of any one of the first to sixth aspects above when the computer program is executed by a computer.

In a sixteenth aspect, the present application provides a chip comprising a processor and a memory, the memory being configured to store a computer program, the processor being configured to call and run the computer program stored in the memory to perform the method according to any one of the first to sixth aspects.

Drawings

Fig. 1 illustrates an application scenario to which the tenant resource management method in a multi-tenant scenario provided in the present application is applicable;

FIG. 2 is a flowchart of a first embodiment of a tenant resource management method in a multi-tenant scenario of the present application;

FIG. 3 is a flowchart of a second embodiment of a tenant resource management method in a multi-tenant scenario of the present application;

FIG. 4 is a flowchart of a third embodiment of a tenant resource management method in a multi-tenant scenario of the present application;

FIG. 5 is a flowchart of a fourth embodiment of a tenant resource management method in a multi-tenant scenario of the present application;

fig. 6 is a schematic structural diagram of an embodiment of a virtual network element node according to the present application;

fig. 7 is a schematic structural diagram of an embodiment of a virtual network device according to the present application.

Detailed Description

To make the purpose, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be clearly and completely described below with reference to the drawings in the present application, and it is obvious that the described embodiments are some, but not all embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," and the like in the description examples and claims of this application and in the drawings are used for descriptive purposes only and are not to be construed as indicating or implying relative importance, nor order. Furthermore, the terms "comprises" and "comprising," as well as any variations thereof, are intended to cover a non-exclusive inclusion, such as a list of steps or elements. A method, system, article, or apparatus is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, system, article, or apparatus.

It should be understood that in the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" for describing an association relationship of associated objects, indicating that there may be three relationships, e.g., "a and/or B" may indicate: only A, only B and both A and B are present, wherein A and B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of single item(s) or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.

Fig. 1 illustrates an application scenario applicable to a tenant resource MANagement method in a multi-tenant scenario, where the scenario is a dynamic MANagement and organization (MANO) MANagement system for virtual resources of multiple tenants, and the MANO MANagement system includes a Network Function Virtualization Orchestrator (NFVO), a Virtual Network Function Manager (VNFM), a Virtual Infrastructure Manager (VIM), and a Container as a Service Manager (CaaS Mgr). The NFVO provides a tenant management interface to the outside, and the NFVO may be connected to an Operation Support System (OSS) through the tenant management interface to implement functions of creating/deleting tenants, adding/deleting/querying tenant resources, and the like. And according to the positioning of the VNFM, namely if the VNFM manages CaaS tenants, the NFVO transparently transmits all tenant management related requests to the VNFM through the tenant management interface, and if the VNFM does not manage the CaaS tenants and only executes related resource management, the NFVO sends tenant resource adding/deleting/inquiring requests to the VNFM through the tenant management interface. A node management interface is provided between the VNFM and the CaaS Mgr, and is used to manage a newly added resource into the CaaS Mgr or request the CaaS Mgr to delete information of a resource to be deleted before and after a related resource management operation is performed (for example, a virtual machine is created/deleted).

The tenant resource management method under the multi-tenant scene comprises the following two conditions: the first is that different tenants share the CaaS Mgr, for example, the entire MANO management system uses a common CaaS Mgr, different network elements represent different tenants, all network elements share the same CaaS Mgr, and isolation between tenants is achieved through different network elements. In this case, the VNFM needs to carry identification information (e.g., tenant Identity (ID)) of the tenant in communication with the CaaS Mgr, and is used to notify the CaaS Mgr to perform container management according to the tenant. The second method is that different tenants use different CaaS Mgr, for example, vendors represent tenants, and network elements of each vendor only use CaaS Mgr provided by the vendor, and isolation between tenants is achieved through different CaaS Mgr. In this case, the VNFM identifies the corresponding CaaS Mgr according to the identification information of the tenant, and there is no need to additionally provide the identification information of the tenant in communication with the CaaS Mgr.

Fig. 2 is a flowchart of a first embodiment of a tenant resource management method in a multi-tenant scenario of the present application, and as shown in fig. 2, the method of the present embodiment describes processes of creating a tenant and adding tenant resources, and the method may include:

step 201, the OSS sends a tenant creation request to the NFVO.

The tenant creating request mainly comprises identity information of the tenant, including the name, account number and the like of the tenant, and can also comprise the information of the profile and the like of the tenant as assistance.

Step 202, the NFVO creates resource record information of the tenant.

The resource record information of the tenant includes identity information of the tenant and identification information (tenant ID) created for the tenant, for example, NFVO may record the resource record information of the tenant in a form of a list, each tenant corresponds to an entry, the entry includes the ID of the tenant and the identity information of the tenant, and the entry corresponds to the second case and further includes identification information of CaaS Mgr used by the tenant. In this embodiment, the VNFM is not responsible for managing CaaS tenants, and only performs related resource management, so that resource record information of the tenants is created and maintained by the NFVO.

Optionally, if the VNFM is responsible for managing the CaaS tenant, the NFVO may pass the tenant creation request through to the VNFM, and the VNFM creates resource record information of the tenant.

Step 203, the NFVO feeds back the tenant creation response to the OSS.

And after the NFVO creates the resource record information of the tenant, feeding back a creation response to the OSS, namely notifying the OSS that the creation of the tenant is successful.

Optionally, if the VNFM is responsible for managing the CaaS tenant, the VNFM sends a tenant creation response to the NFVO after creating resource record information of the tenant, and then the NFVO feeds back the tenant creation response to the OSS.

And step 204, the OSS sends a tenant resource increasing request to the NFVO.

The tenant resource addition request includes identification information (e.g., tenant ID or tenant name) of the tenant requesting addition of the resource and the number of resources requested to be added. The OSS may obtain, according to a request of a tenant, a resource quantity required by the tenant, for example, a virtual machine or bare machine quantity, so that when the OSS requests the NFVO to add a resource, the OSS not only provides identification information of the tenant that requested the resource quantity, but also carries the resource quantity requested by the tenant to be added.

Step 205, the NFVO passes the tenant resource addition request through to the VNFM.

The resource management of the tenant is realized by interaction and coordination of the VNFM and the CaaS Mgr, so that the NFVO transmits the tenant resource increasing request to the VNFM.

Step 206, VNFM determines resources allocated to tenant.

The system brings all the idle resources into a resource pool, which is a list of the idle resources, wherein the identification information, the resource specification and the like of the idle resources are recorded. When resources are allocated to tenants (namely network element deployment), the VNFM selects from the resource pool according to the number of resources requested to be added by the tenants and the number of free resources in the resource pool, and if the number of free resources in the resource pool is enough, the VNFM does not need to specially apply for new resources from a Virtualized Infrastructure Manager (VIM).

Alternatively, if the amount of free resources in the resource pool is not enough, the VNFM needs to apply for new resources to the VIM (step in the dashed box in the figure). In this embodiment, if a new resource needs to be applied, the VNFM sends a resource creation request to the VIM according to a specification of a resource in the resource pool (the data may be preconfigured in the VNFM, or obtained from a specific Virtualized Network Function Descriptor (VNFD)), and after creation of the VIM is completed, second feedback information is fed back to the VNFM, where the information carries identification information of the newly created resource, and the VNFM brings the newly created resource into the resource pool, that is, adds information of the newly created resource into a list of free resources, and prepares for subsequent allocation and use.

And step 207, sending a node distribution request to the CaaS Mgr by the VNFM.

After the VNFM determines the resources allocated to the tenants, a node allocation request is sent to the CaaS Mgr, and the node allocation request carries identification information of the resources allocated to the tenants. The embodiment corresponds to the first case, that is, different tenants share the CaaS Mgr, and the VNFM needs to carry identification information of the tenant in the node allocation request, so that the CaaS Mgr identifies which tenant is allocated with the resource. The embodiment corresponds to the second case, that is, different tenants use different CaaS Mgr, and because the tenants and the CaaS Mgr used by the tenants have a corresponding relationship, the VNFM does not need to carry identification information of the tenants in the node allocation request.

And step 208, the CaaS Mgr manages the distributed resources.

For example, for K8S, the CaaS Mgr adds a resource (e.g., a virtual machine or a bare machine) corresponding to the identification information of the resource through its node management function, and adds a label of "tenant-ID" to the resource by using a label (label) mechanism, so as to identify the tenant to which the resource has been assigned by the tenant ID.

And step 209, the CaaS Mgr sends first feedback information to the VNFM.

After the CaaS Mgr finishes the operation, the result of the processing is fed back to the VNFM, and the VNFM resource allocation is notified to be finished.

Step 210, the VNFM transmits the first feedback information to the NFVO.

In this embodiment, the NFVO is responsible for managing the CaaS tenant, so the VNFM transmits the first feedback information to the NFVO and notifies the NFVO of completion of resource allocation.

And step 211, the NFVO adds identification information of resources allocated to the tenant in the resource record information of the tenant according to the first feedback information.

And the NFVO updates the resource record information of the locally stored tenant after receiving the feedback, and increases the identification information of the resource allocated to the tenant or increases the quantity of the resource allocated to the tenant.

When a subsequent MANO management system has a need to deploy a container network element, the VNFM needs to carry identification information (e.g., a tenant ID or a tenant name) of a tenant when sending a container management request to the CaaS Mgr, where the identification information of the tenant may be obtained from a network element deployment request received by the VNFM, or the VNFM determines the identity of the tenant according to related information to generate the identity of the tenant by itself, for example, determines the identity of the tenant according to a network element provider, a network element type/ID, and the like.

Fig. 3 is a flowchart of a second embodiment of a tenant resource management method in a multi-tenant scenario, and as shown in fig. 3, the method of this embodiment describes a process of deleting a tenant and releasing tenant resources, and the method may include:

step 301, the OSS sends a tenant resource release request to the NFVO.

The tenant resource release request includes identification information (e.g., tenant ID or tenant name) of the tenant requesting release of the resource and the number of resources requested to be released.

Step 302, the NFVO passes the tenant resource release request through to the VNFM.

The resource management of the tenant is realized by interaction and coordination of the VNFM and the CaaS Mgr, so that the NFVO transmits the tenant resource release request to the VNFM.

Step 303, the VNFM determines the resources to be released.

The VNFM selects the resources to be released according to the amount of resources to be released.

And step 304, sending a node release request to the CaaS Mgr by the VNFM.

After the VNFM determines the resources to be released, a node release request is sent to the CaaS Mgr, and the node allocation request carries identification information of the resources to be released. The embodiment corresponds to the first case, that is, different tenants share the CaaS Mgr, and the VNFM needs to carry identification information of the tenant in the node allocation request, so that the CaaS Mgr identifies which tenant is allocated with the resource. The embodiment corresponds to the second case, that is, different tenants use different CaaS Mgr, and because the tenants and the CaaS Mgr used by the tenants have a corresponding relationship, the VNFM does not need to carry identification information of the tenants in the node allocation request.

And 305, managing the released resources by the CaaS Mgr.

The CaaS Mgr releases the corresponding resource according to the identification information of the tenant and the identification information of the resource in the node release request, for example, for K8S, the CaaS Mgr releases the resource (for example, a virtual machine or a bare machine) corresponding to the identification information of the resource through the node management function, and deletes the label (label) of the resource. If there are still running container instances on the selected resource, the CaaS Mgr needs to deploy the container instances on other resources until there are no running container instances on the resource, at which point the CaaS Mgr releases the selected resource back to the resource pool.

And step 306, the CaaS Mgr sends third feedback information to the VNFM.

After the CaaS Mgr finishes the operation, the CaaS Mgr feeds back a processing result to the VNFM, namely, notifies the VNFM that the release of the resources is finished.

And 307, deleting the identification information of the resource to be released in the resource record information of the tenant by the VNFM according to the third feedback information.

And after receiving the feedback, the VNFM updates the resource record information of the tenants stored locally, deletes the identification information of the released resources in the resource record information, or deletes the quantity of the resources to be released.

Step 308, the OSS sends a tenant delete request to the NFVO.

The tenant deletion request includes identification information of the tenant (e.g., a tenant ID or a tenant name).

Step 309, the NFVO passes the tenant delete request through to the VNFM.

In this embodiment, the VNFM is responsible for managing CaaS tenants, and resource record information of the tenants is created and maintained by the VNFM, so the NFVO passes through tenant deletion requests to the VNFM.

And step 310, the VNFM determines whether the resources of the tenant are all released according to the resource record information of the tenant.

The VNFM judges whether all resources of the tenant are released or not, and the tenant can be deleted only if the tenant does not occupy any resources.

Step 311, if the resources of the tenant are all released, the VNFM deletes the resource record information of the tenant.

And after the VNFM determines that all resources of the tenant are released, deleting the locally stored resource record information of the tenant.

And step 312, the VNFM transmits the tenant deletion response to the NFVO in a transparent manner.

After the VNFM deletes the resource record information of the tenant, the VNFM transparently transmits a tenant deletion response to the NFVO, namely, the NFVO notifies the OSS that the tenant is successfully deleted. If the VNFM fails to delete the tenant, for example, the resources of the tenant are not completely released, the VNFM notifies the OSS that the tenant fails to be deleted through the NFVO.

And step 313, the NFVO feeds back the tenant delete response to the OSS.

Fig. 4 is a flowchart of a third embodiment of a tenant resource management method in a multi-tenant scenario, and as shown in fig. 4, the method in this embodiment describes a process of creating a tenant and adding tenant resources in the second case, where the method may include:

step 401, the OSS sends a tenant creation request to the NFVO.

The tenant creation request mainly includes the name of the tenant, and may also include, as an auxiliary, information such as the profile of the tenant. Since the second case is described in this embodiment, that is, different tenants use different CaaS Mgr, the tenant creation request also carries identification information of the CaaS Mgr used by the tenant, such as a name and an IP address of the CaaS Mgr.

Step 402, the NFVO passes through the tenant create request to the VNFM.

In this embodiment, the VNFM is responsible for managing CaaS tenants, and resource record information of the tenants is created and maintained by the VNFM, so the NFVO passes tenant creation requests to the VNFM.

Step 403, the VNFM creates resource record information of the tenant.

The resource record information of the tenant includes identity information of the tenant, identification information (tenant ID) created for the tenant, and identification information of CaaS Mgr used by the tenant, for example, the VNFM may record resource record information of the tenant in a form of a list, each tenant corresponds to an entry, and the entry includes the ID of the tenant, the identity information of the tenant, and the identification information of CaaS Mgr used by the tenant.

Optionally, before the VNFM creates the resource record information of the tenant, the VNFM communicates with the corresponding CaaS Mgr according to the identification information of the CaaS Mgr, and confirms that the CaaS Mgr is available.

And step 404, transmitting the tenant creating response to the NFVO through the VNFM.

After the VNFM creates resource record information of the tenant, the VNFM transparently transmits a tenant creating response to the NFVO, namely, the NFVO informs the OSS of successful creation of the tenant.

Step 405, the NFVO feeds back the create response to the OSS.

Step 406, the OSS sends a tenant resource addition request to the NFVO.

Step 407, the NFVO passes the tenant resource addition request through to the VNFM.

Step 408, VNFM determines the resources allocated to the tenant.

The system brings all the idle resources into a resource pool, which is a list of the idle resources, wherein the identification information, the resource specification and the like of the idle resources are recorded. When resources are allocated to the tenants (namely network element deployment), the VNFM selects from the resource pool according to the number of resources requested to be increased by the tenants and the number of idle resources in the resource pool, and if the number of the idle resources in the resource pool is enough, the VNFM does not need to specially apply for new resources to the VIM.

And 409, sending a node distribution request to the CaaS Mgr by the VNFM.

After the VNFM determines the resources allocated to the tenants, a node allocation request is sent to the corresponding CaaS Mgr according to the identification information of the CaaS Mgr in the resource record information of the tenants, and the identification information of the resources allocated to the tenants is carried in the node allocation request. Since the second case is described in this embodiment, that is, different tenants use different CaaS Mgr, the node allocation request does not carry identification information of the tenant.

And step 410, the CaaS Mgr manages the distributed resources.

And the CaaS Mgr manages the corresponding resources according to the identification information of the resources in the node allocation request.

And 411, sending the first feedback information to the VNFM by the CaaS Mgr.

And step 412, the VNFM adds identification information of the resource allocated to the tenant in the resource record information of the tenant according to the first feedback information.

In this embodiment, the VNFM is responsible for managing the CaaS tenant, and after receiving the feedback, the VNFM updates the resource record information of the locally stored tenant, and adds the identification information of the resource allocated to the tenant, or increases the number of the resources allocated to the tenant.

Fig. 5 is a flowchart of a fourth embodiment of the tenant resource management method in the multi-tenant scenario, and as shown in fig. 5, the method in this embodiment describes a process of deleting a tenant and releasing tenant resources in the first case, where the method may include:

step 501, the OSS sends a tenant resource release request to the NFVO.

The tenant resource release request includes identification information (e.g., tenant ID or tenant name) of the tenant requesting release of the resource and the number of resources requested to be released. Since the second case is described in this embodiment, that is, different tenants use different CaaS Mgr, the tenant resource release request also carries identification information of the CaaS Mgr used by the tenant, such as a name and an IP address of the CaaS Mgr.

Step 502, the NFVO passes the tenant resource release request through to the VNFM.

Step 503, VNFM determines the resource to be released.

And step 504, sending a node release request to the CaaS Mgr by the VNFM.

After the VNFM determines the resources to be released, a node release request is sent to the corresponding CaaS Mgr according to the identification information of the CaaS Mgr used by the tenant, and the identification information of the resources to be released is carried in the node allocation request. Since the second case is described in this embodiment, that is, different tenants use different CaaS Mgr, the node allocation request does not carry identification information of the tenant.

And 505, managing the released resources by the CaaS Mgr.

The CaaS Mgr releases the corresponding resource according to the identification information of the resource in the node release request, for example, for K8S, the CaaS Mgr releases the resource (for example, a virtual machine or a bare machine) corresponding to the identification information of the resource through the node management function. If there are still running container instances on the selected resource, the CaaS Mgr needs to deploy the container instances on other resources until there are no running container instances on the resource, at which point the CaaS Mgr releases the selected resource back to the resource pool.

And step 506, the CaaS Mgr sends third feedback information to the VNFM.

And 507, deleting the identification information of the resource to be released in the resource record information of the tenant by the VNFM according to the third feedback information.

Step 508, the OSS sends a tenant delete request to the NFVO.

Step 509, the NFVO passes the tenant delete request through to the VNFM.

And step 510, the VNFM determines whether the resources of the tenant are all released according to the resource record information of the tenant.

Step 511, if the resources of the tenant are all released, the VNFM deletes the resource record information of the tenant.

And step 512, transmitting the tenant deletion response to the NFVO through the VNFM.

Step 513, the NFVO feeds back the tenant delete response to the OSS.

Fig. 6 is a schematic structural diagram of an embodiment of a virtual network element node in the present application, and as shown in fig. 6, the apparatus in this embodiment may include: a receiving module 601, a processing module 602, and a sending module 603, the apparatus of this embodiment may be a VNFM in the scenario shown in fig. 1, may also be a CaaS Mgr, and may also be an NFVO.

Corresponding to the VNFM, a receiving module 601, configured to receive a tenant resource addition request sent by the NFVO, where the tenant resource addition request includes a number of resources that the tenant requests to add; a processing module 602, configured to determine, according to the number of resources requested to be added by the tenant and the number of idle resources in the resource pool, resources allocated to the tenant; a sending module 603, configured to send a node allocation request to the CaaS Mgr used by the tenant, where the node allocation request includes identification information of the resource allocated to the tenant; the receiving module 601 is further configured to receive first feedback information sent by the CaaS Mgr.

In a possible implementation manner, the processing module 602 is further configured to update resource record information of the tenant according to the first feedback information; or, the sending module 603 is further configured to transparently transmit the first feedback information to the NFVO.

In a possible implementation manner, the processing module 602 is further configured to determine whether a new resource needs to be created according to the number of resources requested to be added by the tenant and the number of free resources in the resource pool; if a new virtual machine needs to be created, the sending module 603 is further configured to send a resource creation request to the VIM; the receiving module 601 is further configured to receive second feedback information sent by the VIM, where the second feedback information includes identification information of a resource newly created by the VIM; the processing module 602 is further configured to include the newly created resource in the resource pool.

In a possible implementation manner, the receiving module 601 is further configured to receive a tenant creating request sent by the NFVO, where the tenant creating request includes identity information of the tenant; the processing module 602 is further configured to create resource record information of the tenant, where the resource record information of the tenant includes identity information of the tenant.

In a possible implementation manner, the tenant resource addition request further includes identification information of the tenant; the processing module 602 is further configured to determine, according to the identification information of the tenant, CaaS Mgr used by the tenant.

In a possible implementation manner, the receiving module 601 is further configured to receive a tenant creating request sent by the NFVO, where the tenant creating request includes identity information of the tenant and identification information of CaaS Mgr used by the tenant; the processing module 602 is further configured to create resource record information of the tenant, where the resource record information of the tenant includes identity information of the tenant and identification information of the CaaS Mgr used by the tenant.

In a possible implementation manner, the processing module 602 is further configured to communicate with the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant to determine whether the CaaS Mgr is available; and if the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant is available, creating resource record information of the tenant.

In a possible implementation manner, the receiving module 601 is further configured to receive a tenant resource release request sent by a network function virtualization orchestrator NFVO, where the tenant resource release request includes a quantity of resources requested to be released; the processing module 602 is further configured to determine resources to be released according to the quantity of the resources requested to be released; the sending module 603 is further configured to send a node release request to a container as a service manager, CaaS Mgr, used by the tenant, where the node release request includes identification information of the resource to be released; the receiving module 601 is further configured to receive third feedback information sent by the CaaS Mgr.

In a possible implementation manner, the processing module 602 is further configured to update resource record information of the tenant according to the third feedback information; or, the sending module 603 is further configured to transparently transmit the third feedback information to the NFVO.

In a possible implementation manner, the tenant resource release request further includes identification information of the tenant; the processing module 602 is further configured to determine, according to the identification information of the tenant, CaaS Mgr used by the tenant.

In a possible implementation manner, the receiving module 601 is further configured to receive a tenant deleting request sent by the NFVO, where the tenant deleting request includes identification information of the tenant; the processing module 602 is further configured to determine whether resources of the tenant have been completely released according to the resource record information of the tenant; and if the resources of the tenant are completely released, deleting the resource record information of the tenant.

Corresponding to the CaaS Mgr, the receiving module 601 is configured to receive a node allocation request sent by the VNFM, where the node allocation request includes identification information of a resource allocated to a tenant; a processing module 602, configured to allocate the resource allocated to the tenant; a sending module 603, configured to send the first feedback information to the VNFM.

In a possible implementation manner, the receiving module 601 is further configured to receive a node release request sent by a VNFM, where the node release request includes identification information of the resource to be released; the processing module 602 is further configured to release the resource to be released back to a resource pool; the sending module 603 is further configured to send third feedback information to the VNFM.

In a possible implementation manner, the processing module 602 is further configured to determine whether the resource to be released carries services of other tenants; if the resources to be released bear the services of other tenants, migrating the services of the other tenants to other resources; and releasing the resources to be released back to the resource pool after the resources to be released are idle.

Corresponding to NFVO, the receiving module 601 is configured to receive a tenant creating request sent by an OSS, where the tenant creating request includes a name of the tenant; a processing module 602, configured to create resource record information of the tenant, where the resource record information of the tenant includes a name of the tenant.

In a possible implementation manner, the receiving module 601 is further configured to receive a tenant deleting request sent by an OSS, where the tenant deleting request includes identification information of the tenant; the processing module 602 is further configured to determine whether resources of the tenant have been completely released according to the resource record information of the tenant; and if the resources of the tenant are completely released, deleting the resource record information of the tenant.

The apparatus of this embodiment may be used to implement the technical solution of any one of the method embodiments shown in fig. 2 to 5, and the implementation principle and the technical effect are similar, which are not described herein again.

Fig. 7 is a schematic structural diagram of an embodiment of a virtual network device according to the present application, and as shown in fig. 7, the virtual network device includes a processor 701, a memory 702, an input device 703 and an output device 704; the number of the processors 701 in the virtual network device may be one or more, and one processor 701 is taken as an example in fig. 7; the processor 701, the memory 702, the input device 703 and the output device 704 in the virtual network apparatus may be connected by a bus or other means, and fig. 7 illustrates an example of connection by a bus.

Memory 702 serves as a computer-readable storage medium that may be used to store software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the methods of the embodiments illustrated in fig. 2-5 of the present application. The processor 701 executes various functional applications and data processing of the virtual network device by running software programs, instructions and modules stored in the memory 702, that is, implements the tenant resource management method in the multi-tenant scenario described above.

The memory 702 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the terminal, and the like. Further, the memory 702 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, memory 702 may further include memory located remotely from processor 701, which may be connected to a virtual network appliance over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input device 703 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the virtual network apparatus. The output device 704 may include a display device such as a display screen.

In one possible implementation, the present application provides a computer-readable storage medium storing instructions for performing the method in the embodiments of fig. 2-5 described above when the instructions are executed on a computer.

In one possible implementation, the present application provides a computer program for performing the method in the embodiments of fig. 2-5 described above when the computer program is executed by a computer.

In one possible implementation, the present application provides a chip including a processor and a memory, where the memory is used to store a computer program, and the processor is used to call and execute the computer program stored in the memory to execute the method in the embodiment shown in fig. 2 to 5.

Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A tenant resource management method under a multi-tenant scene is characterized in that the method realizes isolation between tenants through different network elements or isolation between tenants through different CaaS Mgrs, and the method comprises the following steps:

a Virtual Network Function Manager (VNFM) receives a tenant resource increasing request sent by a Network Function Virtualization Orchestrator (NFVO), wherein the tenant resource increasing request comprises the number of resources required to be increased by a tenant;

the VNFM determines resources allocated to the tenant according to the number of the resources requested to be added by the tenant and the number of free resources in a resource pool;

the VNFM sends a node allocation request to a container as a service manager (CaaS) Mgr used by the tenant, wherein the node allocation request comprises identification information of the resource allocated to the tenant;

the VNFM receives first feedback information sent by the CaaS Mgr;

when isolation between tenants is achieved through different network elements, the VNFM further sends identification information of the tenants to the CaaS Mgr.

2. The method of claim 1, wherein after the VNFM receives first feedback information sent by the CaaS Mgr, the method further comprises:

the VNFM updates the resource record information of the tenant according to the first feedback information; alternatively, the first and second electrodes may be,

and the VNFM transparently transmits the first feedback information to the NFVO.

3. The method according to claim 1 or 2, wherein after the VNFM receives the tenant resource addition request sent by NFVO, the method further comprises:

the VNFM determines whether new resources need to be created or not according to the number of resources required to be added by the tenant and the number of free resources in the resource pool;

if a new virtual machine needs to be created, the VNFM sends a resource creation request to a Virtual Infrastructure Manager (VIM);

the VNFM receives second feedback information sent by the VIM, wherein the second feedback information comprises identification information of resources newly created by the VIM;

the VNFM includes the newly created resource in the resource pool.

4. The method according to claim 1 or 2, wherein the tenant resource addition request further comprises identification information of the tenant; the node allocation request further includes identification information of the tenant.

5. The method of claim 4, wherein before the VNFM receives a tenant resource addition request sent by NFVO, the method further comprises:

the VNFM receives a tenant creating request sent by the NFVO, wherein the tenant creating request comprises identity information of the tenant;

the VNFM creates resource record information of the tenant, the resource record information of the tenant including identity information of the tenant.

6. The method according to claim 1 or 2, wherein the tenant resource addition request further comprises identification information of the tenant; after the VNFM receives the tenant resource addition request sent by the NFVO, the method further includes:

and the VNFM determines CaaS Mgr used by the tenant according to the identification information of the tenant.

7. The method of claim 6, wherein before the VNFM receives the tenant resource addition request sent by the NFVO, the method further comprises:

the VNFM receives a tenant creating request sent by the NFVO, wherein the tenant creating request comprises identity information of the tenant and identification information of CaaS Mgr used by the tenant;

the VNFM establishes resource record information of the tenant, and the resource record information of the tenant comprises identity information of the tenant and identification information of CaaS Mgr used by the tenant.

8. The method of claim 7, wherein after the VNFM receives the tenant create request sent by the NFVO, the method further comprises:

the VNFM is communicated with the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant to determine whether the CaaS Mgr is available;

the VNFM creates resource record information of the tenant, including:

and if the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant is available, the VNFM creates the resource record information of the tenant.

9. A tenant resource management method under a multi-tenant scene is characterized in that the method realizes isolation between tenants through different network elements or isolation between tenants through different CaaS Mgrs, and the method comprises the following steps:

a Virtual Network Function Manager (VNFM) receives a tenant resource release request sent by a Network Function Virtualization Orchestrator (NFVO), wherein the tenant resource release request comprises the quantity of resources requested to be released;

the VNFM determines resources to be released according to the quantity of the resources requested to be released;

the VNFM sends a node release request to a container as a service manager (CaaS Mgr) used by the tenant, wherein the node release request comprises identification information of the resource to be released;

the VNFM receives third feedback information sent by the CaaS Mgr;

10. The method of claim 9, wherein after the VNFM receives third feedback information sent by the CaaS Mgr, the method further comprises:

the VNFM updates the resource record information of the tenant according to the third feedback information; alternatively, the first and second electrodes may be,

and the VNFM transparently transmits the third feedback information to the NFVO.

11. The method according to claim 9 or 10, wherein the tenant resource release request further includes identification information of the tenant; the node release request further includes identification information of the tenant.

12. The method according to claim 9 or 10, wherein the tenant resource release request further includes identification information of the tenant; after the VNFM receives the tenant resource release request sent by the NFVO, the method further includes:

13. The method of claim 11, wherein after the VNFM receives third feedback information sent by the CaaS Mgr, the method further comprises:

the VNFM receives a tenant deleting request sent by the NFVO, wherein the tenant deleting request comprises identification information of the tenant;

the VNFM determines whether the resources of the tenant are completely released according to the resource record information of the tenant;

and if the resources of the tenant are completely released, the VNFM deletes the resource record information of the tenant.

14. The method of claim 12, wherein after the VNFM receives third feedback information sent by the CaaS Mgr, the method further comprises:

15. A virtual network function manager VNFM, wherein isolation between tenants is achieved by different network elements or isolation between tenants is achieved by different CaaS Mgr, the method comprising:

the network function virtualization orchestrator NFVO comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving a tenant resource increasing request sent by the network function virtualization orchestrator NFVO, and the tenant resource increasing request comprises the number of resources required to be increased by a tenant;

the processing module is used for determining resources allocated to the tenant according to the number of the resources requested to be added by the tenant and the number of the idle resources in the resource pool;

a sending module, configured to send a node allocation request to a container as a service manager, CaaS Mgr, used by the tenant, where the node allocation request includes identification information of the resource allocated to the tenant;

the receiving module is further configured to receive first feedback information sent by the CaaS Mgr;

when isolation between tenants is achieved through different network elements, the sending module is further configured to send identification information of the tenants to the CaaS Mgr.

16. The VNFM of claim 15, wherein the processing module is further configured to update the tenant's resource record information based on the first feedback information; alternatively, the first and second electrodes may be,

the sending module is further configured to transparently transmit the first feedback information to the NFVO.

17. The VNFM of claim 15 or 16, wherein the processing module is further configured to determine whether a new resource needs to be created according to the number of resources requested to be added by the tenant and the number of free resources in the resource pool;

if a new virtual machine needs to be created, the sending module is further configured to send a resource creation request to the virtual infrastructure manager VIM;

the receiving module is further configured to receive second feedback information sent by the VIM, where the second feedback information includes identification information of a resource newly created by the VIM;

the processing module is further configured to incorporate the newly created resource into the resource pool.

18. The VNFM of claim 15 or 16, wherein the tenant resource addition request further comprises identification information of the tenant; the node allocation request further includes identification information of the tenant.

19. The VNFM of claim 18, wherein the receiving module is further configured to receive a tenant create request sent by the NFVO, and the tenant create request includes identity information of the tenant;

the processing module is further configured to create resource record information of the tenant, where the resource record information of the tenant includes identity information of the tenant.

20. The VNFM of claim 15 or 16, wherein the tenant resource addition request further comprises identification information of the tenant; the processing module is further configured to determine, according to the identification information of the tenant, the CaaS Mgr used by the tenant.

21. The VNFM of claim 20, wherein the receiving module is further configured to receive a tenant creation request sent by the NFVO, and the tenant creation request includes identity information of the tenant and identification information of CaaS Mgr used by the tenant;

the processing module is further configured to create resource record information of the tenant, where the resource record information of the tenant includes identity information of the tenant and identification information of the CaaS Mgr used by the tenant.

22. The VNFM of claim 21, wherein the processing module is further configured to communicate with a CaaS Mgr identified by the identifying information of the CaaS Mgr used by the tenant to determine whether the CaaS Mgr is available; and if the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant is available, creating resource record information of the tenant.

23. A virtual network element device, comprising:

one or more processors;

a memory for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-14.