WO2020192598A1 - 一种部署虚拟机和容器的方法及装置 - Google Patents

一种部署虚拟机和容器的方法及装置 Download PDF

Info

Publication number
WO2020192598A1
WO2020192598A1 PCT/CN2020/080505 CN2020080505W WO2020192598A1 WO 2020192598 A1 WO2020192598 A1 WO 2020192598A1 CN 2020080505 W CN2020080505 W CN 2020080505W WO 2020192598 A1 WO2020192598 A1 WO 2020192598A1
Authority
WO
WIPO (PCT)
Prior art keywords
deployment
request
application
container
instance
Prior art date
Application number
PCT/CN2020/080505
Other languages
English (en)
French (fr)
Inventor
陈学梁
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP20778926.4A priority Critical patent/EP3933580B1/en
Publication of WO2020192598A1 publication Critical patent/WO2020192598A1/zh
Priority to US17/481,549 priority patent/US20220004410A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/503—Resource availability

Definitions

  • the embodiments of the present application relate to the field of computer technology, and in particular, to a method and device for deploying virtual machines and containers.
  • MEC multi-access edge computing
  • VM virtual machine
  • kubernetes as the most popular container management platform, is suitable for most container scenarios.
  • kubernetes due to the limited resource usage of edge nodes, kubernetes cannot meet the resource occupation requirements of edge nodes in the MEC system, and kubernetes cannot be used for container deployment in the MEC system.
  • the embodiment of the present application provides a method and device for deploying a virtual machine and a container, so as to implement the deployment of the VM and the container in the MEC system.
  • an embodiment of the present application provides a method for deploying a virtual machine and a container.
  • the method includes: a unified orchestration function entity receives a deployment request for requesting to deploy an instance of an application program, the deployment request includes an identification ID and an orchestration of the application program Information, orchestration information is used to indicate the resources required to run the instance of the application.
  • the unified orchestration function entity determines the deployment mode of the application to be container deployment or virtual machine VM deployment, so that the unified orchestration function entity determines the deployment according to the deployment request.
  • the method requests VIM or CIM to deploy a VM or container that can run an instance of the application.
  • the unified orchestration function entity 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), so that the unified orchestration function entity sends a resource allocation request to VIM or CIM according to the determined deployment method, and requests the use of container deployment to deploy the resources required by the application, or sends a resource allocation request to VIM, requesting adoption
  • the VM deployment method deploys the resources required by the application, completes the VM deployment of the application, and realizes that both VM deployment and container deployment can be implemented in the MEC system.
  • the method further includes: if the deployment mode of the application is container deployment, the unified orchestration function entity sends to the architecture manager a request to deploy an instance capable of running the application The first resource allocation request for the resources required by the container, or, if the deployment mode of the application is VM deployment, the unified orchestration function entity sends to the VIM the first resource allocation request for requesting the deployment of a VM capable of running an instance of the application. 2. Resource allocation request.
  • the first resource allocation request can be sent to the architecture manager to request the architecture manager to allocate container resources that can run the application instance, or, when the VM is deployed, the first resource allocation request can be sent to the VIM.
  • Resource allocation request requesting VIM to allocate VM resources that can run the instance of the application. In this way, both container deployment and VM deployment can be implemented.
  • the unified orchestration function entity determines the application according to the deployment request
  • the deployment method includes: the unified orchestration function entity determines the deployment method of the application according to the ID and the corresponding relationship of the application. Based on this possible design, the ID used to identify the application can be associated with the deployment mode of the application, and the deployment mode of the application can be determined according to the correspondence, which is simple and easy.
  • the deployment request also includes the deployment type identification.
  • the deployment type identification is used to identify the deployment method of the application, and the functional entities are organized according to
  • the deployment request to determine the deployment method of the application includes: the unified orchestration function entity determines the deployment method of the application according to the deployment type identification.
  • a deployment type identifier for identifying the deployment mode of the application can be added to the orchestration information, and the deployment type identifier is used to explicitly indicate the deployment mode of the application, which is simple and easy to implement.
  • deployment type identifier may be included in the newly added information element in the deployment request, or may be included in the scheduling information included in the deployment request, and is not limited.
  • the method further includes: uniformly orchestrating the functional entity receiving from The first resource allocation response of the architecture manager. Based on this possible design, after allocating container resources, the first resource allocation response may 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 program.
  • the method further includes: uniformly orchestrating the functional entity receiving from VIM's second resource allocation response. Based on this possible design, after VM resources are allocated, the first resource allocation response may be returned to the unified orchestration functional entity, so that the unified orchestration functional entity knows that the VM resources have been successfully allocated to the instance of the application program.
  • 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 the running application The traffic rules and DNS rules followed by the instance. Based on this possible design, it is possible to request some rules followed by the MEP for running the instance of the application, so as to run the instance of the application according to the rules configured by the MEP.
  • a seventh possible design in combination with the first aspect or any possible design of the first aspect, the method further includes: uniformly orchestrating a response to the deployment request sent by the functional entity, where the response to the deployment request is used to indicate the successful deployment of the application
  • the response to the deployment request includes the ID of the application. Based on this possible design, after the instance of the application is successfully deployed, a response to the deployment request can be sent to the requester that requests the deployment of the instance of the application, so that the requester knows the instance of the application that is successfully deployed.
  • the method further includes: the unified orchestration function entity receives a termination request; the termination request includes the ID of the application program, and the termination request is used to terminate the application The instance of the program; if the deployment method of the application is container deployment, the unified orchestration function entity sends the first resource deletion request to the architecture manager, where the first resource deletion request can be used to request the architecture manager to delete the instance occupation 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 VIM, where the first resource deletion request can be used to request VIM to delete the resources occupied by the instance of the application.
  • the unified orchestration function entity 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 method of the application, such as: if the deployment method is container deployment, send to the architecture manager The first resource deletion request requests the architecture manager to delete the resources occupied by the instance of the application; or, if the deployment mode is VM deployment, a second resource deletion request is sent to VIM to request the VIM to delete the resources occupied by the instance of the application. In this way, it is possible to request the architecture manager or VIM to delete the instance of the application when the instance of the application is not needed.
  • the unified orchestration function entity is MEPM or MEO. Based on this possible design, the method for deploying VMs and containers provided in the embodiments of the present application can be executed by MEPM or MEO, which improves execution flexibility.
  • the architecture manager is VIM or CIM.
  • an existing functional entity such as VIM
  • VIM can execute the function of deploying a container in the embodiment of this application
  • CIM can execute the process of deploying a container provided in the embodiment of this application.
  • this application provides a communication device, which may be a unified orchestration functional entity or a chip or a system on a chip in the unified orchestration functional entity, where the unified orchestration functional entity is MEPM or MEO, which can implement the above aspects or
  • the functions performed by the functional entities are arranged in a unified manner, and the functions can be realized by hardware, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device may include: a unified scheduling management module;
  • the unified orchestration scheduling management module is used to receive deployment requests and determine the deployment mode of the application according to the deployment request.
  • 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.
  • the information is used to indicate the resources required to deploy the instance of the application; the deployment mode of the application includes container deployment or virtual machine VM deployment.
  • the unified orchestration function entity also includes:
  • the container orchestration management module is used to send a first resource allocation request to the architecture manager if the unified orchestration management module determines that the deployment mode of the application is container deployment, where the first resource allocation request is used to request deployment to be able to run the application The resources required by the container of the instance;
  • the virtual machine VM scheduling management module is configured to send a second resource allocation request to the virtualization infrastructure manager VIM if the unified scheduling management module determines that the deployment mode of the application program is VM deployment, where the second resource allocation request is used for Request the resources required to deploy a VM capable of running an instance of the application.
  • the specific implementation of the communication device can refer to the first aspect or any one of the possible designs of the first aspect to uniformly orchestrate the behavior and functions of the functional entities in the method for deploying virtual machines and containers, which 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.
  • a communication device including: 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 to enable the The communication device executes the method for deploying a virtual machine and a container as described in the first aspect or any possible design of the first aspect.
  • a computer-readable storage medium is provided, and the computer-readable storage medium is a non-volatile readable storage medium.
  • the computer-readable storage medium stores instructions that, when run on a computer, enable the computer to execute the method for deploying virtual machines and containers as described in the first aspect or any one of the possible designs of the foregoing aspects.
  • a computer program product containing instructions which when running on a computer, enables the computer to execute the deployment of virtual machines and containers described in the first aspect or any one of the possible designs of the foregoing aspects. method.
  • a chip system in a sixth aspect, includes a processor and a communication interface for supporting the chip system to implement the functions involved in the above aspects.
  • the processor receives a deployment request through the communication interface and responds to the deployment request. , Determine the deployment method of the application, where 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 orchestration information, and the orchestration information is used to indicate the resources required to deploy the instance of the application;
  • the deployment methods include container deployment or virtual machine VM deployment.
  • the chip system further includes a memory, and the memory is used to store necessary program instructions and data of the communication device.
  • the chip system can be composed of chips, or include chips and other discrete devices.
  • the technical effects brought about by any one of the design methods of the third aspect to the sixth aspect may 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.
  • embodiments of the present application provide an MEC system, including the unified orchestration function entity and the virtualized infrastructure manager VIM as described in the second to sixth aspects; or, including the second to sixth aspects The unified orchestration function entity, VIM and CIM.
  • FIG. 1 is a schematic diagram of the architecture of an MEC system provided by an embodiment of the application
  • FIG. 2 is a schematic diagram of the architecture of another MEC system provided by an embodiment of the application.
  • FIG. 3 is a flowchart of a method for deploying virtual machines and containers according to an embodiment of the application
  • FIG. 4 is a flowchart of a method for terminating an application program provided by an embodiment of the application
  • FIG. 5a is a flowchart of another method for deploying virtual machines and containers according to an embodiment of the application
  • FIG. 5b is a flowchart of yet another method for deploying virtual machines and containers according to an embodiment of the application
  • FIG. 6a is a flowchart of a method for terminating an application program provided by an embodiment of the application
  • FIG. 6b is a flowchart of another method for terminating an application program according to an embodiment of the application.
  • FIG. 7a is a flowchart of a method for an onboard application provided by an embodiment of the application.
  • Fig. 7b is a flowchart of a method for querying an application provided by an embodiment of the application
  • Fig. 7c is a flowchart of a method for enabling an application provided by an embodiment of the application.
  • Fig. 7d is a flowchart of a method for disabling an application provided by an embodiment of the application.
  • FIG. 7e is a flowchart of a method for deleting an application provided by an embodiment of the application.
  • FIG. 8 is a schematic diagram of the composition of a unified orchestration function entity provided by an embodiment of the application.
  • FIG. 10 is a schematic diagram of the composition of another MEC system provided by an embodiment of this application.
  • the functions of the existing network elements in the MEC system can be enhanced to enable the network elements to support container management (such as deployment, delete Etc.), for example, the VIM in the MEC system can be enhanced so that the VIM supports the virtualization management of the VM and also has the function of supporting the management of the container, so as to realize that both the VM and the container can be deployed in the MEC system.
  • the enhanced MEC system can be referred to as shown in FIG. 1.
  • FIG. 1 is a schematic diagram of the architecture of an MEC system provided by an embodiment of this application.
  • the MEC system can include two major levels: mobile edge host level and mobile edge system level. system).
  • the mobile edge host level may include: multiple mobile edge hosts (mobile edge hosts), mobile edge platform managers (mobile edge platform managers, MEPM), and virtualised infrastructure managers (virtualised infrastructure managers, VIM).
  • the mobile edge system level can include: customer facing service portal (CFS portal), terminal, user application lifecycle management agent (user app LCM proxy), operation support system (operations support system), and mobile edge coordinator /Orchestrator (mobile edge orchestrator, MEO), etc.
  • CFS portal customer facing service portal
  • terminal terminal
  • user application lifecycle management agent user app LCM proxy
  • operation support system operations support system
  • MEO mobile edge coordinator /Orchestrator
  • the mobile edge host can be a physical host, which is mainly used to provide computing, storage and network resources for mobile edge applications.
  • the mobile edge host may include a mobile edge platform (mobile edge platform), multiple mobile edge applications (ME APP), and virtualisation infrastructure (VI).
  • mobile edge platform mobile edge platform
  • ME APP multiple mobile edge applications
  • VIP virtualisation infrastructure
  • the mobile edge platform MEP is mainly used to provide mobile edge services for mobile edge applications and provide intermediary services for mobile edge applications. For example, it can provide services for the discovery and use of mobile edge applications.
  • Mobile edge applications may include virtual machine (virtual machine) applications running on a virtualized infrastructure, and may also include applications running in containers.
  • the mobile edge application can interact with the mobile edge platform to provide mobile edge services, and it can also interact with the mobile edge platform to perform processes related to the mobile edge application life cycle, such as indicating the availability of the mobile edge application, relocating user status, etc. .
  • mobile edge applications also have a certain number of rules and requirements associated with them, such as: resources required by mobile edge applications, maximum delay, required services or useful services, etc.
  • the mobile edge platform manager MEPM mainly has the following functions: manage the life cycle of mobile edge applications, such as: notify the mobile edge coordinator/orchestrator of related events of the mobile edge application; provide element management functions for the mobile edge platform; manage mobile The rules and requirements of edge applications, such as: management of service authorization, traffic rules, domain name system (DNS) configuration and conflict resolution of mobile edge applications.
  • manage the life cycle of mobile edge applications such as: notify the mobile edge coordinator/orchestrator of related events of the mobile edge application; provide element management functions for the mobile edge platform; manage mobile
  • the rules and requirements of edge applications such as: management of service authorization, traffic rules, domain name system (DNS) configuration and conflict resolution of mobile edge applications.
  • DNS domain name system
  • Virtualized Infrastructure Manager which can support the virtualized management of VMs and the management of containers, mainly has the following two major functions.
  • the mobile edge coordinator/orchestrator MEO is the core functional component of the mobile edge system. It mainly has the following functions: maintain the overall view resources of the mobile edge system, available mobile edge services and topology according to the deployment of the mobile edge host; according to the constraints (E.g. delay of mobile edge applications, etc.) Select appropriate mobile edge hosts to provide available resources and available services for the instantiation of mobile edge applications; trigger the instantiation or termination of mobile edge applications; trigger the relocation of mobile edge applications; manage the mobile edge hosts Container resources, such as tracking the available resource capacity of the container, and managing container mirroring, etc.
  • the operation support system can be the operator's OSS. It can receive requests from the CFS portal (or terminal application) to instantiate or terminate the application, and forward the received request to the mobile edge coordinator/orchestrator, and the mobile edge coordinator/orchestrator according to the request Perform the follow-up process.
  • the terminal can be called terminal equipment (terminal equipment) or user equipment (UE) or mobile station (mobile station, MS) or mobile terminal equipment (mobile terminal, MT), etc., and an application (application , APP) icon.
  • the terminal may be a mobile phone, a tablet computer, a desktop, a laptop, a handheld computer, a notebook computer, a personal computer (PC), a netbook, a cellular phone, and a personal digital assistant (PDA), Wearable devices (such as smart watches), smart home devices, on-board computers, etc., the specific form of the device is not particularly limited in this embodiment.
  • the mobile edge hosts and the components in the mobile edge hosts can communicate with each other through the mobile edge point (Mp) interface, and the mobile edge hosts and other devices in the MEC system They can communicate with each other through mobile edge management (mobile edge management, Mm), and other devices in the MEC system except the mobile edge host can also communicate with each other through the Mm interface.
  • Mp mobile edge point
  • Mm mobile edge management
  • the equipment in the MEC system and the terminal or the CFS portal can communicate with each other through an interface (such as an Mx interface) with an external entity.
  • the mobile edge platform and mobile edge applications 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
  • the mobile edge hosts can communicate with each other through Mp3. Communication.
  • the OSS and the mobile edge coordinator/orchestrator can communicate with each other through Mm1, and the 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 virtualization 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 life cycle management agent and OSS can communicate with each other through Mm8, and the user application life cycle 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 life cycle management agent can communicate with each other through Mx2, and the app on the terminal can send a request to the user application life cycle management agent through Mx2, requesting to run the mobile edge application or move the mobile edge application into/out of the mobile edge system .
  • Fig. 1 is only an exemplary drawing, and the number of network elements included in the MEC system shown in Fig. 1 is not limited. In addition to the network elements shown in Fig. 1, the MEC system may also include other equipment and the like. In addition, the name of each device and the name of the interface between the devices in FIG. 1 are not limited. In addition to the names shown in FIG. 1, each device and the interface between the devices can also be named other names without limitation.
  • a new functional entity of the deployment container can be added to the MEC system, so that the newly added functional entity supports the management of the container (such as: Deployment, deletion, etc.) to implement the deployment of containers in the MEC system.
  • the enhanced MEC system can refer to FIG. 2.
  • the MEC system may include: mobile edge host level and mobile edge system level (mobile edge system).
  • the mobile edge host level may include: multiple mobile edge hosts, mobile edge platform managers (mobile edge platform managers, MEPM), virtualisation infrastructure managers (VIM), and container foundations Architecture manager (container infrastructure manager, CIM).
  • the mobile edge system level can include: CFS portal (CFS portal), terminal, user application lifecycle management agent (user app LCM proxy), operation support system (operations support system), and mobile edge coordinator/orchestrator (mobile edge orchestrator, MEO) etc.
  • the mobile edge host in Figure 2 may be a physical host, which is mainly used to provide computing, storage, and network resources for mobile edge applications.
  • the mobile edge host may include a mobile edge platform (mobile edge platform), multiple mobile edge applications (ME APP), virtualisation infrastructure (VI) and container infrastructure (CI).
  • CI has the function of a container engine, such as the function of a docker engine.
  • the CIM shown in Figure 2 can support container management.
  • Mainly has the following functions: 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 container-related resource performance and faults Information etc.
  • 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 container-related resource performance and faults Information etc.
  • CIM and VIM can be independently deployed in the MEC system shown in Figure 2, or centrally deployed in the same functional entity, without limitation.
  • the example of this application only uses CIM and VIM to be deployed independently in the MEC shown in Figure 2. The system is described as an example.
  • the mobile edge hosts and the components in the mobile edge hosts can communicate with each other through the mobile edge platform interface (mobile edge point, Mp), and the mobile edge host and MEC Other devices in the 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 host can also communicate with each other through the Mm interface.
  • the equipment in the MEC system and the terminal or the CFS portal can communicate with each other through an interface (such as an Mx interface) with an external entity. Refer to Figure 2 for specific interfaces.
  • Fig. 2 is only an exemplary drawing, and the number of network elements included in the MEC system shown in Fig. 2 is not limited. In addition to the network elements shown in Fig. 2, the MEC system may also include other equipment and the like. In addition, the name of each device and the name of the interface between the devices in FIG. 2 are not limited. In addition to the names shown in FIG. 2, each device and the interface between the devices can also be named other names without limitation.
  • FIG. 3 is a method for deploying virtualization and containers provided by an embodiment of the application. As shown in FIG. 3, the method may include steps 301 to 308:
  • Step 301 The unified orchestration function entity receives the deployment request.
  • the unified orchestration function entity may be a chip or a system on a chip in the MEO or MEO that can implement the functions performed by the unified orchestration function entity in the embodiments of this application, or it may be MEPM or MEPM that can implement the unified orchestration function in the embodiments of this application.
  • the chip or system-on-chip of the function performed by the entity, or the unified orchestration functional entity may include multiple functional modules for executing the method described in the embodiments of the present application, and some of the multiple functional modules are located in the MEO , The remaining modules are located in MEPM and are not restricted.
  • the embodiment of the present application only takes the unified orchestration function entity as the MEO or MEPM as an example for description.
  • the deployment request can be used to request the instantiated deployment of an application.
  • the application can be a third-party business application (application, APP), such as QQ games, large-scale mobile games, and video surveillance programs in the MEC system ( Face recognition, data analysis, etc.), the deployment mode of the application may include but not limited to VM deployment or container deployment.
  • the application program can be uniquely identified by the application program's (indentity, ID), and the ID of different application programs may be different.
  • the ID of the application program may be a unique identifier assigned by the MEO after the application program is successfully on-boarded to the MEC system.
  • the deployment request may include, but is not limited to, the identity (ID) of the application program and arrangement information, and may also include other information, which is not limited.
  • the orchestration information may include resource information required for the instantiated deployment of the application, such as the mirror address of the application, disk type, storage volume name, disk size, etc., and may also include the orchestration type (VM or container), and so on.
  • the arrangement information can be tosca type or yaml type based on kubernetes.
  • the arrangement information may include keywords or some special parameters, and the arrangement information can be identified by the keywords or these special parameters.
  • the orchestration information may be as follows, which may include basic information of the application program and storage resources of the application program, etc., where the basic information of the application program may include basic node information, application How the program is deployed, stored information, etc.
  • Basic node information can include “node template (node_templates), software development tool (sdk-appgroud), node type (type: hwpaas.node.Appgroup), requirements (requirements), member (member), node name (node: sdk- app), node relationship (relationship: hwpass.relationships.Consistsof), etc.
  • Application deployment methods can include: application package (package), node deployment method (node: sdk-VM), node relationship (relationship: hwpass.relationship) .PackageConsistsor).
  • Storage information can include "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.
  • Application storage resources can include: system disk (system_disk), type (type: hwpaas.nodes.LocalVolume), properties (properties), type (type: local_storage), name (name: test), lvmType: system, volume type (volumeType:high IO), device (devices:/dev/sdc), volume type (volumeType: "high IO"), size (size:20G), mode (mode:private), stripe (stripe:true), delete Policy (deletePolicy: reserved), etc.
  • volumeType "high IO"
  • the unified orchestration function entity receiving the deployment request may include: the unified orchestration function entity receives the deployment request sent by the OSS through Mm1, where the deployment The request can be sent to the OSS by the CFS portal or the user app LCM proxy; or, the unified orchestration function entity receives the deployment request sent by the user app LCM proxy through Mm9, where the deployment request can be sent by the APP on the terminal to the user app LCM proxy.
  • the unified orchestration function entity receiving the deployment request may include: the unified orchestration function entity receives the deployment request sent by the OSS through Mm2, where the The deployment request can be sent to the OSS by the CFS portal or the user app LCM proxy; or the unified orchestration function entity receives the deployment request sent by the MEO through the Mm3, where the MEO can obtain the deployment request in the above manner and send it to the MEPM, which will not be repeated.
  • the method may further include: MEO obtains instance configuration data of the application, and forwards the deployment to MEPM according to the instance configuration data of the application request.
  • the instance configuration data of the application can include information such as the node where the instance of the application is deployed, the method of deployment, and the resources (such as computing resources, network resources, and storage resources, etc.) required to deploy the instance of the application in such a deployment method. .
  • the MEO forwarding the deployment request to MEPM according to the instance configuration data of the application may include: in the case of deploying the instance of the application in the deployment mode specified by the instance configuration data of the application, if there is a deployment method for the application in the MEC system The node of the instance and the resources needed to deploy the instance of the application will forward the deployment request to MEPM; otherwise, it will refuse to forward the deployment request to MEPM.
  • Step 302 The unified orchestration function entity determines the deployment mode of the application according to the deployment request.
  • the deployment request includes orchestration information.
  • the types of orchestration information are different.
  • the orchestration information can be of the tosca type.
  • the orchestration information can be of yaml type.
  • the unified orchestration function entity 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 VM deployment; if the orchestration information is of the yaml type, the deployment method of the application is determined to be container deployment.
  • the unified layout function entity may include keywords included in the layout information to determine the type of the layout information.
  • the orchestration information includes the orchestration type (VM or container). If the orchestration type is VM, the orchestration information is determined to be the tosca type, and the deployment method of the application is VM deployment. On the contrary, if the orchestration type is the container, the orchestration information is determined to be yaml type, the deployment method of the application is container deployment.
  • the deployment request may include a deployment type identifier, which may be used to indicate the deployment mode of the application.
  • the unified orchestration function entity After the unified orchestration function entity receives the deployment request, it can parse the deployment request and base the deployment request on the deployment request. Type identification, which determines how the application is deployed.
  • the deployment type identifier can be a number of binary bits, such as 0 or 1, "0" means VM deployment, "1" means container deployment, and can also be other identifiers (indentity) used to indicate the deployment method of the application. For example, it can be a combination of numbers, letters, symbols and other information in any form that is easy for users to understand, and there is no restriction.
  • deployment type identifier may be included in the newly added information element in the deployment request, or may be included in the scheduling information included in the deployment request, and is not limited.
  • the deployment request may also include other information.
  • the deployment request can forcibly include the deployment type identification (or called the deployment method) and the ID of the application instance ( Or application ID), virtual storage information (virtual storage desciptor), mobile edge host information (selected ME HostInfo), and optionally, virtual machine description (virtual compute description), container description (container description), etc.
  • N is an integer greater than 1.
  • the deployment request may include the application ID, and there is a correspondence between the application ID and the deployment mode of the application.
  • the unified orchestration function entity can parse the deployment request, and determine the application requested by the deployment request according to the ID of the application included in the deployment request and the correspondence between the ID of the application stored in advance and the deployment mode of the application How the program is deployed.
  • the ID of the application program 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.
  • the ID of the application and the deployment method of the application can be pre-stored in the MEO or MEPM.
  • the MEO can receive an on-board application request sent by the OSS including the application and the deployment method of the application. ,Onboard the application according to the request of the on-board application.
  • MEO can assign a unique ID to the application and correspond the application’s ID to the deployment method of the application. Stored on MEO or MEPM.
  • Table 2 shows the correspondence between the application ID and the deployment mode of the application.
  • the deployment mode corresponding to APP 1 is container deployment
  • the deployment mode of APP 2 is container deployment
  • APP 3 The deployment method is container deployment.
  • the unified orchestration function entity may use APP 1 as an index to look up Table 2 and determine that the deployment mode corresponding to APP 1 is VM deployment.
  • the unified orchestration function entity may use APP 2 as an index to query Table 2, and determine that the deployment mode corresponding to APP 2 is container deployment.
  • the unified orchestration function entity may use APP 3 as an index to look up Table 2 and determine that the deployment mode corresponding to APP 3 is container deployment.
  • step 302 if it is determined in step 302 that the deployment method of the application program is container deployment, step 303 to step 305 are performed; if the deployment method of the application program is VM deployment, step 306 to step 308 are performed:
  • Step 303 The unified orchestration function entity sends a first resource allocation request to the architecture manager.
  • the architecture manager when the method shown in FIG. 3 is executed based on FIG. 1, the architecture manager may be the VIM in FIG. 1 or the functional modules in the VIM, for example, it may be the VIM that can execute the execution of the architecture manager in the embodiment of this application.
  • the chip or system-on-chip, etc. of the functions performed by the architecture manager are not limited. The embodiment of the present application is only described by taking the architecture manager as the VIM in FIG. 1 or the CIM in FIG. 2 as an example.
  • the first resource allocation request may be used to request resources required to deploy a container capable of running the instance of the application program; such as computing resources, network resources, storage resources, and so on.
  • the first resource allocation request may include the ID of the application program, the identifier of the container deployment, and resource information required to deploy the application program in the container deployment manner.
  • the container deployment identifier can be used to identify that the deployment mode of the application is container deployment.
  • the resource information required for container deployment may include computing resources, storage resources, and network resources required to deploy the application in a container deployment manner.
  • the resource information required for container deployment may specifically include: container image address, disk type, volume name, disk size, and so on.
  • the unified orchestration function entity when the unified orchestration function entity is MEO and the architecture manager is the VIM in FIG. 1, as shown in FIG. 1, the unified orchestration function entity may send the first resource allocation request to the architecture manager through Mm4.
  • the unified orchestration function entity When the unified orchestration function entity is MEPM and the architecture manager is the VIM in FIG. 1, as shown in FIG. 1, the unified orchestration function entity can send the first resource allocation request to the architecture manager through Mm6.
  • the unified orchestration function entity When the unified orchestration function entity is the MEO and the architecture manager is the CIM in FIG. 2, as shown in FIG. 2, the unified orchestration function entity can send the first resource allocation request to the architecture manager through Mm10.
  • the unified orchestration function entity When the unified orchestration function entity is MEPM and the architecture manager is the CIM in FIG. 2, as shown in FIG. 2, the unified orchestration function entity can send the first resource allocation request to the architecture manager through Mm11.
  • Step 304 The architecture manager receives the first resource allocation request, and deploys a container capable of running an instance of the application according to the first resource allocation request.
  • the manner in which the architecture manager deploys a container capable of running an instance of the application program according to the first resource allocation request can refer to the existing technology, for example: the architecture manager finds the container mirror warehouse according to the container mirror address, and downloads from the container mirror warehouse The container image of the application; call the storage plug-in to request the creation of a storage volume; request the container engine to create a pause container; request the network plug-in to create CNI Add() and request the container engine to create and run the container.
  • the architecture manager needs to check whether there is a container image of the application in the container image warehouse. If it does not exist, the application container The deployment failed; if it exists, check whether the container image of the application is available, if it is available, download the container image from the container mirror warehouse, and execute the container deployment process. If it is not available, the container deployment of the application fails.
  • the container image warehouse stores the application ID and application status information (available or unavailable, etc.). If the container image has the same ID as the application ID included in the first resource allocation request, the container is determined The container image of the application exists in the mirror warehouse, and vice versa, it does not exist; if the status information of the application identified by the application ID included in the first resource allocation request is available, the status of the application in the container warehouse is determined The container image is available, otherwise, it is not available.
  • Step 305 The architecture manager sends a first resource allocation response to the unified orchestration function entity.
  • the first resource allocation response may be used to instruct the architecture manager to successfully deploy the container.
  • the first resource allocation response may include the ID of the application.
  • the architecture manager when the architecture manager is the MEO and the architecture manager is the VIM in FIG. 1, as shown in FIG. 1, the architecture manager may send the first resource allocation response to the unified orchestration function entity through Mm4.
  • the architecture manager can send the first resource allocation response to the unified orchestration function entity through Mm6.
  • the architecture manager may send the first resource allocation response to the unified orchestration function entity through Mm10.
  • the architecture manager may send the first resource allocation response to the unified orchestration function entity through Mm11.
  • Step 306 The unified orchestration function entity sends a second resource allocation request to the VIM.
  • the second resource allocation request may be used to request resources required to deploy a VM capable of running the instance of the application program; such as computing resources, network resources, storage resources, and so on.
  • the second resource allocation request may include the ID of the application program, the identification of the VM deployment, and resource information required to deploy the application program in the VM deployment manner.
  • the ID of VM deployment may be used to identify the deployment mode of the application as VM deployment.
  • the resource information required for VM deployment may include computing resources, storage resources, and network resources required for deploying the application in a VM deployment manner.
  • the resource information required for VM deployment may specifically include: VM mirror address, disk type, volume name, disk size, and so on.
  • the unified orchestration function entity may send a second resource allocation request to the VIM through Mm6.
  • Step 307 The VIM receives the second resource allocation request, and deploys a VM capable of running an instance of the application program according to the second resource allocation request.
  • VIM can download the VM image of the application program from the VM image warehouse according to the VM image address;
  • the storage plugin requests to create a storage volume;
  • VIM needs to check whether the VM image of the application exists in the VM mirror warehouse. If it does not exist, the VM deployment of the application fails; If it exists, check whether the VM image of the application is available. If it is available, download the VM image from the VM mirror warehouse and execute the VM deployment process. If it is not available, the VM deployment of the application fails.
  • the ID of the application and the status information of the application are stored in the VM mirror warehouse. If the VM mirror has the same ID as the ID of the application included in the second resource allocation request, the VM is determined The VM image of the application exists in the mirror warehouse, otherwise, it does not exist; if the status information of the application identified by the ID of the application included in the second resource allocation request is available, it is determined that the application status information exists in the VM warehouse The VM image is available, and vice versa, it is not available.
  • Step 308 VIM sends a second resource allocation response to the unified orchestration function entity.
  • the second resource allocation response can be used to indicate that the VIM successfully deploys the VM.
  • the second resource allocation response may include the ID of the application.
  • the VIM may send a second resource allocation response to the unified orchestration function entity through Mm6.
  • the received request can be analyzed to determine the deployment method (container deployment or VM deployment) of the application requested to be deployed. If it is a container deployment, send to VIM or CIM sends a resource allocation request, requesting to deploy the resources required by the application in the container deployment method, and complete the container deployment of the application; if it is a VM deployment, send a resource allocation request to VIM to request the deployment of the application in the VM deployment method Required resources to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be implemented in the MEC system.
  • the deployment method container deployment or VM deployment
  • the unified orchestration function entity may send the first configuration request to the MEP.
  • the first configuration request can 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 that are followed by the instance of the application running on the container.
  • DNS domain name system
  • a configuration request may include traffic rules, DNS rules, required and optional services, and services generated by the application instance running on the container.
  • the MEP can configure traffic rules, DNS rules, etc.
  • the response to the configuration request can be used to indicate that the configuration of the traffic rules, DNS rules, etc. followed by the application instance is successful.
  • 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 an instance of the application running on the VM.
  • the second configuration request may include traffic rules, DNS rules, required and optional services, and services generated by the application instance running on the container.
  • the MEP can configure traffic rules, DNS rules, etc. for the application instance 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.
  • the response to the configuration request can be used to indicate that the configuration of the traffic rules, DNS rules, etc. followed by the application instance is successful.
  • the MEO may forward the first resource allocation response or the second resource allocation response it receives to the MEPM, so that the MEPM receives the first resource allocation response or the second resource allocation response After performing the above process, I will not repeat it.
  • MEPM can consider the application After instantiated deployment is complete, you can send a response to the deployment request to OSS or through MEO to OSS.
  • 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 instantiated deployment of the application.
  • the response to the deployment request can include resource information allocated to the instance of the application. For example, it may include computing resources, network resources, and storage resources that are finally allocated to the instance of the application.
  • the application instance can also be terminated and the resources occupied by the application instance are released.
  • the process of terminating the instance of the application program can be referred to as shown in FIG. 4, which may include:
  • Step 401 The unified orchestration function entity receives the termination request.
  • the unified orchestration function entity can be described in step 301, which will not be repeated.
  • the termination request may be used to request the termination of the instance of the application program, and the termination request may include the ID of the application program.
  • the instance of the application may be an instance deployed through a container deployment method or a VM deployment method.
  • the termination request can forcibly include the termination type (termination type), the ID of the application instance (or the ID of the application), and optionalally, it also includes graceful termination timeout, etc.
  • N is an integer greater than 1.
  • the unified orchestration functional entity receiving the termination request may include: the unified orchestration functional entity receives the termination request sent by the OSS through Mm1, where the termination request may be The CFS portal or the user app LCM proxy is sent to the OSS; or the unified orchestration function entity receives the termination request sent by the user app LCM proxy through Mm9, where the termination request can be sent to the user app LCM proxy by the APP on the terminal.
  • the unified orchestration functional entity receiving the termination request may include: the unified orchestration functional entity receives the termination request sent by the OSS through Mm2, where the The termination request can be sent to the OSS by the CFS portal or the user app LCM proxy; or the unified orchestration function entity receives the termination request sent by the MEO through the Mm3, where the MEO can obtain the termination request in the above-mentioned manner and send it to the MEPM, which will not be repeated.
  • Step 402 The unified orchestration function entity sends a termination request to the MEP.
  • Step 403 The MEP receives the termination request, and terminates the application instance according to the termination request.
  • the instance in which the MEP terminates the application according to the termination request in step 403 can also be described as an instance in which the MEP destroys the application according to the termination request, which is not limited.
  • the MEP terminating the instance of the application program according to the termination request may include: the MEP sends a termination notification to the instance of the application program through Mp1, and the instance of the application program receives the termination notification and terminates the instance of the application program according to the termination notification. , And sends a termination response to the MEP. After receiving the termination response, the MEP considers the application instance to have terminated.
  • a timer can be set in the MEP. After the MEP sends a termination notification to the application instance through Mp1, the on timer is started. When the timer expires, the application instance is terminated without receiving After the termination response sent by the instance of the application, the instance of the application is terminated.
  • Step 404 The MEP sends a termination response to the unified orchestration function entity.
  • the termination response can be used to indicate the successful termination of the instance of the application.
  • 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, perform steps 406 to step 408; if the deployment mode of the application is VM deployment, perform step 409 ⁇ Step 411.
  • step 405 the process of determining the deployment mode of the application by the unified orchestration function entity can refer to the description in step 302, and will not be repeated.
  • Step 406 The unified orchestration function entity sends a first resource deletion request to the architecture manager.
  • the architecture manager as described in step 303, may be VIM or CIM.
  • the first resource deletion request may be used to request the framework manager to delete the container used to run the instance of the application program.
  • Step 407 The architecture manager receives the first resource deletion request, and deletes the container according to the first resource deletion request.
  • the way the architecture manager deletes the container according to the first resource deletion request can refer to the prior art.
  • the architecture manager can delete (or release) all the resources occupied by the container, such as computing resources, storage resources, network resources, etc. Wait.
  • Step 408 The architecture manager sends a first resource deletion response to the unified orchestration function entity, and the unified orchestration function entity receives the first resource deletion request.
  • the first resource deletion response may be used to indicate that the container corresponding to the instance of the application program is successfully deleted.
  • Step 409 The unified orchestration function entity sends a second resource deletion request to the VIM.
  • the second resource deletion request may be used to request the VIM to delete the VM used to run the instance of the application program.
  • Step 410 The VIM receives the second resource deletion request, and deletes the VM according to the second resource deletion request.
  • Step 411 VIM sends a second resource deletion response to the unified orchestration function entity, and the unified orchestration function entity receives the second resource deletion request.
  • the second resource deletion response may be used to indicate that the VM corresponding to the instance of the application is successfully deleted.
  • Step 412 The unified orchestration function entity sends a response to the termination request.
  • 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, and the response to the termination request may be used to indicate the successful termination of the instance of the application and the deletion of the instance of the application. Resources occupied.
  • the unified orchestration function entity may send a response to the termination request to the OSS.
  • the following describes the method shown in FIG. 3 with reference to the MEC system shown in FIG. 1, taking the unified orchestration function entity as the MEPM and the architecture manager as the VIM as an example.
  • Fig. 5a is a flow chart of another method for deploying virtual machines and containers according to an embodiment of the application. As shown in Fig. 5a, the method may include:
  • Step 501a OSS sends a deployment request to MEO.
  • the relevant description of the deployment request can refer to the description in step 301, which will not be repeated.
  • Step 502a MEO receives the deployment request, and sends the deployment request to MEPM.
  • Step 503a 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, perform steps 504a to 506a; if the deployment mode of the application is VM deployment, perform step 507a ⁇ Step 509a.
  • step 503a can refer to the description of step 302, and will not be repeated.
  • Step 504a MEPM sends a first resource allocation request to VIM.
  • step 504a For the related description of the first resource allocation request and the execution process of step 504a, please refer to the description of step 303, which will not be repeated.
  • Step 505a The VIM receives the first resource allocation request, and deploys a container capable of running an instance of the application according to the first resource allocation request.
  • step 505a can refer to the description of step 304, and will not be repeated.
  • Step 506a VIM sends a first resource allocation response to MEPM, and MEPM receives the first resource allocation response.
  • step 506a can refer to the description of step 305, and will not be repeated.
  • Step 507a MEPM sends a second resource allocation request to VIM.
  • step 507a For the related description of the second resource allocation request and the execution process of step 507a, refer to the description of step 306, and will not be repeated.
  • Step 508a The VIM receives the second resource allocation request, and deploys a VM capable of running an instance of the application program according to the second resource allocation request.
  • step 508a can be referred to as described in step 307, which will not be repeated.
  • Step 509a VIM sends a second resource allocation response to MEPM, and MEPM receives the second resource allocation response.
  • step 510a can refer to the description of step 308, and will not be repeated.
  • Step 510a MEPM sends a response to the deployment request to MEO.
  • Step 511a The MEO receives the response to the deployment request, and sends the response to the deployment request to the OSS.
  • the received request can be analyzed to determine the deployment method (container deployment or VM deployment) of the application requested to be deployed. If it is a container deployment, send to VIM sends a resource allocation request to request the resources needed to deploy the application in the container deployment method, and complete the container deployment of the application; if it is a VM deployment, it sends a resource allocation request to VIM to request the deployment of the application in the VM deployment method Resources to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be implemented in the MEC system.
  • the deployment method container deployment or VM deployment
  • Figure 5b is a flow chart of another method for deploying virtual machines and containers according to an embodiment of this application. As shown in Figure 5b, the method may include:
  • Step 501b OSS sends a deployment request to MEO.
  • the relevant description of the deployment request can refer to the description in step 301, which will not be repeated.
  • Step 502b MEO receives the deployment request and sends the deployment request to MEPM.
  • 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, perform steps 504b to 506b; if the deployment mode of the application is VM deployment, perform step 507b ⁇ Step 509b.
  • step 503b can refer to the description of step 302, and will not be repeated.
  • Step 504b MEPM sends a first resource allocation request to CIM.
  • step 504b For the related description of the first resource allocation request and the execution process of step 504b, please refer to the description of step 303, which will not be repeated.
  • Step 505b The CIM receives the first resource allocation request, and deploys a container capable of running an instance of the application according to the first resource allocation request.
  • step 505b can refer to the description of step 304, and will not be repeated.
  • Step 506b CIM sends a first resource allocation response to MEPM, and MEPM receives the first resource allocation response.
  • step 506b can refer to the description of step 305, and will not be repeated.
  • Step 507b MEPM sends a second resource allocation request to VIM.
  • step 306 For the related description of the second resource allocation request and the execution process of step 507b, refer to the description of step 306, which will not be repeated.
  • Step 508b The VIM receives the second resource allocation request, and deploys a VM capable of running an instance of the application according to the second resource allocation request.
  • step 508b can refer to the description of step 307, and will not be repeated.
  • Step 509b VIM sends a second resource allocation response to MEPM, and MEPM receives the second resource allocation response.
  • step 509b can refer to the description of step 308, and will not be repeated.
  • Step 510b MEPM sends a response to the deployment request to MEO.
  • Step 511b The MEO receives the response to the deployment request, and sends the response to the deployment request to the OSS.
  • the received request can be analyzed to determine the deployment method (container deployment or VM deployment) of the application requested to be deployed. If it is a container deployment, send to CIM sends a resource allocation request, requesting the resources needed to deploy the application in the container deployment method, and completes the container deployment of the application; if it is a VM deployment, it sends a resource allocation request to VIM to request the deployment of the application in the VM deployment method Resources to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be implemented in the MEC system.
  • the deployment method container deployment or VM deployment
  • the instance of the application can also be terminated and the resources occupied by the instance of the application can be released.
  • the process of terminating the application instance will be described through the method shown in FIG. 6a or FIG. 6b.
  • FIG. 6a is a flowchart of a method for terminating an application program according to an embodiment of the application. As shown in FIG. 6a, the method may include:
  • Step 601a OSS sends a termination request to MEO.
  • step 401 For the related description of the termination request, please refer to the description in step 401, which is not repeated here.
  • Step 602a MEO receives the termination request and sends the termination request to MEPM.
  • Step 603a The MEPM receives the termination request and sends the termination request to the MEP.
  • Step 604a The MEP receives the termination request, and terminates the application instance according to the termination request.
  • step 604a can refer to the description of step 403, and will not be repeated.
  • Step 605a The MEP sends a termination response to the MEPM.
  • step 605a For the related description of the termination response and the execution process of step 605a, please refer to the description of step 404, which will not be repeated.
  • Step 606a MEPM determines the deployment mode of the application program. If the deployment mode of the application program is container deployment, perform steps 607a to 609a; if the deployment mode of the application program is VM deployment, perform steps 610a to step 612a.
  • step 606a can refer to the description of step 405, and will not be repeated.
  • Step 607a MEPM sends a first resource deletion request to VIM.
  • step 607a For the related description of the first resource deletion request and the execution process of step 607a, please refer to the description of step 406, which will not be repeated.
  • Step 608a VIM receives the first resource deletion request, and deletes the container according to the first resource deletion request.
  • step 608a can refer to the description of step 407, and will not be repeated.
  • Step 609a VIM sends a first resource deletion response to MEPM, and MEPM receives the first resource deletion response.
  • step 609a can refer to the description of step 408, and will not be repeated.
  • Step 610a MEPM sends a second resource deletion request to VIM.
  • step 610a For the related description of the second resource deletion request and the execution process of step 610a, refer to the description of step 409, which will not be repeated.
  • Step 611a The VIM receives the second resource deletion request, and deletes the VM according to the second resource deletion request.
  • step 611a can refer to the description of step 410, and will not be repeated.
  • Step 612a VIM sends a second resource deletion response to MEPM, and MEPM receives the second resource deletion response.
  • step 612a can refer to the description of step 411, which will not be repeated.
  • Step 613a MEPM sends a response to the termination request to MEO.
  • Step 614a The MEO receives the response to the termination request, and sends the response to the termination request to the OSS.
  • corresponding termination processing can be performed according to the deployment method of the application, such as: if the deployment method is container deployment, send the first resource delete to VIM Request, request VIM to delete the container resource occupied by the instance of the application; or, if the deployment mode is VM deployment, send a second resource deletion request to VIM to request VIM to delete the VM resource occupied by the instance of the application.
  • the deployment method is container deployment
  • send the first resource delete to VIM Request request VIM to delete the container resource occupied by the instance of the application
  • the deployment mode is VM deployment
  • send a second resource deletion request to VIM to request VIM to delete the VM resource occupied by the instance of the application In this way, it is possible to request the architecture manager or VIM to delete the instance of the application without requiring an instance of the application.
  • Fig. 6b is a flowchart of another method for terminating an application program according to an embodiment of the application. As shown in Fig. 6b, the method may include:
  • Step 601b OSS sends a termination request to MEO.
  • step 401 For the related description of the termination request, please refer to the description in step 401, which is not repeated here.
  • Step 602b MEO receives the termination request and sends the termination request to MEPM.
  • Step 603b The MEPM receives the termination request and sends the termination request to the MEP.
  • Step 604b The MEP receives the termination request, and terminates the instance of the application program according to the termination request.
  • step 604b can refer to the description of step 403, and will not be repeated.
  • Step 605b The MEP sends a termination response to the MEPM.
  • step 605b For the related description of the termination response and the execution process of step 605b, refer to the description of step 404, which will not be repeated.
  • Step 606b MEPM receives the termination request and determines the deployment mode of the application. If the deployment mode of the application is container deployment, perform steps 607b to 609b; if the deployment mode of the application is VM deployment, perform steps 610b to 612b .
  • step 606b can refer to the description of step 405, which will not be repeated.
  • Step 607b MEPM sends a first resource deletion request to CIM.
  • step 406 For the related description of the first resource deletion request and the execution process of step 607b, please refer to the description of step 406, which will not be repeated here.
  • Step 608b The CIM receives the first resource deletion request, and deletes the container according to the first resource deletion request.
  • step 608b can refer to the description of step 407, and will not be repeated.
  • Step 609b CIM sends a first resource deletion response to MEPM, and MEPM receives the first resource deletion response.
  • step 609b can refer to the description of step 408, and will not be repeated.
  • Step 610b MEPM sends a second resource deletion request to VIM.
  • step 610b For the related description of the second resource deletion request and the execution process of step 610b, refer to the description of step 409, which will not be repeated.
  • Step 611b The VIM receives the second resource deletion request, and deletes the VM according to the second resource deletion request.
  • step 611b can refer to the description of step 410, and will not be repeated.
  • Step 612b VIM sends a second resource deletion response to MEPM, and MEPM receives the second resource deletion response.
  • step 612b can refer to the description of step 411, and will not be repeated.
  • Step 613b MEPM sends a response to the termination request to MEO.
  • Step 614b The MEO receives the response to the termination request, and sends the response to the termination request to the OSS.
  • the corresponding termination processing can be performed according to the deployment mode of the application, such as: if the deployment mode is container deployment, send the first resource delete to CIM Request, request CIM to delete the container resource occupied by the instance of the application; or, if the deployment mode is VM deployment, send a second resource deletion request to VIM to request the VIM to delete the VM resource occupied by the instance of the application. In this way, it is possible to request the architecture manager or VIM to delete the instance of the application without requiring an instance of the application.
  • the container image warehouse may store a container image file, and the container image file may store an application deployed by the container.
  • a VM image file can be stored in the VM image warehouse, and the VM image file can store applications deployed by VM.
  • the container image warehouse and the VM image warehouse can include one or more applications, each application Can be uniquely identified by the ID of the application.
  • the application program may be stored in a mirror warehouse (container mirror warehouse or VM mirror warehouse) through an on-boarding process. Specifically, the process may be as shown in Figure 7a, including:
  • Step 701a OSS sends an onboard application request to MEO.
  • the onboard application request can be used to request that the application be loaded into the MEC system.
  • the onboard application request can include the application and the deployment type identification, and the deployment type identification can be used to identify the application as a container deployment Application or VM deployment application.
  • the on-board application request may also include the container image address.
  • the on-board application request may also include the VM
  • the mirror address is not limited in this embodiment of the application.
  • the OSS may receive the on-board application request sent by the CFS portal or the user app LCM proxy, and forward the received on-board application request to the MEO.
  • Step 702a The MEO receives the onboard application request, and saves the application in the mirror warehouse.
  • the mirror warehouse can be deployed in MEO or MEPM without limitation.
  • the image warehouse can include container image warehouse and VM image warehouse. If the deployment type identifier is used to identify the application as a container image, the application is saved in the container image warehouse. If the deployment type identifier is used to identify the application as a VM application, Then save the application to the VM mirror warehouse.
  • 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: can assign the status of the application to be available or unavailable, etc.
  • Step 703a The MEO sends a response to the onboard application request to the OSS.
  • the response requested by the onboard application can be used to indicate that the application is successfully onboard (or saved) to the MEC system.
  • the response of 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.
  • the application included in the on-board application request can include mandatory elements.
  • the MEO receives the on-board application request, it can verify the mandatory elements included in the application and Whether the agreed elements are the same, if they are the same, it means that the application has the integrity and authenticity and can be saved in the MEC system; on the contrary, if the mandatory elements included in the application are different from the agreed elements, it means that the application has been tampered with, etc. The application was saved to the MEC system, and the application failed to load.
  • the agreed element may be an element that is predetermined between the OSS and the MEO and can be used to verify the authenticity and integrity of the application.
  • the application program can be board-loaded into the MEC system, and the application program is available in the MEC system and can be instantiated and deployed.
  • MEO can manage the onboard applications as follows: query, disable (or disable), enable (enable), delete, etc.
  • query can be performed as follows: query, disable (or disable), enable (enable), delete, etc.
  • Figure 7b for the process of querying the application
  • Figure 7c for the process of disabling the application
  • Figure 7d for the process of enabling the application
  • Figure 7e for the process of deleting the application.
  • FIG. 7b is a flowchart of a query application program provided by an embodiment of the application. As shown in FIG. 7b, it may include:
  • Step 701b OSS sends an application query request to MEO.
  • the query application request can be used to request related information of the query application, such as the rules and requirements of the application.
  • the application query request may include the ID of the application, and may also include other information, such as filter conditions, etc., without limitation.
  • the OSS may receive the query application request sent by the CFS portal or the user bpp LCM proxy, and forward the received query application request to the MEO.
  • Step 702b The MEO receives the application query request, and queries the application related information from the mirror warehouse.
  • MEO queries the relevant information of the application from the container image warehouse; if the application is a VM application, MEO queries the relevant information of the application from the VM image warehouse.
  • Step 703b The MEO sends a response to the query application request to the OSS.
  • the response to the query request of the application may include relevant information of the application, such as the rules and requirements of the application.
  • the MEO may carry relevant information about the application that meets the filter condition in the response and send it to the OSS.
  • Fig. 7c is a flow chart of disabling an application provided by an embodiment of the application. As shown in Fig. 7c, it may include:
  • Step 701c OSS sends a request to disable the application to MEO.
  • the request to disable the application can be used to request to disable the application and make the application unavailable.
  • the request to disable the application may include the ID of the application, etc., and is not limited.
  • the OSS may receive a request for disabling an application sent by a CFS portal or a user bpp LCM proxy, and forward the received request for disabling the application to the MEO.
  • Step 702c The MEO receives the request for disabling the application, and confirms the disabling of the application according to the request for disabling the application.
  • MEO may first check whether the application identified by the application ID exists according to the ID of the application included in the request for disabling the application. If so, check whether the status of the application is enabled; if it is enabled The application, MEO marks the application as disabled.
  • Step 703c The MEO sends a response to disable the application to the OSS.
  • the response of the disabled application can be used to indicate that the application is disabled in the MEC system.
  • Fig. 7d is a flow chart of activating an application provided by an embodiment of the application. As shown in Fig. 7d, it may include:
  • Step 701d OSS sends a request to start the application to MEO.
  • the application activation request can be used to request the activation of the application to make the application available in the MEC system.
  • the request to activate the application may include the ID of the application, etc., without limitation.
  • the OSS may receive the application activation request sent by the DFS portal or the user bpp LDM proxy, and forward the received application activation request to the MEO.
  • Step 702d The MEO receives the application activation request, and confirms the activation of the application according to the application activation request.
  • the MEO may first check whether the application identified by the application ID exists according to the ID of the application included in the request to enable the application, and if so, check whether the application is marked as disabled and not marked as Delete pending, if yes, enable the application.
  • Step 703d The MEO sends a response to enable the application to the OSS.
  • the response of the activation application may be used to indicate that the application is activated in the MED system.
  • Fig. 7e is a flow chart of deleting an application provided by an embodiment of the application. As shown in Fig. 7e, it may include:
  • Step 701e OSS sends a request to delete the application to MEO.
  • the request to delete the application can be used to request the deletion of the application to make the application available in the MEC system.
  • the application deletion request may include the application ID and the deployment type identification (VM or container) of the application, and may also include other information, which is not limited.
  • the OSS may receive the application deletion request sent by the EFS portal or the user app LEM proxy, and forward the received application deletion request to the MEO.
  • Step 702e The MEO receives the application deletion request, and confirms the deletion of the application according to the application deletion request.
  • the 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 will set the status of the application to delete pending. If the application is disabled and not used, MEO deletes the application from the mobile edge system.
  • the MEO can determine whether the application requested to be deleted is a VM application or a container image according to the deployment type identifier (VM deployment or container deployment) included in the application deletion request. If the deletion request is a VM application, the MEO Interactively delete with the file server that stores the VM application; if it is a container image, MEO needs to access the container image warehouse and call the container engine command to delete the corresponding container image. If the application is in the deletion pending state, MEO can check all instances of the application and delete the application after the application instance is terminated. If there is no instance of the used application, MEO can delete the application.
  • the deployment type identifier VM deployment or container deployment
  • Step 703e The MEO sends a response to delete the application to the OSS.
  • the response of deleting the application may be used to indicate that the application is deleted in the MEO system.
  • each functional entity such as a unified orchestration functional entity (MEPM or MEO), VIM, etc.
  • MEPM or MEO unified orchestration functional entity
  • VIM unified orchestration functional entity
  • the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software-driven hardware depends on the specific application and design constraint conditions of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of this application.
  • the embodiment of the present application may divide the MEPM into functional modules according to the foregoing method examples.
  • each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module.
  • the above-mentioned integrated modules can be implemented in the form of hardware or software functional modules. It should be noted that the division of modules in the embodiments of the present application is illustrative, and is only a logical function division, and there may be other division methods in actual implementation.
  • Fig. 8 shows a structure diagram of a unified orchestration function entity 80.
  • the unified orchestration function entity 80 may be a chip or a system on a chip in MEO or MEO, or a chip or a system on chip in MEPM or MEPM.
  • the orchestration function entity 80 may be used to perform the functions of the unified orchestration function entity involved in the foregoing embodiments.
  • the unified orchestration function entity 80 shown in FIG. 8 includes:
  • the unified orchestration scheduling management module 801 is used to receive the deployment request and determine the deployment mode of the application program according to the deployment request.
  • the deployment request is used to request the deployment of an application program instance, and the deployment request includes the identification ID of the application program and the orchestration information.
  • the orchestration information is used to indicate the resources required to deploy the instance of the application; the deployment mode of the application includes container deployment or virtual machine VM deployment.
  • the unified orchestration scheduling management module 801 may support the unified orchestration function entity 80 to execute steps 301, 302, and so on.
  • the unified orchestration function entity 80 may also include: a container orchestration management module 802, configured to send the first to the architecture manager if the unified orchestration management module 801 determines that the deployment mode of the application is container deployment A resource allocation request, where the first resource allocation request is used to request the deployment of resources required by a container capable of running an instance of the application program.
  • the container orchestration management module 802 may be used to support the unified editing function entity 80 to execute step 303 and so on.
  • the VM scheduling management module 803 is configured to send a second resource allocation request to the VIM if the unified orchestration management module 801 determines that the deployment mode of the application program is VM deployment, where the second resource allocation request is used to request the deployment of the running application The resources required by the VM of the instance.
  • the VM scheduling management module 803 may be used to support the unified orchestration function entity 80 to execute step 306 and so on.
  • the architecture manager can be VIM or CIM, etc., without limitation.
  • the unified orchestration function entity 80 provided by the embodiment of the present application is used to perform the above-mentioned method for deploying virtual machines and containers to unify orchestrating the functions of the function entity 80, so that the same effect as the above-mentioned method for deploying virtual machines and containers can be achieved.
  • the embodiments of the present application do not limit the deployment position of the components included in the unified orchestration function entity 80.
  • the components included in the unified orchestration function entity 80 can be deployed in a centralized manner in MEO or MEPM, or separately deployed in different locations.
  • the unified orchestration and scheduling management module 801 can be deployed in the MEO
  • the container orchestration management module 802 and the VM scheduling management module 803 can be deployed in the MEPM without limitation.
  • the unified orchestration function entity 80 shown in FIG. 8 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.
  • the processing module is used to support the unified orchestration function entity 80 to perform step 301, step 302, step 303, step 306, and other processes that perform the technology described herein.
  • the communication module is used to support the unified orchestration function entity 80 to receive deployment requests and communicate with other network entities, such as communication with the function modules or network entities shown in FIG. 1.
  • the unified orchestration function entity 80 may also include a storage module for storing program codes and data of the unified orchestration function entity 80.
  • the processing module may be a processor, such as a central processing unit (CPU), a general-purpose processor network processor (NP), digital signal processing (DSP), microcomputer Processor, microcontroller, programmable logic device (PLD) or any combination of them.
  • the processor may also be any other device with processing functions, such as a circuit, a device, or a software module.
  • 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 that can realize communication.
  • devices or communication networks such as Ethernet, radio access network (RAN)
  • RAN radio access network
  • the memory can be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and/or instructions, or it can be a random access memory (RAM) or can store information and / Or other types of dynamic storage devices for instructions, which can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or Other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired commands or data structures Program code and any other medium that can be accessed by the computer, but not limited to this.
  • ROM read-only memory
  • RAM random access memory
  • EEPROM electrically erasable programmable read-only memory
  • CD-ROM compact disc read-only memory
  • Other optical disc storage optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs
  • the memory may exist independently of the processor, that is, the memory may be a memory external to the processor. In this case, the memory may be connected to the processor through a communication line for storing instructions or program codes.
  • the processor calls and executes the instructions or program codes stored in the memory, it can implement the method for deploying virtual machines and containers provided in the following embodiments of the present application.
  • 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.
  • FIG. 9 is an MEC system architecture diagram provided by an embodiment of the application. As shown in FIG.
  • the system may include: a unified orchestration function entity 80 and VIM 81, where the unified orchestration function entity 80 and the function entity shown in FIG. 8 include Same parts and same functions.
  • the unified orchestration function entity may be MEPM or MEO as shown in Fig. 1 or Fig. 2.
  • the unified orchestration function entity 80 is used to receive the deployment request and determine the deployment mode of the application according to the deployment request.
  • the deployment request is used to request to deploy an instance of the application.
  • the deployment request includes the identification ID of the application and the orchestration information.
  • the deployment method of the application includes container deployment or virtual machine VM deployment;
  • the unified orchestration function entity 80 is also used to send a first resource allocation request to VIM 81 if the deployment mode of the application is container deployment, where the first resource allocation request is used to request the deployment of a container capable of running an instance of the application. Or, if the deployment method of the application is VM deployment, a second resource allocation request is sent to VIM81, where the second resource allocation request is used to request the resources required to deploy a VM capable of running an instance of the application;
  • VIM81 used to receive a first resource allocation request, and deploy a container that can run an application instance according to the first resource allocation request; or, to receive a second resource allocation request, and deploy a container that can run an application according to the second resource allocation request Virtual machine VM.
  • MEPM or MEO After MEPM or MEO receives a request to deploy an application, it can analyze the received request to determine the deployment method (container deployment or VM deployment) of the application requested for deployment. If it is a container deployment, Then send a resource allocation request to VIM, request the use of container deployment to deploy the resources required by the application, and complete the container deployment of the application; if it is a VM deployment, send a resource allocation request to VIM to request the deployment of the application in the VM deployment method Required resources to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be implemented in the MEC system.
  • the deployment method container deployment or VM deployment
  • FIG. 10 is another MEC system architecture diagram provided by an embodiment of this application.
  • the system may include: a unified orchestration function entity 80, VIM81, and CIM82, where the unified orchestration function entity 80 is shown in FIG. 8
  • the functional entities include the same components and have the same functions.
  • the unified orchestration functional entity may be the MEPM or MEO shown in Figure 1 or Figure 2.
  • the unified orchestration function entity 80 is used to receive the deployment request and determine the deployment mode of the application according to the deployment request.
  • the deployment request is used to request to deploy an instance of the application.
  • the deployment request includes the identification ID of the application and the orchestration information.
  • the deployment method of the application includes container deployment or virtual machine VM deployment;
  • the unified orchestration function entity 80 is also used to send a first resource allocation request to VIM 81 if the deployment mode of the application is container deployment, where the first resource allocation request is used to request the deployment of 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, where the second resource allocation request is used to request the deployment of a VM that can run an instance of the application Required resources;
  • VIM81 configured to receive a first resource allocation request, and deploy a container capable of running an instance of the application according to the first resource allocation request;
  • the CIM 82 is configured 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.
  • MEPM or MEO After MEPM or MEO receives a request to deploy an application, it can analyze the received request to determine the deployment method (container deployment or VM deployment) of the application requested for deployment. If it is a container deployment, Then send a resource allocation request to CIM, request the use of container deployment to deploy the resources required by the application, and complete the container deployment of the application; if it is a VM deployment, send a resource allocation request to VIM to request the deployment of the application in the VM deployment method Required resources to complete the VM deployment of the application. In this way, both VM deployment and container deployment can be implemented in the MEC system.
  • the deployment method container deployment or VM deployment
  • the disclosed device and method may be implemented in other ways.
  • the device embodiments described above are merely illustrative.
  • the division of the modules or units is only a logical function division.
  • there may be other division methods for example, multiple units or components may be It can be combined or integrated into another device, or some features can be omitted or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate parts may or may not be physically separate.
  • the parts displayed as units may be one physical unit or multiple physical units, that is, they may be located in one place, or they may be distributed to multiple different places. . Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • each unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.
  • 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.
  • the technical solutions of the embodiments of the present application are essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of software products, which are stored in a storage medium It includes several instructions to make a device (may be a single-chip microcomputer, a chip, etc.) or a processor (processor) execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk and other media that can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例公开了一种部署虚拟机和容器的方法及装置，用于实现在MEC系统中既可以容器部署又可以VM部署。所述方法包括：统一编排功能实体接收部署请求，根据部署请求，确定应用程序的部署方式为容器部署或者VM部署；进一步的，若应用程序的部署方式为容器部署，则统一编排功能实体向架构管理器发送第一资源分配请求，请求架构管理器部署能够运行应用程序的实例的容器；若应用程序的部署方式为VM部署，则向VIM发送第二资源分配请求，请求VIM部署能够运行应用程序的实例的VM。

