WO2020211652A1 - 多租户场景下的租户资源管理方法和装置 - Google Patents

多租户场景下的租户资源管理方法和装置 Download PDF

Info

Publication number
WO2020211652A1
WO2020211652A1 PCT/CN2020/082884 CN2020082884W WO2020211652A1 WO 2020211652 A1 WO2020211652 A1 WO 2020211652A1 CN 2020082884 W CN2020082884 W CN 2020082884W WO 2020211652 A1 WO2020211652 A1 WO 2020211652A1
Authority
WO
WIPO (PCT)
Prior art keywords
tenant
resource
vnfm
caas
mgr
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/CN2020/082884
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
Publication of WO2020211652A1 publication Critical patent/WO2020211652A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources

Definitions

  • This application relates to resource virtualization technology, and in particular to a method and device for tenant resource management in a multi-tenant scenario.
  • Multi-tenant is a commonly used concept in the field of cloud computing operation and maintenance management. Its main purpose is to ensure the isolation of data for each user in an environment where multiple users share a platform or infrastructure.
  • tenants usually refer to customers of the system or platform, as well as a series of data created and used by customers, such as accounts, statistics, user data, customized application environments, computing resources used, and network resources And storage resources. Since the system or platform will serve multiple tenants at the same time, the service provider needs to ensure that multiple tenants will not affect each other, and ensure that the data of each tenant is safe from being acquired or even tampered with by other tenants.
  • Container is a virtualization technology at the operating system level, usually virtual Virtualized Machine (VM) container mode, that is, the virtual machine is deployed first, and then the container is deployed on the virtual machine, and the isolation between different container applications is achieved through the virtual machine to ensure security.
  • VM Virtualized Machine
  • the present application provides a tenant resource management method and device in a multi-tenant scenario to realize the management function of multiple CaaS tenants in the MANO management system and to meet the isolation of applications of different tenants in the multi-tenant scenario.
  • this application provides a method for tenant resource management in a multi-tenant scenario.
  • the execution body of the method is a VNFM.
  • the method includes: the VNFM receives a tenant resource increase request sent by NFVO, and the tenant resource increase request includes a tenant The number of resources requested to be increased; the VNFM determines the resources allocated to the tenant according to the number of resources requested to be increased by the tenant and the number of free resources in the resource pool; the VNFM sends a node allocation request to the CaaS Mgr used by the tenant The node allocation request includes the identification information of the resource allocated to the tenant; 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; Alternatively, the VNFM transparently transmits the first feedback information to the NFVO.
  • the method further includes: the number of resources added by the VNFM according to the tenant request and the number of free resources in the resource pool Determine whether a new resource needs to be created; 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, and the second feedback information includes the Identification information of the resource newly created by the VIM; the VNFM incorporates the newly created resource into the resource pool.
  • the tenant resource increase request further includes identification information of the tenant; the node allocation request further includes identification information of the tenant.
  • the method further includes: the VNFM receives the tenant creation request sent by the NFVO, and the tenant creation request includes the tenant The identity information of the tenant; the VNFM creates the resource record information of the tenant, and the resource record information of the tenant includes the identity information of the tenant.
  • the tenant resource increase request further includes identification information of the tenant; after the VNFM receives the tenant resource increase request sent by the NFVO, the method further includes: the VNFM according to the tenant The identification information of determines the CaaS Mgr used by the tenant.
  • the method further includes: the VNFM receives the tenant creation request sent by the NFVO, and the tenant creation request includes the tenant The identity information of the tenant and the identification information of the CaaS Mgr used by the tenant; the VNFM creates the resource record information of the tenant, and the resource record information of the tenant includes the identity information of the tenant and the CaaS Mgr used by the tenant Identification information.
  • the method further includes: determining the communication between the VNFM and the CaaS Mgr identified by the identification information of the CaaS Mgr used by the tenant Whether the CaaS Mgr is available; the creation of the resource record information of the tenant by the VNFM includes: 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 of the tenant information.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces tenants are created and tenant resources are added to realize multiple CaaS tenants in the MANO management system
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • this application provides a tenant resource management method in a multi-tenant scenario, including: a VNFM receives a tenant resource release request sent by an NFVO, where the tenant resource release request includes the number of resources requested to be released; The number of resources requested to be released determines the resources to be released; the VNFM sends a node release request to the CaaS Mgr used by the tenant, and the node release request includes identification information of the resources to be released; the VNFM receives the CaaS The third feedback message sent by Mgr.
  • the method further includes: the VNFM updates the resource record information of the tenant according to the third feedback information; Alternatively, the VNFM transparently transmits the third feedback information to the NFVO.
  • the tenant resource release request further includes identification information of the tenant; the node release request further includes identification information of the tenant.
  • 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: the VNFM according to the tenant The identification information of determines the CaaS Mgr used by the tenant.
  • the method further includes: the VNFM receives a tenant deletion request sent by the NFVO, and the tenant deletion request includes The identification information of the tenant; the VNFM determines whether all the resources of the tenant have been released according to the resource record information of the tenant; if all the resources of the tenant have been released, the VNFM deletes the resource record of the tenant information.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • this application provides a method for tenant resource management in a multi-tenant scenario.
  • the execution subject of the method is CaaS Mgr.
  • the method includes receiving a node allocation request sent by a VNFM, and the node allocation request includes allocation to tenants.
  • the identification information of the resource; the resource allocated to the tenant is allocated to the tenant; the first feedback information is sent to the VNFM.
  • the node allocation request further includes identification information of the tenant.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces tenants are created and tenant resources are added to realize multiple CaaS tenants in the MANO management system
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • this application provides a method for tenant resource management in a multi-tenant scenario.
  • the execution subject of the method is CaaS Mgr.
  • the method includes receiving a node release request sent by a VNFM, and the node release request includes the requirement. Identification information of the released resource; releasing the resource to be released back to the resource pool; sending third feedback information to the VNFM.
  • the node release request further includes identification information of the tenant.
  • the method before releasing the resource to be released back to the resource pool, the method further includes: judging whether the resource to be released carries services of other tenants; if the resource to be released is If the services of other tenants are carried, the services of the other tenants are migrated to other resources; the releasing the resources to be released back to the resource pool includes: when the resources to be released are free, the The resources to be released are released back to the resource pool.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • this application provides a tenant resource management method in a multi-tenant scenario.
  • the execution body of the method is NFVO.
  • the method includes: receiving a tenant creation request sent by OSS, and the tenant creation request includes the tenant's Name; create resource record information of the tenant, the resource record information of the tenant includes the name of the tenant.
  • the tenant creation request further includes identification information of the CaaS Mgr used by the tenant; the resource record information of the tenant further includes identification information of the CaaS Mgr used by the tenant.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces tenants are created and tenant resources are added to realize multiple CaaS tenants in the MANO management system
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • this application provides a tenant resource management method in a multi-tenant scenario.
  • the execution body of the method is NFVO.
  • the method includes: receiving a tenant deletion request sent by OSS, and the tenant deletion request includes the tenant's Identification information; determine whether the resources of the tenant have all been released according to the resource record information of the tenant; if all the resources of the tenant have been released, delete the resource record information of the tenant.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • the present application provides a VNFM, including: a receiving module, configured to receive a tenant resource increase request sent by NFVO, where the tenant resource increase request includes the number of resources requested by the tenant; The number of resources requested to be increased and the number of free resources in the resource pool determine the resources allocated to the tenant; the sending module is configured to send a node allocation request to the CaaS Mgr used by the tenant, and the node allocation request includes the allocation to The identification information of the resource of the tenant; the receiving module is further configured to receive the first feedback information sent by the CaaS Mgr.
  • 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 to the NFVO The first feedback information.
  • the processing module is further configured to determine whether a new resource needs to be created according to the number of resources requested by the tenant and the number of idle resources in the resource pool; if a new virtual resource needs to be created
  • the sending module is also used to send a resource creation request to VIM;
  • the receiving module is also used to receive second feedback information sent by the VIM, and the second feedback information includes the newly created VIM Identification information of the resource;
  • the processing module is also used to incorporate the newly created resource into the resource pool.
  • the tenant resource increase request further includes identification information of the tenant; the node allocation request further includes identification information of the tenant.
  • the receiving module is further configured to receive a tenant creation request sent by the NFVO, where the tenant creation request includes the identity information of the tenant; and the processing module is further configured to create a tenant The resource record information of the tenant, the resource record information of the tenant includes the identity information of the tenant.
  • the tenant resource increase request further includes identification information of the tenant; the processing module is further configured to determine the CaaS Mgr used by the tenant according to the identification information of the tenant.
  • the receiving module is further configured to receive a tenant creation request sent by the NFVO, where the tenant creation request includes the identity information of the tenant and the identification information of the CaaS Mgr used by the tenant.
  • the processing module is also used to create resource record information of the tenant, and the resource record information of the tenant includes the identity information of the tenant and the identification information of the CaaS Mgr used by the tenant.
  • 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; if the CaaS Mgr used by the tenant is available If the CaaS Mgr identified by the identification information is available, the resource record information of the tenant is created.
  • the receiving module is further configured to receive a tenant resource release request sent by the network function virtualization orchestrator NFVO, where the tenant resource release request includes the number of resources requested to be released; the processing module, It is also used to determine the resources to be released according to the amount of resources requested to be released; the sending module is also used to send a node release request to the container or service manager CaaS Mgr used by the tenant, and the node release request includes all The identification information of the resource to be released; the receiving module is further configured to receive the third feedback information sent by the CaaS Mgr.
  • 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 to the NFVO The third feedback information.
  • the tenant resource release request further includes identification information of the tenant; the node release request further includes identification information of the tenant.
  • the tenant resource release request further includes identification information of the tenant; the processing module is further configured to determine the CaaS Mgr used by the tenant according to the identification information of the tenant.
  • the receiving module is further configured to receive a tenant deletion request sent by the NFVO, where the tenant deletion request includes identification information of the tenant; the processing module is further configured to The resource record information of the tenant determines whether all the resources of the tenant have been released; if all the resources of the tenant have been released, the resource record information of the tenant is deleted.
  • this application provides a CaaS Mgr, including: a receiving module, configured to receive a node allocation request sent by a VNFM, where the node allocation request includes identification information of resources allocated to tenants; and a processing module, configured to transfer the The resources allocated to the tenant are allocated to the tenant; the sending module is used to send the first feedback information to the VNFM.
  • the node allocation request further includes identification information of the tenant.
  • the receiving module is further configured to receive a node release request sent by the VNFM, where the node release request includes identification information of the resource to be released; the processing module is further configured to The resource to be released is released back to the resource pool; the sending module is further configured to send third feedback information to the VNFM.
  • the node release request further includes identification information of the tenant.
  • the processing module is also used to determine whether the resource to be released carries services of other tenants; if the resource to be released carries services of other tenants, The services of the other tenants are migrated to other resources; when the resources to be released are free, the resources to be released are released back to the resource pool.
  • this application provides an NFVO, which includes: a receiving module for receiving a tenant creation request sent by OSS, where the tenant creation request includes the name of the tenant; a processing module for creating resource records of the tenant Information, the resource record information of the tenant includes the name of the tenant.
  • the tenant creation request further includes identification information of the CaaS Mgr used by the tenant; the resource record information of the tenant further includes identification information of the CaaS Mgr used by the tenant.
  • the receiving module is further configured to receive a tenant deletion request sent by OSS, where the tenant deletion request includes identification information of the tenant; and the processing module is further configured to The resource record information of determines whether the resources of the tenant have all been released; if all the resources of the tenant have been released, the resource record information of the tenant is deleted.
  • this application provides a tenant resource management method in a multi-tenant scenario, including: NFVO sends a tenant creation request to VNFM, the tenant creation request includes the identity information of the tenant; VNFM creates the resource record information of the tenant, and the resource record of the tenant The information includes the identity information of the tenant. NFVO sends a tenant resource increase request to the VNFM.
  • the tenant resource increase request includes the number of resources requested by the tenant; the VNFM determines the resources allocated to the tenant according to the number of resources requested by the tenant and the number of free resources in the resource pool; the CaaS used by the VNFM to the tenant Mgr sends a node allocation request, which includes the identification information of the resources allocated to the tenant; CaaS Mgr allocates the resources allocated to the tenant to the tenant; CaaS Mgr sends the first feedback information to the VNFM; the VNFM updates the tenant’s information according to the first feedback information Resource record information, adding the resources allocated to the tenant to the tenant's resource record information.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • the VNFM creates and maintains tenant record information, and increases tenant resources to realize MANO
  • the management function of multiple CaaS tenants in the management system satisfies the isolation of applications of different tenants in the multi-tenant scenario.
  • this application provides a tenant resource management method in a multi-tenant scenario, including: NFVO creates resource record information of the tenant according to a tenant creation request sent by OSS, and the resource record information of the tenant includes the identity information of the tenant. NFVO sends a tenant resource increase request to the VNFM.
  • the tenant resource increase request includes the number of resources requested by the tenant; the VNFM determines the resources allocated to the tenant according to the number of resources requested by the tenant and the number of free resources in the resource pool; the CaaS used by the VNFM to the tenant Mgr sends a node allocation request, which includes the identification information of the resources allocated to the tenant; CaaS Mgr allocates the resources allocated to the tenant to the tenant; CaaS Mgr sends the first feedback information to the VNFM; the VNFM sends the first feedback information to the NFVO; NFVO updates the tenant's resource record information according to the first feedback information, and adds the resources allocated to the tenant to the tenant's resource record information.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces By adding tenant management interfaces, NFVO creates and maintains tenant record information, and VNFM adds tenant resources to achieve The management function of multiple CaaS tenants in the MANO management system meets the isolation of applications of different tenants in the multi-tenant scenario.
  • this application provides a tenant resource management system in a multi-tenant scenario.
  • the system includes: VNFM, CaaS Mgr, and NFVO.
  • the VNFM adopts the VNFM described in any one of the seventh aspects.
  • the CaaS Mgr adopts the CaaS Mgr described in any one of the eighth aspect above
  • the NFVO adopts the NFVO described in any one of the ninth aspect above.
  • NFVO provides a tenant management interface externally. NFVO can connect to OSS through the tenant management interface to realize functions such as creating/deleting tenants, adding/deleting/querying tenant resources, etc.
  • a tenant management interface is also provided between NFVO and VNFM.
  • VNFM if the VNFM manages CaaS tenants, NFVO transparently transmits all tenant management related requests to the VNFM through the tenant management interface. If the VNFM does not manage the CaaS tenants, it only executes related requests. For resource management, NFVO sends a request for adding/deleting/inquiring tenant resources to the VNFM through the tenant management interface.
  • a node management interface is provided between VNFM and CaaS Mgr, which is used to manage new resources to CaaS Mgr before and after related resource management operations (such as creating/deleting virtual machines), or to request CaaS Mgr to delete resources to be deleted Information.
  • the tenant resource management method includes two situations: the first is that different tenants share CaaS Mgr.
  • the entire MANO management system uses a common CaaS Mgr, which is connected to different networks. Yuan represents different tenants, all network elements share the same CaaS Mgr, and the isolation between tenants is achieved through different network elements.
  • the VNFM needs to carry the identification information (for example, tenant ID) of the tenant in the communication with the CaaS Mgr to notify the CaaS Mgr to perform container management according to the tenant.
  • the second is that different tenants use different CaaS Mgrs.
  • the vendor represents the tenant
  • each vendor's network element only uses the CaaS Mgr provided by the vendor itself, and the isolation between tenants is achieved through different CaaS Mgrs.
  • the VNFM identifies the corresponding CaaS Mgr according to the identification information of the tenant, and does not need to provide additional identification information of the tenant in the communication with the CaaS Mgr.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces tenants are created and tenant resources are added or tenant resources are released and tenants are deleted to realize MANO.
  • the management function of multiple CaaS tenants in the management system satisfies the isolation of applications of different tenants in the multi-tenant scenario.
  • this application provides a virtual network element device, including:
  • One or more processors are One or more processors;
  • Memory used to store one or more programs
  • the one or more processors When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of the first to sixth aspects.
  • the present application provides a computer-readable storage medium that stores instructions, and when the instructions are run on a computer, they are used to execute any one of the first to sixth aspects above The method described.
  • this application provides a computer program, when the computer program is executed by a computer, it is used to execute the method described in any one of the first to sixth aspects.
  • this application provides a chip including a processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the first To the method of any one of the six aspects.
  • Figure 1 shows an application scenario to which the tenant resource management method in a multi-tenant scenario provided by this application is applicable
  • Embodiment 2 is a flowchart of Embodiment 1 of a tenant resource management method in a multi-tenant application scenario
  • Embodiment 3 is a flowchart of Embodiment 2 of a tenant resource management method in a multi-tenant application scenario
  • Embodiment 4 is a flowchart of Embodiment 3 of a tenant resource management method in a multi-tenant application scenario
  • FIG. 5 is a flowchart of Embodiment 4 of a tenant resource management method in a multi-tenant application scenario
  • FIG. 6 is a schematic structural diagram of an embodiment of a virtual network element node of this application.
  • FIG. 7 is a schematic structural diagram of an embodiment of a virtual network device of this application.
  • At least one (item) refers to one or more, and “multiple” refers to two or more.
  • “And/or” is used to describe the association relationship of associated objects, indicating that there can be three types of relationships, for example, “A and/or B” can mean: only A, only B, and both A and B , Where A and B can be singular or plural.
  • the character “/” generally indicates that the associated objects are in an “or” relationship.
  • the following at least one item (a)” or similar expressions refers to any combination of these items, including any combination of a single item (a) or plural items (a).
  • At least one (a) of a, b or c can mean: a, b, c, "a and b", “a and c", “b and c", or "a and b and c" ", where a, b, and c can be single or multiple.
  • FIG. 1 shows the applicable application scenario of the tenant resource management method in the multi-tenant scenario provided by this application.
  • This scenario is a dynamic management and orchestration (MANagement and Orchestration, MANO) management system for multi-tenant virtual resources, including the network Function Virtualization Orchestrator (Network Function Virtualization Orchestrator, NFVO), Virtual Network Function Manager (Virtualized Network Functions Manager, VNFM), Virtualized Infrastructure Manager (Virtualised Infrastructure Manager, VIM), and Container-as-a-Service Manager (Container as a Service Manager, CaaS Mgr).
  • NFVO provides a tenant management interface externally.
  • NFVO can connect to the Operation Support System (OSS) through the tenant management interface to implement functions such as creating/deleting tenants, adding/deleting/querying tenant resources, etc.
  • OSS Operation Support System
  • a tenant management interface is also provided between NFVO and VNFM. According to the positioning of VNFM, if the VNFM manages CaaS tenants, NFVO transparently transmits all tenant management related requests to the VNFM through the tenant management interface. If the VNFM does not manage the CaaS tenants, it only executes related requests. For resource management, NFVO sends a request for adding/deleting/inquiring tenant resources to the VNFM through the tenant management interface.
  • a node management interface is provided between VNFM and CaaS Mgr, which is used to manage new resources to CaaS Mgr before and after related resource management operations (such as creating/deleting virtual machines), or to request CaaS Mgr to delete resources to be deleted Information.
  • the tenant resource management methods in the multi-tenant scenario provided by this application include two situations: the first is that different tenants share CaaS Mgr.
  • the entire MANO management system uses a common CaaS Mgr, and different network elements represent different tenants. Network elements share the same CaaS Mgr, and isolation between tenants is achieved through different network elements.
  • the VNFM needs to carry identification information (for example, tenant identity (ID)) of the tenant in the communication with the CaaS Mgr, which is used to notify the CaaS Mgr to perform container management according to the tenant.
  • ID tenant identity
  • the second is that different tenants use different CaaS Mgrs.
  • the vendor represents the tenant
  • each vendor's network element only uses the CaaS Mgr provided by the vendor itself, and the isolation between tenants is achieved through different CaaS Mgrs.
  • the VNFM identifies the corresponding CaaS Mgr according to the identification information of the tenant, and does not need to provide additional identification information of the tenant in the communication with the CaaS Mgr.
  • FIG. 2 is a flowchart of Embodiment 1 of a tenant resource management method in a multi-tenant scenario of this application. As shown in Figure 2, the method of this embodiment describes the process of creating tenants and adding tenant resources. The method may include:
  • Step 201 OSS sends a tenant creation request to NFVO.
  • the tenant creation request mainly includes the identity information of the tenant, including the tenant's name, account number, etc., as an aid, it may also include information such as the tenant's profile.
  • Step 202 NFVO creates resource record information of the tenant.
  • the resource record information of the tenant includes the identity information of the tenant and the identification information (tenant ID) created for the tenant.
  • NFVO can record the resource record information of the tenant in the form of a list.
  • Each tenant corresponds to an entry, and the entry includes The ID of the tenant and the identity information of the tenant, corresponding to the second case above, also include the identification information of the CaaS Mgr used by the tenant.
  • the VNFM is not responsible for managing CaaS tenants, but only performs related resource management. Therefore, the resource record information of the tenants is created and maintained by NFVO.
  • NFVO will transparently transmit the tenant creation request to the VNFM, and the VNFM will create the tenant's resource record information.
  • Step 203 NFVO feeds back the tenant creation response to OSS.
  • NFVO After NFVO has created the tenant's resource record information, it will feed back the creation response to OSS, that is, notify OSS that the tenant has been successfully created.
  • the VNFM first sends a tenant creation response to the NFVO after creating the resource record information of the tenant, and then the NFVO feeds it back to the OSS.
  • Step 204 OSS sends a tenant resource increase request to NFVO.
  • the tenant resource increase request includes identification information (for example, tenant ID or tenant name) of the tenant requesting to increase the resource and the number of resources requested to be increased.
  • OSS can obtain the number of resources required by the tenant, such as the number of virtual machines or bare metal, according to the tenant's request. Therefore, when OSS requests NFVO for additional resources, in addition to the identification information of the requesting tenant, it also carries the number of resources requested by the tenant. .
  • Step 205 The NFVO transparently transmits the tenant resource increase request to the VNFM.
  • the resource management of the tenant is realized by the interaction and coordination of the VNFM and CaaS Mgr, so the NFVO transparently transmits the tenant resource increase request to the VNFM.
  • Step 206 The VNFM determines the resources allocated to the tenant.
  • the system incorporates all idle resources into the resource pool.
  • the resource pool is a list of idle resources, which records the identification information and resource specifications of the idle resources.
  • VNFM selects from the resource pool according to the number of resources requested by the tenant and the number of free resources in the resource pool. If the number of free resources in the resource pool is sufficient, the VNFM does not Specially apply for new resources from the Virtualised Infrastructure Manager (VIM).
  • VIP Virtualised Infrastructure Manager
  • the VNFM needs to apply to the VIM for new resources (the steps in the dashed box in the figure).
  • the VNFM is based on the resource specifications in the resource pool (the data can be pre-configured in the VNFM or obtained from a specific virtualized network function descriptor (VNF Descriptor, VNFD) ) Send a resource creation request to the VIM.
  • VNF Descriptor VNF Descriptor
  • Send a resource creation request to the VIM Send a resource creation request to the VIM.
  • the second feedback information is fed back to the VNFM.
  • the information carries the identification information of the newly created resource.
  • the VNFM includes the newly created resource in the resource pool, that is, in the free resource
  • the information of the newly created resource is added to the list, ready for subsequent allocation.
  • Step 207 The VNFM sends a node allocation request to CaaS Mgr.
  • the VNFM After the VNFM determines the resources allocated to the tenant, it sends a node allocation request to CaaS Mgr, and the node allocation request carries identification information of the resources allocated to the tenant.
  • This embodiment corresponds to the first situation described above, that is, different tenants share the CaaS Mgr, and the VNFM needs to carry the identification information of the tenant in the node allocation request, so that the CaaS Mgr can identify which tenant is allocated resources.
  • This embodiment corresponds to the above-mentioned second situation, that is, different tenants use different CaaS Mgr. Since the tenant and the CaaS Mgr used by the tenant have a corresponding relationship, the VNFM does not need to carry the identification information of the tenant in the node allocation request.
  • Step 208 CaaS Mgr takes over the allocated resources.
  • a resource such as a virtual machine or a bare metal
  • Step 209 CaaS Mgr sends the first feedback information to the VNFM.
  • the CaaS Mgr After the CaaS Mgr completes the above operations, it feeds back the processing result to the VNFM, that is, notifies the VNFM that the resource allocation is complete.
  • Step 210 The VNFM transparently transmits the first feedback information to the NFVO.
  • the NFVO is responsible for managing the CaaS tenants, so the VNFM transparently transmits the first feedback information to the NFVO to notify the NFVO that the resource allocation is completed.
  • Step 211 The NFVO adds identification information of the resource allocated to the tenant in the resource record information of the tenant according to the first feedback information.
  • the NFVO After receiving the feedback, the NFVO updates the locally stored resource record information of the tenant, adding the identification information of the resource allocated to the tenant, or increasing the number of resources allocated to the tenant.
  • the VNFM When the subsequent MANO management system needs to deploy container network elements, the VNFM needs to carry the identification information of the tenant (such as tenant ID or tenant name) when sending the container management request to CaaS Mgr.
  • the identification information of the tenant can be received from the network element of the VNFM Obtained in the deployment request, or generated by the VNFM based on relevant information to determine the identity of the tenant, for example, to determine the identity of the tenant based on the network element provider, network element type/ID, etc.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces tenants are created and tenant resources are added to realize multiple CaaS tenants in the MANO management system
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • Fig. 3 is a flowchart of the second embodiment of the tenant resource management method in the multi-tenant scenario of the application. As shown in Fig. 3, the method of this embodiment describes the process of deleting tenants and releasing tenant resources. The method may include:
  • Step 301 OSS sends a tenant resource release request to NFVO.
  • the tenant resource release request includes identification information (such as tenant ID or tenant name) of the tenant requesting to release the resource and the number of resources requested to be released.
  • Step 302 The NFVO transparently transmits the tenant resource release request to the VNFM.
  • the resource management of the tenant is realized by the interaction and coordination of the VNFM and CaaS Mgr, so the NFVO transparently 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 number of resources to be released.
  • Step 304 The VNFM sends a node release request to CaaS Mgr.
  • the VNFM After determining the resource to be released, the VNFM sends a node release request to CaaS Mgr, and the node allocation request carries identification information of the resource to be released.
  • This embodiment corresponds to the first situation described above, that is, different tenants share the CaaS Mgr, and the VNFM needs to carry the identification information of the tenant in the node allocation request, so that the CaaS Mgr can identify which tenant is allocated resources.
  • This embodiment corresponds to the above-mentioned second situation, that is, different tenants use different CaaS Mgr. Since the tenant and the CaaS Mgr used by the tenant have a corresponding relationship, the VNFM does not need to carry the identification information of the tenant in the node allocation request.
  • Step 305 CaaS Mgr manages the released resources.
  • 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, CaaS Mgr releases the resource (such as virtual machine or bare metal) corresponding to the identification information of the resource through its node management function. And delete the label of the resource. If there are still running container instances on the selected resource, CaaS Mgr needs to deploy the container instance on other resources until there are no running container instances on the resource, at which time CaaS Mgr releases the selected resource back to the resource pool.
  • the resource such as virtual machine or bare metal
  • Step 306 CaaS Mgr sends third feedback information to the VNFM.
  • the CaaS Mgr After the CaaS Mgr completes the above operations, it feeds back the processing result to the VNFM, that is, notifies the VNFM that the resource release is complete.
  • Step 307 The VNFM deletes the identification information of the resource to be released in the resource record information of the tenant according to the third feedback information.
  • the VNFM After receiving the feedback, the VNFM updates the locally stored resource record information of the tenant, and deletes the identification information of the released resource, or deletes the quantity of the resource to be released.
  • Step 308 OSS sends a tenant deletion request to NFVO.
  • the tenant deletion request includes identification information of the tenant (for example, tenant ID or tenant name).
  • Step 309 The NFVO transparently transmits the tenant deletion request to the VNFM.
  • the VNFM is responsible for managing CaaS tenants.
  • the resource record information of the tenants is created and maintained by the VNFM. Therefore, the NFVO transparently transmits the tenant deletion request to the VNFM.
  • Step 310 The VNFM determines whether all the resources of the tenant have been released according to the resource record information of the tenant.
  • the VNFM judges whether all the resources of the tenant have been released, and the tenant can be deleted only if the tenant does not occupy any resources.
  • Step 311 If all the resources of the tenant have been released, the VNFM deletes the resource record information of the tenant.
  • the VNFM After the VNFM determines that all the resources of the tenant have been released, it deletes the locally stored resource record information of the tenant.
  • Step 312 The VNFM transparently transmits the tenant deletion response to the NFVO.
  • the VNFM After the VNFM deletes the tenant's resource record information, it transparently transmits the tenant deletion response to the NFVO, that is, informs the OSS of the successful deletion of the tenant through NFVO. If the VNFM fails to delete the tenant, for example, the resources of the tenant are not completely released, the VNFM informs the OSS of the failure to delete the tenant through NFVO.
  • Step 313 NFVO feeds back a tenant deletion response to OSS.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • FIG. 4 is a flowchart of Embodiment 3 of the tenant resource management method in the multi-tenant scenario of this application. As shown in Figure 4, the method of this embodiment describes the process of creating tenants and adding tenant resources in the second case above. Methods can include:
  • Step 401 OSS sends a tenant creation request to NFVO.
  • the tenant creation request mainly includes the name of the tenant, and as an aid, it may also include information such as a profile of the tenant. Since this embodiment describes the second case described above, 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 the name and IP address of the CaaS Mgr.
  • Step 402 The NFVO transparently transmits the tenant creation request to the VNFM.
  • the VNFM is responsible for managing CaaS tenants, and the resource record information of the tenants is created and maintained by the VNFM, so the NFVO transparently transmits the tenant creation request to the VNFM.
  • Step 403 The VNFM creates resource record information of the tenant.
  • the resource record information of the tenant includes the identity information of the tenant, the identification information (tenant ID) created for the tenant, and the identification information of the CaaS Mgr used by the tenant.
  • the VNFM can record the resource record information of the tenant in the 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 the CaaS Mgr used by 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.
  • Step 404 The VNFM transparently transmits the tenant creation response to the NFVO.
  • the VNFM After the VNFM creates the tenant's resource record information, it transparently transmits the tenant creation response to NFVO, that is, informs the OSS of the successful tenant creation through NFVO.
  • Step 405 NFVO feeds back the creation response to OSS.
  • Step 406 OSS sends a tenant resource increase request to NFVO.
  • the tenant resource increase request includes identification information (for example, tenant ID or tenant name) of the tenant requesting to increase the resource and the number of resources requested to be increased.
  • OSS can obtain the number of resources required by the tenant, such as the number of virtual machines or bare metal, according to the tenant's request. Therefore, when OSS requests NFVO for additional resources, in addition to the identification information of the requesting tenant, it also carries the number of resources requested by the tenant. .
  • Step 407 The NFVO transparently transmits the tenant resource increase request to the VNFM.
  • the resource management of the tenant is realized by the interaction and coordination of the VNFM and CaaS Mgr, so the NFVO transparently transmits the tenant resource increase request to the VNFM.
  • Step 408 The VNFM determines the resources allocated to the tenant.
  • the system incorporates all idle resources into the resource pool.
  • the resource pool is a list of idle resources, which records the identification information and resource specifications of the idle resources.
  • VNFM selects from the resource pool according to the number of resources requested by the tenant and the number of free resources in the resource pool. If the number of free resources in the resource pool is sufficient, the VNFM does not Specially apply for new resources from VIM.
  • the VNFM needs to apply to the VIM for new resources (the steps in the dashed box in the figure).
  • the VNFM is based on the resource specifications in the resource pool (the data can be pre-configured in the VNFM or obtained from a specific virtualized network function descriptor (VNF Descriptor, VNFD) ) Send a resource creation request to the VIM.
  • VNF Descriptor VNF Descriptor
  • Send a resource creation request to the VIM Send a resource creation request to the VIM.
  • the second feedback information is fed back to the VNFM.
  • the information carries the identification information of the newly created resource.
  • the VNFM includes the newly created resource in the resource pool, that is, in the free resource
  • the information of the newly created resource is added to the list, ready for subsequent allocation.
  • Step 409 The VNFM sends a node allocation request to CaaS Mgr.
  • the VNFM After the VNFM determines the resources allocated to the tenant, it sends a node allocation request to the corresponding CaaS Mgr according to the identification information of the CaaS Mgr in the resource record information of the tenant, and the node allocation request carries the identification information of the resources allocated to the tenant. Since this embodiment describes the second situation described above, that is, different tenants use different CaaS Mgr, the node allocation request does not need to carry the identification information of the tenant.
  • Step 410 CaaS Mgr takes over the allocated resources.
  • the CaaS Mgr manages the corresponding resources according to the identification information of the resources in the node allocation request.
  • Step 411 The CaaS Mgr sends the first feedback information to the VNFM.
  • the CaaS Mgr After the CaaS Mgr completes the above operations, it feeds back the processing result to the VNFM, that is, notifies the VNFM that the resource allocation is complete.
  • 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.
  • the VNFM is responsible for managing the CaaS tenants. After receiving the feedback, the VNFM updates the locally stored resource record information of the tenants, adding identification information of the resources allocated to the tenants, or increasing the number of resources allocated to the tenants.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • tenant management interfaces tenants are created and tenant resources are added to realize multiple CaaS tenants in the MANO management system
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • FIG. 5 is a flowchart of Embodiment 4 of the tenant resource management method in the multi-tenant scenario of the application. As shown in Figure 5, the method of this embodiment describes the process of deleting tenants and releasing tenant resources in the first case above. Methods can include:
  • Step 501 OSS sends a tenant resource release request to NFVO.
  • the tenant resource release request includes identification information (such as tenant ID or tenant name) of the tenant requesting to release the resource and the number of resources requested to be released. Since this embodiment describes the second situation described above, 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 the name and IP address of the CaaS Mgr.
  • Step 502 The NFVO transparently transmits the tenant resource release request to the VNFM.
  • the resource management of the tenant is realized by the interaction and coordination of the VNFM and CaaS Mgr, so the NFVO transparently transmits the tenant resource release request to the VNFM.
  • Step 503 The VNFM determines the resources to be released.
  • the VNFM selects the resources to be released according to the number of resources to be released.
  • Step 504 The VNFM sends a node release request to CaaS Mgr.
  • the VNFM After determining the resource to be released, the VNFM sends a node release request to the corresponding CaaS Mgr according to the identification information of the CaaS Mgr used by the tenant, and the node allocation request carries the identification information of the resource to be released. Since this embodiment describes the second situation described above, that is, different tenants use different CaaS Mgr, the node allocation request does not need to carry the identification information of the tenant.
  • Step 505 CaaS Mgr manages the released resources.
  • 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, virtual machine or bare metal) corresponding to the resource identification information through its node management function. If there are still running container instances on the selected resource, CaaS Mgr needs to deploy the container instance on other resources until there are no running container instances on the resource, at which time CaaS Mgr releases the selected resource back to the resource pool.
  • the resource for example, virtual machine or bare metal
  • Step 506 CaaS Mgr sends third feedback information to the VNFM.
  • the CaaS Mgr After the CaaS Mgr completes the above operations, it feeds back the processing result to the VNFM, that is, notifies the VNFM that the resource release is complete.
  • Step 507 The VNFM deletes the identification information of the resource to be released from the resource record information of the tenant according to the third feedback information.
  • the VNFM After receiving the feedback, the VNFM updates the locally stored resource record information of the tenant, and deletes the identification information of the released resource, or deletes the quantity of the resource to be released.
  • Step 508 OSS sends a tenant deletion request to NFVO.
  • the tenant deletion request includes identification information of the tenant (for example, tenant ID or tenant name).
  • Step 509 The NFVO transparently transmits the tenant deletion request to the VNFM.
  • the VNFM is responsible for managing CaaS tenants, and the resource record information of the tenants is created and maintained by the VNFM, so the NFVO transparently transmits the tenant deletion request to the VNFM.
  • Step 510 The VNFM determines whether all the resources of the tenant have been released according to the resource record information of the tenant.
  • the VNFM judges whether all the resources of the tenant have been released, and the tenant can be deleted only if the tenant does not occupy any resources.
  • Step 511 If all the resources of the tenant have been released, the VNFM deletes the resource record information of the tenant.
  • the VNFM After the VNFM determines that all the resources of the tenant have been released, it deletes the locally stored resource record information of the tenant.
  • Step 512 The VNFM transparently transmits the tenant deletion response to the NFVO.
  • the VNFM After the VNFM deletes the tenant's resource record information, it transparently transmits the tenant deletion response to the NFVO, that is, informs the OSS of the successful deletion of the tenant through the NFVO. If the VNFM fails to delete the tenant, for example, the resources of the tenant are not completely released, the VNFM informs the OSS of the failure to delete the tenant through NFVO.
  • Step 513 NFVO feeds back a tenant deletion response to OSS.
  • the concept of multi-tenancy is introduced in the MANO management system and the CaaS Mgr platform, and the resource pool is managed and divided according to tenants.
  • the management function meets the isolation of applications of different tenants in multi-tenant scenarios.
  • Fig. 6 is a schematic structural diagram of an embodiment of a virtual network element node of this application.
  • the apparatus of this embodiment may include: a receiving module 601, a processing module 602, and a sending module 603.
  • the VNFM in the scenario shown can also be CaaS Mgr or NFVO.
  • the receiving module 601 is used to receive a tenant resource increase request sent by NFVO, where the tenant resource increase request includes the number of resources the tenant requests to increase; the processing module 602 is used to increase the number of resources and resources according to the tenant request The number of free resources in the pool determines the resources allocated to the tenant; the sending module 603 is configured to send a node allocation request to the CaaS Mgr used by the tenant, where the node allocation request includes the number of resources allocated to the tenant Identification information; the receiving module 601 is also used to receive the first feedback information sent by the CaaS Mgr.
  • 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 transmit to the NFVO Transmit the first feedback information.
  • the processing module 602 is further configured to determine whether a new resource needs to be created according to the number of resources requested by the tenant and the number of idle resources in the resource pool; if a new resource needs to be created Virtual machine, the sending module 603 is also used to send a resource creation request to VIM; the receiving module 601 is also used to receive second feedback information sent by the VIM, where the second feedback information includes the VIM Identification information of the newly created resource; the processing module 602 is also used to include the newly created resource into the resource pool.
  • the tenant resource increase request further includes identification information of the tenant; the node allocation request further includes identification information of the tenant.
  • the receiving module 601 is further configured to receive a tenant creation request sent by the NFVO, where the tenant creation request includes the 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 the identity information of the tenant.
  • the tenant resource increase request further includes identification information of the tenant; the processing module 602 is further configured to determine the CaaS Mgr used by the tenant according to the identification information of the tenant.
  • the receiving module 601 is further configured to receive a tenant creation request sent by the NFVO, where the tenant creation request includes the identity information of the tenant and the identity of the CaaS Mgr used by the tenant Information;
  • the processing module 602 is also used to create resource record information of the tenant, and the resource record information of the tenant includes the identity information of the tenant and the identification information of the CaaS Mgr used by the tenant.
  • 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; if the CaaS Mgr used by the tenant is available If the CaaS Mgr identified by the identification information of the Mgr is available, the resource record information of the tenant is created.
  • the receiving module 601 is further configured to receive a tenant resource release request sent by the network function virtualization orchestrator NFVO, where the tenant resource release request includes the number of resources requested to be released; the processing module 602.
  • the sending module 603 is also configured to send a node release request to the container or service manager CaaS Mgr used by the tenant, and the node releases The request includes the identification information of the resource to be released; the receiving module 601 is further configured to receive the third feedback information sent by the CaaS Mgr.
  • the processing module 602 is further configured to update the resource record information of the tenant according to the third feedback information; or, the sending module 603 is further configured to transmit to the NFVO Pass the third feedback information.
  • the tenant resource release request further includes identification information of the tenant; the node release request further includes identification information of the tenant.
  • the tenant resource release request further includes identification information of the tenant; the processing module 602 is further configured to determine the CaaS Mgr used by the tenant according to the identification information of the tenant.
  • the receiving module 601 is further configured to receive a tenant deletion request sent by the NFVO, where the tenant deletion request includes identification information of the tenant; the processing module 602 is further configured to Determine whether the resources of the tenant have all been released according to the resource record information of the tenant; if all the resources of the tenant have been released, delete the resource record information of the tenant.
  • the receiving module 601 is used to receive a node allocation request sent by the VNFM, where the node allocation request includes identification information of the resources allocated to the tenant; the processing module 602 is used to allocate the resources allocated to the tenant to The tenant; a sending module 603, configured to send first feedback information to the VNFM.
  • the node allocation request further includes identification information of the tenant.
  • the receiving module 601 is further configured to receive a node release request sent by the VNFM, where the node release request includes identification information of the resource to be released; the processing module 602 also uses To release the resource to be released back to the resource pool; the sending module 603 is also used to send third feedback information to the VNFM.
  • the node release request further includes identification information of the tenant.
  • the processing module 602 is also used to determine whether the resources to be released carry services of other tenants; if the resources to be released carry services of other tenants, then Migrate the services of the other tenants to other resources; when the resources to be released are free, release the resources to be released back to the resource pool.
  • the receiving module 601 is used to receive a tenant creation request sent by OSS, the tenant creation request includes the name of the tenant; the processing module 602 is used to create resource record information of the tenant, and the resource of the tenant The record information includes the name of the tenant.
  • the tenant creation request further includes identification information of the CaaS Mgr used by the tenant; the resource record information of the tenant further includes identification information of the CaaS Mgr used by the tenant.
  • the receiving module 601 is further configured to receive a tenant deletion request sent by OSS, where the tenant deletion request includes identification information of the tenant; the processing module 602 is further configured to The resource record information of the tenant determines whether all the resources of the tenant have been released; if all the resources of the tenant have been released, the resource record information of the tenant is deleted.
  • the device of this embodiment can be used to implement the technical solutions of any of the method embodiments shown in FIGS. 2-5, and its implementation principles and technical effects are similar, and will not be repeated here.
  • FIG. 7 is a schematic structural diagram of an embodiment of a virtual network device of this application.
  • the virtual network device includes a processor 701, a memory 702, an input device 703, and an output device 704; the number of processors 701 in the virtual network device can be There are one or more.
  • One processor 701 is taken as an example in FIG. 7; the processor 701, memory 702, input device 703, and output device 704 in the virtual network device can be connected by a bus or other means. Connect as an example.
  • the memory 702 can be used to store software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the method in the embodiment shown in FIGS. 2-5 of this 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 above-mentioned tenant resource management method in the multi-tenant scenario.
  • the memory 702 may mainly include a program storage area and a data storage area.
  • the program storage area may store an operating system and an application program required by at least one function; the data storage area may store data created according to the use of the terminal, etc.
  • the memory 702 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices.
  • the memory 702 may further include a memory remotely provided with respect to the processor 701, and these remote memories may be connected to a virtual network device through a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
  • the input device 703 can be used to receive inputted numeric or character information, and generate key signal input related to user settings and function control of the virtual network device.
  • the output device 704 may include a display device such as a display screen.
  • this application provides a computer-readable storage medium that stores an instruction, and when the instruction runs on a computer, it is used to execute the implementation shown in Figure 2-5 above.
  • the method in the example is a possible implementation manner.
  • this application provides a computer program, when the computer program is executed by a computer, it is used to execute the method in the embodiment shown in FIGS. 2-5.
  • the present application provides a chip including a processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute Figure 2-5 shows the method in the embodiment.
  • a person of ordinary skill in the art can understand that all or part of the steps in the foregoing method embodiments can be implemented by a program instructing relevant hardware.
  • the aforementioned program can be stored in a computer readable storage medium.
  • the steps including the foregoing method embodiments are executed; and the foregoing storage medium includes: ROM, RAM, magnetic disk, or optical disk and other media that can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了一种多租户场景下的租户资源管理方法和装置。本申请实施例提供的多租户场景下的租户资源管理方法，包括：VNFM接收NFVO发送的租户资源增加请求，该租户资源增加请求包括租户请求增加的资源数量；VNFM根据租户请求增加的资源数量和资源池中的空闲资源数量确定分配给租户的资源；VNFM向租户使用的CaaS Mgr发送节点分配请求，该节点分配请求包括分配给租户的资源的标识信息；VNFM接收CaaS Mgr发送的第一反馈信息。本申请实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。

