WO2023220904A1

WO2023220904A1 - Virtual-machine level decentralized service management

Info

Publication number: WO2023220904A1
Application number: PCT/CN2022/093204
Authority: WO
Inventors: Xiaopeng Wang; Aonan ZHAI; Charles Hai Qing ZHU; Sid SIDHARTHA; Rakesh KELKAR; Wen Yang; Petro DEGTIARENKO
Original assignee: Microsoft Technology Licensing, Llc
Priority date: 2022-05-17
Filing date: 2022-05-17
Publication date: 2023-11-23
Also published as: CN118020060A

Abstract

The present disclosure provides methods, apparatuses and virtual machines for implementing virtual-machine level decentralized service management at a virtual machine in a cloud service platform. The virtual machine may be included in a virtual machine set associated with a target service. An action execution request for the target service, which indicates an action associated with the target service, may be received from a control plane in the cloud service platform, and an action execution event may be generated based on the action execution request. Alternatively, an action execution event for the target service, which indicates an action associated with the target service, may be received from a second virtual machine in the virtual machine set. The action execution event may be propagated in the virtual machine set. Execution of the action at the virtual machine may be triggered based at least on the action execution event.

Description

VIRTUAL-MACHINE LEVEL DECENTRALIZED SERVICE MANAGEMENT

BACKGROUND

Cloud service platform may provide users with resources required to support their services. In a multi-user or multi-tenant scenario, the cloud service platform may operate based on virtual machines (VMs) , and may run different services on isolated VM sets. For example, a service from a user may be run on an exclusive VM set in the cloud service platform, and VMs in this VM set would not be applied for other users’ services. That is, different services from different users would be run on respective VM sets, and these VM sets would not be shared among different services or different users. Herein, the term “users” may refer to various entities that utilize the cloud service platform to run their services, which may also be referred to as “tenants” , “customers” , etc.

SUMMARY

This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. It is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Embodiments of the present disclosure propose methods, apparatuses and virtual machines for implementing virtual-machine level decentralized service management at a virtual machine in a cloud service platform. The virtual machine may be included in a virtual machine set associated with a target service. An action execution request for the target service, which indicates an action associated with the target service, may be received from a control plane in the cloud service platform, and an action execution event may be generated based on the action execution request. Alternatively, an action execution event for the target service, which indicates an action associated with the target service, may be received from a second virtual machine in the virtual machine set. The action execution event may be propagated in the virtual machine set. Execution of the action at the virtual machine may be triggered based at least on the action execution event.

It should be noted that the above one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the drawings set forth in detail certain illustrative features of the one or more aspects. These features are only indicative of the various ways in which the principles of various aspects may be employed, and this disclosure is intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed aspects will hereinafter be described in connection with the appended drawings that are provided to illustrate and not to limit the disclosed aspects.

FIG. 1 illustrates exemplary architecture of VM level decentralized service management according to an embodiment.

FIG. 2 illustrates an exemplary process of implementing VM level decentralized service management at a VM according to an embodiment.

FIG. 3 illustrates an exemplary process of implementing VM level decentralized service management at a VM according to an embodiment.

FIG. 4 illustrates exemplary architecture of VM level decentralized service management for a service update action according to an embodiment.

FIG. 5 illustrates a flowchart of an exemplary method for implementing VM level decentralized service management at a VM in a cloud service platform according to an embodiment.

FIG. 6 illustrates a flowchart of an exemplary method for implementing VM level decentralized service management at a VM in a cloud service platform according to an embodiment.

FIG. 7 illustrates an exemplary apparatus for implementing VM level decentralized service management in a cloud service platform according to an embodiment.

DETAILED DESCRIPTION

The present disclosure will now be discussed with reference to several example implementations. It is to be understood that these implementations are discussed only for enabling those skilled in the art to better understand and thus implement the embodiments of the present disclosure, rather than suggesting any limitations on the scope of the present disclosure.

In the VM-based cloud service platform, there are two existing modes for managing a service run on a VM set, i.e., a push mode and a pull mode. In the push mode, a control plane in the cloud service platform needs to interact with each VM in the VM set, so as to push a request of executing a desired action associated with the service to each VM and collect action status information from each VM, wherein the action status information associated with a VM indicates execution status of the action at the VM. In the pull mode, a central storage system is introduced into the cloud service platform. The control plane publishes a desired action associated with the service to the central storage system. Each VM in the VM set periodically synchronizes with the central storage system through accessing the central storage system directly or via any mid-tier services, so as to get the desired action for execution and report its action status information back to the central storage system. The control plane would then pull back all the action status information associated with all VMs in the VM set from the central storage system.

Compared with the pull mode, the push mode does not need any central storage system. But the push mode will highly increase complexity of the control plane, because the control plane needs to interact with all VMs in the VM set and handle various possible abnormal failure cases due to, e.g., VM restarting, VM replacing, etc.

Compared with the push mode, the pull mode would not significantly increase complexity of the control plane. However, the pull mode requires deploying at least one extra central storage system into the cloud service platform. If all the users share the same central storage system, this central storage system shall support potentially-hostile multi-user or multi-tenant, which is hard to achieve in any public cloud so far. If each user is deployed with an exclusive central storage system and accordingly multiple central storage systems are deployed for multiple users, this will increase the burden of managing the multiple central storage systems in the cloud service platform, and will also lead to extra cost for each user.

Embodiments of the present disclosure propose VM level decentralized service management in a cloud service platform, which avoids significantly-increased complexity of the control plane and does not require any extra central storage system.

