Enable application-centric cloud management

Three steps to automate application and workload deployment and management

Managing complex applications and workloads in the cloud requires timely infrastructure reconfiguration automation. Application-centric management — in which your management efforts are focused on controlling all required resources as a unified system and the parameters for all runtime services as a single system definition — can provide an alternative, but equally effective, way to keep the performance level of your cloud at its best. This article presents a definition of application-centric-style management, the three key steps to achieving it, and demonstrates how to automate the deployment of a two-tier J2EE application in the IBM® Cloud. You get to practice action creation, hooking actions to events, and event handling.

Share:

Joydeep Biswas, Senior Software Developer, Kaavo

Joydeep Biswas is a senior software developer at Kaavo and works on the IMOD product. He has over five years of experience in developing Enterprise Java applications. Joydeep has a BEng and an MEng in Computer Science and Engineering from Jadavpur University, one of the top ten universities in India. At Jadavpur University, Joydeep received a gold medal for graduating top of his class.



13 October 2010

Also available in Chinese Russian Japanese Portuguese

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Cloud Computing: Introduction to Software as a Service

Deployments are becoming more complex with increasing needs for computing resources. Managing these complex applications and workloads in the cloud without some level of timely infrastructure configuration automation can be almost impossible for the busy IT department. Not to mention that cloud providers need the ability to handle production exceptions, manage application and workload service levels and resources, and schedule activities without human intervention.

Infrastructure service providers promise cost savings through cloud deployment. To achieve this, supplementary life cycle management tools are needed to properly manage applications to achieve efficiencies. End users need to be able to configure firewalls, deploy and configure software automatically on the cloud infrastructure to run and manage their applications and workloads. Application-centric management— a top-down approach for cloud computing that means managing the services, software, infrastructure, middleware, network, and storage required for running the applications and workloads in the cloud from the application owner's perspective — enables the user to manage all the required resources as a unified system for a given application.

In this article application-centric management is described and you see how to automate the deployment and management of any application or workload in public, private, and hybrid clouds through application-centric management. As an example, a use-case is offered that deploys a two-tier J2EE application with a load balancer and J2EE servers, along with automation for auto-scaling, auto-recovery, etc., for managing runtime service levels. Our example is deployed on the IBM Smart Business Development and Test Cloud and the process can be applied to any cloud environment; the example uses IMOD (see sidebar). IMOD is a framework based on patent-pending technology devised by Kaavo that automates the deployment and runtime management of any complex multi-server, multi-tier application or workloads.

Application centricity is a universal approach

In an application-centric cloud environment, you are managing systems for specific applications rather than managing servers and routers. All required resources for a given application are managed as a unified system; all the information for deploying and managing runtime services levels for the resources required by a given application are captured in a single system definition. This is referred to as a top-down approach.

In contrast, in an infrastructure-centric or bottom-up approach, resources (servers, storage, and network resources) are managed individually.

Application-centric management gives application owners more flexibility, control, visibility, automation, and security for the infrastructure resources used by their applications.

Although a specific Java™ application is used via the IMOD software to illustrate an application-centric cloud management approach, the concepts and techniques can be applied to other applications and systems. For example:

  • The system definition file (used to define the multi-tier application) is an XML file.
  • The code examples provided in this article are in XML and shell scripts.
  • Graphical wizards exist to auto-generate the XML without users having to write it.
  • The component concepts defined in the system definition file for this article — action, event, tier, etc. — are all generic parts of a multi-tier web application, in this case a J2EE application.
  • The IMOD software itself is designed to interface with any cloud platform and is currently integrated with five different clouds.

Three keys to establishing application-centric management in IMOD

There are three key steps to build an application-centric management system in the cloud:

  1. Define the application. This includes:
    • Defining the system structure.
    • Configuring server groups.
    • Defining actions.
    • Defining hooks for standard events.
    • Defining custom events.
  2. Set up Autopilot.
  3. Start/deploy the system.

