Method and device for deploying virtual machines and containers

Abstract

The embodiment of the present application discloses a method and device for deploying virtual machines and containers, which are used to implement both container deployment and VM deployment in an MEC system. The method includes: a unified orchestration function entity receives a deployment request, and according to the deployment request, determines whether the deployment mode of the application is container deployment or VM deployment; further, 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, requesting the architecture manager to deploy a container capable of running an instance of the application; if the deployment mode of the application is VM deployment, a second resource allocation request is sent to the VIM, requesting the VIM to deploy a VM capable of running an instance of the application.

Description

Technical Field

[0001] 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

[0002] With the development of computer technology and communication technology, multi-access edge computing (MEC) has become the fifth generation (5 th The MEC system is located at the edge of the network. Most of the business data sent by users can be filtered and processed by the MEC system before being uploaded to the cloud, which can improve the data processing speed and transmission reliability.

[0003] Currently, in MEC systems, application instances can only be deployed through virtual machine (VM) deployment. However, with the development of communication technology, the demand for mixed deployment of VM and container in MEC systems has emerged, and application instances can be deployed through container deployment or VM deployment.

[0004] In the existing technology, kubernetes is the most popular container management platform and is suitable for most container scenarios. However, in the MEC system, due to the limited resource usage of edge nodes, kubernetes cannot meet the resource usage requirements of edge nodes in the MEC system, and kubernetes cannot be used to deploy containers in the MEC system. Summary of the invention

[0005] 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.

[0006] In order to achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] 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 function entity receives a deployment request for requesting deployment of an instance of an application, the deployment request comprising 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 function 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 function 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.

[0008] Based on the method described in the first aspect, after the unified orchestration function 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 function entity sends 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 sends a resource allocation request to the VIM, requesting the use of VM deployment to deploy the resources required for the application, and completing the VM deployment of the application, so that both VM deployment and container deployment can be achieved in the MEC system.

[0009] In a first possible design, in combination with the first aspect, the method further includes: if the application is deployed as container deployment, 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 VM deployment, 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.

[0010] 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. Alternatively, 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.

[0011] In a second possible design, in combination with the first aspect or the first possible design of the first aspect, there is a corresponding relationship between the ID of the application and the deployment mode of the application, and the unified orchestration function entity determines the deployment mode of the application according to the deployment request, including: the unified orchestration function entity determines the deployment mode of the application according to the ID of the application and the corresponding relationship. Based on this possible design, the ID used to identify the application and the deployment mode of the application can be matched, and the deployment mode of the application can be determined according to the corresponding relationship, which is simple and easy.

[0012] 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, the deployment type identifier is used to identify the deployment method of the application, and the unified orchestration function entity determines the deployment method of the application according to the deployment request, including: the unified orchestration function entity determines the deployment method of the application according to 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 method of the application is explicitly indicated by the deployment type identifier, which is simple and easy.

[0013] 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.

[0014] In a fourth possible design, in combination with any possible design from the first possible design of the first aspect to the third possible design of the first aspect, the method further includes: the unified orchestration function entity receives 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 knows that the container resources have been successfully allocated to the instance of the application.

[0015] In a fifth possible design, in combination with any possible design from the first possible design of the first aspect to the third possible design of the first aspect, the method further includes: the unified orchestration function entity receives 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 learns that VM resources have been successfully allocated to the instance of the application.

[0016] 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 sends a configuration request to the MEP, wherein the configuration request is used to request the MEP to configure traffic rules and DNS rules followed by the instance of the application. Based on this possible design, some rules followed by the instance of the application can be requested from the MEP so that the instance of the application is run according to the rules configured by the MEP.

[0017] 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 sends a response to the deployment request, wherein the response to the deployment request is used to indicate that the instance of the application is successfully deployed, and the response to the deployment request includes an ID of the application. Based on this possible design, after the instance of the application is successfully deployed, the response to the deployment request can be sent to a requester who requests to deploy the instance of the application, so that the requester learns that the instance of the application is successfully deployed.