According to the embodiments of the present disclosure, a decentralized control layer may be added into each VM for implementing service management. Herein, the service management may refer to, e.g., an action associated with a target service. The control plane only needs to interact with any one VM in a VM set associated with the target service to request executing a desired action associated with the target service at multiple VMs in the VM set, and interact with any one VM in the VM set to pull back action status information associated with the multiple VMs. Thus, the embodiments of the present disclosure work in a new push mode different from the existing push mode, wherein according to the embodiments of the present disclosure, the control panel only needs to push a request of executing a desired action to any one VM in a VM set and pull back action status information associated with multiple VMs in the VM set from any one VM in the VM set, instead of requesting each VM to execute a desired action and collecting action status information from each VM as required in the existing push mode. The control layer may be implemented by, e.g., an administration module, a transport module, a membership discovery module, etc.

Since the control plane only needs to interact with one VM in a VM set to request executing a desired action at multiple VMs or obtain action status information associated with the multiple VMs, the embodiments of the present disclosure may enable the logic of the control plane to be simpler, thus avoiding significantly-increased complexity of the control plane. Accordingly, this will lead to better resource utilization, stability, scaling, etc.

Since no extra central storage system is required, the embodiments of the present disclosure may avoid leading to extra cost of deploying a central storage system for a user and also make the user’s service more stable.

In the existing push mode, the control plane works in an in-the-loop approach, in which the control plane needs to interact with each VM in a VM set for instructing execution of a desired action. While the embodiments of the present disclosure enable the control plane to work in an on-the-loop approach, in which the control plane only needs to interact with any one VM in a VM set. Thus, in the embodiments of the present disclosure, the control plane may instruct execution of a desired action in a fire-and-forget approach, in which after the control plane sends a request of executing a desired action to a VM in a VM set, the control plane could pay no attention to how the request will be propagated among VMs in the VM set. Due to the decentralized mechanism, each VM would have the capability of propagating and collecting events and information, and thus VMs in a VM set would execute the desired action without involving further operations by the control plane in the loop. Accordingly, the embodiments of the present disclosure may be easily adapted to various types of service management, e.g., service update, VM restarting, VM replacing, data publishing, data sharing, data copying, applying security patch, etc. Even for a VM that is restarted or newly-added during or after execution of an action, the VM may easily obtain information about the action from other VMs and execute the action correctly.

Moreover, beneficial from the VM level decentralized service management, the embodiments of the present disclosure may be effectively applied in various scenarios, especially in the multi-user or multi-tenant scenario. For example, a service from each user among the multiple users may be effectively managed through the embodiments of the present disclosure, respectively.

FIG. 1 illustrates exemplary architecture 100 of VM level decentralized service management according to an embodiment.

A cloud service platform may comprise a control plane 102 for controlling, managing, or scheduling various resources or processes according to user’s instructions or predetermined configurations and logics. The control plane 102 may be implemented by software or program codes and may be embodied in one or more nodes in the cloud service platform. The control plane 102 may also be referred to as, e.g., “control plane service” , “control plane layer” , etc. An operator, who is on behalf of a user, may interact with the control plane 102 for issuing instructions related to the user’s service, obtaining desired information, etc.

It is assumed that the cloud service platform comprises a VM set 110 for supporting a target service from a specific user. The VM set 110 may comprise, e.g., a VM 120, a VM 130, a VM 140, etc. It should be understood that the architecture 100 only shows the three exemplary VMs in the VM set 110, but in fact, the VM set 110 may comprise more or less VMs for supporting the target service. Each VM may have various exclusive resources, e.g., computing resources, processing procedures, operating system, etc.

Each VM may run a service instance of the target service. For example, the VM 120 runs a service instance 128, the VM 130 runs a service instance 138, the VM 140 runs a service instance 148, etc.

According to the embodiments of the present disclosure, a decentralized control layer may be added into each VM for implementing service management. In an implementation, the control layer may comprise, e.g., an administration module, a transport module, a membership discovery module, etc. For example, the VM 120 comprises a control layer formed by an administration module 122, a transport module 124 and a membership discovery module 126, the VM 130 comprises a control layer formed by an administration module 132, a transport module 134 and a membership discovery module 136, and the VM 140 comprises a control layer formed by an administration module 142, a transport module 144 and a membership discovery module 146. It should be understood that each of the administration module, the transport module and the membership discovery module may be implemented by software or program codes, and thus may also be deemed as a specific “service” or “layer” . Moreover, although not shown, the transport module and the membership discovery module may also be collectively referred to as a communication module or communication service. Moreover, it should be understood that the concept “control layer” is merely a logical definition of the combination of the administration module, the transport module and the membership discovery module for the sake of explaining and understanding the general idea of the embodiments of the present disclosure, and such concept is not necessarily introduced into and thus can be omitted from the detailed processings involved in the embodiments of the present disclosure.

The administration module may handle business logic. The administration module provides a plugin mechanism through which various types of service management, e.g., various types of action, may be easily and effectively supported. For example, the administration module may comprise various registered or predefined handler plugins for supporting various types of service management related to the target service, respectively. In an implementation, for each type of service management, a corresponding handler plugin may be defined by, e.g., trigger signal, event converter, event handler, event callback handler, etc.

