Method and apparatus for deploying virtual network functions

Abstract

The application provides a virtual network function deployment method and a deployment device. The deployment method allocates resources for VDU required by a VNF to be deployed, takes the total VDU required as a whole group, calculates and schedules resources required by the total VDU in a calculation period in a group granularity, and until the whole group of VDU is scheduled to obtain corresponding resources or the whole group of VDU fails to be scheduled. The deployment position of the VDU of the VNF to be deployed is calculated in a group granularity, and the allocation mode not conducive to the overall deployment is recalculated and adjusted, so that the success rate of VNF deployment is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network function virtualization, and particularly relates to a virtual network function deployment method and a deployment device. BACKGROUND

[0002] Network function virtualization (NFV) technology can realize decoupling of upper-layer software and lower-layer general hardware through virtualization of computing resources, storage resources and network resources, so as to flexibly deploy software-defined network functions to general servers, switches and storage devices, and promote efficient and low-cost network operation. In the NFV framework, a network function implemented by software is referred to as a virtual network function (VNF). In order to ensure normal operation of the VNF and collaborative work between different VNFs, a cloud operating system (OS) needs to schedule resources and deploy the VNF to a general hardware platform. SUMMARY

[0003] The present application provides a virtual network function deployment method and a deployment device, aiming to improve network deployment efficiency.

[0004] In a first aspect, the present application provides a virtual network function deployment method applied to an infrastructure service manager, and the method comprises the following steps: receiving first request information sent by a virtual network function manager (VNFM), the first request information being used to request to deploy 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 a same group of VDUs, M being a positive integer; and deploying the same group of VDUs by using a group scheduling method, wherein the group scheduling method is to allocate resources for each VDU in the same group of VDUs in one calculation period, until each VDU in the same group of VDUs obtains corresponding resources or the same group of VDUs fails to be allocated with resources as a whole, and the calculation period is used to calculate corresponding resources for each VDU in the same group of VDUs.

[0005] In the method, the group scheduling method takes the whole of the multiple VDUs as a granularity, and uniformly schedules and calculates the resources required by the whole of the multiple VDUs, so as to improve the rationality of resource allocation and increase the success possibility of VDU deployment.

[0006] In a possible implementation, the first request information carries first information, the first information indicates that a load group object identifier associated with a VDU required by the first VNF is a first load group object identifier, the load group object identifier is used to indicate a load group object, and the load group object includes the following attribute information: a maximum number of VDUs that can be associated with the load group object identifier, a scheduling strategy when the VDU associated with the load group object identifier is deployed by using a group scheduling method, a scheduling priority when the VDU associated with the load group object identifier is deployed by using the group scheduling method, and a scheduling timeout time when the VDU associated with the load group object identifier is deployed by using the group scheduling method.

[0007] The infrastructure service manager creates M VDUs for the first VNF, including: the infrastructure service manager creates M VDUs, and each VDU in the M VDUs is associated with the first load group object identifier.

[0008] The M VDUs are deployed by using the group scheduling method, including: the VDU associated with the first load group object identifier is deployed according to the attribute information of the load group object indicated by the first load group object identifier by using the group scheduling method.

[0009] The load group object is introduced as a custom resource, the load group object is a whole group, and a plurality of VDUs required by a VNF to be deployed are associated with the load group object by using a tag and become members of the load group object. Meanwhile, a plurality of attributes of the load group object are beneficial to subsequent deployment by using the group scheduling method.

[0010] In some implementations, the VDU associated with the first load group object identifier is deployed according to the attribute information of the load group object indicated by the first load group object identifier by using the group scheduling method, including:

[0011] The undeployed VDU is obtained; when the load group object identifier associated with the undeployed VDU is the first load group object identifier, the undeployed VDU is added to a scheduling queue associated with the obtained first load group object identifier; and the VDU in the scheduling queue is deployed according to the attribute information of the load group object indicated by the first load group object identifier by using the group scheduling method.

[0012] According to the load group object identifier associated with the undeployed VDU, the ordinary VDU and the VDU that needs to be deployed by using the group scheduling method can be added to different scheduling queues, so as to subsequently deploy different VDUs.

[0013] In some implementations, the VDU in the scheduling queue is deployed according to the attribute information of the load group object indicated by the first load group object identifier by using the group scheduling method, including:

[0014] When the number of VDUs in the scheduling queue is equal to the maximum number of load group objects indicated by the first load group object identifier, the VDUs in the scheduling queue are deployed according to the scheduling strategy and the scheduling priority in the load group objects indicated by the first load group object identifier using the group scheduling method, until each VDU in the scheduling queue is successfully deployed or the deployment time exceeds the scheduling timeout time indicated by the load group objects indicated by the first load group object identifier.

[0015] The member number of the load group object is used as the dequeuing rule of the scheduling queue to ensure that the dequeued VDU is associated with the same load group object, so that the group scheduling method is used to schedule multiple VDUs in a group as a granularity.

[0016] In a possible implementation, the method further includes:

[0017] The second information is received from the VNFM, and the second information is used to indicate that the load group object identified by the first load group object identifier is created.

[0018] In some implementations, the method further includes:

[0019] The load group object list is sent to the VNFM, and the second information is received from the VNFM, including: when the load group object identified by the first load group object identifier is not included in the load group object list, the second information is received from the VNFM.

[0020] In some implementations, the method further includes:

[0021] The third information is received from the VNFM, and the third information is used to indicate that the attribute information in the load group object identified by the first load group object identifier is updated.

[0022] In some implementations, the method further includes:

[0023] The load group object list is sent to the VNFM, and the third information is received from the VNFM, including: when the load group object identified by the first load group object identifier is included in the load group object list, the third information is received from the VNFM.

[0024] In some implementations, before the load group object list is sent to the VNFM, the method further includes:

[0025] The second request information is received from the VNFM, and the second request information is used to request to query the load group object list.

[0026] The virtual network function deployment method provided in the present application can not only independently perform add, delete, modify and query operations on load group objects, but also implement group scheduling verification in the process of deploying VDUs.

[0027] In a possible implementation, the VDU in the scheduling queue is deployed according to attribute information of a load group object indicated by the first load group object identifier, by using a group scheduling method, including:

[0028] The first node includes a candidate deployment node of the VDU in the scheduling queue, and the first scheduler is used for allocating resources for the VDU; the VDU in the scheduling queue is deployed according to attribute information of a load group object indicated by the first load group object identifier, by using a group scheduling method by the second scheduler, which is a copy of the first scheduler.

[0029] In some implementations, the VDU in the scheduling queue is deployed according to attribute information of a load group object indicated by the first load group object identifier, by using a group scheduling method, including:

[0030] The first node includes a candidate deployment node of the VDU in the scheduling queue, and the first scheduler is used for allocating resources for the VDU; the VDU in the scheduling queue is deployed according to attribute information of a load group object indicated by the first load group object identifier, by using a group scheduling method by the at least one scheduling solver, which is an independent third-party scheduler.

[0031] The VDU in the scheduling queue is deployed according to attribute information of a load group object indicated by the first load group object identifier, by using a group scheduling method by the second scheduler or the scheduling solver, which can relieve the computing load pressure.

[0032] In a second aspect, the present application provides a virtual network function deployment method, applied to a virtual network function manager VNFM, including:

[0033] Receiving third request information, the third request information is used to trigger the deployment of a virtual deployment unit VDU for a first virtual network function VNF; sending first request information to an infrastructure service manager, the first request information is used to request the deployment of the VDU for the first VNF.

[0034] In a possible implementation, the third request information and the first request information carry first information, the first information indicates that a load group object identifier associated with a VDU required by the first VNF is a first load group object identifier, the load group object identifier is used to indicate a load group object, and the load group object includes the following attribute information: a maximum number of VDUs that can be associated with the load group object identifier, a scheduling strategy when the VDU associated with the load group object identifier is deployed by using a group scheduling method, a scheduling priority when the VDU associated with the load group object identifier is deployed by using the group scheduling method, and a scheduling timeout time when the VDU associated with the load group object identifier is deployed by using the group scheduling method.

[0035] In a possible implementation, the method further includes:

[0036] sending second information to the infrastructure service manager, the second information being used to indicate creation of a load group object identified by the first load group object identifier.

[0037] In some implementations, the method further includes:

[0038] receiving a load group object list from the infrastructure service manager; wherein sending the second information to the infrastructure service manager includes sending the second information to the infrastructure service manager when the load group object identified by the first load group object identifier is not included in the load group object list.

[0039] In some implementations, the method further includes:

[0040] sending third information to the infrastructure service manager, the third information being used to indicate update of attribute information in the load group object identified by the first load group object identifier.

[0041] In some implementations, the method further includes:

[0042] receiving a load group object list from the infrastructure service manager; wherein sending the third information to the infrastructure service manager includes sending the third information to the infrastructure service manager when the load group object identified by the first load group object identifier is included in the load group object list.

[0043] In some implementations, before receiving the load group object list from the infrastructure service manager, the method further includes:

[0044] sending second request information to the infrastructure service manager, the second request information being used to request query of the load group object list.

[0045] In some implementations, the third request information is specifically used to request instantiation of the first VNF, or the third request information is specifically used to request VDU scaling for the first VNF.

[0046] The third request information, whether used to request instantiation of the first VNF or used to request scaling for the first VNF, needs to allocate scheduling resources for VDU required by the first VNF.

[0047] In some implementations, the request information received by the VNFM is input by an administrator on the VNFM, or the request information received by the VNFM is received by the VNFM from the NFVO.

[0048] Under the NFV system architecture, both the NFVO and the VNFM can implement management of VNFs.

[0049] In a third aspect, the present application provides a virtual network function deployment apparatus, which comprises various functional modules for implementing any of the deployment methods mentioned in the above implementation manners. In some implementation manners, each module can be implemented by software and / or hardware.

[0050] In a fourth aspect, the present application provides a virtual network function deployment apparatus, which comprises a processor and a memory connected with the processor in communication; the memory stores computer-executed instructions. The processor executes the computer-executed instructions stored in the memory to implement the virtual network function deployment method provided in the first aspect.

[0051] In a fifth aspect, the present application provides a virtual network function deployment apparatus, which comprises a processor and a memory connected with the processor in communication; the memory stores computer-executed instructions. The processor executes the computer-executed instructions stored in the memory to implement the virtual network function deployment method provided in the second aspect.

[0052] In a sixth aspect, the present application provides a virtual network function deployment system, which comprises the apparatus in the fourth aspect and the apparatus in the fifth aspect.

[0053] In a seventh aspect, the present application provides a computer program product, which comprises a computer program; the computer program is executed by a processor to implement the method in the first aspect, the second aspect or any of the possible implementation manners thereof.

[0054] In an eighth aspect, the present application provides a computer readable medium, which stores program codes for execution by an apparatus, the program codes comprising codes for executing the method in the first aspect, the second aspect or any of the possible implementation manners thereof. BRIEF DESCRIPTION OF DRAWINGS

[0055] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and serve to explain the principles of the present application, together with the description.

[0056] Figure 1 A schematic diagram of a NFV system standardization architecture proposed by the European Telecommunications Standards Institute;

[0057] Figure 2 A schematic diagram of a load group concept provided by an embodiment of the present application;

[0058] Figure 3 A schematic diagram of a virtual network function deployment method provided by an embodiment of the present application;

[0059] Figure 4 A schematic diagram of a virtual network function deployment method provided by an embodiment of the present application;

[0060] Figure 5 A flowchart for implementing adding, deleting, modifying and inquiring of a load group object list is provided for an embodiment of the present application.

[0061] Figure 6 A schematic diagram of a VDU associating a load group object is provided for an embodiment of the present application.

[0062] Figure 7 A component architecture schematic diagram of K8S extension group scheduling is provided for an embodiment of the present application.

[0063] Figure 8 A flowchart of K8S implementing group scheduling is provided for an embodiment of the present application.

[0064] Figure 9 A framework schematic diagram of K8S extension coordinator supporting group scheduling calculation is provided for an embodiment of the present application.

[0065] Figure 10 A flowchart of K8S implementing group scheduling through a master coordinator is provided for an embodiment of the present application.

[0066] Figure 11 A framework schematic diagram of K8S extension scheduler supporting group scheduling calculation is provided for an embodiment of the present application.

[0067] Figure 12 A flowchart of K8S implementing group scheduling through a master scheduler and a scheduler is provided for an embodiment of the present application.

[0068] Figure 13 A structural schematic diagram of a virtual network function deployment apparatus is provided for an embodiment of the present application.

[0069] Figure 14 A structural schematic diagram of a virtual network function deployment apparatus is provided for another embodiment of the present application.

[0070] Figure 15 A structural schematic diagram of a virtual network function deployment apparatus is provided for still another embodiment of the present application.

[0071] Through the above-mentioned drawings, the specific embodiments of the present application have been shown, and more detailed descriptions will be given hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of the present application by any means, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0072] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0073] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Traditional telecommunications network systems consist of various specialized hardware devices, each running corresponding functions. As network scale increases, telecommunications network systems become increasingly complex, and scalability decreases. NFV technology, through virtualization, separates the software functions of devices from the underlying hardware, achieving software and hardware decoupling of telecommunications network functional nodes, and is a core technology for the cloudification of telecommunications-grade services. Based on NFV technology, VNFs with different functions can be deployed on a general-purpose hardware platform, thereby reducing the cost of telecommunications network systems and providing better scalability.

[0074] Different vendors may develop VNFs with different functionalities. Service providers can flexibly select VNFs according to their own needs and combine different VNFs. In order to ensure that all selected VNFs can work together normally and run on a common hardware platform, a standardized architecture is needed to constrain the development of VNFs. Figure 1 This is a schematic diagram of the standardized architecture of an NFV system proposed by the European Telecommunications Standards Institute (ETSI). Figure 1 As shown, the NFV system includes the NFV management and orchestration (NFV-MAMO) module, the NFV infrastructure (NFVI), VNF, the element management (EM) module, and the operation support system / business support system (OSS / BSS).

[0075] Among them, the NFV-MAMO module includes four functional modules of NFV orchestrator (NFVO), VNF manager (VNFM), container infrastructure service manager (CISM) and virtualized infrastructure manager (VIM).

[0076] The NFVO has a global view function of virtual resources, mainly responsible for processing the life cycle management of virtual services, the allocation and scheduling of virtual resources in virtual infrastructure and NFVI, and the NFVO can also execute resource-related requests from the VNFM, send configuration information to the VNFM, and collect the state information of the VNF.

[0077] The VNFM is mainly responsible for the life cycle management of one or more VNFs, and the VNFM can perform instantiation, update, query, elastic scaling and termination operations on the VNF by communicating with the VNF. There can be multiple VNFM in the NFV system, which are responsible for the life cycle management of different types of VNFs.

[0078] The VIM can perform resource management functions, such as managing the allocation of infrastructure resources, resource discovery and fault handling. The VIM and the VNFM can communicate with each other to allocate resources and exchange configuration and state information of virtualized hardware resources. The function of CISM is similar to that of VIM, mainly for resource management of container objects. Both VIM and CISM are infrastructure service managers.

[0079] NFVI is mainly used to provide hardware resources for upper-layer VNFs. The underlying physical hardware resources in NFVI are abstracted into virtualized hardware resources such as virtual machines (VMs) and containers through a virtualization layer. The upper-layer VNF runs in a virtualized resource environment, achieving complete decoupling of software and hardware.

[0080] The EM module performs traditional fault, user and configuration, performance and security management functions for VNFs.

[0081] OSS / BSS supports various end-to-end telecommunications services. OSS supports network configuration, service provision and fault management functions, and BSS supports product management, order management, revenue management and customer management.

[0082] Under the NFV architecture, cloud OS can be used to achieve comprehensive virtualization of computing resources, storage resources and network resources, and can perform unified management, monitoring and optimization of physical hardware virtualized resources.

[0083] As a core technology for implementing cloud computing, NFV technology introduces three levels of services for implementing cloud computing of telecom-level services: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).

[0084] IaaS focuses on providing basic resources for users, and in actual applications, it is usually provided in the form of a VM. Therefore, when implementing network function virtualization under an IaaS architecture, one or more VMs are invoked to deploy a VNF of a corresponding function in a virtual machine scenario.

[0085] PaaS is a business model that provides a server platform as a service. In a PaaS architecture, interface services are provided to other business developers, who can develop businesses or applications using these service interface capabilities.

