Method and device for deploying virtual machine and container

Abstract

The embodiment of the invention discloses a method and device for deploying a virtual machine and a container. The method and device are used for achieving container deployment and VM deployment in an MEC system. The method comprises the steps that a unified arrangement function entity receives a deployment request, and according to the deployment request, the deployment mode of an application program is determined to be container deployment or VM deployment; further, if the deployment mode of the application program is container deployment, the unified arrangement function entity sends a first resource allocation request to the architecture manager, and the architecture manager is requested to deploy a container capable of running an instance of the application program; and if the deployment mode of the application program is VM deployment, sending a second resource allocation request to the VIM, and requesting the VIM to deploy a VM capable of running an instance of the application program.

Description

[0001] This application is a divisional application. The application number of the original application is 201910224223.9, and the original application date is March 22, 2019. The entire content of the original application is incorporated into this application by reference. Technical Field

[0002] The embodiments of the present application relate to the field of computer technology, and more particularly to a method and apparatus for deploying virtual machines and containers. Background Art

[0003] With the development of computer technology and communication technology, multi-access edge computing (MEC) has become the fifth generation (5 th MEC is a key technology for 5G (5G) mobile networks. Located at the edge of the network, most business data sent by users can be filtered and processed by the MEC system before being uploaded to the cloud, improving data processing speed and transmission reliability.

[0004] Currently, in MEC systems, application instances can only be deployed through virtual machines (VMs). However, with the development of communication technologies, the need for hybrid deployment of VMs and containers in MEC systems has emerged, allowing application instances to be deployed through either container or VM deployment.

[0005] In existing technologies, Kubernetes is the most popular container management platform and is suitable for most container scenarios. However, in MEC systems, due to the limited resource usage of edge nodes, Kubernetes cannot meet the resource usage requirements of edge nodes in MEC systems, and Kubernetes cannot be used for container deployment in MEC systems. Summary of the Invention

[0006] The embodiments of the present application provide a method and apparatus for deploying virtual machines and containers to implement deployment of VMs and containers in an MEC system.

[0007] To achieve the above objectives, the present invention adopts the following technical solutions:

[0008] In a first aspect, an embodiment of the present application provides a method for deploying virtual machines and containers, the method comprising: a unified orchestration functional entity receives a deployment request for requesting deployment of an instance of an application, the deployment request including an identification ID of the application and orchestration information, the orchestration information being used to indicate resources required to run the instance of the application, the unified orchestration functional entity determining, based on the deployment request, whether the deployment mode of the application is container deployment or virtual machine (VM) deployment, so that the unified orchestration functional entity requests the VIM or CIM to deploy a VM or container capable of running the instance of the application according to the determined deployment mode.

[0009] Based on the method described in the first aspect, after the unified orchestration functional entity receives a request to deploy an application, it can analyze and process the received deployment request, and determine the deployment method (container deployment or VM deployment) of the instance of the deployed application based on the content included in the deployment request, so that the unified orchestration functional entity can send a resource allocation request to the VIM or CIM according to the determined deployment method, requesting the use of container deployment to deploy the resources required for the application, or send a resource allocation request to the VIM, requesting the use of VM deployment to deploy the resources required for the application, and complete the VM deployment of the application, so that both VM deployment and container deployment can be achieved in the MEC system.

[0010] In a first possible design, in combination with the first aspect, the method further includes: if the application is deployed as a container, the unified orchestration function entity sends a first resource allocation request to the architecture manager for requesting resources required for deploying a container capable of running an instance of the application; or, if the application is deployed as a VM, the unified orchestration function entity sends a second resource allocation request to the VIM for requesting resources required for deploying a VM capable of running an instance of the application.

[0011] Based on this possible design, when deploying a container, a first resource allocation request can be sent to the architecture manager, requesting the architecture manager to allocate container resources that can run an instance of the application; or, when deploying a VM, a second resource allocation request can be sent to the VIM, requesting the VIM to allocate VM resources that can run an instance of the application. In this way, both container deployment and VM deployment can be achieved.

[0012] In a second possible design, in combination with the first aspect or the first possible design of the first aspect, a correspondence exists between the application ID and the application deployment method, and the unified orchestration functional entity determines the application deployment method based on the deployment request, including: the unified orchestration functional entity determines the application deployment method based on the application ID and the correspondence. Based on this possible design, the ID used to identify the application and the application deployment method can be associated, and the application deployment method can be determined based on this correspondence, which is simple and easy.

[0013] In a third possible design, in combination with the first aspect or the first possible design of the first aspect, the deployment request also includes a deployment type identifier, which is used to identify the deployment method of the application. The unified orchestration functional entity determining the deployment method of the application based on the deployment request includes: the unified orchestration functional entity determining the deployment method of the application based on the deployment type identifier. Based on this possible design, a deployment type identifier for identifying the deployment method of the application can be added to the orchestration information, and the deployment type identifier explicitly indicates the deployment method of the application, which is simple and easy to implement.

[0014] It should be noted that the deployment type identifier may be included in a new information element in the deployment request, or may be included in the orchestration information included in the deployment request, without limitation.

[0015] In a fourth possible design, in combination with any of the first possible design to the third possible design of the first aspect, the method further includes: the unified orchestration function entity receiving a first resource allocation response from the architecture manager. Based on this possible design, after allocating the container resources, the first resource allocation response can be returned to the unified orchestration function entity so that the unified orchestration function entity is informed that the container resources have been successfully allocated to the application instance.

[0016] In a fifth possible design, in combination with any one of the first possible design to the third possible design of the first aspect, the method further includes: the unified orchestration function entity receiving a second resource allocation response from the VIM. Based on this possible design, after allocating VM resources, the first resource allocation response can be returned to the unified orchestration function entity, so that the unified orchestration function entity is informed that VM resources have been successfully allocated to the application instance.

[0017] In a sixth possible design, in combination with the first aspect or any possible design of the first aspect, the method further includes: the unified orchestration function entity sending a configuration request to the MEP, wherein the configuration request is used to request the MEP to configure traffic rules and DNS rules to be followed by the instance of the application. Based on this possible design, the MEP can be requested to specify the rules to be followed by the instance of the application, so that the instance of the application can be run according to the rules configured by the MEP.

[0018] In a seventh possible design, in combination with the first aspect or any possible design of the first aspect, the method further includes: the unified orchestration function entity sending a response to the deployment request, wherein the response to the deployment request indicates the successful deployment of the application instance, and the response to the deployment request includes the application ID. Based on this possible design, after the application instance is successfully deployed, the response to the deployment request may be sent to the requestor who requested the deployment of the application instance, so that the requestor is informed of the successful deployment of the application instance.

[0019] In an eighth possible design, in combination with the first aspect or any possible design of the first aspect, the method further includes: the unified orchestration function entity receiving a termination request; the termination request including an application ID, the termination request being used to terminate the instance of the application; if the application is deployed as a container, the unified orchestration function entity sending a first resource deletion request to the architecture manager, wherein the first resource deletion request may be used to request the architecture manager to delete resources occupied by the instance of the application; or, if the application is deployed as a VM, the unified orchestration function entity sending a second resource deletion request to the VIM, wherein the first resource deletion request may be used to request the VIM to delete resources occupied by the instance of the application. Based on this possible design, after receiving the termination request to terminate the instance of the application, the unified orchestration function entity may perform corresponding termination processing based on the deployment mode of the application, such as: if the deployment mode is container, sending the first resource deletion request to the architecture manager, requesting the architecture manager to delete the resources occupied by the instance of the application; or, if the deployment mode is VM, sending the second resource deletion request to the VIM, requesting the VIM to delete the resources occupied by the instance of the application. In this manner, the architecture manager or VIM may be requested to delete the instance of the application when the application instance is no longer needed.

[0020] A ninth possible design, in combination with the first aspect or any possible design of the first aspect, unifies the orchestration functional entity into an MEPM or MEO. Based on this possible design, the method for deploying VMs and containers provided in the embodiments of the present application can be executed by the MEPM or MEO, thereby improving execution flexibility.

[0021] In a tenth possible design, in combination with the first aspect or any possible design of the first aspect, the architecture manager is a VIM or a CIM. Based on this possible design, an existing functional entity, such as a VIM, can perform the container deployment function in the embodiments of the present application, or a newly added functional entity, a CIM, can perform the container deployment process provided in the embodiments of the present application.

[0022] In a second aspect, the present application provides a communication device, which may be a unified orchestration functional entity or a chip or system-on-chip in the unified orchestration functional entity, wherein the unified orchestration functional entity is an MEPM or MEO, and may implement the functions performed by the unified orchestration functional entity in the above-mentioned aspects or possible designs. The functions may be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions. For example, the communication device may include: a unified orchestration scheduling management module;

[0023] The unified orchestration and scheduling management module is used to receive deployment requests and determine the deployment method of the application based on the deployment request. The deployment request is used to request the deployment of an instance of the application. The deployment request includes the application's identification ID and orchestration information. The orchestration information is used to indicate the resources required to deploy the instance of the application. The application deployment method includes container deployment or virtual machine VM deployment.

[0024] Furthermore, the unified orchestration functional entity also includes:

[0025] a container orchestration management module configured to send a first resource allocation request to the architecture manager if the unified orchestration scheduling management module determines that the application is deployed in a container, wherein the first resource allocation request is used to request resources required to deploy a container capable of running an instance of the application;

[0026] The virtual machine VM scheduling management module is used to send a second resource allocation request to the virtualization infrastructure manager VIM if the unified orchestration scheduling management module determines that the deployment mode of the application is VM deployment, wherein the second resource allocation request is used to request the resources required for deploying the VM that can run the instance of the application.

[0027] The specific implementation of the communication device can refer to the unified orchestration of the behavior of the functional entity in the method for deploying virtual machines and containers provided in the first aspect or any possible design of the first aspect, and will not be repeated here. Therefore, the provided communication device can achieve the same beneficial effects as the first aspect or any possible design of the first aspect.

[0028] In a third aspect, a communication device is provided, comprising: a processor and a memory; the memory is used to store computer-executable instructions, and when the communication device is running, the processor executes the computer-executable instructions stored in the memory, so that the communication device performs the method of deploying virtual machines and containers as described in the first aspect or any possible design of the first aspect.

[0029] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium is a non-volatile readable storage medium. The computer-readable storage medium stores instructions that, when executed on a computer, enable the computer to perform the method for deploying virtual machines and containers described in the first aspect or any possible design of the above aspects.

[0030] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the method for deploying virtual machines and containers as described in the first aspect or any possible design of the above aspects.

[0031] In the sixth aspect, a chip system is provided, which includes a processor and a communication interface, which are used to support the chip system to implement the functions involved in the above aspects, such as the processor receiving a deployment request through the communication interface, and determining the deployment method of the application based on the deployment request, wherein the deployment request is used to request the deployment of an instance of the application, and the deployment request includes the identification ID and orchestration information of the application, and the orchestration information is used to indicate the resources required to deploy the instance of the application; the deployment method of the application includes container deployment or virtual machine VM deployment. In one possible design, the chip system also includes a memory, which is used to store program instructions and data necessary for the communication device. The chip system can be composed of chips, or it can include chips and other discrete devices.

[0032] Among them, the technical effects brought about by any design method in the third to sixth aspects can refer to the technical effects brought about by the above-mentioned first aspect or any possible design of the first aspect, and will not be repeated here.

[0033] In the seventh aspect, an embodiment of the present application provides an MEC system, including the unified orchestration functional entity and the virtualization infrastructure manager VIM as described in aspects 2 to 6; or, including the unified orchestration functional entity, VIM and CIM as described in aspects 2 to 6. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 A schematic diagram of the architecture of an MEC system provided in an embodiment of the present application;

[0035] Figure 2A schematic diagram of the architecture of another MEC system provided in an embodiment of the present application;

[0036] Figure 3 A flowchart of a method for deploying virtual machines and containers provided in an embodiment of the present application;

[0037] Figure 4 A flowchart of a method for terminating an application instance provided in an embodiment of the present application;

[0038] Figure 5a A flowchart of another method for deploying virtual machines and containers provided in an embodiment of the present application;

[0039] Figure 5b A flowchart of another method for deploying virtual machines and containers provided in an embodiment of the present application;

[0040] Figure 6a A flowchart of a method for terminating an application instance provided in an embodiment of the present application;

[0041] Figure 6b A flowchart of another method for terminating an instance of an application provided in an embodiment of the present application;

[0042] Figure 7a A flow chart of a method for onboard application provided in an embodiment of the present application;

[0043] Figure 7b A flowchart of a method for querying an application provided in an embodiment of the present application;

[0044] Figure 7c A flowchart of a method for enabling an application provided in an embodiment of the present application;

[0045] Figure 7d A flowchart of a method for disabling an application provided in an embodiment of the present application;

[0046] Figure 7e A flowchart of a method for deleting an application provided in an embodiment of the present application;

[0047] Figure 8 A schematic diagram of the composition of a unified orchestration functional entity provided in an embodiment of the present application;

[0048] Figure 9 A schematic diagram of the composition of an MEC system provided in an embodiment of the present application;

[0049] Figure 10 A schematic diagram of another MEC system composition provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The following describes in detail the implementation of the embodiment of the present application in conjunction with the accompanying drawings.

[0051] In one example, in order to realize that both VM and container can be deployed in the MEC system, the function of the existing network element in the MEC system can be enhanced so that the network element supports the management of containers (such as deployment, deletion, etc.). For example, the VIM in the MEC system can be enhanced so that the VIM supports the virtualization management of VM and also has the function of supporting the management of containers, so that both VM and container can be deployed in the MEC system. Specifically, the enhanced MEC system can refer to Figure 1 shown.

[0052] Figure 1 This is a schematic diagram of the architecture of a MEC system provided in an embodiment of the present application, such as Figure 1 As shown in the figure, the MEC system can include two major levels: the mobile edge host level and the mobile edge system level. The mobile edge host level can include: multiple mobile edge hosts (mobile edge hosts), a mobile edge platform manager (MEPM), and a virtualization infrastructure manager (VIM). The mobile edge system level can include: a customer facing service portal (CFS portal), terminals, a user app lifecycle management agent (user app LCM proxy), an operations support system, and a mobile edge orchestrator / orchestrator (MEO).

[0053] A mobile edge host, which can be a physical host, is primarily used to provide computing, storage, and network resources for mobile edge applications. A mobile edge host can include a mobile edge platform (ME platform), multiple mobile edge applications (ME apps), and a virtualization infrastructure (VI).

[0054] The mobile edge platform (MEP) is mainly used to provide mobile edge services (mobile edge services) and intermediary services for mobile edge applications, such as providing services for discovery and use between mobile edge applications.

[0055] Mobile edge applications can include applications running on virtual machines (VMs) within a virtualized infrastructure, or applications running in containers. Mobile edge applications can interact with the mobile edge platform to provide mobile edge services and to perform processes related to the mobile edge application lifecycle, such as indicating the mobile edge application's availability and relocating user status. Furthermore, mobile edge applications also have a number of associated rules and requirements, such as required resources, maximum latency, and required or useful services.

[0056] The Mobile Edge Platform Manager (MEPM) has the following main functions: managing the life cycle of mobile edge applications, such as notifying the mobile edge coordinator / orchestrator of relevant events of mobile edge applications; providing element management functions for the mobile edge platform; managing the rules and requirements of mobile edge applications, such as managing service authorization, traffic rules, domain name system (DNS) configuration and conflict resolution for mobile edge applications.

[0057] The Virtualization Infrastructure Manager (VIM) supports virtualization management of VMs and containers, and has two main functions: first, allocating, managing, and releasing virtualized resources (such as computing, storage, and network resources) on the virtualization infrastructure; preparing the virtualization infrastructure for running software images, such as configuring the virtualization infrastructure, receiving and storing software images, etc.; rapidly configuring mobile edge applications, such as collecting and reporting performance and fault information of virtualized resources; and performing mobile edge program relocation. Second, allocating, managing, and releasing container-related resources (such as computing, storage, and network resources); receiving and storing container images; supporting rapid configuration of mobile edge applications, and collecting and reporting performance and fault information of container-related resources.

[0058] The mobile edge coordinator / orchestrator MEO is a core functional component at the mobile edge system level. Its main functions are as follows: maintaining the overall view resources, available mobile edge services and topology of the mobile edge system based on the deployment of mobile edge hosts; selecting appropriate mobile edge hosts to provide available resources and available services for mobile edge application instantiation based on constraints (such as the latency of mobile edge applications); triggering the instantiation or termination of mobile edge applications; triggering the relocation of mobile edge applications; managing the container resources of mobile edge hosts, such as tracking the available resource capacity of containers and managing container images.

[0059] The operations support system, which can be the operator's OSS, receives requests from the CFS portal (or terminal application) to instantiate or terminate applications and forwards the received requests to the mobile edge coordinator / orchestrator, which then executes subsequent processes based on the requests.

[0060] A terminal may be referred to as terminal equipment (UE), user equipment (UE), mobile station (MS), or mobile terminal (MT), and an application (APP) icon may be provided on the terminal. Specifically, the terminal may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, personal computer (PC), netbook computer, cellular phone, personal digital assistant (PDA), wearable device (such as a smart watch), smart home device, or vehicle-mounted computer. This embodiment does not impose any special restrictions on the specific form of the device.

[0061] exist Figure 1 In the MEC system shown, mobile edge hosts and components within them can communicate with each other through the mobile edge platform interface (mobile edge point, Mp). Mobile edge hosts and other devices in the MEC system can communicate with each other through mobile edge management (mobile edge management, Mm). Devices other than mobile edge hosts in the MEC system can also communicate with each other through the Mm interface. Devices in the MEC system can communicate with terminals or CFS portals through interfaces with external entities (e.g., Mx interfaces).

[0062] For example, Figure 1As shown, the mobile edge platform and the mobile edge application can communicate with each other through Mp1, the mobile edge platform and the data plane in the virtualized infrastructure can communicate with each other through Mp2, and the mobile edge hosts can communicate with each other through Mp3.

[0063] The OSS and the mobile edge coordinator / orchestrator can communicate through Mm1, and the OSS and the mobile edge platform manager can communicate through Mm2. The mobile edge coordinator / orchestrator and the mobile edge platform manager can communicate through Mm3, and the mobile edge coordinator / orchestrator and the virtualized infrastructure manager can communicate through Mm4. The mobile edge platform manager and the mobile edge platform can communicate through Mm5, and the mobile edge platform manager and the virtualized infrastructure manager can communicate through Mm6. The virtualized infrastructure manager and the virtualized infrastructure can communicate through Mm7. The user application lifecycle management agent and the OSS can communicate through Mm8, and the user application lifecycle management agent and the mobile edge coordinator / orchestrator can communicate through Mm9. The CFS portal and the OSS can communicate through Mx1. The CFS portal can send requests from third parties to the OSS through Mx1. The terminal and the user application lifecycle management agent can communicate with each other through Mx2. The app on the terminal can send a request to the user application lifecycle management agent through Mx2 to request to run the mobile edge application or move the mobile edge application into / out of the mobile edge system.

[0064] It should be pointed out that Figure 1 The accompanying drawings are for illustrative purposes only. Figure 1 The number of network elements included in the MEC system shown is unlimited, except Figure 1 In addition to the network elements shown, the MEC system may also include other devices. Figure 1 The names of the devices and interfaces between devices are not restricted, except Figure 1 In addition to the names shown, each device and the interfaces between devices can be named with other names without restriction.

[0065] In another example, in order to realize that both VM and container can be deployed in MEC system, a new functional entity for deploying container can be added in MEC system, so that the new functional entity supports container management (such as deployment, deletion, etc.) to realize the deployment of container in MEC system. Figure 2 shown.

[0066] like Figure 2 As shown in FIG, another schematic diagram of the architecture of the MEC system provided in the embodiment of the present application is shown in FIG. Figure 2As shown, the MEC system may include: a mobile edge host level and a mobile edge system level. The mobile edge host level may include: multiple mobile edge hosts, a mobile edge platform manager (MEPM), a virtualization infrastructure manager (VIM), and a container infrastructure manager (CIM). The mobile edge system level may include: a CFS portal, terminals, a user app LCM proxy, an operations support system, and a mobile edge orchestrator / orchestrator (MEO).

[0067] in, Figure 2 The relevant functions of MEO, MEPM, VIM and other functional entities in the MEC system shown can be referred to Figure 1 It has been described in , so I will not repeat it here.

[0068] in, Figure 2 The mobile edge host in this context can be a physical host that primarily provides computing, storage, and network resources for mobile edge applications. The mobile edge host can include a mobile edge platform (ME platform), multiple mobile edge applications (ME apps), virtualization infrastructure (VI), and container infrastructure (CI). CI has the functionality of a container engine, such as a Docker engine.

[0069] in, Figure 2 The CIM shown can support container management. Its main functions are as follows: allocate, manage, and release container-related resources (such as computing, storage, and network resources); receive and store container images; support rapid configuration of mobile edge applications, and collect and report performance and fault information of container-related resources. It should be noted that CIM can be deployed independently from VIM. Figure 2In the MEC system shown in the figure, it can also be centrally deployed in the same functional entity without limitation. This application example only uses CIM and VIM to be independently deployed in Figure 2 The MEC system shown is used as an example for description.

[0070] and Figure 1 Similar, in Figure 2 In the MEC system shown, the mobile edge hosts and the components within the mobile edge hosts can communicate with each other through the mobile edge platform interface (mobile edge point, Mp), the mobile edge hosts and other devices in the MEC system can communicate with each other through the mobile edge management (mobile edge management, Mm), and other devices in the MEC system except the mobile edge hosts can also communicate with each other through the Mm interface. Devices and terminals or CFS portals in the MEC system can communicate with each other through interfaces with external entities (such as: Mx interface). For specific interfaces, please refer to Figure 2 As described in.

[0071] It should be pointed out that Figure 2 The accompanying drawings are for illustrative purposes only. Figure 2 The number of network elements included in the MEC system shown is unlimited, except Figure 2 In addition to the network elements shown, the MEC system may also include other devices. Figure 2 The names of the devices and interfaces between devices are not restricted, except Figure 2 In addition to the names shown, each device and the interfaces between devices can be named with other names without restriction.

[0072] The following is based on Figure 1 or Figure 2 The MEC system shown describes the method provided in the embodiment of the present application.

[0073] Figure 3 A method for deploying virtualization and containers is provided in an embodiment of the present application, such as Figure 3 As shown, the method may include steps 301 to 308:

[0074] Step 301: The unified orchestration function entity receives a deployment request.

[0075] The unified orchestration functional entity may be a MEO or a chip or system-on-chip in the MEO that can implement the functions performed by the unified orchestration functional entity in the embodiment of the present application. It may also be a MEPM or a chip or system-on-chip in the MEPM that can implement the functions performed by the unified orchestration functional entity in the embodiment of the present application. Alternatively, the unified orchestration functional entity may include multiple functional modules for executing the methods described in the embodiments of the present application, some of these multiple functional modules are located in the MEO, and the remaining modules are located in the MEPM, without limitation. The embodiments of the present application are described only by taking the unified orchestration functional entity as a MEO or MEPM as an example.

[0076] The deployment request can be used to request the instantiation and deployment of an application. This application can be a third-party service application (APP), such as QQ Games, large mobile games, or video surveillance programs (face recognition, data analysis, etc.) in the MEC system. The deployment method of this application can include, but is not limited to, VM deployment or container deployment. The application can be uniquely identified by its identity (ID), and the IDs of different applications are different. For example, the application ID can be a unique identifier assigned by the MEO after the application is successfully onboarded to the MEC system.

[0077] Specifically, the deployment request may include but is not limited to the identification (ID) and orchestration information of the application, and may also include other information without limitation. The orchestration information may include resource information required for the instantiation and deployment of the application, such as: the image address of the application, the disk type, the storage volume name, the disk size, etc., and may also include the orchestration type (VM or container), etc. The orchestration information may be of tosca type or of yaml type based on kubernetes. Exemplarily, the orchestration information may include keywords or some special parameters, and the orchestration information may be identified by the keywords or these special parameters.

[0078] For example, taking VM deployment as an example, the orchestration information can be as follows, which can include basic information of the application and storage resources of the application, etc. Among them, the basic information of the application can include basic information of the node, deployment method of the application, storage information, etc. Basic node information can include "node templates (node_templates), software development tools (sdk-appgroud), node type (type: hwpaas.node.Appgroup), requirements (requirements), members (member), node name (node:sdk-app), node relationship (relationship: hwpass.relationships.Consistsof), etc. The application deployment method can include: application package (package), node deployment method (node:sdk-VM), node relationship (relationship: hwpass.relationship.PackageConsistsor). Storage information can include "volume (volume), node system disk (node:system_disk), node relationship (relationship: hwpass.relationship.Attachesto), volume (volume), node (node:data_disk), node relationship (relationship: hwpass.relationship.AttachesTo), etc. The storage resources of an application can include: system disk (system_disk), type (type:hwpaas.nodes.LocalVolume), properties (properties), type (type:local_storage), name (name:test), lvmType:system, volume type (volumeType:high IO), devices (devices: / dev / sdc), volume type (volumeType:"high IO"), size (size:20G), mode (mode:private), stripe (stripe:true), deletion policy (deletePolicy:reserved), etc.

[0079]

[0080]

[0081] In one example, the unified orchestration function entity is Figure 1 or Figure 2Taking MEO in as an example, the unified orchestration function entity receiving the deployment request may include: the unified orchestration function entity receiving the deployment request sent by the OSS through Mm1, wherein the deployment request may be sent to the OSS by the CFS portal or the user app LCM proxy; or, the unified orchestration function entity receiving the deployment request sent by the user app LCM proxy through Mm9, wherein the deployment request may be sent to the user app LCM proxy by the APP on the terminal.

[0082] In another example, the unified orchestration function entity is Figure 1 or Figure 2 Taking MEPM in the example, the unified orchestration function entity receiving the deployment request may include: the unified orchestration function entity receiving the deployment request sent by OSS through Mm2, wherein the deployment request can be sent to OSS by the CFS portal or the user app LCM proxy; or, the unified orchestration function entity receiving the deployment request sent by MEO through Mm3, wherein MEO can obtain the deployment request and send it to MEPM in the above manner, which will not be repeated.

[0083] In another example, when MEO receives a deployment request and forwards it to MEPM, the method may further include: MEO obtains the instance configuration data of the application, and forwards the deployment request to MEPM according to the instance configuration data of the application. The instance configuration data of the application may include information such as which node the instance of the application is deployed on, the deployment method, and the resources required to deploy the instance of the application using such a deployment method (such as computing resources, network resources, and storage resources, etc.). MEO forwards the deployment request to MEPM according to the instance configuration data of the application, which may include: when deploying the instance of the application using the deployment method specified by the instance configuration data of the application, if there is a node in the MEC system where the instance of the application can be deployed and the resources required to deploy the instance of the application, then the deployment request is forwarded to MEPM; otherwise, the deployment request is refused to be forwarded to MEPM.

[0084] Step 302: The unified orchestration function entity determines the deployment mode of the application program according to the deployment request.

[0085] In one example, the deployment request includes orchestration information. The type of orchestration information is different for different deployment modes. For example, when the application is deployed in a VM, the orchestration information can be of the tosca type. When the application is deployed in a container, the orchestration information can be of the yaml type.

[0086] After receiving a deployment request, the unified orchestration function entity parses the request, obtains the orchestration information included in the deployment request, and determines the application deployment method based on the type of orchestration information. For example, if the orchestration information is of the tosca type, the application is determined to be deployed as a VM; if the orchestration information is of the yaml type, the application is determined to be deployed as a container.

[0087] The unified orchestration function entity may determine the type of the orchestration information using keywords included in the orchestration information. For example, if the orchestration information includes the orchestration type (VM or container), if the orchestration type is VM, the orchestration information is determined to be of the tosca type, and the application deployment method is VM deployment. Conversely, if the orchestration type is container, the orchestration information is determined to be of the yaml type, and the application deployment method is container deployment.

[0088] In another example, the deployment request may include a deployment type identifier, which can be used to indicate the deployment method of the application. After the unified orchestration function entity receives the deployment request, it can parse the deployment request and determine the deployment method of the application based on the deployment type identifier included in the deployment request.

[0089] Among them, the deployment type identifier can be a binary bit number, such as: 0 or 1, "0" represents VM deployment, "1" represents container deployment, and can also be other identifiers (identity) used to indicate the deployment method of the application, such as: it can be an identifier composed of any form of information such as numbers, letters, symbols, etc., which is easy for users to understand, etc., without limitation.

[0090] It should be noted that the deployment type identifier can be included in a newly added information element in the deployment request, or can be included in the orchestration information included in the deployment request, without limitation. In addition to the orchestration information and the deployment type identifier, the deployment request can also include other information.

[0091] For example, Table 1 below shows the content included in a deployment request. As shown in Table 1, the deployment request may compulsorily include a deployment type identifier (or deployment method), an application instance ID (or application ID), virtual storage information (virtual storage desciptor), and mobile edge host information (selected ME HostInfo). Optionally, it may also include a virtual compute descriptor, a container descriptor, etc. In Table 1, N is an integer greater than 1.

[0092] Table 1

[0093]

[0094] In another example, the deployment request may include an application ID, and there is a correspondence between the application ID and the application deployment method. After receiving the deployment request, the unified orchestration function entity may parse the deployment request and determine the deployment method of the application requested in the deployment request based on the application ID included in the deployment request and the pre-stored correspondence between the application ID and the application deployment method.

[0095] The ID of the application may be included in the orchestration information of the deployment request, or may be included in the deployment request independently of the orchestration information, without limitation.

[0096] Among them, the application ID and the application deployment method can be pre-stored in MEO or MEPM. For example, MEO can receive an on-board application request sent by OSS, including the application and the application deployment method, and on-board the application according to the on-board application request. When the application is successfully on-boarded to the MEC system, MEO can assign a unique ID to the application and store the application ID and the application deployment method correspondingly on MEO or MEPM.

[0097] For example, the following Table 2 shows the correspondence between the application ID and the deployment mode of the application. As shown in Table 2, the deployment mode corresponding to APP 1 is container deployment, the deployment mode of APP 2 is container deployment, and the deployment mode of APP 3 is container deployment. When the ID of the application included in the deployment request is APP 1, the unified orchestration functional entity can query Table 2 with APP 1 as the index to determine that the deployment mode corresponding to APP 1 is VM deployment. When the ID of the application included in the deployment request is APP 2, the unified orchestration functional entity can query Table 2 with APP 2 as the index to determine that the deployment mode corresponding to APP 2 is container deployment. When the ID of the application included in the deployment request is APP 3, the unified orchestration functional entity can query Table 2 with APP 3 as the index to determine that the deployment mode corresponding to APP 3 is container deployment.

[0098] Table 2

[0099] Application ID How the application is deployed APP 1 VM deployment APP 2 Container deployment APP 3 Container deployment

[0100] Furthermore, after step 302, if it is determined in step 302 that the application is deployed in a container, then steps 303 to 305 are executed; if the application is deployed in a VM, then steps 306 to 308 are executed:

[0101] Step 303: The unified orchestration function entity sends a first resource allocation request to the architecture manager.

[0102] Among them, when Figure 3 The method shown is based on Figure 1 When executed, the framework manager can Figure 1 The VIM in the VIM or the functional module in the VIM, such as a chip or a system on a chip in the VIM that can execute the functions executed by the architecture manager in the embodiment of the present application; when Figure 3 The method shown is based on Figure 2 When executed, the framework manager can Figure 2 The CIM or the functional module in the CIM, such as a chip or system on chip in the CIM that can perform the functions performed by the architecture manager in the embodiment of the present application, is not limited. Figure 1 VIM or Figure 2 The following describes the CIM in the example.

[0103] Among them, the first resource allocation request can be used to request the resources required to deploy a container that can run an instance of the application; such as computing resources, network resources, storage resources, etc. The first resource allocation request may include the ID of the application, the identifier of the container deployment, and the resource information required to deploy the application using the container deployment method. The identifier of the container deployment can be used to identify that the deployment method of the application is container deployment. The resource information required for container deployment may include the computing resources, storage resources, and network resources required to deploy the application using the container deployment method. Exemplarily, the resource information required for container deployment may specifically include: container image address, disk type, volume name, disk size, etc.

[0104] For example, when the unified orchestration function entity is MEO and the architecture manager is Figure 1 When using VIM, such as Figure 1 As shown, the unified orchestration function entity can send a first resource allocation request to the architecture manager through Mm4.

[0105] When the unified orchestration functional entity is MEPM, the architecture manager is Figure 1 When using VIM, such as Figure 1 As shown, the unified orchestration function entity can send a first resource allocation request to the architecture manager through Mm6.

[0106] When the unified orchestration functional entity is MEO, the architecture manager is Figure 2 When CIM in Figure 2 As shown, the unified orchestration function entity can send a first resource allocation request to the architecture manager through Mm10.

[0107] When the unified orchestration functional entity is MEPM, the architecture manager is Figure 2 When CIM in Figure 2 As shown, the unified orchestration function entity can send a first resource allocation request to the architecture manager through Mm11.

[0108] Step 304: The infrastructure manager receives the first resource allocation request and deploys a container capable of running an instance of the application according to the first resource allocation request.

[0109] Exemplarily, the way in which the architecture manager deploys a container capable of running an instance of an application based on the first resource allocation request can refer to the existing technology, such as: the architecture manager finds the container image repository based on the container image address and downloads the container image of the application from the container image repository; calls the storage plug-in to request the creation of a storage volume; requests the container engine to create a psuse container; requests the network plug-in to create CNI Add() and requests the container engine to create and run the container.

[0110] It should be noted that before the architecture manager downloads the container image of the application from the container image repository, the architecture manager needs to check whether the container image of the application exists in the container image repository. If not, the container deployment of the application fails; if it exists, check whether the container image of the application is available. If available, download the container image from the container image repository and execute the container deployment process. If not available, the container deployment of the application fails.

[0111] Among them, the container image repository stores the application ID and the application status information (available or unavailable, etc.). If the container image contains an ID that is the same as the application ID included in the first resource allocation request, it is determined that the container image of the application exists in the container image repository; otherwise, it does not exist; if the status information of the application identified by the application ID included in the first resource allocation request is available, it is determined that the container image of the application existing in the container repository is available; otherwise, it is unavailable.

[0112] Step 305: The fabric manager sends a first resource allocation response to the unified orchestration function entity.

[0113] The first resource allocation response may be used to indicate to the architecture manager that the container has been successfully deployed. The first resource allocation response may include an ID of the application.

[0114] For example, when the fabric manager is MEO, the fabric manager is Figure 1 When using VIM, such as Figure 1 As shown, the fabric manager may send a first resource allocation response to the unified orchestration function entity through Mm4.

[0115] When the fabric manager is MEPM, the fabric manager is Figure 1 When using VIM, such as Figure 1 As shown, the fabric manager may send a first resource allocation response to the unified orchestration function entity through Mm6.

[0116] When the fabric manager is MEO, the fabric manager is Figure 2 When CIM in Figure 2 As shown, the fabric manager may send a first resource allocation response to the unified orchestration function entity through Mm10.

[0117] When the fabric manager is MEPM, the fabric manager is Figure 2 When CIM in Figure 2 As shown, the fabric manager may send a first resource allocation response to the unified orchestration function entity through Mm11.

[0118] Step 306: The unified orchestration function entity sends a second resource allocation request to the VIM.

[0119] The second resource allocation request may be used to request the resources required to deploy a VM capable of running an instance of the application, such as computing resources, network resources, storage resources, and the like. The second resource allocation request may include the ID of the application, an identifier for VM deployment, and resource information required to deploy the application using the VM deployment method. The identifier for VM deployment may be used to identify that the deployment method of the application is VM deployment. The resource information required for VM deployment may include computing resources, storage resources, and network resources required to deploy the application using the VM deployment method. Exemplarily, the resource information required for VM deployment may specifically include: VM image address, disk type, volume name, disk size, and the like.

[0120] For example, Figure 1 or Figure 2 As shown, the unified orchestration function entity can send a second resource allocation request to the VIM through Mm6.

[0121] Step 307: The VIM receives the second resource allocation request and deploys a VM capable of running the instance of the application according to the second resource allocation request.

[0122] Exemplarily, the way in which VIM deploys a VM capable of running an instance of an application based on the second resource allocation request can refer to the existing technology, such as: VIM can download the VM image of the application from the VM image repository based on the VM image address; call the storage plug-in to request the creation of a storage volume; request the VM engine to create psuseVM; request the network plug-in to create a network plane and call libvirt to create and run the VM.

[0123] It should be noted that before VIM downloads the VM image of the application from the VM image repository, VIM needs to check whether the VM image of the application exists in the VM image repository. If not, the VM deployment of the application fails; if so, it checks whether the VM image of the application is available. If available, it downloads the VM image from the VM image repository and executes the VM deployment process. If not available, the VM deployment of the application fails.

[0124] Among them, the VM image repository stores the application ID and the application status information (available or unavailable, etc.). If the VM image contains an ID that is the same as the application ID included in the second resource allocation request, it is determined that the VM image of the application exists in the VM image repository; otherwise, it does not exist; if the status information of the application identified by the application ID included in the second resource allocation request is available, it is determined that the VM image of the application existing in the VM warehouse is available; otherwise, it is unavailable.

[0125] Step 308: The VIM sends a second resource allocation response to the unified orchestration function entity.

[0126] The second resource allocation response may be used to indicate that the VIM has successfully deployed the VM. The second resource allocation response may include the ID of the application. For example, Figure 1 or Figure 2 As shown, the VIM may send a second resource allocation response to the unified orchestration function entity through Mm6.

[0127] based on Figure 3 The method shown, after receiving a request to deploy an application, can analyze the received request and determine the deployment mode (container deployment or VM deployment) of the application requested to be deployed. If it is container deployment, a resource allocation request is sent to the VIM or CIM, requesting that the resources required for the application be deployed in the container deployment mode to complete the container deployment of the application; if it is VM deployment, a resource allocation request is sent to the VIM, requesting that the resources required for the application be deployed in the VM deployment mode to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0128] Further, in Figure 3In the illustrated method, taking the unified orchestration functional entity as an MEPM as an example, after receiving the first resource allocation response, the unified orchestration functional entity may send a first configuration request to the MEP. The first configuration request may be used to request the MEP to configure traffic rules, domain name system (DNS) rules, services, and services generated by the application instance running on the container. The first configuration request may include the traffic rules, DNS rules, required and optional services, and services generated by the application instance running on the container. After receiving the first configuration request, the MEP may configure traffic rules, DNS rules, and other services for the application instance based on the first configuration request. After successful configuration, the MEP may send a response to the first configuration request to the unified orchestration functional entity. The response to the first configuration request may indicate that the traffic rules, DNS rules, and other services followed by the application instance have been successfully configured.