The trigger signal may be a request received or input from the control plane, e.g., an action execution request from the control plane, wherein the action execution request may indicate a desired action associated with the target service and may be generated by the control plane in response to an instruction from the user. A trigger signal for a specific handler plugin may have a type corresponding to the type of service management supported by the handler plugin. For example, if the type of service management or action supported by the handler plugin is “service update” , the trigger signal for this handler plugin shall have or indicate a type of “service update” . Accordingly, for a specific request from the control plane, the administration module may select, among multiple registered handler plugins, a handler plugin corresponding to the type of service management or action indicated by the request, and further start the operation of the selected handler plugin.

The event converter may convert a request received from the control plane into a corresponding event. Herein, an event may refer to a data format that can be understood, processed or transported by modules in a VM. For example, the event converter may convert an action execution request received from the control plane into an action execution event, wherein the action execution event includes information about the desired action indicated by the action execution request. Moreover, the event converter may also convert an event into an information format or data format that can be understood or processed by the control plane. For example, the event converter may extract action status information from an action status changing event. The action status information may be provided to the control plane, which indicates an execution progress or execution result of the desired action at a VM.The action status changing event may be received from another VM, which includes information about an execution progress or execution result of the desired action at said another VM.

The event handler may directly handle an event generated by the event converter. For example, if the event converter generates an action execution event based on an action execution request received from the control plane, the event handler, which is in the same VM with the event converter, may directly handle this action execution event. It should be understood that the handling of the action execution event by the event handler may refer to that the event handler triggers execution of the desired action indicated by the action execution event, e.g. the event handler may invoke or instruct any existing execution module in the VM, which is responsible of executing the action, to execute the action.

The event callback handler may handle an event received from another VM. For example, if an action execution event is received from another VM, the event callback handler may handle this received action execution event. Similar with the event handler, the handling of the action execution event by the event callback handler may refer to that the event callback handler triggers execution of the desired action indicated by the action execution event, e.g. the event callback handler may invoke or instruct any existing execution module in the VM, that is responsible of executing the action, to execute the action.

It should be understood that all the above discussions related to the administration module are exemplary, and the embodiments of the present disclosure are not limited to any specific types of plugin mechanism adopted by the administration module and any specific approaches for defining a handler plugin. Depending on different scenarios or different types of service management, the administration module may comprise various handler plugins and these handler plugins may be defined in various approaches.

From the above discussions, it can be seen that the administration module may not only act as an interface between the control plane and a VM, but also be responsible of handling or controlling various events.

The transport module may propagate events within the VM set. For example, transport modules in different VMs may collaboratively propagate various events among all the VMs in the VM set. Events may be sent and received among transport modules in different VMs. The transport modules in all the VMs in the VM set may work in an eventually-consistent approach, in which the same event will be finally obtained by all of the VMs regardless of which VM generating the event or firstly sending the event. In an implementation, the transport module may operate based on a Gossip protocol. For example, events may be propagated in the VM set through the Gossip protocol. In this way, an event from a VM may be efficiently broadcasted to all other VMs in the VM set. It should be understood that the embodiments of the present disclosure are not limited to any specific transporting approaches adopted by the transport module, e.g., the transport module may adopt any transport techniques that are based on the eventually-consistent approach, besides the Gossip protocol, for propagating events.

The membership discovery module may discover all the VMs in the VM set that supports the same target service and obtain metadata information of these VMs. Herein, since service instances run on different VMs in the VM set are related to the same target service, these service instances on these VMs may be deemed as different members of the target service. Metadata information of a VM may comprise, e.g., IP address of the VM, fault domain, update domain, etc. As an example, the membership discovery module 126 in the VM 120 may at least obtain IP addresses of other VMs in the VM set 110, including an IP address of the VM 130, etc. Thus, when the transport module 124 in the VM 120 is to send an event to the VM 130, the transport module 124 may send the event to the VM 130 based on the IP address of the VM 130 obtained by the membership discovery module 126, and accordingly, the transport module 134 in the VM 130 may receive the event from the VM 120. It should be understood that the embodiments of the present disclosure are not limited to any specific techniques or approaches adopted by the membership discovery module for obtaining metadata information of other VMs.

In the architecture 100, all of the VM 120, the VM 130 and the VM 140 are configured with an administration module, a transport module and a membership discovery module in the same decentralized approach. Accordingly, these VMs have the same capability of implementing VM level decentralized service management. When an action associated with the target service is desired by the user to execute, the control plane 102 only needs to interact with any one VM in the VM set 110 to request executing the action, and this interacted VM could propagate an action execution event corresponding to the action among the VMs in the VM set 110. Each VM could execute the action according to the action execution event. Moreover, each VM may propagate an event status changing event which includes event status information associated with this VM among the VMs in the VM set 110, and thus each VM may obtain event status information associated with other VMs in the VM set 110. Accordingly, the control plane 102 may interact with any one VM in the VM set 110 to pull back action status information associated with the VMs in the VM set 110 from this interacted VM.

It should be understood that, in some cases, the desired action may be required to execute only in a part of designated VMs in the VM set 110. Even in such cases, the embodiments of the present disclosure still can effectively trigger execution of the action at these designated VMs and provide action status information associated with these designated VMs to the control plane 102 in a similar approach as discussed above.

Moreover, the embodiments of the present disclosure may also apply various types of triggering strategy at an administration module in a VM such that the administration module may decide whether or when to trigger execution of an action at the VM based on the triggering strategy. The triggering strategy may be based on, e.g., any combination of an action execution event, at least one action status changing event received from other VMs, and metadata of the current VM. It should be understood that the triggering strategy may vary according to different types of service management or action, and the embodiments of the present disclosure are not limited to any specific triggering strategy.

