A multi-tenant management method and device

Abstract

A multi-tenant management method and device, in the method, by indicating information indicating whether the deployment position of the container object called by the VNF instance and the deployment position of other container objects called by the VNF instance are in the same spatial range, the isolation requirement of the VNF instance deployment is met, and the security of the VNF instance can be guaranteed. And, the spatial range, such as a container cluster or a namespace, is usually created by the NFVO, in the above scheme, the VNFM can request the CISM to deploy the container object in the spatial range managed by the CISM according to the identifier of the tenant carried in the instantiation request of the VNF, so that the VNFM can avoid the need to manage the container object on the premise of perceiving the spatial range in which the container object is deployed.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a multi-tenant management method and apparatus. Background Technology

[0002] Container as a Service (CaaS) is a new virtualization technology used by telecommunications operators in their cloud transformation towards internet technology (IT). In CaaS, a virtualized network function (VNF) invokes one or more container objects to implement its functionality, forming a containerized VNF. The lifecycle management of a containerized VNF is achieved through the management of the container objects it invokes.

[0003] In CaaS technology, each container object needs to be scheduled to run on corresponding node resources (including compute resources, storage resources, or network resources) in the container cluster. Therefore, from the perspective of the container cluster, multiple containerized VNFs form a multi-tenancy, where multiple tenants share node resources within the container cluster. Please refer to [reference needed]. Figure 1 This is a schematic diagram illustrating an example of multi-tenancy in a container cluster. Figure 1 It includes two container clusters, namely Container Cluster 1 and Container Cluster 2. Container Cluster 1 provides node resources for tenant 1 (e.g., VNF1), Container Cluster 1 and Container Cluster 2 provide node resources for tenant 2 (e.g., VNF2), and Container Cluster 2 provides node resources for tenant 3 (e.g., VNF3).

[0004] Considering the security of applications within a tenant, it may be necessary to isolate the container objects called by each tenant. Therefore, how to manage the aforementioned multi-tenancy is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a multi-tenant management method and apparatus for managing multi-tenant calls to a container cluster.

[0006] Firstly, a multi-tenant management method is provided, executed by a Virtualization Network Function Manager (VNFM). In this method, the VNFM first receives an instantiation request from a VNF, which includes the tenant identifier of the container object invoked by the VNF instance. Then, the VNFM obtains indication information indicating whether the container object invoked by the VNF is deployed in the same spatial scope as other container objects within the same tenant. This first indication, along with the identifier of the container object invoked by the VNF instance and the tenant identifier of the container object, is included in a container object creation request and sent to the Container Infrastructure Service Management (CISM). The CISM then creates the container object invoked by the VNF instance based on the information in the creation request. The spatial scope includes the container cluster and / or the namespace within the container cluster. Upon receiving the container object creation response from the CISM, the VNFM completes the instantiation of the VNF instance.

[0007] In the above technical solution, by indicating whether the container object invoked by the VNF instance and other container objects invoked by the same VNF instance are deployed in the same spatial range, the isolation requirement of the VNF instance deployment is met, thus ensuring the security of the VNF instance. Furthermore, the aforementioned spatial range, such as a container cluster or namespace, is typically created by NFVO. In this solution, the VNFM can request the CISM to deploy container objects within its managed spatial range based on the tenant identifier carried in the VNF instantiation request, thereby avoiding the need for the VNFM to be aware of the spatial range in which the container objects are deployed before managing them.

[0008] Furthermore, the above descriptions of spatial extent are merely two examples. In this application, spatial extent can also be a collection of spatial extents of other granularities, and no limitation is imposed here.

[0009] In one possible design, the instruction information may include, but is not limited to, the following two cases:

[0010] First scenario:

[0011] The instruction information includes the affinity / anti-affinity rules of the container object. The affinity / anti-affinity rules include the identifier of the affinity / anti-affinity group to which the container object belongs, as well as the scope of the affinity / anti-affinity group, which includes the aforementioned spatial range.

[0012] In the above technical solution, the indication information can be indicated by affinity / anti-affinity rules. In this application, the scope of the affinity / anti-affinity group in the affinity / anti-affinity rules can include not only sites and regions, but also the spatial scope in this application, which can increase the applicability of the affinity / anti-affinity rules.

[0013] In one possible design, affinity / anti-affinity rules can be stored in the Virtualized Network Function Descriptor (VNFD), so the VNFM can obtain affinity / anti-affinity rules from the VNFD corresponding to the VNF instance.

[0014] The second scenario:

[0015] The indication information includes the identifier of the spatial range used in the lifecycle management operations of the VNF instance.

[0016] In the above technical solution, the instruction information can be indicated according to the lifecycle management operation, and the spatial range identifier can be directly indicated in the lifecycle management operation, which is simple to implement.

[0017] In one possible design, when the VNFM needs to obtain indication information, the VNFM sends a lifecycle management permission request to the Network Functions Virtualization Orchestrator (NFVO) that includes the deployment location constraints of the VNF, the scope of which includes the aforementioned spatial range. Then, the VNFM receives a lifecycle management permission response from the NFVO, which includes the scope of the deployment location constraints that the NFVO permits the VNFM to use in lifecycle management operations. The scope of the deployment location constraints permitted by the NFVO is the indication information.

[0018] In the above technical solutions, the scope of deployment location constraints can include not only sites and regions, but also the spatial scope in this application, which can increase the applicability of deployment location constraints.

[0019] In addition, in the above technical solution, VNFM can obtain the instruction information through either of the two different methods mentioned above, which can increase the flexibility of the multi-tenancy management method.

[0020] In one possible design, the tenant identifier of the container object invoked by the VNF instance is either the identifier of the VNF instance or the identifier of the container object package used by the VNF instance.

[0021] In the above technical solution, tenant identification can be indicated by a variety of information, which can increase the flexibility of the solution.

[0022] Secondly, a multi-tenant management method is provided. This method is executed by a Network Functions Virtualization Orchestrator (NFVO). In this method, NFVO first receives an instantiation request for a Network Service (NS) instance, then determines the tenant identifier of the container object called by the Virtualized Network Functions (VNF) instances included in the NS instance, and obtains the Network Service Descriptor File (NSD) corresponding to the NS instance. The NSD includes affinity / anti-affinity groups between the VNF instances included in the NS instance. Finally, NFVO carries the affinity / anti-affinity groups and the tenant identifier in a multi-tenant management policy creation request and sends it to the Container Infrastructure Service Management (CISM). Upon receiving the creation request, CISM creates a multi-tenant management policy based on the affinity / anti-affinity groups and the tenant identifier. This multi-tenant management policy is used to indicate whether the container objects called by the tenant and other tenants are deployed in the same spatial scope. The spatial scope includes the container cluster and / or the namespace in the container cluster. The tenant and the other tenants are tenants of the container objects called by the VNF instances included in the NS instance.

[0023] In the above technical solution, NFVO can pre-create a multi-tenant management policy corresponding to each tenant in CISM. This multi-tenant management policy can be used to indicate whether container objects called by different tenants are deployed in the same spatial range, thereby meeting the isolation requirements of different VNF ​​instance deployments and ensuring the security of the VNF instance. Furthermore, in this application, the scope of application of the multi-tenant management policy can include not only sites and regions, but also the spatial range described in this application, thus increasing the applicability of the multi-tenant management policy.

[0024] Furthermore, the above descriptions of spatial extent are merely two examples. In this application, spatial extent can also be a collection of spatial extents of other granularities, and no limitation is imposed here.

[0025] In one possible design, the NFVO can send a VNF instance identifier creation request to the Virtualization Network Function Manager (VNFM) to create an identifier for the VNF instance included in the NS. Then, it receives a VNF instance identifier creation response from the VNFM, which includes the identifier of the VNF instance included in the NS instance. Thus, the NFVO maps the identifier of the VNF instance included in the NS instance to a tenant identifier, thereby determining the tenant identifier of the container object invoked by the VNF instance included in the NS instance.

[0026] In one possible design, the tenant identifier is the identifier of the container object package used by the VNF instance.

[0027] In the above technical solutions, the tenant identifier can be obtained by mapping the identifier of the VNF instance; alternatively, it can be obtained by mapping the identifier of the container object package used by the VNF instance, which can increase the flexibility of the multi-tenant management method.

[0028] In one possible design, NFVO can also receive a termination request for an NS instance that includes the identifier of the NS instance, and then determine the identifier of the tenant of the container object called by the VNF instance included in the NS instance based on the identifier of the NS instance, and send the tenant's identifier along with a deletion request in the multi-tenant management policy to CISM, thereby causing CISM to delete the multi-tenant management policy associated with the tenant's identifier.

[0029] In the above technical solution, after terminating the NS instance, the multi-tenancy management policy of the tenant corresponding to the NS instance in CISM can also be deleted to reduce the storage space occupied by invalid multi-tenancy management policies.

[0030] In one possible design, the multi-tenancy management strategy includes the identifier of the tenant of the container object, the identifier of the affinity / anti-affinity group to which the container object included by the tenant belongs, the type of affinity / anti-affinity, and the scope of the affinity / anti-affinity group, which includes the aforementioned spatial range.

[0031] In the above technical solution, the scope of the affinity / anti-affinity group in the multi-tenancy management strategy can include not only sites and regions, but also the spatial scope in this application, which can be the scope of application of the multi-tenancy management strategy.

[0032] Thirdly, a multi-tenant management method is provided, which is executed by the Container Infrastructure Service Management (CISM). In this method, CISM first receives a container object creation request sent by the Virtualization Network Function Manager (VNFM). The creation request includes the identifier of the container object requested by VNFM, the identifier of the tenant of the container object, and indication information. The indication information is used to indicate whether the container object is deployed in the same spatial range as other container objects in the same tenant, which includes the container cluster and / or the namespace in the container cluster. Then, CISM creates the container object according to the identifier of the container object, the identifier of the tenant of the container object, and the indication information, and sends a container object creation response to VNFM.

[0033] In the above technical solution, the indication information indicates whether the container object and other container objects in the same tenant are deployed in the same spatial range. In this way, CISM can create container objects according to the indication information to meet the isolation requirements of the VNF instance for container object deployment, and can ensure the security of the VNF instance.

[0034] Furthermore, the above descriptions of spatial extent are merely two examples. In this application, spatial extent can also be a collection of spatial extents of other granularities, and no limitation is imposed here.

[0035] In one possible design, the instruction information may include, but is not limited to, the following two cases:

[0036] First scenario:

[0037] The indication information includes the affinity / anti-affinity rules of the container object, which include the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group, which includes the aforementioned spatial range.

[0038] The second scenario:

[0039] The information includes the identifier of the spatial scope used in the lifecycle management operations of the tenant of this container object.

[0040] In the above technical solution, the instruction information can be indicated by either of the two different types of information, which can increase the flexibility of the multi-tenancy management method.

[0041] In one possible design, the process of creating a container object based on the instruction information according to CISM will also differ due to the different instruction information. Specifically:

[0042] In the first case described above, CISM first determines the deployment location of other container objects in the same tenant as the container object as a first spatial range; when the indication indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, the container object is created in the first spatial range; or, when the indication indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the container object is created in a second spatial range, wherein the first spatial range is different from the second spatial range.

[0043] In the second case described above, CISM directly creates the container object within the spatial range corresponding to the identifier of the spatial range.

[0044] In the above technical solutions, CISM can create the container object in multiple ways, which can increase the flexibility of CISM.

