Virtual network function deployment method and deployment device

Abstract

This application provides a virtual network function deployment method and deployment apparatus. According to the deployment method provided in this application, when resources are allocated to VDUs required by the VNF to be deployed, all necessary VDUs are used as a whole group to calculate the resources required to schedule all VDUs in one computation periodicity at the group granularity until the corresponding resources are acquired to schedule the entire group of VDUs or scheduling of the entire group of VDUs fails. When the deployment position of VDUs for the VNF to be deployed is calculated at the group granularity, allocation methods that do not contribute to the overall deployment are recalculated and adjusted, resulting in an improved success rate for VNF deployment.

Description

Technical Field

[0001] This application claims the priority of Chinese Patent Application No. 202310576405.9, titled "Virtual Network Function Deployment Method and Deployment Device", filed with the China National Intellectual Property Administration on May 19, 2023, which is hereby incorporated by reference in its entirety.

[0002] This application relates to the field of network function virtualization technology, and more particularly, to a virtual network function deployment method and a deployment device.

Background Art

[0003] Network function virtualization (NFV) technology separates upper-layer software from lower-layer general-purpose hardware by virtualizing computing resources, storage resources, and network resources, and flexibly deploys software-defined network functions on general-purpose devices such as servers, switches, or memories, thereby facilitating efficient and cost-effective network operations. In the NFV framework, network functions realized by software are called virtual network functions (VNFs). To ensure the normal execution of VNFs and the cooperation between different VNFs, a cloud operating system (OS) needs to schedule resources to deploy VNFs on a general-purpose hardware platform.

Summary of the Invention

Means for Solving the Problems

[0004] This application provides a virtual network function deployment method and a deployment device to improve network deployment efficiency.

[0005] According to a first aspect, the present application provides a virtual network function deployment method applicable to an infrastructure service manager, the method comprising: receiving first request information sent by a virtual network function manager VNFM, the first request information requesting the deployment of a virtual deployment unit VDU for a first virtual network function VNF; creating M VDUs for the first VNF, the M VDUs being associated as VDUs in the same group, where M is a positive integer; and deploying the VDUs in the same group by using a group scheduling method, the group scheduling method allocating resources to each of the VDUs in the same group at one computation periodicity until each of the VDUs in the same group obtains a corresponding resource or the allocation of resources to the entire group of VDUs in the same group fails, the computation periodicity being for calculating the corresponding resource for each of the VDUs in the same group.

[0006] In this method, multiple VDUs are used as the granularity in the group scheduling method, and a unified scheduling calculation is performed for the resources required by all of the VDUs, improving the rationality of resource allocation and increasing the likelihood of successful VDU deployment.

[0007] In possible implementations, the first request information carries the first information, which indicates that the workload group object identifier associated with the VDU required by the first VNF ​​is the first workload group object identifier, the workload group object identifier indicates a workload group object, and the workload group object includes the following attribute information: the maximum number of VDUs associated with the workload group object identifier, the scheduling policy when the VDUs associated with the workload group object identifier are deployed using a group scheduling method, the scheduling priority when the VDUs associated with the workload group object identifier are deployed using a group scheduling method, and the scheduling timeout duration when the VDUs associated with the workload group object identifier are deployed using a group scheduling method.

[0008] The creation of M VDUs for the first VNF ​​by the Infrastructure Services Manager includes the creation of M VDUs, with each of the M VDUs being associated with the first workload group object identifier.

[0009] The step of deploying M VDUs by using a group scheduling method includes the step of deploying the VDU associated with the first workload group object identifier by using a group scheduling method based on attribute information of the workload group object indicated by the first workload group object identifier.

[0010] Workload group objects are introduced as custom resources. Workload group objects are used as a whole group. Multiple VDUs required by the VNF being deployed are associated with the workload group object via labels and become members of the workload group object. Furthermore, several attributes of the workload group object facilitate subsequent deployments performed using group scheduling methods.

[0011] In some implementations, the step of expanding the VDU associated with the first workload group object identifier is performed by using a group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier. The process includes the steps of: obtaining an unexpanded VDU; adding the unexpanded VDU to the obtained scheduling queue associated with the first workload group object identifier, if the workload group object identifier associated with the unexpanded VDU is the first workload group object identifier; and expanding the VDU in the scheduling queue by using a group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier.

[0012] By using a group scheduling method based on the workload group object identifier associated with undeployed VDUs, common VDUs and VDUs that need to be deployed can be placed in different scheduling queues, facilitating the subsequent deployment of different VDUs.

[0013] In some implementations, the step of deploying VDUs to the scheduling queue by using a group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier is: The process includes the step of deploying the VDUs in the scheduling queue in accordance with the scheduling policy and scheduling priority of the workload group object indicated by the first workload group object identifier, by using a group scheduling method until each VDU in the scheduling queue is successfully deployed or the deployment duration exceeds the scheduling timeout duration of the workload group object indicated by the first workload group object identifier, provided that the number of VDUs in the scheduling queue is equal to the maximum number of workload group objects indicated by the first workload group object identifier.

[0014] In this way, reaching the number of members in a workload group object is used as a dequeuing rule for the scheduling queue, ensuring that the VDUs for dequeuing scheduling are associated with the same workload group object, and scheduling multiple VDUs at the group granularity by using the group scheduling method.

[0015] In possible embodiments, this method The step of receiving second information from VNFM, further including the step of creating a workload group object whose identifier is a first workload group object identifier.

[0016] In some implementations, this method is The steps further include sending a list of workload group objects to the VNFM, and receiving second information from the VNFM, wherein the workload group object whose identifier is the first workload group object identifier is, if the workload group object list is not included, the steps of receiving second information from the VNFM.

[0017] In some implementations, this method is The step of receiving third information from VNFM, the third information indicating that the attribute information of a workload group object whose identifier is a first workload group object identifier is updated.

[0018] In some implementations, the method further includes the step of sending a list of workload group objects to the VNFM, and the step of receiving third information from the VNFM includes the step of receiving third information from the VNFM if the list of workload group objects contains a workload group object whose identifier is the first workload group object identifier. Includes.

[0019] In some implementations, before sending the workload group object list to the VNFM, this method The further step of receiving a second request from VNFM, wherein the second request is for requesting a query of a workload group object list.

[0020] According to the virtual network function deployment method provided in this application, operations such as adding, deleting, modifying, and querying workload group objects can be performed independently, and group scheduling checks may also be performed during the VDU deployment process.

[0021] In possible implementations, by using a group scheduling method, the step of expanding VDUs in the scheduling queue based on attribute information of a workload group object indicated by a first workload group object identifier is: The method further includes: associating a group scheduling label with a first node via a first scheduler, wherein the first node includes a candidate deployment node for a VDU in a scheduling queue, and the first scheduler is configured to allocate resources to the VDU; and deploying a VDU in a scheduling queue via a second scheduler by using a group scheduling method based on attribute information of a workload group object indicated by a first workload group object identifier, wherein the second scheduler is a copy of the first scheduler.

[0022] In some implementations, the step of expanding VDUs in the scheduling queue by using a group scheduling method based on attribute information of a workload group object indicated by a first workload group object identifier is: The process includes: associating a group scheduling label with a first node via a first scheduler, wherein the first node includes a candidate deployment node for a VDU in a scheduling queue, and the first scheduler is configured to allocate resources to the VDU; and deploying the VDU in a scheduling queue via at least one scheduling solver by using a group scheduling method based on attribute information of a workload group object indicated by a first workload group object identifier, wherein the scheduling solver is an independent third-party scheduler.

[0023] Regardless of whether the group scheduling method is used via a second scheduler or schedule solver, the computational workload may be reduced.

[0024] According to a second aspect, the present application provides a virtual network function deployment method applicable to a virtual network function manager VNFM, the method being: Receiving third request information for triggering the deployment of a virtual deployment unit (VDU) for a first virtual network function (VNF); and transmitting first request information to an infrastructure service manager, the first request information being for requesting to deploy a VDU for the first VNF.

[0025] In a possible implementation form, the third request information and the first request information carry first information, the first information indicating that a workload group object identifier associated with a VDU required by the first VNF is the first workload group object identifier, the workload group object identifier indicating a workload group object, the workload group object including the following attribute information: the maximum number of VDUs associated with the workload group object identifier; a scheduling policy when the VDUs associated with the workload group object identifier are deployed by using a group scheduling method; a scheduling priority when the VDUs associated with the workload group object identifier are deployed by using a group scheduling method; and a timeout duration when the VDUs associated with the workload group object identifier are deployed by using a group scheduling method.

[0026] In a possible implementation, the method further includes transmitting second information to the infrastructure service manager, the second information indicating to create a workload group object whose identifier is the first workload group object identifier.