Later in this article, you'll see how to use this approach to automate the deployment of a two-tier J2EE application in the IBM Cloud.


About the scripting language

The code examples in this article are standard command-line scripts; basically commands that a system admin will use when manually performing the steps in the examples. Proprietary scripts or programming languages are not used.

The scripts are a sequence of commands for the target servers. They can be shell scripts, Perl scripts, Python scripts, etc. When the scripts need information available only at runtime, use Apache Velocity templates to dynamically generate those scripts.

The body for the install-jdk action is a shell script comprising invocations of standard Linux commands such as wget, tar, etc., as shown in the following code; any other scripting language can be used.

Sample shell script
/usr/bin/wget -O /opt/jdk1.6.tar.gz http://SOURCE.com/jdk1.6.0_16.tar.gz
cd /opt/
 tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

Configuration files are handled in a similar way. The action configure-apache-balancer has a body as shown in this code:

Configuration file sample
<Proxy balancer://mycluster>
                    #foreach ($node in $AppNodes)
                    BalancerMember http://$node.publicIP:8080
                   #end
        </Proxy>
           ProxyPass /app balancer://mycluster
        <Location /balancer-manager>
                     SetHandler balancer-manager
                     Order Deny,Allow
                     Allow from all
         </Location>

When this template is rendered, it generates a configuration file for apache mod_proxy. XML-based system definition files is not used for describing application, but it is used mostly for internal representation.

A number of GUI wizards exist for auto-generating system definition files. The following XML fragment is generated by the wizard.

XML fragment generated by the wizard
          <serverType role="ndbd" min="1" max="6"> 
           <ibmServer> 
            <name>AppNode</name>  
            <ibmAccount>xxxx</ibmAccount>  
            <keypair>yyyy</keypair>  
            <imageIdentifier>20001150</imageIdentifier>  
            <instanceType>BRZ32.1/2048/175</instanceType>  
            <location>41</location>  
            ..........//Event and other information              
            <startupCount>2</startupCount>  
          </ibmServer> 
         </serverType>

Example: Defining the application

The first step towards an application-centric management approach to managing applications is defining the application, so let's define the components for IMOD and what each does.

Kaavo's IMOD

Kaavo's IMOD uses patent-pending technology to deliver application-centric management of virtual resources in the clouds. IMOD provides an easy-to-use web interface for deploying, running, and managing complex multi-server, n-tier applications in public, private, and hybrid clouds. For more information, see Kaavo products and technology.

In IMOD, a complete multi-tier application (or a system) is defined using an XML file called the System Definition file (see the N-Tier Guide System Definition wiki in Resources for more information). After the system is defined, a single click deploys the entire application.

The system definition file has two components: deployment time and runtime:

  • The deployment component carries all the information about provisioning resources and deploys and configures the middleware and application components to bring the application online.
  • The runtime component has the workflows to be executed in response to defined events to make sure application service levels are met during runtime automatically without human intervention.

Once the system is deployed, you have "autopilot" functionality that will let you streamline and automate production support for your application.

Some of the other IMOD building blocks include

  • Server
  • Server type, server group
  • Tier
  • NTier
  • Action: Executable and non-executable actions
  • Events: Standard and custom events

Let's look at each in detail.

Server

A server directly represents a virtual server or instance in the cloud. A server is specified by a number of parameters — cloud service accounts to use for provisioning the instance ibmAccount), images to create the instance from (imageIdentifier), types of the instance (instanceType), and more. Listing 1 shows how to specify an instance in the IBM Cloud using XML.

Listing 1. Specify an instance in the IBM Cloud using XML
<ibmServer> 
  <name>AppNode</name>  
  <ibmAccount>xxxx</ibmAccount>  
  <keypair>yyyy</keypair>  
  <imageIdentifier>20001150</imageIdentifier>  
  <instanceType>BRZ32.1/2048/175</instanceType>  
  <location>41</location>  

  ..........//Event and other information    
  <startupCount>2</startupCount>  