Description

一种部署虚拟机和容器的方法及装置
本申请要求于2019年03月22日提交国家知识产权局、申请号为201910224223.9、申请名称为“一种部署虚拟机和容器的方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及计算机技术领域，尤其涉及一种部署虚拟机和容器的方法及装置。
背景技术
随着计算机技术和通信技术的发展，多接入边缘计算(multi-access edge computing，MEC)成为第五代(5th generation，5G)移动网络的关键技术。MEC系统位于网络边缘，用户发出的大多数业务数据可以先通过MEC系统的过滤和处理后再上传到云，以提高数据的处理速度和传输可靠性。
目前，MEC系统中，仅可以通过虚拟机(virtual machine，VM)部署方式部署应用程序的实例。但是，随着通信技术的发展，VM和容器混合部署在MEC系统的需求出现，通过容器部署或者VM部署方式部署应用程序的实例。
现有技术中，kubernetes作为现在最热门的容器管理平台，适用于大多数的容器场景。但在MEC系统中，由于边缘节点的资源使用有限，kubernetes不能满足MEC系统中边缘节点的资源占用要求，不能采用kubernetes在MEC系统中进行容器部署。
发明内容
本申请实施例提供一种部署虚拟机和容器的方法及装置，以实现在MEC系统中部署VM和容器。
为达到上述目的，本申请实施例采用如下技术方案：
第一方面，本申请实施例提供一种部署虚拟机和容器的方法，该方法包括：统一编排功能实体接收用于请求部署应用程序的实例的部署请求，部署请求包括应用程序的标识ID和编排信息，编排信息用于指示运行应用程序的实例所需的资源，统一编排功能实体根据部署请求，确定应用程序的部署方式为容器部署或者虚拟机VM部署，以便统一编排功能实体根据确定出的部署方式请求VIM或者CIM部署能够运行应用程序的实例的VM或者容器。
基于第一方面所述的方法，统一编排功能实体接收到部署应用程序的请求后，可以对接收到的部署请求进行分析处理，根据部署请求包括的内容确定部署应用程序的实例的部署方式(容器部署或者VM部署)，以便统一编排功能实体根据确定出的部署方式向VIM或者CIM发送资源分配请求，请求采用容器部署方式部署应用程序所需的资源，或者，向VIM发送资源分配请求，请求采用VM部署方式部署应用程序所需的资源，完成应用程序的VM部署，实现在MEC系统中即可以实现VM部署，又可以实现容器部署。
第一种可能的设计中，结合第一方面，所述方法还包括：若应用程序的部署方式为容器部署，则统一编排功能实体向架构管理器发送用于请求部署能够运行应用程序的实例的容器所需的资源的第一资源分配请求，或者，若应用程序的部署方式为VM部署，则统一 编排功能实体向VIM发送用于请求部署能够运行应用程序的实例的VM所需的资源的第二资源分配请求。
基于该可能的设计，可以在容器部署时，向架构管理器发送第一资源分配请求，请求该架构管理器分配能够运行应用程序的实例的容器资源，或者，在VM部署时，向VIM发送第二资源分配请求，请求VIM分配能够运行该应用程序的实例的VM资源，如此，即可以实现容器部署又可以实现VM部署。
第二种可能的设计中，结合第一方面或者第一方面的第一种可能的设计，应用程序的ID与应用程序的部署方式间存在对应关系，统一编排功能实体根据部署请求，确定应用程序的部署方式包括：统一编排功能实体根据应用程序的ID以及对应关系，确定应用程序的部署方式。基于该可能的设计，可以将用于标识应用程序的ID与应用程序的部署方式对应起来，根据该对应关系可以确定应用程序的部署方式，简单易行。
第三种可能的设计中，结合第一方面或者第一方面的第一种可能的设计，部署请求中还包括部署类型标识，部署类型标识用于标识应用程序的部署方式，统一编排功能实体根据部署请求，确定应用程序的部署方式包括：统一编排功能实体根据部署类型标识，确定应用程序的部署方式。基于该可能的设计，可以在编排信息中增加用于标识应用程序的部署方式的部署类型标识，通过该部署类型标识显性指示应用程序的部署方式，简单易行。
需要说明的是，部署类型标识可以包括在部署请求中新增的信元中，也可以包括部署请求所包括的编排信息中，不予限制。
第四种可能的设计中，结合第一方面的第一种可能的设计至第一方面的第三种可能的设计中的任一可能的设计，所述方法还包括：统一编排功能实体接收来自架构管理器的第一资源分配响应。基于该可能的设计，可以在分配容器资源之后，向统一编排功能实体返回第一资源分配响应，以便统一编排功能实体获知已成功为应用程序的实例分配容器资源。
第五种可能的设计中，结合第一方面的第一种可能的设计至第一方面的第三种可能的设计中的任一可能的设计，所述方法还包括：统一编排功能实体接收来自VIM的第二资源分配响应。基于该可能的设计，可以在分配VM资源之后，向统一编排功能实体返回第一资源分配响应，以便统一编排功能实体获知已成功为应用程序的实例分配VM资源。
第六种可能的设计，结合第一方面或者第一方面的任一可能的设计，所述方法还包括：统一编排功能实体向MEP发送配置请求，其中，配置请求用于请求MEP配置运行应用程序的实例所遵循的流量规则、DNS规则。基于该可能的设计，可以向MEP请求运行该应用程序的实例所遵循的一些规则，以便按照MEP配置的规则运行应用程序的实例。
第七种可能的设计，结合第一方面或者第一方面的任一可能的设计，所述方法还包括：统一编排功能实体发送部署请求的响应，其中，部署请求的响应用于指示成功部署应用程序的实例，部署请求的响应包括应用程序的ID。基于该可能的设计，可以在成功部署应用程序的实例之后，向请求部署应用程序的实例的请求方发送部署请求的响应，以便请求方获知成功部署应用程序的实例。
第八种可能的设计，结合第一方面或者第一方面的任一可能的设计，所述方法还包括：统一编排功能实体接收终止请求；终止请求包括应用程序的ID，终止请求用于终止应用程序的实例；若应用程序的部署方式为容器部署，则统一编排功能实体向架构管理器发送第一资源删除请求，其中，第一资源删除请求可以用于请求架构管理器删除应用程序的实例 占用的资源；或者，若应用程序的部署方式为VM部署，则统一编排功能实体向VIM发送第二资源删除请求，其中，第一资源删除请求可以用于请求VIM删除应用程序的实例占用的资源。基于该可能的设计，统一编排功能实体接收到终止应用程序的实例的终止请求后，可以根据应用程序的部署方式进行相应的终止处理，如：若部署方式为容器部署，则向架构管理器发送第一资源删除请求，请求架构管理器删除应用程序的实例占用的资源；或者，若部署方式为VM部署，则向VIM发送第二资源删除请求，请求VIM删除应用程序的实例占用的资源。如此，可以在不需要该应用程序的实例的情况下，请求架构管理器或者VIM删除该应用程序的实例。
第九种可能的设计，结合第一方面或者第一方面的任一可能的设计，统一编排功能实体为MEPM或者MEO。基于该可能的设计，可以由MEPM或者MEO执行本申请实施例提供的部署VM和容器的方法，提高了执行灵活性。
第十种可能的设计，结合第一方面或者第一方面的任一可能的设计，架构管理器为VIM或者CIM。基于该可能的设计，可以由现有功能实体，如：VIM执行本申请实施例中部署容器的功能，或者，新增功能实体CIM执行本申请实施例提供的部署容器的过程。
第二方面，本申请提供一种通信装置，该通信装置可以为统一编排功能实体或者统一编排功能实体中的芯片或者片上系统，其中，统一编排功能实体为MEPM或者MEO，可以实现上述各方面或者各可能的设计中统一编排功能实体所执行的功能，所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。如：该通信装置可以包括：统一编排调度管理模块；
统一编排调度管理模块，用于接收部署请求，并根据部署请求，确定应用程序的部署方式，其中，部署请求用于请求部署应用程序的实例，部署请求包括应用程序的标识ID和编排信息，编排信息用于指示部署应用程序的实例所需的资源；应用程序的部署方式包括容器部署或者虚拟机VM部署。
进一步的，统一编排功能实体还包括：
容器编排管理模块，用于若统一编排调度管理模块确定应用程序的部署方式为容器部署，则向架构管理器发送第一资源分配请求，其中，第一资源分配请求用于请求部署能够运行应用程序的实例的容器所需的资源；
虚拟机VM调度管理模块，用于若统一编排调度管理模块确定应用程序的部署方式为VM部署，则向虚拟化基础架构管理器VIM发送第二资源分配请求，其中，第二资源分配请求用于请求部署能够运行应用程序的实例的VM所需的资源。
其中，该通信装置的具体实现方式可以参考第一方面或第一方面的任一种可能的设计提供的部署虚拟机和容器的方法中统一编排功能实体的行为功能，在此不再重复赘述。因此，该提供的通信装置可以达到与第一方面或者第一方面的任一种可能的设计相同的有益效果。
第三方面，提供了一种通信装置，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该通信装置运行时，该处理器执行该存储器存储的该计算机执行指令，以使该通信装置执行如上述第一方面或者第一方面的任一种可能的设计所述的部署虚拟机和容器的方法。
第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质为非易失性可读 存储介质。该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面或者上述方面的任一种可能的设计所述的部署虚拟机和容器的方法。
第五方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面或者上述方面的任一种可能的设计所述的部署虚拟机和容器的方法。
第六方面，提供了一种芯片系统，该芯片系统包括处理器、通信接口，用于支持该芯片系统实现上述方面中所涉及的功能，例如处理器通过通信接口接收部署请求，并根据部署请求，确定应用程序的部署方式，其中，部署请求用于请求部署应用程序的实例，部署请求包括应用程序的标识ID和编排信息，编排信息用于指示部署应用程序的实例所需的资源；应用程序的部署方式包括容器部署或者虚拟机VM部署。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存通信装置必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
其中，第三方面至第六方面中任一种设计方式所带来的技术效果可参见上述第一方面或者第一方面的任一种可能的设计所带来的技术效果，不再赘述。
第七方面，本申请实施例提供一种MEC系统，包括如第二方面至第六方面所述的统一编排功能实体、虚拟化基础架构管理器VIM；或者，包括如第二方面至第六方面所述的统一编排功能实体、VIM以及CIM。
附图说明
图1为本申请实施例提供的一种MEC系统的架构示意图；
图2为本申请实施例提供的又一种MEC系统的架构示意图；
图3为本申请实施例提供的一种部署虚拟机和容器的方法流程图；
图4为本申请实施例提供的一种终止应用程序的实例的方法流程图；
图5a为本申请实施例提供的又一种部署虚拟机和容器的方法流程图；
图5b为本申请实施例提供的再一种部署虚拟机和容器的方法流程图；
图6a为本申请实施例提供的一种终止应用程序的实例的方法流程图；
图6b为本申请实施例提供的又一种终止应用程序的实例的方法流程图；
图7a为本申请实施例提供的一种板载应用程序的方法流程图；
图7b为本申请实施例提供的一种查询应用程序的方法流程图；
图7c为本申请实施例提供的使能应用程序的方法流程图；
图7d为本申请实施例提供的去使能应用程序的方法流程图；
图7e为本申请实施例提供的一种删除应用程序的方法流程图；
图8为本申请实施例提供的一种统一编排功能实体的组成示意图；
图9为本申请实施例提供的一种MEC系统组成示意图；
图10为本申请实施例提供的又一种MEC系统组成示意图。
具体实施方式
下面结合说明书附图，对本申请实施例的实施方式进行详细描述。
在一种示例中，为了实现在MEC系统中即可以部署VM，又可以部署容器，可以增强MEC系统中已存在的网元的功能，使其该网元支持容器的管理(如：部署、删除等)，例如，可以增强MEC系统中的VIM，使VIM支持VM的虚拟化管理的同时还具备支持容 器的管理的功能，以实现在MEC系统中即可以部署VM，又可以部署容器。具体的，增强后的MEC系统可以参照图1所示。
图1为本申请实施例提供的一种MEC系统的架构示意图，如图1所示，该MEC系统可以包括两大级：移动边缘主机级(mobile edge host level)和移动边缘系统级(mobile edge system)。其中，移动边缘主机级可以包括：多个移动边缘主机(mobile edge host)、移动边缘平台管理器(mobile edge platform manager，MEPM)、虚拟化基础架构管理器(virtualised infrastructure manager，VIM)。移动边缘系统级可以包括：面向客户的服务门户(customer facing service portal，CFS portal)、终端、用户应用生命周期管理代理(user app LCM proxy)、运营支撑系统(operations support system)以及移动边缘协调器/编排器(mobile edge orchestrator，MEO)等。
移动边缘主机，可以是一台物理主机，主要用于为移动边缘应用提供计算、存储和网络资源。移动边缘主机可以包括移动边缘平台(mobile edge platform)、多个移动边缘应用(mobile edge application，ME APP)、虚拟化基础架构(virtualisation infrastructure，VI)。
移动边缘平台MEP，主要用于为移动边缘应用提供移动边缘服务(mobile edge service)以及为移动边缘应用提供居间服务，如：可以为移动边缘应用间的发现和使用提供服务等。
移动边缘应用，可以包括运行在虚拟化基础架构之上的虚拟机(virtual machine)的应用程序，也可以包括运行在容器的应用程序。移动边缘应用可以与移动边缘平台进行交互以提供移动边缘服务，还可以与移动边缘平台交互，以执行与移动边缘应用生命周期相关的过程，如：指示移动边缘应用的可用性，重新定位用户状态等。除此之外，移动边缘应用还具有与其相关联的一定数量的规则和要求，如：还具有移动边缘应用所需的资源、最大延迟、所需的服务或者有用的服务等。
移动边缘平台管理器MEPM，主要具有如下功能：管理移动边缘应用的生命周期，如：将移动边缘应用的相关事件通知给移动边缘协调器/编排器；为移动边缘平台提供元素管理功能；管理移动边缘应用的规则和要求，如：管理移动边缘应用的服务授权、流量规则、域名系统(domain name system，DNS)配置和解决冲突等。
虚拟化基础架构管理器(VIM)，可以支持VM的虚拟化管理和容器的管理，主要具有如下两大功能，第一：分配、管理和释放虚拟化基础设施上的虚拟化资源(如：计算、存储和网络资源)；为运行软件映像准备虚拟化基础架构，如：配置虚拟化基础设施、接收和存储软件映像等；快速配置移动边缘应用，如：收集和上报虚拟化资源的性能和故障信息；执行移动边缘程序重定位等。第二：分配、管理和释放容器相关的资源(如：计算、存储和网络资源)；接收和存储容器映像；支持快速配置移动边缘应用，并收集和上报容器相关的资源的性能和故障信息等。
移动边缘协调器/编排器MEO，是移动边缘系统级的核心功能部件，主要具有如下功能：根据移动边缘主机的部署维护移动边缘系统的整体视图资源、可用的移动边缘服务以及拓扑；根据约束条件(如：移动边缘应用的延迟等)选择适当的移动边缘主机为移动边缘应用实例化提供可用资源和可用服务；触发移动边缘应用实例化或者终止；触发移动边缘应用重定位；管理移动边缘主机的容器资源，如：跟踪容器可用资源容量，并管理容器镜像等。
运营支撑系统，可以是运营商的OSS。它可以接收来自CFS门户(或者终端应用)的 用于请求实例化应用或终止应用的请求，并将接收到请求转发给移动边缘协调器/编排器，由移动边缘协调器/编排器根据该请求执行后续过程。
终端，可以称为终端设备(terminal equipment)或者用户设备(user equipment，UE)或者移动台(mobile station，MS)或者移动终端设备(mobile terminal，MT)等，终端上可以设置有应用程序(application，APP)图标。具体的，终端可以为手机、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、个人计算机(Personal Computer，PC)、上网本、蜂窝电话、以及个人数字助理(Personal Digital Assistant，PDA)、可穿戴式设备(如智能手表)、智能家居设备、车载电脑等，本实施例对该设备的具体形式不做特殊限制。
在图1所示的MEC系统中，移动边缘主机之间以及移动边缘主机内各部件间可以通过移动边缘平台的接口(mobile edge point，Mp)相互通信，移动边缘主机与MEC系统中的其他设备可以通过移动边缘管理(mobile edge management，Mm)相互通信，MEC系统中除移动边缘主机外的其他设备间也可以通过Mm接口相互通信。MEC系统中的设备与终端或CFS门户可以通过与外部实体之间的接口(如：Mx接口)相互通信。
例如，如图1所示，移动边缘平台与移动边缘应用之间可以通过Mp1相互通信，移动边缘平台与虚拟化基础架构中的数据平面间可以通过Mp2相互通信，移动边缘主机间可以通过Mp3相互通信。
OSS与移动边缘协调器/编排器之间可以通过Mm1相互通信，OSS与移动边缘平台管理器间可以通过Mm2相互通信。移动边缘协调器/编排器与移动边缘平台管理器间可以通过Mm3相互通信，移动边缘协调器/编排器与虚拟化基础架构管理器间可以通过Mm4相互通信。移动边缘平台管理器与移动边缘平台间可以通过Mm5相互通信，移动边缘平台管理器与虚拟化基础架构管理器间可以通过Mm6相互通信。虚拟化基础架构管理器与虚拟化基础架构间可以通过Mm7相互通信。用户应用生命周期管理代理与OSS之间可以通过Mm8相互通信，用户应用生命周期管理代理与移动边缘协调器/编排器之间可以通过Mm9相互通信。CFS门户与OSS之间可以通过Mx1相互通信，CFS门口可以将第三方发出的请求通过Mx1发送给OSS。终端与用户应用生命周期管理代理之间可以通过Mx2相互通信，终端上的app可以通过Mx2向用户应用生命周期管理代理发送请求，请求运行移动边缘应用或者将移动边缘应用移入/移出移动边缘系统中。
需要指出的是，图1仅为示例性附图，图1所示MEC系统包括的网元的数量不受限制，除图1所示网元之外，该MEC系统还可以包括其他设备等。此外，图1中各个设备的名称、设备间接口的名称不受限制，除图1所示名称之外，各个设备、设备间的接口还可以命名为其他名称，不予限制。
在又一种示例中，为了实现在MEC系统中即可以部署VM，又可以部署容器，可以在MEC系统中新增部署容器的功能实体，使该新增的功能实体支持容器的管理(如：部署、删除等)，以实现在MEC系统中部署容器。具体的，增强后的MEC系统可以参照图2所示。
如图2所示，为本申请实施例提供的又一种MEC系统的架构示意图，如图2所示，该MEC系统可以包括：移动边缘主机级(mobile edge host level)和移动边缘系统级(mobile edge system)。其中，移动边缘主机级可以包括：多个移动边缘主机(mobile edge host)、移动边缘平台管理器(mobile edge platform manager，MEPM)、虚拟化基础架构管理器 (virtualisation infrastructure manager，VIM)以及容器基础架构管理器(container infrastructure manager，CIM)。移动边缘系统级可以包括：CFS门户(CFS portal)、终端、用户应用生命周期管理代理(user app LCM proxy)、运营支撑系统(operations support system)以及移动边缘协调器/编排器(mobile edge orchestrator，MEO)等。
其中，图2所示MEC系统中的MEO、MEPM、VIM等功能实体的相关功能可参照图1中所述，不再赘述。
其中，图2中的移动边缘主机，可以是一台物理主机，主要用于为移动边缘应用提供计算、存储和网络资源。移动边缘主机可以包括移动边缘平台(mobile edge platform)、多个移动边缘应用(mobile edge application，ME APP)、虚拟化基础架构(virtualisation infrastructure，VI)以及容器基础架构(container infrastructure，CI)。CI具有容器引擎的功能，如：具有docker engine的功能。
其中，图2所示CIM可以支持容器的管理。主要具有如下功能：分配、管理和释放容器相关的资源(如：计算、存储和网络资源)；接收和存储容器映像；支持快速配置移动边缘应用，并收集和上报容器相关的资源的性能和故障信息等。需要说明的是，CIM可以和VIM独立部署在图2所示MEC系统中，也可以集中部署在同一功能实体中，不予限制，本申请实例仅以CIM和VIM独立部署在图2所示MEC系统中为例进行描述。
与图1类似，在图2所示的MEC系统中，移动边缘主机之间以及移动边缘主机内各部件间可以通过移动边缘平台的接口(mobile edge point，Mp)相互通信，移动边缘主机与MEC系统中的其他设备可以通过移动边缘管理(mobile edge management，Mm)相互通信，MEC系统中除移动边缘主机外的其他设备间也可以通过Mm接口相互通信。MEC系统中的设备与终端或CFS门户可以通过与外部实体之间的接口(如：Mx接口)相互通信。具体接口可参照图2中所述。
需要指出的是，图2仅为示例性附图，图2所示MEC系统包括的网元的数量不受限制，除图2所示网元之外，该MEC系统还可以包括其他设备等。此外，图2中各个设备的名称、设备间接口的名称不受限制，除图2所示名称之外，各个设备、设备间的接口还可以命名为其他名称，不予限制。
下面基于图1或者图2所示的MEC系统，对本申请实施例提供的方法进行描述。
图3为本申请实施例提供的一种部署虚拟化和容器的方法，如图3所示，该方法可以包括步骤301～步骤308：
步骤301：统一编排功能实体接收部署请求。
其中，统一编排功能实体可以为MEO或者MEO中能够实现本申请实施例中统一编排功能实体所执行的功能的芯片或者片上系统，还可以为MEPM或者MEPM中能够实现本申请实施例中统一编排功能实体所执行的功能的芯片或者片上系统，又或者，统一编排功能实体可以包括用于执行实现本申请实施例所述方法的多个功能模块，这多个功能模块中的部分功能模块位于MEO中，剩余部分模块位于MEPM中，不予限制。本申请实施例仅以统一编排功能实体为MEO或者MEPM为例进行说明。
其中，部署请求可以用于请求实例化部署应用程序，该应用程序可以为第三方业务的应用程序(application，APP)，如：可以为QQ游戏、大型手机游戏、MEC系统中的视频监控程序(人脸识别、数据分析等)，该应用程序的部署方式可以包括但不限于VM部 署或者容器部署等。应用程序可以由应用程序的(indentity，ID)唯一标识，不同应用程序的ID以是不同的。示例性的，应用程序的ID可以是在应用程序成功板载(on-boarding)到MEC系统后，由MEO分配的唯一标识。
具体的，该部署请求可以包括但不限于应用程序的标识(indentity，ID)和编排信息，还可以包括其他信息，不予限制。编排信息可以包括应用程序的实例化部署所需的资源信息，如：应用程序的镜像地址、磁盘类型、存储的卷名、磁盘大小等等，还可以包括编排类型(VM或者容器)等等。该编排信息可以为tosca类型，也可以为基于kubernetes的yaml类型。示例性的，该编排信息中可以包括关键字或者一些特殊的参数，可以通过该关键字或者这些特殊的参数识别出该编排信息的。
例如，以应用程序的部署方式为VM部署为例，编排信息可以如下所示，可以包括应用程序的基本信息以及应用程序的存储资源等，其中，应用程序的基本信息可以包括节点基本信息、应用程序的部署方式、存储信息等。节点基本信息可以包括“节点模板(node_templates)、软件开发工具(sdk-appgroud)、节点类型(type:hwpaas.node.Appgroup)、需求(requirements)、成员(member)、节点名称(node:sdk-app)、节点关系(relationship:hwpass.relationships.Consistsof)等。应用程序的部署方式可以包括：应用程序包(package)、节点部署方式(node:sdk-VM)、节点关系(relationship:hwpass.relationship.PackageConsistsor)。存储信息可以包括“卷(volume)、节点系统盘(node:system_disk)、节点关系(relationship:hwpass.relationship.Attachesto)、卷(volume)、节点(node:data_disk)、节点关系(relationship:hwpass.relationship.AttachesTo)等。应用程序的存储资源可以包括：系统盘(system_disk)、类型(type:hwpaas.nodes.LocalVolume)、属性(properties)、类型(type:local_storage)、名称(name:test)、lvmType：system、卷类型(volumeType:high IO)、设备(devices:/dev/sdc)、卷类型(volumeType：“high IO”)、大小(size:20G)、模式(mode:private)、条纹(stripe:true)、删除策略(deletePolicy：reserved)等。
node_templates:
sdk-appgroud：
type:hwpaas.node.Appgroup
requirements:
—member:
node:sdk-app
relationship:hwpass.relationships.Consistsof
sdk-app:
type:hwpaas.nodes.Application
properties
type:VM
requirements:
—package:
node:sdk-VM
relationship:hwpass.relationship.PackageConsistsor
—volume:
node:system_disk
relationship:hwpass.relationship.Attachesto
—volume:
node:data_disk
relationship:hwpass.relationship.AttachesTo
sdk_VM:
type:hwpaas.node.SoftwareComponent
properties:
package_type:VM
image:{get_input:VM_image_url}
cpu：
mem：
system_disk
type:hwpaas.nodes.LocalVolume
properties:
type:local_storage
name:test
lvmType：system
volumeType:high IO
devices:/dev/sdc
volumeType：“high IO”
size:20G
mode:private
stripe:true
deletePolicy：reserved
在一种示例中，以统一编排功能实体为图1或者图2中的MEO为例，统一编排功能实体接收部署请求可以包括：统一编排功能实体通过Mm1接收OSS发送的部署请求，其中，该部署请求可以由CFS门户或者user app LCM proxy发送给OSS；或者，统一编排功能实体通过Mm9接收user app LCM proxy发送的部署请求，其中，该部署请求可以由终端上的APP发送给user app LCM proxy。
在另一种示例中，以统一编排功能实体为图1或者图2中的MEPM为例，统一编排功能实体接收部署请求可以包括：统一编排功能实体通过Mm2接收OSS发送的部署请求，其中，该部署请求可以由CFS门户或者user app LCM proxy发送给OSS；或者，统一编排功能实体通过Mm3接收MEO发送的部署请求，其中，MEO可以通过上述方式获取部署请求并发送给MEPM，不再赘述。
其中，另一种示例中，在MEO接收到部署请求并转发给MEPM的情况下，所述方法还可以包括：MEO获取应用程序的实例配置数据，根据应用程序的实例配置数据向MEPM转发该部署请求。应用程序的实例配置数据可以包括应用程序的实例部署在哪个节点、部 署的方式、采用这样的部署方式部署应用程序的实例所需要的资源(如：计算资源、网络资源以及存储资源等)等信息。MEO根据应用程序的实例配置数据向MEPM转发该部署请求可以包括：在采用应用程序的实例配置数据所规定的部署方式部署应用程序的实例的情况下，若MEC系统中存在可部署该应用程序的实例的节点以及部署该应用程序的实例所需要的资源，则向MEPM转发该部署请求，反之，则拒绝向MEPM转发该部署请求。
步骤302：统一编排功能实体根据部署请求，确定应用程序的部署方式。
一种示例中，部署请求中包括编排信息，针对不同的部署方式，编排信息的类型是不同的，如：当应用程序的部署方式为VM部署时，编排信息可以为tosca类型，当应用程序的部署方式为容器部署时，编排信息可以为yaml类型。
统一编排功能实体接收到部署请求后，解析部署请求，获取部署请求包括的编排信息，根据编排信息的类型确定应用程序的部署方式。如：若编排信息为tosca类型，则确定应用程序为VM部署；若编排信息为yaml类型，则确定应用程序的部署方式为容器部署。
其中，统一编排功能实体可以包括编排信息中包括的关键字确定编排信息的类型。例如，编排信息中包括编排类型(VM或者容器)，若编排类型为VM，则确定编排信息为tosca类型，应用程序的部署方式为VM部署，反之，若编排类型为容器，则确定编排信息为yaml类型，应用程序的部署方式为容器部署。
又一种示例中，部署请求中可以包括部署类型标识，该部署类型标识可以用于指示应用程序的部署方式，统一编排功能实体接收到部署请求后，可以解析部署请求，根据部署请求包括的部署类型标识，确定应用程序的部署方式。
其中，部署类型标识可以为二进制比特数，如：0或1，“0”表示VM部署，“1”表示容器部署，还可以为其他用于指示应用程序的部署方式的标识符(indentity)，如：可以为由数字、字母、符号等任意形式的信息组合而成、易于用户理解的标识符等，不予限制。
需要说明的是，部署类型标识可以包括在部署请求中新增的信元中，也可以包括在部署请求所包括的编排信息中，不予限制。除包括编排信息、部署类型标识之外，部署请求还可以包括其他信息。
例如，下表一示出了部署请求所包括的内容，如表一所示，该部署请求可以强制性包括部署类型标识(或者称为部署方式(deploy method))、应用程序的实例的ID(或者应用程序的ID)、虚拟存储信息(virtual storage desciptor)以及移动边缘主机信息(selected ME HostInfo)，可选的，还包括虚拟机描述(virtual compute descripto)、容器描述(container descripto)等。其中，在表一中，N为大于1的整数。
表一
Figure PCTCN2020080505-appb-000001
Figure PCTCN2020080505-appb-000002
再一种示例中，部署请求中可以包括应用程序的ID，应用程序的ID与应用程序的部署方式间存在对应关系。统一编排功能实体接收到部署请求后，可以解析部署请求，根据部署请求包括的应用程序的ID以及预先存储的应用程序的ID与应用程序的部署方式间的对应关系，确定部署请求所请求的应用程序的部署方式。
其中，应用程序的ID可以包括在部署请求的编排信息中，也可以独立于编排信息包括在部署请求中，不予限制。
其中，应用程序的ID与应用程序的部署方式可以预先存储在MEO或者MEPM中，如：MEO可以接收OSS发送的包括应用程序和应用程序的部署方式的板载(on-board)应用程序的请求，根据板载应用程序的请求对应用程序进行板载，当应用程序的成功板载到MEC系统后，MEO可以为应用程序分配唯一的ID，并将应用程序的ID与应用程序的部署方式对应存储在MEO上或者MEPM上。
例如，下表二示出了应用程序的ID与应用程序的部署方式间的对应关系，如表二所示，APP 1对应的部署方式为容器部署，APP 2的部署方式为容器部署，APP 3的部署方式为容器部署。当部署请求包括的应用程序的ID为APP 1时，统一编排功能实体可以以APP 1为索引查询表二，确定APP 1对应的部署方式为VM部署。当部署请求包括的应用程序的ID为APP 2时，统一编排功能实体可以以APP 2为索引查询表二，确定APP 2对应的部署方式为容器部署。当部署请求包括的应用程序的ID为APP 3时，统一编排功能实体可以以APP 3为索引查询表二，确定APP 3对应的部署方式为容器部署。
表二
应用程序的ID 应用程序的部署方式
APP 1 VM部署
APP 2 容器部署
APP 3 容器部署
进一步的，在步骤302之后，若步骤302中确定出应用程序的部署方式为容器部署，则执行步骤303～步骤305；若应用程序的部署方式为VM部署，则执行步骤306～步骤308：
步骤303：统一编排功能实体向架构管理器发送第一资源分配请求。
其中，当图3所示方法基于图1执行时，架构管理器可以为图1中的VIM或者VIM 中的功能模块，如：可以为VIM中能够执行本申请实施例中架构管理器所执行的功能的芯片或者片上系统等；当图3所示方法基于图2执行时，架构管理器可以为图2中的CIM或者CIM中的功能模块，如：可以为CIM中能够执行本申请实施例中架构管理器所执行的功能的芯片或者片上系统等，不予限制。本申请实施例仅以架构管理器为图1中的VIM或者图2中的CIM为例进行描述。
其中，第一资源分配请求可以用于请求部署能够运行所述应用程序的实例的容器所需的资源；如：计算资源、网络资源、存储资源等。第一资源分配请求可以包括应用程序的ID、容器部署的标识和采用容器部署方式部署应用程序所需的资源信息。容器部署的标识可以用于标识该应用程序的部署方式为容器部署。容器部署所需的资源信息可以包括采用容器部署方式部署该应用程序所需的计算资源、存储资源以及网络资源。示例性的，容器部署所需的资源信息具体可以包括：容器镜像地址、磁盘类型、卷名、磁盘大小等等。
示例性的，当统一编排功能实体为MEO，架构管理器为图1中的VIM时，如图1所示，统一编排功能实体可以通过Mm4向架构管理器发送第一资源分配请求。
当统一编排功能实体为MEPM，架构管理器为图1中的VIM时，如图1所示，统一编排功能实体可以通过Mm6向架构管理器发送第一资源分配请求。
当统一编排功能实体为MEO，架构管理器为图2中的CIM时，如图2所示，统一编排功能实体可以通过Mm10向架构管理器发送第一资源分配请求。
当统一编排功能实体为MEPM，架构管理器为图2中的CIM时，如图2所示，统一编排功能实体可以通过Mm11向架构管理器发送第一资源分配请求。
步骤304：架构管理器接收第一资源分配请求，根据第一资源分配请求部署能够运行应用程序的实例的容器。
示例性的，架构管理器根据第一资源分配请求部署能够运行应用程序的实例的容器的方式可参照现有技术，如：架构管理器根据容器镜像地址找到容器镜像仓库、从容器镜像仓库中下载该应用程序的容器镜像；调用存储插件请求创建存储的卷；请求容器引擎创建pause容器；请求网络插件创建CNI Add()以及请求容器引擎创建和运行容器。
需要说明的是，在架构管理器从容器镜像仓库中下载该应用程序的容器镜像之前，架构管理器需要检查容器镜像仓库中是否存在该应用程序的容器镜像，若不存在，则应用程序的容器部署失败；若存在，则查看该应用程序的容器镜像是否可用，若可用，则从容器镜像仓库中下载容器镜像，执行容器部署流程，若不可用，则该应用程序的容器部署失败。
其中，容器镜像仓库中存储有应用程序的ID以及应用程序的状态信息(可用或者不可用等)，若容器镜像中存在与第一资源分配请求包括的应用程序的ID相同的ID，则确定容器镜像仓库中存在该应用程序的容器镜像，反之，则不存在；若第一资源分配请求包括的应用程序的ID所标识的应用程序的状态信息为可用，则确定容器仓库中存在的应用程序的容器镜像是可用的，反之，则不可用。
步骤305：架构管理器向统一编排功能实体发送第一资源分配响应。
其中，第一资源分配响应可以用于指示架构管理器成功部署容器。第一资源分配响应可以包括应用程序的ID。
示例性的，当架构管理器为MEO，架构管理器为图1中的VIM时，如图1所示，架构管理器可以通过Mm4向统一编排功能实体发送第一资源分配响应。
当架构管理器为MEPM，架构管理器为图1中的VIM时，如图1所示，架构管理器可以通过Mm6向统一编排功能实体发送第一资源分配响应。
当架构管理器为MEO，架构管理器为图2中的CIM时，如图2所示，架构管理器可以通过Mm10向统一编排功能实体发送第一资源分配响应。
当架构管理器为MEPM，架构管理器为图2中的CIM时，如图2所示，架构管理器可以通过Mm11向统一编排功能实体发送第一资源分配响应。
步骤306：统一编排功能实体向VIM发送第二资源分配请求。
其中，第二资源分配请求可以用于请求部署能够运行所述应用程序的实例的VM所需的资源；如：计算资源、网络资源、存储资源等。第二资源分配请求可以包括应用程序的ID、VM部署的标识和采用VM部署方式部署应用程序所需的资源信息。VM部署的标识可以用于标识该应用程序的部署方式为VM部署。VM部署所需的资源信息可以包括采用VM部署方式部署该应用程序所需的计算资源、存储资源以及网络资源。示例性的，VM部署所需的资源信息具体可以包括：VM镜像地址、磁盘类型、卷名、磁盘大小等等。
示例性的，如图1或图2所示，统一编排功能实体可以通过Mm6向VIM发送第二资源分配请求。
步骤307：VIM接收第二资源分配请求，根据第二资源分配请求部署能够运行应用程序的实例的VM。
示例性的，VIM根据第二资源分配请求部署能够运行应用程序的实例的VM的方式可参照现有技术，如：VIM可以根据VM镜像地址，VM镜像仓库中下载该应用程序的VM镜像；调用存储插件请求创建存储的卷；请求VM引擎创建psuseVM；请求网络插件创建网络平面以及调用libvirt创建和运行VM。
需要说明的是，在VIM从VM镜像仓库中下载该应用程序的VM镜像之前，VIM需要检查VM镜像仓库中是否存在该应用程序的VM镜像，若不存在，则该应用程序的VM部署失败；若存在，则查看该应用程序的VM镜像是否可用，若可用，则从VM镜像仓库中下载VM镜像，执行VM部署流程，若不可用，则该应用程序的VM部署失败。
其中，VM镜像仓库中存储有应用程序的ID以及应用程序的状态信息(可用或者不可用等)，若VM镜像中存在与第二资源分配请求包括的应用程序的ID相同的ID，则确定VM镜像仓库中存在该应用程序的VM镜像，反之，则不存在；若第二资源分配请求包括的应用程序的ID所标识的应用程序的状态信息为可用，则确定VM仓库中存在的应用程序的VM镜像是可用的，反之，则不可用。
步骤308：VIM向统一编排功能实体发送第二资源分配响应。
其中，第二资源分配响应可以用于指示VIM成功部署VM。第二资源分配响应可以包括该应用程序的ID。示例性的，如图1或图2所示，VIM可以通过Mm6向统一编排功能实体发送第二资源分配响应。
基于图3所示方法，在接收到部署应用程序的请求后，可以对接收到的请求进行分析，确定请求部署的应用程序的部署方式(容器部署或者VM部署)，若为容器部署，则向VIM或者CIM发送资源分配请求，请求采用容器部署方式部署应用程序所需的资源，完成应用程序的容器部署；若为VM部署，则向VIM发送资源分配请求，请求采用VM部署方式部署应用程序所需的资源，完成应用程序的VM部署，如此，可以在MEC系统中 即可以实现VM部署，又可以实现容器部署。
进一步的，在图3所示方法中，以统一编排功能实体为MEPM为例，当统一编排功能实体接收到第一资源分配响应之后，统一编排功能实体可以向MEP发送第一配置请求，所述第一配置请求可以用于请求MEP配置在容器上运行应用程序的实例所遵循的流量规则、域名系统(domain name system，DNS)规则、服务、以及应用程序的实例生成的服务等，所述第一配置请求可以包括在容器上运行应用程序的实例所遵循的流量规则、DNS规则、必需和可选服务、以及应用程序的实例生成的服务等。MEP接收到第一配置请求后，可以根据第一配置请求为该应用程序的实例配置流量规则、DNS规则等，并在配置成功后，向统一编排功能实体发送第一配置请求的响应，第一配置请求的响应可以用于指示应用程序的实例所遵循的流量规则、DNS规则等配置成功。
类似的，当统一编排功能实体接收到第二资源分配响应之后，统一编排功能实体可以向MEP发送第二配置请求，所述第二配置请求可以用于请求MEP配置在VM上运行应用程序的实例所遵循的流量规则、DNS规则、必需和可选服务、以及应用程序的实例生成的服务等。所述第二配置请求可以包括在容器上运行应用程序的实例所遵循的流量规则、DNS规则、必需和可选服务、以及应用程序的实例生成的服务等。MEP接收到第二配置请求后，可以根据第二配置请求为该应用程序的实例配置流量规则、DNS规则等，并在配置成功后，向统一编排功能实体发送第二配置请求的响应，第二配置请求的响应可以用于指示应用程序的实例所遵循的流量规则、DNS规则等配置成功。
需要说明的是，当统一编排功能实体为MEO，MEO可以将其接收到的第一资源分配响应或者第二资源分配响应转发该MEPM，以便MEPM接收到第一资源分配响应或者第二资源分配响应后执行上述过程，不再赘述。
进一步的，在图3所示方法中，以统一编排功能实体为MEPM为例，当统一编排功能实体接收到第一配置请求的响应或第二配置请求的响应后，MEPM可以认为该应用程序的实例化部署完成，可以向OSS或者通过MEO向OSS发送部署请求的响应。
其中，部署请求的响应与步骤301中所述的部署请求相对应，可以用于指示成功完成该应用程序的实例化部署，该部署请求的响应可以包括分配给该应用程序的实例的资源信息，如：可以包括最终分配给该应用程序的实例的计算资源、网络资源以及存储资源等等。
进一步的，当已部署的应用程序的实例不被需要时，为了节约资源，还可以终止应用程序的实例，释放应用程序的实例所占用的资源。具体的，终止应用程序的实例的过程可参照图4所示，可以包括：
步骤401：统一编排功能实体接收终止请求。
其中，统一编排功能实体可以步骤301中所述，不再赘述。
其中，终止请求可以用于请求终止应用程序的实例，该终止请求可以包括应用程序的ID。应用程序的实例可以为通过容器部署方式或者VM部署方式部署的实例。
例如，下表三示出了终止请求所包括的内容，如表一所示，该终止请求可以强制性包括终止类型(termination type)、应用程序的实例的ID(或者应用程序的ID)，可选的，还包括优雅终止时间(graceful termination timeout)等。其中，在表三中，N为大于1的整数。
表三
Figure PCTCN2020080505-appb-000003
示例性的，以统一编排功能实体为图1或者图2中的MEO为例，统一编排功能实体接收终止请求可以包括：统一编排功能实体通过Mm1接收OSS发送的终止请求，其中，该终止请求可以由CFS门户或者user app LCM proxy发送给OSS；或者，统一编排功能实体通过Mm9接收user app LCM proxy发送的终止请求，其中，该终止请求可以由终端上的APP发送给user app LCM proxy。
在另一种示例中，以统一编排功能实体为图1或者图2中的MEPM为例，统一编排功能实体接收终止请求可以包括：统一编排功能实体通过Mm2接收OSS发送的终止请求，其中，该终止请求可以由CFS门户或者user app LCM proxy发送给OSS；或者，统一编排功能实体通过Mm3接收MEO发送的终止请求，其中，MEO可以通过上述方式获取终止请求并发送给MEPM，不再赘述。
步骤402：统一编排功能实体向MEP发送终止请求。
步骤403：MEP接收终止请求，根据终止请求终止应用程序的实例。
其中，步骤403中MEP根据终止请求终止应用程序的实例还可以描述为MEP根据终 止请求销毁应用程序的实例，不予限制。
在一种示例中，MEP根据终止请求终止应用程序的实例可以包括：MEP通过Mp1向应用程序的实例发送终止通知，应用程序的实例接收到该终止通知后，根据该终止通知终止应用程序的实例，并向MEP发送终止响应，MEP接收到终止响应后，认为应用程序的实例已终止。
在另一种示例中，MEP中可以设置一定时器，在MEP通过Mp1向应用程序的实例发送终止通知后，开启开定时器，当该定时器超时时，终止应用程序的实例，无需在接收到应用程序的实例发送的终止响应后，再终止应用程序的实例。
步骤404：MEP向统一编排功能实体发送终止响应。
其中，终止响应可以用于指示成功终止该应用程序的实例。
步骤405：统一编排功能实体根据终止请求，确定应用程序的部署方式；若应用程序的部署方式为容器部署，则执行步骤406～步骤408；若应用程序的部署方式为VM部署，则执行步骤409～步骤411。
其中，步骤405中，统一编排功能实体确定应用程序的部署方式的过程可参照步骤302所述，不再赘述。
步骤406：统一编排功能实体向架构管理器发送第一资源删除请求。
其中，架构管理器如步骤303中所述，可以为VIM或者CIM。
其中，第一资源删除请求可以用于请求架构管理器删除用于运行应用程序的实例的容器。
步骤407：架构管理器接收第一资源删除请求，根据第一资源删除请求删除容器。
其中，架构管理器根据第一资源删除请求删除容器的方式可参照现有技术，如：架构管理器可以删除(或者释放)该容器占用的全部资源，如：计算资源、存储资源、网络资源等等。
步骤408：架构管理器向统一编排功能实体发送第一资源删除响应，统一编排功能实体接收第一资源删除请求。
其中，第一资源删除响应可以用于指示成功删除该应用程序的实例对应的容器。
步骤409：统一编排功能实体向VIM发送第二资源删除请求。
其中，第二资源删除请求可以用于请求VIM删除用于运行应用程序的实例的VM。
步骤410：VIM接收第二资源删除请求，根据第二资源删除请求删除VM。
步骤411：VIM向统一编排功能实体发送第二资源删除响应，统一编排功能实体接收第二资源删除请求。
其中，第二资源删除响应可以用于指示成功删除该应用程序的实例对应的VM。
步骤412：统一编排功能实体发送终止请求的响应。
其中，该终止请求的响应为与步骤401中的终止请求对应的响应，可以包括应用程序的ID，该终止请求的响应可以用于指示成功终止该应用程序的实例以及删除该应用程序的实例所占用的资源。
示例性的，统一编排功能实体可以向OSS发送终止请求的响应。
基于图4所示方法，可以在不需要应用程序的实例的情况下，终止应用程序的实例以及删除应用程序的实例所占用的资源，提高了资源利用率。
下面结合图1所示的MEC系统，以统一编排功能实体为MEPM，架构管理器为VIM为例，对图3所示方法进行描述。
图5a为本申请实施例提供又一种部署虚拟机和容器的方法流程图，如图5a所示，所述方法可以包括：
步骤501a：OSS向MEO发送部署请求。
其中，部署请求的相关描述可以参照步骤301中所述，不再赘述。
步骤502a：MEO接收部署请求，向MEPM发送部署请求。
步骤503a：MEPM接收部署请求，根据部署请求确定应用程序的部署方式，若应用程序的部署方式为容器部署，则执行步骤504a～步骤506a；若应用程序的部署方式为VM部署，则执行步骤507a～步骤509a。
其中，步骤503a可参照步骤302所述，不再赘述。
步骤504a：MEPM向VIM发送第一资源分配请求。
其中，第一资源分配请求的相关描述以及步骤504a的执行过程可参照步骤303所述，不再赘述。
步骤505a：VIM接收第一资源分配请求，根据第一资源分配请求部署能够运行应用程序的实例的容器。
其中，步骤505a可参照步骤304所述，不再赘述。
步骤506a：VIM向MEPM发送第一资源分配响应，MEPM接收第一资源分配响应。
其中，步骤506a可参照步骤305所述，不再赘述。
步骤507a：MEPM向VIM发送第二资源分配请求。
其中，第二资源分配请求的相关描述以及步骤507a的执行过程可参照步骤306所述，不再赘述。
步骤508a：VIM接收第二资源分配请求，根据第二资源分配请求部署能够运行应用程序的实例的VM。
其中，步骤508a可参照步骤307所述，不再赘述。
步骤509a：VIM向MEPM发送第二资源分配响应，MEPM接收第二资源分配响应。
其中，步骤510a可参照步骤308所述，不再赘述。
步骤510a：MEPM向MEO发送部署请求的响应。
步骤511a：MEO接收部署请求的响应，向OSS发送部署请求的响应。
基于图5a所示方法，在接收到部署应用程序的请求后，可以对接收到的请求进行分析，确定请求部署的应用程序的部署方式(容器部署或者VM部署)，若为容器部署，则向VIM发送资源分配请求，请求采用容器部署方式部署应用程序所需的资源，完成应用程序的容器部署；若为VM部署，则向VIM发送资源分配请求，请求采用VM部署方式部署应用程序所需的资源，完成应用程序的VM部署，如此，可以在MEC系统中即可以实现VM部署，又可以实现容器部署。
下面结合图2所示的MEC系统，以统一编排功能实体为MEPM，架构管理器为CIM为例，对图3所示方法进行描述。
图5b为本申请实施例提供再一种部署虚拟机和容器的方法流程图，如图5b所示，所述方法可以包括：
步骤501b：OSS向MEO发送部署请求。
其中，部署请求的相关描述可以参照步骤301中所述，不再赘述。
步骤502b：MEO接收部署请求，向MEPM发送部署请求。
步骤503b：MEPM接收部署请求，根据部署请求确定应用程序的部署方式，若应用程序的部署方式为容器部署，则执行步骤504b～步骤506b；若应用程序的部署方式为VM部署，则执行步骤507b～步骤509b。
其中，步骤503b可参照步骤302所述，不再赘述。
步骤504b：MEPM向CIM发送第一资源分配请求。
其中，第一资源分配请求的相关描述以及步骤504b的执行过程可参照步骤303所述，不再赘述。
步骤505b：CIM接收第一资源分配请求，根据第一资源分配请求部署能够运行应用程序的实例的容器。
其中，步骤505b可参照步骤304所述，不再赘述。
步骤506b：CIM向MEPM发送第一资源分配响应，MEPM接收第一资源分配响应。
其中，步骤506b可参照步骤305所述，不再赘述。
步骤507b：MEPM向VIM发送第二资源分配请求。
其中，第二资源分配请求的相关描述以及步骤507b的执行过程可参照步骤306所述，不再赘述。
步骤508b：VIM接收第二资源分配请求，根据第二资源分配请求部署能够运行应用程序的实例的VM。
其中，步骤508b可参照步骤307所述，不再赘述。
步骤509b：VIM向MEPM发送第二资源分配响应，MEPM接收第二资源分配响应。
其中，步骤509b可参照步骤308所述，不再赘述。
步骤510b：MEPM向MEO发送部署请求的响应。
步骤511b：MEO接收部署请求的响应，向OSS发送部署请求的响应。
基于图5b所示方法，在接收到部署应用程序的请求后，可以对接收到的请求进行分析，确定请求部署的应用程序的部署方式(容器部署或者VM部署)，若为容器部署，则向CIM发送资源分配请求，请求采用容器部署方式部署应用程序所需的资源，完成应用程序的容器部署；若为VM部署，则向VIM发送资源分配请求，请求采用VM部署方式部署应用程序所需的资源，完成应用程序的VM部署，如此，可以在MEC系统中即可以实现VM部署，又可以实现容器部署。
作为部署应用程序的实例的逆过程，当不再需要已部署的应用程序的实例时，为了节约资源，还可以终止应用程序的实例，释放应用程序的实例所占用的资源。下面结合图1所示的MEC系统，以统一编排功能实体为MEPM，架构管理器为VIM为例，通过图6a或者图6b所示方法对终止应用程序的实例的过程进行描述。
图6a为本申请实施例提供一种终止应用程序的实例的方法流程图，如图6a所示，所述方法可以包括：
步骤601a：OSS向MEO发送终止请求。
其中，终止请求的相关描述可以参照步骤401中所述，不再赘述。
步骤602a：MEO接收终止请求，向MEPM发送终止请求。
步骤603a：MEPM接收终止请求，向MEP发送终止请求。
步骤604a：MEP接收终止请求，根据终止请求终止应用程序的实例。
其中，步骤604a可参照步骤403所述，不再赘述。
步骤605a：MEP向MEPM发送终止响应。
其中，终止响应的相关描述以及步骤605a的执行过程可参照步骤404所述，不再赘述。
步骤606a：MEPM确定应用程序的部署方式，若应用程序的部署方式为容器部署，则执行步骤607a～步骤609a；若应用程序的部署方式为VM部署，则执行步骤610a～步骤612a。
其中，步骤606a可参照步骤405所述，不再赘述。
步骤607a：MEPM向VIM发送第一资源删除请求。
其中，第一资源删除请求的相关描述以及步骤607a的执行过程可参照步骤406所述，不再赘述。
步骤608a：VIM接收第一资源删除请求，根据第一资源删除请求删除容器。
其中，步骤608a可参照步骤407所述，不再赘述。
步骤609a：VIM向MEPM发送第一资源删除响应，MEPM接收第一资源删除响应。
其中，步骤609a可参照步骤408所述，不再赘述。
步骤610a：MEPM向VIM发送第二资源删除请求。
其中，第二资源删除请求的相关描述以及步骤610a的执行过程可参照步骤409所述，不再赘述。
步骤611a：VIM接收第二资源删除请求，根据第二资源删除请求删除VM。
其中，步骤611a可参照步骤410所述，不再赘述。
步骤612a：VIM向MEPM发送第二资源删除响应，MEPM接收第二资源删除响应。
其中，步骤612a可参照步骤411所述，不再赘述。
步骤613a：MEPM向MEO发送终止请求的响应。
步骤614a：MEO接收终止请求的响应，向OSS发送终止请求的响应。
基于图6a所示方法，可以在接收到终止应用程序的实例的终止请求后，根据应用程序的部署方式进行相应的终止处理，如：若部署方式为容器部署，则向VIM发送第一资源删除请求，请求VIM删除应用程序的实例占用的容器资源；或者，若部署方式为VM部署，则向VIM发送第二资源删除请求，请求VIM删除应用程序的实例占用的VM资源。如此，可以在不需要应用程序的实例的情况下，请求架构管理器或者VIM删除该应用程序的实例。
下面结合图2所示的MEC系统，以统一编排功能实体为MEPM，架构管理器为CIM为例，对终止应用程序的实例的过程进行描述。
图6b为本申请实施例提供再一种终止应用程序的实例的方法流程图，如图6b所示，所述方法可以包括：
步骤601b：OSS向MEO发送终止请求。
其中，终止请求的相关描述可以参照步骤401中所述，不再赘述。
步骤602b：MEO接收终止请求，向MEPM发送终止请求。
步骤603b：MEPM接收终止请求，向MEP发送终止请求。
步骤604b：MEP接收终止请求，根据终止请求终止应用程序的实例。
其中，步骤604b可参照步骤403所述，不再赘述。
步骤605b：MEP向MEPM发送终止响应。
其中，终止响应的相关描述以及步骤605b的执行过程可参照步骤404所述，不再赘述。
步骤606b：MEPM接收终止请求，确定应用程序的部署方式，若应用程序的部署方式为容器部署，则执行步骤607b～步骤609b；若应用程序的部署方式为VM部署，则执行步骤610b～步骤612b。
其中，步骤606b可参照步骤405所述，不再赘述。
步骤607b：MEPM向CIM发送第一资源删除请求。
其中，第一资源删除请求的相关描述以及步骤607b的执行过程可参照步骤406所述，不再赘述。
步骤608b：CIM接收第一资源删除请求，根据第一资源删除请求删除容器。
其中，步骤608b可参照步骤407所述，不再赘述。
步骤609b：CIM向MEPM发送第一资源删除响应，MEPM接收第一资源删除响应。
其中，步骤609b可参照步骤408所述，不再赘述。
步骤610b：MEPM向VIM发送第二资源删除请求。
其中，第二资源删除请求的相关描述以及步骤610b的执行过程可参照步骤409所述，不再赘述。
步骤611b：VIM接收第二资源删除请求，根据第二资源删除请求删除VM。
其中，步骤611b可参照步骤410所述，不再赘述。
步骤612b：VIM向MEPM发送第二资源删除响应，MEPM接收第二资源删除响应。
其中，步骤612b可参照步骤411所述，不再赘述。
步骤613b：MEPM向MEO发送终止请求的响应。
步骤614b：MEO接收终止请求的响应，向OSS发送终止请求的响应。
基于图6b所示方法，可以在接收到终止应用程序的实例的终止请求后，根据应用程序的部署方式进行相应的终止处理，如：若部署方式为容器部署，则向CIM发送第一资源删除请求，请求CIM删除应用程序的实例占用的容器资源；或者，若部署方式为VM部署，则向VIM发送第二资源删除请求，请求VIM删除应用程序的实例占用的VM资源。如此，可以在不需要应用程序的实例的情况下，请求架构管理器或者VIM删除该应用程序的实例。
在图3～图6b所示方法中，容器镜像仓库可以存储有容器镜像文件，该容器镜像文件中可以保存有采用容器部署的应用程序。类似的，VM镜像仓库中可以存储有VM镜像文件，该VM镜像文件中可以保存有采用VM部署的应用程序，容器镜像仓库和VM镜像仓库中可以包括一个或者多个应用程序，每个应用程序可以由应用程序的ID唯一标识。示例性的，可以通过板载(on-boarding)流程将应用程序存储到镜像仓库(容器镜像仓库或者VM镜像仓库)中。具体的，该过程可以如图7a所示，包括：
步骤701a：OSS向MEO发送板载应用程序请求。
其中，板载应用程序请求可以用于请求将应用程序板载到MEC系统中，该板载应用程序请求可以包括应用程序以及部署类型标识，该部署类型标识可以用于标识该应用程序 为容器部署的应用程序或者VM部署的应用程序。
需要说明的是，当应用程序为容器部署的应用程序时，该板载应用程序请求还可以包括容器镜像地址，当应用程序为VM部署的应用程序时，该板载应用程序请求还可以包括VM镜像地址，本申请实施例对此不作限制。
示例性的，OSS可以接收CFS门户或者user app LCM proxy发送的板载应用程序请求，并将接收到的板载应用程序请求转发给MEO。
步骤702a、MEO接收板载应用程序请求，将应用程序保存到镜像仓库中。
示例性，镜像仓库可以部署在MEO或者MEPM中，不予限制。镜像仓库可以包括容器镜像仓库和VM镜像仓库，若部署类型标识用于标识应用程序为容器镜像，则将应用程序保存到容器镜像仓库中，若部署类型标识用于标识应用程序为VM应用程序，则将应用程序保存到VM镜像仓库中。
同时，MEO可以为每个应用程序分配ID，以唯一标识该应用程序，还可以为每个应用程序分配与其相关的状态信息，如：可以分配应用程序的状态为可用或者不可用等等。
步骤703a、MEO向OSS发送板载应用程序请求的响应。
其中，板载应用程序请求的响应可以用于指示该应用程序成功板载(或者保存)到MEC系统中。板载应用程序请求的响应与步骤701a中的板载应用程序请求对应，可以包括但不限于应用程序的ID等信息。
在图7a所示方法中，为了防止恶意应用程序攻击，板载应用程序请求包括的应用程序中可以包括强制元素，当MEO接收到板载应用程序请求后，可以检验应用程序包括的强制元素与约定元素是否相同，若相同，则表示应用程序具备完整性和真实性，可以保存到MEC系统中；反之，若应用程序包括的强制元素与约定元素不同，则表示应用程序被篡改等，不能将应用程序保存到MEC系统中，该应用程序板载失败。
其中，约定元素可以为OSS与MEO之间事先预定好的、能够用于检验应用程序的真实性和完整性的元素。
如此，可以将应用程序板载到MEC系统中，该应用程序在MEC系统中是可用的，可以进行实例化部署。
在图3～图6b所示方法中，MEO可以对板载后的应用程序进行如下管理：查询、禁用(或者去使能(disable)、启用(enable，使能)、删除等。具体的，查询应用程序的过程可参照图7b所示，禁用应用程序的过程可参照图7c所示，启用应用程序的过程可参照图7d所示，删除应用程序的过程可参照图7e所示。
图7b为本申请实施例提供的一种查询应用程序的流程图，如图7b所示，可以包括：
步骤701b：OSS向MEO发送查询应用程序请求。
其中，查询应用程序请求可以用于请求查询应用程序的相关信息，如：应用程序的规则和要求等。该查询应用程序请求可以包括应用程序的ID，还可以包括其他信息，如：过滤条件等等，不予限制。
示例性的，OSS可以接收CFS门户或者user bpp LCM proxy发送的查询应用程序请求，并将接收到的查询应用程序请求转发给MEO。
步骤702b、MEO接收查询应用程序请求，从镜像仓库中查询应用程序的相关信息。
示例性，若应用程序为容器镜像，则MEO从容器镜像仓库中查询应用程序的相关信 息；若应用程序为VM应用程序，则MEO从VM镜像仓库中查询应用程序的相关信息。
步骤703b、MEO向OSS发送查询应用程序请求的响应。
其中，查询应用程序请求的响应可以包括应用程序的相关信息，如：应用程序的规则和要求等。示例性的，MEO可以将满足过滤条件的应用程序的相关信息携带在该响应中发送给OSS。
如此，可以通过图7b所示的查询流程，查询应用程序的相关信息。
图7c为本申请实施例提供的一种禁用应用程序的流程图，如图7c所示，可以包括：
步骤701c：OSS向MEO发送禁用应用程序的请求。
其中，禁用应用程序请求可以用于请求禁用应用程序，使该应用程序不可用。该禁用应用程序请求可以包括应用程序的ID等，不予限制。
示例性的，OSS可以接收CFS门户或者user bpp LCM proxy发送的禁用应用程序请求，并将接收到的禁用应用程序请求转发给MEO。
步骤702c：MEO接收禁用应用程序请求，根据禁用应用程序请求，确认禁用应用程序。
示例性的，MEO可以先根据禁用应用程序请求所包括的应用程序的ID，检查该应用程序的ID所标识的应用程序是否存在，若存在，则查看应用程序的状态是不是启用；若启用了该应用程序，则MEO将该应用程序标记为禁用。
步骤703c：MEO向OSS发送禁用应用程序的响应。
其中，所述禁用应用程序的响应可以用于指示该应用程序在MEC系统中被禁用。
如此，可以通过图7c所示流程禁用MEC系统中存在的应用程序。
图7d为本申请实施例提供的一种启用应用程序的流程图，如图7d所示，可以包括：
步骤701d：OSS向MEO发送启用应用程序的请求。
其中，启用应用程序请求可以用于请求启用应用程序，使该应用程序在MEC系统中可用。该启用应用程序请求可以包括应用程序的ID等，不予限制。
示例性的，OSS可以接收DFS门户或者user bpp LDM proxy发送的启用应用程序请求，并将接收到的启用应用程序请求转发给MEO。
步骤702d：MEO接收启用应用程序请求，根据启用应用程序请求，确认启用应用程序。
示例性的，MEO可以先根据启用应用程序请求所包括的应用程序的ID，检查该应用程序的ID所标识的应用程序是否存在，若存在，则查看该应用程序是否被标记禁用且未标记为删除待处理，若是，则启用该应用程序。
步骤703d：MEO向OSS发送启用应用程序的响应。
其中，所述启用应用程序的响应可以用于指示该应用程序在MED系统中被启用。
如此，可以通过图7d所示流程启用MED系统中存在的应用程序。
图7e为本申请实施例提供的一种删除应用程序的流程图，如图7e所示，可以包括：
步骤701e：OSS向MEO发送删除应用程序的请求。
其中，删除应用程序请求可以用于请求删除应用程序，使该应用程序在MEC系统中可用。该删除应用程序请求可以包括应用程序的ID以及应用程序的部署类型标识(VM或者容器)，也可以包括其他信息，不予限制。
示例性的，OSS可以接收EFS门户或者user app LEM proxy发送的删除应用程序请求，并将接收到的删除应用程序请求转发给MEO。
步骤702e：MEO接收删除应用程序请求，根据删除应用程序请求，确认删除应用程序。
示例性的，MEO可以先根据删除应用程序请求所包括的应用程序的ID，检查该应用程序的ID所标识的应用程序是否已禁用以及是否已禁用应用程序正在使用中。如果应用程序已禁用但正在使用中，则MEO会设置应用程序的状态为删除暂挂。如果应用程序已禁用且未使用，则MEO从移动边缘系统中删除应用程序。
具体来说，MEO可以根据删除应用程序请求所包括的部署类型标识(VM部署或者容器部署)，判断请求删除的应用程序是VM应用程序还是容器镜像，如果请求删除的是VM应用程序，则MEO与保存有VM应用程序的文件服务器交互删除；如果是容器镜像，则MEO需要访问容器镜像仓库，调用容器引擎命令删除对应的容器镜像。如果应用程序处于删除暂挂状态，则MEO可以检查该应用程序对应的所有实例，待应用程序的实例终止后删除该应用程序。如果没有使用的应用程序的实例，则MEO可以删除该应用程序。
步骤703e：MEO向OSS发送删除应用程序的响应。
其中，所述删除应用程序的响应可以用于指示该应用程序在MEO系统中被删除。
如此，可以通过图7e所示流程删除MEO系统中存在的应用程序。
上述主要从MEC系统中各个功能实体之间交互的角度对本申请实施例提供的方案进行了介绍。可以理解的是，各个功能实体，例如统一编排功能实体(MEPM或者MEO)、VIM等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对MEPM进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
图8示出了的一种统一编排功能实体80的结构图，该统一编排功能实体80可以为MEO或者MEO中的芯片或者片上系统，还可以为MEPM或者MEPM中的芯片或者片上系统，该统一编排功能实体80可以用于执行上述实施例中涉及的统一编排功能实体的功能。作为一种可实现方式，图8所示的统一编排功能实体80包括：
统一编排调度管理模块801，用于接收部署请求，并根据部署请求，确定应用程序的部署方式，其中，部署请求用于请求部署应用程序的实例，部署请求包括应用程序的标识ID和编排信息，编排信息用于指示部署应用程序的实例所需的资源；应用程序的部署方式包括容器部署或者虚拟机VM部署。例如，统一编排调度管理模块801可以支持统一编排功能实体80执行步骤301、步骤302等。
进一步的，如图8所示，统一编排功能实体80还可以包括：容器编排管理模块802，用于若统一编排调度管理模块801确定应用程序的部署方式为容器部署，则向架构管理器发送第一资源分配请求，其中，第一资源分配请求用于请求部署能够运行应用程序的实例的容器所需的资源。例如，容器编排管理模块802可以用于支持统一编功能实体80执行步骤303等。
VM调度管理模块803，用于若统一编排调度管理模块801确定应用程序的部署方式为VM部署，则向VIM发送第二资源分配请求，其中，第二资源分配请求用于请求部署能够运行应用程序的实例的VM所需的资源。例如，VM调度管理模块803可以用于支持统一编排功能实体80执行步骤306等。
其中，架构管理器可以为VIM或者CIM等，不予限制。
需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。本申请实施例提供的统一编排功能实体80，用于执行上述部署虚拟机和容器的方法统一编排功能实体80的功能，因此可以达到与上述部署虚拟机和容器的方法相同的效果。
此外，需要说明的是，本申请实施例不限制统一编排功能实体80所包括的部件的部署位置，统一编排功能实体80所包括的部件可以集中部署在MEO或者MEPM中，也可以分离部署在不同的功能实体中，例如，统一编排调度管理模块801可以部署在MEO中，容器编排管理模块802和VM调度管理模块803可以部署在MEPM中，不予限制。
作为又一种可实现方式，图8所示统一编排功能实体80可以包括：处理模块和通信模块。统一编排调度管理模块801、容器编排管理模块802和VM调度管理模块803可以集成在处理模块中。处理模块用于对通信模块接收到的信息进行控制管理，例如，处理模块用于支持该统一编排功能实体80执行步骤301、步骤302、步骤303、步骤306以及执行本文所描述的技术的其它过程。通信模块用于支持统一编排功能实体80接收部署请求以及与其他网络实体的通信，例如与图1示出的功能模块或网络实体之间的通信。进一步的，该统一编排功能实体80还可以包括存储模块，用于存储统一编排功能实体80的程序代码和数据。
其中，处理模块可以是处理器，如：可以是中央处理器(central processing unit，CPU)，通用处理器网络处理器(network processor，NP)、数字信号处理器(digital signal processing，DSP)、微处理器、微控制器、可编程逻辑器件(programmable logic device，PLD)或它们的任意组合。处理器还可以是其它任意具有处理功能的装置，例如电路、器件或软件模块。
通信模块可以为与其他设备或通信网络通信(如以太网，无线接入网(radio access network，RAN)的通信接口，如可以为模块、电路、收发器或者任何能够实现通信的装置。
存储器可以是只读存储器(read-only memory，ROM)或可存储静态信息和/或指令的其他类型的静态存储设备，也可以是随机存取存储器(random access memory，RAM)或者可存储信息和/或指令的其他类型的动态存储设备，还可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或 存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。一种可能的设计中，存储器可以独立于处理器存在，即存储器可以为处理器外部的存储器，此时，存储器可以通过通信线路与处理器相连接，用于存储指令或者程序代码。处理器调用并执行存储器中存储的指令或程序代码时，能够实现本申请下述实施例提供的部署虚拟机和容器的方法。又一种可能的设计中，存储器也可以和处理器集成在一起，即存储器可以为处理器的内部存储器，例如，该存储器为高速缓存，可以用于暂存一些数据和/或指令信息等。图9为本申请实施例提供的一种MEC系统架构图，如图9所示，该系统可以包括：统一编排功能实体80、VIM81，其中，统一编排功能实体80与图8所示功能实体包括相同部件，且具有相同功能。统一编排功能实体可以为图1或者图2所示的MEPM或MEO。
统一编排功能实体80，用于接收部署请求，根据部署请求确定应用程序的部署方式，其中，部署请求用于请求部署应用程序的实例，部署请求包括应用程序的标识ID和编排信息，编排信息用于指示部署应用程序的实例所需的资源，应用程序的部署方式包括容器部署或者虚拟机VM部署；
统一编排功能实体80，还用于若应用程序的部署方式为容器部署，则向VIM81发送第一资源分配请求，其中，第一资源分配请求用于请求部署能够运行应用程序的实例的容器所需的资源；或者，若应用程序的部署方式为VM部署，则向VIM81发送第二资源分配请求，其中，第二资源分配请求用于请求部署能够运行应用程序的实例的VM所需的资源；
VIM81，用于接收第一资源分配请求，根据第一资源分配请求部署能够运行应用程序的实例的容器；或者，用于接收第二资源分配请求，根据第二资源分配请求部署能够运行应用程序的虚拟机VM。
需要说明的是，上述系统架构中各功能实体的具体实施方法可参照上述方法实施例涉及的各步骤的所有相关内容，在此不再赘述。
基于图9所示系统，MEPM或者MEO接收到部署应用程序的请求后，可以对接收到的请求进行分析，确定请求部署的应用程序的部署方式(容器部署或者VM部署)，若为容器部署，则向VIM发送资源分配请求，请求采用容器部署方式部署应用程序所需的资源，完成应用程序的容器部署；若为VM部署，则向VIM发送资源分配请求，请求采用VM部署方式部署应用程序所需的资源，完成应用程序的VM部署，如此，可以在MEC系统中即可以实现VM部署，又可以实现容器部署。
图10为本申请实施例提供的又一种MEC系统架构图，如图10所示，该系统可以包括：统一编排功能实体80、VIM81以及CIM82，其中，统一编排功能实体80与图8所示功能实体包括相同部件，且具有相同功能，统一编排功能实体可以为图1或者图2所示的MEPM或MEO。
统一编排功能实体80，用于接收部署请求，根据部署请求确定应用程序的部署方式，其中，部署请求用于请求部署应用程序的实例，部署请求包括应用程序的标识ID和编排信息，编排信息用于指示部署应用程序的实例所需的资源，应用程序的部署方式包括容器部署或者虚拟机VM部署；
统一编排功能实体80，还用于若应用程序的部署方式为容器部署，则向VIM81发送 第一资源分配请求，其中，第一资源分配请求用于请求部署能够运行应用程序的实例的容器所需的资源；或者，若应用程序的部署方式为VM部署，则统一编排功能实体80向CIM82发送第二资源分配请求，其中，第二资源分配请求用于请求部署能够运行应用程序的实例的VM所需的资源；
VIM81，用于接收第一资源分配请求，根据第一资源分配请求部署能够运行应用程序的实例的容器；
CIM82，用于接收第二资源分配请求，根据第二资源分配请求部署能够运行应用程序的虚拟机VM。
需要说明的是，上述系统架构中各功能实体的具体实施方法可参照上述方法实施例涉及的各步骤的所有相关内容，在此不再赘述。
基于图10所示系统，MEPM或者MEO接收到部署应用程序的请求后，可以对接收到的请求进行分析，确定请求部署的应用程序的部署方式(容器部署或者VM部署)，若为容器部署，则向CIM发送资源分配请求，请求采用容器部署方式部署应用程序所需的资源，完成应用程序的容器部署；若为VM部署，则向VIM发送资源分配请求，请求采用VM部署方式部署应用程序所需的资源，完成应用程序的VM部署，如此，可以在MEC系统中即可以实现VM部署，又可以实现容器部署。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (19)

  1. 一种部署虚拟机和容器的方法，其特征在于，所述方法包括：
    统一编排功能实体接收部署请求，其中，所述部署请求用于请求部署应用程序的实例，所述部署请求包括所述应用程序的标识ID和编排信息，所述编排信息用于指示运行所述应用程序的实例所需的资源；
    所述统一编排功能实体根据所述部署请求，确定所述应用程序的部署方式，其中，所述应用程序的部署方式包括容器部署或者虚拟机VM部署。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    若所述应用程序的部署方式为容器部署，则所述统一编排功能实体向架构管理器发送第一资源分配请求，其中，所述第一资源分配请求用于请求部署能够运行所述应用程序的实例的容器所需的资源；或者，
    若所述应用程序的部署方式为VM部署，则所述统一编排功能实体向虚拟化基础架构管理器VIM发送第二资源分配请求，其中，第二资源分配请求用于请求部署能够运行所述应用程序的实例的VM所需的资源。
  3. 根据权利要求1或2所述的方法，其特征在于，应用程序的ID与应用程序的部署方式间存在对应关系，所述统一编排功能实体根据所述部署请求，确定所述应用程序的部署方式包括：
    所述统一编排功能实体根据所述应用程序的ID以及所述对应关系，确定所述应用程序的部署方式。
  4. 根据权利要求1或2所述的方法，其特征在于，所述部署请求中还包括部署类型标识，所述部署类型标识用于标识所述应用程序的部署方式，所述统一编排功能实体根据所述部署请求，确定所述应用程序的部署方式包括：
    所述统一编排功能实体根据所述部署类型标识，确定所述应用程序的部署方式。
  5. 根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：
    所述统一编排功能实体向移动边缘平台MEP发送配置请求，其中，所述配置请求用于请求所述MEP配置运行所述应用程序的实例所遵循的流量规则、域名系统DNS规则。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
    所述统一编排功能实体接收终止请求；所述终止请求包括所述应用程序的ID，所述终止请求用于终止所述应用程序的实例；
    若所述应用程序的部署方式为容器部署，则所述统一编排功能实体向架构管理器发送第一资源删除请求，其中，所述第一资源删除请求可以用于请求所述架构管理器删除所述应用程序的实例占用的资源；
    若所述应用程序的部署方式为VM部署，则所述统一编排功能实体向VIM发送第二资源删除请求，其中，所述第一资源删除请求可以用于请求VIM删除所述应用程序的实例占用的资源。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，所述统一编排功能实体为移动边缘平台管理器MEPM或者移动边缘编排器MEO。
  8. 根据权利要求2或6所述的方法，其特征在于，所述架构管理器为所述VIM或者容器基础架构管理器CIM。
  9. 一种统一编排功能实体，其特征在于，所述统一编排功能实体包括：
    统一编排调度管理模块，用于接收部署请求，并根据所述部署请求，确定应用程序的部署方式，其中，所述部署请求用于请求部署所述应用程序的实例，所述部署请求包括所述应用程序的标识ID和编排信息，所述编排信息用于指示部署所述应用程序的实例所需的资源；所述应用程序的部署方式包括容器部署或者虚拟机VM部署。
  10. 根据权利要求9所述的统一编排功能实体，其特征在于，所述统一编排功能实体还包括：
    容器编排管理模块，用于若所述统一编排调度管理模块确定所述应用程序的部署方式为容器部署，则向架构管理器发送第一资源分配请求，其中，所述第一资源分配请求用于请求部署能够运行所述应用程序的实例的容器所需的资源；
    虚拟机VM调度管理模块，用于若所述统一编排调度管理模块确定所述应用程序的部署方式为VM部署，则向虚拟化基础架构管理器VIM发送第二资源分配请求，其中，所述第二资源分配请求用于请求部署能够运行所述应用程序的实例的VM所需的资源。
  11. 根据权利要求9或10所述的统一编排功能实体，其特征在于，应用程序的ID与应用程序的部署方式间存在对应关系，所述统一编排调度管理模块，具体用于：
    根据所述应用程序的ID以及所述对应关系，确定所述应用程序的部署方式。
  12. 根据权利要求9或10所述的统一编排功能实体，其特征在于，所述部署请求中还包括部署类型标识，所述部署类型标识用于标识所述应用程序的部署方式，所述统一编排调度管理模块，具体用于：根据所述部署类型标识，确定所述应用程序的部署方式。
  13. 根据权利要求9-12任一项所述的统一编排功能实体，其特征在于，所述统一编排调度管理模块，还用于向移动边缘平台MEP发送配置请求，其中，所述配置请求用于请求所述MEP配置运行所述应用程序的实例所遵循的流量规则、域名系统DNS规则。
  14. 根据权利要求9-13任一项所述的统一编排功能实体，其特征在于，
    所述统一编排调度管理模块，还用于接收终止请求；所述终止请求包括所述应用程序的ID，所述终止请求用于终止所述应用程序的实例；
    容器编排管理模块，还用于若所述应用程序的部署方式为容器部署，则向架构管理器发送第一资源删除请求，其中，所述第一资源删除请求可以用于请求所述架构管理器删除所述应用程序的实例占用的资源；
    VM调度管理模块，还用于若所述应用程序的部署方式为VM部署，则所述统一编排功能实体向所述VIM发送第二资源删除请求，其中，所述第一资源删除请求可以用于请求VIM删除所述应用程序的实例占用的资源。
  15. 根据权利要求9-14任一项所述的统一编排功能实体，其特征在于，所述统一编排功能实体为移动边缘平台管理器MEPM或者移动边缘编排器MEO。
  16. 根据权利要求10或14所述的统一编排功能实体，其特征在于，所述架构管理器为所述VIM或者容器基础架构管理器CIM。
  17. 一种多接入边缘计算MEC系统，其特征在于，所述MEC系统包括：统一编排功能实体、虚拟化基础架构管理器VIM；
    所述统一编排功能实体，用于接收部署请求，根据所述部署请求确定应用程序的部署方式，其中，所述部署请求用于请求部署所述应用程序的实例，所述部署请求包括所述应 用程序的标识ID和编排信息，所述编排信息用于指示部署所述应用程序的实例所需的资源，所述应用程序的部署方式包括容器部署或者虚拟机VM部署；
    当所述应用程序的部署方式为容器部署时，所述统一编排功能实体，还用于向所述VIM发送第一资源分配请求，其中，所述第一资源分配请求用于请求部署能够运行所述应用程序的实例的容器所需的资源；或者，当所述应用程序的部署方式为VM部署时，所述统一编排功能实体，还用于向所述VIM发送第二资源分配请求，其中，所述第二资源分配请求用于请求部署能够运行所述应用程序的实例的VM所需的资源；
    所述VIM，用于接收第一资源分配请求，根据第一资源分配请求部署能够运行所述应用程序的实例的容器；或者，用于接收第二资源分配请求，根据所述第二资源分配请求部署能够运行所述应用程序的虚拟机VM。
  18. 一种多接入边缘计算MEC系统，其特征在于，所述MEC系统包括：统一编排功能实体、移动边缘编排器MEO、虚拟化基础架构管理器VIM以及容器基础架构管理器CIM；
    所述统一编排功能实体，用于接收部署请求，根据所述部署请求确定应用程序的部署方式，其中，所述部署请求用于请求部署所述应用程序的实例，所述部署请求包括所述应用程序的标识ID和编排信息，所述编排信息用于指示部署所述应用程序的实例所需的资源，所述应用程序的部署方式包括容器部署或者虚拟机VM部署；
    当所述应用程序的部署方式为容器部署时，所述统一编排功能实体，还用于向所述CIM发送第一资源分配请求，其中，所述第一资源分配请求用于请求部署能够运行所述应用程序的实例的容器所需的资源；或者，当所述应用程序的部署方式为VM部署时，所述统一编排功能实体，还用于向所述VIM发送第二资源分配请求，其中，所述第二资源分配请求用于请求部署能够运行所述应用程序的实例的VM所需的资源；
    所述CIM，用于接收第一资源分配请求，根据第一资源分配请求部署能够运行所述应用程序的实例的容器；
    所述VIM，用于接收第二资源分配请求，根据所述第二资源分配请求部署能够运行所述应用程序的虚拟机VM。
  19. 根据权利要求17或者18所述的MEC系统，其特征在于，所述统一编排功能实体为移动边缘平台管理器MEPM或者移动边缘编排器MEO。
PCT/CN2020/080505 2019-03-22 2020-03-20 一种部署虚拟机和容器的方法及装置 WO2020192598A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20778926.4A EP3933580B1 (en) 2019-03-22 2020-03-20 Method and device for deploying virtual machine or container
US17/481,549 US20220004410A1 (en) 2019-03-22 2021-09-22 Method For Deploying Virtual Machine And Container, And Related Apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910224223.9 2019-03-22
CN201910224223.9A CN111722906A (zh) 2019-03-22 2019-03-22 一种部署虚拟机和容器的方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/481,549 Continuation US20220004410A1 (en) 2019-03-22 2021-09-22 Method For Deploying Virtual Machine And Container, And Related Apparatus

Publications (1)

Publication Number Publication Date
WO2020192598A1 true WO2020192598A1 (zh) 2020-10-01

Family

ID=72563737

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/080505 WO2020192598A1 (zh) 2019-03-22 2020-03-20 一种部署虚拟机和容器的方法及装置

Country Status (4)

Country Link
US (1) US20220004410A1 (zh)
EP (1) EP3933580B1 (zh)
CN (1) CN111722906A (zh)
WO (1) WO2020192598A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114500539A (zh) * 2022-04-14 2022-05-13 浙江大云物联科技有限公司 智慧路灯系统中边缘应用部署方法、装置及可读存储介质
WO2022260330A1 (en) * 2021-06-08 2022-12-15 Samsung Electronics Co., Ltd. Improvements in and relating to multi-access edge computing
WO2022267994A1 (zh) * 2021-06-24 2022-12-29 中移(成都)信息通信科技有限公司 通信系统、方法、装置、第一设备、第二设备及存储介质
CN117573379A (zh) * 2024-01-16 2024-02-20 国网湖北省电力有限公司信息通信公司 一种基于对称放缩合并的微服务部署方法

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112330229B (zh) * 2020-12-02 2023-09-22 北京元心科技有限公司 资源调度方法、装置、电子设备及计算机可读存储介质
CN113282302A (zh) * 2021-05-10 2021-08-20 浙江九州云信息科技有限公司 一种基于5g+ai工业视觉的边缘应用管理方法及系统
TWI786908B (zh) * 2021-10-28 2022-12-11 中華電信股份有限公司 用於優化網路功能管理之系統、方法及其電腦可讀媒介
CN114880000A (zh) * 2022-07-05 2022-08-09 深圳市信润富联数字科技有限公司 工控机远程运维方法、装置、电子设备及存储介质
US11915059B2 (en) * 2022-07-27 2024-02-27 Oracle International Corporation Virtual edge devices
US20240080242A1 (en) 2022-08-29 2024-03-07 Oracle International Corporation Control plane techniques for substrate managed containers
US20240113968A1 (en) * 2022-10-04 2024-04-04 Vmware, Inc. Using crds to create externally routable addresses and route records for pods
US20240248741A1 (en) * 2023-01-19 2024-07-25 VMware LLC Unified deployment of container infrastructure and resources
CN117389690B (zh) * 2023-12-08 2024-03-15 中电云计算技术有限公司 镜像包的构建方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107766050A (zh) * 2017-10-31 2018-03-06 新华三云计算技术有限公司 一种异构应用的部署方法以及装置
CN108399094A (zh) * 2017-02-08 2018-08-14 中国移动通信有限公司研究院 一种应用的部署方法、其部署装置及边缘数据中心
US20190042319A1 (en) * 2018-09-28 2019-02-07 Kapil Sood Mobile edge-cloud security infrastructure
CN109358967A (zh) * 2018-09-26 2019-02-19 中国联合网络通信集团有限公司 一种me平台app实例化迁移方法及服务器

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR112018000241A2 (pt) * 2015-07-23 2018-11-06 Intel Corporation modelo de recursos de rede para suportar gerenciamento de ciclo de vida de virtualização de função de rede
US10048977B2 (en) * 2015-12-22 2018-08-14 Intel Corporation Methods and apparatus for multi-stage VM virtual network function and virtual service function chain acceleration for NFV and needs-based hardware acceleration
WO2017143548A1 (zh) * 2016-02-25 2017-08-31 华为技术有限公司 用于应用自动化部署的方法和云管理节点
WO2017166136A1 (zh) * 2016-03-30 2017-10-05 华为技术有限公司 一种vnf的资源分配方法及装置
US10073974B2 (en) * 2016-07-21 2018-09-11 International Business Machines Corporation Generating containers for applications utilizing reduced sets of libraries based on risk analysis
CN106453646A (zh) * 2016-11-29 2017-02-22 上海有云信息技术有限公司 一种安全服务平台的资源调度方法和装置
CN107145380B (zh) * 2017-03-27 2020-06-16 华为技术有限公司 虚拟资源编排方法及装置
CN108737131B (zh) * 2017-04-14 2021-04-20 中兴通讯股份有限公司 网络设备虚拟化的实现方法和装置
WO2018224243A1 (en) * 2017-06-08 2018-12-13 British Telecommunications Public Limited Company Containerised programming
CN109039686B (zh) * 2017-06-12 2022-11-08 中兴通讯股份有限公司 一种业务混合编排的方法及装置
CN114880078A (zh) * 2018-06-05 2022-08-09 华为技术有限公司 管理容器服务的方法和装置
US11244242B2 (en) * 2018-09-07 2022-02-08 Intel Corporation Technologies for distributing gradient descent computation in a heterogeneous multi-access edge computing (MEC) networks
CN111949364A (zh) * 2019-05-16 2020-11-17 华为技术有限公司 容器化vnf的部署方法和相关设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108399094A (zh) * 2017-02-08 2018-08-14 中国移动通信有限公司研究院 一种应用的部署方法、其部署装置及边缘数据中心
CN107766050A (zh) * 2017-10-31 2018-03-06 新华三云计算技术有限公司 一种异构应用的部署方法以及装置
CN109358967A (zh) * 2018-09-26 2019-02-19 中国联合网络通信集团有限公司 一种me平台app实例化迁移方法及服务器
US20190042319A1 (en) * 2018-09-28 2019-02-07 Kapil Sood Mobile edge-cloud security infrastructure

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3933580A4

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022260330A1 (en) * 2021-06-08 2022-12-15 Samsung Electronics Co., Ltd. Improvements in and relating to multi-access edge computing
US11936527B2 (en) 2021-06-08 2024-03-19 Samsung Electronics Co., Ltd Multi-access edge computing (MEC)
WO2022267994A1 (zh) * 2021-06-24 2022-12-29 中移(成都)信息通信科技有限公司 通信系统、方法、装置、第一设备、第二设备及存储介质
CN114500539A (zh) * 2022-04-14 2022-05-13 浙江大云物联科技有限公司 智慧路灯系统中边缘应用部署方法、装置及可读存储介质
CN114500539B (zh) * 2022-04-14 2022-08-16 浙江大云物联科技有限公司 智慧路灯系统中边缘应用部署方法、装置及可读存储介质
CN117573379A (zh) * 2024-01-16 2024-02-20 国网湖北省电力有限公司信息通信公司 一种基于对称放缩合并的微服务部署方法
CN117573379B (zh) * 2024-01-16 2024-03-29 国网湖北省电力有限公司信息通信公司 一种基于对称放缩合并的微服务部署方法

Also Published As

Publication number Publication date
EP3933580A1 (en) 2022-01-05
CN111722906A (zh) 2020-09-29
EP3933580A4 (en) 2022-04-06
EP3933580B1 (en) 2024-08-21
US20220004410A1 (en) 2022-01-06

Similar Documents

Publication Publication Date Title
WO2020192598A1 (zh) 一种部署虚拟机和容器的方法及装置
US7587492B2 (en) Dynamic performance management for virtual servers
US11573725B2 (en) Object migration method, device, and system
WO2015196931A1 (zh) 基于磁盘io的虚拟资源分配方法及装置
US8104038B1 (en) Matching descriptions of resources with workload requirements
CN111464355A (zh) Kubernetes容器集群的伸缩容控制方法、装置和网络设备
US20210405902A1 (en) Rule-based provisioning for heterogeneous distributed systems
CN110716788B (zh) 管理虚拟化资源的方法和装置
CN108399101A (zh) 资源调度的方法、装置和系统
US20190281503A1 (en) Management Method, Management Unit, and System
US20220057947A1 (en) Application aware provisioning for distributed systems
US11036535B2 (en) Data storage method and apparatus
US11726684B1 (en) Cluster rebalance using user defined rules
US20210132860A1 (en) Management of multiple physical function non-volatile memory devices
US10360076B1 (en) Prioritized rebalancing of distributed file system
CN106911741B (zh) 一种虚拟化网管文件下载负载均衡的方法及网管服务器
CN106331075B (zh) 用于存储文件的方法、元数据服务器和管理器
WO2022052898A1 (zh) 一种计算机系统、容器管理方法及装置
WO2022140945A1 (zh) 容器集群的管理方法和装置
CN114296909A (zh) 一种根据kubernetes事件的节点自动扩容缩容方法及系统
US11301436B2 (en) File storage method and storage apparatus
CN112015515B (zh) 一种虚拟网络功能的实例化方法及装置
CN105307130A (zh) 一种资源分配方法及系统
CN112889247B (zh) Vnf服务实例化方法及装置
US11340950B2 (en) Service band management system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20778926

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020778926

Country of ref document: EP

Effective date: 20210927