[0027] In some implementations, the method further includes The step of receiving a list of workload group objects from the infrastructure service manager, and sending second information to the infrastructure service manager, further includes sending the second information to the infrastructure service manager if the list of workload group objects does not include a workload group object whose identifier is the first workload group object identifier.

[0028] In some implementations, this method is A step of sending third information to an infrastructure service manager, the third information indicating that it updates attribute information of a workload group object whose identifier is a first workload group object identifier.

[0029] In some implementations, this method is The step of receiving a list of workload group objects from an infrastructure service manager, and sending a third piece of information to the infrastructure service manager, further includes sending the third piece of information to the infrastructure service manager if the list of workload group objects contains a workload group object whose identifier is a first workload group object identifier.

[0030] In some implementations, this method receives the workload group object list from the infrastructure service manager before it is available. The step of sending a second request to an infrastructure service manager, wherein the second request is for requesting a query for a list of workload group objects.

[0031] In some implementations, the third request information specifically requests the instantiation of the first VNF, or specifically requests the scaling out of the VDU of the first VNF.

[0032] Regardless of whether the third request information is for requesting the instantiation of the first VNF ​​or for requesting the scaling out of the first VNF, the scheduling resources must be allocated to the VDUs required by the first VNF.

[0033] In some implementations, request information received by the VNFM is either entered by the administrator on the VNFM, or the request information received by the VNFM is received by the VNFM from the NFVO.

[0034] In an NFV system architecture, both NFVO and VNFM can manage VNFs.

[0035] According to a third aspect, the application provides a virtual network function deployment device, the virtual network function deployment device including a function module configured to perform one of the deployment methods described in the above embodiments. In some implementations, each module may be implemented via software and / or hardware.

[0036] According to a fourth aspect, the present application provides a virtual network function deployment device including a processor and memory communicating with the processor, wherein the memory stores computer executable instructions. The processor executes the computer executable instructions stored in the memory in order to implement the virtual network function deployment method provided in the first aspect.

[0037] According to a fifth aspect, the present application provides a virtual network function deployment device including a processor and memory communicating with the processor, wherein the memory stores computer executable instructions. The processor executes the computer executable instructions stored in the memory and implements the virtual network function deployment method provided in the second aspect.

[0038] According to the sixth aspect, the present application provides a virtual network function deployment system. The system includes the apparatus of the fourth aspect and the apparatus of the fifth aspect.

[0039] According to the seventh aspect, the present application provides a computer program product including a computer program. When the computer program is executed by a processor, a method in the first aspect, the second aspect, or any one of their possible implementations is carried out.

[0040] According to the eighth aspect, the present application provides a computer-readable medium for storing program code for execution by a device, the program code including a method in the first aspect, the second aspect, or any one of their possible implementations.

[0041] The drawings accompanying this specification are incorporated herein and constitute part of this specification to illustrate embodiments conforming to this application and are used together with this specification to illustrate the principles of this application. [Brief explanation of the drawing]

[0042] [Figure 1] This is a diagram of the standardized architecture of an NFV system proposed by the European Telecommunications Standards Organization. [Figure 2] This is a diagram illustrating the concept of a workload group according to one embodiment of this application. [Figure 3] This is a schematic flowchart of a virtual network function deployment method according to one embodiment of this application. [Figure 4]This is a schematic flowchart of a virtual network function deployment method according to one embodiment of this application. [Figure 5] This is a schematic flowchart of adding, deleting, modifying, and querying a workload group object list according to one embodiment of this application. [Figure 6] This is a diagram illustrating the association between a VDU and a workload group object according to one embodiment of the present application. [Figure 7] This is a diagram of the architecture of a K8s component for extending group scheduling according to one embodiment of the present application. [Figure 8] This is a schematic flowchart of a K8s performing group scheduling according to one embodiment of this application. [Figure 9] This is a diagram illustrating a framework in which K8s is extended by a coscheduler to support group scheduling calculations, according to one embodiment of this application. [Figure 10] This is a schematic flowchart illustrating how K8s performs group scheduling via a primary scheduler and a coscheduler, according to one embodiment of this application. [Figure 11] This figure shows a framework in which K8s is extended by a schedule solver to support group scheduling calculations, according to one embodiment of the present application. [Figure 12] This is a schematic flowchart illustrating how K8s performs group scheduling via a primary scheduler and a schedule solver, according to one embodiment of this application. [Figure 13] This is a diagram showing the structure of a virtual network function deployment device according to one embodiment of the present application. [Figure 14] This is a diagram showing the structure of a virtual network function deployment device according to another embodiment of the present application. [Figure 15] This is a diagram showing the structure of a virtual network function deployment device according to yet another embodiment of the present application. [Modes for carrying out the invention]

[0043] Specific embodiments of this application are shown by the aforementioned accompanying drawings and are described in more detail below. The accompanying drawings and textual description are not intended to limit the scope of the concepts of this application in any way, but are intended to illustrate the concepts of this application to those skilled in the art by reference to specific embodiments.

[0044] Exemplary embodiments are described in detail herein, and examples of these exemplary embodiments are presented in the accompanying drawings. Where the following description relates to the accompanying drawings, unless otherwise indicated, the same numbers in different accompanying drawings indicate the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, the embodiments are merely examples of apparatuses and methods described in detail in the accompanying claims and consistent with some aspects of this application.

[0045] In this application, "at least one" means one or more, and "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships may exist. For example, A and / or B may indicate that only A exists, both A and B exist, and only B exists, and A and B may be singular or plural. In the textual descriptions of this application, the character " / " generally indicates an "or" relationship between related objects. Conventional telecommunications network systems include various dedicated hardware devices, with different dedicated hardware devices performing corresponding functions. As network size increases, telecommunications network systems become more complex and, accordingly, less scalable. NFV technology separates the software functions of a device from the underlying hardware via virtualization technology in order to separate the software and hardware of communication network function nodes. NFV technology is a core technology for carrier-class service cloudification. Based on NFV technology, VNFs with different functions can be deployed on a general-purpose hardware platform, reducing the cost of telecommunications network systems and providing better scalability.

[0046] Different vendors may develop VNFs with different functionalities. Service providers can flexibly select and combine different VNFs based on their requirements. A standardized architecture is necessary due to constraints during VNF development to ensure that all selected VNFs operate and cooperate properly and can run on a general-purpose hardware platform. Figure 1 is a diagram of a standardized architecture for an NFV system proposed by the European Telecommunications Standards Institute (ETSI). As shown in Figure 1, the NFV system includes an NFV management and orchestration (NFV-MAMO) module, an NFV infrastructure (network functions virtualization infrastructure, NFVI), VNFs, an element management (EM) module, and an operation support system / business support system (OSS / BSS).

[0047] The NFV-MAMO module includes four functional modules: the NFV orchestrator (NFVO), the VNF manager (VNFM), the container infrastructure service manager (CISM), and the virtualized infrastructure manager (VIM).

[0048] NFVO has a global perspective on virtual resources and primarily manages the lifecycle of virtualization services, and is responsible for allocating and scheduling virtual resources in the virtualization infrastructure and NFVI. In addition, NFVO can further execute resource-related requests from VNFM, send configuration information to VNFM, and collect VNF ​​status information.

[0049] A VNFM primarily manages the lifecycle of one or more VNFs. Through communication with VNFs, a VNFM can perform actions such as instantiating, updating, querying, auto-scaling, and stopping VNFs. An NFV system may have multiple VNFMs, each responsible for managing the lifecycle of a different type of VNF.

[0050] VIM may perform resource management functions such as allocating infrastructure resources, resource discovery, and fault handling management. VIM and VNFM may communicate with each other to allocate resources and exchange configuration and status information for virtualization hardware resources. CISM's functions are similar to VIM's, but CISM primarily manages resources for container objects. Both VIM and CISM are infrastructure service managers.

[0051] NFVI is primarily configured to provide hardware resources to higher-layer VNFs. The underlying physical hardware resources within the NFVI are abstracted and transformed into virtualized hardware resources such as virtual machines (VMs) or containers via the virtualization layer. The higher-layer VNFs operate within a virtual resource environment, resulting in complete decoupling of software and hardware.

[0052] The EM module performs the traditional fault, user, configuration, performance, and security management functions of the VNF.

[0053] OSS / BSS supports a variety of end-to-end telecommunications services. OSS supports management functions such as network configuration, service provisioning, and fault management. BSS supports product management, order management, revenue management, and customer management.

[0054] In an NFV architecture, comprehensive virtualization of computing, storage, and network resources can be achieved using a cloud OS, and the virtualized physical hardware resources can be centrally managed, monitored, and optimized.

[0055] As a core technology for implementing cloud computing, NFV technology introduces three levels of services for implementing carrier-class service cloudification: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

[0056] IaaS focuses on providing users with basic resources, which are typically delivered in the form of VMs in actual applications. Therefore, when network function virtualization is implemented in an IaaS architecture, in the corresponding virtual machine scenario, one or more VMs are invoked to deploy a VNF with the corresponding functionality.