</ibmServer>

Server type, server group

In IMOD, servers are organized into groups. A group can have any size within a specified range; the size of the group depends upon the scale of the deployment.

Every group starts with an initial size and it may vary at runtime depending upon the runtime load and the autopilot setup. All members of the group are created equal, but configuration of different servers within a group may slightly differ.

Example of server groups are groups of ndbd nodes in a mysql cluster, groups of manager nodes in a mysql cluster, groups of jboss nodes in a jboss cluster, and so forth.

Listing 2 shows an XML fragment that describes a server type. The role uniquely identifies a server type. Attributes min and max represent maximum and minimum group size. The tag startupCount represents the initial group size.

Listing 2. XML fragment describing server type
<serverType role="ndbd" min="1" max="6"> 
          <ibmServer> 
            <name>AppNode</name>  
            <ibmAccount>xxxx</ibmAccount>  
            <keypair>yyyy</keypair>  
            <imageIdentifier>20001150</imageIdentifier>  
            <instanceType>BRZ32.1/2048/175</instanceType>  
            <location>41</location>  
            ..........//Event and other information              
            <startupCount>2</startupCount>  
          </ibmServer> 
</serverType>

N-tier architecture

Multi-tier or n-tier architecture is a client-server architecture in which presentation, application processing, and data management are logically separate processes. N-tier architecture's main benefit is that it allows developers to build applications that are more flexible and reusable since you only have to modify the target tier when making changes or upgrades. A good example of an n-tier application is one that uses middleware to service data requests between users and a database. Three-tier architecture is the most used.

Tier

Tier directly represents a tier in a multi-tier application. A tier is composed of a number of server groups. For example, a mysql-cluster-based database tier would be comprised of two server groups, an ndbd group and a manager group. When a multi-tier application is deployed, its tiers are deployed in sequence following the specified start-up order for the tiers. Listing 3 shows XML fragment for a database tier with two server groups.

<tier displayindex="3">
      <name>db_tier</name>  
      .....//Event and other information 
      <serverTypes>
        
	   <serverType role="manager" min="1" max="1">
          <ibmServer>
            ....
          </ibmServer>
        </serverType>  

        <serverType role="ndbd" min="2" max="2">
          <ibmServer>
            ...
          </ibmServer>
        </serverType>

      </serverTypes>
</tier>

NTier

This represents the multi-tier application and it comprises of a number of tiers. Listing 4 shows the XML fragment for an ntier.

Listing 4. XML fragment for an ntier
<ntier>
    .../Event and other information
    <tier displayindex="1">
     ...
    </tier>
    
    <tier displayindex="2">
     ...
    </tier>

    <tier displayindex="3">
     ...
    </tier>

</ntier>

Action

Actions are like reusable procedures. They are used for generating executable scripts and configuration files from velocity templates and copying them to target servers and optionally executing them (in case of executable scripts). There are two types of actions:

  • Executable
  • Non-executable

Executable actions
Executable actions generate an executable script and copy the script to a specified location on the specified set of servers. Listing 5 is an example of an executable action.

Listing 5. An executable action
<action name="start-apache" execute="true" 
 target="[tier=web_tier][serverrole=default]">
       <scriptName>apache.sh</scriptName>
       <scriptPath>/root</scriptPath>
       <scriptTemplate type="inline">
       <![CDATA[
               /etc/init.d/httpd start
               ]]>
       </scriptTemplate>

</action>
  • The execute attribute specifies whether the action is executable or not. In this example, execute="true" specifies that the action is an executable one.
  • The target attribute represents the set of servers on which the script will be executed. The expression [tier=web_tier][serverrole=default] returns the set of servers in the named tier(web_tier) and with the named server type(default).
  • The element scriptPath specifies the directory where the generated script will be copied to; scriptName specifies the file name the script will be saved as.
  • The scriptTemplate element contains the body of the action. The body of an action is a Velocity template (Velocity is a Java-based template engine that permits web designers to reference methods defined in Java code). But in this trivial example, it is a static text.