[0018] 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 receives a termination request; the termination request includes an 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 first resource deletion request to the architecture manager, wherein the first resource deletion request can be used to request the architecture manager to delete the resources occupied by the instance of the application; or, if the deployment mode of the application is VM deployment, the unified orchestration function entity sends a second resource deletion request to the VIM, wherein the first resource deletion request can be used to request the VIM to delete the resources occupied by the instance of the application. Based on this possible design, after the unified orchestration function entity receives the termination request to terminate the instance of the application, it can perform corresponding termination processing according to the deployment mode of the application, such as: if the deployment mode is container deployment, the first resource deletion request is sent to the architecture manager to request the architecture manager to delete the resources occupied by the instance of the application; or, if the deployment mode is VM deployment, the second resource deletion request is sent to the VIM to request the VIM to delete the resources occupied by the instance of the application. In this way, the architecture manager or VIM can be requested to delete the instance of the application when the instance of the application is not needed.

[0019] A ninth possible design, in combination with the first aspect or any possible design of the first aspect, is to unify the orchestration function entity into MEPM or MEO. Based on this possible design, the method for deploying VMs and containers provided in the embodiment of the present application can be executed by MEPM or MEO, thereby improving execution flexibility.

[0020] 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 function of deploying a container in the embodiment of the present application, or a newly added functional entity CIM can perform the process of deploying a container provided in the embodiment of the present application.

[0021] In a second aspect, the present application provides a communication device, which may be a unified orchestration function entity or a chip or system on chip in the unified orchestration function entity, wherein the unified orchestration function entity is a MEPM or a MEO, and may implement the functions performed by the unified orchestration function entity in the above aspects or possible designs, and 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 functions. For example, the communication device may include: a unified orchestration scheduling management module;

[0022] 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, wherein the deployment request is used to request the deployment of an instance of the application, the deployment request includes the identification ID of the application and the 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.

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

[0024] The container orchestration management module is configured to send a first resource allocation request to the architecture manager if the unified orchestration scheduling management module determines that the deployment mode of the application is container deployment, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application;

[0025] 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.

[0026] Among them, the specific implementation method of the communication device can refer to the behavior function of the unified orchestration function entity in the method for deploying virtual machines and containers provided by 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.

[0027] In a third aspect, a communication device is provided, comprising: a processor and a memory; the memory is used to store computer execution instructions, and when the communication device is running, the processor executes the computer execution 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.

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

[0029] 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.

[0030] In a 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 according to 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, and can also include chips and other discrete devices.

[0031] 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.

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

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

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

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

[0036] Figure 4 A flow chart of a method for terminating an instance of an application provided in an embodiment of the present application;

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

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

[0039] Figure 6a A flow chart of a method for terminating an instance of an application provided in an embodiment of the present application;

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

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

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

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

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

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

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

[0047] Fig. 9 A schematic diagram of the composition of a MEC system provided in an embodiment of the present application;

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

[0049] The implementation of the embodiment of the present application is described in detail below in conjunction with the accompanying drawings.

[0050] In one example, in order to realize that both VMs and containers can be deployed in the MEC system, the functions of the existing network elements in the MEC system can be enhanced so that the network elements support 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 VMs and also has the function of supporting the management of containers, so that both VMs and containers can be deployed in the MEC system. Specifically, the enhanced MEC system can refer to Figure 1 shown.

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

[0052] A mobile edge host can be a physical host that is mainly used to provide computing, storage and network resources for mobile edge applications. A mobile edge host can include a mobile edge platform (mobile edge platform), multiple mobile edge applications (mobile edge applications, ME APP), and a virtualization infrastructure (virtualisation infrastructure, VI).

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

[0054] Mobile edge applications may include applications running on virtual machines on a virtualized infrastructure, or applications running on containers. Mobile edge applications may interact with a mobile edge platform to provide mobile edge services, and may also interact with a mobile edge platform to perform processes related to the life cycle of mobile edge applications, such as indicating the availability of mobile edge applications, relocating user status, etc. In addition, mobile edge applications also have a certain number of rules and requirements associated with them, such as resources required by mobile edge applications, maximum latency, required services, or useful services, etc.

[0055] 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 the service authorization, traffic rules, domain name system (DNS) configuration and conflict resolution of mobile edge applications.

[0056] The Virtualization Infrastructure Manager (VIM) can support the virtualization management of VMs and the management of containers. It has two main functions: first, allocate, manage and release virtualized resources (such as computing, storage and network resources) on the virtualization infrastructure; prepare virtualized infrastructure for running software images, such as configuring virtualized infrastructure, receiving and storing software images, etc.; quickly configure mobile edge applications, such as collecting and reporting performance and fault information of virtualized resources; perform mobile edge program relocation, etc. Second, 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, etc.