Description

多租户场景下的租户资源管理方法和装置
本申请要求于2019年4月18日提交中国专利局、申请号为201910313602.5、申请名称为“多租户场景下的租户资源管理方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及资源虚拟化技术，尤其涉及一种多租户场景下的租户资源管理方法和装置。
背景技术
多租户(multi-tenant)是云计算领域运维管理中常用的一个概念，其主要目的是在多用户共享平台或基础设施的环境下，为每个用户保障数据的隔离性。在云计算中，租户通常是指系统或者平台的客户，以及客户在创建并使用的一系列数据，例如，账户、统计信息、用户数据、定制化的应用程序环境以及使用的计算资源、网络资源和存储资源等。由于系统或者平台会同时服务于多个租户，因此服务提供商需要保证多个租户不会互相影响，并确保各个租户的数据安全，不被其他租户获取甚至篡改。
服务提供商可以使用不同技术来切割租户的应用程序环境和数据，其中包括容器即服务(Container as a Service，CaaS)技术，容器(Container)是一种操作系统级别的虚拟化技术，通常采用虚拟机(Virtualized Machine，VM)容器方式，即先部署虚拟机，再在虚拟机上部署容器，通过虚拟机实现不同容器应用之间的隔离，保证安全性。
但是，如果虚拟机作为资源池要在不同的容器之间共享，就无法满足多租户场景下通过虚拟机实现不同容器应用之间的隔离的目的，无法确保租户的隔离性和安全性。
发明内容
本申请提供一种多租户场景下的租户资源管理方法和装置，以实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第一方面，本申请提供一种多租户场景下的租户资源管理方法，该方法的执行主体为VNFM，所述方法包括：VNFM接收NFVO发送的租户资源增加请求，所述租户资源增加请求包括租户请求增加的资源数量；所述VNFM根据所述租户请求增加的资源数量和资源池中的空闲资源数量确定分配给所述租户的资源；所述VNFM向所述租户使用的CaaS Mgr发送节点分配请求，所述节点分配请求包括所述分配给所述租户的资源的标识信息；所述VNFM接收所述CaaS Mgr发送的第一反馈信息。
在一种可能的实现方式中，所述VNFM接收所述CaaS Mgr发送的第一反馈信息之后，所述方法还包括：所述VNFM根据所述第一反馈信息更新所述租户的资源记录信息；或者，所述VNFM向所述NFVO透传所述第一反馈信息。
在一种可能的实现方式中，所述VNFM接收NFVO发送的租户资源增加请求之后，所述方法还包括：所述VNFM根据所述租户请求增加的资源数量和所述资源池中的空闲资源数量确定是否需要创建新的资源；若需要创建新的虚拟机，则所述VNFM向VIM发 送资源创建请求；所述VNFM接收所述VIM发送的第二反馈信息，所述第二反馈信息包括所述VIM新创建的资源的标识信息；所述VNFM将所述新创建的资源纳入所述资源池中。
在一种可能的实现方式中，所述租户资源增加请求还包括所述租户的标识信息；所述节点分配请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述VNFM接收NFVO发送的租户资源增加请求之前，所述方法还包括：所述VNFM接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息；所述VNFM创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息。
在一种可能的实现方式中，所述租户资源增加请求还包括所述租户的标识信息；所述VNFM接收NFVO发送的租户资源增加请求之后，所述方法还包括：所述VNFM根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
在一种可能的实现方式中，所述VNFM接收NFVO发送的租户资源增加请求之前，所述方法还包括：所述VNFM接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息；所述VNFM创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息。
在一种可能的实现方式中，所述VNFM接收所述NFVO发送的租户创建请求之后，所述方法还包括：所述VNFM与所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr通信确定所述CaaS Mgr是否可用；所述VNFM创建所述租户的资源记录信息，包括：若所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr可用，则所述VNFM创建所述租户的资源记录信息。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，创建租户和增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第二方面，本申请提供一种多租户场景下的租户资源管理方法，包括：VNFM接收NFVO发送的租户资源释放请求，所述租户资源释放请求包括请求释放的资源数量；所述VNFM根据所述请求释放的资源数量确定要释放的资源；所述VNFM向所述租户使用的CaaS Mgr发送节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；所述VNFM接收所述CaaS Mgr发送的第三反馈信息。
在一种可能的实现方式中，所述VNFM接收所述CaaS Mgr发送的第三反馈信息之后，所述方法还包括：所述VNFM根据所述第三反馈信息更新所述租户的资源记录信息；或者，所述VNFM向所述NFVO透传所述第三反馈信息。
在一种可能的实现方式中，所述租户资源释放请求还包括所述租户的标识信息；所述节点释放请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述租户资源释放请求还包括所述租户的标识信息；所述VNFM接收NFVO发送的租户资源释放请求之后，所述方法还包括：所述VNFM根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
在一种可能的实现方式中，所述VNFM接收所述CaaS Mgr发送的第三反馈信息之后， 所述方法还包括：所述VNFM接收所述NFVO发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；所述VNFM根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；若所述租户的资源已经全部释放，则所述VNFM删除所述租户的资源记录信息。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，释放租户资源和删除租户，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第三方面，本申请提供一种多租户场景下的租户资源管理方法，该方法的执行主体为CaaS Mgr，所述方法包括：接收VNFM发送的节点分配请求，所述节点分配请求包括分配给租户的资源的标识信息；将所述分配给租户的资源分配给所述租户；向所述VNFM发送第一反馈信息。
在一种可能的实现方式中，所述节点分配请求还包括所述租户的标识信息。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，创建租户和增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第四方面，本申请提供一种多租户场景下的租户资源管理方法，该方法的执行主体为CaaS Mgr，所述方法包括：接收VNFM发送的节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；将所述要释放的资源释放回资源池；向所述VNFM发送第三反馈信息。
在一种可能的实现方式中，所述节点释放请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述将所述要释放的资源释放回资源池之前，还包括：判断所述要释放的资源上是否承载有其他租户的业务；若所述要释放的资源上承载有其他租户的业务，则将所述其他租户的业务迁移至其他资源；所述将所述要释放的资源释放回资源池，包括：当所述要释放的资源空闲后，将所述要释放的资源释放回资源池。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，释放租户资源和删除租户，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第五方面，本申请提供一种多租户场景下的租户资源管理方法，该方法的执行主体为NFVO，所述方法包括：接收OSS发送的租户创建请求，所述租户创建请求包括所述租户的名称；创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的名称。
在一种可能的实现方式中，所述租户创建请求还包括所述租户使用的CaaS Mgr的标识信息；所述租户的资源记录信息还包括所述租户使用的CaaS Mgr的标识信息。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，创建租户和增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第六方面，本申请提供一种多租户场景下的租户资源管理方法，该方法的执行主体为NFVO，所述方法包括：接收OSS发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；若所述租户的资源已经全部释放，则删除所述租户的资源记录信息。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，释放租户资源和删除租户，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第七方面，本申请提供一种VNFM，包括：接收模块，用于接收NFVO发送的租户资源增加请求，所述租户资源增加请求包括租户请求增加的资源数量；处理模块，用于根据所述租户请求增加的资源数量和资源池中的空闲资源数量确定分配给所述租户的资源；发送模块，用于向所述租户使用的CaaS Mgr发送节点分配请求，所述节点分配请求包括所述分配给所述租户的资源的标识信息；所述接收模块，还用于接收所述CaaS Mgr发送的第一反馈信息。
在一种可能的实现方式中，所述处理模块，还用于根据所述第一反馈信息更新所述租户的资源记录信息；或者，所述发送模块，还用于向所述NFVO透传所述第一反馈信息。
在一种可能的实现方式中，所述处理模块，还用于根据所述租户请求增加的资源数量和所述资源池中的空闲资源数量确定是否需要创建新的资源；若需要创建新的虚拟机，则所述发送模块，还用于向VIM发送资源创建请求；所述接收模块，还用于接收所述VIM发送的第二反馈信息，所述第二反馈信息包括所述VIM新创建的资源的标识信息；所述处理模块，还用于将所述新创建的资源纳入所述资源池中。
在一种可能的实现方式中，所述租户资源增加请求还包括所述租户的标识信息；所述节点分配请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述接收模块，还用于接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息；所述处理模块，还用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息。
在一种可能的实现方式中，所述租户资源增加请求还包括所述租户的标识信息；所述处理模块，还用于根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
在一种可能的实现方式中，所述接收模块，还用于接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息；所述处理模块，还用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息。
在一种可能的实现方式中，所述处理模块，还用于与所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr通信确定所述CaaS Mgr是否可用；若所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr可用，则创建所述租户的资源记录信息。
在一种可能的实现方式中，所述接收模块，还用于接收网络功能虚拟化编排器NFVO发送的租户资源释放请求，所述租户资源释放请求包括请求释放的资源数量；所述处理模块，还用于根据所述请求释放的资源数量确定要释放的资源；所述发送模块，还用于向所述租户使用的容器即服务管理器CaaS Mgr发送节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；所述接收模块，还用于接收所述CaaS Mgr发送的第三反馈信息。
在一种可能的实现方式中，所述处理模块，还用于根据所述第三反馈信息更新所述租户的资源记录信息；或者，所述发送模块，还用于向所述NFVO透传所述第三反馈信息。
在一种可能的实现方式中，所述租户资源释放请求还包括所述租户的标识信息；所述 节点释放请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述租户资源释放请求还包括所述租户的标识信息；所述处理模块，还用于根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
在一种可能的实现方式中，所述接收模块，还用于接收所述NFVO发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；所述处理模块，还用于根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；若所述租户的资源已经全部释放，则删除所述租户的资源记录信息。
第八方面，本申请提供一种CaaS Mgr，包括：接收模块，用于接收VNFM发送的节点分配请求，所述节点分配请求包括分配给租户的资源的标识信息；处理模块，用于将所述分配给租户的资源分配给所述租户；发送模块，用于向所述VNFM发送第一反馈信息。
在一种可能的实现方式中，所述节点分配请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述接收模块，还用于接收VNFM发送的节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；所述处理模块，还用于将所述要释放的资源释放回资源池；所述发送模块，还用于向所述VNFM发送第三反馈信息。
在一种可能的实现方式中，所述节点释放请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述处理模块，还用于判断所述要释放的资源上是否承载有其他租户的业务；若所述要释放的资源上承载有其他租户的业务，则将所述其他租户的业务迁移至其他资源；当所述要释放的资源空闲后，将所述要释放的资源释放回资源池。
第九方面，本申请提供一种NFVO，包括：接收模块，用于接收OSS发送的租户创建请求，所述租户创建请求包括所述租户的名称；处理模块，用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的名称。
在一种可能的实现方式中，所述租户创建请求还包括所述租户使用的CaaS Mgr的标识信息；所述租户的资源记录信息还包括所述租户使用的CaaS Mgr的标识信息。
在一种可能的实现方式中，所述接收模块，还用于接收OSS发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；所述处理模块，还用于根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；若所述租户的资源已经全部释放，则删除所述租户的资源记录信息。
第十方面，本申请提供一种多租户场景下的租户资源管理方法，包括：NFVO向VNFM发送租户创建请求，租户创建请求包括租户的身份信息；VNFM创建租户的资源记录信息，租户的资源记录信息包括租户的身份信息。NFVO向VNFM发送租户资源增加请求，租户资源增加请求包括租户请求增加的资源数量；VNFM根据租户请求增加的资源数量和资源池中的空闲资源数量确定分配给租户的资源；VNFM向租户使用的CaaS Mgr发送节点分配请求，节点分配请求包括分配给租户的资源的标识信息；CaaS Mgr将分配给租户的资源分配给租户；CaaS Mgr向VNFM发送第一反馈信息；VNFM根据第一反馈信息更新租户的资源记录信息，将分配给租户的资源加入租户的资源记录信息中。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，由VNFM创建和维护租户记录信息，并增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第十一方面，本申请提供一种多租户场景下的租户资源管理方法，包括：NFVO根据OSS发送的租户创建请求创建租户的资源记录信息，租户的资源记录信息包括租户的身份信息。NFVO向VNFM发送租户资源增加请求，租户资源增加请求包括租户请求增加的资源数量；VNFM根据租户请求增加的资源数量和资源池中的空闲资源数量确定分配给租户的资源；VNFM向租户使用的CaaS Mgr发送节点分配请求，节点分配请求包括分配给租户的资源的标识信息；CaaS Mgr将分配给租户的资源分配给租户；CaaS Mgr向VNFM发送第一反馈信息；VNFM向NFVO发送第一反馈信息；NFVO根据第一反馈信息更新租户的资源记录信息，将分配给租户的资源加入租户的资源记录信息中。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，由NFVO创建和维护租户记录信息，由VNFM增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第十二方面，本申请提供一种多租户场景下的租户资源管理系统，所述系统包括：VNFM、CaaS Mgr和NFVO，所述VNFM采用上述第七方面中任一项所述的VNFM，所述CaaS Mgr采用上述第八方面中任一项所述的CaaS Mgr，所述NFVO采用上述第九方面中任一项所述的NFVO。其中，NFVO对外提供租户管理接口，NFVO可以通过租户管理接口与OSS连接，实现创建/删除租户、增加/删除/查询租户资源等功能。NFVO和VNFM之间也提供了租户管理接口，根据VNFM的定位，即若VNFM管理CaaS租户，则NFVO通过租户管理接口向VNFM透传所有租户管理相关请求，若VNFM不管理CaaS租户，只执行相关资源管理，则NFVO通过租户管理接口向VNFM发送增加/删除/查询租户资源请求。VNFM和CaaS Mgr之间提供了节点管理接口，用于在执行相关资源管理操作前后(例如创建/删除虚拟机)，将新增资源纳管到CaaS Mgr中，或请求CaaS Mgr删除即将删除的资源的信息。基于本申请提供的多租户场景下的租户资源管理系统，租户资源管理方法包括两种情况：第一种是不同租户共享CaaS Mgr，例如，整个MANO管理系统采用一个公共的CaaS Mgr，以不同网元代表不同租户，所有网元共享同一个CaaS Mgr，通过不同的网元实现租户之间的隔离。该情况下，VNFM在与CaaS Mgr的通信中需要携带租户的标识信息(例如，租户ID)，用于通知CaaS Mgr按照租户进行容器管理。第二种是不同租户使用不同的CaaS Mgr，例如，以厂商代表租户，每个厂商的网元只使用厂商自己提供的CaaS Mgr，通过不同的CaaS Mgr实现租户之间的隔离。该情况下，VNFM根据租户的标识信息识别对应的CaaS Mgr，在与CaaS Mgr的通信中不需要额外提供租户的标识信息。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，创建租户和增加租户资源或者释放租户资源和删除租户，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
第十三方面，本申请提供一种虚拟网元设备，包括：
一个或多个处理器；
存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实 现如上述第一至六方面中任一所述的方法。
第十四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质存储有指令，当所述指令在计算机上运行时，用于执行上述第一至六方面中任一项所述的方法。
第十五方面，本申请提供一种计算机程序，当所述计算机程序被计算机执行时，用于执行上述第一至六方面中任一项所述的方法。
第十六方面，本申请提供一种芯片，包括处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行如上述第一至六方面中任一项所述的方法。
附图说明
图1示出了本申请提供的多租户场景下的租户资源管理方法适用的应用场景；
图2为本申请多租户场景下的租户资源管理方法实施例一的流程图；
图3为本申请多租户场景下的租户资源管理方法实施例二的流程图；
图4为本申请多租户场景下的租户资源管理方法实施例三的流程图；
图5为本申请多租户场景下的租户资源管理方法实施例四的流程图；
图6为本申请虚拟网元节点实施例的结构示意图；
图7为本申请虚拟网络设备实施例的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书实施例和权利要求书及附图中的术语“第一”、“第二”等仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元。方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
图1示出了本申请提供的多租户场景下的租户资源管理方法适用的应用场景，该场景为针对多租户的虚拟资源的动态管理和编排(MANagement and Orchestration，MANO)管理系统，其中包括网络功能虚拟化编排器(Network Function Virtualization Orchestrator， NFVO)、虚拟网络功能管理器(Virtualized Network Functions Manager，VNFM)、虚拟基础设施管理器(Virtualised Infrastructure Manager，VIM)和容器即服务管理器(Container as a Service Manager，CaaS Mgr)。NFVO对外提供租户管理接口，NFVO可以通过租户管理接口与运营支撑系统(Operation Support System，OSS)连接，实现创建/删除租户、增加/删除/查询租户资源等功能。NFVO和VNFM之间也提供了租户管理接口，根据VNFM的定位，即若VNFM管理CaaS租户，则NFVO通过租户管理接口向VNFM透传所有租户管理相关请求，若VNFM不管理CaaS租户，只执行相关资源管理，则NFVO通过租户管理接口向VNFM发送增加/删除/查询租户资源请求。VNFM和CaaS Mgr之间提供了节点管理接口，用于在执行相关资源管理操作前后(例如创建/删除虚拟机)，将新增资源纳管到CaaS Mgr中，或请求CaaS Mgr删除即将删除的资源的信息。
本申请提供的多租户场景下的租户资源管理方法包括两种情况：第一种是不同租户共享CaaS Mgr，例如，整个MANO管理系统采用一个公共的CaaS Mgr，以不同网元代表不同租户，所有网元共享同一个CaaS Mgr，通过不同的网元实现租户之间的隔离。该情况下，VNFM在与CaaS Mgr的通信中需要携带租户的标识信息(例如，租户身份标识(identity，ID))，用于通知CaaS Mgr按照租户进行容器管理。第二种是不同租户使用不同的CaaS Mgr，例如，以厂商代表租户，每个厂商的网元只使用厂商自己提供的CaaS Mgr，通过不同的CaaS Mgr实现租户之间的隔离。该情况下，VNFM根据租户的标识信息识别对应的CaaS Mgr，在与CaaS Mgr的通信中不需要额外提供租户的标识信息。
图2为本申请多租户场景下的租户资源管理方法实施例一的流程图，如图2所示，本实施例的方法描述创建租户和增加租户资源的过程，该方法可以包括：
步骤201、OSS向NFVO发送租户创建请求。
该租户创建请求主要包括租户的身份信息，包括租户的名称、账号等，作为辅助还可以包括租户的简介等信息。
步骤202、NFVO创建租户的资源记录信息。
该租户的资源记录信息包括租户的身份信息，以及给该租户创建的标识信息(租户ID)，例如，NFVO可以以列表的形式记录租户的资源记录信息，每个租户对应一个条目，条目中包括该租户的ID、该租户的身份信息，对应于上述第二种情况还包括租户使用的CaaS Mgr的标识信息。本实施例中VNFM不负责管理CaaS租户，只执行相关资源管理，因此租户的资源记录信息由NFVO来创建并维护。
可选的，如果VNFM负责管理CaaS租户，NFVO就会将租户创建请求透传给VNFM，由VNFM创建租户的资源记录信息。
步骤203、NFVO向OSS反馈租户创建响应。
NFVO创建好租户的资源记录信息后，向OSS反馈创建响应，即通知OSS租户创建成功。
可选的，如果VNFM负责管理CaaS租户，则VNFM在创建租户的资源记录信息后先向NFVO发送租户创建响应，再由NFVO反馈给OSS。
步骤204、OSS向NFVO发送租户资源增加请求。
该租户资源增加请求包括请求增加资源的租户的标识信息(例如租户ID或租户名称)和请求增加的资源数量。OSS可以根据租户的请求获取该租户需要的资源数量，例如虚拟 机或者裸机数量，因此OSS在向NFVO请求增加资源时，除了提出请求的租户的标识信息，还携带了该租户请求增加的资源数量。
步骤205、NFVO将租户资源增加请求透传给VNFM。
租户的资源管理由VNFM和CaaS Mgr通过交互协调实现，因此NFVO将租户资源增加请求透传给VNFM。
步骤206、VNFM确定分配给租户的资源。
系统将空闲的资源全部纳入资源池，资源池即空闲资源的列表，其中记录了空闲的资源的标识信息和资源规格等。在给租户分配资源时(即网元部署)，VNFM根据租户请求增加的资源数量和资源池中的空闲资源数量，从资源池中进行选取，如果资源池中的空闲资源数量足够，则VNFM不用专门向虚拟化基础设施管理器(Virtualised Infrastructure Manager，VIM)申请新的资源。
可选的，如果资源池中的空闲的资源数量不够，则需要VNFM向VIM申请新的资源(图中虚线框中的步骤)。本实施例中，如果需要申请新的资源，VNFM根据资源池中的资源的规格(该数据可以预先配置到VNFM中，或是从特定的虚拟化网络功能描述符(VNF Descriptor，VNFD)中获取)向VIM发送资源创建请求，VIM创建完成后，向VNFM反馈第二反馈信息，该信息中携带了新创建的资源的标识信息，VNFM将新创建的资源纳入资源池中，即在空闲资源的列表中加入新创建的资源的信息，准备后续分配使用。
步骤207、VNFM向CaaS Mgr发送节点分配请求。
VNFM确定分配给租户的资源后，向CaaS Mgr发送节点分配请求，在该节点分配请求中携带上分配给租户的资源的标识信息。本实施例对应上述第一种情况，即不同租户共享CaaS Mgr，VNFM需要在节点分配请求中携带租户的标识信息，以使CaaS Mgr识别出是给哪个租户分配资源。本实施例对应上述第二种情况，即不同租户使用不同的CaaS Mgr，由于租户和其使用的CaaS Mgr具有对应关系，因此VNFM在节点分配请求中不需要携带租户的标识信息。
步骤208、CaaS Mgr纳管分配的资源。
CaaS Mgr根据节点分配请求中的租户的标识信息和资源的标识信息，纳管对应的资源，并将其分配给指定租户，例如对于K8S，CaaS Mgr通过其节点管理功能添加资源的标识信息对应的资源(例如虚拟机或者裸机)，并利用标签(label)机制给该资源添加“tenant＝租户ID”的标签，标识该资源已被分配给租户ID标识的租户。
步骤209、CaaS Mgr向VNFM发送第一反馈信息。
CaaS Mgr完成上述操作后向VNFM反馈处理结果，即通知VNFM资源分配完成。
步骤210、VNFM将第一反馈信息透传给NFVO。
本实施例中由NFVO负责管理CaaS租户，因此VNFM将第一反馈信息透传给NFVO，通知NFVO资源分配完成。
步骤211、NFVO根据第一反馈信息在租户的资源记录信息中增加分配给租户的资源的标识信息。
NFVO在收到反馈之后更新本地存放的租户的资源记录信息，在其中增加分配给租户的资源的标识信息，或者增加分配给租户的资源的数量。
后续MANO管理系统有部署容器网元的需求时，VNFM在向CaaS Mgr发送容器管 理请求时需要携带租户的标识信息(例如租户ID或租户名称)，租户的标识信息可从VNFM接收到的网元部署请求中获取，或是VNFM根据相关信息判断租户身份自行生成，例如根据网元提供商、网元类型/ID等判断租户的身份。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，创建租户和增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
图3为本申请多租户场景下的租户资源管理方法实施例二的流程图，如图3所示，本实施例的方法描述删除租户和释放租户资源的过程，该方法可以包括：
步骤301、OSS向NFVO发送租户资源释放请求。
该租户资源释放请求包括请求释放资源的租户的标识信息(例如租户ID或租户名称)和请求释放的资源数量。
步骤302、NFVO将租户资源释放请求透传给VNFM。
租户的资源管理由VNFM和CaaS Mgr通过交互协调实现，因此NFVO将租户资源释放请求透传给VNFM。
步骤303、VNFM确定要释放的资源。
VNFM根据要释放的资源数量选择要释放的资源。
步骤304、VNFM向CaaS Mgr发送节点释放请求。
VNFM确定要释放的资源后，向CaaS Mgr发送节点释放请求，在该节点分配请求中携带上要释放的资源的标识信息。本实施例对应上述第一种情况，即不同租户共享CaaS Mgr，VNFM需要在节点分配请求中携带租户的标识信息，以使CaaS Mgr识别出是给哪个租户分配资源。本实施例对应上述第二种情况，即不同租户使用不同的CaaS Mgr，由于租户和其使用的CaaS Mgr具有对应关系，因此VNFM在节点分配请求中不需要携带租户的标识信息。
步骤305、CaaS Mgr管理释放的资源。
CaaS Mgr根据节点释放请求中的租户的标识信息和资源的标识信息，释放相应的资源，例如对于K8S，CaaS Mgr通过其节点管理功能释放资源的标识信息对应的资源(例如虚拟机或者裸机)，并删除该资源的标签(label)。如果所选资源上仍有运行的容器实例，CaaS Mgr需要将容器实例部署在其他资源上，直到该资源上没有任何运行的容器实例，此时CaaS Mgr将所选资源释放回资源池。
步骤306、CaaS Mgr向VNFM发送第三反馈信息。
CaaS Mgr完成上述操作后向VNFM反馈处理结果，即通知VNFM资源释放完成。
步骤307、VNFM根据第三反馈信息在租户的资源记录信息中删除要释放的资源的标识信息。
VNFM在收到反馈之后更新本地存放的租户的资源记录信息，在其中删除释放的资源的标识信息，或者删除要释放的资源的数量。
步骤308、OSS向NFVO发送租户删除请求。
该租户删除请求包括租户的标识信息(例如租户ID或租户名称)。
步骤309、NFVO将租户删除请求透传给VNFM。
本实施例中，VNFM负责管理CaaS租户，租户的资源记录信息由VNFM来创建并维 护，因此NFVO将租户删除请求透传给VNFM。
步骤310、VNFM根据租户的资源记录信息确定租户的资源是否已经全部释放。
VNFM判断租户的所有资源是否都已释放，只有该租户不占用任何资源才可以删除该租户。
步骤311、若租户的资源已经全部释放，则VNFM删除租户的资源记录信息。
VNFM在确定租户的所有资源都已释放后，删除本地存放的租户的资源记录信息。
步骤312、VNFM向NFVO透传租户删除响应。
VNFM删除租户的资源记录信息后，向NFVO透传租户删除响应，即通过NFVO通知OSS租户删除成功。若VNFM删除租户失败，例如该租户的资源没有完全释放完，则VNFM通过NFVO通知OSS删除租户失败。
步骤313、NFVO向OSS反馈租户删除响应。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，释放租户资源和删除租户，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
图4为本申请多租户场景下的租户资源管理方法实施例三的流程图，如图4所示，本实施例的方法描述在上述第二种情况下创建租户和增加租户资源的过程，该方法可以包括：
步骤401、OSS向NFVO发送租户创建请求。
该租户创建请求主要包括租户的名称，作为辅助还可以包括租户的简介等信息。由于本实施例描述的是上述第二种情况，即不同租户使用不同的CaaS Mgr，因此租户创建请求中还携带了租户使用的CaaS Mgr的标识信息，例如CaaS Mgr的名称、IP地址等。
步骤402、NFVO将租户创建请求透传给VNFM。
本实施例中，VNFM负责管理CaaS租户，租户的资源记录信息由VNFM来创建并维护，因此NFVO将租户创建请求透传给VNFM。
步骤403、VNFM创建租户的资源记录信息。
该租户的资源记录信息包括租户的身份信息，给该租户创建的标识信息(租户ID)，以及租户使用的CaaS Mgr的标识信息，例如，VNFM可以以列表的形式记录租户的资源记录信息，每个租户对应一个条目，条目中包括该租户的ID、该租户的身份信息以及租户使用的CaaS Mgr的标识信息。
可选的，VNFM在创建租户的资源记录信息之前，VNFM根据CaaS Mgr的标识信息与对应的CaaS Mgr进行通信，确认该CaaS Mgr是可用的。
步骤404、VNFM向NFVO透传租户创建响应。
VNFM创建好租户的资源记录信息后，向NFVO透传租户创建响应，即通过NFVO通知OSS租户创建成功。
步骤405、NFVO向OSS反馈创建响应。
步骤406、OSS向NFVO发送租户资源增加请求。
该租户资源增加请求包括请求增加资源的租户的标识信息(例如租户ID或租户名称)和请求增加的资源数量。OSS可以根据租户的请求获取该租户需要的资源数量，例如虚拟机或者裸机数量，因此OSS在向NFVO请求增加资源时，除了提出请求的租户的标识信 息，还携带了该租户请求增加的资源数量。
步骤407、NFVO将租户资源增加请求透传给VNFM。
租户的资源管理由VNFM和CaaS Mgr通过交互协调实现，因此NFVO将租户资源增加请求透传给VNFM。
步骤408、VNFM确定分配给租户的资源。
系统将空闲的资源全部纳入资源池，资源池即空闲资源的列表，其中记录了空闲的资源的标识信息和资源规格等。在给租户分配资源时(即网元部署)，VNFM根据租户请求增加的资源数量和资源池中的空闲资源数量，从资源池中进行选取，如果资源池中的空闲资源数量足够，则VNFM不用专门向VIM申请新的资源。
可选的，如果资源池中的空闲的资源数量不够，则需要VNFM向VIM申请新的资源(图中虚线框中的步骤)。本实施例中，如果需要申请新的资源，VNFM根据资源池中的资源的规格(该数据可以预先配置到VNFM中，或是从特定的虚拟化网络功能描述符(VNF Descriptor，VNFD)中获取)向VIM发送资源创建请求，VIM创建完成后，向VNFM反馈第二反馈信息，该信息中携带了新创建的资源的标识信息，VNFM将新创建的资源纳入资源池中，即在空闲资源的列表中加入新创建的资源的信息，准备后续分配使用。
步骤409、VNFM向CaaS Mgr发送节点分配请求。
VNFM确定分配给租户的资源后，根据租户的资源记录信息中的CaaS Mgr的标识信息向相应的CaaS Mgr发送节点分配请求，在该节点分配请求中携带上分配给租户的资源的标识信息。由于本实施例描述的是上述第二种情况，即不同租户使用不同的CaaS Mgr，因此节点分配请求中不用携带租户的标识信息。
步骤410、CaaS Mgr纳管分配的资源。
CaaS Mgr根据节点分配请求中的资源的标识信息，纳管对应的资源。
步骤411、CaaS Mgr向VNFM发送第一反馈信息。
CaaS Mgr完成上述操作后向VNFM反馈处理结果，即通知VNFM资源分配完成。
步骤412、VNFM根据第一反馈信息在租户的资源记录信息中增加分配给租户的资源的标识信息。
本实施例中由VNFM负责管理CaaS租户，VNFM在收到反馈之后更新本地存放的租户的资源记录信息，在其中增加分配给租户的资源的标识信息，或者增加分配给租户的资源的数量。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，创建租户和增加租户资源，实现MANO管理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
图5为本申请多租户场景下的租户资源管理方法实施例四的流程图，如图5所示，本实施例的方法描述在上述第一种情况下删除租户和释放租户资源的过程，该方法可以包括：
步骤501、OSS向NFVO发送租户资源释放请求。
该租户资源释放请求包括请求释放资源的租户的标识信息(例如租户ID或租户名称)和请求释放的资源数量。由于本实施例描述的是上述第二种情况，即不同租户使用不同的CaaS Mgr，因此租户资源释放请求中还携带了租户使用的CaaS Mgr的标识信息，例如CaaS  Mgr的名称、IP地址等。
步骤502、NFVO将租户资源释放请求透传给VNFM。
租户的资源管理由VNFM和CaaS Mgr通过交互协调实现，因此NFVO将租户资源释放请求透传给VNFM。
步骤503、VNFM确定要释放的资源。
VNFM根据要释放的资源数量选择要释放的资源。
步骤504、VNFM向CaaS Mgr发送节点释放请求。
VNFM确定要释放的资源后，根据租户使用的CaaS Mgr的标识信息向相应的CaaS Mgr发送节点释放请求，在该节点分配请求中携带上要释放的资源的标识信息。由于本实施例描述的是上述第二种情况，即不同租户使用不同的CaaS Mgr，因此节点分配请求中不用携带租户的标识信息。
步骤505、CaaS Mgr管理释放的资源。
CaaS Mgr根据节点释放请求中的资源的标识信息，释放相应的资源，例如对于K8S，CaaS Mgr通过其节点管理功能释放资源的标识信息对应的资源(例如虚拟机或者裸机)。如果所选资源上仍有运行的容器实例，CaaS Mgr需要将容器实例部署在其他资源上，直到该资源上没有任何运行的容器实例，此时CaaS Mgr将所选资源释放回资源池。
步骤506、CaaS Mgr向VNFM发送第三反馈信息。
CaaS Mgr完成上述操作后向VNFM反馈处理结果，即通知VNFM资源释放完成。
步骤507、VNFM根据第三反馈信息在租户的资源记录信息中删除要释放的资源的标识信息。
VNFM在收到反馈之后更新本地存放的租户的资源记录信息，在其中删除释放的资源的标识信息，或者删除要释放的资源的数量。
步骤508、OSS向NFVO发送租户删除请求。
该租户删除请求包括租户的标识信息(例如租户ID或租户名称)。
步骤509、NFVO将租户删除请求透传给VNFM。
本实施例中，VNFM负责管理CaaS租户，租户的资源记录信息由VNFM来创建并维护，因此NFVO将租户删除请求透传给VNFM。
步骤510、VNFM根据租户的资源记录信息确定租户的资源是否已经全部释放。
VNFM判断租户的所有资源是否都已释放，只有该租户不占用任何资源才可以删除该租户。
步骤511、若租户的资源已经全部释放，则VNFM删除租户的资源记录信息。
VNFM在确定租户的所有资源都已释放后，删除本地存放的租户的资源记录信息。
步骤512、VNFM向NFVO透传租户删除响应。
VNFM删除租户的资源记录信息后，向NFVO透传租户删除响应，即通过NFVO通知OSS租户删除成功。若VNFM删除租户失败，例如该租户的资源没有完全释放完，则VNFM通过NFVO通知OSS删除租户失败。
步骤513、NFVO向OSS反馈租户删除响应。
本实施例，在MANO管理系统和CaaS Mgr平台中引入多租户概念，将资源池按照租户进行管理和划分，通过增加租户管理接口，释放租户资源和删除租户，实现MANO管 理系统中的多CaaS租户的管理功能，满足多租户场景下不同租户的应用的隔离。
图6为本申请虚拟网元节点实施例的结构示意图，如图6所示，本实施例的装置可以包括：接收模块601、处理模块602和发送模块603，本实施例的装置可以是图1所示场景中的VNFM，也可以是CaaS Mgr，还可以是NFVO。
对应于VNFM，接收模块601，用于接收NFVO发送的租户资源增加请求，所述租户资源增加请求包括租户请求增加的资源数量；处理模块602，用于根据所述租户请求增加的资源数量和资源池中的空闲资源数量确定分配给所述租户的资源；发送模块603，用于向所述租户使用的CaaS Mgr发送节点分配请求，所述节点分配请求包括所述分配给所述租户的资源的标识信息；所述接收模块601，还用于接收所述CaaS Mgr发送的第一反馈信息。
在一种可能的实现方式中，所述处理模块602，还用于根据所述第一反馈信息更新所述租户的资源记录信息；或者，所述发送模块603，还用于向所述NFVO透传所述第一反馈信息。
在一种可能的实现方式中，所述处理模块602，还用于根据所述租户请求增加的资源数量和所述资源池中的空闲资源数量确定是否需要创建新的资源；若需要创建新的虚拟机，则所述发送模块603，还用于向VIM发送资源创建请求；所述接收模块601，还用于接收所述VIM发送的第二反馈信息，所述第二反馈信息包括所述VIM新创建的资源的标识信息；所述处理模块602，还用于将所述新创建的资源纳入所述资源池中。
在一种可能的实现方式中，所述租户资源增加请求还包括所述租户的标识信息；所述节点分配请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述接收模块601，还用于接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息；所述处理模块602，还用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息。
在一种可能的实现方式中，所述租户资源增加请求还包括所述租户的标识信息；所述处理模块602，还用于根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
在一种可能的实现方式中，所述接收模块601，还用于接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息；所述处理模块602，还用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息。
在一种可能的实现方式中，所述处理模块602，还用于与所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr通信确定所述CaaS Mgr是否可用；若所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr可用，则创建所述租户的资源记录信息。
在一种可能的实现方式中，所述接收模块601，还用于接收网络功能虚拟化编排器NFVO发送的租户资源释放请求，所述租户资源释放请求包括请求释放的资源数量；所述处理模块602，还用于根据所述请求释放的资源数量确定要释放的资源；所述发送模块603，还用于向所述租户使用的容器即服务管理器CaaS Mgr发送节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；所述接收模块601，还用于接收所述CaaS Mgr发送的第三反馈信息。
在一种可能的实现方式中，所述处理模块602，还用于根据所述第三反馈信息更新所 述租户的资源记录信息；或者，所述发送模块603，还用于向所述NFVO透传所述第三反馈信息。
在一种可能的实现方式中，所述租户资源释放请求还包括所述租户的标识信息；所述节点释放请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述租户资源释放请求还包括所述租户的标识信息；所述处理模块602，还用于根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
在一种可能的实现方式中，所述接收模块601，还用于接收所述NFVO发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；所述处理模块602，还用于根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；若所述租户的资源已经全部释放，则删除所述租户的资源记录信息。
对应于CaaS Mgr，接收模块601，用于接收VNFM发送的节点分配请求，所述节点分配请求包括分配给租户的资源的标识信息；处理模块602，用于将所述分配给租户的资源分配给所述租户；发送模块603，用于向所述VNFM发送第一反馈信息。
在一种可能的实现方式中，所述节点分配请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述接收模块601，还用于接收VNFM发送的节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；所述处理模块602，还用于将所述要释放的资源释放回资源池；所述发送模块603，还用于向所述VNFM发送第三反馈信息。
在一种可能的实现方式中，所述节点释放请求还包括所述租户的标识信息。
在一种可能的实现方式中，所述处理模块602，还用于判断所述要释放的资源上是否承载有其他租户的业务；若所述要释放的资源上承载有其他租户的业务，则将所述其他租户的业务迁移至其他资源；当所述要释放的资源空闲后，将所述要释放的资源释放回资源池。
对应于NFVO，接收模块601，用于接收OSS发送的租户创建请求，所述租户创建请求包括所述租户的名称；处理模块602，用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的名称。
在一种可能的实现方式中，所述租户创建请求还包括所述租户使用的CaaS Mgr的标识信息；所述租户的资源记录信息还包括所述租户使用的CaaS Mgr的标识信息。
在一种可能的实现方式中，所述接收模块601，还用于接收OSS发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；所述处理模块602，还用于根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；若所述租户的资源已经全部释放，则删除所述租户的资源记录信息。
本实施例的装置，可以用于执行图2-5任一所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
图7为本申请虚拟网络设备实施例的结构示意图，如图7所示，该虚拟网络设备包括处理器701、存储器702、输入装置703和输出装置704；虚拟网络设备中处理器701的数量可以是一个或多个，图7中以一个处理器701为例；虚拟网络设备中的处理器701、存储器702、输入装置703和输出装置704可以通过总线或其他方式连接，图7中以通过总线连接为例。
存储器702作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请图2-5所示实施例中的方法对应的程序指令/模块。处理器701通过运行存储在存储器702中的软件程序、指令以及模块，从而执行虚拟网络设备的各种功能应用以及数据处理，即实现上述的多租户场景下的租户资源管理方法。
存储器702可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器702可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器702可进一步包括相对于处理器701远程设置的存储器，这些远程存储器可以通过网络连接至虚拟网络设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置703可用于接收输入的数字或字符信息，以及产生与虚拟网络设备的用户设置以及功能控制有关的键信号输入。输出装置704可包括显示屏等显示设备。
在一种可能的实现方式中，本申请提供一种计算机可读存储介质，该计算机可读存储介质存储有指令，当该指令在计算机上运行时，用于执行上述图2-5所示实施例中的方法。
在一种可能的实现方式中，本申请提供一种计算机程序，当所述计算机程序被计算机执行时，用于执行上述图2-5所示实施例中的方法。
在一种可能的实现方式中，本申请提供一种芯片，包括处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行图2-5所示实施例中的方法。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (22)

  1. 一种多租户场景下的租户资源管理方法，其特征在于，所述方法包括：
    虚拟网络功能管理器VNFM接收网络功能虚拟化编排器NFVO发送的租户资源增加请求，所述租户资源增加请求包括租户请求增加的资源数量；
    所述VNFM根据所述租户请求增加的资源数量和资源池中的空闲资源数量确定分配给所述租户的资源；
    所述VNFM向所述租户使用的容器即服务管理器CaaS Mgr发送节点分配请求，所述节点分配请求包括所述分配给所述租户的资源的标识信息；
    所述VNFM接收所述CaaS Mgr发送的第一反馈信息。
  2. 根据权利要求1所述的方法，其特征在于，所述VNFM接收所述CaaS Mgr发送的第一反馈信息之后，所述方法还包括：
    所述VNFM根据所述第一反馈信息更新所述租户的资源记录信息；或者，
    所述VNFM向所述NFVO透传所述第一反馈信息。
  3. 根据权利要求1或2所述的方法，其特征在于，所述VNFM接收NFVO发送的租户资源增加请求之后，所述方法还包括：
    所述VNFM根据所述租户请求增加的资源数量和所述资源池中的空闲资源数量确定是否需要创建新的资源；
    若需要创建新的虚拟机，则所述VNFM向虚拟基础设施管理器VIM发送资源创建请求；
    所述VNFM接收所述VIM发送的第二反馈信息，所述第二反馈信息包括所述VIM新创建的资源的标识信息；
    所述VNFM将所述新创建的资源纳入所述资源池中。
  4. 根据权利要求1-3中任一项所述的方法，其特征在于，所述租户资源增加请求还包括所述租户的标识信息；所述节点分配请求还包括所述租户的标识信息。
  5. 根据权利要求4所述的方法，其特征在于，所述VNFM接收NFVO发送的租户资源增加请求之前，所述方法还包括：
    所述VNFM接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息；
    所述VNFM创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息。
  6. 根据权利要求1-3中任一项所述的方法，其特征在于，所述租户资源增加请求还包括所述租户的标识信息；所述VNFM接收NFVO发送的租户资源增加请求之后，所述方法还包括：
    所述VNFM根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
  7. 根据权利要求6所述的方法，其特征在于，所述VNFM接收NFVO发送的租户资源增加请求之前，所述方法还包括：
    所述VNFM接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息；
    所述VNFM创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息。
  8. 根据权利要求7所述的方法，其特征在于，所述VNFM接收所述NFVO发送的租户创建请求之后，所述方法还包括：
    所述VNFM与所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr通信确定所述CaaS Mgr是否可用；
    所述VNFM创建所述租户的资源记录信息，包括：
    若所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr可用，则所述VNFM创建所述租户的资源记录信息。
  9. 一种多租户场景下的租户资源管理方法，其特征在于，包括：
    虚拟网络功能管理器VNFM接收网络功能虚拟化编排器NFVO发送的租户资源释放请求，所述租户资源释放请求包括请求释放的资源数量；
    所述VNFM根据所述请求释放的资源数量确定要释放的资源；
    所述VNFM向所述租户使用的容器即服务管理器CaaS Mgr发送节点释放请求，所述节点释放请求包括所述要释放的资源的标识信息；
    所述VNFM接收所述CaaS Mgr发送的第三反馈信息。
  10. 根据权利要求9所述的方法，其特征在于，所述VNFM接收所述CaaS Mgr发送的第三反馈信息之后，所述方法还包括：
    所述VNFM根据所述第三反馈信息更新所述租户的资源记录信息；或者，
    所述VNFM向所述NFVO透传所述第三反馈信息。
  11. 根据权利要求9或10所述的方法，其特征在于，所述租户资源释放请求还包括所述租户的标识信息；所述节点释放请求还包括所述租户的标识信息。
  12. 根据权利要求9或10所述的方法，其特征在于，所述租户资源释放请求还包括所述租户的标识信息；所述VNFM接收NFVO发送的租户资源释放请求之后，所述方法还包括：
    所述VNFM根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
  13. 根据权利要求11或12所述的方法，其特征在于，所述VNFM接收所述CaaS Mgr发送的第三反馈信息之后，所述方法还包括：
    所述VNFM接收所述NFVO发送的租户删除请求，所述租户删除请求包括所述租户的标识信息；
    所述VNFM根据所述租户的资源记录信息确定所述租户的资源是否已经全部释放；
    若所述租户的资源已经全部释放，则所述VNFM删除所述租户的资源记录信息。
  14. 一种虚拟网络功能管理器VNFM，其特征在于，包括：
    接收模块，用于接收网络功能虚拟化编排器NFVO发送的租户资源增加请求，所述租户资源增加请求包括租户请求增加的资源数量；
    处理模块，用于根据所述租户请求增加的资源数量和资源池中的空闲资源数量确定分配给所述租户的资源；
    发送模块，用于向所述租户使用的容器即服务管理器CaaS Mgr发送节点分配请求，所述节点分配请求包括所述分配给所述租户的资源的标识信息；
    所述接收模块，还用于接收所述CaaS Mgr发送的第一反馈信息。
  15. 根据权利要求14所述的VNFM，其特征在于，所述处理模块，还用于根据所述第一反馈信息更新所述租户的资源记录信息；或者，
    所述发送模块，还用于向所述NFVO透传所述第一反馈信息。
  16. 根据权利要求14或15所述的VNFM，其特征在于，所述处理模块，还用于根据所述租户请求增加的资源数量和所述资源池中的空闲资源数量确定是否需要创建新的资源；
    若需要创建新的虚拟机，则所述发送模块，还用于向虚拟基础设施管理器VIM发送资源创建请求；
    所述接收模块，还用于接收所述VIM发送的第二反馈信息，所述第二反馈信息包括所述VIM新创建的资源的标识信息；
    所述处理模块，还用于将所述新创建的资源纳入所述资源池中。
  17. 根据权利要求14-16中任一项所述的VNFM，其特征在于，所述租户资源增加请求还包括所述租户的标识信息；所述节点分配请求还包括所述租户的标识信息。
  18. 根据权利要求17所述的VNFM，其特征在于，所述接收模块，还用于接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息；
    所述处理模块，还用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息。
  19. 根据权利要求14-16中任一项所述的VNFM，其特征在于，所述租户资源增加请求还包括所述租户的标识信息；所述处理模块，还用于根据所述租户的标识信息确定所述租户使用的CaaS Mgr。
  20. 根据权利要求19所述的VNFM，其特征在于，所述接收模块，还用于接收所述NFVO发送的租户创建请求，所述租户创建请求包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息；
    所述处理模块，还用于创建所述租户的资源记录信息，所述租户的资源记录信息包括所述租户的身份信息和所述租户使用的CaaS Mgr的标识信息。
  21. 根据权利要求20所述的VNFM，其特征在于，所述处理模块，还用于与所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr通信确定所述CaaS Mgr是否可用；若所述租户使用的CaaS Mgr的标识信息所标识的CaaS Mgr可用，则创建所述租户的资源记录信息。
  22. 一种虚拟网元设备，其特征在于，包括：
    一个或多个处理器；
    存储器，用于存储一个或多个程序；
    当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-13中任一所述的方法。