Actions can be invoked inside event-handlers using the following syntax:

<command type="action" name="action-name" />

It is easy to see that when this action, or any other executable action for that matter, is executed the following three steps are executed for each target server:

  1. The Velocity template is rendered using the Velocity template engine. In this example, the template is static text, so the generated content is the same as the template (for example, /etc/init.d/httpd start).
  2. A file with the generated content is created in the path /root/apache.sh in the target server.
  3. The script /root/apache.sh is executed on the target server.

Figure 1 demonstrates how the execution of actions is logged centrally for audit and debugging.

Figure 1. Sample log of actions
Sample log of actions

Listing 6 shows another example with a non-trivial Velocity template.

Listing 6. Another non-trivial Velocity template example
      <scriptName>GrantPhpDbAccess.sh</scriptName>  
      <scriptPath>/root</scriptPath>  
      <scriptTemplate type="inline">
         
        <![CDATA[
#!/bin/sh
#foreach ($clientNode in $SqlClientNodes)
mysql -uroot -p${mysqladminpassword} -e "GRANT ALL PRIVILEGES ON ${appdb}.*
   TO '${appdbuser}'@'${clientNode.publicIP}' IDENTIFIED BY '${appdbpassword}'"
#end	  
        ]]> 
      </scriptTemplate>  
      <parameters> 
        <parameter name="mysqladminpassword" type="literal" value="kaavo"/>  
        <parameter name="appdb" type="literal" value="php_collab"/>  
        <parameter name="appdbuser" type="literal" value="phpcollab"/>  
        <parameter name="appdbpassword" type="literal" value="admin"/>  
        <parameter name="SqlClientNodes" type="serverref" 
         value="[tier=app_tier][serverrole=default]"/> 
      </parameters>      
 </action>

The action body now contains dynamic content. This action accepts five parameters: mysqladminpassword, appdb, and so on. They have default values specified using the value attribute.

The first four parameters (type="literal") are initialized to strings specified using the value attribute. The last one (SqlClientNodes) is initialized to a collection of server objects returned by the expression [tier=app_tier][serverrole=default]. When this action is executed in the previous step 1 ("The Velocity template is rendered using the Velocity template engine"), references to these parameters are resolved while rendering the template.

Each server object has a number of properties (for example, publicIP) that can be accessed in the template. The foreach loop iterates over the $SqlClientNodes collection with the $clientNode as the loop variable. In each iteration of the loop, ${clientNode.publicIP} fetches the public IP of the server object. This action generates the following script:

Listing 7. Each loop iteration fetches the public IP of the server object
#!/bin/sh
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP1' IDENTIFIED BY 'admin'
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP2' IDENTIFIED BY 'admin'
...
...
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIPn' IDENTIFIED BY 'admin'

where publicIP1, publicIP2, ..., publicIPn represent the public IPs of the all the servers in the SqlClientNodes collection (or in other words, the public IPs of all the servers in the tier, app_tier, and server type=default.)

The parameters just defined are user-defined parameters. In addition to these, there are three implicit parameters that can be referred to in the template:

  • CurrentTarget (the node on which the script is being created).
  • AllTargets (set of all nodes that are targets of the action).
  • OtherTargets (set of all nodes except the CurrentTarget).

(The N-Tier Guide in Resources can provide a comprehensive list of server object properties and implicit parameters.)

Actions can be added to a system and also edited in any phase of the system's life cycle using a wizard (Figure 2).

Figure 2. Adding an action using a wizard
Adding an action using a wizard

Non-executable actions
Non-executable actions are similar to the executable actions; the only difference is that these actions generate non-executable files in the previous steps 1 and 2. And step 3 doesn't exist for these types of actions because for these actions, the attribute execute is set to false.