[0086] Container as a service (CaaS) provides services in the form of containers and can be regarded as a specific type of PaaS service. Containers are an operating system-level virtualization technology that isolates different processes through operating system isolation technologies such as CGroup and Namespace under Linux. Containers do not have an operating system, only processes, and are therefore more lightweight than VMs. Containers can be deployed not only on bare metal but also in virtual machines. A containerized system deployed on bare metal is called a bare-metal container, and a containerized system deployed on a virtual machine is called a virtual machine container. When implementing network function virtualization under a CaaS architecture, one or more containers are invoked to deploy a VNF of a corresponding function in a container scenario.

[0087] Under a CaaS architecture, the most widely used container management and orchestration technology in the field at present is the Kubernetes (K8S) container cluster management system based on an open-source platform. K8S can provide a complete set of functions such as resource scheduling, deployment and running, service discovery, and scaling for containerized applications, and its essence can be regarded as a mini-CaaS manager based on container technology.

[0088] According to the above different scenarios, one or more smaller granularity virtual deployment units (VDUs) are required when deploying VNFs. In a virtual scenario, a VDU object refers to a VM; in a container scenario, K8S uses the minimum deployment unit "Pod" to manage containers, and each "Pod" contains one or more closely related containers, so the VDU object refers to a "Pod". When CISM / VIM schedules resources to deploy VNFs, it actually allocates resources for the VDUs contained in the VNF to be deployed. Only when all the VDUs of the VNF to be deployed are bound to the corresponding resource nodes can it be determined that the corresponding VNF deployment is successful.

[0089] In the prior art, the CISM / VIM scheduler calculates the deployment location with a single VDU as the granularity. In the case where the hardware resources are limited but meet the VNF deployment requirements, after some VDUs are deployed to the corresponding hardware location, the remaining VDUs may not be able to be deployed due to insufficient remaining resources, resulting in VNF deployment failure. For example:

[0090] In a container scenario, the virtual deployment unit VDU corresponds to "Pod", and the current "Pod" required by the VNF to be deployed has A-Pod{Cpu(6v) / Mem(40G)}, B-Pod{Cpu(2v) / Mem(20G)}, C-Pod{Cpu(4v) / Mem(40G)} and D-Pod{Cpu(4v) / Mem(30G)} respectively, and the current available resources include frame 0-slot 0 single board: numa0{FreeCpu(8v) / Mem(100G)} and numa1{FreeCpu(8v) / Mem(100G)}. CISM calculates the deployment location for each Pod in the order of B, C, D, and A. The calculation shows that B-Pod and C-Pod are deployed on numa0, and D-Pod is deployed on numa1. When calculating the deployment location for A-Pod, since the remaining resources on numa0 and numa1 do not meet the requirements of A-Pod, A-Pod fails to allocate resources. Since the prior art calculates resources with a single "Pod" as the granularity, when A-Pod deployment fails, CISM can only repeatedly calculate the deployment location of A-Pod within the deployment time limit until it times out, resulting in VNF deployment failure.

[0091] On the other hand, calculating the deployment location with a single VDU as the granularity, when multiple VNFs share a host aggregate (HA) resource pool, the VDU in the VNF has discrete resource requirement specifications, and the remaining resources of multiple single boards in the HA are insufficient to deploy other VDUs, resulting in a large amount of resource fragmentation that cannot be utilized.

[0092] To solve the above problems, the application provides a virtual network function deployment method, aiming to improve network deployment efficiency.

[0093] The technical concept of the application is that when allocating resources for VDU required by the VNF to be deployed, the required full VDU is associated as a whole group, the resources required for scheduling the full VDU are calculated in a group as a granularity in a calculation period, when the scheduling of any VDU fails, the VDU to which the resources have been successfully allocated in the group is recalculated for the allocatable resources, until the corresponding resources are scheduled for the whole group of VDU or the whole group of VDU fails.

[0094] When the deployment position of the VDU of the VNF to be deployed is calculated in a group as a granularity, the allocation mode that is not conducive to the overall deployment is recalculated and adjusted, and the success rate of VNF deployment is improved.

[0095] Figure 2 The load group concept diagram is provided for the embodiments of the application. The application introduces the concept of load group (WorkloadGroup) to assist the infrastructure service manager to group schedule the VDU required by the VNF to be deployed. For the infrastructure service manager, the load group is a self-defined resource, and the load group object is the instantiation of the resource. As shown in Figure 2 Load group 1 (WorkloadGroup1) is a load group object, and the load group object has a series of attributes, including: load group name identification, group member quantity, group scheduling strategy, group scheduling priority and group scheduling timeout.

[0096] In this system, workload1, workload2, and workload3 are the three VDUs required for the deployed VNF. They are associated with the name of WorkloadGroup1 through tags, becoming members of WorkloadGroup1. Workload4 is a regular VDU workload for comparison. The group scheduling strategy is the scheduling strategy used by CISM / VIM when deploying workload1 to workload3, members of WorkloadGroup1. Based on resource requirements, it can be categorized as LeastHost, LeastAllocate, and MostAllocate. Group scheduling priority distinguishes the scheduling priority between different workload groups; a smaller priority value indicates a higher priority. It should be noted that VDU priorities are manually set, and members of the same workload group have the same priority. The group scheduling timeout is the time limit for CISM / VIM to allocate resources to workload1 to workload3. If any VDU fails to receive the required scheduling resources within the group scheduling timeout period, the deployment is considered a failure.

[0097] Figure 3 This application provides an exemplary interactive flowchart of a method for deploying a virtual network function according to an embodiment of the present application. This method can be applied to, for example... Figure 1 In the system described above, the following is combined with Figure 3 Regarding this deployment method Figure 1 The application in the NFV system shown is described in detail. The Infrastructure Service Manager in this embodiment can be CISM or VIM.

[0098] S301, VNFM receives third request information, which is used to trigger the deployment of a virtual deployment unit (VDU) for the first virtual network function (VNF).

[0099] In this step, the third request information is used to trigger the deployment of a VDU for the first VNF. As an example, the third request information is the instantiation request information for the first VNF. As the management module for VNFs, VNFM allows administrators to trigger the instantiation request for the first VNF ​​by sending the third request information to VNFM through its deployment interface.

[0100] It should be noted that before triggering the instantiation request by the VNFM deployment interface, the deployment software package of the first VNF and the virtualized network function descriptor (VNFD) need to be uploaded. The deployment software package contains a software image for running the VNF, which is downloaded to the infrastructure service manager. The VNFD is a description template for deploying the VNF, from which the VNFM can extract the input parameters required for deploying the first VNF. The deployment software package and the VNFD template can be uploaded through the VNF Portal.

[0101] In some implementations, the third request information also carries the first information, and the first information indicates that the load group object identifier associated with the VDU required by the first VNF is the first load group object identifier, so that the VDU required by the first VNF becomes a group member of the first load group object. It can be understood that the load group object identifier is the load group name identifier in the load group object attribute, and the attribute information of the first load group object is used to assist the infrastructure service manager in group scheduling the VDU required by the first VNF.

[0102] It should be noted that the load group object identifier associated with the VDU required by the first VNF indicated by the first information and the attribute information contained in the first load group object are obtained based on the VNFD, that is, when the CISM / VIM performs group scheduling on the VDU required by the VNF to be deployed based on the concept of load group, the group scheduling tag of the VDU required by the VNF to be deployed and the attribute parameters of the associated load group object also need to be included in the VNFD template. After the administrator obtains the above information based on the VNFD, the administrator can also make further modifications according to the needs.

[0103] In this embodiment, when deploying the VDU associated with the load group object according to the attribute information of the load group object, as shown in FIG. 3A, Figure 4 The method further includes S301-1, S301-2 and S301-3.

[0104] S301-1, the VNFM sends second request information to the infrastructure service manager to obtain a load group object list and information.

[0105] The infrastructure service manager provides the VNFM with an interface for adding, deleting, modifying and querying the load group object, and the VNFM sends the second request information to the infrastructure service manager, so as to query the identifier and attribute information of the load group object contained in the load group object list.

[0106] S301-2, the VNFM judges whether to create or update the first load group object, generates and sends configuration information to the infrastructure service manager.

[0107] In this step, the VNFM can query whether the load group object list contains the load group object identified by the first load group object identifier according to the first information.