[0045] In one possible design, CISM can also receive a multi-tenant management policy creation request sent by the Network Functions Virtualization Orchestrator (NFVO). This creation request includes the tenant identifier of the container object invoked by the Virtualized Network Function (VNF) instance and the affinity / anti-affinity group between the VNF instance and other VNF instances of the NS instance. Then, CISM creates a multi-tenant management policy based on the affinity / anti-affinity group and the tenant identifier. The multi-tenant management policy is used to indicate whether the container objects invoked by the tenant and other tenants are deployed in the same spatial scope, which includes the container cluster and / or the namespace in the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

[0046] For an explanation of the multi-tenancy management strategy, please refer to the relevant content in the second section; it will not be repeated here.

[0047] In one possible design, CISM can also create the container object based on the container object's identifier, the container object's tenant identifier, indication information, and the multi-tenancy management policy created by NFVO, thereby increasing CISM's flexibility.

[0048] In one possible design, when the indication information includes the affinity / anti-affinity rules for the container object, CISM first determines the deployment locations of other container objects in the same tenant as the container object as a third spatial range. If the third spatial range satisfies the multi-tenancy management policy, and the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant, the container object is created in the third spatial range. Alternatively, if the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant, the container object is created in a fourth spatial range, which satisfies the multi-tenancy management policy.

[0049] In one possible design, CISM can also receive deletion requests for multi-tenant management policies sent by NFVO, which include the tenant's identifier. CISM then deletes the multi-tenant management policy associated with that tenant's identifier, thereby deleting invalid multi-tenant management policies and improving the utilization of storage space in CISM.

[0050] Fourthly, a multi-tenant management device is provided, which has the functionality of VNFM as described in the first aspect. This functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functionality. In one possible design, the device includes a processor and a transceiver, the processor being configured to handle the corresponding functions performed by the device in the above-described method. The transceiver is used to enable communication between the device and NFVO and CISM. The device may also include a memory coupled to the processor, which stores necessary program instructions and data for the device.

[0051] In one possible design, a processor and a transceiver are included, wherein:

[0052] Under the control of the processor, the transceiver receives instantiation requests for VNFs, and the instantiation requests include the tenant identifier of the container object invoked by the VNF;

[0053] The processor obtains indication information, which indicates whether the container object invoked by the VNF is deployed in the same spatial range as other container objects in the same tenant; the spatial range includes the container cluster and / or the namespace in the container cluster;

[0054] Under the control of the processor, the transceiver sends a container object creation request to the Container Infrastructure Service Management (CISM). The creation request includes the identifier of the container object, the identifier of the tenant of the container object invoked by the VNF, and the indication information. It also receives the container object creation response sent by the CISM and completes the instantiation of the VNF.

[0055] For details regarding the logical space scope, tenant identification, and instruction information, please refer to the relevant content in the first section; they will not be repeated here.

[0056] In one possible design, the processor obtains the affinity / anti-affinity rules from the virtualized network function descriptor (VNFD) corresponding to the VNF.

[0057] In one possible design, the transceiver, under the control of the processor, sends a lifecycle management permission request for the VNF to the Network Functions Virtualization Orchestrator (NFVO). The lifecycle management permission request includes a deployment location constraint for the VNF, the scope of which includes the spatial range. Then, it receives a lifecycle management permission response from the NFVO, the lifecycle management permission response including the scope of the deployment location constraint that the NFVO authorizes the device to use in lifecycle management operations. The scope of the deployment location constraint authorized by the NFVO is the indication information.

[0058] Fifthly, a multi-tenant management device is provided, which has the function of implementing NFVO in the second aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function. In one possible design, the device includes a processor and a transceiver, the processor being configured to process the corresponding function performed by the device in the above-described method. The transceiver is used to enable communication between the device and VNFM and CISM. The device may also include a memory coupled to the processor, which stores necessary program instructions and data for the device.

[0059] In one possible design, a processor and a transceiver are included, wherein:

[0060] Under the control of the processor, the transceiver receives instantiation requests for network service NS instances;

[0061] The processor determines the tenant identifier of the container object invoked by the Virtualized Network Function (VNF) instance included in the NS instance; and obtains the Network Service Descriptor File (NSD) corresponding to the NS instance, the NSD including affinity / anti-affinity groups between the VNF instances included in the NS instance;

[0062] Under the control of the processor, the transceiver sends a multi-tenant management policy creation request to the Container Infrastructure Service Management (CISM). The creation request includes the affinity / anti-affinity group and the tenant's identifier. The CISM creates a multi-tenant management policy based on the affinity / anti-affinity group and the tenant's identifier. The multi-tenant management policy is used to indicate whether the container objects invoked by the tenant and other tenants are deployed in the same spatial scope. The spatial scope includes the container cluster and / or the namespace in the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

[0063] For details regarding the logical space scope and multi-tenancy management strategy, please refer to the relevant content in the second section; it will not be repeated here.

[0064] In one possible design, the transceiver, under the control of the processor, sends a VNF instance identifier creation request to the Virtualization Network Function Manager (VNFM), the VNF instance identifier creation request being used to create identifiers for VNF instances included in the NS; and receives a VNF instance identifier creation response sent by the VNFM, the VNF instance identifier creation response including the identifiers of VNF instances included in the NS instance; the processor maps the identifiers of the VNF instances included in the NS instance to the tenant identifier.

[0065] In one possible design, the tenant identifier is the identifier of the container object package used by the VNF instance.

[0066] In one possible design, the transceiver, under the control of the processor, receives a termination request from the NS instance, the termination request including the identifier of the NS instance; the processor, based on the identifier of the NS instance, determines the identifier of the tenant of the container object invoked by the VNF instance included in the NS instance; the transceiver, under the control of the processor, sends a deletion request for the multi-tenant management policy to the CISM, the deletion request including the identifier of the tenant, and the CISM deletes the multi-tenant management policy associated with the identifier of the tenant.

[0067] Sixthly, a multi-tenant management device is provided, which has the functionality of CISM as described in the third aspect. This functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functionality. In one possible design, the device includes a processor and a transceiver, the processor being configured to handle the corresponding functionality performed by the device. The transceiver is used to enable communication between the device and VNFM and NFVO. The device may also include a memory coupled to the processor, which stores necessary program instructions and data for the device.

[0068] In one possible design, a processor and a transceiver are included, wherein:

[0069] Under the control of the processor, the transceiver receives a container object creation request sent by the Virtualization Network Function Manager (VNFM). The creation request includes the identifier of the container object requested by the VNFM, the identifier of the container object's tenant, and indication information. The indication information is used to indicate whether the container object is deployed in the same spatial range as other container objects in the same tenant. The spatial range includes the container cluster and / or the namespace in the container cluster.

[0070] The processor creates the container object according to the instruction information and controls the transceiver to send a container object creation response to the VNFM.

[0071] In one possible design, the indication information includes the affinity / anti-affinity rules of the container object, the affinity / anti-affinity rules including the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

[0072] In one possible design, the processor determines the deployment location of other container objects in the same tenant as the container object as a first spatial range; and, when the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, the processor creates the container object in the first spatial range; or, when the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the processor creates the container object in a second spatial range, wherein the first spatial range is different from the second spatial range.

[0073] In one possible design, the indication information includes an identifier of the spatial extent used in the lifecycle management operations of the container object's tenant.

[0074] In one possible design, the processor creates the container object within a spatial extent corresponding to the identifier of the spatial extent.

[0075] In one possible design, the transceiver, under the control of the processor, receives a multi-tenant management policy creation request sent by the Network Functions Virtualization Orchestrator (NFVO). The creation request includes the tenant identifier of the container object invoked by the Virtualized Network Function (VNF) instance and the affinity / anti-affinity group between the VNF instance and other VNF instances of the NS instance. The processor creates a multi-tenant management policy based on the affinity / anti-affinity group and the tenant identifier. The multi-tenant management policy indicates whether the container objects invoked by the tenant and other tenants are deployed in the same spatial scope, which includes the container cluster and / or namespaces within the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

[0076] In one possible design, the processor creates the container object based on the container object's identifier, the container object's tenant identifier, the indication information, and the multi-tenancy management policy.

[0077] In one possible design, the indication information includes affinity / anti-affinity rules for the container object; the processor determines the deployment locations of other container objects in the same tenant as the container object as a third spatial range; and, when it is determined that the third spatial range satisfies the multi-tenancy management policy, and the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, the container object is created in the third spatial range; or, when the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the container object is created in a fourth spatial range, the fourth spatial range satisfying the multi-tenancy management policy.

[0078] In one possible design, the transceiver, under the control of the processor, receives a deletion request for a multi-tenant management policy sent by the NFVO, the deletion request including the tenant's identifier; the processor deletes the multi-tenant management policy associated with the tenant's identifier.

[0079] In a seventh aspect, a multi-tenant management device is provided, which has the function of implementing VNFM in the above-described method. The communication device may include corresponding functional modules, such as a receiving module, an acquisition module, and a sending module, respectively used to implement the steps in the method of the first aspect.

[0080] In one possible design, the module includes a receiving module, an acquiring module, and a sending module, wherein:

[0081] A receiving module is used to receive instantiation requests for VNFs, wherein the instantiation request includes the identifier of the tenant of the container object invoked by the VNF;

[0082] The acquisition module is used to acquire indication information, which indicates whether the container object called by the VNF is deployed in the same spatial range as other container objects in the same tenant; the spatial range includes the container cluster and / or the namespace in the container cluster;

[0083] The sending module is used to send a container object creation request to the Container Infrastructure Service Management (CISM). The creation request includes the identifier of the container object, the identifier of the tenant of the container object invoked by the VNF, and the indication information.

[0084] The receiving module is also used to receive the creation response of the container object sent by the CISM, and to complete the instantiation of the VNF.

[0085] For details regarding the spatial scope, tenant identification, and signage information, please refer to the relevant content in the first section; they will not be repeated here.

[0086] In one possible design, the acquisition module is specifically used for:

[0087] The affinity / anti-affinity rules are obtained from the Virtualized Network Function Descriptor (VNFD) corresponding to the VNF.

[0088] In one possible design, the sending module is specifically used for:

[0089] Send a lifecycle management license request for the VNF to the Network Functions Virtualization Orchestrator (NFVO). The lifecycle management license request includes a deployment location constraint for the VNF, and the scope of the deployment location constraint includes the spatial range.

[0090] The receiving module is specifically used to: receive the lifecycle management license response sent by the NFVO, wherein the lifecycle management license response includes the scope within which the NFVO authorizes the device to use the deployment location constraint in the lifecycle management operation, and the scope within which the deployment location constraint is authorized by the NFVO is the indication information.

[0091] Eighthly, a multi-tenant management device is provided, which has the function of implementing NFVO in the above-described method. The communication device may include corresponding functional modules, such as a receiving module, a determining module, an acquiring module, and a sending module, respectively used to implement the steps in the method of the second aspect.

[0092] In one possible design, the module includes a receiving module, a determining module, an acquiring module, and a sending module, wherein:

[0093] The receiving module is used to receive instantiation requests for network service NS instances;

[0094] The determination module is used to determine the tenant identifier of the container object invoked by the Virtualized Network Function (VNF) instance included in the NS instance;

[0095] The acquisition module is used to acquire the network service descriptor file (NSD) corresponding to the NS instance, wherein the NSD includes affinity / anti-affinity groups between the VNF instances included in the NS instance;

[0096] The sending module is used to send a multi-tenant management policy creation request to the Container Infrastructure Service Management (CISM). The creation request includes the affinity / anti-affinity group and the tenant's identifier. The CISM creates a multi-tenant management policy based on the affinity / anti-affinity group and the tenant's identifier. The multi-tenant management policy is used to indicate whether the container objects invoked by the tenant and other tenants are deployed in the same spatial scope. The spatial scope includes the namespace in the container cluster and / or the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