[0129] Similarly, after the unified orchestration function entity receives the second resource allocation response, the unified orchestration function entity may send a second configuration request to the MEP. The second configuration request may be used to request the MEP to configure traffic rules, DNS rules, required and optional services, and services generated by the application instance running on the VM. The second configuration request may include traffic rules, DNS rules, required and optional services, and services generated by the application instance running on the container. After receiving the second configuration request, the MEP may configure traffic rules, DNS rules, and other information for the application instance based on the second configuration request. After successful configuration, the MEP may send a response to the second configuration request to the unified orchestration function entity. The response to the second configuration request may be used to indicate that the traffic rules, DNS rules, and other information followed by the application instance are successfully configured.

[0130] It should be noted that when the unified orchestration function entity is MEO, MEO can forward the first resource allocation response or second resource allocation response it receives to the MEPM, so that MEPM performs the above process after receiving the first resource allocation response or the second resource allocation response, which is not repeated here.

[0131] Further, in Figure 3 In the method shown, taking the unified orchestration functional entity as MEPM as an example, when the unified orchestration functional entity receives a response to the first configuration request or a response to the second configuration request, MEPM may consider that the instantiation deployment of the application is completed, and may send a response to the deployment request to OSS or to OSS through MEO.

[0132] Among them, the response to the deployment request corresponds to the deployment request described in step 301, and can be used to indicate the successful completion of the instantiation deployment of the application. The response to the deployment request may include resource information allocated to the instance of the application, such as: computing resources, network resources, and storage resources ultimately allocated to the instance of the application, etc.