Events

An NTier, a Tier, a Server Group, or each of the individual servers in a group are controlled by sending events to them. An event has a specified target. Events can be fired in different ways:

  • Manually: Users may fire events by using the user interface.
  • By the event scheduler.
  • By making a web service call (which allows users to programmatically interact with IMOD via SOAP using a document/literal wrapped style).
  • By setting up a trigger in the monitoring system (see the N-Tier Guide).

There are two kinds of events: Standard and custom events.

Standard events
Standard events are predefined events. These events are defined whenever a system is defined in IMOD.

There are two kinds of standard events: Start and Stop. All of NTier, Tier, and Server (Group) can be a target of these events, so for each of them you will have a start event and a stop event. For example, start ntier, start tier1, start tier2, start server1, start server2, stop tier1, etc.

Every event has a handler which is a block of code that is executed in response to the occurrence of the event. For standard events, event handlers are predefined. Nevertheless, the default behavior of these event handlers can be customized by implementing predefined hooks for them. The start events have post-startup hooks; the stop events have pre-shutdown hooks. Listing 8 demonstrates the structure of these event-handlers.

Listing 8. The structure of event-handlers in pseudocode
Proc Start-server-handler
  Begin
       Execute start-server-default-logic
       Execute post-startup hook
  END

Proc Stop-server-handler
  Begin
       Execute pre-shutdown hook
       Execute stop-server-default-logic       
  END

The default logic for start server (referred to as start-server-default-logic in Listing 8) is to provision a server in the back-end cloud. The default logic for stop server is to de-provision the server. The post-startup and pre-shutdown hooks are blank by default.

Custom events
In addition to the standard events that are available by default, users can define their own events. Listing 9 is an example of a custom event.

Listing 9. A user-defined, custom event
<event name="system-scaleup" description="App system scaleup" type="custom"> 
      <handler timeout="6000"> 
        <pre-process> 
          	<startServers> 
            	       <serverType role="[tier=app_tier][serverrole=default]" count="1" 
                          addToEvent="true"/> 
          	</startServers> 
        </pre-process>  
        <process> 
         	 <command type="action" name="start-app" 
              target="[tier=app_tier][serverrole=default][scaleupserver]"/>  
          <command type="action" name="configure-apache-balancer"/>  
          <command type="action" name="reset-apache"/>        
        </process> 
     </handler> 
 </event>

An event is identified by a name and the handler of the event and is defined along with the event. So if the event in Listing 9 is defined in a system whenever an event with the name system-scaleup happens, the specified handler is executed.

The event handler starts a new server and configures it by executing a sequence of commands on it. This type of event handler may be used for scaling up an existing system by more instances.

Similarly, events can be defined for recovering a dead server (Listing 10).

Listing 10. Events defined for recovering dead servers
<event name="server-recovery" description="App server recovery" type="custom"> 
      <handler timeout="6000"> 
        <pre-process> 
          <recoverServers> 
            		<server server-to-recover="[context=event][param=instanceid]"/> 
          </recoverServers> 
        </pre-process>  
        <process> 
         	 <command type="action" name="start-app" 
              target="[tier=app_tier][serverrole=default][recoveringserver]"/>  
          	<command type="action" name="configure-apache-balancer"/>  
          	<command type="action" name="reset-apache"/> 
        </process> 
      </handler> 
 </event>

Such elements as startServers, recoverServers, and stopServers are available only in the event handler of custom events.

Again, see the N-Tier Guide in Resources for a more detailed description on custom events.


Example: Designing the system