[0108] If the load group object list does not contain the load group object identified by the first load group object identifier, the VNFM determines that the first load group object needs to be created. Accordingly, the VNFM generates second information, which is used to instruct to create the load group object identified by the first load group object.

[0109] If the load group object list contains the load group object identified by the first load group object identifier, denoted as the initial first load group object, the VNFM further determines whether the attribute information of the initial first load group object is the same as the attribute information of the first load group object indicated by the first information. If the attribute information of the initial first load group object is different from the attribute information of the first load group object indicated by the first information, the VNFM determines that the attribute information of the initial first load group object in the load group object list needs to be updated. Accordingly, the VNFM generates third information, which is used to instruct to update the attribute information of the load group object identified by the first load group object identifier.

[0110] The second information or the third information indicates the configuration information required by the first load group object, which is sent by the VNFM to the infrastructure service manager

[0111] S301-3, the infrastructure service manager creates or updates the first load group object in response to the configuration information.

[0112] The second information or the third information contains the identifier and the attribute information of the first load group object. According to the configuration information, the infrastructure service manager creates the first load group object or updates the attribute information of the initial first load group object in the load group object list to be consistent with the attribute information of the first load group object contained in the configuration information.

[0113] It can be understood that the above three steps S301-1, S301-2 and S301-3 play a group scheduling verification function, which prevents the identifier and other attribute information of the first load group object indicated by the first information from conflicting with the existing load group object information in the load group object list, and avoids causing the first VNF deployment to fail. The above three steps are non-essential steps in the first VNF deployment process.

[0114] S302, the VNFM sends first request information to the infrastructure service manager, the first request information being used to request to deploy VDU for the first VNF.

[0115] In this step, the first request information is used to request the infrastructure service manager to create VDU for the first VNF, wherein the number of VDU instances required by the first VNF is determined according to the third request information, and thus the first request information is generated based on the third request information.

[0116] In a possible implementation, when the first information indicating the load group object identifier associated with the VDU required by the first VNF is carried in the third request information, the first information is also carried in the first request information in order to pass the content indicated in the first information to the infrastructure service manager.

[0117] S303, the infrastructure service manager creates M VDUs for the first VNF, and the M VDUs are associated as group VDUs, where M is a positive integer.

[0118] In this step, the first request information is used to request the infrastructure service manager to create VDU for the first VNF, wherein the number of VDU instances required by the first VNF is determined according to the third request information, and thus the first request information is generated based on the third request information.

[0119] In a possible implementation, when the first information indicating the load group object identifier associated with the VDU required by the first VNF is carried in the third request information, the first information is also carried in the first request information in order to pass the content indicated in the first information to the infrastructure service manager.

[0120] S304, the infrastructure service manager deploys the group VDUs using a group scheduling method, wherein the group scheduling method is to allocate resources for each VDU in the group VDUs in one calculation period, until each VDU in the group VDUs obtains corresponding resources or the group VDUs fail to be allocated resources as a whole, and the calculation period is used to calculate corresponding resources for each VDU in the group VDUs.

[0121] When the M VDUs are associated as group VDUs, the infrastructure service manager can calculate corresponding deployment positions for all group members using the group scheduling method. If any group member does not have a corresponding mapped position in the schedulable resources through calculation, the group member VDU that has obtained a corresponding mapped position is traced back, and the schedulable resources are adjusted until the M VDUs all obtain corresponding mapped positions or the calculation time exceeds one calculation period. When the calculation time exceeds one calculation period, the group VDUs fail to be scheduled as a whole. After the M VDUs all obtain corresponding scheduling positions, the infrastructure service manager binds each VDU to a corresponding resource node, and at this time, the first VNF is considered to be successfully deployed.

[0122] In the embodiment, the VNF is deployed by the group scheduling method, the allocation mode not conducive to overall deployment is recalculated and adjusted, and the success rate of VNF deployment is improved. Meanwhile, the concept of load group is introduced, the unnecessary operation in the deployment process is reduced by the method of calculation first and binding later, and the efficiency of VNF deployment is improved.

[0123] In the process of VNF instantiation, the group scheduling verification function is realized by the VNFM in the above embodiment. In some implementation modes, the load group object can also be manually managed by the VNFM before instantiation. The method of manually managing the load group object is described below in combination with the embodiment Figure 5 . Figure 5 As shown in the figure, the VNF deployment method provided by the embodiment of the application can also realize deployment planning of the load group object before instantiation, specifically including:

[0124] S501, the VNFM receives fourth request information, and the fourth request information is used for querying a load group object list.

[0125] Before the VNF instantiation, the VNFM can first query the existing load group object in the load group object list, so as to facilitate early planning according to the deployment demand of the to-be-deployed VNF.

[0126] S502, the VNFM sends second request information to an infrastructure service manager to obtain a load group object list.

[0127] As an instantiation of a self-defined resource, the load group object is essentially a resource, which can be managed by the infrastructure service manager. The second request information is used to obtain the load group object list from the infrastructure service manager.

[0128] S503, the VNFM outputs the load group object list.

[0129] The VNFM feeds back the obtained load group object list to the inquirer. The inquirer judges whether to create a new load group object or update the attribute information of the existing load group object in the load group object list based on the deployment demand of the to-be-deployed VNF.

[0130] For the embodiment, the attribute information of the first load group object is needed for deploying the first VNF, and whether the load group object with the first load group object identifier is included in the load group object list is queried.

[0131] If the load group object with the first load group object identifier is not included in the load group object list, it is judged that the first load group object needs to be created.

[0132] If the load group object list contains a load group object identified by the first load group object identifier, the load group object is recorded as an initial first load group object, and if the attribute information of the initial first load group object is inconsistent with the attribute information of the first load group object required by the first VNF deployment, it is determined that the attribute information of the initial first load group object in the load group object list needs to be updated.

[0133] S504, the VNFM receives fifth request information, and the fifth request information is used to request to create or update a load group object identified by the first load group object identifier.

[0134] In this step, the inquirer sends the fifth request information to the VNFM according to the judgment result in S503. When the judgment result is that the first load group object needs to be created, the fifth request information is used to request to create a load group object identified by the first load group object identifier. When the judgment result is that the attribute information of the load group object in the load group object list needs to be updated, the fifth request information is used to request to update the load group object identified by the first load group object identifier.

[0135] According to the judgment result, the fifth request information carries the second information or the third information, and the second information or the third information contains the attribute information that the load group object identified by the first load group object identifier should contain or update.

[0136] S505, the VNFM sends the fifth request information to the infrastructure service manager.

[0137] The infrastructure service manager provides the VNFM with an add, delete, modify and query interface of the load group object.

[0138] S506, the infrastructure service manager creates or updates a load group object identified by the first load group object identifier based on the fifth request information.

[0139] If the fifth request information carries the second information, the infrastructure service manager creates the first load group object, and if the fifth request information carries the third information, the infrastructure service manager updates the attribute information of the initial first load group object in the load group object list to be consistent with the attribute information of the first load group object contained in the third information.

[0140] In the above steps, the deployment planning is mainly performed for the deployment demand of the first VNF. For the co-deployment demand of multiple VNFs, the load group object can also be manually managed by the VNFM. For example:

[0141] For example, Figure 6As shown, the VNF-1 to be deployed contains three "Pods" of "Pod" control 1, "Pod" compute 1 and "Pod" compute 2, the VNF-2 to be deployed contains three "Pods" of "Pod" control 2, "Pod" compute 3 and "Pod" compute 4, and the VNF-1 and the VNF-2 need to be co-deployed. According to the requirement of compact deployment of the VNF-1 and the VNF-2, a load group object WG1 is defined, and the attribute information of the WG1 is as follows: load group name identifier: WG1; group member quantity: 6; group scheduling strategy: minimum single board usage number; group scheduling priority: 1; group scheduling timeout time: 30s. Each "Pod" in the VNF-1 and the VNF-2 is associated with the name identifier of the WG1 through a label.

[0142] After querying the load group object list, there is no load group object with the name identifier WG1, and thus it is judged that the WG1 object needs to be created. According to the attribute parameters of the defined WG1 object, the fifth request information and the carried second information are configured, and the infrastructure service manager creates the WG1 object based on the fifth request information.

[0143] In this embodiment, the load group object is manually managed by the VNFM, the addition, deletion, modification and query of the load group object can be realized, and the conflict between the attributes of the load group object required by the VDU associated with the VNF to be deployed and the existing load group object in the load group object list can also be avoided.