[0133] Furthermore, when the deployed application instance is no longer needed, in order to save resources, the application instance can be terminated to release the resources occupied by the application instance. Figure 4 As shown, this may include:

[0134] Step 401: The unified orchestration function entity receives a termination request.

[0135] The unified orchestration function entity may be as described in step 301 and will not be described in detail herein.

[0136] The termination request may be used to request the termination of an instance of an application, and the termination request may include an ID of the application. The instance of the application may be an instance deployed in a container deployment mode or a VM deployment mode.

[0137] For example, Table 3 below shows the contents of a termination request. As shown in Table 1, the termination request may mandatorily include a termination type, the ID of the application instance (or the application ID), and optionally, a graceful termination timeout. In Table 3, N is an integer greater than 1.

[0138] Table 3

[0139]

[0140] For example, the unified arrangement function entity is Figure 1 or Figure 2 Taking MEO in the example, the unified orchestration function entity receiving the termination request may include: the unified orchestration function entity receiving the termination request sent by the OSS through Mm1, wherein the termination request may be sent to the OSS by the CFS portal or the user app LCM proxy; or, the unified orchestration function entity receiving the termination request sent by the user app LCM proxy through Mm9, wherein the termination request may be sent to the user app LCM proxy by the APP on the terminal.

[0141] In another example, the unified orchestration function entity is Figure 1 or Figure 2Taking MEPM in the example, the unified orchestration function entity receiving the termination request may include: the unified orchestration function entity receiving the termination request sent by OSS through Mm2, wherein the termination request may be sent to OSS by the CFS portal or the user app LCM proxy; or, the unified orchestration function entity receiving the termination request sent by MEO through Mm3, wherein MEO may obtain the termination request and send it to MEPM in the above manner, which will not be repeated here.