[0057] PaaS is a business model that provides a server platform as a service to provide interface services within a PaaS architecture. Other service developers may develop services or applications by using such service interface functionality.

[0058] Container as a Service (CaaS) presents services in the form of containers and can be considered a specific type of PaaS service. As an operating system-level virtualization technique, containers isolate different processes through operating system isolation techniques such as Linux's CGroup and namespaces. Inside a container, there is no operating system, only processes. Therefore, containers are lighter than VMs. Furthermore, containers can be deployed not only on bare metal servers but also on virtual machines. A container-based system deployed on a bare metal server is called a container running on a bare metal server, and a container-based system deployed on a virtual machine is called a container running on a virtual machine. When network function virtualization is implemented in a CaaS architecture, in the corresponding container scenario, one or more containers are invoked to deploy a VNF with the corresponding function.

[0059] In CaaS architectures, the Kubernetes (K8s) container cluster management system, based on an open-source platform, is currently widely used in the field of container management and orchestration. K8s can provide a whole set of functions such as resource scheduling, deployment and execution, service discovery, and scaling for container-based applications. Essentially, K8s can be thought of as a mini-CaaS manager based on container technology.

[0060] From the different scenarios above, it is clear that deploying a VNF requires one or more smaller-grained virtual deployment units (VDUs). In the virtual machine scenario, the VDU object points to a VM. In the container scenario, K8s manages containers by using the smallest deployment unit, "Pod." Each "Pod" contains one or more closely related containers. Therefore, the VDU object points to a "Pod." When CISM / VIM schedules resources to deploy a VNF, the resources are actually assigned to the VDUs contained within the VNF being deployed. A VNF can only be considered successfully deployed if all VDUs in the VNF being deployed are bound to their corresponding resource nodes.

[0061] In conventional technology, the CISM / VIM scheduler calculates deployment locations at the granularity of a single VDU. If hardware resources are limited, but VNF ​​deployment requirements must be met, after some VDUs are initially deployed to their corresponding hardware locations, the remaining VDUs may fail to deploy due to insufficient remaining resources. As a result, the VNF deployment fails. For example, In a container scenario, a virtual deployment unit (VDU) corresponds to a "Pod". Currently, the "Pods" required by the VNF to be deployed include one A-Pod {Cpu(6v) / Mem(40G)}, one B-Pod {Cpu(2v) / Mem(20G)}, one C-Pod {Cpu(4v) / Mem(40G)}, and one D-Pod {Cpu(4v) / Mem(30G)}. Currently available resources include the board in subrack 0 and slot 0, which are numa0 {FreeCpu(8v) / Mem(100G)} and numa1 {FreeCpu(8v) / Mem(100G)}. Based on the dequeue order of B, C, D, and A, CISM calculates the deployment position of each Pod, and the calculation results in B-Pod and C-Pod being deployed to numa0 and D-Pod being deployed to numa1. When CISM calculates the deployment location of A-Pod, the remaining resources on numa0 and numa1 do not meet the requirements for A-Pod, and therefore resource allocation to A-Pod fails. In conventional techniques, resource calculation is performed at a single granularity, "Pod". Therefore, if A-Pod deployment fails, CISM can only repeatedly calculate the deployment location of A-Pod within the deployment time limit until a timeout occurs. As a result, VNF deployment fails.

[0062] Furthermore, if the deployment location is calculated at the granularity of a single VDU, and multiple VNFs share a host aggregate (HA) resource pool, the resource requirements of the VDUs within the VNF are discrete, and the remaining resources of multiple boards in the HA are insufficient to deploy another VDU. As a result, a large amount of resource fragments cannot be utilized.

[0063] To solve the aforementioned problems, this application provides a method for deploying virtual network functions to improve network deployment efficiency.

[0064] The technical concept of this application is as follows: when resources are allocated to VDUs required by the VNF being deployed, all required VDUs are associated as a group in order to calculate the resources required to schedule all VDUs in a computationally cyclical manner at the group granularity. If the scheduling of any one of the VDUs fails, the resources available for the VDUs in the group that have been successfully allocated are recalculated until the corresponding resources are acquired to schedule the entire group of VDUs, or the scheduling of the entire group of VDUs fails.

[0065] When the deployment location of VDUs for the target VNF ​​is calculated at the group granularity, allocation methods that are not helpful for the overall deployment are recalculated and adjusted, resulting in an improved success rate for VNF deployment.

[0066] Figure 2 is a diagram illustrating the concept of a workload group according to one embodiment of the present application. The concept of a Workload Group is introduced in the present application to assist the Infrastructure Service Manager in performing group scheduling for VDUs required by the VNF being deployed. For the Infrastructure Service Manager, a workload group is a custom resource, and a workload group object is an instantiation of this type of resource. As shown in Figure 2, WorkloadGroup1 is a workload group object, and the workload group object has a set of attributes including a workload group name identifier, the number of group members, a group scheduling policy, a group scheduling priority, and a group scheduling timeout duration.

[0067] The three VDUs, namely workload1, workload2, and workload3, are used as VDUs required by the VNF to be deployed, associated with the name identifier of workloadgroup1 via labels, and become group members of workloadgroup1. Workload4 is used as a common VDU workload for comparison. The group scheduling policy is used as the scheduling policy that CISM / VIM uses when deploying group members, i.e., workload1-workload3 within WorkloadGroup1. Based on resource requirements, the group scheduling policy may be categorized as LeastHost, LeastAllocate, MostAllocate, etc. Group scheduling priority is used to distinguish the scheduling priority of different workload group objects. A lower group scheduling priority value indicates a higher priority. Note that VDU priorities are set manually, and group members within the same workload group object have the same priority. The group scheduling timeout duration is used as a time limit for CISM / VIM to allocate resources to workload1-workload3. If any one of the VDUs (workload1-workload3) does not acquire the necessary scheduling resources within the group scheduling timeout duration, the deployment is considered to have failed.

[0068] Figure 3 is an illustrative dialogue flowchart of a virtual network function deployment method according to one embodiment of the present application. This method may be applied to the system shown in Figure 1. The application of the deployment method to the NFV system shown in Figure 1 will be described in detail with reference to Figure 3. The infrastructure service manager in this embodiment of the present application may be a CISM or a VIM.

[0069] S301: The VNFM receives a third request, which is intended to trigger the deployment of a virtual deployment unit (VDU) to the first virtual network function (VNF).

[0070] In this step, the third request information is intended to trigger the deployment of the VDU for the first VNF. In one example, the third request information is the instantiation request information for the first VNF. The VNFM is used as the VNF management module. The administrator may trigger the instantiation request for the first VNF ​​on the VNFM's deployment interface and send the third request information to the VNFM.

[0071] Note that the deployment software package and virtual network function module descriptor (VNF descriptor, VNFD) for the first VNF ​​must be uploaded before an instantiation request is triggered on the VNFM deployment interface. The deployment software package contains the software image used to run the VNF, and the software image is delivered to the Infrastructure Services Manager. The VNFD is a description template used to deploy the VNF, and the VNFM may extract the input parameters necessary to deploy the first VNF ​​from the VNFD. The deployment software package and VNFD template may be uploaded via the VNF portal.

[0072] In some implementations, the third request information further carries the first information, which indicates that the workload group object identifier associated with the VDU required by the first VNF ​​is the first workload group object identifier. Thus, the VDU required by the first VNF ​​becomes a group member of the first workload group object. The workload group object identifier is the workload group name identifier within the workload group object attributes, and it will be understood that the attribute information of the first workload group object is intended to assist the infrastructure service manager when performing group scheduling for the VDU required by the first VNF.

[0073] It should be noted that the workload group object identifier and attribute information contained in the first workload group object, associated with the VDU required by the first VNF ​​and indicated by the first information, are obtained based on the VNFD. In other words, if the concept of workload groups is introduced to help CISM / VIM perform group scheduling for the VDU required by the VNF being deployed, the VNFD template should further include the group scheduling label for the VDU required by the VNF being deployed and the attribute parameters of the associated workload group object. After obtaining the aforementioned information based on the VNFD, the administrator may further modify the information as needed.

[0074] In this embodiment, when the VDU associated with the workload group object is expanded based on the attribute information of the workload group object, the method further includes S301-1, S301-2, and S301-3, as shown in Figure 4.

[0075] S301-1: VNFM sends the second request information to the Infrastructure Services Manager to retrieve the workload group object list and information.

[0076] The Infrastructure Services Manager provides an interface to the VNFM for adding, deleting, modifying, and querying workload group objects. The VNFM may send second request information to the Infrastructure Services Manager to query the identifiers and attribute information of the workload group objects included in the workload group object list.