PCT/CN2020/082884 2019-04-18 2020-04-02 多租户场景下的租户资源管理方法和装置 Ceased WO2020211652A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910313602.5 2019-04-18
CN201910313602.5A CN111835679B (zh) 2019-04-18 2019-04-18 多租户场景下的租户资源管理方法和装置

Publications (1)

Publication Number Publication Date
WO2020211652A1 true WO2020211652A1 (zh) 2020-10-22

Family

ID=72837739

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/082884 Ceased WO2020211652A1 (zh) 2019-04-18 2020-04-02 多租户场景下的租户资源管理方法和装置

Country Status (2)

Country Link
CN (1) CN111835679B (zh)
WO (1) WO2020211652A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113472745A (zh) * 2021-05-31 2021-10-01 山东英信计算机技术有限公司 一种基于selinux的openstack公有云多租户隔离方法、系统及终端
CN114462069A (zh) * 2022-04-12 2022-05-10 北京天维信通科技有限公司 多级租户资源访问管理方法、系统、智能终端及存储介质
CN116132176A (zh) * 2023-02-16 2023-05-16 安徽安联云服务有限公司 一种多租户智能云安全管理系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114629958B (zh) * 2022-03-15 2024-01-30 抖音视界有限公司 资源分配方法、装置、电子设备及存储介质
CN115695427A (zh) * 2022-10-31 2023-02-03 中国农业银行股份有限公司 云上多租户资源管理方法和装置
CN116389172B (zh) * 2023-06-05 2023-09-19 国网四川省电力公司信息通信公司 基于多租户的容器云平台资源安全管理方法
CN118827688A (zh) * 2023-11-10 2024-10-22 中国移动通信有限公司研究院 网络云租户管理方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105554015A (zh) * 2015-12-31 2016-05-04 北京轻元科技有限公司 多租户容器云计算系统的管理网络及方法
CN105630604A (zh) * 2015-12-18 2016-06-01 国云科技股份有限公司 一种基于sla的多租户虚拟机资源分配方法
CN106933648A (zh) * 2015-12-31 2017-07-07 中国电信股份有限公司 用于多租户容器资源管理的方法和系统
WO2018192543A1 (en) * 2017-04-19 2018-10-25 Huawei Technologies Co., Ltd. System and method for low latency node local scheduling in distributed resource management

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8307362B1 (en) * 2009-12-18 2012-11-06 Emc Corporation Resource allocation in a virtualized environment
US9009316B2 (en) * 2011-10-06 2015-04-14 Telefonaktiebolaget L M Ericsson (Publ) On-demand integrated capacity and reliability service level agreement licensing
CN103139159B (zh) * 2011-11-28 2015-11-25 上海贝尔股份有限公司 云计算架构中的虚拟机之间的安全通信
CN104142864A (zh) * 2014-08-07 2014-11-12 浪潮电子信息产业股份有限公司 一种基于虚拟化技术的多租户性能隔离框架
CN104253866B (zh) * 2014-09-20 2018-03-27 华为技术有限公司 虚拟网络功能网元的软件部署方法、系统及相关设备
CN105763485A (zh) * 2014-12-15 2016-07-13 中兴通讯股份有限公司 资源分配方法、装置和服务器
CN105847237B (zh) * 2016-03-15 2019-01-15 中国联合网络通信集团有限公司 一种基于nfv的安全管理方法和装置
US20180255137A1 (en) * 2017-03-02 2018-09-06 Futurewei Technologies, Inc. Unified resource management in a data center cloud architecture
CN107689953B (zh) * 2017-08-18 2020-10-27 中国科学院信息工程研究所 一种面向多租户云计算的容器安全监控方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105630604A (zh) * 2015-12-18 2016-06-01 国云科技股份有限公司 一种基于sla的多租户虚拟机资源分配方法
CN105554015A (zh) * 2015-12-31 2016-05-04 北京轻元科技有限公司 多租户容器云计算系统的管理网络及方法
CN106933648A (zh) * 2015-12-31 2017-07-07 中国电信股份有限公司 用于多租户容器资源管理的方法和系统
WO2018192543A1 (en) * 2017-04-19 2018-10-25 Huawei Technologies Co., Ltd. System and method for low latency node local scheduling in distributed resource management

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ITRI: "Network sharing for multi-tenant scenario", 3GPP TSG-SA WG1 MEETING #71, S1-152242, 21 August 2015 (2015-08-21), XP050990454, DOI: 20200619154714A *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113472745A (zh) * 2021-05-31 2021-10-01 山东英信计算机技术有限公司 一种基于selinux的openstack公有云多租户隔离方法、系统及终端
CN114462069A (zh) * 2022-04-12 2022-05-10 北京天维信通科技有限公司 多级租户资源访问管理方法、系统、智能终端及存储介质
CN114462069B (zh) * 2022-04-12 2022-07-22 北京天维信通科技有限公司 多级租户资源访问管理方法、系统、智能终端及存储介质
CN116132176A (zh) * 2023-02-16 2023-05-16 安徽安联云服务有限公司 一种多租户智能云安全管理系统