[0142] Step 402: The unified orchestration function entity sends a termination request to the MEP.

[0143] Step 403: The MEP receives the termination request and terminates the instance of the application according to the termination request.

[0144] The MEP terminating the instance of the application according to the termination request in step 403 can also be described as the MEP destroying the instance of the application according to the termination request, which is not limited.

[0145] In one example, the MEP terminating the instance of the application according to the termination request may include: the MEP sending a termination notification to the instance of the application through Mp1, after the instance of the application receives the termination notification, terminating the instance of the application according to the termination notification, and sending a termination response to the MEP, after the MEP receives the termination response, considering that the instance of the application has been terminated.

[0146] In another example, a timer can be set in the MEP. After the MEP sends a termination notification to the instance of the application through Mp1, the timer is started. When the timer times out, the instance of the application is terminated without having to terminate the instance of the application after receiving a termination response sent by the instance of the application.

[0147] Step 404: The MEP sends a termination response to the unified orchestration function entity.

[0148] The termination response may be used to indicate successful termination of the instance of the application.

[0149] Step 405: The unified orchestration function entity determines the deployment mode of the application according to the termination request; if the deployment mode of the application is container deployment, execute steps 406 to 408; if the deployment mode of the application is VM deployment, execute steps 409 to 411.

[0150] In step 405, the process of the unified orchestration function entity determining the deployment mode of the application program can refer to step 302 and will not be repeated here.