[0144] In this application, the infrastructure service manager uses the group scheduling method to allocate resources for M VDUs associated with the first load group object. For the infrastructure service manager, the load group is a brand-new custom resource, and thus it is necessary to first distinguish the VDU associated with the load group object and the ordinary load VDU. In the following, the scheduling method for the VDU associated with the load group object through the load group name identifier is introduced by taking the bare-metal container scenario as an example.

[0145] Figure 7 The component architecture schematic diagram of the K8S extended group scheduling provided by an embodiment of the present application is shown in FIG. 1. Figure 7 As shown, "kubectl" is used as a command line tool to control and manage the K8S cluster. IF1 is used as an extension interface to provide the addition, deletion, modification and query operations of the load group object. The user-defined resource (custom resource definition, CRD) is a built-in resource type of K8S, and through the CRD resource, the load group WG and other custom resources can be converted into the resource type on K8S. K8S mainly contains four components of API server (API Server), controller manager (Controller-Manager), "Etcd" and scheduler (Scheduler).

[0146] Wherein, the API server is a unified access entrance of all resources in the K8S cluster, and exists as a core pivot of data interaction between various components in the cluster; the controller manager is a core component of the K8S for automatically managing various resources, and through automatic management, can monitor the changes of various states in the cluster in real time; the "Etcd" is responsible for storing information of various resource objects and state data in the cluster; and the scheduler is responsible for cluster resource scheduling, and schedules the "Pod" to a suitable node (Node).

[0147] The K8S scheduler extends a group scheduling queue (GroupPriorityQueue) and a group scheduling flow (ScheduleGroup) on the basis of the original priority queue (PriorityQueue), scheduling flow (Scheduleone) and scheduler cache (Cache). Wherein, the group scheduling queue is used for storing members of a load group to be scheduled, and the group scheduling flow provides a group scheduling algorithm to complete group scheduling calculation on the dequeued load group member. It can be understood that the group scheduling queue and the group scheduling flow can realize the differentiation of the VDU of the associated load group object and the ordinary load VDU, and guarantee that the ordinary load VDU and the VDU of the associated load group object have no conflict in the scheduling process.

[0148] The K8S can be regarded as a mini-CaaS manager in nature, and therefore the K8S can be taken as an example of an infrastructure service manager. Figure 8 A flowchart of the K8S for implementing group scheduling is provided for an embodiment of the present application. As shown in the figure, the group scheduling flow can include S801-S807. Figure 8

[0149] S801, the API server receives first request information, and creates "Pods" required by a first VNF.

[0150] In this step, the first request information is used for requesting to deploy "Pods" for the first VNF, and according to the first request information, it is known that M "Pods" are required for deploying the first VNF. The first request information carries first information, and the first information indicates that the load group object identifier associated with the "Pods" required by the first VNF is the first load group object identifier WG1. Through the reset interface (REST API) of the API server, M "Pods" associated with the first load group object identifier WG1 are created.

[0151] S802, the API server stores the data of the "Pods" required by the first VNF into the "Etcd".

[0152] Since the "Etcd" is equivalent to the database of the K8S, the API server stores the data of the M "Pods" created into the "Etcd". ​

[0153] It can be understood that steps S801 and S802 are actually equivalent to Figure 3 In the embodiment shown in step S303, K8S creates M VDU through the API server and “Etcd”.

[0154] It should be noted that if the load group object list does not contain the load group object identified as the first load group object identifier WG1, the first load group object WG1 can also be created through the API server and “Etcd”, and the load group queue corresponding to the first load group object WG1 in the group scheduling queue.

[0155] S803, the monitor (Informer) in the scheduler listens to the state change of “Etcd”, and according to the load group object identifier associated with the “Pod” to be scheduled, adds it to the load group queue corresponding to the group scheduling queue.

[0156] The monitor in the scheduler listens to the newly added unscheduled “Pod” in “Etcd” through the “list-Watch” mechanism, and the load group queue corresponding to the first load group object WG1 exists in the group scheduling queue. The scheduler adds the “Pod” associated with the load group object identifier WG1 to the load group queue WG1. If the “Pod” has no associated load group object, it is added to the priority queue. Since the API server is the hub for data interaction between components in the K8S framework, when the monitor listens to the state change of “Etcd”, it needs to be transferred through the API server.

[0157] It should be noted that as a custom resource, the information of the load group object is stored in “Etcd”. Before group scheduling starts, the scheduler listens to the resource change in “Etcd” through the monitor, and has created the corresponding load group queue for each load group object in the load group object list in the group scheduling queue.

[0158] Meanwhile, in some implementations, the monitor of the scheduler is also responsible for updating the scheduler cache, which caches the information of the “Pod” to be scheduled and the resource node in “Etcd”.

[0159] S804, the group scheduling queue executes the out-of-queue for the load group member “Pod” that meets the out-of-queue rule.

[0160] In order to implement group scheduling calculation for the load group member “Pod”, the load group member “Pod” in the group scheduling queue can only execute out-of-queue if it meets the out-of-queue rule, and then perform subsequent group scheduling operations.

[0161] As an example, the out-of-queue rule is as follows:

[0162] (1) Check the length of each load group queue in the group scheduling queue. When the length of the load group queue is greater than or equal to the upper limit of the number of group members of the load group, refer to rule (2). The length of the load group queue represents the number of "Pods" in the load group queue.

[0163] (2) Check the group scheduling priority of the load group object associated with each load group queue. The load group queue with the smallest group scheduling priority has the highest scheduling priority and is dequeued earliest. If there are load group queues with the same group scheduling priority, refer to rule (3).

[0164] (3) Check the creation time of the load group queue that meets the condition of rule (2). Compare the creation time of the load group queues with the same group scheduling priority. The load group queue created earliest is dequeued earliest.

[0165] S805. The group scheduling process in the scheduler calls the group scheduling algorithm according to the group scheduling strategy of the dequeued load group object to complete group scheduling calculation.

[0166] The group scheduling process provides a group scheduling algorithm. The group scheduling strategy in the attributes of the dequeued load group object WG1 corresponds to the group scheduling algorithm one-to-one. The group scheduling process calls the corresponding group scheduling algorithm according to the group scheduling strategy of the dequeued load group object to calculate the scheduling destination node for the M "Pods" in the dequeued load group queue.

[0167] In this step, the group scheduling calculation ends until each "Pod" in the dequeued load group queue obtains the corresponding node or the time consumed exceeds the group scheduling timeout time indicated in the attribute information of the load group object.

[0168] S806. The scheduler performs scheduling operation on the load group member "Pod".

[0169] In this step, the scheduler modifies the value of the "nodeName" field of the "Pod" object to the name of the "Node" to which the "Pod" object is scheduled, and updates the "Pod" information and "Node" information in the scheduler cache.

[0170] S807. The scheduler initiates an update request to the API server. The update request is used to update the "Pod" data in the "Etcd".

[0171] The scheduler initiates a request to update the "Pod" data in the "Etcd" through the API server. Until this step, the "Pod" is bound to the corresponding node, and the allocation of resources for the "Pod" is realized.

[0172] In this embodiment, according to the dequeuing rule of the load group queue, the whole group of "Pods" is dequeued to call the group scheduling algorithm to calculate the corresponding resource nodes for the whole group of "Pods", and the resource allocation is realized through calculation and binding, thereby improving the success rate of "Pod" deployment and avoiding the complex operation of repeated binding and unbinding.

[0173] It should be noted that after the group scheduling deployment is completed, the VNFM can check whether the whole amount of "Pods" required for the first VNF to be deployed can be successfully started. If the whole amount of "Pods" required for the first VNF is successfully started, it is judged that the first VNF is successfully instantiated, and the first VNF is successfully deployed.

[0174] The group scheduling algorithm proposed in the above embodiment needs to calculate the whole group of "Pods", and compared with the calculation mode taking a single Pod as a granularity, the calculation resources consumed are greatly increased. Therefore, the extended group scheduling method which can relieve the pressure of calculation resource consumption is introduced below.

[0175] Figure 9 The K8S extended co-scheduler provided by an embodiment of the present application supports the framework of group scheduling calculation. As shown in Figure 9 , the K8S extended co-scheduler (Co-Scheduler) is based on Figure 7 . The co-scheduler is a copy of the master scheduler created by human beings, and therefore the co-scheduler also contains a group scheduling queue and a group scheduling process.