[0097] For details regarding the scope of space and multi-tenancy management strategies, please refer to the relevant content in the second section; they will not be repeated here.

[0098] In one possible design, the sending module is specifically used for:

[0099] Send a VNF instance identifier creation request to the Virtualization Network Function Manager (VNFM), the VNF instance identifier creation request being used to create identifiers for the VNF instances included in the NS;

[0100] The receiving module is specifically used to: receive the VNF instance identifier creation response sent by the VNFM, wherein the VNF instance identifier creation response includes the identifier of the VNF instance included in the NS instance;

[0101] The determination module is specifically used to: map the identifier of the VNF instance included in the NS instance to the tenant identifier.

[0102] In one possible design, the tenant identifier is the identifier of the container object package used by the VNF instance.

[0103] In one possible design, the receiving module is also used for:

[0104] Receive a termination request from the NS instance, the termination request including the identifier of the NS instance;

[0105] The determining module is further configured to: determine the identifier of the tenant of the container object invoked by the VNF instance included in the NS instance, based on the identifier of the NS instance;

[0106] The sending module is also configured to: send a deletion request for a multi-tenant management policy to the CISM, wherein the deletion request includes the identifier of the tenant, and the CISM deletes the multi-tenant management policy associated with the identifier of the tenant.

[0107] Ninthly, a multi-tenant management device is provided, which has the function of implementing CISM in the above-described method. The communication device may include corresponding functional modules, such as a receiving module, a creating module, and a sending module, respectively used to implement the steps in the method of the third aspect.

[0108] In one possible design, the module includes a receiving module, a creating module, and a sending module, wherein:

[0109] The receiving module is used to receive a container object creation request sent by the Virtualization Network Function Manager (VNFM). The creation request includes the identifier of the container object requested by the VNFM, the identifier of the tenant of the container object, and indication information. The indication information is used to indicate whether the container object is deployed in the same spatial range as other container objects in the same tenant as the container object. The spatial range includes the container cluster and / or the namespace in the container cluster.

[0110] A creation module is used to create the container object based on the container object's identifier, the container object's tenant identifier, and the indication information;

[0111] The sending module is used to send a creation response for the container object to the VNFM.

[0112] For details regarding the scope of space and multi-tenancy management strategies, please refer to the relevant content in the third section; they will not be repeated here.

[0113] In one possible design, the creation module is specifically used for:

[0114] The deployment locations of other container objects of the tenant where the container object resides are defined as the first spatial range;

[0115] When the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, the container object is created in the first spatial range; or, when the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the container object is created in the second spatial range, wherein the first spatial range is different from the second spatial range.

[0116] In one possible design, the creation module is specifically used for:

[0117] Create the container object within the spatial range corresponding to the identifier of the spatial range.

[0118] In one possible design, the receiving module is further configured to:

[0119] Receive a multi-tenant management policy creation request sent by the Network Functions Virtualization Orchestrator (NFVO). The creation request includes the tenant identifier of the container object invoked by the Virtualized Network Function (VNF) instance and the affinity / anti-affinity group between the VNF instance and other VNF instances of the NS instance.

[0120] The creation module is further configured to create a multi-tenant management policy based on the affinity / anti-affinity group and the tenant's identifier. The multi-tenant management policy is used to indicate whether the container objects invoked by the tenant and other tenants are deployed in the same spatial range. The spatial range includes the container cluster and / or the namespace in the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

[0121] In one possible design, the creation module is specifically used for:

[0122] The container object is created based on the container object's identifier, the container object's tenant identifier, the instruction information, and the multi-tenancy management policy.

[0123] In one possible design, the indication information includes the affinity / anti-affinity rules of the container object, and the creation module is specifically used for:

[0124] The deployment locations of other container objects of the tenant where the container object resides are determined as the third spatial range;

[0125] If the third spatial range satisfies the multi-tenancy management policy, and the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, then the container object is created in the third spatial range; or,

[0126] When the indication information indicates that the container object is not deployed in the same spatial scope as other container objects in the same tenant as the container object, the container object is created in a fourth spatial scope, the fourth spatial scope satisfying the multi-tenancy management policy.

[0127] In one possible design, the receiving module is further configured to: receive a deletion request for a multi-tenant management policy sent by the NFVO, the deletion request including the tenant's identifier; the creating module is further configured to delete the multi-tenant management policy associated with the tenant's identifier.

[0128] In a tenth aspect, embodiments of this application also provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method performed by VNFM in the first aspect, NFVO in the second aspect, or CISM in the third aspect.

[0129] Eleventhly, embodiments of this application also provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method performed by VNFM in the first aspect, NFVO in the second aspect, or CISM in the third aspect.

[0130] In a twelfth aspect, embodiments of this application provide a chip system including a processor and potentially a memory for implementing the methods performed by VNFM in the first aspect, NFVO in the second aspect, or CISM in the third aspect. The chip system may be composed of chips or may include chips and other discrete devices.

[0131] The beneficial effects of the above-mentioned fourth to twelfth aspects and their implementation methods can be referred to the description of the beneficial effects of the methods and their implementation methods of the first, second or third aspects. Attached Figure Description

[0132] Figure 1 A diagram illustrating an example of multi-tenancy in a container cluster;

[0133] Figure 2 Architecture diagram of a Kubernetes container management and orchestration system;

[0134] Figure 3 This is a schematic diagram of an NFV architecture;

[0135] Figure 4 A flowchart illustrating an example of a multi-tenant management method provided in an embodiment of this application;

[0136] Figure 5 A schematic diagram illustrating an example of the spatial range provided in an embodiment of this application;

[0137] Figure 6 A flowchart illustrating another example of the multi-tenant management method provided in this application embodiment;

[0138] Figure 7 A schematic diagram illustrating an example of multi-tenant management provided in this application embodiment;

[0139] Figure 8 A schematic diagram illustrating another example of multi-tenant management provided in this application embodiment;

[0140] Figure 9 A schematic diagram illustrating another example of multi-tenant management provided in this application embodiment;

[0141] Figure 10 A schematic diagram illustrating another example of multi-tenant management provided in this application embodiment;

[0142] Figure 11 A schematic diagram illustrating another example of multi-tenant management provided in this application embodiment;

[0143] Figure 12 This is a schematic diagram illustrating another example of multi-tenant management provided in this application. Detailed Implementation

[0144] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0145] In this application embodiment, "multiple" refers to two or more. Therefore, in this application embodiment, "multiple" can also be understood as "at least two". "At least one" can be understood as one or more, such as one, two, or more. For example, including at least one means including one, two, or more, and it is not limited to which ones are included. For example, including at least one of A, B, and C, then it could include A, B, C, A and B, A and C, B and C, or A and B and C. "And / or" describes the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship. In this application embodiment, "call" and "use" can be used interchangeably.

[0146] Unless otherwise stated, the ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects, and are not used to limit the order, sequence, priority or importance of multiple objects.

[0147] The above describes some concepts involved in the embodiments of this application. The following describes the technical features involved in the embodiments of this application.

[0148] Please refer to Figure 2 This is an example of CaaS technology, an architecture diagram of a Kubernetes (K8S) container management and orchestration system.

[0149] Kubernetes divides the infrastructure resources in a container cluster into a Kubernetes master node and a group of worker nodes. The master node (also called the management node) runs a set of processes related to container cluster management, such as the Application Programming Interface Server (API server) and the Replication Controller (RC). These processes implement management functions for the entire container cluster, including resource management, pod scheduling, elastic scaling, security control, system monitoring, and error correction. Each worker node runs three components: kubelet, proxy, and docker, responsible for managing the lifecycle of pods on that node and implementing service proxy functions. Figure 2 As shown, a Pod can contain at least one container, so a Pod can be understood as a container warehouse composed of one or more containers.

[0150] Among them, the API Server provides the sole entry point for operating resource objects. All other components must operate on resource data through its provided API interface, and complete related business functions by performing "full query" and "change monitoring" on the relevant resource data.

[0151] The controller manager is the management and control center of the container cluster. Its main purpose is to automate the fault detection and recovery of the Kubernetes cluster. For example, it can perform Pod replication or removal according to the definition of RC to ensure that the number of Pod instances conforms to the definition of RC; it can perform the creation and updating of service endpoint objects according to the management relationship between services and Pods; it can perform node discovery, management and status monitoring; and it can clean up locally cached image files.

[0152] The kubelet component is responsible for the entire lifecycle management of Pods on this node, including creation, modification, monitoring, and deletion. At the same time, Kubelet periodically reports the status information of this node to the API Server.

[0153] The proxy component is used to implement service proxying and software-based load balancing.

[0154] The Docker component provides the runtime environment for containers.

[0155] Please refer to Figure 3This is a schematic diagram of an NFV architecture. This NFV architecture can implement various networks, such as local area networks (LANs), Internet Protocol (IP) networks, or evolved packet core (EPC) networks.

[0156] With the continuous development of virtualization technology, the industry has proposed introducing container management within the reference architecture of NFV Management and Orchestration (MANO). Please refer to... Figure 3 This is a deployment use case for an NFV MANO system management container cluster, defined by the NFV industry standards group under the European Telecommunications Standards Institute (ETSI).

[0157] like Figure 3 As shown, this deployment use case includes NFV-MANO 310, one or more operation support systems / business support systems (OSS / BSS) 320, multiple element managers (EM) 330, multiple VNFs 340, and NFV infrastructure (NFVI) 350.

[0158] OSS / BSS 320 is primarily designed for telecommunications service operators, providing comprehensive network management and business operation functions, including network management (such as fault monitoring and network information collection), billing management, and customer service management.

[0159] The EM 330 is used to perform traditional Fault Management, Configuration Management, Account Management, Performance Management, and Security Management (FCAPS) functions for VNFs.

[0160] VNF 340 corresponds to physical network functions (PNFs) in traditional non-virtualized networks, such as virtualized evolved packet core (EPC) nodes (e.g., mobility management entity (MME), serving gateway (SGW), public data network gateway (PGW), etc.). The functional behavior and state of network functions are independent of virtualization; NFV technology requirements demand that VNFs and PNFs have the same functional behavior and external interfaces.

[0161] A VNF 340 can be composed of one or more container objects. A container object can be understood as... Figure 2 Each pod can be deployed in a container cluster node resource pool. The resources in each container cluster node resource pool can be virtual machines (VMs) or bare metal servers. Each VM hosts one or more container objects.

[0162] NFVI 350 may include a virtual resource layer. This virtual resource layer may include multiple VMs, which can be used to form one or more container cluster node resource pools, for example, in... Figure 3 VM1 to VM3 form container cluster node resource pool 1, and VM4 to VM6 form container node resource pool 2.

[0163] NFV-MANO 310 may include an NFV orchestrator (NFVO) 311, one or more VNFMs 312, a container infrastructure service management (CISM) 313, a container cluster management (CCM) 314, and a virtualized infrastructure manager (VIM) 315.

[0164] Among them, NFVO is used to implement the management and processing of network service descriptors (NSD), virtual network function forwarding graphs (VNF forwarding graphs, VNFFG), network service lifecycle management, and, in conjunction with VNFM, to implement VNF ​​lifecycle management and global view of virtual resources.