A single server running the application would have sufficed for this demonstration, but to illustrate certain features it is designed as multiple load-balanced servers running the application (which we'll refer to with the name of app). The system is designed as a two-tier system with an app tier running the J2EE application and a load-balancer tier. Figure 3 illustrates the architecture of the deployment in the simplest possible way.

Figure 3. The architecture of the two-tier deployment
The architecture of the two-tier deployment

The rationale for using two separate tiers is that IMOD's N-Tier engine allows us to define deployment order among tiers. The load balancer configuration file refers to the IP addresses of the application servers, therefore the load balancer cannot be configured before application servers are up and running and have been assigned their IP addresses.

This architecture has to be mapped into an IMOD N-Tier system. The key required elements in a nutshell are:

  1. Two tiers.
  2. Two server groups.
  3. A number of actions (installing, configuring, starting, and restarting).
  4. Hooks for standard events.
  5. A number of custom events (scaling up and down and recovering a dead server).
  6. Trigger conditions and parameters for custom events.

Let's look at each in a little more detail.

1. Two tiers

Let's call the two tiers app-tier (the application tier) and lb-tier (the load balancer tier). App-tier contains one server group (app-group) and lb-tier contains one server group (lb-group).

2. Two server groups

The two server groups, app-group and lb-group, introduced in the last section, will be realized by different sets of servers. app-group is realized by the IBM SUSE Linux Enterprise Server 11 (x86) base image; lb-group is realized by the Red Hat Enterprise Linux 5.4 (32-bit) base image.

3. A number of actions

The actions that are required deal with installation, configuration, starting and restarting on servers, and opening ports.

Performing Apache installation on lb-group servers
Let's call this install-apache. This is a static script and already serves as the required Velocity template. It's done like the following code.

Action-type: executable 
Script to be executed:

wget http://3rdparty-tools.s3.amazonaws.com/apache/httpd-2.2.14.tar.gz
 tar -xzvf  httpd-2.2.14.tar.gz
 cd httpd-2.2.14
 export CFLAGS=-O2
 ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
  --enable-proxy_balancer=shared --enable-proxy_http=shared --enable-rewrite=shared
  --enable-proxy=shared
 make
 make install
 echo "Include conf/extra/httpd-IMOD.conf" >> /usr/local/apache2/conf/httpd.conf

Configuring Apache load balancer on lb-group servers
Call this one, configure-apache-balancer.

Action-type: non-executable
Config file to be copied:
<Proxy balancer://mycluster>
                    	
        BalancerMember http://publicIP1:8080
        BalancerMember http://publicIP2:8080
        ....
        ....
        BalancerMember http://publicIPn:8080
                   	
</Proxy>
ProxyPass /app balancer://mycluster
<Location /balancer-manager>
        SetHandler balancer-manager
        Order Deny,Allow
        Allow from all
</Location>

In this, publicIP1, publicIP2, ...., and publicIPn are public IPs of load-balanced servers; in other words, the app-group servers in the app-tier.

Evidently, you will need a parameterized dynamic action here to generate BalancerMember lines which depend upon publicIPs of all the [tier=app-tier][serverrole=app-group] servers. This information is not known until those servers are up and running.

The required Velocity template for this action is shown here:

<Proxy balancer://mycluster>
       #foreach ($node in $appNodes)
       BalancerMember http://$node.publicIP:8080
       #end
</Proxy>
  ProxyPass /app balancer://mycluster
<Location /balancer-manager>
       SetHandler balancer-manager
       Order Deny,Allow
       Allow from all
</Location>

Here the BalancerMember lines are generated by a foreach loop that iterates over the collection of required servers ( $appNodes). This collection has to be passed as a parameter.

Starting Apache on lb-group servers and opening ports
Let's call this start-apache. This is a static script.

Action-type: executable
Script to be executed:

cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start
sed -i 's/COMMIT/-A INPUT -p tcp -m tcp --dport 80 
  -j ACCEPT\n-A INPUT -p tcp -m
    tcp --dport 10050 -j ACCEPT\nCOMMIT/g' /etc/sysconfig/iptables
/etc/init.d/iptables restart

Installing and starting the application on app-group servers and opening ports
This one is called start-app. The detailed information — name of software tar file, URL destination of tar file, etc. — will vary according to the J2EE application you're using.

Action-type: executable
Script to be executed:

/usr/bin/wget -O /opt/ APP .tar.gz 
http:// SOURCE .com/ APP .tar.gz
cd /opt
tar -xzvf  APP .tar.gz
ln  -s /opt/ APP  /usr/local/ APP 
export JAVA_HOME=/usr/local/java;
/usr/local/ APP /bin/startup.sh
sed -i 's/^.*FW_SERVICES_EXT_TCP=".*".*$/FW_SERVICES_EXT_TCP="8080 10050"/g'
 /etc/sysconfig/SuSEfirewall2
/etc/init.d/SuSEfirewall2_setup reload

Installing the Java Development Kit
Or install-jdk.

Action-type: executable
Script to be executed:

/usr/bin/wget -O /opt/jdk1.6.tar.gz 
 http:// SOURCE .com/jdk1.6.0_16.tar.gz
cd /opt/
tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

Restarting Apache for after changing load-balancer configuration file
Called restart-apache.

Action-type: executable
Script to be executed:
               
/usr/local/apache2/bin/apachectl stop
sleep 5
rm -rf /usr/local/apache2/conf/extra/httpd-IMOD.conf
cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start

4. Hooks for standard events

These hooks mostly deal with start events.

Post-startup hook for start event for lb-group servers
For sequential invocation of the named actions:

{install-apache->configure-apache-balancer->start-apache}

Post-startup hook for start event for app-group servers

{install-jdk}

Post-startup hook for start event for app-tier

{start-app}

5. A number of custom events

The custom events we'll require will be for:

  • Scaling up app-group (app-group-scaleup; Listing 9).
  • Recovering a dead server in the app-group (app-group-recovery; Listing 10).
  • Scaling down app-group (app-group-scaledown).

6. Trigger conditions and parameters for custom events

And you need to decide the trigger conditions and parameters for each of the custom events in the previous section:

  • The metric to measure (for example, CPU Utilization:User).
  • The server group(s) on which to measure that metric.
  • The condition for the trigger: >, <, =, != threshold.
  • The trigger type: Aggregate or non-aggregate.
  • The threshold value (N).
  • The time period (T).

Example: Implementing the system

Once the design phase is completed, it's time to transform the design on paper into an n-tier system. With IMOD, this is done using different graphical wizards; a "hands-on," manual implementation is beyond the scope of this article.

The design phase described in this article gives you the actions to start-app, install-apache, configure-apache-balancer, and so on. In the implementation phase of Kaavo IMOD, all you would have to do is input these actions to graphical wizards.


In conclusion

No matter how much effort is put into simplifying them, cloud environments will always be comprised of complex applications to manage and an array of workloads to balance. The ability to automatically reconfigure the infrastructure in a timely manner is one key to making cloud management, well, manageable.

A critical component to auto-reconfiguration on the fly is application-centric management — bringing the control of required resources and parameters for runtime services into a single system definition can deliver an effective way to manage cloud system performance.

In this article application-centric management was introduced along with an explanation of its benefits. The three steps to reach it was covered:

  1. How to define the application (which includes defining the system structure, configuring server groups, and defining actions, hooks for standard events, and custom events).
  2. How to set up the autopilot.
  3. How to start and deploy the system.

You saw a bit of XML code to automate the deployment of a two-tier J2EE application in the IBM Cloud; the code details action creation, hooking actions to events, and event handling. These code examples come from a real-world experience in developing and deploying Kaavo IMOD.

I hope you'll apply these techniques (or the concepts they represent) to ease deployment and management of applications and services to the cloud in your next project.

Resources

Learn

Get products and technologies

  • You can download Apache Velocity, the Java-based template engine that permits web page designers to reference methods defined in Java code.
  • With IBM trial software, available for download directly from developerWorks, build your next development project.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, Java technology
ArticleID=550735
ArticleTitle=Enable application-centric cloud management
publish-date=10132010