[0151] Step 406: The unified orchestration function entity sends a first resource deletion request to the architecture manager.

[0152] The architecture manager, as described in step 303 , may be a VIM or a CIM.

[0153] The first resource deletion request may be used to request the architecture manager to delete a container for running an instance of an application.

[0154] Step 407: The framework manager receives the first resource deletion request and deletes the container according to the first resource deletion request.

[0155] Among them, the architecture manager can refer to the existing technology in the way of deleting the container according to the first resource deletion request, such as: the architecture manager can delete (or release) all resources occupied by the container, such as: computing resources, storage resources, network resources, etc.

[0156] Step 408: The architecture manager sends a response to the first resource deletion request to the unified orchestration function entity, and the unified orchestration function entity receives the first resource deletion request.

[0157] The response to the first resource deletion request may be used to indicate successful deletion of the container corresponding to the instance of the application program.

[0158] Step 409: The unified orchestration function entity sends a second resource deletion request to the VIM.

[0159] The second resource deletion request may be used to request the VIM to delete a VM used to run an instance of the application.

[0160] Step 410: The VIM receives the second resource deletion request and deletes the VM according to the second resource deletion request.

[0161] Step 411: The VIM sends a response to the second resource deletion request to the unified orchestration function entity, and the unified orchestration function entity receives the second resource deletion request.

[0162] The response to the second resource deletion request may be used to indicate successful deletion of the VM corresponding to the instance of the application.

[0163] Step 412: The unified orchestration function entity sends a response to the termination request.

[0164] The response to the termination request is a response corresponding to the termination request in step 401 and may include the ID of the application. The response to the termination request may be used to indicate the successful termination of the instance of the application and the deletion of resources occupied by the instance of the application.

[0165] Exemplarily, the unified orchestration function entity may send a response to the termination request to the OSS.

[0166] based on Figure 4The method shown can terminate the instance of the application and delete the resources occupied by the instance of the application when the instance of the application is no longer needed, thereby improving resource utilization.

[0167] The following combination Figure 1 The MEC system shown in the figure takes the unified orchestration function entity as MEPM and the architecture manager as VIM as an example. Figure 3 The method shown is described.

[0168] Figure 5a A flowchart of another method for deploying virtual machines and containers is provided for the embodiment of the present application, such as Figure 5a As shown, the method may include:

[0169] Step 501a: OSS sends a deployment request to MEO.

[0170] The description of the deployment request may refer to step 301 and will not be repeated here.

[0171] Step 502a: MEO receives the deployment request and sends the deployment request to MEPM.

[0172] Step 503a: MEPM receives the deployment request and determines the deployment mode of the application based on the deployment request. If the deployment mode of the application is container deployment, execute steps 504a to 506a; if the deployment mode of the application is VM deployment, execute steps 507a to 509a.

[0173] Among them, step 503a can refer to step 302 and will not be repeated here.

[0174] Step 504a: The MEPM sends a first resource allocation request to the VIM.

[0175] The description of the first resource allocation request and the execution process of step 504a may refer to step 303 and will not be repeated here.

[0176] Step 505a: The VIM receives the first resource allocation request, and deploys a container capable of running an instance of the application program according to the first resource allocation request.

[0177] Among them, step 505a can refer to step 304 and will not be repeated here.

[0178] Step 506a: The VIM sends a first resource allocation response to the MEPM, and the MEPM receives the first resource allocation response.

[0179] Among them, step 506a can refer to step 305 and will not be repeated here.

[0180] Step 507a: The MEPM sends a second resource allocation request to the VIM.

[0181] The description of the second resource allocation request and the execution process of step 507a may refer to step 306 and will not be repeated here.

[0182] Step 508a: The VIM receives the second resource allocation request, and deploys a VM capable of running the instance of the application according to the second resource allocation request.

[0183] Among them, step 508a can refer to step 307 and will not be repeated here.

[0184] Step 509a: The VIM sends a second resource allocation response to the MEPM, and the MEPM receives the second resource allocation response.

[0185] Here, step 510a may refer to step 308 and will not be described in detail.

[0186] Step 510a: MEPM sends a response to the deployment request to MEO.

[0187] Step 511a: The MEO receives the response to the deployment request and sends the response to the deployment request to the OSS.

[0188] based on Figure 5a The method shown, after receiving a request to deploy an application, can analyze the received request and determine the deployment mode (container deployment or VM deployment) of the application requested to be deployed. If it is container deployment, a resource allocation request is sent to the VIM, requesting that the resources required for the application be deployed in the container deployment mode to complete the container deployment of the application; if it is VM deployment, a resource allocation request is sent to the VIM, requesting that the resources required for the application be deployed in the VM deployment mode to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0189] The following combination Figure 2 The MEC system shown in the figure takes the unified orchestration function entity as MEPM and the architecture manager as CIM as an example. Figure 3 The method shown is described.

[0190] Figure 5b A flowchart of another method for deploying virtual machines and containers is provided for the embodiment of the present application, such as Figure 5b As shown, the method may include:

[0191] Step 501b: OSS sends a deployment request to MEO.

[0192] The description of the deployment request may refer to step 301 and will not be repeated here.

[0193] Step 502b: MEO receives the deployment request and sends the deployment request to MEPM.

[0194] Step 503b: MEPM receives the deployment request and determines the deployment mode of the application based on the deployment request. If the deployment mode of the application is container deployment, execute steps 504b to 506b; if the deployment mode of the application is VM deployment, execute steps 507b to 509b.

[0195] Among them, step 503b can refer to step 302 and will not be repeated here.

[0196] Step 504b: MEPM sends a first resource allocation request to CIM.

[0197] The description of the first resource allocation request and the execution process of step 504b may refer to step 303 and will not be repeated here.

[0198] Step 505b: The CIM receives the first resource allocation request, and deploys a container capable of running an instance of the application program according to the first resource allocation request.

[0199] Among them, step 505b can refer to step 304 and will not be repeated here.

[0200] Step 506b: The CIM sends a first resource allocation response to the MEPM, and the MEPM receives the first resource allocation response.

