[go: up one dir, main page]

WO2020211652A1 - Procédé et dispositif de gestion de ressources de locataires dans un scénario à locataires multiples - Google Patents

Procédé et dispositif de gestion de ressources de locataires dans un scénario à locataires multiples 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)
Chinese (zh)
Inventor
杨旭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of WO2020211652A1 publication Critical patent/WO2020211652A1/fr
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

La présente invention concerne, selon des modes de réalisation, un procédé et un dispositif de gestion de ressources de locataires dans un scénario à locataires multiples. Le procédé de gestion de ressources de locataire dans un scénario à locataires multiples de la présente invention comprend les étapes suivantes : un VNFM reçoit une demande d'augmentation de ressources de locataire envoyée par un NFVO, la demande d'augmentation de ressources de locataire comprenant le nombre des ressources objet de l'augmentation demandée par un locataire ; le VNFM détermine, sur la base du nombre de ressources objet de l'augmentation demandée par le locataire et du nombre de ressources inactives dans un groupe de ressources, une ressource à attribuer au locataire ; le VNFM envoie une demande d'attribution de nœud à un gestionnaire CAAS utilisé par le locataire, la demande d'attribution de nœud comprenant des informations d'identification concernant la ressource à attribuer au locataire ; et le VNFM reçoit des premières informations de rétroaction envoyées par le gestionnaire CAAS. La présente invention met en œuvre la fonction de gestion de locataires CAAS multiples dans un système de gestion MANO, ce qui permet d'isoler des applications de différents locataires dans un scénario à locataires multiples.
PCT/CN2020/082884 2019-04-18 2020-04-02 Procédé et dispositif de gestion de ressources de locataires dans un scénario à locataires multiples Ceased WO2020211652A1 (fr)

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 (fr) 2020-10-22

Family

ID=72837739

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/082884 Ceased WO2020211652A1 (fr) 2019-04-18 2020-04-02 Procédé et dispositif de gestion de ressources de locataires dans un scénario à locataires multiples

Country Status (2)

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

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 (fr) * 2017-04-19 2018-10-25 Huawei Technologies Co., Ltd. Système et procédé de planification locale de noeuds à faible latence dans la gestion de ressources distribuées

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 (fr) * 2017-04-19 2018-10-25 Huawei Technologies Co., Ltd. Système et procédé de planification locale de noeuds à faible latence dans la gestion de ressources distribuées

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 (fr) Procédé et dispositif de gestion de ressources de locataires dans un scénario à locataires multiples
US10701139B2 (en) Life cycle management method and apparatus
EP3471345B1 (fr) Procédé d'attribution de ressources fondé sur un sla et nfvo
US11611481B2 (en) Policy management method and system, and apparatus
CN111698112A (zh) 一种容器化虚拟网络功能vnf的资源管理方法及装置
CN111221618B (zh) 一种容器化虚拟网络功能的部署方法和装置
WO2020011214A1 (fr) Procédé et dispositif de gestion de ressource virtualisée
WO2018024059A1 (fr) Procédé et dispositif de déploiement de service dans un réseau virtualisé
US20230261950A1 (en) Method of container cluster management and system thereof
EP3358790A1 (fr) Procédé de traitement de ressource de virtualisation de fonction de réseau et gestionnaire de fonction de réseau virtualisée
WO2017035738A1 (fr) Procédé et dispositif de gestion de ressources
US11442756B2 (en) Common service resource application method, related device, and system
US20200133708A1 (en) Method for Managing VNF Instantiation and Device
WO2020135517A1 (fr) Procédé et dispositif de déploiement d'une fonction de réseau virtuel
WO2021088444A1 (fr) Procédé d'instanciation de ns et nfvo
CN109995552A (zh) Vnf服务实例化方法及装置
WO2023046026A1 (fr) Procédé et appareil de déploiement de vnf conteneurisée
CN109905258B (zh) PaaS的管理方法、装置及存储介质
WO2018014351A1 (fr) Procédé et appareil de configuration de ressources
CN109257201B (zh) 一种License的发送方法和装置
CN112889247B (zh) Vnf服务实例化方法及装置
WO2018014356A1 (fr) Procédé et appaeil de chargement

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