[0057] The mobile edge coordinator / orchestrator MEO is the core functional component at the mobile edge system level, and its main functions are as follows: maintain the overall view resources, available mobile edge services and topology of the mobile edge system according to the deployment of mobile edge hosts; select appropriate mobile edge hosts to provide available resources and available services for mobile edge application instantiation according to constraints (such as: mobile edge application latency, etc.); trigger mobile edge application instantiation or termination; trigger mobile edge application relocation; manage container resources of mobile edge hosts, such as: tracking container available resource capacity, and managing container images, etc.

[0058] The operation support system, which can be the operator's OSS, can receive requests from the CFS portal (or terminal application) for requesting application instantiation or termination, and forward the received request to the mobile edge coordinator / orchestrator, which executes subsequent processes according to the request.

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

[0060] exist Figure 1 In the MEC system shown, the mobile edge hosts and the components in the mobile edge hosts can communicate with each other through the interface of the mobile edge platform (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. The devices in the MEC system can communicate with the terminal or CFS portal through the interface with the external entity (such as: Mx interface).

[0061] For example, Figure 1 As 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.

[0062] OSS and the mobile edge coordinator / orchestrator can communicate with each other through Mm1, and OSS and the mobile edge platform manager can communicate with each other through Mm2. The mobile edge coordinator / orchestrator and the mobile edge platform manager can communicate with each other through Mm3, and the mobile edge coordinator / orchestrator and the virtualized infrastructure manager can communicate with each other through Mm4. The mobile edge platform manager and the mobile edge platform can communicate with each other through Mm5, and the mobile edge platform manager and the virtualized infrastructure manager can communicate with each other through Mm6. The virtualized infrastructure manager and the virtualized infrastructure can communicate with each other through Mm7. The user application lifecycle management agent and OSS can communicate with each other through Mm8, and the user application lifecycle management agent and the mobile edge coordinator / orchestrator can communicate with each other through Mm9. The CFS portal and OSS can communicate with each other through Mx1, and the CFS portal can send requests from third parties to 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, requesting to run the mobile edge application or move the mobile edge application into / out of the mobile edge system.

[0063] 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 also be named with other names without restriction.

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

[0065] like Figure 2 As shown, it is a schematic diagram of the architecture of another MEC system provided in an embodiment of the present application, such as 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, a terminal, a user app LCM proxy, an operations support system, and a mobile edge orchestrator / orchestrator (MEO).

[0066] 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 the article and will not be repeated here.

[0067] in, Figure 2 The mobile edge host in the can be a physical host, which is mainly used to provide computing, storage and network resources for mobile edge applications. The mobile edge host can include a mobile edge platform (mobile edge platform), multiple mobile edge applications (mobile edge applications, ME APP), virtualization infrastructure (virtualisation infrastructure, VI) and container infrastructure (container infrastructure, CI). CI has the function of a container engine, such as: it has the function of a docker engine.

[0068] in, Figure 2 As shown, CIM 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 of 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.

[0069] 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 interface of the mobile edge platform (mobile edge point, Mp), the mobile edge hosts and other devices in the MEC system can communicate with each other through 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. The devices in the MEC system can communicate with the terminal or CFS portal through the interface with the external entity (such as: Mx interface). For specific interfaces, please refer to Figure 2 As described in.

[0070] 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 also be named with other names without restriction.

[0071] 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.

[0072] 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:

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

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

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

[0076] Specifically, the deployment request may include, but is not limited to, the identification (identity, 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 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.

[0077] For example, taking VM deployment as an example, the orchestration information may be as follows, which may include basic information of the application and storage resources of the application, etc., wherein the basic information of the application may include basic node information, deployment method of the application, storage information, etc. The basic node information may 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 deployment method of the application may include: application package (package), node deployment method (node:sdk-VM), node relationship (relationship:hwpass.relationship.PackageConsistsor). Storage information may 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 may 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.

[0078]

[0079]

[0080] 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.

[0081] In another example, the unified orchestration function entity is Figure 1 or Figure 2 Taking MEPM 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 OSS through Mm2, wherein the deployment request may 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 may obtain the deployment request in the above manner and send it to MEPM, which will not be repeated here.

[0082] In another example, when MEO receives a deployment request and forwards it to MEPM, the method may further include: MEO obtains 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 in 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 in the deployment method specified by the instance configuration data of the application, if there are nodes 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.

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

[0084] 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 VM mode, the orchestration information may be of tosca type; when the application is deployed in container mode, the orchestration information may be of yaml type.

[0085] After receiving the deployment request, the unified orchestration function entity parses the deployment request, obtains the orchestration information included in the deployment request, and determines the deployment mode of the application according to the type of the 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.

[0086] The unified orchestration function entity may include keywords included in the orchestration information to determine the type of the orchestration information. For example, 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.

[0087] 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 receiving the deployment request, the unified orchestration function entity can parse the deployment request and determine the deployment method of the application based on the deployment type identifier included in the deployment request.

[0088] 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.

[0089] It should be noted that the deployment type identifier may be included in a newly added information element in the deployment request, or may 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 may also include other information.

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

[0091] Table 1

[0092]

[0093] In another example, the deployment request may include an application ID, and there is a correspondence between the application ID and the deployment method of the application. After receiving the deployment request, the unified orchestration function entity may parse the deployment request, and determine the deployment method of the application requested by the deployment request according to the application ID included in the deployment request and the correspondence between the application ID and the deployment method of the application stored in advance.

[0094] 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.

[0095] Among them, the application ID and the deployment method of the application can be pre-stored in MEO or MEPM, such as: MEO can receive an on-board application request including the application and the deployment method of the application sent by OSS, and on-board the application according to the request of the on-board application. 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 deployment method of the application on MEO or MEPM accordingly.

[0096] 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 function 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 function 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 function entity can query Table 2 with APP 3 as the index to determine that the deployment mode corresponding to APP 3 is container deployment.

[0097] Table 2

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

[0099] Further, after step 302, if it is determined in step 302 that the deployment mode of the application is container deployment, then steps 303 to 305 are executed; if the deployment mode of the application is VM deployment, then steps 306 to 308 are executed:

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

[0101] 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 in the CIM or the functional module in the CIM, such as: it can be 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, etc., without limitation. The embodiment of the present application only takes the architecture manager as Figure 1 VIM in or Figure 2 The following describes the CIM in the example.

[0102] 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.

[0103] For example, when the unified orchestration function entity is MEO, 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.

[0104] 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.

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

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

[0107] Step 304: The architecture manager 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.

[0108] 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.

[0109] 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 so, 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.

[0110] Among them, the container image repository stores the ID of the application and the status information of the application (available or unavailable, etc.). If the container image contains an ID that is the same as the ID of the application 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 ID of the application 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.

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

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

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

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

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

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

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

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

[0119] 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.

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

[0121] Exemplarily, the way in which VIM deploys a VM capable of running an instance of an application according to the second resource allocation request can refer to the prior art, such as: VIM can download the VM image of the application from the VM image repository according to 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.

[0122] 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, check whether the VM image of the application is available. If available, download the VM image from the VM image repository and execute the VM deployment process. If not available, the VM deployment of the application fails.

[0123] Among them, the VM image repository stores the application ID and the application status information (available or unavailable, etc.). If there is an ID in the VM image 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.

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

[0125] The second resource allocation response may be used to indicate that the VIM 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.

[0126] based on Figure 3 The method shown, after receiving a request to deploy an application, can analyze the received request to 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 to request the use of container deployment to deploy the resources required for the application, and complete the container deployment of the application; if it is VM deployment, a resource allocation request is sent to the VIM to request the use of VM deployment to deploy the resources required for the application, and complete the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0127] Further, in Figure 3In the method shown, taking the unified orchestration function entity as an MEPM as an example, after the unified orchestration function entity receives the first resource allocation response, the unified orchestration function entity may send a first configuration request to the MEP, and the first configuration request may be used to request the MEP to configure the traffic rules, domain name system (DNS) rules, services, and services generated by the instance of the application running on the container, and the first configuration request may include the traffic rules, DNS rules, required and optional services, and services generated by the instance of the application running on the container. After receiving the first configuration request, the MEP may configure the traffic rules, DNS rules, and the like for the instance of the application according to the first configuration request, and after the configuration is successful, send a response to the first configuration request to the unified orchestration function entity, and the response to the first configuration request may be used to indicate that the traffic rules, DNS rules, and the like followed by the instance of the application are successfully configured.

[0128] 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, and the second configuration request may be used to request the MEP to configure the traffic rules, DNS rules, required and optional services followed by the instance of the application running on the VM, and the services generated by the instance of the application. The second configuration request may include the traffic rules, DNS rules, required and optional services followed by the instance of the application running on the container, and the services generated by the instance of the application. After receiving the second configuration request, the MEP may configure the traffic rules, DNS rules, etc. for the instance of the application according to the second configuration request, and after the configuration is successful, send a response to the second configuration request to the unified orchestration function entity, and the response to the second configuration request may be used to indicate that the traffic rules, DNS rules, etc. followed by the instance of the application are configured successfully.

[0129] It should be noted that when the unified orchestration function entity is MEO, MEO can forward the received first resource allocation response or second resource allocation response 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.

[0130] 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.

[0131] 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: it may include computing resources, network resources, and storage resources that are ultimately allocated to the instance of the application, etc.

[0132] 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, it may include:

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

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

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

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

[0137] Table 3

[0138]

[0139] For example, the unified arrangement function entity is Figure 1 or Figure 2 Taking MEO in as an 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 userapp LCM proxy by the APP on the terminal.

[0140] In another example, the unified orchestration function entity is Figure 1 or Figure 2Taking MEPM in as an 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 in the above manner and send it to MEPM, which will not be repeated here.

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

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

[0143] 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.

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

[0145] 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 terminating the instance of the application after receiving a termination response sent by the instance of the application.

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

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

[0148] 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.

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

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

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

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

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

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

[0155] 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.

[0156] 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.

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

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

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

[0160] 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.

[0161] 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.

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

[0163] 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 successful termination of the instance of the application and deletion of resources occupied by the instance of the application.

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

[0165] 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.

[0166] Combine the following 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.

[0167] Figure 5a Another method flow chart 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:

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

[0169] The relevant description of the deployment request can refer to that in step 301 and will not be repeated here.

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

[0171] Step 503a: MEPM receives a deployment request and determines the deployment mode of the application according to 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.

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

[0173] Step 504a: MEPM sends a first resource allocation request to VIM.

[0174] 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.

[0175] 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.

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

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

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

[0179] Step 507a: MEPM sends a second resource allocation request to VIM.

[0180] The relevant description of the second resource allocation request and the execution process of step 507a may refer to step 306, which will not be described in detail.

[0181] 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.

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

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

[0184] Among them, step 510a can refer to step 308 and will not be repeated here.

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

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

[0187] based on Figure 5a The method shown, after receiving a request to deploy an application, can analyze the received request to 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 to request the use of container deployment to deploy the resources required for the application, and complete the container deployment of the application; if it is VM deployment, a resource allocation request is sent to the VIM to request the use of VM deployment to deploy the resources required for the application, and complete the VM deployment of the application. In this way, both VM deployment and container deployment can be achieved in the MEC system.

[0188] Combine the following 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.

[0189] 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:

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

[0191] The relevant description of the deployment request can refer to that in step 301 and will not be repeated here.

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

[0193] Step 503b: MEPM receives the deployment request and determines the deployment mode of the application according to 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.

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

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

[0196] The description of the first resource allocation request and the execution process of step 504b may refer to step 303, which will not be described in detail.

[0197] 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.

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

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

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

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

[0202] The relevant description of the second resource allocation request and the execution process of step 507b may refer to step 306, which will not be described in detail.

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

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

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

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

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

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

[0209] based on Figure 5b The method shown, after receiving a request to deploy an application, can analyze the received request to 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 CIM, requesting to deploy the resources required for the application in container deployment mode to complete the container deployment of the application; if it is VM deployment, a resource allocation request is sent to VIM, requesting to deploy the resources required for the application in VM deployment mode to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be realized in the MEC system.

[0210] 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.

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

[0212] Step 601a: OSS sends a termination request to MEO.

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

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

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

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

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

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

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

[0220] 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.

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

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

[0223] 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.

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

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

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

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

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

[0229] The relevant description of the second resource deletion request and the execution process of step 610a may refer to step 409 and will not be described in detail.

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

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

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

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

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

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

[0236] based on Figure 6a The method shown can perform corresponding termination processing according to the deployment mode of the application after receiving a termination request for terminating the instance of the application, such as: if the deployment mode is container deployment, a first resource deletion request is sent to the VIM to request the VIM to delete the container resources occupied by the instance of the application; or if the deployment mode is VM deployment, a second resource deletion request is sent to the VIM to request the VIM to delete the VM resources occupied by the instance of the application. In this way, when the instance of the application is not needed, the architecture manager or the VIM can be requested to delete the instance of the application.

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

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

[0239] Step 601b: OSS sends a termination request to MEO.

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

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

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

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

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

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

[0246] The description of the termination response and the execution process of step 605b may refer to step 404 and will not be described in detail.

[0247] 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.

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

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

[0250] The description of the first resource deletion request and the execution process of step 607b may refer to step 406 and will not be described in detail.

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

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

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

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

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

[0256] The relevant description of the second resource deletion request and the execution process of step 610b may refer to step 409 and will not be described in detail.

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

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

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

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

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

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

[0263] based on Figure 6bThe method shown can perform corresponding termination processing according to the deployment mode of the application after receiving a termination request for terminating the instance of the application, such as: if the deployment mode is container deployment, a first resource deletion request is sent to the CIM to request the CIM to delete the container resources occupied by the instance of the application; or if the deployment mode is VM deployment, a second resource deletion request is sent to the VIM to request the VIM to delete the VM resources occupied by the instance of the application. In this way, when the instance of the application is not needed, the architecture manager or VIM can be requested to delete the instance of the application.

[0264] exist Figure 3 to Figure 6b In the method shown, a container image repository may store a container image file, and the container image file may store an application deployed using a container. Similarly, a VM image repository may store a VM image file, and the VM image file may store an application deployed using a VM. The container image repository and the VM image repository may include one or more applications, and each application may be uniquely identified by the application ID. Exemplarily, an application may be stored in an image repository (container image repository or VM image repository) through an on-boarding process. Specifically, the process may be as follows: Figure 7a As shown, including:

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

[0266] 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.

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

[0268] Exemplarily, 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.

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

[0270] Exemplarily, 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.

[0271] 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.

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

[0273] The response to the onboard application request may be used to indicate that the application is 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 ID of the application.

[0274] 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 MEO receives the onboard application request, it can check 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; conversely, 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.

[0275] The agreed elements may be elements that are predetermined between OSS and MEO and can be used to verify the authenticity and integrity of the application.

[0276] In this way, the application can be onboarded to the MEC system, and the application is available in the MEC system and can be instantiated and deployed.

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

[0278] Figure 7b A flowchart of a query application provided in an embodiment of the present application, such as Figure 7b As shown, it may include:

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

[0280] 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 an application ID, and may also include other information, such as filtering conditions, etc., without limitation.

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

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

[0283] 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.

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

[0285] The response to the application query request may include relevant information of the application, such as application rules and requirements, etc. Exemplarily, the MEO may carry relevant information of the application that meets the filtering condition in the response and send it to the OSS.

[0286] In this way, you can Figure 7b The query process shown is used to query the relevant information of the application.

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

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

[0289] The application disabling request may be used to request disabling of an application, so that the application is unavailable. The application disabling request may include an application ID, etc., without limitation.

[0290] 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.

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

[0292] Exemplarily, 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.

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

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

[0295] In this way, you can Figure 7c The process shown disables the application present in the MEC system.

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

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

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

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

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

[0301] Exemplarily, 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 disabled and not marked as pending deletion, and if so, enable the application.

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

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

[0304] In this way, you can Figure 7d The process shown enables the applications present in the MED system.

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

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

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

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

[0309] Step 702e: MEO receives the application deletion request and confirms deletion of the application according to the application deletion request.

[0310] Exemplarily, MEO may first check whether the application identified by the application ID is disabled and whether the disabled application is in use according to the application ID included in the application deletion request. If the application is disabled but in use, MEO sets the status of the application to deletion pending. If the application is disabled and not in use, MEO deletes the application from the mobile edge system.

[0311] 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 requested for deletion, MEO interacts 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 instance of the application is terminated. If there is no instance of the application in use, MEO can delete the application.

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

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

[0314] In this way, you can Figure 7e The process shown deletes an application that exists in the MEO system.

[0315] 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 is understandable that each functional entity, such as a unified orchestration functional entity (MEPM or MEO), VIM, etc., includes hardware structures and / or software modules corresponding to the execution of each function in order to realize the above functions. It should be easy for those skilled in the art to 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 the form of hardware or computer software driving hardware 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.

[0316] 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 function division. There may be other division methods in actual implementation.

[0317] Figure 8The structure diagram of a unified orchestration function entity 80 is shown. The unified orchestration function entity 80 can be a MEO or a chip or a system on chip in a MEO, or a MEPM or a chip or a 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:

[0318] The unified orchestration scheduling management module 801 is used to receive a deployment request and determine the deployment mode of the application according to the deployment request, wherein the deployment request is used to request the deployment of an instance of the application, the deployment request includes the identification ID of the application and the orchestration information, and the orchestration information is used to indicate the resources required for the deployment of the instance of the application; the deployment mode of the application includes container deployment or virtual machine VM deployment. For example, the unified orchestration scheduling management module 801 can support the unified orchestration function entity 80 to execute steps 301 and 302, etc.

[0319] Further, such as Figure 8 As shown, the unified orchestration function entity 80 may further include: a container orchestration management module 802, which is used to send a first resource allocation request to the architecture manager if the unified orchestration scheduling management module 801 determines that the deployment mode of the application is container deployment, wherein the first resource allocation request is used to request resources required for deploying a container capable of running an instance of the application. For example, the container orchestration management module 802 may be used to support the unified orchestration function entity 80 to perform step 303, etc.

[0320] The VM scheduling management module 803 is used to send a second resource allocation request to the VIM if the unified orchestration scheduling management module 801 determines that the deployment mode of the application is VM deployment, wherein the second resource allocation request is used to request resources required for deploying a VM capable of running an instance of the application. For example, the VM scheduling management module 803 can be used to support the unified orchestration function entity 80 to perform step 306, etc.

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

[0322] It should be noted that all relevant contents of each step involved in the above method embodiment can be referred 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, so it can achieve the same effect as the above method for deploying virtual machines and containers.

[0323] 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.

[0324] As another possible way to achieve this, 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 in 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 in this article. 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 The communication between the functional modules or network entities shown. Further, the unified orchestration functional entity 80 may also include a storage module for storing program codes and data of the unified orchestration functional entity 80.

[0325] 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 a processing function, such as a circuit, a device, or a software module.

[0326] 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, a circuit, a transceiver or any device capable of achieving communication.

[0327] 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 disk storage medium or other magnetic storage devices, 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 may exist independently of the processor, that is, the memory may be a memory external to the processor, in which case the memory may 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 an 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. Fig. 9 A MEC system architecture diagram provided in an embodiment of the present application is as follows: Fig. 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 Fig. 9 The functional entities shown include the same components and have the same functions. The unified arrangement functional entity can be Figure 1 or Figure 2 MEPM or MEO shown.

[0328] The unified orchestration function entity 80 is used to receive a deployment request and determine a deployment mode of the application according to the deployment request, wherein the deployment request is used to request the deployment of an instance of the application, the deployment request includes an identification ID of the application and orchestration information, the orchestration information is used to indicate resources required for the deployment of the instance of the application, and the deployment mode of the application includes container deployment or virtual machine VM deployment;

[0329] The unified orchestration function entity 80 is further configured to send a first resource allocation request to the VIM 81 if the deployment mode of the application is container deployment, 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, 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;

[0330] 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.

[0331] 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, which will not be repeated here.

[0332] based on Fig. 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 application requested to be deployed. 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.

[0333] Fig.10 Another MEC system architecture diagram provided in the embodiment of the present application is as follows: Fig. 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 Fig. 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 shown.

[0334] The unified orchestration function entity 80 is used to receive a deployment request and determine a deployment mode of the application according to the deployment request, wherein the deployment request is used to request the deployment of an instance of the application, the deployment request includes an identification ID of the application and orchestration information, the orchestration information is used to indicate resources required for the deployment of the instance of the application, and the deployment mode of the application includes container deployment or virtual machine VM deployment;

[0335] The unified orchestration function entity 80 is further configured to send a first resource allocation request to the VIM 81 if the deployment mode of the application is container deployment, 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 80 sends 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;

[0336] VIM81 is used 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;

[0337] CIM82 is used 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.

[0338] 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, which will not be repeated here.

[0339] based on Fig. 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.

[0340] 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.

[0341] In the several embodiments provided in the present 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 only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, 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.

[0342] The units described as separate components may or may not be physically separated, 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 different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0343] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0344] 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, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform 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 USB flash drives, mobile hard drives, ROM, RAM, magnetic disks or optical disks.

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