[0201] Among them, step 506b can refer to step 305 and will not be repeated here.

[0202] Step 507b: The MEPM sends a second resource allocation request to the VIM.

[0203] The description of the second resource allocation request and the execution process of step 507b may refer to step 306 and will not be repeated here.

[0204] Step 508b: The VIM receives the second resource allocation request, and deploys a VM capable of running the instance of the application according to the second resource allocation request.

[0205] Among them, step 508b can refer to step 307 and will not be repeated here.

[0206] Step 509b: The VIM sends a second resource allocation response to the MEPM, and the MEPM receives the second resource allocation response.

[0207] Among them, step 509b can refer to step 308 and will not be repeated here.

[0208] Step 510b: MEPM sends a response to the deployment request to MEO.

[0209] Step 511b: MEO receives the response to the deployment request and sends the response to the deployment request to OSS.

[0210] based on Figure 5b The method shown, after receiving a request to deploy an application, can analyze the received request and determine the deployment mode (container deployment or VM deployment) of the application requested to be deployed. If it is container deployment, a resource allocation request is sent to the CIM, requesting that the resources required for the application be deployed in the container deployment mode to complete the container deployment of the application; if it is VM deployment, a resource allocation request is sent to the VIM, requesting that the resources required for the application be deployed in the VM deployment mode to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0211] As the reverse process of deploying an application instance, when the deployed application instance is no longer needed, in order to save resources, the application instance can also be terminated to release the resources occupied by the application instance. Figure 1 The MEC system shown in the figure takes the unified orchestration function entity as MEPM and the architecture manager as VIM as an example. Figure 6a or Figure 6b The method shown describes the process of terminating an instance of an application.

[0212] Figure 6a A flowchart of a method for terminating an application instance is provided for an embodiment of the present application, such as Figure 6a As shown, the method may include:

[0213] Step 601a: The OSS sends a termination request to the MEO.

[0214] The description of the termination request may refer to that in step 401 and will not be repeated here.

[0215] Step 602a: MEO receives the termination request and sends the termination request to MEPM.

[0216] Step 603a: The MEPM receives the termination request and sends the termination request to the MEP.

[0217] Step 604a: The MEP receives the termination request and terminates the instance of the application according to the termination request.

[0218] Among them, step 604a can refer to step 403 and will not be repeated here.

[0219] Step 605a: The MEP sends a termination response to the MEPM.

[0220] The description of the termination response and the execution process of step 605a may refer to step 404 and will not be repeated here.

[0221] Step 606a: MEPM determines the deployment mode of the application. If the deployment mode of the application is container deployment, execute steps 607a to 609a; if the deployment mode of the application is VM deployment, execute steps 610a to 612a.

[0222] Among them, step 606a can refer to step 405 and will not be repeated here.

[0223] Step 607a: MEPM sends a first resource deletion request to VIM.

[0224] The description of the first resource deletion request and the execution process of step 607a may refer to step 406 and will not be repeated here.

[0225] Step 608a: The VIM receives the first resource deletion request, and deletes the container according to the first resource deletion request.

[0226] Among them, step 608a can refer to step 407 and will not be repeated here.

[0227] Step 609a: The VIM sends a first resource deletion response to the MEPM, and the MEPM receives the first resource deletion response.

[0228] Among them, step 609a can refer to step 408 and will not be repeated here.

[0229] Step 610a: MEPM sends a second resource deletion request to VIM.

[0230] The description of the second resource deletion request and the execution process of step 610a may refer to step 409 and will not be repeated here.

[0231] Step 611a: The VIM receives the second resource deletion request, and deletes the VM according to the second resource deletion request.

[0232] Among them, step 611a can refer to step 410 and will not be repeated here.

[0233] Step 612a: The VIM sends a second resource deletion response to the MEPM, and the MEPM receives the second resource deletion response.

[0234] Among them, step 612a can refer to step 411 and will not be repeated here.

[0235] Step 613a: MEPM sends a response to the termination request to MEO.

[0236] Step 614a: The MEO receives the response to the termination request and sends the response to the termination request to the OSS.

[0237] based on Figure 6a The method shown can, upon receiving a termination request to terminate an application instance, perform corresponding termination processing based on the application's deployment method. For example, if the deployment method is container deployment, a first resource deletion request is sent to the VIM, requesting the VIM to delete the container resources occupied by the application instance; or, if the deployment method is VM deployment, a second resource deletion request is sent to the VIM, requesting the VIM to delete the VM resources occupied by the application instance. In this way, even when the application instance is no longer needed, the framework manager or the VIM can be requested to delete the application instance.

[0238] The following combination Figure 2 The MEC system shown takes the unified orchestration functional entity as MEPM and the architecture manager as CIM as an example to describe the process of terminating an instance of an application.

[0239] Figure 6b A flowchart of a method for terminating an application instance is provided for an embodiment of the present application, such as Figure 6b As shown, the method may include:

[0240] Step 601b: The OSS sends a termination request to the MEO.

[0241] The description of the termination request may refer to that in step 401 and will not be repeated here.

[0242] Step 602b: MEO receives the termination request and sends the termination request to MEPM.

[0243] Step 603b: The MEPM receives the termination request and sends the termination request to the MEP.

[0244] Step 604b: The MEP receives the termination request and terminates the instance of the application according to the termination request.

[0245] Among them, step 604b can refer to step 403 and will not be repeated here.

[0246] Step 605b: The MEP sends a termination response to the MEPM.

[0247] The description of the termination response and the execution process of step 605b may refer to step 404 and will not be repeated here.

[0248] Step 606b: MEPM receives the termination request. If the application is deployed in a container, steps 607b to 609b are executed; if the application is deployed in a VM, steps 610b to 612b are executed.

[0249] Among them, step 606b can refer to step 405 and will not be repeated here.

[0250] Step 607b: The MEPM sends a first resource deletion request to the CIM.

[0251] The description of the first resource deletion request and the execution process of step 607b may refer to step 406 and will not be repeated here.

[0252] Step 608b: The CIM receives the first resource deletion request and deletes the container according to the first resource deletion request.

[0253] Among them, step 608b can refer to step 407 and will not be repeated here.

[0254] Step 609b: The CIM sends a first resource deletion response to the MEPM, and the MEPM receives the first resource deletion response.

[0255] Among them, step 609b can refer to step 408 and will not be repeated here.

[0256] Step 610b: MEPM sends a second resource deletion request to VIM.

[0257] The description of the second resource deletion request and the execution process of step 610b may refer to step 409 and will not be repeated here.

[0258] Step 611b: The VIM receives the second resource deletion request, and deletes the VM according to the second resource deletion request.

[0259] Among them, step 611b can refer to step 410 and will not be repeated here.

[0260] Step 612b: The VIM sends a second resource deletion response to the MEPM, and the MEPM receives the second resource deletion response.

[0261] Among them, step 612b can refer to step 411 and will not be repeated here.

[0262] Step 613b: MEPM sends a response to the termination request to MEO.

[0263] Step 614b: The MEO receives the response to the termination request and sends the response to the termination request to the OSS.

[0264] based on Figure 6bThe method shown can, upon receiving a termination request to terminate an application instance, perform termination processing based on the application's deployment method. For example, if the deployment method is container deployment, a first resource deletion request is sent to the CIM, requesting the CIM to delete the container resources occupied by the application instance; or, if the deployment method is VM deployment, a second resource deletion request is sent to the VIM, requesting the VIM to delete the VM resources occupied by the application instance. In this way, even when the application instance is no longer needed, the infrastructure manager or VIM can be requested to delete the application instance.

[0265] exist Figures 3 to 6b In the method shown, the container image repository can store container image files, which can store applications deployed using containers. Similarly, the VM image repository can store VM image files, which can store applications deployed using VMs. The container image repository and the VM image repository can include one or more applications, and each application can be uniquely identified by the application's ID. Exemplarily, the application can be stored in the image repository (container image repository or VM image repository) through an on-boarding process. Specifically, the process can be as follows: Figure 7a Shown, including:

[0266] Step 701a: OSS sends an onboard application request to MEO.

[0267] Among them, the onboard application request can be used to request to onboard the application into the MEC system. The onboard application request can include the application and the deployment type identifier. The deployment type identifier can be used to identify that the application is a container-deployed application or a VM-deployed application.

[0268] It should be noted that when the application is a container-deployed application, the onboard application request may also include the container image address; when the application is a VM-deployed application, the onboard application request may also include the VM image address. This embodiment of the present application does not limit this.

[0269] For example, the OSS may receive an onboard application request sent by the CFS portal or the user app LCM proxy, and forward the received onboard application request to the MEO.

[0270] Step 702a: MEO receives an onboard application request and saves the application to the image repository.

[0271] For example, the image repository can be deployed in MEO or MEPM, without limitation. The image repository can include a container image repository and a VM image repository. If the deployment type identifier is used to identify the application as a container image, the application is saved in the container image repository. If the deployment type identifier is used to identify the application as a VM application, the application is saved in the VM image repository.

[0272] At the same time, MEO can assign an ID to each application to uniquely identify the application, and can also assign status information related to each application, such as: the status of the application can be assigned as available or unavailable, etc.

[0273] Step 703a: The MEO sends a response to the onboard application request to the OSS.

[0274] The response to the onboard application request may indicate that the application has been successfully onboarded (or saved) to the MEC system. The response to the onboard application request corresponds to the onboard application request in step 701a and may include, but is not limited to, information such as the application ID.

[0275] exist Figure 7a In the method shown, in order to prevent malicious application attacks, the application included in the onboard application request may include mandatory elements. When the MEO receives the onboard application request, it can verify whether the mandatory elements included in the application are the same as the agreed elements. If they are the same, it means that the application has integrity and authenticity and can be saved in the MEC system. On the contrary, if the mandatory elements included in the application are different from the agreed elements, it means that the application has been tampered with, etc., and the application cannot be saved in the MEC system, and the application fails to be onboarded.

[0276] The agreed elements may be elements predetermined in advance between the OSS and the MEO and capable of being used to verify the authenticity and integrity of the application.