[0165] VNFM manages the lifecycle of VNFs, including the management of Virtualized Network Function Descriptors (VNFDs), VNF instantiation, VNF instance elastic scaling (including scaling out / up and scaling in / down), VNF instance healing, and VNF instance termination. VNFM also supports receiving elastic scaling policies from NFVOs to achieve automated VNF elastic scaling.

[0166] VIM is primarily responsible for the management of resources in NFVI (including reservation and allocation), monitoring of virtual resource status and fault reporting, and providing virtualization resource pools for upper-layer applications.

[0167] CISM, also known as CaaS management, is responsible for managing container objects invoked by VNFs, including the creation, updating, and deletion of container objects. It also schedules container objects to the corresponding VM's node resources within the managed container cluster node resource pool. These node resources include compute, storage, and network resources. In the ETSI standard, the corresponding concept for a container object is a managed container infrastructure object (MCIO).

[0168] The CCM (Container Management Center) is responsible for managing the container cluster, including creating and scaling up or down the node resource pool used by the cluster. The container cluster is managed by a single management node (e.g., ...). Figure 2 In Kubernetes, the Master and a series of worker nodes (e.g., Figure 2 A container cluster is a collection of nodes. It is a dynamic system in which multiple containers can be deployed. The status of these containers and the communication between them can be monitored by a monitoring and management system. In the ETSI standard, the corresponding concept for a container cluster is a container infrastructure service cluster (CIS Cluster).

[0169] CISM and CCM provide management services for NFVO or VNFM to invoke their functions on the northbound interface.

[0170] Depend on Figure 3 As shown in the deployment use case, container objects can be directly invoked by VNFs, forming containerized VNFs. Therefore, from the perspective of the container cluster, multiple containerized VNFs form a multi-tenant container cluster, such as... Figure 1 As shown. In Figure 1 In the scenario shown, different tenants may be deployed in the same container cluster. For example, both VNF1 and VNF2 need to access node resources provided by container cluster 1, meaning both VNF1 and VNF2 need to be deployed in container cluster 1. Container objects accessed by the same tenant can also be deployed in different container clusters. For example, VNF2 needs to access node resources provided by both container cluster 1 and container cluster 2. For security reasons, it may be necessary to isolate the container objects accessed by different tenants. Therefore, when situations like... Figure 1 In the situation described, how to manage the multi-tenancy to ensure the security of each tenant's application operation is an urgent problem to be solved.

[0171] In view of this, embodiments of this application provide a multi-tenant management method. In this method, when the Virtualization Network Function Manager (VNFM) receives an instantiation request for a VNF (where the tenant of the container object invoked by the VNF refers to the VNF itself), including the identifier of the tenant of the container object invoked by the VNF, the VNFM obtains indication information indicating whether the container object invoked by the VNF is deployed in the same logical space as other container objects in the VNF. Then, the VNFM sends a container object creation request to the Container Infrastructure Service Management (CISM), carrying the identifier of the container object, the identifier of the tenant of the container object invoked by the VNF, and the indication information in the creation request. Upon receiving the creation request, the CISM creates the container object invoked by the VNF according to the pre-stored multi-tenant management policy and the indication information in the creation request, and sends a VNF instantiation response to the VNFM, completing the VNF instantiation process.

[0172] In the above technical solution, by indicating whether the container object called by the VNF instance and other container objects called by the same VNF instance are deployed in the same logical space, the isolation requirement of the VNF instance deployment is met, thus ensuring the security of the VNF instance. Furthermore, the logical space is typically created by the NFVO. In the above solution, the VNFM can request the CISM to deploy container objects within its managed logical space based on the tenant identifier carried in the VNF instantiation request, thereby avoiding the need for the VNFM to be aware of the logical space in which the container objects are deployed before managing them.

[0173] The deployment use cases and business scenarios of the NFV MANO system management container cluster described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0174] The technical solutions provided by the embodiments of this application are described below with reference to the accompanying drawings.

[0175] Please refer to Figure 4 This is a flowchart of a multi-tenant management method provided in an embodiment of this application.

[0176] In the following description, this method will be applied to... Figure 3 Taking the NFV MANO system management container cluster deployment example shown below, that is, NFVO, VNFM, and CISM in the following text can be... Figure 3 The diagram shows NFVO, VNFM, and CISM. Furthermore, this method can be executed by multiple communication devices, which can be NFVO, VNFM, CISM, or communication devices capable of supporting NFVO, VNFM, and CISM to implement the functions required by this method. Of course, other communication devices, such as chip systems, can also be used. There are no restrictions on the implementation methods of these multiple communication devices.

[0177] S401, NFVO receives the instantiation request for the network service NS instance.

[0178] In this embodiment of the application, the instantiation request for the NS instance can be Figure 3 The deployment use case shown is initiated by OSS / BSS, and there are no restrictions on the initiator of the instantiation request for this NS instance.

[0179] The instantiation request for the NS instance can include the NS instance's identifier. When NFVO receives this instantiation request, it can verify its correctness. For example, it can verify whether the NS instance's identifier carried in the instantiation request is correct. If the verification passes, NFVO will then execute the NS instantiation process.

[0180] S402, NFVO determines the identifier of the tenant of the container object invoked by the VNF instance included in the NS instance.

[0181] In this embodiment of the application, a tenant can be understood as a tenant established in a spatial range at different levels, and in this embodiment of the application, a tenant is used to indicate the VNF instance created.

[0182] The spatial range of different levels will be explained below.

[0183] In this application embodiment, the spatial scope may include, but is not limited to: site (or NFVI-PoP, also known as data center), zone, zone group, host, container cluster, and namespace. Site, zone, zone group, and host can be referred to as physical spatial scope, representing physically separated ranges of infrastructure resources at different levels or granularities. Container clusters and their namespaces can also be referred to as logical spatial scopes or virtual spatial scopes, which are abstractions of logical objects at different levels or granularities representing the set of nodes running a container application (e.g., containerized VNF). The concept of a container cluster has already been explained in the preceding introduction to CCM and will not be repeated here. A namespace is a logical grouping composed of a specific set of identifiers, resources, policies, and authorizations. This logical grouping can exclusively occupy a subset of node resources within the container cluster, allocating those node resources to objects represented by the identifiers within the logical group. For example, please refer to... Figure 5 ,exist Figure 3 In the deployment use case shown, each container cluster can include a CISM for managing that container cluster. This CISM provides NFVO with management functions such as namespace creation, reading, updating, and deletion. In other words, the namespaces are created by NFVO within the container cluster, and typically, VNFM is unaware of namespaces created by NFVO. This CISM can be deployed on one of the nodes within that container cluster. Figure 5As shown, container cluster 1 includes 4 nodes, and container cluster 2 includes 5 nodes. CISM is deployed on one node in each container cluster. Each node includes multiple resources; for example, the remaining 3 nodes in container cluster 1 include compute resources 1 to 4, and the remaining 4 nodes in container cluster 2 include compute resources 1' to 5'. NFVO can create two namespaces in container cluster 1, identified as b1 and b2. Namespace b1 occupies a portion of the resources of the 3 nodes in container cluster 1, for example, compute resources 1 and 2 on each of the remaining 3 nodes. Namespace b2 occupies the remaining portion of the resources of the 3 nodes in container cluster 1, for example, compute resources 3 and 4 on each of the remaining 3 nodes. The resources occupied by these two namespaces do not overlap. Figure 5 In the diagram, dashed arrows indicate the node resources occupied by each namespace. NFVO can create two namespaces in container cluster 2, identified as b3 and b4 respectively. Namespace b3 occupies a portion of the resources of the remaining four nodes in container cluster 2, for example, occupies computing resources 1' to 3' of each of the remaining four nodes; namespace b4 occupies another portion of the resources of the remaining four nodes in container cluster 2, for example, occupies computing resources 4' and 5' of each of the remaining four nodes. The node resources occupied by these two namespaces do not overlap. Of course, this embodiment does not limit the number of namespaces that NFVO creates in each container cluster.

[0184] Under the aforementioned different spatial ranges, the tenant can refer to a tenant within a container cluster, or it can refer to a tenant at a site across different container clusters, or it can refer to a tenant within a spatial range corresponding to a combination of the above-mentioned different spatial ranges. No restrictions are placed on the spatial range used by the tenant. For ease of explanation, the following description uses a tenant within a container cluster as an example.

[0185] As an example, in this embodiment of the application, NFVO can obtain the tenant identifier of the container object called by the VNF instance included in the NS instance by interacting with VNFM. Specifically, it can include the following steps:

[0186] When the NFVO receives the instantiation request for the NS, it first determines at least one VNF instance included in the NS instance. For example, the NFVO can obtain the network service descriptor (NSD) file of the NS based on the NS identifier carried in the NS instantiation request, and determine the VNF instances included in the NS based on the NSD. The number of VNF instances included in the NS can be one or more, without limitation. Then, the NFVO can send a VNF instance identifier creation request to the VNFM to create identifiers for the VNF instances included in the NS. This VNF instance identifier creation request can be used to create identifiers for all VNF instances included in the NS, or the NFVO can send one VNF instance identifier creation request for each VNF instance, without limitation on the number of VNF instance identifier creation requests. After receiving the VNF instance identifier creation request, the VNFM creates the identifier for the corresponding VNF instance and sends a VNF instance identifier creation response to the NFVO. The VNF instance identifier creation response includes the identifier of the VNF instance created by the VNFM. When NFVO receives the VNF instance identifier creation response, it maps the VNF instance identifier included in the VNF instance identifier creation response to the tenant identifier of the container object called by the corresponding VNF instance.

[0187] It should be noted that VNFM can also include container object packages used to describe templates for container objects. In the ETSI NFV standard, the concept corresponding to a container object package is a managed container infrastructure object package (MCIOP). In this case, when VNFM receives a VNF instance identifier creation request, it can also obtain the identifier of the container object package corresponding to the container object invoked by the VNF instance, and then send the identifier of the container object package in the VNF instance identifier creation response to the NFVO. The NFVO can then map the identifier of the container object package to the tenant identifier of the container object invoked by the corresponding VNF instance.

[0188] Of course, NFVO can also obtain the tenant identifier of the container object called by the VNF instance included in the NS instance through other methods, which will not be explained in detail here.

[0189] S403, NFVO retrieves the NSD corresponding to the NS instance.

[0190] NFVO can obtain the corresponding NSD based on the identifier of the NS instance. In this embodiment, the NSD includes the affinity / anti-affinity group between the VNF instances included in the NS instance. The affinity / anti-affinity group will be described below.

[0191] Affinity / anti-affinity groups are derived based on affinity / anti-affinity rules. Affinity / anti-affinity rules are a deployment strategy in NFV technology used to constrain the deployment requirements of virtualized functional objects (VNFs) to be deployed, ensuring their proximity or distance when mapped to actual physical resources. These VNFs can include one or more VNF components (VNFCs) that make up a VNF instance, or virtual links (VLs) used to connect various VNF instances.

[0192] For example, for VNFC, the affinity rules for VNFC virtualized compute resources stipulate that two or more VNFCs in an affinity group must be deployed on the same compute node, while the anti-affinity rules for VNFC virtualized compute resources stipulate that two or more VNFCs in an anti-affinity group must be deployed on different compute nodes. For Virtual Link (VL), the affinity rules for VL virtualized network resources stipulate that two or more VLs in an affinity group must be deployed on the same physical network connection, while the anti-affinity rules for VL virtualized network resources stipulate that two or more VLs in an anti-affinity group must be deployed on different physical network connections. These affinity / anti-affinity rules can also be understood as affinity / anti-affinity rules within a certain scope, which may include, but is not limited to: slots, racks, shelves, hosts, zones, zone groups, sites (or NFVI-PoPs), etc. For example, if the affinity / anti-affinity rule refers to a rule within a rack, then the affinity rule for VNFC's virtualized compute resources can be limited to two or more VNFCs within an affinity group that are to be deployed on compute nodes in the same rack. If the affinity / anti-affinity rule refers to a rule within a region, then the affinity rule for VNFC's virtualized compute resources can be limited to two or more VNFCs within an affinity group that are to be deployed on compute nodes in the same region. When the scope is other than that, the understanding of the affinity / anti-affinity rule can refer to the aforementioned explanation when the region scope is a rack or a region, which will not be illustrated here.