Claims

1. A method for deploying virtual machines and containers in a multi-access edge computing MEC system, 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, according to the deployment request, a deployment mode of the application, wherein the deployment mode of the application includes container deployment or virtual machine VM deployment; 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; the architecture manager is a container infrastructure manager CIM; 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.

2. The method according to claim 1, characterized in that: There is a corresponding relationship between the ID of the application 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 the deployment mode of the application according to the ID of the application and the corresponding relationship.

3. The method according to claim 1, 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 program. The unified orchestration function entity determines the deployment mode of the application program according to the deployment request, including: The unified orchestration function entity determines a deployment mode of the application program according to the deployment type identifier.

4. The method according to any one of claims 1 to 3, 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.

5. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The unified orchestration function entity receives a termination request; the termination request includes an 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 first resource deletion request to the architecture manager, wherein the resource deletion request is used to request the architecture manager to delete resources occupied by the instance of the application; If the deployment mode of the application is VM deployment, the unified orchestration function entity sends a second resource deletion request to the VIM, wherein the first resource deletion request is used to request the VIM to delete the resources occupied by the instance of the application.

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

7. The method according to any one of claims 1 to 3, characterized in that: The framework manager may also be the VIM.

8. A unified orchestration functional entity for use in a multi-access edge computing MEC system, characterized in that: The unified orchestration functional entity includes: A unified orchestration scheduling management module, used to receive a deployment request and determine a deployment mode of an application according to the deployment request, wherein the deployment request is used to request deployment of an instance of the application, the deployment request includes an identification ID of the application and orchestration information, the orchestration information is used to indicate resources required to deploy the instance of the application; the deployment mode of the application includes container deployment or virtual machine VM deployment; a container orchestration management module, configured to, if the deployment mode of the application is container deployment, cause the unified orchestration function entity to send a first resource allocation request to an 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 architecture manager is a container infrastructure manager CIM; A virtual machine VM scheduling management module is used for, 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 the resources required for deploying the VM that can run the instance of the application.