[0077] S301-2: VNFM determines whether to create or update the first workload group object, generates configuration information, and sends it to the Infrastructure Services Manager.

[0078] In this step, VNFM may query, based on the first information, whether the workload group object list contains a workload group object whose identifier is the first workload group object identifier.

[0079] If the workload group object list does not contain a workload group object whose identifier is the first workload group object identifier, VNFM determines that the first workload group object needs to be created. In response, VNFM generates second information, which indicates that a workload group object whose identifier is the first workload group object should be created.

[0080] If the workload group object list contains a workload group object whose identifier is the first workload group object identifier, the workload group object is shown as the first first workload group object, and VNFM further determines whether the attribute information of the first first workload group object is the same as the attribute information of the first workload group object shown by the first information. If the attribute information of the first first workload group object is different from the attribute information of the first workload group object shown by the first information, VNFM determines that the attribute information of the first first workload group object in the workload group object list needs to be updated. In response, VNFM generates third information, which indicates that the attribute information of the workload group object whose identifier is the first workload group object identifier should be updated.

[0081] The second or third piece of information indicates the configuration information required by the first workload group object, and VNFM sends the configuration information to the Infrastructure Services Manager.

[0082] S301-3: The Infrastructure Services Manager creates or updates the first workload group object in response to configuration information.

[0083] The second or third piece of information includes the identifier and attribute information of the first workload group object. Based on the configuration information, the infrastructure service manager either creates the first workload group object or updates the attribute information of the first first workload group object in the workload group object list to match the attribute information contained in the configuration information that belongs to the first workload group object.

[0084] The three steps S301-1, S301-2, and S301-3 described above function as a group scheduling check, and it will be understood that the function of the three steps is to avoid conflicts between the identifier of the first workload group object, indicated by the first information and other attribute information, and the information of existing workload group objects in the workload group object list, thereby avoiding deployment failures of the first VNF ​​caused by conflicts. The three steps are optional steps in the deployment process of the first VNF.

[0085] S302:VNFM sends the first request information to the Infrastructure Service Manager, which requests that the VDU be deployed for the first VNF.

[0086] In this step, the first request information is used to request the Infrastructure Service Manager to create VDUs for the first VNF. The number of VDU instances required by the first VNF ​​is determined based on the third request information. Therefore, the first request information is generated based on the third request information.

[0087] In a possible implementation, if the third request information carries the first information indicating the workload group object identifier associated with the VDU required by the first VNF, the first request information also carries the first information in order to forward the contents indicated in the first information to the infrastructure service manager.

[0088] S303: The Infrastructure Services Manager creates M VDUs for the first VNF, and the M VDUs are associated as VDUs in the same group, where M is a positive integer.

[0089] Based on the first request information, M VDUs are required to deploy the first VNF, and the Infrastructure Service Manager creates the M VDUs required by the first VNF. It can be seen that M VDUs are associated as VDUs within the same group.

[0090] In possible implementations, if the first request information carries the first information, the M VDUs created by the infrastructure service manager are further associated with the first workload group object identifier via labels. In this case, the M VDUs become group members of the first workload group object.

[0091] S304: The Infrastructure Services Manager deploys VDUs within the same group by using a group scheduling method, which allocates resources to each VDU within the same group in one computation cycle until each VDU within the same group obtains its corresponding resources or the allocation of resources to the entire group of VDUs within the same group fails, with the computation cycle being for calculating the corresponding resources for each VDU within the same group.

[0092] If M VDUs are associated as VDUs within the same group, the Infrastructure Services Manager may calculate the corresponding deployment locations for all group members by using a group scheduling method. If any one of the group members does not have a corresponding mapping location within the schedulable resources in the calculation, backtracking is performed for the group member VDUs for which a corresponding mapping location is obtained, either until a corresponding mapping location is obtained for each of the M VDUs through the calculation, or until the calculation duration exceeds one calculation cycle, in order to reconcile the schedulable resources. If the calculation duration exceeds a calculation cycle, scheduling of the entire group of VDUs fails. After all M VDUs have obtained their corresponding scheduling locations, the Infrastructure Services Manager binds each VDU to its corresponding resource node. In this case, this is equivalent to the successful deployment of the first VNF.

[0093] In this embodiment, VNFs are deployed by using a group scheduling method, and allocation methods that do not contribute to the overall deployment are recalculated and adjusted, resulting in an improved success rate for VNF deployment. The concept of workload groups is also introduced. Pre-binding calculations reduce unnecessary operations in the deployment process, improving VNF deployment efficiency.

[0094] According to the embodiments described above, in the VNF instantiation process, the group scheduling check function is performed via the VNFM. In some implementations, the workload group object may, alternatively, be manually managed by the VNFM before instantiation. Referring to the embodiment in Figure 5, a method for manually managing the workload group object will be described below. As shown in Figure 5, in the VNF deployment method provided in this embodiment of the present application, the deployment plan for the workload group object may be further performed before instantiation. The method specifically includes the following steps.

[0095] S501: VNFM receives a fourth request, which is to query the workload group object list.

[0096] Before VNF instantiation, the status of existing workload group objects in the workload group object list can be queried via VNFM, making it easier to plan in advance based on the deployment requirements of the VNF to be deployed.

[0097] S502:VNFM sends the second request information to the Infrastructure Services Manager to retrieve the Workload Group Object List.

[0098] As an instantiation of a custom resource, a workload group object is also essentially a resource and may be managed by the Infrastructure Services Manager. The second request information is for retrieving a list of workload group objects from the Infrastructure Services Manager.

[0099] S503: VNFM outputs a list of workload group objects.

[0100] The VNFM feeds back the acquired list of workload group objects to the querier, who then decides whether to create a new workload group object or update the attribute information of an existing workload group object in the list, based on the deployment requirements of the VNF being deployed.

[0101] In this embodiment, attribute information of the first workload group object is required to expand the first VNF. In this case, the workload group object list is queried to determine whether it contains a workload group object whose identifier is the identifier of the first workload group object.

[0102] If the workload group object list does not contain a workload group object whose identifier is the first workload group object identifier, it is determined that the first workload group object needs to be created.

[0103] If the workload group object list contains a workload group object whose identifier is the first workload group object identifier, that workload group object is shown as the first first workload group object. If the attribute information of the first first workload group object does not match the attribute information of the first workload group object required to deploy the first VNF, it is determined that the attribute information of the first first workload group object in the workload group object list needs to be updated.

[0104] S504: VNFM receives a fifth request, which requests that an update be created or executed for the workload group object whose workload group object identifier is the first workload group object identifier.

[0105] In this step, the querier sends a fifth request to the VNFM based on the determination result of S503. If the determination result indicates that the first workload group object needs to be created, the fifth request is to request the creation of a workload group object whose workload group object identifier is the first workload group object identifier. If the determination result indicates that the attribute information of a workload group object in the workload group object list needs to be updated, the fifth request is to request that the VNFM perform an update on the workload group object whose workload group object identifier is the first workload group object identifier.

[0106] Based on the determination result, the fifth request information carries the second or third information, which includes attribute information such that the workload group object identifier should be included in the workload group object whose workload group object identifier is the first workload group object identifier, or the attribute information of the workload group object whose workload group object identifier is the first workload group object identifier should be updated.

[0107] S505: VNFM sends the fifth request information to the Infrastructure Service Manager.

[0108] The Infrastructure Services Manager provides an interface for adding, deleting, modifying, and querying workload group objects in the VNFM.

[0109] S506: Based on the fifth request information, the infrastructure service manager creates or updates a workload group object whose workload group object identifier is the first workload group object identifier.

[0110] If the fifth request information carries the second information, the infrastructure service manager creates the first workload group object. If the fifth request information carries the third information, the infrastructure service manager updates the attribute information of the first first workload group object in the workload group object list to match the attribute information contained in the third information, which belongs to the first workload group object.

[0111] In the steps described above, the deployment plan is executed primarily based on the deployment requirements of the first VNF. For joint deployment requirements of multiple VNFs, the workload group object may also be managed manually by the VNFM. For example, As shown in Figure 6, the VNF-1 to be deployed contains three "Pods": "Pod" Control 1, "Pod" Calculation 1, and "Pod" Calculation 2. The VNF-2 to be deployed contains three "Pods": "Pod" Control 2, "Pod" Calculation 3, and "Pod" Calculation 4. VNF-1 and VNF-2 must be co-deployed. The workload group object WG1 is defined based on the requirement that VNF-1 and VNF-2 expect a compact deployment. The attribute information for WG1 is as follows: workload group name identifier: WG1, number of group members: 6, group scheduling policy: minimum number of boards to use, group scheduling priority: 1, and group scheduling timeout duration: 30 seconds. Each "Pod" in VNF-1 and VNF-2 is associated with the name identifier of WG1 via a label.