[0193] In this embodiment of the application, the scope of the affinity / anti-affinity rule has been expanded, as follows:

[0194] In the aforementioned description of affinity / anti-affinity rules, the scope of application of these rules included physical spaces such as server racks and slots. However, the scope of application of the affinity / anti-affinity rules in this embodiment not only includes the aforementioned physical space but also adds the space (or logical space) of the container cluster and / or the namespace within the container cluster. This physical space and logical space are used together to determine the deployment location of the container object invoked by the VNF instance. Since the scope of application of the affinity / anti-affinity rules in this embodiment includes this logical space, it can be guaranteed that the container object invoked by the VNF instance can be deployed to the same or different container clusters, or to the same or different namespaces, according to the affinity / anti-affinity rules.

[0195] It should be noted that the spatial scope indicated in the affinity / anti-affinity rule can be understood as indicating the type of spatial scope. For example, the spatial scope type can be divided into two types: container cluster and namespace under container cluster. In this case, the affinity / anti-affinity rule can only be used to indicate whether the container object called by the VNF instance and other container objects of the tenant are deployed in the same type of spatial scope, such as the same container cluster or the same namespace. However, there may be multiple spatial scopes of the same type. For example, there may be multiple container clusters, labeled as Container Cluster 1 to Container Cluster 3. If the affinity / anti-affinity rule indicates that the container object called by the VNF instance is deployed in the same container cluster as other container objects of the tenant, then the specific container cluster in which the container object called by the VNF instance is deployed cannot be indicated by the affinity / anti-affinity rule. The specific container cluster can be determined by CISM according to preset rules, which will not be elaborated here.

[0196] As an example, this application extends the "scope" attribute of affinity / anti-affinity rules in the VNF profile and virtual link profile of the NSD information model defined by the ETSI NFV standard, and the VDU profile and virtual link profile of the VNFD information model. For example, the "scope" attribute of local affinity or anti-affinity rule information units and affinity or anti-affinity group information units can be extended, without limitation. For example, the scope of the affinity / anti-affinity rule can be indicated by enumeration in the "scope" attribute, including sites (NFVI-PoP), zones, zone groups, nodes, container clusters, namespaces, etc.

[0197] As described above, the scope of affinity / anti-affinity rules has been expanded to include container clusters and namespaces. This allows rules to instruct all container objects within an affinity group to be deployed in the same container cluster or the same namespace; conversely, it can instruct all container objects within an anti-affinity group to be deployed in different container clusters or different namespaces. It's important to note that for anti-affinity groups, the physical and logical scopes can be defined together. For example, if an anti-affinity group's scope is a specific namespace, it can be understood that all container objects within that group are deployed in different namespaces within the same container cluster at the same site, or conversely, that all container objects within that group are deployed in different namespaces within different container clusters at the same site.

[0198] It should be noted that the execution order of steps S402 and S403 is not limited in this embodiment. Step S402 can be executed first, followed by step S403, or step S403 can be executed first, followed by step S402, or both steps S402 and S403 can be executed simultaneously. Figure 4 The example below uses the case of executing step S402 first and then step S403 as an example.

[0199] S404, NFVO sends a multi-tenancy management policy creation request to CISM, and CISM receives the multi-tenancy management policy creation request.

[0200] Once NFVO obtains the tenant identifier of the container object invoked by the VNF instance included in the NS and the affinity / anti-affinity group between the VNF instances included in the NS instance, it sends a multi-tenant management policy creation request to CISM. The creation request includes the affinity / anti-affinity group and the tenant identifier.

[0201] S405, CISM creates and stores multi-tenancy management policies based on the affinity / anti-affinity group and the tenant's identity.

[0202] In this embodiment, the multi-tenant management policy is used to indicate whether the container objects called by the tenant and other tenants are deployed in the same spatial range. The tenant and the other tenants are all tenants of the container objects called by the VNF instances included in the NS instance. For example, the NS instance includes three VNF instances, labeled VNF instance 1 to VNF instance 3. The tenants of the container objects called by VNF instances 1 to VNF instance 3 are identified as tenant 1 to tenant 3, respectively. CISM can then create a corresponding multi-tenant management policy for each tenant. The multi-tenant management policy corresponding to tenant 1 indicates whether the container objects called by tenant 1, tenant 2, and tenant 3 are deployed in the same spatial range; the multi-tenant management policy corresponding to tenant 2 indicates whether the container objects called by tenant 2, tenant 1, and tenant 3 are deployed in the same spatial range, and so on.

[0203] As an example, a multi-tenant management strategy includes the identifier of the container object's tenant, the identifier of the affinity / anti-affinity group to which the container object belongs, the type of affinity / anti-affinity, and the scope of the affinity / anti-affinity group. The rule type includes affinity or anti-affinity, and the scope of the rule can include any one or a combination of the aforementioned physical and logical scopes. Specifically, CISM can bind the acquired affinity / anti-affinity group and the tenant's identifier together to form a multi-tenant management strategy for the container object invoked by the tenant, which is stored in CISM. This multi-tenant management strategy can be represented as {tenant identifier (labeled tenantID), affinity or anti-affinity group identifier (labeled groupID), rule type, scope of rule}. For example, an example of a multi-tenant management strategy created by CISM is {tenant1, affinity group1, affinity, namespace1}, which means that the container object invoked by tenant1 is deployed in affinity group1, and all members within this affinity group are in the same namespace.

[0204] It should be noted that no restrictions are placed on the specific form of the multi-tenancy management strategy created by CISM.

[0205] At this point, NFVO has created a multi-tenant management policy in CISM for multiple tenants. Thus, when NFVO sends an instantiation request to VNFM to instantiate the VNF instances included in the NS, the required VNF instances can be created according to the multi-tenant management policy.

[0206] S406, CISM sends a multi-tenancy management policy creation response to NFVO, and NFVO receives the multi-tenancy management policy creation response.

[0207] S407, NFVO sends an instantiation request for a VNF instance to VNFM, and VNFM receives the instantiation request.

[0208] In this embodiment, the instantiation request includes the tenant identifier of the container object invoked by the VNF, i.e., the identifier of the VNF instance. It should be noted that if the NS includes multiple VNF instances, the NFVO needs to send an instantiation request for each VNF instance separately. For ease of explanation, the following description uses one of the instantiation requests sent by the NFVO as an example; the processing of other VNF instances and the process described below will not be repeated here.

[0209] S408, VNFM obtains instruction information.

[0210] In this embodiment, the indication information is used to indicate whether the container object invoked by the VNF is deployed in the same logical space as other container objects in the same tenant (i.e., the VNF instance). As an example, the indication information can be understood as the affinity / anti-affinity rule of the container object. In this case, when the VNFM receives an instantiation request for the VNF instance, it can obtain the Virtualization Network Function Descriptor File (VNFD) corresponding to the VNF instance based on the VNF instance's identifier, and retrieve the affinity / anti-affinity rule from the VNFD. As an example, the affinity / anti-affinity rule includes the affinity / anti-affinity rule type (e.g., affinity or anti-affinity) of the container object invoked by the VNF instance, the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group. This scope includes the aforementioned spatial range, and can be represented as: {identifier of affinity / anti-affinity group, rule type, scope of rule application}; or, the affinity / anti-affinity rule may also include the identifier of the container object, and can be represented as: {identifier of container object, identifier of affinity / anti-affinity group, rule type, scope of rule application}. Each piece of information included in the affinity / anti-affinity rule can be referred to the foregoing content, and will not be repeated here.

[0211] S409, VNFM sends a container object creation request to CISM, and CISM receives the container object creation request.

[0212] In this embodiment, the creation request includes the identifier of the container object to be created, the identifier of the container object's tenant (i.e., the identifier of the VNF instance), and the indication information (i.e., the affinity / anti-affinity rules of the container object). It should be noted that if the VNF calls multiple container objects, the VNFM can send multiple container object creation requests to the CISM to create these multiple container objects. Alternatively, the VNFM can send only one container object creation request, carrying the identifiers of the multiple container objects in that creation request. No restrictions are placed on the method by which the VNFM sends the container object creation request.

[0213] S410, CISM creates the container object based on the container object's identifier, the container object's tenant's identifier, and the indication information.

[0214] In this application embodiment, CISM can create container objects in ways including but not limited to the following two methods:

[0215] In the first approach, CISM creates a container object solely based on the container object's identifier, the tenant's identifier, and the indication information.

[0216] As an example, after receiving a creation request for a container object, CISM determines the location of the container cluster and / or the namespace within that cluster where the container object is deployed, based on the affinity / anti-affinity rules in the creation request. Then, it creates the container object at that determined location. Specifically, CISM first determines the deployment locations of other container objects within the same tenant as the container object, for example, a first spatial scope. This first spatial scope can be any of the aforementioned spatial scopes, such as a container cluster or a namespace. If the indication information indicates that the container object is deployed in the same spatial scope as other container objects within the same tenant, CISM creates the container object within that first spatial scope. If the indication information indicates that the container object is not deployed in the same spatial scope as other container objects within the same tenant, CISM selects a second spatial scope different from the first spatial scope and creates the container object within that second spatial scope.

[0217] For example, if CISM determines, based on the indication information, that the container objects invoked by the VNF instance are deployed in the same namespace within the same container cluster as other container objects invoked by the VNF instance, then CISM can determine which namespace to deploy the container objects invoked by the VNF instance in based on the availability of resources in the multiple namespaces it manages. For instance, if the container objects invoked by the VNF instance include container objects c1 to c3, and the indication information indicates that container object c1 is deployed in the same namespace as other container objects of the VNF instance (i.e., container objects c2 and c3), and the other container object c2 invoked by the VNF instance is already deployed in the namespace with identifier b1, or if other member container object c3 in the affinity group of container object c1 invoked by the VNF instance is already deployed in the namespace with identifier b1, and this namespace has sufficient resources to support the operation of container object c1, then CISM will also deploy container object c1 in the namespace with identifier b1. If the indication information suggests that container object c1 is deployed in a different namespace than other container objects of the VNF instance, and another container object c2 called by the VNF instance is already deployed in the namespace with identifier b1, or another member container object c3 in the affinity group of container object c1 called by the VNF instance is already deployed in the namespace with identifier b1, then CISM determines that container object c1 needs to be deployed in another namespace, for example, in the namespace with identifier b2. Of course, CISM can also determine in which namespace the container object called by the VNF instance is deployed based on other algorithms, which is not limited here.

[0218] In the second method, CISM creates a container object based on the container object's identifier, the container object's tenant identifier, pre-stored multi-tenancy management policies, and instruction information.

[0219] As an example, after CISM determines the location of the container cluster and / or the namespace under the container cluster where the container object is deployed based on the affinity / anti-affinity rules of the container object in the creation request, it can further confirm or adjust the location of the container cluster and / or the namespace under the container cluster where the container object is deployed based on the multi-tenant management policy stored in execution step S405, so as to avoid the tenant calling the container object using the container cluster or namespace used by other tenants that does not match the affinity / anti-affinity rules of the container object.