[0176] Figure 10 The K8S provided by an embodiment of the present application realizes the group scheduling process through the master co-scheduler. The specific process of realizing the group scheduling by the K8S architecture containing the co-scheduler is described below. Figure 10 . As shown in Figure 9 , the group scheduling process realized by the master co-scheduler can include S1001-S1008. Figure 10

[0177] S1001, the co-scheduler creates a load group queue.

[0178] Before the group scheduling starts, the master scheduler has created a corresponding load group queue in the group scheduling queue for each load group object in the load group object list through the monitor listening to the resource change in the "Etcd".

[0179] In this embodiment, the co-scheduler, as a copy of the master scheduler, also needs to create a corresponding load group queue in the group scheduling queue in the co-scheduler for each load group object in the load group object list. It should be noted that there is no sequence relationship between the creation of the load group queue by the master scheduler and the co-scheduler.

[0180] ​S1002, the API server receives the first request information, and creates a "Pod" required for the first VNF.

[0181] S1003, the API server stores the data of the "Pod" required for the first VNF into "Etcd".

[0182] The processes of steps S1002 and S1003 are consistent with steps S801 and S802 in the embodiment shown in Figure 8

[0183] S1004, the primary scheduler pre-selects nodes for the "Pod" required for the first VNF, and locks the alternative nodes.

[0184] In this step, the primary scheduler first adds the "Pod" required for the first VNF into the associated load group queue according to the pre-selection strategy, and executes the dequeuing of the "Pod" in the load group queue after meeting the dequeuing rule. Subsequently, the primary scheduler filters the nodes that do not meet the strategy from "Etcd" through the API server, and locks the alternative nodes in the scheduler cache according to the pre-selection strategy. Figure 8

[0185] S1005, the primary scheduler updates the "Node" information, the "Pod" information, and the information of the load group object associated with the "Pod" in "Etcd" through the API server.

[0186] The primary scheduler labels the alternative nodes in "Etcd" with the first load group object through the API server, avoids the "Pod" that is not a member of the first load group from calling the alternative nodes, and updates the information of the dequeued "Pod" and the pre-scheduling information of the first load group object in "Etcd", so as to facilitate the group scheduling operation of the subsequent coordination scheduler.

[0187] S1006, the coordination scheduler calls the group scheduling algorithm to allocate resource nodes for the dequeued load group member "Pod" from the alternative nodes.

[0188] The coordination scheduler listens to the resource changes in "Etcd" through the monitor, and according to the pre-scheduling information of the first load group object, the nodes with the first load group object label and the dequeued "Pod" information in the scheduler cache in the coordination scheduler. The above process of the monitor listening to the state changes in "Etcd" is realized through the API server.

[0189] ​​The dequeued load group member "Pod" is associated with the first load group object, and at the low-computing-load node, the coordination scheduler invokes a corresponding group scheduling algorithm according to the group scheduling strategy of the first load group object, and calculates the scheduling destination node for the dequeued "Pod" within the node range with the label of the first load group object until each "Pod" in the dequeued load group queue obtains a corresponding node or the time consumed exceeds the group scheduling timeout time indicated in the attribute information of the first load group object, and the group scheduling calculation ends.

[0190] After the group scheduling calculation ends, the coordination scheduler modifies the value of the "nodeName" field of the "Pod" object and updates the "Pod" information and "Node" information in the scheduler cache in the coordination scheduler.

[0191] S1007, the coordination scheduler updates the "Node" information, the "Pod" information and the information of the load group object associated with the "Pod" in the "Etcd" through the API server.

[0192] In this step, the coordination scheduler updates the "Pod" information in the "Etcd" through the API server, binds the "Pod" to the corresponding node, and clears the load group object identifier of the standby node, and the standby scheduling information of the first load group object is updated as scheduled information.

[0193] S1008, the master scheduler updates the cache information.

[0194] The master scheduler releases the lock of the standby node in the scheduler cache and clears the load group object identifier of the standby node. This step is not necessary for the "Pod" required for deploying the first VNF, and the main role is to avoid the deployment failure of the member "Pod" of other load group objects due to the failure to invoke the standby node. Since the master scheduler updates the cache information according to the "Pod" information in the "Etcd", this step needs to be realized through the API server.

[0195] In this embodiment, the dynamic start and stop of the coordination scheduler by the low-computing-load node completes the group scheduling calculation of the load group object with a large number of group members, more efficiently utilizes the computing resources, and relieves the computing overhead pressure.

[0196] In some implementations, the computing overhead pressure of the scheduler can also be shared by extending the scheduling solver (ScheduleSolver). Figure 11 The K8S extended scheduling solver provided by an embodiment of the present application supports the framework diagram of group scheduling calculation, and the scheduling solver is a third-party scheduler independent of the cloud OS.

[0197] Figure 12The K8S provided by an embodiment of the present application implements the group scheduling process through the master scheduler and the scheduling solver. The following describes the group scheduling process in combination with Figure 12 , the K8S architecture containing the scheduling solver implements the group scheduling process. As shown in Figure 11 , the group scheduling process implemented through the master scheduler and the scheduling solver can include S1201-S1208. Figure 12

[0198] S1201, the master scheduler pulls up the scheduling solver and registers the use.

[0199] The plurality of scheduling solver instances are distributed and deployed in the low-computing-load nodes. Since the scheduling solver is an independent third-party scheduler, the master scheduler needs to predict the computing resources consumed by the group scheduling according to the group member quantity information of the load group object, and pull up one or more scheduling solvers on demand.

[0200] S1202, the API server receives the first request information and creates the “Pod” required by the first VNF.

[0201] S1203, the API server stores the data of the “Pod” required by the first VNF into the “Etcd”.

[0202] S1204, the master scheduler pre-selects the nodes for the “Pod” required by the first VNF and locks the alternative nodes.

[0203] The above steps S1202-S1204 are consistent with the steps S1002-S1004 in the embodiment shown in Figure 10 .

[0204] S1205, the master scheduler selects the scheduling solver instance and pushes the alternative nodes, the dequeued load group member “Pod” information, and the load group information to the scheduling solver instance.

[0205] In this step, the master scheduler can select one or more scheduling solver instances according to the load balancing strategy, and push the alternative nodes, the dequeued load group member “Pod” information, and the attribute information of the first load group object associated with the “Pod” to the selected scheduling solver instance. It should be noted that if multiple scheduling solver instances are selected, the information to be pushed is sent into the multiple scheduling solver instances in batches, and the multiple scheduling solver instances operate in parallel.

[0206] S1206, the scheduling solver calls the group scheduling algorithm to allocate the resource nodes for the dequeued load group member “Pod” from the alternative nodes.

[0207] ​The dequeued Pod associates with the first load group object, and the scheduling solver invokes a corresponding group scheduling algorithm according to the group scheduling policy of the first load group object, and calculates the node to which the dequeued Pod is scheduled within the node range with the label of the first load group object, until each Pod in the dequeued load group queue obtains a corresponding node or the time consumed exceeds the group scheduling timeout time indicated in the attribute information of the first load group object, and the group scheduling calculation ends.

[0208] In S1207, the master scheduler receives the group scheduling calculation result sent by the scheduling solver, and updates the cache information of the master scheduler.

[0209] In this step, the master scheduler modifies the value of the "nodeName" field of the "Pod" object according to the group scheduling calculation result, and updates the "Pod" information and "Node" information in the scheduler cache of the master scheduler.

[0210] In S1208, the master scheduler updates the "Node" information, "Pod" information and the information of the load group object associated with the "Pod" in the "Etcd" through the API server.

[0211] This step is basically the same as S1007 in the embodiment Figure 10 The difference between this step S1208 and S1007 in the embodiment

[0212] This step is consistent with S1008 in the embodiment Figure 10 This step is also a non-mandatory step for the "Pod" required for deploying the first VNF, and the main role is to avoid the deployment failure of the member "Pod" of other load group objects due to the inability to invoke the alternative node.

[0213] In this embodiment, the group scheduling calculation is implemented by the scheduling solver deployed on the low-computing-load node, which can more efficiently utilize the computing resources and relieve the computing overhead pressure.

