Seeing Murano Actions in action

The Juno release of Murano introduces the new Murano actions feature, which allows you to manage application components after application deployment.  In this blog post we look at the basic concepts of using Murano actions for specific autoscaling and high availabilty (HA) use cases.

What is Murano?

As a quick review before we start digging into the technical details of actions, Murano is an OpenStack project that enables application developers and cloud developers to publish applications in a browsable catalog. With the catalog, users can create complex multi-tier application environments with the push of a button using published applications as building blocks.  

Murano provides a UI that is implemented as a plugin for the OpenStack Dashboard to simplify application management. This plugin provides:

1. The application catalog page, where users can find applications

2. The environments page, where users can manage multi-tier applications

3. The package management page, where users can upload/download Murano application packages

Murano uses Heat templates to provision OpenStack resources. The application author can employ the Murano agent for  software configuration, or if the application author prefers an agentless mode, he or she can employ Heat software configuration resources.

Murano actions

Murano actions are workflows that an application author defines to expose specific operations the application can perform, such as being able to restart, backup, upgrade, and scale up/down. The Murano API server exposes the workflows as Web hooks when you deploy the application.

Now let’s take a look at auto-scaling and HA, which are two common use cases that require orchestration.

Auto-scaling

Auto-scaling is a typical use case for some applications that could be scaled horizontally. The usual example is a cluster of Web applications that can be scaled up/down depending on actual traffic.  The Murano application author can implement application autoscaling in two different ways:

1. The first approach supported by Murano is to use Heat autoscaling resources, which works perfectly if you can scale your application with the addition of simple Heat resources.

2. The second approach is to use Murano actions to expose specific workflows for the application scaling process. As you have full control over the scale up process, you can write complex, sophisticated scaling scenarios such as, “I need 1 additional Database host for every 10 Web Servers, and if I have more than 10 Web Servers switch from the HAProxy LoadBalancer to the F5 hardware load balancer.”

For the Auto-scaling use-case, we usually use the Ceilometer monitoring app, which enables us to create simple alarms based on CPU and memory usage. Figure 1 depicts a Java application as an example. It has three dependencies:

1. A monitoring app

2. The Java Servlet Container app

3. The Database app

The Java application defines the ‘scaleUP’ action workflow. When this action is triggered by the monitoring component via an HTTP call to an action web hook exposed by the API, the workflow adds a new instance to the Tomcat Cluster, deploys Tomcat and the application on it, and then adds it to the load balancer. The underlying Heat stack is then updated by adding the corresponding resources, consisting of the VM, LB Pool Member, and Ceilometer alarm associated with the new VM. This workflow can be changed to provide more logic for scaling other components, such as database scaling or changing the load balancer.

High Availability

HA for applications is not new. IT departments are very familiar with HA and have open source and proprietary methods to tackle it.  The following are the two main HA enablement approaches:

1. Having HA inside the application so that the application itself performs all necessary actions in case of failure. Galera clusters and Tomcat clusters are good examples of HA solutions embedded into the application itself.

OR

2. Having the underlying software and/or hardware infrastructure provide HA. VMWare HA VM is a good example of the underlying infrastructure providing HA on a virtual hardware level. Pacemaker/Corosync is another example of a software-based HA solution for applications that do not support HA directly.

You can use Murano actions to add HA to some applications, defining a workflow to be performed when an initial application host fails or the application does not respond to monitoring probes. OpenStack provides a number of options to successfully perform an HA switchover:

1. If an application does not have any external dependencies, you can use the Nova evacuate command to simply move the VM to a new compute host or spawn a new VM instance and pause the original one.

2. If an application keeps its state and all data on a file system, then your HA strategy will be built around volumes. When the monitoring system detects a failure, it invokes a Murano action by sending an HTTP request to an exposed web hook. Murano starts performing a workflow to pause the original application’s VM, detach the data volume, spawn a new VM with the application, and attach the data volume to the new VM.

3. In more complex scenarios where a component requiring HA is used by other components, the triggered action performs the necessary steps to create a new instance for the failed component and then updates all of the component’s users with the new information.

Figure 2 depicts the Nagios monitoring service, which provides a fast response to the failure and has a lot of different probes that can be used by an application.

Our demo Java application has two different strategies for HA. When deployed on top of a Tomcat Cluster, it just adds a new VM to the cluster if Nagios reports that one of the existing VMs is down. If the Java application is deployed on top of a single Tomcat instance, it tries to restart the Tomcat service first. If the restart is unsuccessful, the Java application spawns a new VM with Tomcat and deploys itself to the new VM.

Next steps

Murano actions also include functions such as backups, application upgrades,  and so on. In future posts, I’ll provide more detailed explanations for functions, including backups and application upgrades, with code snippets and template examples.