Moreover, although not shown, each VM may further comprise any existing execution modules that are responsible for executing various actions associated with the target service respectively and can be invoked by the administration module to execute an action. The embodiments of the present invention are not limited to any such existing execution modules or any specific executing approaches of actions

FIG. 2 illustrates an exemplary process 200 of implementing VM level decentralized service management at a VM according to an embodiment. Hereinafter, the VM performing the process 200 may be referred to as a first VM included in a VM set associated with a target service. The first VM may be a VM which interacts with the control plane and receives an action execution request from the control plane. The first VM may be selected from the VM set by the control plane in various approaches, e.g., in a random approach, according to a predefined rule, etc.

At 202, an action execution request may be received from the control plane. For example, an administration module in the first VM may receive the action execution request. The action execution request may indicate an action associated with a target service.

At 204, an action execution event may be generated based on the action execution request. For example, the administration module in the first VM may generate the action execution event based on the action execution request. In an implementation, the administration module may select a registered handler plugin corresponding to the action, and start the operation of the handler plugin. For example, an event converter in the selected handler plugin may convert the action execution request to the action execution event.

At 206, the action execution event may be propagated in the VM set, such that all other VMs in the VM set may receive the action execution event. For example, a transport module in the first VM may propagate the action execution event in the VM set. In an implementation, the process 200 may comprise obtaining metadata information 208 of all other VMs in the VM set. For example, a membership discovery module in the first VM may obtain the metadata information 208 of all other VMs in the VM set. Accordingly, the action execution event may be propagated in the VM set based on the metadata information 208, e.g., IP addresses of other VMs. It should be understood that, each VM in the VM set may comprise a membership discovery module, thus all the VMs may discover each other through respective membership discovery modules.

At 210, execution of the action at the first VM may be triggered based at least on the action execution event. For example, the administration module in the first VM may trigger the execution of the action at the first VM. In this case, a triggering strategy may be defined as: directly triggering execution of an action at a VM in response to an action execution event. As an example, the triggering of execution of the action may comprise invoking or instructing an existing execution module in the first VM, which is responsible of executing the action, to execute the action. In an implementation, an event handler in the selected handler plugin may trigger the execution of the action at the first VM, e.g., instructing the execution module to execute the action.

At 212, action status information associated with the first VM may be obtained in response to the execution of the action at the first VM. For example, the administration module in the first VM may obtain the action status information associated with the first VM from the execution module. In an implementation, the event handler in the selected handler plugin may obtain the action status information. The action status information may include an execution progress or execution result of the action at the first VM, e.g., not started, in progress, success, failure, etc. The embodiments of the present disclosure are not limited to any specific types of information included in the action status information.

At 214, the action status information associated with the first VM may be recorded into an action status information set. For example, the administration module in the first VM may record the action status information associated with the first VM into the action status information set. In an implementation, the event handler in the selected handler plugin may record the action status information associated with the first VM into the action status information set. The action status information set may include the action status information associated with the first VM and action status information associated with other VMs in the VM set.

At 216, an action status changing event may be generated based on the action status information associated with the first VM. The action status changing event may include information about the execution progress or execution result of the action at the first VM. For example, the administration module in the first VM may generate the action status changing event based on the action status information associated with the first VM. In an implementation, the event converter in the selected handler plugin may convert the action status information associated with the first VM into the action status changing event.

At 218, the action status changing event may be propagated in the VM set, such that all other VMs in the VM set may receive the action status changing event and thus obtain the action status information associated with the first VM. For example, the transport module in the first VM may propagate the action status changing event in the VM set.

At 220, at least one action status changing event may be received from at least one VM in the VM set. The received action status changing event may include information about an execution progress or execution result of the action at the at least one VM. For example, the transport module in the first VM may receive the action status changing event from the at least one VM.

At 222, action status information associated with the at least one VM may be extracted from the action status changing event which is received at 220. For example, the administration module in the first VM may extract the action status information associated with the at least one VM from the received action status changing event. In an implementation, the event converter in the selected handler plugin may convert the received action status changing event into the action status information associated with the at least one VM.

At 224, the action status information associated with the at least one VM extracted at 222 may be recorded into the action status information set. For example, the administration module in the first VM may record the extracted action status information associated with the at least one VM into the action status information set. In an implementation, the event handler in the selected handler plugin may record the extracted action status information associated with the at least one VM into the action status information set.

It should be understood that the steps 220, 222 and 224 may be performed iteratively, and thus the first VM may obtain action status information of all other VMs in the VM set and record action status information of these VMs into the action status information set.

Optionally, the process 200 may comprise providing the action status information set to the control plane at 226. The action status information set may include action status information associated with all the VMs in the VM set. The action status information set may be then presented to the user. In an implementation, the first VM may proactively provide the action status information set to the control plane. In an implementation, the first VM may provide the action status information set to the control plane in response to a request received from the control plane. For example, the control plane may interact with the first VM to request the action status information set, and the first VM may provide the action status information set to the control plane in response to such a request. It should be understood that although the process 200 shows that the first VM performing the process 200 provides the action status information set to the control plane, the control plane may also obtain an action status information set from any other VM in the VM set.