[0214] In the above embodiments, the first request information is used to request instantiation of the first VNF, and in some implementations, the first request information can also be used to request scaling of VDU for the first VNF. It should be noted that when the first request information is used to request scaling of VDU for the first VNF, the first information carried by the first request information indicates that the load group object identifier associated with the scaling of VDU for the first VNF is the first load group object identifier. Scaling of VDU for the first VNF means that the number of group members of the first load group has reached the upper limit, and therefore the first request information further carries second information indicating new attribute information of the first load group object. The new attribute information of the first load group object modifies the upper limit of the number of group members of the original first load group to the upper limit of the number of group members after scaling.

[0215] It can be understood that only when the first VNF scaling VDU is fully started, the first VNF is equivalent to successful scaling, and therefore the first VNF scaling VDU needs to be deployed to the corresponding resource node subsequently. The deployment method of the scaling VDU is consistent with the deployment method of the VDU required by the first VNF in the above embodiments, which will not be described here.

[0216] In the above embodiments, the request information received by the VNFM is input by the administrator on the VNFM, and in some implementations, the NFVO can receive the request information input by the administrator, and the request information is transmitted to the VNFM through the NFVO. Correspondingly, the deployment software package of the VNF to be deployed and the VNFD are uploaded through the deployment interface of the NFVO, and the group scheduling verification function can also be implemented through the NFVO. For example: Figure 3 and Figure 4 In step S301 in the above embodiments, the first request information is used to trigger deployment of a virtual deployment unit VDU for a first virtual network function VNF; the NFVO transmits a second request information to the infrastructure service manager through the VNFM, and the second request information is used to request deployment of VDU for the first VNF.

[0217] In some implementations, the NFVO can directly interact with the infrastructure service manager, and in this case, the VNFM in the above embodiments can be replaced by the NFVO, and the related methods performed by the VNFM in the embodiment method are performed by the NFVO.

[0218] Figure 13 A structural schematic diagram of a virtual network function deployment apparatus provided by an embodiment of the present application is shown in the following figure. Figure 13 The deployment method implemented through the VNFM in the embodiment Figures 3-5 will be described below. As shown in Figure 13 , the apparatus 1300 of the present embodiment can include a receiving module 1301 and a sending module 1302.

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

[0220] The sending module 1302 is used to send a first request message to the infrastructure service manager, the first request message being used to request the deployment of a VDU for the first VNF.

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

[0222] In some implementations, the sending module 1302 is also used to send a second request message to the infrastructure service manager, the second request message being used to request a list of load group objects.

[0223] In some implementations, the receiving module 1301 is also used to receive a fourth request message, which is used to query the list of load group objects.

[0224] In some implementations, the receiving module 1301 is further configured to receive a fifth request message. The fifth request message is used to request the creation or update of a load group object identified as a first load group object. The fifth request message carries second or third information. The second information includes attribute information that the load group object identified as a first load group object should contain, and the third information includes attribute information that the load group object identified as a first load group object should update.

[0225] Figure 14 A schematic diagram of a deployment apparatus for a virtual network function provided in another embodiment of this application. The following is in conjunction with... Figure 14 For the embodiments Figures 3-5 The deployment method implemented through infrastructure servers will be explained. For example... Figure 14 As shown, the device 1400 in this embodiment may include: a receiving module 1401, a processing module 1402, and a verification module 1403.

[0226] The receiving module 1401 is used to receive first request information from VNFM, and the first request information is used to request the deployment of VDU for the first VNF.

[0227] The processing module 1402 is configured to create M VDUs for the first VNF, and deploy the M VDUs using a group scheduling method. When the group scheduling method is used, the VDUs to be deployed are multiple, and the resource allocation for the first VDU among the multiple VDUs fails, the resource allocation for a second VDU among the multiple VDUs is re-performed, and the second VDU includes a VDU among the multiple VDUs that has been successfully allocated with resources before the first VDU.

[0228] In some implementations, the checking module 1403 is configured to create, based on the second information, a load group object identified by the first load group object identifier, or update, based on the third information, the load group object identified by the first load group object identifier.

[0229] In some implementations, the receiving module 1401 is configured to receive, from the VNFM, second request information used to request to query a list of load group objects.

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

[0231] It should be understood that the apparatus 1300 and the apparatus 1400 are embodied in the form of functional modules. The term “module” can refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (for example, a shared processor, a dedicated processor, or a group processor, etc.) and a memory for executing one or more software or firmware programs, a combinational logic circuit, and / or other suitable components that support the described functions.

[0232] The apparatus 1300 and the apparatus 1400 described above have the functions of implementing the respective processes and / or steps in the above method embodiments; the above functions can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0233] Figure 15 A structural schematic diagram of a virtual network function deployment apparatus provided by yet another embodiment of the present application is shown. Figure 15 The apparatus 1500 shown can be used to perform the method performed by the virtual network function deployment apparatus in any of the preceding methods, and the following describes the apparatus 1500 in combination with the method. Figure 15 Detailed description of the embodiments Figures 13-14 The virtual network function deployment apparatus in the embodiments is described in detail.

[0234] AsFigure 15 As shown, the apparatus 1500 of the 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 are communicatively connected to each other through the bus 1504.

[0235] The memory 1501 can be a read only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1501 can store a program, and when the program stored in the memory 1501 is executed by the processor 1502, the processor 1502 is configured to execute any of the foregoing methods.

[0236] 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 for executing related programs.

[0237] The processor 1502 can also be an integrated circuit chip having a processing capability of signals. In the implementation process, each related step in the embodiments of the present application can be completed by the integrated logic circuit of hardware in the processor 1502 or the instruction in the form of software.

[0238] The processor 1502 described above can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. Each method, step and logic block diagram disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0239] The steps of the method disclosed in the embodiments of the present application can be directly embodied as hardware code processing executed by a code processor, or executed by a combination of hardware and software modules in the code processor. The software module can be located in a random access memory, a flash memory, a read only memory, a programmable read only memory, an electrically erasable programmable memory, a register, or other mature storage media in the art. The storage medium is located in the memory 1501, and the processor 1502 reads the information in the memory 1501, and combines the hardware to complete the functions required to be executed by the units included in the apparatus of the present application.

[0240] The communication interface 1503 can use, but is not limited to, a transceiver such as a transceiver to realize the communication between the device 1500 and other devices or devices.

[0241] The bus 1504 can include a path for transmitting information between various components (for example, the memory 1501, the processor 1502, the communication interface 1503) of the device 1500.

[0242] The embodiments of the present application further provide a computer readable storage medium, and the computer readable storage medium stores computer instructions. When the processor executes the computer instructions, each step in the method in the above embodiments is realized.

[0243] The embodiments of the present application further provide a computer program product, and the computer program product includes computer instructions. When the processor executes the computer instructions, each step in the method in the above embodiments is realized.

[0244] It should be noted that the modules or components shown in the above embodiments can be one or more integrated circuits configured to implement the above method, for example: one or more application specific integrated circuits, or one or more microprocessors, or one or more field programmable gate arrays, etc. For another example, when a certain module above is implemented in the form of a processing element calling program code, the processing element can be a general purpose processor, such as a central processing unit or other processor capable of calling program code, such as a controller. For another example, these modules can be integrated together in the form of a system on a chip (SOC).

[0245] In the embodiments described above, all or some of the steps can be implemented by software, hardware, firmware or any combination thereof. When implemented in software, all or some of the steps can be stored in or performed in relation to one or more computer program products and can be implemented as one or more computer programs. The computer program product can be a computer program storage medium readable by a computer and encoding a computer program of instructions for executing modules. The computer program product can be a computer readable storage medium. The computer readable storage medium can be a volatile (transitory) or non-volatile memory or mass storage mechanism. The computer readable storage medium can include program instructions to implement an application programming interface (API) or one or more interfaces described in the specification. The program instructions can cause a processor to execute the steps described herein. The computer readable storage medium can be tangible or in transitory. The computer readable storage medium can be a computer readable signal medium. The computer readable signal medium can be a computer readable instruction signal, or a computer readable data signal, or a transitory computer readable medium. The computer readable storage medium can be any medium that can be accessed by a computer. Examples of a computer readable storage medium can include an electronic, magnetic, optical, electromagnetic, infrared, semiconductor system, semiconductor memory device, or any other medium that can be used to store and access programming code and that can be read by a computer. Examples of a computer readable storage medium can include a floppy disk, a flexible disk, hard disk, solid state drive, USB flash drive, RAM, ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, or a file server. The computer program product can be a computer program propagated from one computer to another, through a computer readable storage medium or any other form of a computer readable signal medium. The computer program product can be a computer program to control tangible parts of the application. The computer program product can encode a computer program of instructions for executing modules.