Also Published As

Publication number Publication date
CN111835679A (zh) 2020-10-27
CN111835679B (zh) 2022-03-25

Similar Documents

Publication Publication Date Title
US12020055B2 (en) VNF service instantiation method and apparatus
WO2020211652A1 (zh) 多租户场景下的租户资源管理方法和装置
US10701139B2 (en) Life cycle management method and apparatus
EP3471345B1 (en) Sla-based resource allocation method and nfvo
US11611481B2 (en) Policy management method and system, and apparatus
CN111698112A (zh) 一种容器化虚拟网络功能vnf的资源管理方法及装置
CN111221618B (zh) 一种容器化虚拟网络功能的部署方法和装置
CN114691567A (zh) 基于微服务的多云接口适配方法、系统及存储介质
WO2020011214A1 (zh) 管理虚拟化资源的方法和装置
WO2018024059A1 (zh) 一种虚拟化网络中业务部署的方法和装置
US20230261950A1 (en) Method of container cluster management and system thereof
US11442756B2 (en) Common service resource application method, related device, and system
EP3358790A1 (en) Network function virtualization resource processing method and virtualized network function manager
US20200133708A1 (en) Method for Managing VNF Instantiation and Device
WO2017035738A1 (zh) 一种资源管理方法及装置
WO2020135517A1 (zh) 部署虚拟化网络功能的方法和装置
WO2021088444A1 (zh) 实例化ns的方法及nfvo
CN109995552A (zh) Vnf服务实例化方法及装置
WO2023046026A1 (zh) 一种容器化vnf的部署方法及装置
CN109905258B (zh) PaaS的管理方法、装置及存储介质
WO2018014351A1 (zh) 一种资源配置方法及装置
CN109257201B (zh) 一种License的发送方法和装置
CN112889247B (zh) Vnf服务实例化方法及装置
WO2018014356A1 (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: 20791609

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20791609

Country of ref document: EP

Kind code of ref document: A1