[0220] Specifically, CISM first determines the deployment locations of other container objects within the same tenant as the container object, such as a third space. Then, it determines whether the third space satisfies a multi-tenancy management policy. If the third space satisfies the policy, and the indication message indicates that the container object is deployed in the same space as other container objects within the same tenant, CISM creates the container object within that third space. If the indication message indicates that the container object is not deployed in the same space as other container objects within the same tenant, CISM determines a fourth space from other space ranges that satisfies the multi-tenancy management policy and creates the container object within that fourth space.

[0221] It should be noted that determining whether a certain spatial range meets the multi-tenancy management policy can be understood as follows: if the multi-tenancy management policy indicates that the tenant where the container object resides cannot deploy container objects of other tenants in the same spatial range, then determining whether a certain spatial range meets the multi-tenancy management policy means determining whether container objects of other tenants are created within that spatial range. If no container objects of other tenants are created within that spatial range, then the spatial range meets the multi-tenancy management policy; otherwise, it is determined that the spatial range does not meet the multi-tenancy management policy.

[0222] For example, CISM determines, based on the indication information, that the container object called by the VNF instance is deployed in the same namespace under the same container cluster as other container objects called by the VNF instance. Furthermore, based on the availability of resources in the multiple namespaces it manages, CISM determines that the container object called by the VNF instance should be deployed in the namespace with identifier b1. Then, CISM determines that other VNF instance container objects are also deployed in the namespace with identifier b1. Since the multi-tenant management policy stored in CISM instructs that the VNF instance cannot use the same namespace as other VNF instances, CISM readjusts the deployment location of the container object called by the VNF instance. For example, the container object called by the VNF instance can be deployed in the namespace with identifier b2.

[0223] S411, CISM sends a creation response for the container object to VNFM, and VNFM receives the creation response for the container object.

[0224] S412, VNFM sends a VNF instantiation response to NFVO, and NFVO receives the VNF instantiation response.

[0225] Once CISM successfully creates the container object invoked by the VNF instance, VNFM sends a response message to NFVO confirming the successful creation of the VNF instance.

[0226] Once NFVO confirms that the instantiation of the NS is complete, the instantiation of the NS is considered complete.

[0227] In the above technical solution, the affinity / anti-affinity rules of the container object directly indicate whether the container object called by the VNF instance is deployed in the same spatial scope (the same container cluster or the same namespace) as other container objects of the VNF instance. This satisfies the isolation requirements of the VNF instance deployment and ensures the security of the VNF instance. Furthermore, VNFM requests CISM to deploy container objects within its managed spatial scope based on the tenant identifier carried in the VNF instantiation request, thus eliminating the need for VNFM to be aware of the spatial scope in which the container objects are deployed before it can manage them.

[0228] Because infrastructure layer resources are limited, to make efficient use of these resources, an NS instance can be deleted after it has not been used for an extended period or is no longer needed. This can be achieved through the following steps:

[0229] S413, NFVO receives the termination request for the NS instance.

[0230] The termination request includes the identifier of the NS instance. This termination request can be sent by OSS / BSS, or by other devices; there are no restrictions on this.

[0231] S414, NFVO determines the tenant identifier of the container object invoked by the VNF instance included in the NS instance based on the identifier of the NS instance.

[0232] Specifically, after NFVO executes step S402 to obtain the identifier of the tenant (i.e., the VNF instance) of the container object called by the VNF instance included in the NS, it can store the tenant's identifier in NFVO, creating a mapping relationship between the identifier of the NS instance and the identifier of the tenant. Thus, NFVO can obtain the identifier of the tenant corresponding to the NS instance that needs to be terminated based on its stored mapping relationship. Of course, other methods can also be used to obtain the tenant's identifier; this is not limited here.

[0233] S415, NFVO removes the multi-tenancy management policy corresponding to the tenant in CISM.

[0234] Specifically, the NFVO can first send a deletion request for the multi-tenant management policy to the CISM, which includes the tenant's identifier. After receiving the deletion request, the CISM deletes the multi-tenant management policy associated with the tenant's (i.e., the VNF instance's) identifier and sends a deletion response for the multi-tenant management policy to the NFVO.

[0235] S416, NFVO sends a termination request for the VNF instance to VNFM, and VNFM receives the termination request for the VNF instance.

[0236] The termination request for this VNF instance includes the identifier of the VNF instance.

[0237] S417. VNFM sends a deletion request for the container object to CISM, and CISM receives the deletion request for the container object.

[0238] The deletion request includes the identifier of the container object invoked by the VNF instance.

[0239] S418, CISM rules for deleting container objects based on affinity / anti-affinity.

[0240] S419, CISM sends a deletion response to VNFM for the container object.

[0241] S420, VNFM sends a termination response for the VNF instance to NFVO, and NFVO receives the termination response for the VNF instance.

[0242] Once VNFM determines that CISM has successfully deleted all container objects invoked by the VNF instance, it sends a VNF termination response to NFVO.

[0243] Once NFVO receives termination responses for all VNFs included in the NS instance, it confirms that the termination of the NS is complete.

[0244] exist Figure 4 In the illustrated embodiment, affinity / anti-affinity rules of container objects are used to indicate whether the container object invoked by the VNF instance is deployed in the same container cluster or the same namespace as other container objects of the VNF instance, thereby achieving multi-tenancy management in the container cluster. In other embodiments, other information can also be used to indicate whether the container object invoked by the VNF instance is deployed in the same container cluster or the same namespace as other container objects of the VNF instance. For example, the placement constraint information in the VNF lifecycle management license operation can be used to perform the above-mentioned multi-tenancy management. The following describes an embodiment of using the placement constraint information in the VNF lifecycle management license operation to perform the above-mentioned multi-tenancy management.

[0245] Please refer to Figure 6 The flowchart is a further example of the multi-tenant management method provided in the embodiments of this application, and the flowchart is described as follows:

[0246] S601, NFVO receives the instantiation request for the network service NS instance.

[0247] S602, NFVO determines the identifier of the tenant (i.e., the VNF instance) of the container object invoked by the VNF instance included in the NS instance.

[0248] Steps S601 to S602 are similar to steps S401 to S402, and will not be described again here.

[0249] S603, NFVO sends an instantiation request for a VNF instance to VNFM, and VNFM receives the instantiation request.

[0250] The instantiation request includes the tenant identifier of the container object invoked by the VNF instance.

[0251] Step S603 is similar to step S406, and will not be described again here.

[0252] S604, VNFM sends a lifecycle management license request for VNF to NFVO, and NFVO receives the lifecycle management license request.

[0253] In this embodiment of the application, the lifecycle management license request includes the deployment location constraint of the VNF.

[0254] It should be noted that, in this embodiment of the application, the "range" attribute of the deployment location constraint has been expanded, as follows:

[0255] The scope of this deployment location constraint includes not only Figure 4 The physical space ranges such as server racks and slots in the illustrated embodiments also include, but are not limited to, the space ranges of container clusters and / or namespaces within container clusters (or, the namespaces of container clusters can be referred to as logical space ranges). These physical and logical space ranges together determine the deployment location of the container objects invoked by the VNF instance. Thus, this deployment location constraint information ensures that the container objects invoked by the VNF instance can be deployed to the same or different container clusters, or to the same or different namespaces.

[0256] As an example, this application extends the "Deployment Location Constraint" and "Constraint Resource Reference" information units in the VNF lifecycle management licensing operation defined in the ETSI NFV standard. For instance, in the "Scope" attribute of the "Deployment Location Constraint" information unit, the deployment location constraint scope of the VNF instance is indicated by enumeration, including sites, regions, region groups, nodes, container clusters, namespaces, etc. A new attribute, such as the "cismConnectionId" attribute, is added to the "Constraint Resource Reference" information unit, pointing to the CISM connection identifier.

[0257] Therefore, in this embodiment, the deployment location constraint of the VNF instance included in the lifecycle management license request can be represented as {deployment location constraint type, scope of the deployment location constraint, identifier of the container object invoked by the VNF instance}. The deployment location constraint type can include an affinity type or an anti-affinity type, the scope of the deployment location constraint includes, but is not limited to, the spatial range of the container cluster and / or the namespace within the container cluster, and the identifier of the container object invoked by the VNF instance can include {container object 1, container object 2, ..., container object n}. Of course, this deployment location constraint can also be represented in other forms, which are not limited here.

[0258] S605, NFVO sends a lifecycle management license response to VNFM, and VNFM receives the lifecycle management license response.

[0259] In this embodiment, the lifecycle management license response includes the scope of the deployment location constraint that the NFVO authorizes the VNFM to use in lifecycle management operations. For example, the scope of the deployment location constraint can be the same as the scope of the deployment location constraint carried in the lifecycle management license request in step S504. Alternatively, the NFVO can reset the scope of the deployment location constraint according to other strategies. The reset scope of the deployment location constraint may include, but is not limited to, the spatial range of the container cluster and / or the namespace within the container cluster. For example, if the NFVO authorizes the VNFM to use the deployment location constraint in lifecycle management operations within a specific container cluster or a namespace within a container cluster, then the identification information of the container cluster or the namespace can be carried in the lifecycle management license response. For example, the NFVO authorizes the VNFM to use the deployment location constraint in lifecycle management operations within a container cluster with identification information a1 or a namespace with identification information b1. It should be noted that in this case, the scope of the deployment location constraint authorized by the NFVO is the target spatial range determined by the identification information.

[0260] In this case, the scope of the deployment location constraint of the NFVO license can indicate whether the container object invoked by the VNF is deployed in the same spatial scope as other container objects in the same tenant. In other words, the VNFM obtains the indication information from the lifecycle management license response.

[0261] S606, VNFM sends a container object creation request to CISM, and CISM receives the container object creation request.

[0262] In this embodiment of the application, the creation request includes the scope of the deployment location constraints of the NFVO license, the identifier of the created container object, and the identifier of the tenant of the container object.

[0263] S607, CISM creates the container object for the VNF instance within the spatial range corresponding to the range constrained by the deployment location.

[0264] Specifically, CISM creates the container object in a second spatial range corresponding to the identifier of the spatial range indicated by the deployment location constraint.

[0265] For example, if the scope of the deployment location constraint is the namespace with the identifier b2, then CISM can deploy the container object called by the VNF instance in the namespace with the identifier b2.

[0266] It should be noted that, in the embodiments of this application, NFVO can also be adopted as follows: Figure 4In steps S402 to S405, a multi-tenant management policy is created in CISM. If a multi-tenant management policy is already pre-stored in CISM, CISM can also create the container object based on the pre-stored multi-tenant management policy and the deployment location constraint.

[0267] For example, CISM determines whether the second spatial range corresponding to the identifier of the spatial range indicated by the deployment location constraint satisfies the multi-tenancy management policy. If it does, the container object is created in the second spatial range; otherwise, the container object cannot be created. The determination of whether the second spatial range satisfies the multi-tenancy management policy is similar to the corresponding content in step S410 and will not be repeated here.

[0268] S608, CISM sends a creation response for the container object to VNFM, and VNFM receives the creation response for the container object.

[0269] S609, VNFM sends a VNF instantiation response to NFVO, and NFVO receives the VNF instantiation response.

[0270] Steps S608 to S609 are similar to steps S411 to S412, and will not be described again here.

[0271] In the embodiments provided above, the methods provided by this application have been described from the perspectives of NFVO, CISM, VNFM, and the interaction between the three. To implement the various functions of VNFM in the methods provided above, VNFM may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.

[0272] Figure 7 A schematic diagram of a multi-tenant management device 700 is shown. Device 700 can be a Virtual Network Provider (VNFM) capable of implementing the VNFM functionality provided in the embodiments of this application; device 700 can also be a device that supports VNFM in implementing the VNFM functionality provided in the embodiments of this application. Device 700 can be a hardware structure, a software module, or a hardware structure plus a software module. Device 700 can be implemented by a chip system. In the embodiments of this application, the chip system can be composed of chips or can include chips and other discrete devices.

[0273] The device 700 may include a receiving module 701, an acquisition module 702, and a sending module 703.

[0274] The receiving module 701 can be used to perform Figure 4Steps S407, S411, S416, and S419 in the illustrated embodiment may be used to perform... Figure 6 Steps S603, S605, and S608 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0275] Module 702 can be used to execute Figure 4 Step S408 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0276] The sending module 703 can be used to perform Figure 4 Steps S409, S417, and S420 in the illustrated embodiment may be used to perform... Figure 6 Steps S604, S606, and S609 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0277] The receiving module 701 and the transmitting module 703 are used for communication between the device 700 and other modules. They can be circuits, devices, interfaces, buses, software modules, transceivers, or any other device that can realize communication.