Moreover, optionally, if the triggering strategy for triggering the execution of the action at the first VM is defined based on a combination of the action execution event generated at 204 and the at least one action status changing event received at 220, the triggering of the execution of the action at 210 may be decided according to this triggering strategy. In this case, for example, the triggering strategy may regulate that only when execution progresses or execution results of other VMs meet predetermined criteria, the first VM could trigger the execution of the action at the first VM. Accordingly, the triggering of the execution of the action at 210 needs to further consider the at least one action status changing event received from the at least one another VM.

Moreover, optionally, if the triggering strategy for triggering the execution of the action at the first VM is defined based on a combination of the action execution event generated at 204 and metadata of the first VM, or a combination of the action execution event generated at 204, the at least one action status changing event received at 220 and metadata of the first VM, the triggering of the execution of the action at 210 may be decided according to this triggering strategy. In this case, for example, the triggering strategy may regulate that at least when information in the metadata of the first VM meets predetermined criteria, e.g., update domain or fault domain of the first VM meets a predetermined requirement, the first VM could trigger the execution of the action at the first VM. Accordingly, the triggering of the execution of the action at 210 needs to further consider the metadata of the first VM.

It should be understood that all the steps and their orders in the process 200 are exemplary, and the embodiments of the present disclosure would cover any changes to the process 200. For example, although the steps in the process 200 in FIG. 2 are connected by arrows for showing exemplary performing orders, any of these steps may be performed in any other orders or concurrently.

FIG. 3 illustrates an exemplary process 300 of implementing VM level decentralized service management at a VM according to an embodiment. Hereinafter, the VM performing the process 300 may be referred to as a second VM included in a VM set associated with a target service, wherein the second VM may be in the same VM set with the first VM performing the process 200 in FIG. 2. The second VM may be a VM which receives an action execution event from at least one another VM in the VM set, rather than a VM which receives an action execution request from the control plane as shown in FIG. 2. The second VM performing the process 300 may be any one VM in the VM set other than the first VM performing the process 200 in FIG. 2.

At 302, an action execution event for the target service may be received from at least one another VM in the VM set. For example, a transport module in the second VM may receive the action execution event. The action execution event may indicate an action associated with the target service.

At 304, the action execution event may be propagated in the VM set, such that all other VMs in the VM set may receive the action execution event. For example, the transport module in the second VM may propagate the action execution event in the VM set. In an implementation, the process 300 may comprise obtaining metadata information 306 of all other VMs in the VM set. For example, a membership discovery module in the second VM may obtain the metadata information 306 of all other VMs in the VM set. Accordingly, the action execution event may be propagated in the VM set based on the metadata information 306, e.g., IP addresses of other VMs.

At 310, execution of the action at the second VM may be triggered based at least on the action execution event. For example, an administration module in the second VM may trigger the execution of the action at the second VM. In an implementation, the administration module may select a registered handler plugin corresponding to the action, and start the operation of the handler plugin. A triggering strategy may be defined as: directly triggering execution of an action at a VM in response to receiving an action execution event from at least one another VM. As an example, the triggering of execution of the action may comprise invoking or instructing an existing execution module in the second VM, which is responsible of executing the action, to execute the action. In an implementation, an event callback handler in the selected handler plugin may trigger the execution of the action at the second VM, e.g., instructing the execution module to execute the action.

At 310, action status information associated with the second VM may be obtained in response to the execution of the action at the second VM. For example, the administration module in the second VM may obtain the action status information associated with the second VM from the execution module. In an implementation, the event callback handler in the selected handler plugin may obtain the action status information. The action status information may include an execution progress or execution result of the action at the second VM, e.g., not started, in progress, success, failure, etc. The embodiments of the present disclosure are not limited to any specific types of information included in the action status information.

At 312, the action status information associated with the second VM may be recorded into an action status information set. For example, the administration module in the second VM may record the action status information associated with the second VM into the action status information set. In an implementation, the event callback handler in the selected handler plugin may record the action status information associated with the second VM into the action status information set. The action status information set may include the action status information associated with the second VM and action status information associated with other VMs in the VM set.

At 314, an action status changing event may be generated based on the action status information associated with the second VM. The action status changing event may include information about the execution progress or execution result of the action at the second VM. For example, the administration module in the second VM may generate the action status changing event based on the action status information associated with the second VM. In an implementation, an event converter in the selected handler plugin may convert the action status information associated with the second VM into the action status changing event.

At 316, the action status changing event may be propagated in the VM set, such that all other VMs in the VM set may receive the action status changing event and thus obtain the action status information associated with the second VM. For example, the transport module in the second VM may propagate the action status changing event in the VM set.

At 318, at least one action status changing event may be received from at least one VM in the VM set. The received action status changing event may include information about an execution progress or execution result of the action at the at least one VM. For example, the transport module in the second VM may receive the action status changing event from the at least one VM.

At 320, action status information associated with the at least one VM may be extracted from the action status changing event which is received at 318. For example, the administration module in the second VM may extract the action status information associated with the at least one VM from the received action status changing event. In an implementation, the event converter in the selected handler plugin may convert the received action status changing event into the action status information associated with the at least one VM.

At 322, the action status information associated with the at least one VM extracted at 320 may be recorded into the action status information set. For example, the administration module in the second VM may record the extracted action status information associated with the at least one VM into the action status information set. In an implementation, the event callback handler in the selected handler plugin may record the extracted action status information associated with the at least one VM into the action status information set.

It should be understood that the steps 318, 320 and 322 may be performed iteratively, and thus the second VM may obtain action status information of all other VMs in the VM set and record action status information of these VMs into the action status information set.