[0112] The workload group object list is queried, and no workload group object with the name identifier WG1 exists. Therefore, it is determined that a WG1 object needs to be created. The fifth request information and the second information carried are configured based on the attribute parameters of the defined WG1 object, and the infrastructure service manager creates the WG1 object based on the fifth request information.

[0113] In this embodiment, workload group objects are managed manually by the VNFM, and as a result, workload group objects may be added, deleted, modified, and queried, and conflicts between the attributes of the workload group objects associated with the VDU required by the VNF being deployed and existing workload group objects in the workload group object list can be avoided.

[0114] In this application, the Infrastructure Service Manager allocates resources to M VDUs associated with a first workload group object by using a group scheduling method. For the Infrastructure Service Manager, a workload group is a new custom resource. Therefore, it is necessary to first distinguish between VDUs associated with a workload group object and common workload VDUs. Below, using a bare metal container scenario as an example, we describe a method for scheduling VDUs associated as members of a workload group object via a workload group name identifier.

[0115] Figure 7 is a diagram of the architecture of K8s components for extending group scheduling according to one embodiment of the present application. As shown in Figure 7, "kubectl" is used as a command-line tool for controlling and managing the K8s cluster. IF1 is an extension interface that provides operations such as adding, deleting, modifying, and querying workload group objects. Custom resource definitions (CRDs) are built-in resource types in K8s. Custom resources, such as workload group WGs, may be translated into resource types on K8s via CRD resources. K8s mainly consists of four components: API Server, Controller-Manager, "Etcd", and Scheduler.

[0116] The API server is a unified access entry point for all resources within a K8s cluster and acts as a core hub for data exchange between components within the cluster. The Controller Manager is a core component for K8s to automatically manage various resources, and changes in various statuses within the cluster may be monitored in real time through automated management. "Etcd" is responsible for storing information about various resource objects and status data within the cluster. The Scheduler is responsible for scheduling resources within the cluster and scheduling "Pods" to the appropriate nodes (Nodes).

[0117] Based on the original Priority Queue, Schedule one, and Scheduler Cache, the K8s scheduler extends the Group Priority Queue and Schedule Group. The Group Priority Queue stores the workload group members to be scheduled, and the Group Priority Queue provides a group scheduling algorithm to complete the group scheduling calculation for the workload group members to be dequeued. To ensure there is no conflict between common workload VDUs and VDUs associated with workload group objects in the scheduling process, it will be understood that the Group Priority Queue and Group Priority Queue may distinguish between VDUs associated with workload group objects and common workload VDUs.

[0118] Essentially, K8s can be considered a mini-CaaS manager. Therefore, K8s may be used as an example of an infrastructure service manager. Figure 8 is a schematic flowchart of how K8s implements group scheduling according to one embodiment of the present application. As shown in Figure 8, the group scheduling procedure may include S801 to S807.

[0119] S801: The API server receives the first request information and creates the "Pod" required by the first VNF.

[0120] In this step, the first request information requests the deployment of "Pods" for the first VNF. Based on the first request information, it is determined that M "Pods" are needed to deploy the first VNF. The first request information carries the first information, which indicates that the workload group object identifier associated with the "Pods" required by the first VNF ​​is the first workload group object identifier WG1. The M "Pods" whose associated workload group object identifier is the first workload group object identifier WG1 are created via the API server's reset interface (REST API).

[0121] S802: The API server stores the "Pod" data required by the first VNF ​​in "Etcd".

[0122] Since "Etcd" is equivalent to the Kubernetes database, the API server stores the data of the M "Pods" it has created in "Etcd".

[0123] Steps S801 and S802 are actually equivalent to step S303 in the embodiment shown in Figure 3, and it will be understood that K8s creates M VDUs via the API server and "Etcd".

[0124] If the workload group object list does not contain a workload group object whose identifier is the first workload group object identifier WG1, the first workload group object WG1 may be created via the API server and "Etcd", and a workload group queue WG1 corresponding to the first workload group object WG1 will be created in the group scheduling queue.

[0125] S803: The Informer in the scheduler monitors the status changes of "Etcd" and adds the "Pod" to the corresponding workload group queue in the group scheduling queue based on the workload group object identifier associated with the scheduled "Pod".

[0126] The information provider within the scheduler listens for and detects newly added unscheduled Pods in Etcd using the "list-watch" mechanism. Because there is a workload group queue WG1 corresponding to the first workload group object WG1 in the group scheduling queue, the scheduler adds Pods whose associated workload group object identifier is WG1 to workload group queue WG1. If a Pod is not associated with a workload group object, the scheduler adds the Pod to the priority queue. The API server is used as a hub for data interaction between components within the K8s framework. Therefore, if the information provider monitors status changes in Etcd, it is necessary to implement transfer via the API server.

[0127] Note that "Etcd" uses workload groups as custom resources and stores information about workload group objects. Before group scheduling begins, the scheduler listens for and detects resource changes in "Etcd" via the information provider and creates a corresponding workload group queue in the group scheduling queue for each workload group object in the workload group object list.

[0128] In addition, in some implementations, the information provider within the scheduler is further responsible for updating the scheduler cache, which caches information about resource nodes within "Pods" and "Etcds" that should be scheduled.

[0129] S804: Dequeue the "Pod" workload group member in the group scheduling queue, satisfying the dequeue rules.

[0130] In order to perform group scheduling calculations for a workload group member "Pod," dequeuing and subsequent group scheduling operations may be performed only if the workload group member "Pod" in the group scheduling queue satisfies the dequeuing rules.

[0131] For example, the dequeuing rules are as follows:

[0132] (1) Check the length of each workload group queue in the group scheduling queue. If the length of the workload group queue is greater than or equal to the maximum number of group members in the workload group, refer to rule (2). The length of the workload group queue indicates the number of "Pods" in the workload group queue.

[0133] (2) Check the group scheduling priority of the workload group object associated with each workload group queue. The workload group queue with the lowest priority has the highest scheduling priority and will be the first to be dequeued. If there are workload group queues with the same scheduling priority, refer to rule (3).

[0134] (3) Check the creation time of the workload group queue that satisfies the conditions of rule (2). Compare the creation times of workload group queues with the same group scheduling priority. The earliest dequeue is performed on the earliest created workload group queue.

[0135] S805: In the scheduler's group scheduling procedure, the group scheduling algorithm is invoked according to the group scheduling policy of the dequeued workload group object in order to complete the group scheduling calculation.

[0136] The group scheduling procedure provides a group scheduling algorithm. The group scheduling policy in the attributes of the workload group object WG1 on which the dequeue is performed corresponds one-to-one with the group scheduling algorithm. The group scheduling procedure invokes the corresponding group scheduling algorithm according to the group scheduling policy of the workload group object on which the dequeue is performed, and calculates the nodes on which the M "Pods" in the workload group queue on which the dequeue is performed should be scheduled.

[0137] In this step, the group scheduling calculation is not completed until each "Pod" in the workload group queue from which the dequeue was performed has acquired its corresponding node, or until the consumed duration exceeds the group scheduling timeout duration indicated in the attribute information of the workload group object.

[0138] S806: The scheduler performs scheduling operations for the workload group member "Pod".

[0139] In this step, the scheduler changes the value of the "nodeName" field in the "Pod" object to the name of the "Node" scheduled for the "Pod" object. The scheduler also updates the "Pod" and "Node" information in the scheduler cache.

[0140] S807: The scheduler initiates an update request to the API server, which is intended to update the data in the "Pod" within "Etcd".

[0141] The scheduler initiates a request via the API server to update the data in the "Etcd" of the "Pod". The "Pod" is not bound to the corresponding node until this step. In this way, resources are allocated to the "Pod".

[0142] In this embodiment, the entire group of "Pods" in the workload group queue is dequeued according to the dequeuing rules of the workload group queue, and as a result, the group scheduling algorithm is invoked to calculate the corresponding resource nodes for the entire group of "Pods," and the resources are allocated via calculation and binding, improving the success rate of "Pod" deployments and avoiding the complex operation of repeated binding and unbinding.

[0143] Note that after the group scheduling deployment is complete, VNFM can check whether all the "Pods" required by the first VNF ​​being deployed can be started successfully. If all the "Pods" required by the first VNF ​​are started successfully, the instantiation of the first VNF ​​is deemed successful, and the first VNF ​​is deployed successfully.

[0144] According to the group scheduling algorithm provided in the aforementioned embodiment, computations must be performed for the entire group of "Pods," which significantly increases the consumption of computing resources compared to performing computations at the granularity of a single "Pod." Therefore, the following describes methods for extending group scheduling that can mitigate the computing resource consumption pressure.

[0145] Figure 9 is a diagram of a framework in which K8s is extended by a co-scheduler to support group scheduling calculations, according to one embodiment of the present application. As shown in Figure 9, K8s is extended by a co-scheduler based on Figure 7. The co-scheduler is a copy of a manually created primary scheduler. Thus, the co-scheduler also includes a group scheduling queue and a group scheduling procedure.