[0278] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0279] Figure 8 A schematic diagram of a multi-tenant management device 800 is shown. Device 800 can be an NFVO (NFVeelo), capable of implementing the NFVO functionality provided in the embodiments of this application; device 800 can also be any device capable of supporting NFVO to implement the NFVO functionality provided in the embodiments of this application. Device 800 can be a hardware structure, a software module, or a hardware structure plus a software module. Device 800 can be implemented by a chip system. In the embodiments of this application, the chip system can be composed of chips or can include chips and other discrete devices.

[0280] The device 800 may include a receiving module 801, a determining module 802, an acquiring module 803, and a sending module 804.

[0281] The receiving module 801 can be used to perform Figure 4 Steps S401, S406, S412, S413, S415, and S420 in the illustrated embodiment may be used to perform... Figure 6 Steps S601, S604, and S609 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0282] Module 802 can be used to execute Figure 4 Steps S402 and S414 in the illustrated embodiment may be used to perform Figure 6 Step S602 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0283] Module 803 can be used for execution Figure 4 Step S403 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0284] The sending module 804 can be used to perform Figure 4 Steps S404, S407, and S415-S416 in the illustrated embodiment may be used to perform... Figure 6 Steps S603 and S605 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0285] The receiving module 801 and the transmitting module 804 are used for communication between the device 800 and other modules. They can be circuits, devices, interfaces, buses, software modules, transceivers, or any other device that can realize communication.

[0286] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0287] Figure 9 A schematic diagram of a multi-tenant management device 900 is shown. The device 900 can be a CISM (Multi-Tenant Management System) capable of implementing the functions of the CISM in the methods provided in the embodiments of this application; the device 900 can also be a device that supports the CISM in implementing the functions of the CISM in the methods provided in the embodiments of this application. The device 900 can be a hardware structure, a software module, or a hardware structure plus a software module. The device 900 can be implemented by a chip system. In the embodiments of this application, the chip system can be composed of chips or can include chips and other discrete devices.

[0288] The device 900 may include a receiving module 901, a creating module 902, and a sending module 903.

[0289] The receiving module 901 can be used to perform Figure 4 Steps S404, S409, S415, and S417 in the illustrated embodiment may be used to perform... Figure 6 Step S606 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0290] Module 902 can be used for execution. Figure 4 Steps S405, S410, and S418 in the illustrated embodiment may be used to perform... Figure 6 Step S607 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0291] The sending module 903 can be used to perform Figure 4 Steps S406, S411, S415, and S419 in the illustrated embodiment may be used to perform... Figure 6 Step S608 in the illustrated embodiments, and / or other processes used to support the techniques described herein.

[0292] The receiving module 901 and the transmitting module 903 are used for communication between the device 900 and other modules. They can be circuits, devices, interfaces, buses, software modules, transceivers, or any other device that can realize communication.

[0293] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0294] The module division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in each embodiment of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0295] like Figure 10 The image shows a multi-tenant management device 1000 provided in an embodiment of this application. The multi-tenant management device 1000 based on a container cluster can be... Figure 4 or Figure 6 The NFVO in the illustrated embodiment can implement the NFVO function in the method provided in this application embodiment; the container cluster-based multi-tenant management device 1000 can also be a device that supports NFVO to implement the NFVO function in the method provided in this application embodiment. The container cluster-based multi-tenant management device 1000 can be a chip system. In this application embodiment, the chip system can be composed of chips or may include chips and other discrete devices.

[0296] The container cluster-based multi-tenant management device 1000 includes at least one processor 1020, used to implement or support the implementation of the NFVO function in the method provided in the embodiments of this application. For example, the processor 1020 can send a multi-tenant management policy creation request to CISM, as detailed in the method examples, which will not be repeated here.

[0297] The container cluster-based multi-tenant management device 1000 may further include at least one memory 1030 for storing program instructions and / or data. The memory 1030 is coupled to the processor 1020. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1020 may operate in conjunction with the memory 1030. The processor 1020 may execute program instructions stored in the memory 1030. At least one of the at least one memories may be included in the processor.

[0298] The container cluster-based multi-tenant management device 1000 may further include a communication interface 1010 for communicating with other devices via a transmission medium, thereby enabling devices in the container cluster-based multi-tenant management device 1000 to communicate with other devices. For example, the other device may be a VNFM (Virtual Non-Functional Module). The processor 1020 may use the communication interface 1010 to send and receive data.

[0299] This application embodiment does not limit the specific connection medium between the communication interface 1010, processor 1020, and memory 1030. This application embodiment... Figure 10 The memory 1030, processor 1020, and communication interface 1010 are connected via a bus 1040. Figure 10 The connections between other components are shown in bold and are for illustrative purposes only, not as limiting information. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0300] In the embodiments of this application, the processor 1020 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0301] In this embodiment, the memory 1030 can be non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in this embodiment can also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0302] like Figure 11 The image shows a multi-tenant management device 1100 provided in an embodiment of this application. The multi-tenant management device 1100 based on a container cluster can be... Figure 4 or Figure 6 The VNFM in the illustrated embodiment can implement the VNFM function in the method provided in this application embodiment; the container cluster-based multi-tenant management device 1100 can also be a device that supports VNFM to implement the VNFM function in the method provided in this application embodiment. The container cluster-based multi-tenant management device 1100 can be a chip system. In this application embodiment, the chip system can be composed of chips or may include chips and other discrete devices.

[0303] The container cluster-based multi-tenant management device 1100 includes at least one processor 1120, which is used to implement or support the implementation of the NFVO function in the method provided in the embodiments of this application. Exemplarily, the processor 1120 can obtain instruction information, as detailed in the method examples, which will not be repeated here.

[0304] The container cluster-based multi-tenant management device 1100 may further include at least one memory 1130 for storing program instructions and / or data. The memory 1130 is coupled to the processor 1120. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 1120 may operate in conjunction with the memory 1130. The processor 1120 may execute program instructions stored in the memory 1130. At least one of the at least one memories may be included in the processor.

[0305] The container cluster-based multi-tenant management device 1100 may further include a communication interface 1111 for communicating with other devices via a transmission medium, thereby enabling devices in the container cluster-based multi-tenant management device 1100 to communicate with other devices. For example, the other device may be an NFVO. The processor 1120 may use the communication interface 1111 to send and receive data.

[0306] This application embodiment does not limit the specific connection medium between the communication interface 1111, processor 1120, and memory 1130. This application embodiment... Figure 11 The memory 1130, processor 1120, and communication interface 1111 are connected via a bus 1140. Figure 11 The connections between other components are shown in bold and are for illustrative purposes only, not as limiting information. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0307] In the embodiments of this application, the processor 1120 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0308] In this embodiment, the memory 1130 can be non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in this embodiment can also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0309] like Figure 12 The image shows a multi-tenant management device 1200 provided in an embodiment of this application. The multi-tenant management device 1200 based on a container cluster can be... Figure 4 or Figure 6The CISM in the illustrated embodiment can implement the functions of CISM in the method provided in this application embodiment; the container cluster-based multi-tenant management device 1200 can also be a device that supports CISM to implement the functions of CISM in the method provided in this application embodiment. The container cluster-based multi-tenant management device 1200 can be a chip system. In this application embodiment, the chip system can be composed of chips or may include chips and other discrete devices.

[0310] The container cluster-based multi-tenant management device 1200 includes at least one processor 1220 for implementing or supporting the implementation of the CISM functionality in the methods provided in the embodiments of this application. For example, the processor 1220 can create multi-tenant management policies based on affinity / anti-affinity groups and tenant identifiers, as detailed in the method examples, which will not be repeated here.

[0311] The container cluster-based multi-tenant management device 1200 may further include at least one memory 1230 for storing program instructions and / or data. The memory 1230 is coupled to the processor 1220. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 1220 may operate in conjunction with the memory 1230. The processor 1220 may execute program instructions stored in the memory 1230. At least one of the at least one memory may be included in the processor.

[0312] The container cluster-based multi-tenant management device 1200 may further include a communication interface 1210 for communicating with other devices via a transmission medium, thereby enabling devices in the container cluster-based multi-tenant management device 1200 to communicate with other devices. For example, the other device may be a VNFM (Virtual Non-Functional Module). The processor 1220 may use the communication interface 1210 to send and receive data.

[0313] This application embodiment does not limit the specific connection medium between the communication interface 1210, processor 1220, and memory 1230. This application embodiment... Figure 12 The memory 1230, processor 1220, and communication interface 1210 are connected via a bus 1240. Figure 12 The connections between other components are shown in bold and are for illustrative purposes only, not as limiting information. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0314] In the embodiments of this application, the processor 1220 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0315] In this embodiment, the memory 1230 can be non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in this embodiment can also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0316] This application also provides a computer-readable storage medium, including instructions that, when executed on a computer, cause the computer to perform... Figure 4 or Figure 6 The methods performed in the illustrated embodiments are NFVO, VNFM, or CISM.

[0317] This application also provides a computer program product, including instructions that, when run on a computer, cause the computer to perform... Figure 4 or Figure 6 The methods performed in the illustrated embodiments are NFVO, VNFM, or CISM.

[0318] This application provides a chip system including a processor and potentially a memory, for implementing the functions of NFVO, VNFM, or CISM in the aforementioned methods. The chip system can be composed of chips or may include chips and other discrete devices.

[0319] This application provides a system that includes the aforementioned NFVO, VNFM, and CISM.

[0320] The methods provided in this application can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software or firmware, they can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disk, hard disk, magnetic tape), optical media (e.g., digital video disc (DVD)), or semiconductor media (e.g., SSD), etc.

[0321] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A multi-tenant management method, characterized in that, include: The Virtualization Network Function Manager (VNFM) receives an instantiation request for a VNF, the instantiation request including the tenant identifier of the container object invoked by the VNF; The VNFM obtains indication information, which is used to indicate whether the container object called by the VNF is deployed in the same spatial range as other container objects in the same tenant where the container object is located; The VNFM sends a container object creation request to the Container Infrastructure Service Management (CISM). The creation request includes the identifier of the container object, the identifier of the tenant of the container object invoked by the VNF, and the indication information, so that the CISM determines the spatial range in which the container object is deployed based on the identifier of the container object, the identifier of the tenant of the container object, and the indication information, and creates the container object in the determined spatial range. The spatial range includes the container cluster, or the spatial range includes the namespace in the container cluster. The VNFM receives the container object creation response sent by the CISM and completes the instantiation of the VNF.