[0246] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the present application cover any and all variations of the application that come within the scope of the claims and their equivalents. It is intended that the specification and examples be considered exemplary only, with the true scope and spirit of the application indicated by the following claims.

[0247] It is to be understood that the application is not limited to the precise construction described in the specification and shown in the drawings, and that various modifications and changes can be effected therein by those skilled in the art without departing from the scope of the application. The scope of the application is to be limited only by the appended claims.

Claims

1. A method for deploying virtual network functions, applied to an infrastructure service manager, characterized in that, The method comprises: receiving first request information sent by a virtual network function manager (VNFM), the first request information being used to request to deploy 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 a same group of VDUs, M being a positive integer; deploying the same group of VDUs using a group scheduling method, wherein the group scheduling method is to allocate resources for each VDU in the same group of VDUs in one calculation period until each VDU in the same group of VDUs obtains corresponding resources or the whole group of VDUs fails to be allocated resources.

2. The method of claim 1, wherein, The first request information carries first information, the first information indicating that a load group object identifier associated with the VDU required by the first VNF is a first load group object identifier, the load group object identifier being used to indicate a load group object, the load group object comprising attribute information of a maximum number of VDUs that can be associated with the load group object identifier, a scheduling strategy when deploying VDUs associated with the load group object identifier using the group scheduling method, a scheduling priority when deploying VDUs associated with the load group object identifier using the group scheduling method, and a scheduling timeout time when deploying VDUs associated with the load group object identifier using the group scheduling method. The method further comprises: creating the M VDUs, and each VDU in the M VDUs being associated with the first load group object identifier; deploying the M VDUs using the group scheduling method, comprising: deploying VDUs associated with the first load group object identifier according to attribute information of a load group object indicated by the first load group object identifier using the group scheduling method.

3. The method of claim 2, wherein, The method further comprises: obtaining an undeployed VDU; when the undeployed VDU is associated with the first load group object identifier, adding the undeployed VDU to a scheduling queue associated with the first load group object identifier; deploying VDUs in the scheduling queue according to attribute information of a load group object indicated by the first load group object identifier using the group scheduling method.

4. The method of claim 3, wherein, The method further comprises: when the number of VDUs in the scheduling queue is equal to the maximum number of VDUs in the load group object indicated by the first load group object identifier, deploying VDUs in the scheduling queue according to the scheduling strategy and the scheduling priority in the load group object indicated by the first load group identifier using the group scheduling method, until each VDU in the scheduling queue is successfully deployed or the deployment time exceeds the scheduling timeout time in the load group object indicated by the first load group identifier.

5. The method according to any one of claims 2 to 4, characterized in that, The method further comprises: receiving second information from the VNFM, the second information being used to indicate creation of a load group object identified by the first load group object identifier.

6. The method of claim 5, wherein, The method further includes: sending a load group object list to the VNFM; wherein the receiving the second information from the VNFM includes: receiving the second information from the VNFM when the load group object list does not contain a load group object identified by the first load group object identifier.

7. The method according to any one of claims 2 to 6, characterized in that, The method further includes: receiving third information from the VNFM, the third information being used to indicate update of attribute information in a load group object identified by the first load group object identifier.

8. The method of claim 7, wherein, The method further includes: sending a load group object list to the VNFM; wherein the receiving the third information from the VNFM includes: receiving the third information from the VNFM when the load group object list contains a load group object identified by the first load group object identifier.

9. The method according to claim 6 or 8, characterized in that, Before the sending the load group object list to the VNFM, the method further includes: receiving second request information from the VNFM, the second request information being used to request query of a load group object list.

10. The method of claim 3, wherein, The using the group scheduling method to deploy the VDU in the scheduling queue according to attribute information of a load group object indicated by the first load group object identifier includes: associating a group scheduling tag with a first node by a first scheduler, the first node containing a candidate deployment node of the VDU in the scheduling queue, the first scheduler being used to allocate resources for the VDU; deploying the VDU in the scheduling queue according to attribute information of a load group object indicated by the first load group object identifier by a second scheduler using the group scheduling method, the second scheduler being a copy of the first scheduler.

11. The method of claim 10, wherein, The using the group scheduling method to deploy the VDU in the scheduling queue according to attribute information of a load group object indicated by the first load group object identifier includes: associating a group scheduling tag with a first node by a first scheduler, the first node containing a candidate deployment node of the VDU in the scheduling queue, the first scheduler being used to allocate resources for the VDU; deploying the VDU in the scheduling queue according to attribute information of a load group object indicated by the first load group object identifier by at least one scheduling solver using the group scheduling method, the scheduling solver being an independent third-party scheduler.

12. A method for deploying a virtual network function, applied to a virtual network function manager (VNFM), the method comprising: The method includes: receiving third request information, the third request information being used to trigger deployment of a virtual deployment unit VDU for a first virtual network function VNF; sending first request information to the infrastructure service manager, the first request information being used to request to deploy VDU for the first VNF, the VDU required by the first VNF being a same-group VDU deployed in a group scheduling method, the same-group VDU being associated with M VDUs, M being a positive integer, the group scheduling method being to allocate resources for each VDU in the same-group VDU in one calculation period until each VDU in the same-group VDU gets corresponding resources or the same-group VDU fails to allocate resources as a whole, the calculation period being used to calculate corresponding resources for each VDU in the same-group VDU.

13. The method of claim 12, wherein, The third request information and the first request information carry first information, the first information indicating that a load group object identifier associated with the VDU required by the first VNF is a first load group object identifier, the load group object identifier being used to indicate a load group object, the load group object including the following attribute information: a maximum number of VDUs capable of being associated with the load group object identifier, a scheduling strategy when deploying VDUs associated with the load group object identifier in the group scheduling method, a scheduling priority when deploying VDUs associated with the load group object identifier in the group scheduling method, and a scheduling timeout time when deploying VDUs associated with the load group object identifier in the group scheduling method.

14. The method of claim 13, wherein, The method further includes: sending second information to the infrastructure service manager, the second information being used to indicate to create a load group object identified as the first load group object identifier.

15. The method of claim 14, wherein, The method further includes: receiving a load group object list from the infrastructure service manager; wherein the sending of the second information to the infrastructure service manager includes: when the load group object list does not contain the load group object identified as the first load group object identifier, sending the second information to the infrastructure service manager.

16. The method according to any one of claims 13 to 15, characterized in that, The method further includes: sending third information to the infrastructure service manager, the third information being used to indicate to update attribute information in the load group object identified as the first load group object identifier.

17. The method of claim 16, wherein, The method further includes: receiving a load group object list from the infrastructure service manager; wherein the sending of the third information to the infrastructure service manager includes: when the load group object list contains the load group object identified as the first load group object identifier, sending the third information to the infrastructure service manager.

18. The method of claim 15 or 17, wherein, Before the receiving of the load group object list from the infrastructure service manager, the method further includes: sending second request information to the infrastructure service manager, the second request information being used to request to query a load group object list.

19. The method according to any one of claims 12 to 18, characterized in that, The third request information is specifically used to request to instantiate the first VNF, or the third request information is specifically used to request to expand VDU for the first VNF.

20. The method according to any of claims 12 to 19, characterized in that, The third request information is input 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 apparatus, characterized by, The apparatus comprises functional modules for implementing the deployment method of the virtual network function as claimed in any one of claims 1 to 11, or comprises functional modules for implementing the deployment method of the virtual network function as claimed in any one of claims 12 to 19. 22.A system for deployment of virtual network functions, the system comprising: The apparatus comprises a first deployment apparatus for implementing the deployment method of the virtual network function as claimed in any one of claims 1 to 11, and a second deployment apparatus for implementing the deployment method of the virtual network function as claimed in any one of claims 12 to 19.

23. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, which, when executed by a processor, are used to implement the deployment method of the virtual network function as claimed in any one of claims 1 to 11, or any one of claims 12 to 19.

24. A computer program product, characterised in that, The computer program, when executed by a processor, implements the deployment method of the virtual network function as claimed in any one of claims 1 to 11, or any one of claims 12 to 19.

Images