9. The unified orchestration functional entity according to claim 8, characterized in that: There is a corresponding relationship between the application ID and the deployment mode of the application. The unified orchestration and scheduling management module is specifically used to: The deployment mode of the application is determined according to the ID of the application and the corresponding relationship.

10. The unified orchestration functional entity according to claim 8, characterized in that: The deployment request also includes a deployment type identifier, and the deployment type identifier is used to identify the deployment mode of the application. The unified orchestration and scheduling management module is specifically used to determine the deployment mode of the application according to the deployment type identifier.

11. The unified orchestration functional entity according to any one of claims 8 to 10, characterized in that: The unified orchestration and scheduling management module is also 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.

12. The unified orchestration functional entity according to any one of claims 8 to 10, characterized in that: The unified orchestration function entity also includes: The unified orchestration scheduling management module is further used 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 configured to send a first 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 resources occupied by the instance of the application; The VM scheduling management module is also used for, if the deployment mode of the application is VM deployment, the unified orchestration function entity sends a second resource deletion request to the VIM, wherein the first resource deletion request is used to request the VIM to delete the resources occupied by the instance of the application.

13. The unified orchestration functional entity according to any one of claims 8 to 10, characterized in that: The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

14. The unified orchestration functional entity according to any one of claims 8 to 10, characterized in that: The framework manager may also be the VIM.