2. The method according to claim 1, characterized in that, The indication information includes the affinity / anti-affinity rules of the container object, the affinity / anti-affinity rules include the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

3. The method according to claim 2, characterized in that, The VNFM acquires indication information, including: The VNFM obtains the affinity / anti-affinity rules from the virtualized network function descriptor (VNFD) corresponding to the VNF.

4. The method according to claim 1, characterized in that, The indication information includes an identifier of the spatial range used in the lifecycle management operations of the VNF.

5. The method according to claim 4, characterized in that, The VNFM acquires indication information, including: The VNFM sends a lifecycle management license request for the VNF to the Network Functions Virtualization Orchestrator (NFVO). The lifecycle management license request includes a deployment location constraint for the VNF, and the scope of the deployment location constraint includes the spatial range. The VNFM receives a lifecycle management license response from the NFVO. The lifecycle management license response includes the scope of the deployment location constraint that the NFVO authorizes the VNFM to use in lifecycle management operations. The scope of the deployment location constraint authorized by the NFVO is the indication information.

6. The method according to any one of claims 1-5, characterized in that, The tenant identifier of the container object invoked by the VNF instance is either the identifier of the VNF instance or the identifier of the container object package used by the VNF instance.

7. A multi-tenant management method, characterized in that, include: The Container Infrastructure Service Management (CISM) receives a container object creation request from the Virtualization Network Functions Manager (VNFM). The creation request includes the identifier of the container object requested by the VNFM, the identifier of the container object's tenant, and indication information. The indication information is used to indicate whether the container object is deployed in the same spatial range as other container objects in the same tenant. The CISM determines the spatial range in which the container object is deployed based on the identifier of the container object, the identifier of the tenant of the container object, and the indication information, wherein the spatial range includes the container cluster, or the spatial range includes the namespace in the container cluster; The CISM creates the container object within a defined spatial range; The CISM sends a container object creation response to the VNFM.

8. The method according to claim 7, characterized in that, The indication information includes the affinity / anti-affinity rules of the container object, the affinity / anti-affinity rules include the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

9. The method according to claim 8, characterized in that, The CISM determines the spatial range in which the container object is deployed based on the container object's identifier, the container object's tenant identifier, and the indication information, including: The deployment locations of other container objects of the tenant where the container object resides are defined as the first spatial range; When the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, the spatial range in which the container object is deployed is determined to be the first spatial range; or, when the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the spatial range in which the container object is deployed is determined to be the second spatial range, wherein the first spatial range is different from the second spatial range.

10. The method according to claim 7, characterized in that, The indication information includes an identifier of the spatial extent used in the lifecycle management operations of the tenant of the container object.

11. The method according to claim 10, characterized in that, The CISM determines the spatial range in which the container object is deployed based on the container object's identifier, the container object's tenant identifier, and the indication information, including: The spatial range in which the container object is deployed is determined based on the spatial range corresponding to the identifier of the spatial range.

12. The method according to claim 7, characterized in that, The method further includes: The CISM receives a multi-tenant management policy creation request sent by the Network Function Virtualization Orchestrator (NFVO). The creation request includes the tenant identifier of the container object invoked by the Virtual Network Function (VNF) instance and the affinity / anti-affinity group between the VNF instance and other VNF instances of the NS instance. The CISM creates a multi-tenant management policy based on the affinity / anti-affinity group and the tenant's identifier. The multi-tenant management policy is used to indicate whether the container objects invoked by the tenant and other tenants are deployed in the same spatial scope. The spatial scope includes the container cluster, or the spatial scope includes the namespace in the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

13. The method according to claim 12, characterized in that, The multi-tenancy management strategy includes the identifier of the tenant of the container object, the identifier of the affinity / anti-affinity group to which the container object included by the tenant belongs, the type of affinity / anti-affinity, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

14. The method according to claim 12 or 13, characterized in that, The CISM determines the spatial range in which the container object is deployed based on the container object's identifier, the container object's tenant identifier, and the indication information, including: The CISM determines the spatial range in which the container object is deployed based on the container object's identifier, the container object's tenant identifier, the instruction information, and the multi-tenancy management policy.

15. The method according to claim 14, characterized in that, The indication information includes the affinity / anti-affinity rules of the container object. The CISM determines the spatial range in which the container object is deployed based on the container object's identifier, the container object's tenant identifier, the indication information, and the multi-tenancy management policy, including: The deployment locations of other container objects of the tenant where the container object resides are determined as the third spatial range; If the third spatial range satisfies the multi-tenancy management strategy, and the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, then the spatial range where the container object is deployed is determined to be the third spatial range; or, When the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the spatial range where the container object is deployed is determined to be the fourth spatial range, and the fourth spatial range satisfies the multi-tenancy management strategy.

16. The method according to any one of claims 12-13, characterized in that, The method further includes: The CISM receives a deletion request for the multi-tenancy management policy sent by the NFVO, and the deletion request includes the tenant's identifier; The CISM removes the multi-tenancy management policy associated with the tenant's identity.

17. A multi-tenant management device, characterized in that, include: A receiving module is used to receive instantiation requests for VNFs, wherein the instantiation request includes the identifier of the tenant of the container object invoked by the VNF; The acquisition module is used to acquire indication information, which indicates whether the container object called by the VNF is deployed in the same spatial range as other container objects in the same tenant; the sending module is used to send a container object creation request to the Container Infrastructure Service Management (CISM), which includes the identifier of the container object, the identifier of the tenant of the container object called by the VNF, and the indication information, so that the CISM determines the spatial range in which the container object is deployed based on the identifier of the container object, the identifier of the tenant of the container object, and the indication information, and creates the container object in the determined spatial range, wherein the spatial range includes the container cluster, or the spatial range includes the namespace in the container cluster; The receiving module is also used to receive the creation response of the container object sent by the CISM, and to complete the instantiation of the VNF.

18. The apparatus according to claim 17, characterized in that, The indication information includes the affinity / anti-affinity rules of the container object, the affinity / anti-affinity rules include the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

19. The apparatus according to claim 18, characterized in that, The acquisition module is specifically used for: The affinity / anti-affinity rules are obtained from the Virtualized Network Function Descriptor (VNFD) corresponding to the VNF.

20. The apparatus according to claim 17, characterized in that, The indication information includes an identifier of the spatial range used in the lifecycle management operations of the VNF.

21. The apparatus according to claim 20, characterized in that, The sending module is specifically used for: Send a lifecycle management license request for the VNF to the Network Functions Virtualization Orchestrator (NFVO). The lifecycle management license request includes a deployment location constraint for the VNF, and the scope of the deployment location constraint includes the spatial range. The receiving module is specifically used to: receive a lifecycle management license response sent by the NFVO, wherein the lifecycle management license response includes the scope within which the NFVO authorizes the device to use the deployment location constraint in lifecycle management operations, and the scope within which the deployment location constraint is authorized by the NFVO is the indication information.

22. The apparatus according to any one of claims 17-21, characterized in that, The tenant identifier of the container object invoked by the VNF instance is either the identifier of the VNF instance or the identifier of the container object package used by the VNF instance.

23. A multi-tenant management device, characterized in that, include: The receiving module is used to receive a container object creation request sent by the Virtualization Network Function Manager (VNFM). The creation request includes the identifier of the container object to be created by the VNFM, the identifier of the tenant of the container object, and indication information. The indication information is used to indicate whether the container object is deployed in the same spatial range as other container objects in the same tenant as the container object. A creation module is used to determine the spatial range in which the container object is deployed based on the identifier of the container object, the identifier of the tenant of the container object, and the indication information, and to create the container object in the determined spatial range, wherein the spatial range includes the container cluster, or the spatial range includes the namespace in the container cluster; The sending module is used to send a creation response for the container object to the VNFM.

24. The apparatus according to claim 23, characterized in that, The indication information includes the affinity / anti-affinity rules of the container object, the affinity / anti-affinity rules include the identifier of the affinity / anti-affinity group to which the container object belongs, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

25. The apparatus according to claim 24, characterized in that, The creation module is specifically used for: The deployment locations of other container objects of the tenant where the container object resides are defined as the first spatial range; When the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, the spatial range in which the container object is deployed is determined to be the first spatial range; or, when the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the spatial range in which the container object is deployed is determined to be the second spatial range, wherein the first spatial range is different from the second spatial range.

26. The apparatus according to claim 23, characterized in that, The indication information includes an identifier of the spatial extent used in the lifecycle management operations of the tenant of the container object.

27. The apparatus according to claim 26, characterized in that, The creation module is specifically used for: The spatial range in which the container object is deployed is determined based on the spatial range corresponding to the identifier of the spatial range.

28. The apparatus according to claim 23, characterized in that, The receiving module is also used for: Receive a multi-tenant management policy creation request sent by the Network Functions Virtualization Orchestrator (NFVO). The creation request includes the tenant identifier of the container object invoked by the Virtualized Network Function (VNF) instance and the affinity / anti-affinity group between the VNF instance and other VNF instances of the NS instance. The creation module is further configured to create a multi-tenant management policy based on the affinity / anti-affinity group and the tenant's identifier. The multi-tenant management policy is used to indicate whether the container objects invoked by the tenant and other tenants are deployed in the same spatial range. The spatial range includes the container cluster, or the spatial range includes the namespace in the container cluster. The tenant and the other tenants are tenants of the container objects invoked by the VNF instances included in the NS instance.

29. The apparatus according to claim 28, characterized in that, The multi-tenancy management strategy includes the identifier of the tenant of the container object, the identifier of the affinity / anti-affinity group to which the container object included by the tenant belongs, the type of affinity / anti-affinity, and the scope of the affinity / anti-affinity group, the scope of the scope including the spatial range.

30. The apparatus according to claim 28 or 29, characterized in that, The creation module is specifically used for: The spatial range in which the container object is deployed is determined based on the container object's identifier, the container object's tenant identifier, the indication information, and the multi-tenancy management policy.

31. The apparatus according to claim 30, characterized in that, The indication information includes the affinity / anti-affinity rules of the container object, and the creation module is specifically used for: The deployment locations of other container objects of the tenant where the container object resides are determined as the third spatial range; If the third spatial range satisfies the multi-tenancy management strategy, and the indication information indicates that the container object is deployed in the same spatial range as other container objects in the same tenant as the container object, then the spatial range where the container object is deployed is determined to be the third spatial range; or, When the indication information indicates that the container object is not deployed in the same spatial range as other container objects in the same tenant as the container object, the spatial range where the container object is deployed is determined to be the fourth spatial range, and the fourth spatial range satisfies the multi-tenancy management strategy.

32. The apparatus according to claim 28 or 29, characterized in that, The receiving module is also used for: Receive a deletion request for the multi-tenant management policy sent by the NFVO, wherein the deletion request includes the identifier of the tenant; The creation module is also used to delete multi-tenancy management policies associated with the tenant's identifier.

33. A multi-tenant management device, characterized in that, Includes a processor configured to be coupled to a memory, read from and execute instructions in the memory to implement the method as described in any one of claims 1-6 or 7-16.

34. A readable storage medium, characterized in that, Includes a program or instructions that, when executed, cause the method described in any one of claims 1-6 or 7-16 to be performed.

35. A computer program product, characterized in that, Includes computer-readable instructions, which, when read and executed by the communication device, cause the communication device to perform the method as described in any one of claims 1-6 or 7-16.

Images