[0146] Figure 10 is a schematic flowchart of a K8s implementation of group scheduling via a primary scheduler and a coscheduler according to one embodiment of the present application. Referring to Figure 10, the specific procedure for performing group scheduling in a K8s architecture including the coscheduler shown in Figure 9 will be described below. As shown in Figure 10, the group scheduling procedure performed via the primary scheduler and the coscheduler may include S1001 to S1008.

[0147] S1001: The scheduler creates a workload group queue.

[0148] Before group scheduling begins, the primary scheduler listens for and detects resource changes in "Etcd" via the information provider and creates a corresponding workload group queue in the group scheduling queue for each workload group object in the workload group object list.

[0149] In this embodiment, the coscheduler is used as a copy of the primary scheduler, and for each workload group object in the workload group object list, it is necessary to create a workload group queue in the coscheduler that corresponds to the group scheduling queue. Note that there is no order relationship when the primary scheduler and the coscheduler create their respective workload group queues separately.

[0150] S1002: The API server receives the first request information and creates the "Pod" required by the first VNF.

[0151] S1003: The API server stores the "Pod" data required by the first VNF ​​in "Etcd".

[0152] The steps in steps S1002 and S1003 correspond to steps S801 and S802 in the embodiment shown in Figure 8.

[0153] S1004: The primary scheduler pre-selects nodes for the "Pods" required by the first VNF ​​and locks the candidate nodes.

[0154] In this step, the primary scheduler first adds the "Pods" required by the first VNF ​​to the relevant workload group queue according to steps S803 and S804 of the embodiment in Figure 8, and dequeues the "Pods" in the workload group queue if the "Pods" satisfy the dequeue rules. Then, according to the pre-selection policy, the primary scheduler filters out nodes that do not satisfy the policy from "Etcd" via the API server and locks the candidate nodes in the scheduler cache.

[0155] S1005: The primary scheduler updates the "Node" information, "Pod" information, and information about the workload group object associated with the "Pod" in "Etcd" via the API server.

[0156] The primary scheduler marks candidate nodes in "Etcd" with the label of the first workload group object via the API server, prevents calls to candidate nodes by "Pods" that are not members of the first workload group, and updates information about the "Pods" to dequeue, as well as the first workload group object preparation scheduling information, within "Etcd". This then helps the coscheduler perform group scheduling operations.

[0157] S1006: The scheduler invokes the group scheduling algorithm to assign resource nodes to "Pods," which are workload group members to be dequeued from candidate nodes.

[0158] The resource scheduler monitors resource changes within "Etcd" via the information provider unit, and the scheduler cache within the resource scheduler holds information about nodes with the label of the first workload group object and information about "Pods" to be dequeued based on the preparation scheduling information of the first workload group object. In the above description, the API server performs the transfer during the process in which the information provider unit monitors status changes in "Etcd".

[0159] Each "Pod" in a workload group that is being dequeued is associated with a first workload group object. The scheduler on a node with a low computational workload invokes the corresponding group scheduling algorithm according to the group scheduling policy of the first workload group object and calculates which node the "Pod" to be dequeued will be scheduled to be scheduled to, within the range of nodes that have the label of the first workload group object. The group scheduling calculation is not completed until each "Pod" in the workload group queue that has been dequeued has obtained its corresponding node, or until the time consumed exceeds the group scheduling timeout duration indicated in the attribute information of the first workload group object.

[0160] After the group scheduling calculation is complete, the CosmoScheduler modifies the value of the "nodeName" field of the "Pod" object and updates the "Pod" and "Node" information in the scheduler cache within the CosmoScheduler.

[0161] S1007: The scheduler updates information about "Nodes," "Pods," and the workload group objects associated with "Pods" within "Etcd" via the API server.

[0162] In this step, the scheduler updates the Pod information in Etcd via the API server, binds the Pod to the corresponding node, and clears the workload group object identifier of the candidate node. The preparation scheduling information for the first workload group object is updated with the scheduled information.

[0163] S1008: The primary scheduler updates the information in the cache.

[0164] The primary scheduler unlocks the candidate node in the scheduler cache and clears the workload group object identifier of the candidate node. This step is optional for deploying the "Pod" required by the first VNF. The main function of this step is to avoid deployment failures caused by the inability to invoke a candidate node for another workload group object member "Pod". The primary scheduler updates the information in the cache based on the "Pod" information in "Etcd". Therefore, this step requires forwarding by the API server.

[0165] In this embodiment, nodes with low computational workloads are used to dynamically start / stop the cossetter to complete group scheduling calculations for workload group objects with a large number of group members, resulting in more efficient use of computational resources and reduced computational overhead pressure.

[0166] In some implementations, the computational overhead pressure of the scheduler may be mitigated alternatively through extensions by a schedule solver. Figure 11 shows a framework in which K8s is extended by a schedule solver to support group scheduling computations, according to one embodiment of the present application. The schedule solver is a third-party scheduler independent of the cloud OS.

[0167] Figure 12 is a schematic flowchart of an embodiment of the present application in which K8s implements group scheduling via a primary scheduler and a schedule solver. Referring to Figure 12, the specific procedure for performing group scheduling in a K8s architecture including the schedule solver of Figure 11 will be described below. As shown in Figure 12, the group scheduling procedure performed via the primary scheduler and the schedule solver may include S1201 to S1208.

[0168] S1201: The primary scheduler starts the schedule solver and registers it for use.

[0169] Multiple schedule solver instances are deployed distributed across nodes with low computing workloads. Since the schedule solver is an independent third-party scheduler, the primary scheduler must pre-determine the computing resources to be consumed for group scheduling based on information about the number of group members in the workload group object, and start one or more schedule solvers as needed.

[0170] S1202: The API server receives the first request information and creates the "Pod" required by the first VNF.

[0171] S1203: The API server stores the "Pod" data required by the first VNF ​​in "Etcd".

[0172] S1204: The primary scheduler pre-selects nodes for the "Pods" required by the first VNF ​​and locks the candidate nodes.

[0173] In the above description, the steps S1202 to S1204 correspond to steps S1002 to S1004 in the embodiment shown in Figure 10.

[0174] S1205: The primary scheduler selects a schedule solver instance and pushes information about candidate nodes, the workload group members "Pods" to dequeue, and the workload group information to the schedule solver.

[0175] In this step, the primary scheduler may select one or more schedule solver instances according to the workload balancing policy and push information about candidate nodes, the workload group members "Pods" to be dequeued, and the attribute information of the first workload group object associated with the "Pods" to the selected schedule solver instances. Note that if multiple schedule solver instances are selected, the information that needs to be pushed is sent in batches to the multiple schedule solver instances, and the multiple schedule solver instances perform the calculations in parallel.

[0176] S1206: The schedule solver invokes the group scheduling algorithm and assigns resource nodes to the workload group members "Pods" that are dequeued from the candidate nodes.

[0177] Each "Pod" in a workload group that is to be dequeued is associated with a first workload group object. The scheduling solver invokes the corresponding group scheduling algorithm according to the group scheduling policy of the first workload group object and calculates which node the "Pod" to be dequeued will be scheduled to, within the range of nodes that have the label of the first workload group object. The group scheduling calculation is not completed until each "Pod" in the workload group queue on which the dequeuing was performed has obtained its corresponding node, or until the consumed duration exceeds the group scheduling timeout duration indicated in the attribute information of the first workload group object.

[0178] S1207: The primary scheduler receives the group scheduling calculation result sent by the schedule solver and updates the information in the primary scheduler cache.

[0179] In this step, the primary scheduler modifies the value of the "nodeName" field of the "Pod" object based on the group scheduling calculation result, and updates the "Pod" and "Node" information in the scheduler cache within the primary scheduler.

[0180] S1208: The primary scheduler updates the "Node" information, "Pod" information, and the information of the workload group object associated with the "Pod" in "Etcd" via the API server.

[0181] This step is basically the same as S1007 in the embodiment of Figure 10. The difference is that in step S1007, the coss scheduler initiates the update request, and in step S1208, the primary scheduler initiates the update request. S1209: The primary scheduler updates the information in the cache.

[0182] This step corresponds to S1008 in the embodiment of Figure 10 and is also an optional step for deploying the "Pod" required by the first VNF. The main function of this step is to avoid deployment failures caused by the inability to invoke a candidate node of another workload group object member "Pod".

[0183] In this embodiment, group scheduling calculations are performed via a scheduling solver deployed on nodes with low computing workloads, which can result in more efficient use of computing resources and reduced computing overhead pressure.