15. 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 function entity is used to receive a deployment request, and determine a deployment mode of the application according to the deployment request, wherein the deployment request is used to request deployment of an instance of the application, the deployment request includes an identification ID of the application and orchestration information, the orchestration information is used to indicate resources required for deploying the instance of the application, and the deployment mode of the application includes container deployment or virtual machine VM deployment; When the deployment mode of the application is container deployment, the unified orchestration function entity is further used 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 deployment mode of the application is VM deployment, the unified orchestration function entity is further used 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.

16. The MEC system according to claim 15, characterized in that: The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

17. A multi-access edge computing MEC system, characterized in that: The MEC system includes: a unified orchestration function entity, a virtualization infrastructure manager VIM and a container infrastructure manager CIM; The unified orchestration function entity is used to receive a deployment request, and determine a deployment mode of the application according to the deployment request, wherein the deployment request is used to request deployment of an instance of the application, the deployment request includes an identification ID of the application and orchestration information, the orchestration information is used to indicate resources required for deploying the instance of the application, and the deployment mode of the application includes container deployment or virtual machine VM deployment; When the deployment mode of the application is container deployment, the unified orchestration function entity is further used 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 deployment mode of the application is VM deployment, the unified orchestration function entity is further used 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 used 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, characterized in that: The unified orchestration function entity is a mobile edge platform manager MEPM or a mobile edge orchestrator MEO.

Images