[0277] In this way, the application can be loaded into the MEC system, and the application is available in the MEC system and can be instantiated and deployed.

[0278] exist Figures 3 to 6b In the method shown, MEO can manage the onboard applications as follows: query, disable (or disable), enable (enable), delete, etc. Specifically, the process of querying applications can be referred to Figure 7b The process of disabling an application can be found in Figure 7c As shown, the process of enabling the application can refer to Figure 7d As shown, the process of deleting the application can refer to Figure 7e shown.

[0279] Figure 7b A flowchart of a query application provided in an embodiment of the present application is shown in FIG. Figure 7b As shown, this may include:

[0280] Step 701b: OSS sends an application query request to MEO.

[0281] The application query request may be used to request information related to the application, such as application rules and requirements, etc. The application query request may include the application ID and other information, such as filtering conditions, etc., without limitation.

[0282] Exemplarily, the OSS may receive a query application request sent by the CFS portal or the user bpp LCM proxy, and forward the received query application request to the MEO.

[0283] Step 702b: MEO receives the application query request and queries the application related information from the image repository.

[0284] For example, if the application is a container image, MEO queries the relevant information of the application from the container image repository; if the application is a VM application, MEO queries the relevant information of the application from the VM image repository.

[0285] Step 703b: MEO sends a response to the application query request to OSS.

[0286] The response to the application query request may include application-related information, such as application rules and requirements, etc. For example, the MEO may send the response to the OSS carrying relevant information of the application that meets the filtering conditions.

[0287] So, you can Figure 7b The query process shown is to query the relevant information of the application.

[0288] Figure 7c A flowchart of disabling an application program is provided in an embodiment of the present application, such as Figure 7c As shown, this may include:

[0289] Step 701c: The OSS sends a request to the MEO to disable the application.

[0290] The application disable request may be used to request the application be disabled, making the application unavailable. The application disable request may include the application ID, etc., without limitation.

[0291] Exemplarily, the OSS may receive a disable application request sent by the CFS portal or the user bpp LCM proxy, and forward the received disable application request to the MEO.

[0292] Step 702c: The MEO receives the application disabling request and confirms disabling the application according to the application disabling request.

[0293] For example, MEO may first check whether the application identified by the application ID included in the disable application request exists, and if so, check whether the application status is enabled; if the application is enabled, MEO marks the application as disabled.

[0294] Step 703c: The MEO sends a response to disable the application to the OSS.

[0295] The response of disabling the application may be used to indicate that the application is disabled in the MEC system.

[0296] So, you can Figure 7c The process shown disables an application that exists in the MEC system.

[0297] Figure 7d A flowchart of enabling an application provided in an embodiment of the present application is as follows: Figure 7d As shown, this may include:

[0298] Step 701d: OSS sends a request to MEO to enable the application.

[0299] The application activation request may be used to request activation of an application so that the application is available in the MEC system. The application activation request may include the application ID, etc., without limitation.

[0300] Exemplarily, the OSS may receive an application activation request sent by the DFS portal or the user bpp LDM proxy, and forward the received application activation request to the MEO.

[0301] Step 702d: The MEO receives the application activation request and confirms activation of the application according to the application activation request.

[0302] For example, MEO may first check whether the application identified by the application ID included in the application activation request exists, and if so, check whether the application is marked as disabled and not marked as pending deletion. If so, enable the application.

[0303] Step 703d: MEO sends a response to OSS to enable the application.

[0304] The response of enabling the application may be used to indicate that the application is enabled in the MED system.

[0305] So, you can Figure 7d The process shown enables the applications present in the MED system.

[0306] Figure 7e A flowchart of deleting an application provided in an embodiment of the present application is as follows: Figure 7e As shown, this may include:

[0307] Step 701e: OSS sends a request to MEO to delete the application.

[0308] The application deletion request can be used to request the deletion of an application so that the application can be available in the MEC system. The application deletion request can include the application ID and the application deployment type identifier (VM or container), and can also include other information without limitation.

[0309] Exemplarily, the OSS may receive an application deletion request sent by the EFS portal or the user bpp LEM proxy, and forward the received application deletion request to the MEO.

[0310] Step 702e: MEO receives the application deletion request and confirms deletion of the application based on the application deletion request.

[0311] For example, the MEO may first check, based on the application ID included in the application deletion request, whether the application identified by the application ID is disabled and whether the disabled application is in use. If the application is disabled but in use, the MEO sets the application status to deletion pending. If the application is disabled and not in use, the MEO deletes the application from the mobile edge system.

[0312] Specifically, MEO can determine whether the application requested for deletion is a VM application or a container image based on the deployment type identifier (VM deployment or container deployment) included in the application deletion request. If the application is a VM application, MEO will interact with the file server that stores the VM application to delete it; if it is a container image, MEO needs to access the container image repository and call the container engine command to delete the corresponding container image. If the application is in a pending deletion state, MEO can check all instances corresponding to the application and delete the application after the application instance is terminated. If there is no instance of the application in use, MEO can delete the application.

[0313] Step 703e: MEO sends a response to OSS to delete the application.

[0314] The response of deleting the application may be used to indicate that the application is deleted in the MEO system.

[0315] So, you can Figure 7e The process shown here deletes an application that exists in the MEO system.

[0316] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the interaction between the various functional entities in the MEC system. It can be understood that each functional entity, such as the unified orchestration functional entity (MEPM or MEO), VIM, etc., in order to implement the above functions, includes a hardware structure and / or software module corresponding to each function. Those skilled in the art should easily realize that, in combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0317] The embodiment of the present application can divide the MEPM into functional modules according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0318] Figure 8The structure of a unified orchestration function entity 80 is shown. The unified orchestration function entity 80 can be a MEO or a chip or system on chip in a MEO, or a MEPM or a chip or system on chip in a MEPM. The unified orchestration function entity 80 can be used to perform the functions of the unified orchestration function entity involved in the above embodiments. As an implementation method, Figure 8 The unified orchestration function entity 80 shown includes:

[0319] Unified orchestration scheduling management module 801 is configured to receive a deployment request and, based on the deployment request, determine an application deployment method. A deployment request is used to request deployment of an application instance and includes the application's ID and orchestration information. The orchestration information indicates the resources required to deploy the application instance. Application deployment methods include container deployment or virtual machine (VM) deployment. For example, unified orchestration scheduling management module 801 may support unified orchestration function entity 80 in executing steps 301 and 302.

[0320] Further, such as Figure 8 As shown, unified orchestration functional entity 80 may further include a container orchestration management module 802 configured to, if unified orchestration scheduling management module 801 determines that the application is deployed in a container, send a first resource allocation request to the architecture manager, wherein the first resource allocation request is used to request resources required to deploy a container capable of running an instance of the application. For example, container orchestration management module 802 may be configured to support unified orchestration functional entity 80 in executing step 303, etc.

[0321] The VM scheduling management module 803 is configured to send a second resource allocation request to the VIM if the unified orchestration scheduling management module 801 determines that the application is deployed in a VM deployment mode. The second resource allocation request is used to request the resources required to deploy a VM capable of running the application instance. For example, the VM scheduling management module 803 can be configured to support the unified orchestration function entity 80 in executing step 306, etc.

[0322] The architecture manager may be VIM or CIM, etc., without limitation.

[0323] It should be noted that all relevant content of each step involved in the above method embodiment can be referenced to the functional description of the corresponding functional module and will not be repeated here. The unified orchestration functional entity 80 provided in the embodiment of the present application is used to perform the functions of the unified orchestration functional entity 80 of the above method for deploying virtual machines and containers, and thus can achieve the same effect as the above method for deploying virtual machines and containers.

[0324] In addition, it should be noted that the embodiments of the present application do not limit the deployment locations of the components included in the unified orchestration functional entity 80. The components included in the unified orchestration functional entity 80 can be centrally deployed in MEO or MEPM, or can be separately deployed in different functional entities. For example, the unified orchestration scheduling management module 801 can be deployed in MEO, and the container orchestration management module 802 and the VM scheduling management module 803 can be deployed in MEPM without restriction.

[0325] As another possible implementation method, Figure 8 The unified orchestration function entity 80 shown may include: a processing module and a communication module. The unified orchestration scheduling management module 801, the container orchestration management module 802, and the VM scheduling management module 803 may be integrated into the processing module. The processing module is used to control and manage the information received by the communication module. For example, the processing module is used to support the unified orchestration function entity 80 to execute steps 301, 302, 303, and 306 and other processes of the technology described herein. The communication module is used to support the unified orchestration function entity 80 to receive deployment requests and communicate with other network entities, such as Figure 1 Furthermore, the unified orchestration functional entity 80 may further include a storage module for storing program codes and data of the unified orchestration functional entity 80 .

[0326] The processing module may be a processor, such as a central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor may also be any other device having processing functionality, such as a circuit, a device, or a software module.

