Virtualised network function instantiation method and apparatus
By pre-configuring the runtime cluster in Serverless mode, the problem of excessively long VNF instantiation time is solved, enabling fast VNF cold start and improving system flexibility and fault tolerance.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- HUAWEI TECH CO LTD
- Filing Date
- 2025-11-10
- Publication Date
- 2026-05-21
Smart Images

Figure CN2025133775_21052026_PF_FP_ABST
Abstract
Description
Method and apparatus for instantiating virtualized network functions
[0001] This application claims priority to Chinese Patent Application No. 202411629876.2, filed on November 14, 2024, entitled "Method and Apparatus for Instantiating Functions", and Chinese Patent Application No. 202510551395.2, filed on April 28, 2025, entitled "Method and Apparatus for Instantiating VNFs", the entire contents of which are incorporated herein by reference. Technical Field
[0002] This application relates to the field of computer technology, and in particular to a method and apparatus for instantiating a Virtualized Network Function (VNF). Background Technology
[0003] Serverless refers to a cloud computing execution model. Serverless does not mean that servers are not needed, but rather that from the user's perspective, users only need to focus on the functionality of the application itself. When deploying the application, users only need to know that the application is deployed to the cloud, without needing to know which specific server the application is deployed on or what virtualization technology is used.
[0004] Serverless architecture typically employs a front-end FaaS and a back-end BaaS, generally using event-driven programming and microservices. Event-driven programming means associating Serverless Virtual Networks (VNFs) with triggers. When an event occurs, the trigger captures the event and then instantiates the VNF, which handles the captured event. The actual operation of triggers depends on the event, such as HTTP message triggers, database content change triggers, or timer triggers.
[0005] Serverless can quickly scale up and down based on actual business needs. Compared to the scaling of traditional cloud services, Serverless supports reducing application instances to zero. Many enterprises use Serverless to provide long-tail services for numerous low-frequency applications, only consuming resources when business activity occurs. When business peaks arrive, Serverless can scale up application instances in the hundreds of milliseconds, effectively supporting peak business conditions.
[0006] Since application instances are triggered by business operations, there are high requirements for instance startup time. WebAssembly (WASM) is a binary instruction set based on a stack-based virtual machine, which has high portability. Applications using WASM technology are generally small and have fast startup speed, making it a suitable technology for use in serverless mode.
[0007] However, for some VNF applications in Serverless mode, there is a problem that VNF instantiation takes a long time. For example, when Serverless VNF+WASM is applied to a Network Functions Virtualization (NFV) system, the conditions that VNF instantiation depends on need to be created after the event is triggered (such as virtual machine allocation / container creation, and installation of WASM runtime + dependent components, etc.). In this way, VNF instantiation takes a long time. Summary of the Invention
[0008] This application provides a VNF instantiation method and apparatus. By pre-configuring a target runtime cluster that meets the necessary conditions for the operation of the target VNF, and instantiating the target VNF based on the target runtime cluster when the corresponding event of the target VNF is triggered, the overall instantiation time of the target VNF is reduced and the efficiency of cold start of the target VNF is improved.
[0009] In a first aspect, this application provides a VNF instantiation method applied to a VNF manager (VNFM). The method includes: firstly receiving an instance trigger message from a target VNF; then determining the target runtime cluster corresponding to the target VNF based on the instance trigger message; and finally instantiating the target VNF based on the target runtime cluster, wherein the target runtime cluster satisfies a first condition, the first condition including necessary conditions on which the target VNF depends for operation.
[0010] Based on the above embodiments, by determining the target runtime cluster that meets the necessary conditions for the operation of the target VNF when the event corresponding to the target VNF is triggered, the target VNF can be directly instantiated based on the target runtime cluster. There is no need to create the conditions that the VNF instantiation depends on (such as virtual machine allocation / container creation, and installation of WASM runtime + dependent components, etc.), which reduces the overall time of target VNF instantiation and improves the efficiency of target VNF cold start.
[0011] In this application, the runtime cluster can also be a runtime resource pool, and the target VNF is equivalent to the target serverless VNF.
[0012] The instance trigger message can directly carry the identifier corresponding to the target runtime cluster, thereby determining the target runtime cluster corresponding to the target VNF based on the identifier. This facilitates rapid location of the target runtime cluster.
[0013] In addition, the VNF manager instantiates the target VNF based on the target runtime cluster. This can be done by first sending a first instruction message to the Infrastructure Management (IM) to instruct the allocation of a target node from the target runtime cluster. The first instruction message carries the identifier of the target runtime cluster. After the target node is determined, the target VNF is instantiated based on the target node.
[0014] Based on the above implementation method, since the first instruction information carries the identifier of the target runtime cluster, the resource manager can quickly locate the target runtime cluster, and then allocate the corresponding target node from the target runtime cluster through the resource manager, so that the VNF manager can perform instantiation operation on the allocated node, which helps to improve the efficiency of the instantiation operation.
[0015] In addition, the VNF manager instantiates the target VNF based on the target runtime cluster. It can also first send a first authorization request to the orchestrator, which is used to request authorization for the VNF manager to use the nodes in the target runtime cluster; then receive a first authorization response from the orchestrator, which is used to authorize the VNF manager to use the target node in the target runtime cluster; and finally instantiate the target VNF based on the target node.
[0016] Based on the above implementation method, by indirectly instructing the resource manager to allocate target nodes through the orchestrator, the allocation of target nodes can be achieved even when communication between the VNF manager and the resource manager is not possible, thereby improving the fault tolerance of the system.
[0017] In a feasible embodiment, determining the target node based on the aforementioned direct or indirect methods can be done when the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances. When the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances, a second instruction can be sent to the resource manager, instructing the request for a new target node. By pre-determining the existence of available nodes in the target runtime cluster based on the relationship between the number of instances running in the current target runtime cluster and the maximum number of fast-start instances, and only allocating the target node when it is determined that an available node exists, the system's flexibility is improved.
[0018] Furthermore, the determination of whether the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances of the target VNF can also be performed at the trigger node. When the trigger determines that the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances of the target VNF, it carries the identifier corresponding to the target runtime cluster in the instance trigger message sent to the VNF manager. When the VNF determines that the instance trigger message carries the identifier corresponding to the target runtime cluster, it executes the aforementioned target node allocation steps.
[0019] When the trigger determines that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances in the target VNF, the instance trigger message sent to the VNF manager does not carry the identifier corresponding to the target runtime cluster. When the VNF determines that the instance trigger message does not carry the identifier corresponding to the target runtime cluster, it sends a second instruction message to the resource manager. This second instruction message is used to instruct the request for a new target node. This also improves the system's flexibility.
[0020] In one feasible implementation, before receiving the instance trigger message of the target VNF from the trigger, a first request instruction from the orchestrator can be received first, which is used to request the creation of the identifier of the target VNF; then, first information from the orchestrator is received, which is used to determine a first condition; based on the first condition, the target runtime cluster is determined from the existing runtime cluster; a correspondence between the target runtime cluster and the target VNF is established; finally, a first reply instruction is sent to the orchestrator, which is used to notify that the creation of the identifier of the target VNF is complete.
[0021] Based on the aforementioned implementation method, by establishing a correspondence between the target VNF and the target runtime cluster in advance on the VNF manager node, when the VNF manager receives an instance trigger message of the target VNF, it can quickly locate the target runtime cluster based on the correspondence, thereby improving the system's operating efficiency.
[0022] In one feasible implementation, the first condition further includes a maximum number of fast-start instances N, wherein the target runtime cluster comprises at least M worker nodes, and the M worker nodes are capable of running N target VNF instances. Instantiation of the target VNF by the target runtime cluster is performed through the corresponding worker nodes, each worker node being configured with all the environment components, infrastructure resources, etc., required for the target VNF to run.
[0023] Based on the above implementation method, pre-configuring the maximum number of fast-start instances corresponding to the target VNF can meet more personalized requirements of users or operators.
[0024] Among them, the target runtime cluster can also be created dynamically, and the dynamic creation of the target runtime cluster can be divided into direct mode and indirect mode.
[0025] In one feasible implementation, for the direct mode, if it is determined that there is no runtime cluster in the existing runtime cluster that meets the first condition, a third instruction message can be sent to the resource manager to instruct the resource manager to create the target runtime cluster according to the first information.
[0026] Based on the above example method, a target runtime cluster that better suits the operational requirements of the target VNF can be dynamically created. This avoids the problem that if an existing runtime cluster does not meet the first condition, subsequent rapid startup of the target VNF instantiation based on the runtime cluster cannot be achieved. This improves the system's flexibility.
[0027] In one feasible implementation, for the indirect mode, if there is no runtime cluster in the existing runtime cluster that meets the first condition, the VNF manager sends a second authorization request to the orchestrator, thereby requesting the orchestrator to instruct the resource manager to create the target runtime cluster according to the first information and authorize the VNF manager to use the target runtime cluster; after the target runtime cluster is created, the VNF manager receives a second authorization response from the orchestrator, which is used to authorize the VNF manager to use the target runtime cluster, and the authorization response may carry the identifier of the target runtime cluster.
[0028] Optionally, after receiving the second authorization request, the orchestrator can choose to reserve only the infrastructure resources (without installing runtime), thereby authorizing the VNF manager to use the reserved infrastructure resources based on the second authorization response, and can carry the identifier of the reserved infrastructure resources.
[0029] Based on the above implementation method, when the VNF manager cannot directly and dynamically create the target runtime cluster, the orchestrator can be used to dynamically create the target runtime cluster, thereby improving the stability of the system.
[0030] In one feasible implementation, the first information further includes third information, which is used to determine the cluster usage mode, including either shared or exclusive usage.
[0031] In one feasible implementation, the first information may further include second information, which is used to determine the code corresponding to the target VNF. If the cluster is used exclusively at this time, after the VNF manager establishes the correspondence between the target runtime cluster and the target VNF, it will also send a fourth instruction to the resource manager, thereby instructing the resource manager to download the code corresponding to the target VNF to the worker nodes included in the target runtime cluster based on the second information, so that the worker nodes can run the target VNF.
[0032] Based on the above implementation method, when the cluster is used exclusively, the code corresponding to the target VNF can be downloaded to the worker nodes included in the target runtime cluster in advance, so that the code does not need to be downloaded when the target VNF is instantiated, thereby reducing the instantiation time of the target VNF.
[0033] In one feasible implementation, the VNF manager can also receive the mapping between the target runtime cluster and the target VNF from the orchestrator.
[0034] Based on the above implementation method, the step of establishing the correspondence between the target runtime cluster and the target VNF can also be performed by the orchestrator, thereby improving the flexibility of the system.
[0035] In one feasible implementation, the VNF manager detects whether the execution task corresponding to the target VNF instance has been completed, and deletes the target VNF instance after determining that the execution task corresponding to the target VNF instance has been completed.
[0036] Based on the above implementation method, the VNF manager can avoid more resource waste and improve resource utilization by detecting the processing status of the execution tasks corresponding to the target VNF instance and deleting the target VNF instance in a timely manner when the execution tasks corresponding to the target VNF instance are completed.
[0037] In one feasible implementation, if the VNF manager receives a fifth instruction from the orchestrator, indicating that the target VNF should be deinstantiated, then the target VNF is deinstantiated based on the fifth instruction. Subsequently, the mapping between the target VNF and the target runtime cluster is released, and if no corresponding VNF exists in the target runtime cluster, the target runtime cluster is deleted. A second response is then sent to the orchestrator. It is understood that deleting the target runtime cluster can be performed if the target runtime cluster is dynamically created; if the target runtime cluster is a runtime cluster pre-created by the operator, then deletion is unnecessary.
[0038] Based on the above implementation method, after deinstantiating the target VNF, the correspondence between the target VNF and the target runtime cluster will be removed, and the target runtime cluster will be deleted if there is no corresponding VNF in the target runtime cluster. This can release idle resources and avoid excessive resource waste.
[0039] Secondly, this application provides a VNF instantiation method, which includes: applying to a trigger, the method including: when an instance triggering event of a target VNF is captured, sending an instance triggering message of the target VNF to a VNF manager, so that the VNF manager determines the target runtime cluster corresponding to the target VNF based on the instance triggering message, and instantiating the target VNF based on the target runtime cluster, wherein the target runtime cluster satisfies a first condition, the first condition including necessary conditions on which the target VNF depends for operation.
[0040] Based on the same reasons as the aforementioned embodiments, by sending an instance trigger message for the target VNF to the VNF manager when the event corresponding to the target VNF is triggered, the VNF manager can determine the target runtime cluster that meets the necessary conditions for the operation of the target VNF. Thus, the target VNF can be directly instantiated based on the target runtime cluster without having to create the conditions that the VNF instantiation depends on (such as virtual machine allocation / container creation, and installation of WASM runtime + dependent components, etc.). This reduces the overall instantiation time of the target VNF and improves the efficiency of cold start of the target VNF.
[0041] In one feasible implementation, if it is determined that the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances, then the instance trigger message carries the identifier of the target runtime cluster; if it is determined that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances, then the instance trigger message does not carry the identifier of the target runtime cluster.
[0042] Based on the same reasons as the aforementioned embodiments, the existence of available nodes in the target runtime cluster is determined in advance by the relationship between the number of instances running in the current target runtime cluster and the maximum number of fast-start instances. The allocation of target nodes is only performed when it is determined that there are available nodes, thereby improving the flexibility of the system.
[0043] Thirdly, this application provides a VNF instantiation method, which is applied to an orchestrator. The method includes: receiving first information, the first information being used to determine a first condition, the first condition including necessary conditions on which the target VNF depends for operation; determining a target runtime cluster that satisfies the first condition from an existing runtime cluster based on the first information; establishing a correspondence between the target runtime cluster and the target VNF; and sending the correspondence between the target runtime cluster and the target VNF to the VNF manager.
[0044] For the same reasons as the aforementioned embodiments, the above-described instance method establishes a correspondence between the target VNF and the target runtime cluster, and then sends it to the VNF manager. This allows the VNF manager to quickly locate the target runtime cluster based on this correspondence when the event corresponding to the target VNF is triggered. This facilitates the subsequent instantiation of the target VNF through the target runtime cluster, reduces the overall instantiation time of the target VNF, and improves the efficiency of the target VNF cold start.
[0045] In one feasible implementation, the orchestrator can also send initial information to the VNF manager.
[0046] In one feasible implementation, upon receiving the first authorization request from the VNF manager, the orchestrator can also interact with the resource manager, enabling the resource manager to allocate target nodes from the target runtime cluster. After completing the allocation, the resource manager sends a first authorization response to the VNF manager, authorizing the VNF manager to use the target nodes in the target runtime cluster. This allows for target node allocation even when communication between the VNF manager and the resource manager is unavailable, improving system fault tolerance.
[0047] In one feasible implementation, when the orchestrator receives a second authorization request from the VNF manager, it can also interact with the resource manager, enabling the resource manager to create the target runtime cluster based on the first information. After completing the creation of the target runtime cluster, the resource manager sends a second authorization response to the VNF manager, authorizing the use of the target runtime cluster. This second authorization response may also include the identifier of the target runtime cluster. This allows the creation of the target runtime cluster even when communication between the VNF manager and the resource manager is impossible, improving the system's fault tolerance.
[0048] Fourthly, a communication device is provided, the communication device including units or modules for performing any of the possible methods in the first, second or third aspects described above.
[0049] Fifthly, embodiments of this application provide a communication device, which includes at least one processor and a memory; wherein the memory is used to store computer programs or instructions; and at least one processor is used to execute the computer programs or instructions in the memory, such that the methods that may be implemented in any of the first to third aspects described above are executed.
[0050] In a sixth aspect, embodiments of this application provide a communication system, which includes a VNF manager, a trigger, and an orchestrator, wherein the VNF manager is used to execute the method of any one of the first aspects described above, the trigger is used to execute the method of any one of the second aspects described above, and the orchestrator is used to execute the method of any one of the third aspects described above.
[0051] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing computer instructions that, when executed, cause a computer to perform any of the methods described above.
[0052] Eighthly, embodiments of this application provide a computer program product, the computer program product including: computer program code, which, when executed by a computer, causes the computer to perform a method as described above.
[0053] Ninthly, embodiments of this application provide a chip coupled to a memory for reading and executing program instructions in the memory, so that the device in which the chip is located implements any of the methods described above.
[0054] It is understood that the index generation apparatus described in the fourth or fifth aspect above is used to execute the methods provided in any of the first, second, and third aspects, and the communication system described in the sixth aspect, the computer storage medium described in the seventh aspect, the computer program product described in the eighth aspect, and the chip described in the ninth aspect are all used to implement the methods provided in any of the first, second, and third aspects. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description
[0055] Figure 1A is a schematic diagram of an NFV system architecture provided in an embodiment of this application;
[0056] Figure 1B is a schematic diagram of a VNF instantiation structure provided in an embodiment of this application;
[0057] Figure 1C is a schematic diagram of a runtime cluster structure provided in an embodiment of this application;
[0058] Figure 2 is a flowchart of a VNF instantiation method provided in an embodiment of this application;
[0059] Figure 3 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0060] Figure 4 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0061] Figure 5 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0062] Figure 6 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0063] Figure 7 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0064] Figure 8 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0065] Figure 9 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0066] Figure 10 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0067] Figure 11 is a flowchart of another VNF instantiation method provided in an embodiment of this application;
[0068] Figure 12 is a schematic diagram of the structure of a communication device provided in an embodiment of this application;
[0069] Figure 13 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation
[0070] The technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings. The terms "system" and "network" in the embodiments of this application can be used interchangeably. Unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship; for example, A / B can represent A or B. "And / or" in this application is merely a description of 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, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be one or multiple. Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish between network elements and similar items with essentially the same function. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.
[0071] References to "one embodiment" or "some embodiments" in the embodiments described in this application mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0072] The following detailed embodiments further illustrate the objectives, technical solutions, and beneficial effects of this application. It should be understood that the following are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.
[0073] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.
[0074] The following describes the scenarios involved in the embodiments of this application.
[0075] This application primarily addresses the application instantiation process in a serverless scenario. The following section describes the NFV system architecture when the application corresponds to a VNF:
[0076] Please refer to Figure 1A, which is an example diagram of an NFV system architecture provided in an embodiment of this application. NFV systems can be used in various networks, such as a data center network, carrier network, or local area network. An NFV system includes an NFV orchestrator (NFVO), a VNF manager, a virtualized infrastructure manager (VIM), an NFV infrastructure layer (NFVI), VNFs, element management (EM), and an operation-support system / business support system (OSS / BSS).
[0077] Understandably, NFVO, VNFM, and VIM can constitute an NFV management and orchestration (NFV MANO) system, which is used to perform monitoring and management of NFVI and VNF.
[0078] The NFVO is primarily responsible for the virtualization orchestration and management of network functions. It receives service requests from the OSS / BSS layer and selects appropriate VNFs (Virtual Network Functions) for instantiation and management based on these requests. The NFVO is also responsible for resource allocation, performance monitoring, and fault recovery to ensure the efficient operation of VNFs. The NFVO can also execute resource-related requests from the VNFM (e.g., requests to obtain Virtual Network Function Descriptors (VNFDs), send configuration information (e.g., VNFDs, requests to modify VNF information, and VNF instantiation requests) to the VNFM, and collect VNF status information. VNFDs can be stored on the NFVO or in a database managed by the NFVO, allowing the NFVO to access and relay them to the VNFM, which then deploys the VNFs based on the VNFDs. The NFVO can store VNFDs for various functionalities of VNFs. Furthermore, the NFVO can communicate with the VIM to allocate and / or reserve resources and exchange configuration and status information of virtualized hardware resources.
[0079] The VNFM (Virtual Network Manager) is primarily responsible for managing and monitoring the lifecycle of VNFs. It works in conjunction with the NFVO layer, receiving instantiation requests from the NFVO and managing tasks such as VNF creation, configuration, upgrades, and deletion. The VNFM also provides monitoring capabilities for VNF performance, faults, and security, ensuring stable VNF operation. Multiple VNFMs can exist in an NFV system, each responsible for lifecycle management of different types of VNFs.
[0080] VIM is primarily responsible for the management and monitoring of virtualized resources in the NFVI layer. This includes managing the allocation of infrastructure resources (e.g., adding resources to virtual containers) and operational functions (e.g., collecting NFVI fault information). VNFM and VIM can communicate with each other to allocate resources and exchange configuration and status information of virtualized hardware resources.
[0081] NFVI is the underlying foundation of the NFV system architecture, providing the virtualization environment and necessary hardware resources. It typically deploys the virtualization environment using hardware resources, software resources, or a combination of both, and provides virtualized resources for VNFs through virtualization technologies (such as virtual machines and containers). The hardware resource layer includes computing hardware, storage hardware, and network hardware, while the virtual resource layer includes virtual computing, virtual storage, and virtual networking.
[0082] A Virtual Network Function (VNF) can be configured to virtualize at least one network function performed by a physical network device, such as a firewall, router, or load balancer. These VNFs can run within the virtualization environment provided by NFVI and communicate with the underlying infrastructure and other VNFs through standardized interfaces. VNFs provide the same services as traditional physical network functions but offer greater flexibility and scalability.
[0083] EM (Effective Management) is responsible for the management of physical devices and network elements. It provides monitoring, configuration, and troubleshooting capabilities for physical devices and virtual network functions. Through EM, operators can ensure the stable operation of network devices and respond quickly to any potential problems.
[0084] OSS / BSS are core systems used by operators to manage and support network services. OSS is primarily responsible for network operation and maintenance, including network monitoring, troubleshooting, and configuration management; while BSS focuses on service-level management, such as customer management, billing, and product management. These two parts are usually tightly integrated to jointly support the full lifecycle management of network services.
[0085] Figure 1A also shows the interfaces between the components, such as the interface Os-Ma-nfvo between OSS / BSS and NFVO, and the interface Ve-Vnfm-em between VNFM and EM, etc., which will not be listed here.
[0086] It is understood that Figure 1A is only an exemplary application system architecture in a serverless scenario. The architecture applicable to the embodiments of this application is not limited to this. Any architecture that can realize the functions of the above-mentioned components is applicable to the embodiments of this application.
[0087] The prior art involved in the embodiments of this application is described below.
[0088] Currently, deployments for Serverless VNF or Application can include two parts.
[0089] Step 1: On-board and Serverless VNF (or Application) instantiation preparation process.
[0090] In this crucial step, the NFV system must complete the following core tasks: First, the system receives and loads the VNF (or Application) package, ensuring the integrity and validity of its contents. The system effectively manages the function code within the VNF (or Application), including code storage, version control, and security checks. To respond to specific events or conditions, the system sets corresponding triggers for the VNF (or Application). These triggers can monitor and identify specific events that require VNF instantiation.
[0091] Step 2: VNF instantiation and event handling process.
[0092] In this step, when the system detects an event that matches the trigger configuration, the trigger immediately captures the event. After capturing the event, the trigger initiates VNF instantiation. This means the system creates a new VNF instance and allocates the necessary resources to handle the event. Once the VNF instance is successfully created and running, it will be responsible for handling the corresponding event. This may include operations such as data processing, transformation, storage, or forwarding, depending on the VNF's functionality and business requirements.
[0093] However, when Serverless VNF+WASM (or Serverless WASM Application) is applied to NFV systems, virtual machine allocation / container creation and WASM runtime + dependent components need to be performed after the event is triggered. In this way, VNF instantiation takes a long time, which cannot take advantage of the fast cold start speed of WASM VNF. Figure 1B is a schematic diagram of the structure of VNF instantiation provided by an embodiment of this application. As shown in Figure 1B, VNF instantiation requires corresponding container installation, container startup, code download and VNF initialization before VNF execution. However, the time spent on the preceding steps is from hundreds of milliseconds to several seconds.
[0094] Based on this, this embodiment solves the problem of excessively long cold start time by establishing a runtime cluster.
[0095] The following is an explanation of the terms involved:
[0096] A runtime cluster refers to a resource collection consisting of multiple servers with VNF runtimes installed. In NFV, clusters can be created and managed through CIS Cluster Management (CCM). CIS stands for Container Infrastructure Service. A runtime cluster can also be a resource pool consisting of virtual machine / container images corresponding to the VNF, the VNF runtime, and business-independent nodes with dependent components installed. In an NFV system, multiple business-independent runtime clusters can be created based on runtime, communication type, resource specifications, and other information. Different VNFs of the same user, or VNFs of different users, can share a runtime cluster if their cluster information is the same.
[0097] Runtime refers to the VNF execution environment. Different languages have different execution environments, and even the same language may have different versions. Here, runtime is used in a broad sense, including all the environment components that VNF depends on for it to function properly.
[0098] Communication type refers to the protocol used by worker nodes in the cluster to communicate with management components and triggers. The mainstream inter-component communication protocols include HTTP and gPRC. Once the communication protocol is determined, the network-related configuration can be completed in advance.
[0099] Resource specifications refer to the requirements for CPU, memory, or storage resources. Worker nodes in the same cluster have the same resource specifications, so that the resources of the worker nodes can be allocated in advance.
[0100] How to use a runtime cluster:
[0101] Shared: VNFs with the same runtime, communication type (optional), and resource specifications can use the runtime cluster in a shared manner.
[0102] Dedicated access can be divided into tenant-dedicated access and VNF-dedicated access. Tenant-dedicated access refers to a dedicated runtime cluster for a tenant, where VNFs within the same tenant can share the cluster. In this mode, the code for multiple VNFs of the same tenant can be downloaded to worker nodes, and the decision on which VNF to run is made after an event is triggered, further reducing cold start time. VNF-dedicated access refers to a dedicated runtime cluster for a single VNF. In this case, because it is a single VNF dedicated access, the VNF code can be downloaded to worker nodes in advance, and even the process can be run. A tenant refers to the logical separation of multiple users or clients within a system. This architecture allows multiple users to use the same database and application instance, thereby saving resources and reducing costs. In other words, a tenant can be understood as a collection of resources owned by an individual, project, or organization. A tenant can have multiple users, and these users use the resources within the tenant according to their permissions.
[0103] Maximum number of fast-start instances:
[0104] This refers to the maximum number of concurrent instances that can be quickly launched using the runtime cluster. This parameter differs from the maximum concurrent instance count, which refers to the maximum number of instances that the VNF can create in the system, preventing resource exhaustion. Maximum fast-start instance count <= maximum concurrent instance count. If the maximum fast-start instance count is exceeded, the system will use a slow startup process, allocating new compute nodes and installing runtime software to instantiate the VNF.
[0105] For example, Figure 1C is a schematic diagram of a runtime cluster structure provided in an embodiment of this application. As shown in Figure 1C, the runtime cluster can have different VNF execution environments and corresponding resource specifications. As shown in the figure, Python 2.7+Memory 512Mib, Python 3.8+Memory 1Gib, Node.js 14.x+Memory 1Gib, and Wasmer 5.0+Memory 512Mib.
[0106] As mentioned above, VNF instantiation currently takes a long time. This application addresses this technical issue by establishing a runtime cluster, which will be described in detail below:
[0107] Example 1: Based on this, please refer to Figure 2. Figure 2 is a flowchart of a VNF instantiation method provided by an embodiment of this application. As shown in Figure 2, the method includes the following steps:
[0108] 201. When the trigger captures an instance trigger event of the target VNF, it sends an instance trigger message for the target VNF. Correspondingly, the VNF manager receives the instance trigger message for the target VNF.
[0109] In this context, the instance trigger message of the target VNF is triggered by the trigger when it captures a corresponding event. This corresponding event is pre-configured based on the target VNF. Examples include timer triggers and user interaction triggers (such as clicking a button or entering text). This trigger can be understood as a special VNF.
[0110] The VNF manager is primarily responsible for managing trigger settings, scaling up and down VNF instances, and load balancing among VNF instances. For example, in an NFV system architecture, the VNF manager can be a VNFM or other modules with VNFM functionality.
[0111] 202. The VNF manager determines the target runtime cluster corresponding to the target VNF based on the instance trigger message.
[0112] The target runtime cluster satisfies the first condition, which includes the necessary conditions upon which the target VNF depends for operation. For example, the necessary conditions upon which the target VNF depends for operation may include the VNF execution environment, communication type, and the corresponding resources (CPU or memory, etc.).
[0113] 203. The VNF manager instantiates the target VNF based on the target runtime cluster.
[0114] Since a target runtime cluster that meets the necessary conditions for the target VNF to run is pre-deployed, the target VNF can be instantiated by allocating the corresponding worker nodes from the target runtime cluster through the resource manager. This avoids a series of operations such as virtual machine allocation / container creation and installation of WASM runtime + dependent components before instantiating the target VNF, thereby reducing the cold start time of the target VNF.
[0115] The resource manager can include the functionality of Virtualized Infrastructure Manager (VIM), Physical Infrastructure Manager (PIM), CCM, and CIS Management (CISM).
[0116] VIM is primarily responsible for the management (including reservation and allocation) of virtualized resources at the infrastructure layer (including virtual compute, storage, and network resources), monitoring the status of virtual resources, and reporting faults, providing virtualized clusters for upper-layer applications. PIM manages physical hardware resources, such as servers, storage devices, and network switches. It provides lifecycle management for physical devices, including deployment, monitoring, troubleshooting, and maintenance. CCM manages the cluster, and CISM manages the container objects invoked by containerized applications, including the creation, updating, and deletion of container objects, and scheduling container objects to appropriate node resources (compute, storage, and network) within the managed container cluster. The corresponding concept for container objects in the ETSI standard is Managed Container Infrastructure Object (MCIO). Additionally, the resource manager may also include management functions for VNF runtime and dependent components.
[0117] Understandably, VNF in this application can also refer to Application, so instantiating VNF can also be understood as instantiating the corresponding Application. When Application consists of only one Function, instantiating Application is equivalent to instantiating Function.
[0118] Example 2: The above examples generally describe the instantiation process for the target VNF. This example provides a detailed explanation of the instantiation details.
[0119] Referring to Figure 3, which is a flowchart of another VNF instantiation method provided in this application embodiment, as shown in Figure 3, NFVO represents the orchestrator, VNFM represents the VNF manager, CCM / infrastructure management represents the resource manager, and Runtime repository represents the system repository. The VNF runtime and the target VNF package (including VNFD) are pre-stored in the system repository, and the operator also plans and creates a runtime cluster based on resource availability, obtaining the identifier of the runtime cluster. The trigger is pre-configured with the identifier of the target runtime cluster used to instantiate the target VNF. The method includes the following steps:
[0120] 301. When the trigger captures an instance trigger event of the target VNF, it sends an instance trigger message for the target VNF, which carries the identifier of the target runtime cluster. Correspondingly, the VNF manager receives the instance trigger message for the target virtualized network function VNF.
[0121] After receiving the instance trigger message from the target Virtualized Network Function (VNF), the VNF Manager needs to allocate target nodes in the target runtime cluster through the Resource Manager. The allocation of target nodes in the target runtime cluster can be done directly or indirectly.
[0122] The direct method is:
[0123] 302A: The VNF Manager sends a first instruction message, which instructs the allocation of a target node from the target runtime cluster. This first instruction message carries the identifier of the target runtime cluster. Correspondingly, the Resource Manager receives the first instruction message.
[0124] The resource manager can locate the target runtime cluster from the existing runtime clusters based on the identifier of the target runtime cluster carried in the first instruction information.
[0125] The indirect method is:
[0126] 302B: The VNF manager sends a first authorization request, which requests authorization for the VNF manager to use nodes in the target runtime cluster. The first authorization request carries the identifier of the target runtime cluster. Correspondingly, the orchestrator receives the first authorization request.
[0127] 302C. The orchestrator sends a first instruction message, which instructs the allocation of a target node from the target runtime cluster. The first instruction message carries the identifier of the target runtime cluster. Correspondingly, the resource manager receives the first instruction message.
[0128] 302D: The orchestrator sends a first authorization response, which authorizes the VNF manager to use the target node in the target runtime cluster. Correspondingly, the VNF manager receives the first authorization response.
[0129] Understandably, when executing the aforementioned 302A and 302B to 302D, one of the steps can be selected from the actual situation for execution.
[0130] 303. The VNF manager instantiates the target VNF based on the target node.
[0131] Example 3: This example is based on Example 2, and is explained in conjunction with the maximum number of fast-start instances.
[0132] Referring to Figure 4, which is a flowchart of another VNF instantiation method provided in the embodiments of this application, as shown in Figure 3, the method includes the following steps:
[0133] 401. When the trigger captures an instance trigger event of the target VNF, it sends an instance trigger message for the target VNF, which carries the identifier of the target runtime cluster. Correspondingly, the VNF manager receives the instance trigger message for the target virtualized network function VNF.
[0134] 402. The VNF manager sends a first retrieval command, which is used to retrieve the target VNF package containing VNFDs. Correspondingly, the orchestrator receives the first retrieval command.
[0135] 403. The orchestrator sends the target VNF package containing the VNFD. Correspondingly, the VNF manager receives the target VNF package containing the VNFD.
[0136] 404. The VNF Manager obtains the maximum number of fast-start instances of the target VNF from the VNFD.
[0137] 405. If the VNF Manager determines that the number of instances running in the current target runtime cluster is less than the maximum number of fast start instances, execute step 406A or 406B; if it determines that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast start instances, execute step 406E.
[0138] Understandably, after the steps of 406B are executed, the steps of 406C and 406D will also be executed sequentially.
[0139] 406A, the VNF manager sends a first instruction message, which instructs the allocation of a target node from the target runtime cluster. This first instruction message carries the identifier of the target runtime cluster. Correspondingly, the resource manager receives the first instruction message.
[0140] 406B. The VNF manager sends a first authorization request, which requests authorization for the VNF manager to use nodes in the target runtime cluster. The first authorization request carries the identifier of the target runtime cluster. Correspondingly, the orchestrator receives the first authorization request.
[0141] 406C. The orchestrator sends a first instruction message, which instructs the allocation of a target node from the target runtime cluster. The first instruction message carries the identifier of the target runtime cluster. Correspondingly, the resource manager receives the first instruction message.
[0142] 406D. The orchestrator sends a first authorization response, which authorizes the VNF manager to use the target node in the target runtime cluster. Correspondingly, the VNF manager receives the first authorization response.
[0143] The 406E and VNF managers send a second instruction message, which instructs the request for a new target node. Correspondingly, the resource manager receives the second instruction message.
[0144] Understandably, when executing the aforementioned 406A and 406B to 406D, one of the steps can be selected according to the actual situation.
[0145] 407. The VNF manager instantiates the target VNF based on the target node.
[0146] Example 4: This example is based on Example 2, and is also explained in conjunction with the maximum number of fast-start instances.
[0147] Referring to Figure 5, which is a flowchart of another VNF instantiation method provided in an embodiment of this application, as shown in Figure 3, the trigger, in addition to being pre-configured with an identifier for the runtime cluster used to instantiate the target VNF, is also pre-configured with a maximum number of fast-start instances. The method includes the following steps:
[0148] 501A. When the trigger captures an instance trigger event of the target VNF, it sends an instance trigger message for the target VNF. If it is determined that the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances, the instance trigger message carries the identifier of the target runtime cluster. Correspondingly, the VNF manager receives the instance trigger message of the target virtualized network function VNF.
[0149] 501B. When the trigger captures an instance trigger event of the target VNF, it sends an instance trigger message for the target VNF. If it is determined that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances, the instance trigger message carries the identifier of the target runtime cluster. Correspondingly, the VNF manager receives the instance trigger message of the target virtualized network function VNF.
[0150] Understandably, after the trigger is pre-configured with the maximum number of fast-start instances, it will record the number of instantiated target VNFs that have been notified to the VNF manager, thereby determining the number of instances running in the current target runtime cluster.
[0151] 502. If the VNF Manager determines that the received instance trigger message carries the identifier of the target runtime cluster, it shall execute step 503A or 503B; if it determines that the received instance trigger message does not carry the identifier of the target runtime cluster, it shall execute step 503E.
[0152] Understandably, after the steps of 503B are executed, the steps of 503C and 503D will also be executed sequentially.
[0153] The 503A VNF Manager sends a first instruction message, which instructs the allocation of a target node from the target runtime cluster. This first instruction message carries the identifier of the target runtime cluster. Correspondingly, the Resource Manager receives the first instruction message.
[0154] 503B: The VNF manager sends a first authorization request, which requests authorization for the VNF manager to use nodes in the target runtime cluster. The first authorization request carries the identifier of the target runtime cluster. Correspondingly, the orchestrator receives the first authorization request.
[0155] The 503C orchestrator sends a first instruction message, which instructs the allocation of a target node from the target runtime cluster. This first instruction message carries the identifier of the target runtime cluster. Correspondingly, the resource manager receives the first instruction message.
[0156] 503D: The orchestrator sends a first authorization response, which authorizes the VNF manager to use the target node in the target runtime cluster. Correspondingly, the VNF manager receives the first authorization response.
[0157] The 503E and VNF managers send a second instruction message, which instructs the request for a new target node. Correspondingly, the resource manager receives the second instruction message.
[0158] Understandably, when executing the aforementioned 503A and 503B to 503D, one of the steps can be selected from the actual situation.
[0159] 504. The VNF manager instantiates the target VNF based on the target node.
[0160] Example 5: In addition to carrying the identifier of the target runtime cluster when sending the instance trigger message, the correspondence between the target VNF and the target runtime cluster can also be recorded in advance in the VNF manager.
[0161] Referring to Figure 6, which is a flowchart of another VNF instantiation method provided in this application embodiment, as shown in Figure 6, NFVO represents the orchestrator, VNFM represents the VNF manager, CCM / infrastructure management represents the resource manager, and Runtime repository represents the system repository. The VNF runtime and the target VNF package (including VNFD) are pre-stored in the system repository, and the operator also plans and creates a runtime cluster based on resource availability, obtaining the identifier of the runtime cluster. This method includes the following steps:
[0162] 601. The orchestrator sends a first request instruction, which requests the creation of an identifier for the target VNF. Correspondingly, the VNF manager receives the first request instruction.
[0163] The first request instruction can be CreateVnfRequest.
[0164] 602. The VNF manager sends a first retrieval command, which is used to retrieve the target VNF package. Correspondingly, the orchestrator receives the first retrieval command.
[0165] 603. The orchestrator sends the target VNF package. Correspondingly, the VNF manager receives the target VNF package.
[0166] 604. The VNF Manager determines whether a target runtime cluster exists in the system based on the runtime information described in the VNFD included in the target VNF package, whether a runtime cluster is used, the usage method, and the maximum number of fast start instances.
[0167] If the 605A VNF Manager determines that a target runtime cluster that meets the aforementioned conditions exists in the system, it establishes a correspondence between the target VNF and the target runtime cluster.
[0168] If the VNF Manager determines that there is no target runtime cluster in the system that meets the aforementioned conditions, it will create a target runtime cluster based on runtime information, whether a runtime cluster is used, the usage method, and the maximum number of fast start instances, and establish a correspondence between the target VNF and the target runtime cluster.
[0169] 606. The VNF manager sends a first response command, which notifies the completion of the creation of the identifier for the target VNF. Correspondingly, the orchestrator receives the first response command.
[0170] Understandably, the process by which the orchestrator requests the VNF manager to create the identifier of the target VNF does not consume resources for instantiation. Therefore, a process for establishing the mapping between the target VNF and the target runtime cluster can be added to this process. The first response command can be CreateVnfResponse.
[0171] 607. When the trigger captures an instance trigger event of the target VNF, it sends an instance trigger message for the target VNF. Correspondingly, the VNF manager receives the instance trigger message for the target virtualized network function VNF.
[0172] 608. The VNF manager determines the target runtime cluster based on the correspondence between the target VNF and the target runtime cluster.
[0173] 609. The VNF manager instantiates the target VNF based on the target runtime cluster.
[0174] As is understandable, the steps by which the VNF manager instantiates the target VNF based on the target runtime cluster have been described in detail in the aforementioned embodiments, and will not be repeated here.
[0175] Example 6: The above examples generally describe the instantiation process for the target VNF. There are two ways to establish a runtime cluster: static and dynamic. Furthermore, the correspondence between the target runtime cluster and the target VNF can also be established using other methods. This example describes the case where the runtime cluster is statically established.
[0176] Referring to Figure 7, which is a flowchart of another VNF instantiation method provided in an embodiment of this application, as shown in Figure 7, OSS / BSS represents a user or operator, NFVO represents an orchestrator, VNFM represents a VNF manager, CCM / infrastructure management represents a resource manager, and Code repository represents a code repository. The method includes the following steps:
[0177] Operators will pre-create runtime clusters based on resource availability and their own policies. These runtime clusters will not be actively deleted even if they are not associated with other VNFs.
[0178] 701. The user or operator sends the first message. Correspondingly, the orchestrator receives the first message.
[0179] The first information is used to determine the first condition, and may also include the third and second information. The first condition includes the necessary conditions upon which the target VNF depends for operation and the maximum number of fast-start instances. The third information is used to determine the cluster usage mode, which may be either shared or exclusive. The second information is used to determine the code corresponding to the target VNF, and if the cluster usage mode is exclusive, the code corresponding to the target VNF can be downloaded to the worker nodes included in the target runtime cluster. The second information may also include the code corresponding to the target VNF itself, or the address used to obtain the code corresponding to the target VNF, or other information.
[0180] In the NFV system architecture, the orchestrator can be NFVO or other modules with corresponding NFVO functions.
[0181] Optionally, the first information may directly include the first condition itself, or it may include the address or other information used to obtain the first condition.
[0182] Optionally, the first piece of information sent can be a VNF or Application package. After receiving the package, the orchestrator can check its integrity and validity, and only send it to the VNF manager after the integrity and validity checks are passed. For example, a VNF package or Application package may include information such as a descriptor, function code, and configuration files, and the aforementioned first piece of information can be represented as a descriptor.
[0183] 702. The orchestrator sends the first message. Correspondingly, the VNF manager receives the first message.
[0184] 703. The VNF manager checks whether there is a target runtime cluster in the existing runtime cluster that meets the first condition. If it exists, it establishes a correspondence between the target runtime cluster and the target VNF.
[0185] Optionally, the aforementioned steps can also be performed within the orchestrator. Since operators pre-create runtime clusters based on resource availability and their own policies, it is possible to determine whether a target runtime cluster satisfying the first condition exists based on the pre-created runtime clusters. When the existence of a target runtime cluster is determined, a mapping relationship between the target runtime cluster and the target VNF is established.
[0186] Understandably, if the first condition also includes the maximum number of fast-start instances N, then the target runtime cluster must satisfy the first condition by including at least M worker nodes, and these M worker nodes must be able to run N target VNF instances.
[0187] Optionally, the target runtime cluster can be pre-planned and created by the operator based on resource availability, or it can be created based on the first information after the first information has been determined. In this embodiment, the target runtime cluster satisfies the first condition, meaning that the target runtime cluster includes worker nodes that can meet the necessary conditions for the target VNF to run. For example, the worker node has the virtual machine image / container image corresponding to the target VNF installed, as well as the environment components that the target VNF depends on, so that the worker node can run the target VNF.
[0188] 704. The VNF Manager sends a fourth instruction message, which instructs the code corresponding to the target VNF to be downloaded to the worker nodes included in the target runtime cluster. Correspondingly, the Resource Manager receives the fourth instruction message.
[0189] Optionally, the VNF manager can send the fourth instruction information if the cluster usage mode in the third information is exclusive. When the cluster usage mode in the third information is exclusive, the exclusive mode can be divided into tenant exclusive and VNF exclusive.
[0190] For the tenant-exclusive approach, the target runtime cluster does not initially establish a correspondence with the target VNFs of other tenants. Furthermore, after establishing the correspondence between the target runtime cluster and the target VNF, the target runtime cluster cannot establish a correspondence with the target VNFs of other tenants until the correspondence between the target runtime cluster and the target VNF is terminated. Other tenants refer to tenants other than the tenant corresponding to the target VNF.
[0191] In the case of exclusive VNF, the target runtime cluster does not have any prior correspondence with other target VNFs. After the correspondence between the target runtime cluster and the target VNF is established, the target runtime cluster cannot establish correspondence with other VNFs before the correspondence between the target runtime cluster and the target VNF is terminated. Other VNFs refer to VNFs that are different from the target VNF.
[0192] When the cluster is used in exclusive mode, the VNF manager sends a fourth instruction message to the resource manager. After receiving the fourth instruction message, the resource manager will download the code corresponding to the target VNF to the code repository of the worker node in the runtime cluster.
[0193] Optionally, considering the first condition also includes the maximum number of fast-start instances N, since the target runtime cluster satisfies the first condition, the target runtime cluster needs to include at least M worker nodes, and these M worker nodes must be able to run N target VNF instances. When the cluster usage mode in this third piece of information is exclusive, the code corresponding to the target VNF can be downloaded to these M worker nodes in advance. It is understandable that the cluster usage mode can also be included in the first condition.
[0194] 705. The VNF manager sends the first notification message. Correspondingly, the orchestrator receives the first notification message.
[0195] 706. The orchestrator sends the first notification message. Correspondingly, the user or operator receives the first notification message.
[0196] The first notification information can be used to notify that the deployment before the instantiation of the target VNF has been completed, such as the establishment of the correspondence between the target runtime cluster and the target VNF.
[0197] Example 7: This example describes the case where the runtime cluster is dynamically created.
[0198] Referring to Figure 8, which is a flowchart of another VNF instantiation method provided in an embodiment of this application, as shown in Figure 8, OSS / BSS represents a user or operator, NFVO represents an orchestrator, VNFM represents a VNF manager, CCM / infrastructure management represents a resource manager, and Code repository represents a code repository. The method includes the following steps:
[0199] 801. The user or operator sends the first message. Correspondingly, the orchestrator receives the first message.
[0200] The first information is used to determine the first condition, and may further include second and third information. The first condition includes the necessary conditions for the target VNF to run and the maximum number of fast-start instances. The third information is used to determine the cluster usage method, which may be either shared or exclusive. The second information is used to determine the code corresponding to the target VNF. Optionally, the cluster usage method may also include not using a cluster. It is understood that the dimension corresponding to the information sent by the user or operator can be the dimension of a Serverless VNF or Serverless Application; similarly, the dimension corresponding to the information sent by the orchestrator to the user or operator can also be the dimension of a Serverless VNF or Serverless Application.
[0201] 802. The orchestrator sends the first message. Correspondingly, the VNF manager receives the first message.
[0202] 803. The VNF Manager checks whether a runtime cluster is needed. If so, it checks whether a target runtime cluster that meets the first condition exists in the system.
[0203] Optionally, in the current embodiment, the operator will not pre-create a runtime cluster based on resource availability and its own policies. In this case, it is necessary to first check whether the target VNF needs to use a runtime cluster.
[0204] For example, if the third information used to determine the cluster usage mode only includes either shared or exclusive, then the check to determine whether the target VNF needs to use a runtime cluster could be to check whether the first information includes the third information, which is used to determine the cluster usage mode. If the third information is not present in the first information, it can be determined that a runtime cluster is not needed; if the third information is present in the first information, it can be determined that a runtime cluster is needed.
[0205] For example, if the cluster usage mode determined by the third information includes any of the following: shared, exclusive, or no cluster usage, then the check on whether the target VNF needs to use the runtime cluster can be to check whether the cluster usage mode determined by the third information is no cluster usage. If the cluster usage mode is no cluster usage, then it can be determined that the runtime cluster does not need to be used; if the cluster usage mode is not no cluster usage, then it can be determined that the runtime cluster needs to be used.
[0206] If it is determined that the target VNF needs to use a runtime cluster, then it is also necessary to check whether a target runtime cluster that meets the first condition exists in the system. The reason for checking whether a target runtime cluster that meets the first condition exists in the system is that there may be runtime clusters created during the deployment of other target VNFs before instantiation.
[0207] If it is determined that the target runtime cluster does not exist within the system and meets the first condition, then the target runtime cluster needs to be dynamically created. Dynamic creation of the target runtime cluster can include two methods: direct creation and indirect creation.
[0208] Indirect creation may include the following steps:
[0209] 804A. The VNF manager sends a second authorization request, which requests the orchestrator to instruct the resource manager to create the target runtime cluster based on the first information and to authorize the VNF manager to use the target runtime cluster. Correspondingly, the orchestrator receives the second authorization request.
[0210] 804B, The orchestrator interacts with the resource manager so that the resource manager can create the target runtime cluster based on the first information.
[0211] 804C: The orchestrator sends a second authorization response, which authorizes the VNF manager to use the target runtime cluster. Correspondingly, the VNF manager receives the second authorization response.
[0212] Optionally, after receiving the second authorization request, the orchestrator can, in addition to directly interacting with the resource manager to create the target runtime cluster, also reserve only the infrastructure resources corresponding to the target VNF (without installing the runtime). Infrastructure resources can include the aforementioned computing resources, runtime resources, and network resources, etc.
[0213] Direct creation may include the following steps:
[0214] The 804D and VNF managers interact with the resource manager to enable the resource manager to create the target runtime cluster based on the initial information.
[0215] For example, the VNF manager can send a third instruction message to the resource manager, which instructs the resource manager to create the target runtime cluster based on the first information. The third instruction message can carry the first information.
[0216] 805. The VNF Manager establishes the mapping between the target runtime cluster and the target VNF.
[0217] After determining or creating the target runtime cluster through the aforementioned steps, the correspondence between the target runtime cluster and the target VNF is established.
[0218] 806. The VNF Manager sends a fourth instruction message, which instructs the code corresponding to the target VNF to be downloaded to the worker nodes included in the target runtime cluster. Correspondingly, the Resource Manager receives the fourth instruction message.
[0219] 807. The VNF manager sends the first notification message. Correspondingly, the orchestrator receives the first notification message.
[0220] 808. The orchestrator sends the first notification message. Correspondingly, the user or operator receives the first notification message.
[0221] Example 8: This example describes the scaling process for an instance of a target VNF.
[0222] Referring to Figure 9, which is a flowchart of another VNF instantiation method provided in an embodiment of this application, as shown in Figure 9, VNFM represents the VNF manager, CCM / Infrastructure Management represents the resource manager, and VNF instance represents the instance corresponding to the target VNF. The method includes the following steps:
[0223] 901. The trigger sends an instance expansion trigger message for the target VNF. Correspondingly, the VNF manager receives the instance expansion trigger message for the target VNF.
[0224] The instance expansion trigger message for this target VNF can also be triggered by a trigger when it captures the corresponding event.
[0225] 902. The VNF Manager sends the first instruction message, which carries the identifier of the target runtime cluster. Correspondingly, the Resource Manager receives the first instruction message.
[0226] The first instruction information is used to instruct the allocation of target nodes from the target runtime cluster.
[0227] 903. The VNF manager instantiates the target VNF based on the target node.
[0228] Upon receiving the first instruction, the resource manager can directly locate the target runtime cluster based on the identifier it contains. It then checks if any available worker nodes exist within the target runtime cluster. An available worker node is one that can currently run the target VNF. If an available worker node exists in the target runtime cluster, it can be directly allocated to instantiate the target VNF. If no available worker node exists, a new worker node needs to be created to instantiate the target VNF. This new worker node can be created within the target runtime cluster or outside the system. Understandably, a newly created worker node is one that can be used to run the target VNF. For example, this worker node includes all the environmental components and corresponding infrastructure resources that the target VNF depends on.
[0229] Understandably, indirect allocation of target nodes can also be achieved based on the orchestrator, which will not be elaborated here.
[0230] 904. The VNF Manager checks whether the execution task corresponding to the target VNF instance has been completed.
[0231] When an event corresponding to the target VNF is triggered, the instantiated target VNF is primarily used to execute the corresponding task. Therefore, it is necessary to check whether the task executed by the target VNF instance has been completed.
[0232] For example, when the task corresponding to the target VNF instance is still in progress, the running state of the target VNF instance can be "Running". When the task corresponding to the target VNF instance is completed, the running state of the target VNF instance can be "Idle".
[0233] 905. If it is determined that the task corresponding to the target VNF instance has been completed, then delete the target VNF instance.
[0234] After deleting the target VNF instance, the target node will be restored to an available state.
[0235] Example 9: After the instantiation of the target VNF is completed, this example describes the subsequent deinstantiation process of the target VNF.
[0236] Referring to Figure 10, which is a flowchart of another VNF instantiation method provided in an embodiment of this application, as shown in Figure 10, OSS / BSS represents a user or operator, NFVO represents an orchestrator, VNFM represents a VNF manager, and CCM / Instrumentation Management represents a resource manager. The method includes the following steps:
[0237] 1001. The user or operator sends a fifth instruction message, which instructs the target VNF to be deinstantiated. Correspondingly, the orchestrator receives the fifth instruction message.
[0238] When a user or operator deletes a target VNF, a fifth instruction message is sent to the orchestrator. The dimension corresponding to the fifth instruction message is the target VNF. After receiving the fifth instruction message, the orchestrator determines the specific target VNF that needs to be de-instantiated and then sends an instruction to the VNF manager to de-instantiate the target VNF.
[0239] 1002. The orchestrator sends the fifth instruction information. Correspondingly, the VNF manager receives the fifth instruction information.
[0240] 1003. The VNF manager performs an instantiation operation on the target VNF.
[0241] 1004. The VNF Manager removes the mapping between the target VNF and the target runtime cluster; if the target runtime cluster does not have a corresponding VNF, the target runtime cluster is deleted.
[0242] During this process, the VNF manager will remove the mapping between the target VNF and the target runtime cluster, and determine whether there are any other VNFs with a mapping in the current target runtime cluster. If there are no other VNFs with a mapping, the target runtime cluster will be deleted to release resources.
[0243] It is understandable that the statically created runtime clusters in the aforementioned embodiments will not be actively deleted even if they do not establish a correspondence with other VNFs. The target runtime cluster to be deleted shown in this embodiment is mainly based on dynamically created runtime clusters.
[0244] 1005. The VNF manager sends a second response message. Correspondingly, the orchestrator receives the second response message.
[0245] The second response information is used to indicate that the deinstantiation of the target VNF has been completed.
[0246] 1006. The orchestrator sends a third response message. Correspondingly, the user or operator receives the third response message.
[0247] The third response information can be the same as the second response information, or it can indicate that the instantiation of the target VNF has been completed.
[0248] Example 10: This example describes the process of scaling up or down the runtime cluster based on corresponding strategies during VNF instantiation.
[0249] Referring to Figure 11, which is a flowchart of another VNF instantiation method provided in an embodiment of this application, as shown in Figure 11, VNFM in Figure 11 represents the VNF manager, and CCM / Instrumentation Management represents the resource manager. The method includes the following steps:
[0250] 1101. The trigger sends an instance trigger message for the target VNF. Correspondingly, the VNF manager receives the instance trigger message for the target VNF.
[0251] The instance trigger message for this target VNF can be triggered by a trigger when the corresponding event is captured.
[0252] 1102. The VNF manager sends the first instruction information, which carries the identifier of the target runtime cluster. Correspondingly, the resource manager receives the first instruction information.
[0253] The first instruction information is used to instruct the allocation of target nodes from the target runtime cluster.
[0254] 1103. The VNF manager instantiates the target VNF based on the target node in the target runtime cluster.
[0255] Understandably, when the resource manager allocates an available target node from the target runtime cluster for instantiating the target VNF, it also includes steps to check the availability of nodes in the target runtime cluster, and to create a new worker node if no worker node is available. These steps will not be elaborated upon here.
[0256] 1104. The resource manager determines that the number of available worker nodes in the target runtime cluster is low, and expansion is needed.
[0257] 1105. Expand the target runtime cluster using Resource Manager.
[0258] Optionally, when the number of available worker nodes in the target runtime cluster is lower than a first preset threshold, the number of worker nodes in the target runtime cluster is increased so that the number of available worker nodes is not lower than the first preset threshold.
[0259] Optionally, when the ratio of the number of available worker nodes in the target runtime cluster to the total number of worker nodes is less than a first preset ratio, the number of worker nodes in the target runtime cluster is increased so that the ratio of the number of available worker nodes in the target runtime cluster to the total number of worker nodes is not less than the first preset ratio.
[0260] 1106. The Resource Manager sends a fourth message, indicating the number of worker nodes that have been added to the target runtime cluster. Correspondingly, the VNF Manager receives the fourth message.
[0261] The VNF manager receives the fourth information, which can be based on a prior subscription, so that the resource manager actively sends the fourth information to the VNF manager after the expansion.
[0262] 1107. The resource manager determines that the number of available worker nodes in the target runtime cluster is too high, and it needs to be scaled down.
[0263] 1108. Resource Manager shrinks the target runtime cluster.
[0264] Optionally, when the number of available worker nodes in the target runtime cluster is higher than the second preset threshold, the number of worker nodes in the target runtime cluster is reduced so that the number of available worker nodes is not higher than the second preset threshold.
[0265] Optionally, when the ratio of the number of available worker nodes in the target runtime cluster to the total number of worker nodes is greater than a second preset ratio, the number of worker nodes in the target runtime cluster is reduced so that the ratio of the number of available worker nodes in the target runtime cluster to the total number of worker nodes is not greater than the second preset ratio.
[0266] 1109. The Resource Manager sends the fifth message, which indicates that the target runtime cluster has reduced the number of worker nodes included. Correspondingly, the VNF Manager receives the fifth message.
[0267] The VNF manager receives the fifth information, which can also be based on a prior subscription, allowing the resource manager to proactively send the fifth information to the VNF manager after scaling down.
[0268] The number of available worker nodes in the target cluster can be increased or decreased in accordance with the methods shown in the foregoing embodiments, so as to maintain the number of available worker nodes in the target runtime cluster at a level with high utilization efficiency.
[0269] As can be seen, in this application, by pre-configuring a target runtime cluster that meets the necessary conditions for the target VNF to run and establishing a correspondence between the target runtime cluster and the target VNF, the target VNF can be instantiated based on the target runtime cluster when an event corresponding to the target VNF is triggered subsequently. This avoids creating the conditions required for VNF instantiation (such as virtual machine allocation / container creation, and installation of WASM runtime + dependent components) only when an event corresponding to the target VNF is triggered, reducing the overall instantiation time of the target VNF and improving the efficiency of cold start of the target VNF.
[0270] Please refer to Figure 12, which is a schematic diagram of a communication device provided in an embodiment of this application. This communication device can be used to execute any of the methods in the foregoing embodiments.
[0271] As shown in Figure 12, the communication device includes a processing module 1201 and a transceiver module 1202. The processing module 1201 may be one or more processors, and the transceiver module 1202 may be a transceiver or a communication interface. This communication device can be used to implement the functions of the VNF manager, trigger, and orchestrator involved in any of the above method embodiments. Optionally, the communication device may further include a storage module 1203 for storing the program code and data of the communication device. The processing module 1201 can read instructions and / or data from the storage unit to enable the device to perform the actions of different devices in the aforementioned method embodiments.
[0272] In the first instance, the communication device can function as a first device or a chip within a first device, and execute the steps performed by the VNF manager in embodiments one through six of the above method. The transceiver module 1202 supports communication between the VNF manager and triggers, orchestrators, or resource managers, etc. The processing module 1201 can be used to support the execution of actions performed by the VNF manager in the above method embodiments, excluding sending and receiving.
[0273] Specifically, the transceiver module 1202 is used to: receive an instance trigger message from the target VNF of the trigger; the processing module 1201 is used to: determine the target runtime cluster corresponding to the target VNF based on the instance trigger message, wherein the target runtime cluster satisfies a first condition, the first condition including the necessary conditions on which the target VNF depends for operation; and instantiate the target VNF based on the target runtime cluster.
[0274] In one feasible implementation, the instance trigger message carries an identifier corresponding to the target runtime cluster. In determining the target runtime cluster corresponding to the target VNF based on the instance trigger message, the processing module 1201 is specifically used to: determine the target runtime cluster corresponding to the target VNF based on the identifier corresponding to the target runtime cluster.
[0275] In one feasible implementation, the transceiver module 1202 is further configured to: send a first instruction message to the resource manager, the first instruction message being used to instruct the allocation of a target node from the target runtime cluster, the first instruction message carrying an identifier of the target runtime cluster; the processing module 1201 is specifically configured to: instantiate a target VNF based on the target node.
[0276] In one feasible implementation, the transceiver module 1202 is further configured to: send a first authorization request to the orchestrator based on an instance-triggered message, the first authorization request being used to request authorization for the VNF manager to use nodes in the target runtime cluster; and receive a first authorization response from the orchestrator, the first authorization response being used to authorize the VNF manager to use target nodes in the target runtime cluster. The processing module 1201 is specifically configured to: instantiate a target VNF based on the target node.
[0277] In one feasible implementation, the processing module 1201 is further configured to: determine the maximum number of fast-start instances of the target VNF; when the processing module 1201 determines that the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances, the transceiver module 1202 is configured to: send a first instruction message to the resource manager, or send a first authorization request to the orchestrator based on the instance trigger message, and receive a first authorization response from the orchestrator; the processing module 1201 is further configured to: instantiate the target VNF based on the target node.
[0278] In one feasible implementation, when the processing module 1201 determines that the instance trigger message carries an identifier corresponding to the target runtime cluster, the transceiver module 1202 is configured to: send a first instruction message to the resource manager, or send a first authorization request to the orchestrator based on the instance trigger message, and receive a first authorization response from the orchestrator; the processing module 1201 is also configured to: instantiate the target VNF based on the target node. The prerequisite for the instance trigger message carrying an identifier corresponding to the target runtime cluster is that the trigger determines that the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances for the target VNF.
[0279] In one feasible implementation, when the processing module 1201 determines that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances, the transceiver module 1202 is used to: send a second instruction message to the resource manager, the second instruction message being used to instruct the request for a new target node; the processing module 1201 is also used to: instantiate a target VNF based on the target node.
[0280] In one feasible implementation, when the processing module 1201 determines that the instance trigger message does not carry the identifier corresponding to the target runtime cluster, the transceiver module 1202 is used to: send a second instruction message to the resource manager, the second instruction message being used to instruct the request for a new target node; the processing module 1201 is also used to: instantiate the target VNF based on the target node. The prerequisite for the instance trigger message not carrying the identifier corresponding to the target runtime cluster is that the trigger determines that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances of the target VNF.
[0281] In one feasible implementation, the transceiver module 1202 is further configured to: receive a first request instruction from the orchestrator, the first request instruction being used to request the creation of an identifier for the target VNF; receive first information from the orchestrator, the first information being used to determine a first condition; the processing module 1201 is further configured to: determine a target runtime cluster from the existing runtime clusters based on the first condition; establish a correspondence between the target runtime cluster and the target VNF; the transceiver module 1202 is further configured to: send a first reply instruction to the orchestrator, the first reply instruction being used to notify that the creation of the identifier for the target VNF is complete.
[0282] In one feasible implementation, the first condition further includes a maximum number of fast-start instances N, and the target runtime cluster includes at least M worker nodes, which are capable of running N target VNF instances.
[0283] In one feasible implementation, the processing module 1201 is further configured to: if there is no runtime cluster that meets the first condition in the existing runtime cluster, then create a target runtime cluster based on the first information.
[0284] In one feasible implementation, the transceiver module 1202 is further configured to: if there is no runtime cluster in the existing runtime cluster that meets the first condition, send a second authorization request to the orchestrator, the second authorization request being used to request the orchestrator to instruct the resource manager to create the target runtime cluster according to the first information and authorize the VNF manager to use the target runtime cluster; and receive a second authorization response from the orchestrator, the second authorization response being used to authorize the VNF manager to use the target runtime cluster.
[0285] In one feasible implementation, the first information further includes third information, which is used to determine the cluster usage mode, including either shared or exclusive usage.
[0286] In one feasible implementation, the first information also includes second information, which is used to determine the code corresponding to the target VNF; if the cluster is used exclusively, the transceiver module 1202 is further used to: send a fourth instruction message to the resource manager, which is used to instruct the code corresponding to the target VNF to be downloaded to the worker nodes included in the target runtime cluster based on the second information, and the worker nodes are able to run the target VNF.
[0287] In one feasible implementation, the transceiver module 1202 is further configured to: receive the correspondence between the target runtime cluster and the target VNF from the orchestrator before receiving the instance trigger message of the target VNF.
[0288] In one feasible implementation, the processing module 1201 is further configured to: detect whether the execution task corresponding to the target VNF instance has been completed; if it is determined that the execution task corresponding to the target VNF instance has been completed, then delete the target VNF instance.
[0289] In one feasible implementation, the transceiver module 1202 is further configured to: receive a fifth instruction message from the orchestrator, the fifth instruction message being used to instruct the deinstantiation of the target VNF; the processing module 1201 is further configured to: deinstantiate the target VNF based on the fifth instruction message; remove the correspondence between the target VNF and the target runtime cluster; delete the target runtime cluster when there is no corresponding VNF in the target runtime cluster; the transceiver module 1202 is further configured to: send a second response message to the orchestrator.
[0290] In a second instance, the communication device can function as a second device or a chip within a second device, and execute the steps performed by the resource manager in embodiments one through six of the above method. The transceiver module 1202 supports communication between the trigger and the VNF manager or orchestrator, etc. The processing module 1201 can be used to support actions performed by the trigger in the above method embodiments, other than sending and receiving.
[0291] Specifically, when the processing module 1201 captures the instance triggering event of the target VNF, the transceiver module 1202 is used to: send the instance triggering message of the target VNF to the VNF manager so that the VNF manager can determine the target runtime cluster corresponding to the target VNF based on the instance triggering message, and instantiate the target VNF based on the target runtime cluster, wherein the target runtime cluster satisfies a first condition, the first condition including the necessary conditions on which the target VNF depends for operation.
[0292] In one feasible implementation, the trigger is pre-configured with the identifier of the target runtime cluster and the maximum number of fast-start instances of the target VNF. If it is determined that the number of instances running in the current target runtime cluster is less than the maximum number of fast-start instances, the instance trigger message carries the identifier of the target runtime cluster; if it is determined that the number of instances running in the current target runtime cluster is greater than or equal to the maximum number of fast-start instances, the instance trigger message does not carry the identifier of the target runtime cluster.
[0293] In a third example, the communication device can function as a third device or a chip within a third device, and execute the steps performed by the orchestrator in embodiments 1 to 6 of the above methods. The transceiver module 1202 supports communication between the orchestrator and the VNF manager, triggers, or resource manager. The processing module 1201 can be used to support actions performed by the orchestrator in the above method embodiments, excluding sending and receiving.
[0294] Specifically, the transceiver module 1202 is used to: receive first information, the first information being used to determine a first condition, the first condition including necessary conditions upon which the target VNF depends for operation; the processing module 1201 is used to: determine the target runtime cluster that meets the first condition from the existing runtime clusters based on the first information; establish a correspondence between the target runtime cluster and the target VNF; the transceiver module 1202 is also used to: send the correspondence between the target runtime cluster and the target VNF to the VNF manager.
[0295] In one feasible implementation, the transceiver module 1202 is also configured to: send first information to the VNF manager.
[0296] In one feasible implementation, the transceiver module 1202 is further configured to: upon receiving a first authorization request from the VNF manager, interact with the resource manager to enable the resource manager to allocate a target node from the target runtime cluster, and after completing the allocation of the target node, send a first authorization response to the VNF manager to authorize the VNF manager to use the target node in the target runtime cluster.
[0297] In one feasible implementation, the transceiver module 1202 is further configured to: upon receiving a second authorization request from the VNF manager, interact with the resource manager so that the resource manager creates a target runtime cluster based on the first information, and after completing the creation of the target runtime cluster, send a second authorization response to the VNF manager authorizing the use of the target runtime cluster, the second authorization response may also include the identifier of the target runtime cluster.
[0298] Furthermore, a processor may include a controller, an arithmetic logic unit (ALU), and registers. For example, the controller is primarily responsible for instruction decoding and issuing control signals for the operations corresponding to the instructions. The ALU is primarily responsible for performing fixed-point or floating-point arithmetic operations, shift operations, and logical operations, and can also perform address operations and translations. Registers are primarily responsible for storing register operands and intermediate operation results temporarily stored during instruction execution. In specific implementations, the processor's hardware architecture can be an ASIC architecture, a microprocessor without interlocked piped stages architecture (MIPS), an advanced reduced instruction set machine (RISC) machine (ARM) architecture, or a network processor (NP) architecture, etc. The processor can be single-core or multi-core.
[0299] The storage module can be an internal storage module of the chip, such as a register or cache. Alternatively, the storage module can be an external storage module, such as ROM or other types of static storage devices that can store static information and instructions, such as RAM.
[0300] It should be noted that the functions of the processor and interface can be implemented through hardware design, software design, or a combination of both; no restrictions are imposed here.
[0301] Furthermore, it should be noted that the aforementioned transceiver unit and / or processing unit can be implemented through virtual modules. For example, the processing unit can be implemented through software functional units or virtual devices, and the transceiver unit can be implemented through software functions or virtual devices. Alternatively, the processing unit or transceiver unit can also be implemented through physical devices. For example, if the device is implemented using a chip / chip circuit, the transceiver unit can be an input / output circuit and / or a communication interface, performing input operations (corresponding to the aforementioned receiving operation) and output operations (corresponding to the aforementioned sending operation); the processing unit is an integrated processor, microprocessor, or integrated circuit.
[0302] Figure 13 is a schematic diagram of another communication device provided in an embodiment of this application. As shown in Figure 13, the communication device may include one or more of the following components: a processor 1301, a memory 1302, and a communication interface 1303. The processor 1301, the memory 1302, and the communication interface 1303 are interconnected and perform communication between them. The memory 1302 may store one or more computer programs, which may be configured to implement the methods described in the above embodiments when executed by one or more processors 1301.
[0303] Processor 1301 may include one or more processing cores. Processor 1301 connects to various parts of the communication device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 1302, and by calling data stored in memory 1302. Optionally, processor 1301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 1301 may integrate one or more of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. It is understood that the aforementioned modem may also not be integrated into processor 1301, but may be implemented separately through a communication chip.
[0304] The memory 1302 may include random access memory (RAM) or read-only memory (ROM). The memory 1302 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1302 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may also store data created during the use of the communication device.
[0305] It is understood that the communication device may include more or fewer structural elements than those shown in the block diagram above.
[0306] This application provides a communication system, which includes a first device corresponding to a VNF manager, a second device corresponding to a trigger, and a third device corresponding to an orchestrator.
[0307] This application provides a computer-readable storage medium storing computer instructions that, when executed, cause the computer to perform any of the methods described above.
[0308] This application provides a computer program product, which includes computer program code. When the computer program code is run, it causes the computer to perform any of the methods described above.
[0309] This application provides a chip coupled to a memory for reading and executing program instructions in the memory, so that the device in which the chip is located implements any of the methods described above.
[0310] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a particular embodiment can be found in the relevant descriptions of other embodiments. It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0311] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.
[0312] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0313] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A VNF instantiation method, characterized in that, The method is applied to a VNF manager, and the method includes: Receive instance trigger message from the target virtualized network function (VNF) of the trigger; Based on the instance trigger message, the target runtime cluster corresponding to the target VNF is determined, and the target runtime cluster satisfies a first condition, which includes the necessary conditions on which the target VNF depends for operation; The target VNF is instantiated based on the target runtime cluster.
2. The method of claim 1, wherein, The instance trigger message carries an identifier corresponding to the target runtime cluster. Determining the target runtime cluster corresponding to the target VNF based on the instance trigger message includes: The target runtime cluster corresponding to the target VNF is determined based on the identifier corresponding to the target runtime cluster.
3. The method according to claim 1 or 2, characterized in that, The instantiation of the target VNF based on the target runtime cluster includes: Send a first instruction message to the resource manager, the first instruction message being used to instruct the allocation of a target node from the target runtime cluster, the first instruction message carrying the identifier of the target runtime cluster; Instantiate the target VNF based on the target node.
4. The method according to claim 1 or 2, characterized in that, The instantiation of the target VNF based on the target runtime cluster includes: Based on the instance trigger message, a first authorization request is sent to the orchestrator. The first authorization request is used to request authorization for the VNF manager to use the nodes in the target runtime cluster. Receive a first authorization response from the orchestrator, the first authorization response being used to authorize the VNF manager to use the target node in the target runtime cluster; Instantiate the target VNF based on the target node.
5. The method according to claim 3 or 4, characterized in that, The method further includes: Determine the maximum number of fast-start instances for the target VNF; If it is determined that the number of instances running in the target runtime cluster is less than the maximum number of fast-start instances, the method described in claim 3 or 4 shall be executed.
6. The method according to claim 3 or 4, characterized in that, The method further includes: When it is determined that the instance trigger message carries an identifier corresponding to the target runtime cluster, the method described in claim 3 or 4 is executed. The prerequisite for the instance trigger message to carry the identifier corresponding to the target runtime cluster is that the trigger determines that the number of instances currently running in the target runtime cluster is less than the maximum number of fast-start instances of the target VNF.
7. The method of claim 5, wherein, The instantiation of the target VNF based on the target runtime cluster includes: When it is determined that the number of instances running in the target runtime cluster is greater than or equal to the maximum number of fast-start instances, a second instruction message is sent to the resource manager, the second instruction message being used to instruct the request for a new target node; Instantiate the target VNF based on the target node.
8. The method of claim 6, wherein, The method further includes: When it is determined that the instance trigger message does not carry the identifier corresponding to the target runtime cluster, a second instruction message is sent to the resource manager, the second instruction message being used to instruct the request of a new target node; Instantiate the target VNF based on the target node; The prerequisite for the instance trigger message not carrying the identifier corresponding to the target runtime cluster is that the trigger determines that the number of instances currently running in the target runtime cluster is greater than or equal to the maximum number of fast-start instances of the target VNF.
9. The method of claim 1, wherein, Before receiving the instance trigger message from the target VNF of the trigger, the method further includes: Receive a first request instruction from the orchestrator, the first request instruction being used to request the creation of an identifier for the target VNF; Receive first information from the orchestrator, the first information being used to determine the first condition; The target runtime cluster is determined from the existing runtime clusters based on the first condition; Establish the correspondence between the target runtime cluster and the target VNF; A first response instruction is sent to the orchestrator, the first response instruction being used to notify that the creation of the identifier for the target VNF is complete.
10. The method of claim 9, wherein, The first condition also includes a maximum number of fast-start instances N, and the target runtime cluster includes at least M worker nodes, wherein the M worker nodes are capable of running N target VNF instances.
11. The method according to claim 9 or 10, characterized in that, Before establishing the correspondence between the target runtime cluster and the target VNF, the method further includes: If there is no existing runtime cluster that meets the first condition, a third instruction message is sent to the resource manager, which instructs the creation of the target runtime cluster based on the first information.
12. The method according to claim 9 or 10, characterized in that, Before establishing the correspondence between the target runtime cluster and the target VNF, the method further includes: If there is no runtime cluster in the existing runtime cluster that meets the first condition, a second authorization request is sent to the orchestrator. The second authorization request is used to request the orchestrator to instruct the resource manager to create the target runtime cluster according to the first information and authorize the VNF manager to use the target runtime cluster. Receive a second authorization response from the orchestrator, the second authorization response being used to authorize the VNF manager to use the target runtime cluster.
13. The method according to any one of claims 9-12, characterized in that, The first information also includes third information, which is used to determine the cluster usage mode, which includes either shared or exclusive usage.
14. The method of claim 13, wherein, The first information also includes second information, which is used to determine the code corresponding to the target VNF. If the cluster usage mode is exclusive, then after establishing the correspondence between the target runtime cluster and the target VNF, the method further includes: A fourth instruction message is sent to the resource manager, the fourth instruction message being used to instruct the code corresponding to the target VNF to be downloaded to the worker nodes included in the target runtime cluster based on the second information, the worker nodes being capable of running the target VNF.
15. The method of claim 1, wherein, Before receiving the instance trigger message of the target VNF, the method further includes: Receive the mapping between the target runtime cluster and the target VNF from the orchestrator.
16. The method according to any one of claims 1 to 15, characterized in that, After sending the first instruction information to the resource manager, the method further includes: Detect whether the execution task corresponding to the target VNF instance has been completed; If it is determined that the task corresponding to the target VNF instance has been completed, then the target VNF instance is deleted.
17. The method according to any one of claims 1 to 16, characterized in that, After sending the first instruction information to the resource manager based on the instance trigger message, the method further includes: Receive a fifth instruction from the orchestrator, the fifth instruction being used to instruct the deinstantiation of the target VNF; Deinstantiate the target VNF based on the fifth instruction information; Remove the mapping between the target VNF and the target runtime cluster; If the target runtime cluster does not have a corresponding VNF, delete the target runtime cluster; Send the second response information to the orchestrator.
18. A VNF instantiation method, comprising: The method is applied to a trigger, and the method includes: When a VNF instance trigger event is captured, an instance trigger message for the target VNF is sent to the VNF manager, so that the VNF manager determines the target runtime cluster corresponding to the target VNF based on the instance trigger message, and instantiates the target VNF based on the target runtime cluster. The target runtime cluster satisfies a first condition, which includes the necessary conditions on which the target VNF depends for operation.
19. The method of claim 18, wherein, The trigger is pre-configured with the identifier of the target runtime cluster and the maximum number of fast-start instances of the target VNF, wherein, If it is determined that the number of instances running in the target runtime cluster is less than the maximum number of fast-start instances, then the instance trigger message carries the identifier of the target runtime cluster. If it is determined that the number of instances running in the target runtime cluster is greater than or equal to the maximum number of fast-start instances, then the instance trigger message does not carry the identifier of the target runtime cluster.
20. A communications device, characterized by Includes units or modules for implementing the method as described in any one of claims 1 to 19.
21. A communications device, the device comprising a processor, a memory, and a computer program stored on the memory, wherein, The processor is configured to retrieve the executable program code computer program stored in the memory to perform the method as described in any one of claims 1-19.
22. A computer readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-19.
23. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-19.
24. A chip, characterized by The chip is coupled to a memory for reading and executing program instructions stored in the memory to implement the method as described in any one of claims 1-17, or to implement the method as described in claim 18 or 19.