[0184] In the embodiments described above, the first request information is for requesting the instantiation of the first VNF. In some implementations, the first request information may further be for requesting the scaling out of the VDU of the first VNF. If the first request information is for requesting the scaling out of the VDU of the first VNF, Note that the workload group object identifier associated with the scaled-out VDU of the first VNF ​​and indicated by the first information carried in the first request information is the identifier of the first workload group object. Scaled-out the VDU of the first VNF ​​means that the number of VDUs currently associated as group members of the first workload group object via labels has reached the maximum number of group members for the first workload group. Therefore, the first request information further carries second information, which indicates new attribute information for the first workload group object. In the new attribute information for the first workload group object, the original maximum number of group members for the first workload group is changed to the maximum number of scaled-out group members.

[0185] It will be understood that the first VNF ​​is considered to have successfully scaled out only if all scaled-out VDUs of the first VNF ​​are started. Therefore, the VDUs scaled out for the first VNF ​​must then be deployed on the corresponding resource nodes. The method for deploying the scaled-out VDUs is the same as the method for deploying the VDUs required by the first VNF ​​in the embodiments described above. Details will not be repeated here.

[0186] In the embodiments described above, the request information received by the VNFM is entered into the VNFM by the administrator. In some implementations, the NFVO may receive the request information entered by the administrator, and the request information is forwarded to the VNFM via the NFVO. Correspondingly, the deployment software package and the VNFD of the VNF to be deployed are also uploaded to the NFVO's deployment interface, and the group scheduling check function may also be implemented via the NFVO. For example, in step S301 of Figures 3 and 4, the NFVO may receive a first request, the first request information is to trigger the deployment of a virtual deployment unit VDU for the first virtual network function VNF. The NFVO sends a second request information to the infrastructure service manager using the VNFM as an intermediary, the second request information is to request the deployment of the VDU for the first VNF.

[0187] In some implementations, the NFVO may interact directly with the infrastructure service manager. In this case, the VNFM in the above-described embodiment may be replaced by the NFVO, and the associated methods performed by the VNFM in the embodiment's method are performed by the NFVO.

[0188] Figure 13 is a diagram showing the structure of a virtual network function deployment device according to one embodiment of the present application. Referring to Figure 13, the deployment method implemented via VNFM in the embodiments of Figures 3 to 5 will be described below. As shown in Figure 13, the device 1300 of this embodiment may include a receiving module 1301 and a transmitting module 1302.

[0189] The receiving module 1301 is configured to receive a third request information, which is intended to trigger the deployment of a virtual deployment unit (VDU) for a first virtual network function (VNF).

[0190] The transmission module 1302 is configured to send a first request to the infrastructure service manager, which is to request that the VDU be deployed for the first VNF.

[0191] In some implementations, the third request information and the first request information carry the first information, which indicates that the workload group object identifier associated with the VDU required by the first VNF ​​is the first workload group object identifier, and the workload group object identifier indicates the workload group object.

[0192] In some implementations, the transmission module 1302 is further configured to send a second request to the infrastructure service manager, which is to request a query for the workload group object list.

[0193] In some implementations, the receiving module 1301 is further configured to receive a fourth request information, which is for querying the workload group object list.

[0194] In some implementations, the receiving module 1301 is further configured to receive a fifth request information, which requests the creation or update of a workload group object whose workload group object identifier is the first workload group object identifier, and the fifth request information carries the second or third information. The second information includes attribute information to be included in the workload group object whose workload group object identifier is the first workload group object identifier, and the third information includes attribute information to be updated for the attribute information of the workload group object whose workload group object identifier is the first workload group object identifier.

[0195] Figure 14 is a diagram showing the structure of a virtual network function deployment device according to another embodiment of the present application. Referring to Figure 14, the deployment method carried out via an infrastructure server in the embodiments of Figures 3 to 5 will be described below. As shown in Figure 14, the device 1400 of this embodiment may include a receiving module 1401, a processing module 1402, and a check module 1403.

[0196] The receiving module 1401 is configured to receive first request information from the VNFM, which is a request to deploy a VDU for a first VNF.

[0197] The processing module 1402 is configured to create M VDUs for a first VNF ​​and deploy the M VDUs using a group scheduling method. The group scheduling method is for reallocating resources to a second VDU among multiple VDUs if there are multiple VDUs to deploy and resource allocation to the first VDU among multiple VDUs fails, and the second VDU is among multiple VDUs and includes a VDU to which resources were successfully allocated before the first VDU.

[0198] In some implementations, the check module 1403 is configured to either create a workload group object whose workload group object identifier is the first workload group object identifier based on the second piece of information, or to update a workload group object whose workload group object identifier is the first workload group object identifier based on the third piece of information.

[0199] In some implementations, the receiving module 1401 is configured to receive a second request from the VNFM, which is a request to query the workload group object list.

[0200] In some implementations, the receiving module 1401 is configured to receive a fifth request information from the VNFM, and the checking module 1403 is configured to either create a workload group object whose workload group object identifier is the first workload group object identifier based on the second information carried in the fifth request information, or to update a workload group object whose workload group object identifier is the first workload group object identifier based on the third information carried in the fifth request information.

[0201] It should be understood that devices 1300 and 1400 are embodied in the form of functional modules. The term “module” may refer to an application-specific integrated circuit (ASIC), electronic circuitry, a processor configured to run one or more software or firmware programs (e.g., a shared processor, a dedicated processor, or a group processor), memory, merged logic circuits, and / or other suitable components that support the described functionality.

[0202] Apparatus 1300 and apparatus 1400 have the function of performing the corresponding procedures and / or steps in the embodiments of the method described above. These functions may be performed by hardware, or by hardware by running corresponding software. The hardware or software includes one or more modules corresponding to those functions.

[0203] Figure 15 is a diagram showing the structure of a virtual network function deployment device according to yet another embodiment of the present application. The device 1500 shown in Figure 15 may be configured to perform a method performed by the virtual network function deployment device in any of the methods described above. The virtual network function deployment device in the embodiments of Figures 13 and 14 will be described in detail with reference to Figure 15.

[0204] As shown in Figure 15, the device 1500 of this embodiment includes a memory 1501, a processor 1502, a communication interface 1503, and a bus 1504. The memory 1501, the processor 1502, and the communication interface 1503 communicate with each other via the bus 1504.

[0205] Memory 1501 may be read-only memory (ROM), a static storage device, a dynamic storage device, or random access memory (RAM). Memory 1501 may store a program. When a program stored in memory 1501 is executed by processor 1502, processor 1502 is configured to perform one of the methods described above.

[0206] The processor 1502 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit, or one or more integrated circuits, and is configured to execute the associated program.

[0207] Alternatively, the processor 1502 may be an integrated circuit chip having signal processing capabilities. In the implementation process, the relevant steps in this embodiment of the present application may be completed via hardware integrated logic circuits within the processor 1502 or via instructions in the form of software.

[0208] Alternatively, the processor 1502 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor may implement or perform the methods, steps, and logic block diagrams disclosed in embodiments of this application. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc.

[0209] The steps in the methods disclosed with reference to embodiments of this application may be performed and carried out directly by a hardware decoding processor, or by using a combination of hardware and software modules within the decoding processor. The software modules may be located in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage media is located in memory 1501, and the processor 1502 reads information in memory 1501 and, in combination with the processor's hardware, completes the functions that need to be performed by the units included in the apparatus of this application.

[0210] The communication interface 1503 may, but is not limited to, use a transceiver device, such as a transceiver, to facilitate communication between the device 1500 and another device or apparatus.

[0211] Bus 1504 may include channels for transmitting information between different parts of the device 1500 (e.g., memory 1501, processor 1502, and communication interface 1503).

[0212] One embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores computer instructions. When a processor executes a computer instruction, the steps of the method of the above-described embodiment are performed.

[0213] One embodiment of this application further provides a computer program product including computer instructions. When the computer instructions are executed by a processor, the steps of the method of the above-described embodiment are carried out.

[0214] It should be noted that the modules or components shown in the embodiments described above may also be one or more integrated circuits configured to carry out the methods described above, such as one or more application-specific integrated circuits, one or more microprocessors, or one or more field-programmable gate arrays. As another example, if the modules described above are implemented in a manner in which processing elements call program code, the processing elements may be a central processing unit or another processor capable of calling program code, such as a general-purpose processor like a controller. As yet another example, the modules may be integrated together and implemented in the form of a system-on-a-chip (SoC).

[0215] All or part of the embodiments described above may be implemented using software, hardware, firmware, software modules, or any combination thereof. When the software is for implementing the embodiments, all or part of the embodiments may be implemented in the form of a computer program product. A 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 procedures or functions according to the embodiments of this application are generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted by wired means (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless means (e.g., infrared, radio, or microwave) from one website, computer, server, or data center to another website, computer, server, or data center. Computer-readable storage media can be any available medium accessible by a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disk drives, or magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0216] Those skilled in the art will readily understand, after reviewing this specification and implementing the invention disclosed herein, alternative implementation solutions of this application. This application is intended to cover any variations, functions, or adaptive modifications of this application. Variations, functions, or adaptive modifications are adapted to the general principles of this application and include common knowledge or commonly used technical means in the art not disclosed herein. This specification and embodiments are considered merely examples, and the actual scope and spirit of this application are shown by the following claims.