Optionally, the process 300 may comprise providing the action status information set to the control plane at 324. The action status information set may include action status information associated with all the VMs in the VM set. The action status information set may be then presented to the user. In an implementation, the second VM may proactively provide the action status information set to the control plane. In an implementation, the second VM may provide the action status information set to the control plane in response to a request received from the control plane. For example, the control plane may interact with the second VM to request the action status information set, and the second VM may provide the action status information set to the control plane in response to such a request. It should be understood that although the process 300 shows that the second VM performing the process 300 provides the action status information set to the control plane, the control plane may also obtain an action status information set from any other VM in the VM set.

Moreover, optionally, if the triggering strategy for triggering the execution of the action at the second VM is defined based on a combination of the action execution event received at 302 and the at least one action status changing event received at 318, the triggering of the execution of the action at 308 may be decided according to this triggering strategy. In this case, for example, the triggering strategy may regulate that only when execution progresses or execution results of other VMs meet predetermined criteria, the second VM could trigger the execution of the action at the second VM. Accordingly, the triggering of the execution of the action at 308 needs to further consider the at least one action status changing event received from the at least one another VM.

Moreover, optionally, if the triggering strategy for triggering the execution of the action at the second VM is defined based on a combination of the action execution event received at 302 and metadata of the second VM, or a combination of the action execution event received at 302, the at least one action status changing event received at 318 and metadata of the second VM, the triggering of the execution of the action at 308 may be decided according to this triggering strategy. In this case, for example, the triggering strategy may regulate that at least when information in the metadata of the second VM meets predetermined criteria, e.g., update domain or fault domain of the second VM meets a predetermined requirement, the second VM could trigger the execution of the action at the second VM. Accordingly, the triggering of the execution of the action at 308 needs to further consider the metadata of the second VM.

It should be understood that all the steps and their orders in the process 300 are exemplary, and the embodiments of the present disclosure would cover any changes to the process 300. For example, although the steps in the process 300 in FIG. 3 are connected by arrows for showing exemplary performing orders, any of these steps may be performed in any other orders or concurrently.

Moreover, although the process 200 in FIG. 2 and the process 300 in FIG. 3 are discussed in connection with the first VM and the second VM respectively, both the process 200 and the process 300 may be supported by the same one VM in the VM set such that this VM may perform different processes in different cases, e.g., performing the process 200 when receiving an action execution request from the control plane, while performing the process 300 when receiving an action execution event from at least one another VM.

FIG. 4 illustrates exemplary architecture 400 of VM level decentralized service management for a service update action according to an embodiment. In FIG. 4, it is assumed that the type of service management for a target service is exemplary “service update” , that is, a service update action is desired to execute for the target service.

The architecture 400 is similar with the architecture 100 in FIG. 1, except that an existing execution module responsible of executing a service update action, e.g., a lifecycle controller agent, is shown in each VM. For example, a lifecycle controller agent 422 is shown as included in the VM 120, a lifecycle controller agent 432 is shown as included in the VM 130, and a lifecycle controller agent 442 is shown as included in the VM 140.

According to the architecture 400, the action execution request received by a VM, e.g., the VM 130, from the control plane 102 is a service update request which indicates a service update action associated with the target service. The VM 130 may perform the process 200 in FIG. 2 for implementing the service management corresponding to the service update action. Moreover, the VM 120 and the VM 140 may perform the process 300 in FIG. 3 for implementing the service management corresponding to the service update action. In each VM, the lifecycle controller agent may be invoked or instructed to execute the service update action, e.g., shutting down the corresponding service instance and updating the service instance to a desired version.

It should be understood that FIG. 4 merely shows exemplary architecture of VM level decentralized service management for the exemplary service update action, and the embodiments of the present disclosure may also be applied for implementing any other types of service managements in similar approaches.

FIG. 5 illustrates a flowchart of an exemplary method 500 for implementing VM level decentralized service management at a VM in a cloud service platform according to an embodiment. The VM may be included in a VM set associated with a target service.

At 510, an action execution request for the target service, which indicates an action associated with the target service, may be received from a control plane in the cloud service platform.

At 520, an action execution event may be generated based on the action execution request.

At 530, the action execution event may be propagated in the VM set.

At 540, execution of the action at the VM may be triggered based at least on the action execution event.

In an implementation, the propagating the action execution event may comprise: propagating the action execution event in the VM set through a Gossip protocol.

In an implementation, the method 500 may further comprise: obtaining metadata information of VMs in the VM set. The propagating the action execution event may comprise: propagating the action execution event in the VM set based on the metadata information.

In an implementation, the method 500 may further comprise: obtaining action status information associated with the VM in response to the execution of the action at the VM; and recording the action status information associated with the VM into an action status information set.

The method 500 may further comprise: generating an action status changing event based on the action status information; and propagating the action status changing event in the VM set.

In an implementation, the method 500 may further comprise: receiving an action status changing event from at least one VM in the VM set; extracting action status information associated with the at least one VM from the action status changing event; and recording the action status information associated with the at least one VM into an action status information set.

The triggering execution of the action may comprise: triggering the execution of the action based at least on the action execution event and the action status changing event.

In an implementation, the method 500 may further comprise: providing an action status information set to the control plane, the action status information set including action status information associated with VMs in the VM set.

Moreover, the method 500 may further comprise any steps/operations for implementing VM level decentralized service management at a VM in a cloud service platform according to the above embodiments of the present disclosure.