[0327] The communication module may be a communication interface for communicating with other devices or communication networks (such as Ethernet, radio access network (RAN), such as a module, circuit, transceiver or any device capable of achieving communication.

[0328] The memory may be a read-only memory (ROM) or other types of static storage devices that can store static information and / or instructions, or a random access memory (RAM) or other types of dynamic storage devices that can store information and / or instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. In one possible design, the memory can exist independently of the processor, that is, the memory can be a memory external to the processor, in which case the memory can be connected to the processor via a communication line for storing instructions or program codes. When the processor calls and executes the instructions or program codes stored in the memory, the method for deploying virtual machines and containers provided in the following embodiments of the present application can be implemented. In another possible design, the memory may also be integrated with the processor, that is, the memory may be the internal memory of the processor, for example, the memory is a cache, which may be used to temporarily store some data and / or instruction information, etc. Figure 9 A MEC system architecture diagram is provided in the embodiment of this application, such as Figure 9 As shown, the system may include: a unified orchestration function entity 80 and a VIM 81, wherein the unified orchestration function entity 80 and Figure 9 The functional entities shown include the same components and have the same functions. Figure 1 or Figure 2 MEPM or MEO as shown.

[0329] The unified orchestration function entity 80 is configured to receive a deployment request and determine an application deployment mode based on the deployment request. The deployment request is used to request deployment of an application instance. The deployment request includes an application ID and orchestration information. The orchestration information indicates resources required to deploy the application instance. The application deployment mode includes container deployment or virtual machine (VM) deployment.

[0330] The unified orchestration function entity 80 is further configured to, if the application is deployed in a container, send a first resource allocation request to the VIM 81, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application; or, if the application is deployed in a VM, send a second resource allocation request to the VIM 81, wherein the second resource allocation request is used to request resources required for deploying a VM capable of running an instance of the application;

[0331] VIM81 is used to receive a first resource allocation request and deploy a container capable of running an instance of an application according to the first resource allocation request; or to receive a second resource allocation request and deploy a virtual machine VM capable of running an application according to the second resource allocation request.

[0332] It should be noted that the specific implementation method of each functional entity in the above system architecture can refer to all relevant contents of each step involved in the above method embodiment, and will not be repeated here.

[0333] based on Figure 9 In the system shown, after MEPM or MEO receives a request to deploy an application, it can analyze the received request and determine the deployment method (container deployment or VM deployment) of the requested application. If it is container deployment, a resource allocation request is sent to VIM, requesting the use of container deployment to deploy the resources required for the application, and completing the container deployment of the application; if it is VM deployment, a resource allocation request is sent to VIM, requesting the use of VM deployment to deploy the resources required for the application, and completing the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0334] Figure 10 Another MEC system architecture diagram provided in the embodiment of this application is as follows: Figure 9 As shown, the system may include: a unified orchestration function entity 80, a VIM 81 and a CIM 82, wherein the unified orchestration function entity 80 and Figure 9 The functional entities shown include the same components and have the same functions. The unified arrangement of functional entities can be Figure 1 or Figure 2 MEPM or MEO as shown.

[0335] The unified orchestration function entity 80 is configured to receive a deployment request and determine an application deployment mode based on the deployment request. The deployment request is used to request deployment of an application instance. The deployment request includes an application ID and orchestration information. The orchestration information indicates resources required to deploy the application instance. The application deployment mode includes container deployment or virtual machine (VM) deployment.

[0336] The unified orchestration function entity 80 is further configured to, if the application is deployed in a container, send a first resource allocation request to the VIM 81, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application; or, if the application is deployed in a VM, send a second resource allocation request to the CIM 82, wherein the second resource allocation request is used to request resources required for deploying a VM capable of running an instance of the application.

[0337] VIM81 is configured to receive a first resource allocation request and deploy a container capable of running an instance of an application program according to the first resource allocation request;

[0338] CIM82 is configured to receive a second resource allocation request and deploy a virtual machine VM capable of running an application program according to the second resource allocation request.

[0339] It should be noted that the specific implementation method of each functional entity in the above system architecture can refer to all relevant contents of each step involved in the above method embodiment, and will not be repeated here.

[0340] based on Figure 9 In the system shown, after MEPM or MEO receives a request to deploy an application, it can analyze the received request and determine the deployment method (container deployment or VM deployment) of the requested application. If it is container deployment, a resource allocation request is sent to CIM, requesting the use of container deployment to deploy the resources required for the application, and completing the container deployment of the application; if it is VM deployment, a resource allocation request is sent to VIM, requesting the use of VM deployment to deploy the resources required for the application, and completing the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0341] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0342] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0343] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0344] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0345] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0346] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for deploying a virtual machine or container, characterized in that: The method comprises: The unified orchestration function entity receives a deployment request, wherein the deployment request is used to request deployment of an instance of an application program, the deployment request includes an identification ID of the application program and orchestration information, and the orchestration information is used to indicate resources required to run the instance of the application program; The unified orchestration function entity determines a deployment mode of the application program according to the deployment request, wherein the deployment mode of the application program includes container deployment or virtual machine (VM) deployment.

2. The method according to claim 1, characterized in that The method further comprises: If the deployment mode of the application is container deployment, the unified orchestration function entity sends a first resource allocation request to the architecture manager, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application; or If the deployment mode of the application is VM deployment, the unified orchestration function entity sends a second resource allocation request to the virtualization infrastructure manager VIM, wherein the second resource allocation request is used to request resources required for deploying a VM capable of running an instance of the application.

3. The method according to claim 1 or 2, characterized in that There is a corresponding relationship between the application ID and the deployment mode of the application. The unified orchestration function entity determines the deployment mode of the application according to the deployment request, including: The unified orchestration function entity determines a deployment mode of the application according to the ID of the application and the corresponding relationship.

4. The method according to claim 1 or 2, characterized in that The deployment request also includes a deployment type identifier, where the deployment type identifier is used to identify a deployment mode of the application. The unified orchestration function entity determines the deployment mode of the application based on the deployment request, including: The unified orchestration function entity determines a deployment mode of the application program according to the deployment type identifier.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The unified orchestration function entity sends a configuration request to the mobile edge platform MEP, wherein the configuration request is used to request the MEP to configure traffic rules and domain name system DNS rules followed by the instance running the application.

6. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The unified orchestration function entity receives a termination request; the termination request includes the ID of the application, and the termination request is used to terminate the instance of the application; If the deployment mode of the application is container deployment, the unified orchestration function entity sends a resource deletion request to the architecture manager, wherein the resource deletion request is used to request the architecture manager to delete the resources occupied by the instance of the application.

7. The method according to any one of claims 1 to 4, characterized in that The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

8. The method according to any one of claims 1 to 4, characterized in that The architecture manager is the VIM or the container infrastructure manager CIM.

9. A communication device, wherein the communication device is a unified orchestration function entity or a chip or system on chip in the unified orchestration function entity, characterized in that: The communication device comprises: A unified orchestration and scheduling management module is used to receive a deployment request and determine the deployment method of the application based on the deployment request, wherein the deployment request is used to request deployment of an instance of the application, the deployment request includes the identification ID of the application and orchestration information, and the orchestration information is used to indicate the resources required to deploy the instance of the application; the deployment method of the application includes container deployment or virtual machine VM deployment.

10. The device according to claim 9, characterized in that The unified scheduling and dispatching management module also includes: a container orchestration management module, configured to, if the application is deployed in a containerized manner, send a first resource allocation request to the architecture manager, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application; The virtual machine VM scheduling management module is used to, if the deployment mode of the application is VM deployment, send a second resource allocation request from the unified orchestration function entity to the virtualization infrastructure manager VIM, wherein the second resource allocation request is used to request the resources required for deploying the VM that can run the instance of the application.

11. The device according to claim 9 or 10, characterized in that There is a corresponding relationship between the application ID and the deployment method of the application. The unified orchestration and scheduling management module is specifically used to: Determine the deployment mode of the application program according to the ID of the application program and the corresponding relationship.

12. The device according to claim 9 or 10, characterized in that The deployment request also includes a deployment type identifier, which is used to identify the deployment method of the application. The unified orchestration and scheduling management module is specifically used to determine the deployment method of the application according to the deployment type identifier.

13. The device according to any one of claims 9 to 12, characterized in that The unified orchestration and scheduling management module is further used to send a configuration request to the mobile edge platform MEP, wherein the configuration request is used to request the MEP to configure the traffic rules and domain name system DNS rules followed by the instance running the application.

14. The device according to any one of claims 9 to 12, characterized in that The communication device further includes: The unified orchestration and scheduling management module is further configured to receive a termination request; the termination request includes the ID of the application, and the termination request is used to terminate the instance of the application; The container orchestration management module is further used to send a resource deletion request to the architecture manager if the deployment mode of the application is container deployment, wherein the resource deletion request is used to request the architecture manager to delete the resources occupied by the instance of the application.

15. The device according to any one of claims 9 to 12, characterized in that The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

16. The device according to any one of claims 9 to 12, characterized in that The architecture manager is the VIM or the container infrastructure manager CIM.

17. A multi-access edge computing MEC system, characterized in that: The MEC system includes: a unified orchestration function entity and a virtualized infrastructure manager VIM; The unified orchestration functional entity is configured to receive a deployment request and determine a deployment mode of the application program based on the deployment request, wherein the deployment request is used to request deployment of an instance of the application program, the deployment request includes an identification ID of the application program and orchestration information, the orchestration information is used to indicate resources required to deploy the instance of the application program, and the deployment mode of the application program includes container deployment or virtual machine (VM) deployment; When the application is deployed in a container, the unified orchestration function entity is further configured to send a first resource allocation request to the VIM, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application; or, when the application is deployed in a VM, the unified orchestration function entity is further configured to send a second resource allocation request to the VIM, wherein the second resource allocation request is used to request resources required for deploying a VM capable of running an instance of the application; The VIM is used to receive the first resource allocation request and deploy a container capable of running an instance of the application according to the first resource allocation request; or to receive the second resource allocation request and deploy a virtual machine VM capable of running the application according to the second resource allocation request.

18. The MEC system according to claim 17, wherein: The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

19. A multi-access edge computing MEC system, characterized in that: The MEC system includes: a unified orchestration function entity and a container infrastructure manager CIM; The unified orchestration functional entity is configured to receive a deployment request and determine a deployment mode of the application program based on the deployment request, wherein the deployment request is used to request deployment of an instance of the application program, the deployment request includes an identification ID of the application program and orchestration information, the orchestration information is used to indicate resources required to deploy the instance of the application program, and the deployment mode of the application program includes container deployment or virtual machine (VM) deployment; When the application is deployed in a container, the unified orchestration function entity is further configured to send a first resource allocation request to the CIM, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application; or, when the application is deployed in a VM, the unified orchestration function entity is further configured to send a second resource allocation request to the VIM, wherein the second resource allocation request is used to request resources required for deploying a VM capable of running an instance of the application; The CIM is configured to receive the first resource allocation request and deploy a container capable of running the instance of the application according to the first resource allocation request; The VIM is configured to receive the second resource allocation request and deploy a virtual machine VM capable of running the application according to the second resource allocation request.

20. The MEC system according to claim 19, wherein: The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

Images