[0217] It should be understood that this application is not limited to the exact structure described above and shown in the attached drawings, and that various modifications and changes may be made without departing from the scope of this application. The scope of this application is limited only by the attached claims. [Explanation of symbols]

[0218] 1300 equipment 1301 Receiver Module 1302 Transmitter Module 1400 equipment 1401 Receiver Module 1402 Processing Module 1403 Check Module 1500 equipment 1501 memory 1502 Processors 1503 Communication Interface 1504 Bus

Claims

1. A method for deploying virtual network functions applicable to an infrastructure service manager, A step of receiving first request information sent by a virtual network function manager VNFM, wherein the first request information is for requesting the deployment of a virtual deployment unit VDU for a first virtual network function VNF, A step of creating M VDUs for the first VNF, wherein the M VDUs are associated as VDUs within the same group, and M is a positive integer. A step of deploying the VDUs within the same group by using a group scheduling method, wherein the group scheduling method allocates resources to each of the VDUs within the same group in one computation periodicity, and the computation periodicity is for calculating the corresponding resources for each of the VDUs within the same group, until each of the VDUs within the same group acquires the corresponding resources or the allocation of resources from the VDUs within the same group to the entire group fails, A method for deploying virtual network functions, including the above.

2. The first request information carries the first information, which indicates that the workload group object identifier associated with the VDU required by the first VNF ​​is the first workload group object identifier, the workload group object identifier indicates a workload group object, the workload group object includes the following attribute information, namely, the maximum number of VDUs associated with the workload group object identifier, the scheduling policy when the VDUs associated with the workload group object identifier are deployed using the group scheduling method, the scheduling priority when the VDUs associated with the workload group object identifier are deployed using the group scheduling method, and the timeout duration when the VDUs associated with the workload group object identifier are deployed using the group scheduling method. The step of creating the M VDUs for the first VNF ​​is: A step of creating M VDUs, each of which is associated with the first workload group object identifier, The step of deploying the M VDUs by using the group scheduling method is: The process includes the step of expanding the VDU associated with the first workload group object identifier by using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier, The method according to claim 1.

3. The step of expanding the VDU associated with the first workload group object identifier by using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier is: Steps to obtain an undeployed VDU, If the workload group object identifier associated with the undeployed VDU is the first workload group object identifier, the steps include adding the undeployed VDU to the retrieved scheduling queue associated with the first workload group object identifier, The steps include: expanding the VDU in the scheduling queue by using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier; The method according to claim 2, including the method described in claim 2.

4. By using the group scheduling method, the step of expanding the VDU in the scheduling queue based on the attribute information of the workload group object indicated by the first workload group object identifier is: If the number of VDUs in the scheduling queue is equal to the maximum number of the workload group object indicated by the first workload group object identifier, the group scheduling method is used to deploy the VDUs in the scheduling queue in accordance with the scheduling policy and scheduling priority of the workload group object indicated by the first workload group object identifier, until each VDU in the scheduling queue is successfully deployed or the deployment duration exceeds the scheduling timeout duration of the workload group object indicated by the first workload group object identifier. The method according to claim 3, including the method described in claim 3.

5. A step of receiving second information from the VNFM, wherein the second information indicates the creation of a workload group object whose identifier is the first workload group object identifier. The method according to any one of claims 2 to 4, further comprising:

6. The steps include sending a list of workload group objects to the VNFM, The step of receiving the second information from the VNFM is: If the aforementioned workload group object list does not include the workload group object whose identifier is the first workload group object identifier, The step of receiving the second information from the VNFM, The method according to claim 5, including the method described in claim 5.

7. A step of receiving third information from the VNFM, wherein the third information indicates that the attribute information of the workload group object whose identifier is the first workload group object identifier is updated. The method according to any one of claims 2 to 6, further comprising:

8. The step further includes sending the aforementioned workload group object list to the VNFM, The step of receiving the third information from the VNFM is: If the aforementioned workload group object list includes the workload group object whose identifier is the aforementioned first workload group object identifier, The step includes receiving the third information from the VNFM, The method according to claim 7.

9. Before the step of sending the aforementioned workload group object list to the VNFM, A step of receiving a second request information from the VNFM, wherein the second request information is for requesting to query the workload group object list, The method according to claim 6 or 8, further comprising:

10. The step of deploying the VDU in the scheduling queue by using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier is: A step of associating a group scheduling label with a first node via a first scheduler, wherein the first node includes a candidate deployment node for the VDU in the scheduling queue, and the first scheduler is configured to allocate resources to the VDU. Steps of deploying the VDU in the scheduling queue via a second scheduler using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier, wherein the second scheduler is a copy of the first scheduler; The method according to claim 3, including the method described in claim 3.

11. The step of deploying the VDU in the scheduling queue by using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier is: A step of associating the group scheduling label with the first node via the first scheduler, wherein the first node includes the candidate deployment node of the VDU in the scheduling queue, and the first scheduler is configured to allocate the resource to the VDU. Steps include: deploying the VDU in the scheduling queue via at least one scheduling solver, using the group scheduling method based on the attribute information of the workload group object indicated by the first workload group object identifier, wherein the scheduling solver is an independent third-party scheduler; The method according to claim 10, including the method described in claim 10.

12. A method for deploying virtual network functions that applies to a virtual network function manager (VNFM), A step of receiving a third request information, wherein the third request information is for triggering the deployment of a virtual deployment unit (VDU) to a first virtual network function (VNF), A step of sending first request information to an infrastructure service manager, wherein the first request information is for requesting that the VDU be deployed to the first VNF, A method for deploying virtual network functions, including the above.

13. The method according to claim 12, wherein the third request information and the first request information carry first information, the first information indicating that the workload group object identifier associated with the VDU required by the first VNF ​​is a first workload group object identifier, the workload group object identifier indicates a workload group object, the workload group object includes the following attribute information, namely, the maximum number of VDUs associated with the workload group object identifier, the scheduling policy when the VDU associated with the workload group object identifier is deployed using the group scheduling method, the scheduling priority when the VDU associated with the workload group object identifier is deployed using the group scheduling method, and the timeout duration when the VDU associated with the workload group object identifier is deployed using the group scheduling method.

14. A step of transmitting second information to the infrastructure service manager, wherein the second information indicates the creation of a workload group object whose identifier is the first workload group object identifier. The method according to claim 13, further comprising:

15. The step further includes receiving a list of workload group objects from the infrastructure service manager, The step of sending the above-mentioned second information to the infrastructure service manager is: If the workload group object list does not include the workload group object whose identifier is the first workload group object identifier, the step includes sending the second information to the infrastructure service manager. The method according to claim 14.

16. A step of transmitting a third piece of information to the infrastructure service manager, the third piece of information indicating that it updates the attribute information of the workload group object whose identifier is the first workload group object identifier, The method according to any one of claims 13 to 15, further comprising:

17. The step further includes receiving the workload group object list from the infrastructure service manager, The step of sending the third information to the infrastructure service manager is: If the workload group object list includes the workload group object whose identifier is the first workload group object identifier, the step includes sending the third information to the infrastructure service manager. The method according to claim 16.

18. Before the step of receiving the workload group object list from the infrastructure service manager, A step of sending a second request to the infrastructure service manager, wherein the second request is for requesting to query the workload group object list, The method according to claim 15 or 17, further comprising:

19. The method according to any one of claims 12 to 18, wherein the third request information specifically requests to instantiate the first VNF, or the third request information specifically requests to scale out the VDU of the first VNF.

20. The method according to any one of claims 12 to 19, wherein the third request information is entered by an administrator on the VNFM, or the third request information is received from a network function virtualization orchestrator NFVO.

21. A virtual network function deployment device comprising a function module configured to implement the virtual network function deployment method described in any one of claims 1 to 11, or a function module configured to implement the virtual network function deployment method described in any one of claims 12 to 19.

22. A virtual network function deployment system comprising a first deployment device and a second deployment device, wherein the first deployment device is configured to perform the virtual network function deployment method described in any one of claims 1 to 11, and the second deployment device is configured to perform the virtual network function deployment method described in any one of claims 12 to 19.

23. A computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the computer-executable instructions are for carrying out the virtual network function deployment method described in any one of claims 1 to 11 or any one of claims 12 to 19.

24. A computer program product comprising a computer program, wherein when the computer program is executed by a processor, the virtual network function deployment method described in any one of claims 1 to 11 or any one of claims 12 to 19 is performed.

Images