FIG. 6 illustrates a flowchart of an exemplary method 600 for implementing VM level decentralized service management at a VM in a cloud service platform according to an embodiment. The VM may be included in a VM set associated with a target service.

At 610, an action execution event for the target service, which indicates an action associated with the target service, may be received from a second VM in the VM set.

At 620, the action execution event may be propagated in the VM set.

At 630, execution of the action at the VM may be triggered based at least on the action execution event.

In an implementation, the method 600 may further comprise: obtaining action status information associated with the VM in response to the execution of the action at the VM; and recording the action status information associated with the VM into an action status information list.

The method 600 may further comprise: generating an action status changing event based on the action status information; and propagating the action status changing event in the VM set.

In an implementation, the method 600 may further comprise: receiving an action status changing event from at least one VM in the VM set; extracting action status information associated with the at least one VM from the action status changing event; and recording the action status information associated with the at least one VM into an action status information list.

Moreover, the method 600 may further comprise any steps/operations for implementing VM level decentralized service management at a VM in a cloud service platform according to the above embodiments of the present disclosure.

FIG. 7 illustrates an exemplary apparatus 700 for implementing VM level decentralized service management in a cloud service platform according to an embodiment.

The apparatus 700 may comprise at least one processor 710. The apparatus 700 may further comprise a memory 720 connected to the at least one processor 710. The memory 720 may store computer-executable instructions that, when executed, cause the at least one processor 710 to any operation of the methods for implementing VM level decentralized service management at a VM in a cloud service platform according to the above embodiments of the present disclosure.

The embodiments of the present disclosure propose a VM in a cloud service platform, for implementing virtual-machine level decentralized service management, the VM being included in a VM set associated with a target service. The VM may comprise an administration module, configured for: receiving an action execution request for the target service from a control plane in the cloud service platform, the action execution request indicating an action associated with the target service; generating an action execution event based on the action execution request; and triggering execution of the action at the VM based at least on the action execution event. The VM may comprise a transport module, configured for propagating the action execution event in the VM set.

In an implementation, the VM may further comprise: a membership discovery module, configured for obtaining metadata information of VMs in the VM set. The transport module may be further configured for: propagating the action execution event in the VM set based on the metadata information.

In an implementation, the administration module may be further configured for: obtaining action status information associated with the VM in response to the execution of the action at the VM; and generating an action status changing event based on the action status information. The transport module may be further configured for: propagating the action status changing event in the VM set.

In an implementation, the transport module may be further configured for: receiving an action status changing event from at least one VM in the VM set. The administration module may be further configured for: extracting action status information associated with the at least one VM from the action status changing event; and triggering the execution of the action based at least on the action execution event and the action status changing event.

In an implementation, the administration module may be further configured for: providing an action status information set to the control plane, the action status information set including action status information associated with VMs in the VM set.

Moreover, the modules in the VM may be configured for performing any steps/operations for implementing VM level decentralized service management at a VM in a cloud service platform according to the above embodiments of the present disclosure.

The embodiments of the present disclosure propose a virtual machine in a cloud service platform, for implementing virtual-machine level decentralized service management, the virtual machine being included in a virtual machine set associated with a target service. The virtual machine may comprise a transport module, configured for: receiving an action execution event for the target service from a second virtual machine in the virtual machine set, the action execution event indicating an action associated with the target service; and propagating the action execution event in the virtual machine set. The virtual machine may comprise an administration module, configured for: triggering execution of the action at the virtual machine based at least on the action execution event.

Moreover, the virtual machine may comprise any other modules, and the modules in the virtual machine may be configured for performing any steps/operations for implementing VM level decentralized service management at a virtual machine in a cloud service platform according to the above embodiments of the present disclosure.

The embodiments of the present disclosure propose a computer program product for implementing VM level decentralized service management at a virtual machine in a cloud service platform. The computer program product may comprise a computer program that is executed by at least one processor for performing any operations of the methods for implementing VM level decentralized service management at a virtual machine in a cloud service platform according to the above embodiments of the present disclosure.

The embodiments of the present disclosure may be embodied in a non-transitory computer-readable medium. The non-transitory computer-readable medium may comprise instructions that, when executed, cause one or more processors to perform any operations of the methods for implementing VM level decentralized service management at a virtual machine in a cloud service platform according to the above embodiments of the present disclosure.

It should be appreciated that all the operations in the methods described above are merely exemplary, and the present disclosure is not limited to any operations in the methods or sequence orders of these operations, and should cover all other equivalents under the same or similar concepts.

Moreover, the articles “a” and “an” as used in this specification and the appended claims should generally be construed to mean “one” or “one or more” unless specified otherwise or clear from the context to be directed to a singular form.

It should also be appreciated that all the modules in the apparatuses described above may be implemented in various approaches. These modules may be implemented as hardware, software, or a combination thereof. Moreover, any of these modules may be further functionally divided into sub-modules or combined together.

Processors have been described in connection with various apparatuses and methods. These processors may be implemented using electronic hardware, computer software, or any combination thereof. Whether such processors are implemented as hardware or software will depend upon the particular application and overall design constraints imposed on the system. By way of example, a processor, any portion of a processor, or any combination of processors presented in the present disclosure may be implemented with a microprocessor, microcontroller, digital signal processor (DSP) , a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a state machine, gated logic, discrete hardware circuits, and other suitable processing components configured to perform the various functions described throughout the present disclosure. The functionality of a processor, any portion of a processor, or any combination of processors presented in the present disclosure may be implemented with software being executed by a microprocessor, microcontroller, DSP, or other suitable platform.

Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, threads of execution, procedures, functions, etc. The software may reside on a computer-readable medium. A computer-readable medium may include, by way of example, memory such as a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip) , an optical disk, a smart card, a flash memory device, random access memory (RAM) , read only memory (ROM) , programmable ROM (PROM) , erasable PROM (EPROM) , electrically erasable PROM (EEPROM) , a register, or a removable disk. Although memory is shown separate from the processors in the various aspects presented throughout the present disclosure, the memory may be internal to the processors, e.g., cache or register.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein. All structural and functional equivalents to the elements of the various aspects described throughout the present disclosure that are known or later come to be known to those of ordinary skilled in the art are intended to be encompassed by the claims.

Claims

A method for implementing virtual-machine level decentralized service management at a virtual machine in a cloud service platform, the virtual machine being included in a virtual machine set associated with a target service, the method comprising:

receiving an action execution request for the target service from a control plane in the cloud service platform, the action execution request indicating an action associated with the target service;

generating an action execution event based on the action execution request;

propagating the action execution event in the virtual machine set; and

triggering execution of the action at the virtual machine based at least on the action execution event.
The method of claim 1, wherein the propagating the action execution event comprises:

propagating the action execution event in the virtual machine set through a Gossip protocol.
The method of claim 1, further comprising:

obtaining metadata information of virtual machines in the virtual machine set, and

wherein the propagating the action execution event comprises: propagating the action execution event in the virtual machine set based on the metadata information.
The method of claim 1, further comprising:

obtaining action status information associated with the virtual machine in response to the execution of the action at the virtual machine; and

recording the action status information associated with the virtual machine into an action status information set.
The method of claim 4, further comprising:

generating an action status changing event based on the action status information; and

propagating the action status changing event in the virtual machine set.
The method of claim 1, further comprising:

receiving an action status changing event from at least one virtual machine in the virtual machine set;

extracting action status information associated with the at least one virtual machine from the action status changing event; and

recording the action status information associated with the at least one virtual machine into an action status information set.
The method of claim 6, wherein the triggering execution of the action comprises:

triggering the execution of the action based at least on the action execution event and the action status changing event.
The method of claim 1, further comprising:

providing an action status information set to the control plane, the action status information set including action status information associated with virtual machines in the virtual machine set.
A method for implementing virtual-machine level decentralized service management at a virtual machine in a cloud service platform, the virtual machine being included in a virtual machine set associated with a target service, the method comprising:

receiving an action execution event for the target service from a second virtual machine in the virtual machine set, the action execution event indicating an action associated with the target service;

propagating the action execution event in the virtual machine set; and

triggering execution of the action at the virtual machine based at least on the action execution event.
The method of claim 9, further comprising:

obtaining action status information associated with the virtual machine in response to the execution of the action at the virtual machine; and

recording the action status information associated with the virtual machine into an action status information list.
The method of claim 10, further comprising:

generating an action status changing event based on the action status information; and

propagating the action status changing event in the virtual machine set.
The method of claim 9, further comprising:

receiving an action status changing event from at least one virtual machine in the virtual machine set;

extracting action status information associated with the at least one virtual machine from the action status changing event; and

recording the action status information associated with the at least one virtual machine into an action status information list.
The method of claim 12, wherein the triggering execution of the action comprises:

triggering the execution of the action based at least on the action execution event and the action status changing event.
A virtual machine in a cloud service platform, for implementing virtual-machine level decentralized service management, the virtual machine being included in a virtual machine set associated with a target service, the virtual machine comprising:

an administration module, configured for: receiving an action execution request for the target service from a control plane in the cloud service platform, the action execution request indicating an action associated with the target service; generating an action execution event based on the action execution request; and triggering execution of the action at the virtual machine based at least on the action execution event; and

a transport module, configured for propagating the action execution event in the virtual machine set.
The virtual machine of claim 14, further comprising:

a membership discovery module, configured for obtaining metadata information of virtual machines in the virtual machine set, and

wherein the transport module is further configured for: propagating the action execution event in the virtual machine set based on the metadata information.
The virtual machine of claim 14, wherein

the administration module is further configured for: obtaining action status information associated with the virtual machine in response to the execution of the action at the virtual machine; and generating an action status changing event based on the action status information, and

the transport module is further configured for: propagating the action status changing event in the virtual machine set.
The virtual machine of claim 14, wherein

the transport module is further configured for: receiving an action status changing event from at least one virtual machine in the virtual machine set, and

the administration module is further configured for: extracting action status information associated with the at least one virtual machine from the action status changing event; and triggering the execution of the action based at least on the action execution event and the action status changing event.
The virtual machine of claim 14, wherein the administration module is further configured for:

providing an action status information set to the control plane, the action status information set including action status information associated with virtual machines in the virtual machine set.
A virtual machine in a cloud service platform, for implementing virtual-machine level decentralized service management, the virtual machine being included in a virtual machine set associated with a target service, the virtual machine comprising:

a transport module, configured for: receiving an action execution event for the target service from a second virtual machine in the virtual machine set, the action execution event indicating an action associated with the target service; and propagating the action execution event in the virtual machine set; and

an administration module, configured for: triggering execution of the action at the virtual machine based at least on the action execution event.
An apparatus for implementing virtual-machine level decentralized service management in a cloud service platform, comprising:

at least one processor; and

a memory storing computer-executable instructions that, when executed, cause the at least one processor to perform any operation according to anyone of claims 1-13.