http://www.developer.com/

Back to article

Building a Test Platform in the Cloud with Open Source Technologies


October 20, 2010

Cloud computing, which aims to provide easy, scalable access to computing resources and IT services on demand, offers new possibilities for testing. A cloud-based test platform delivers automated scaling -- up or down -- of testing infrastructure, which overcomes many challenges of traditional test environments.

A traditional test environment usually is a scaled-down copy of the production environment. Setting one up requires a lot of time and effort because the setup process includes arduous tasks such as procuring the right hardware infrastructure (including an app server, database server, Web server, etc.) and installing the required software (such as the application, database, testing tools, and monitoring tools if needed).

This tutorial explains how we set up a test platform in the cloud using various open source technologies. You can use it as a guide for setting up your own cloud-based test platform.

The following are the open source technologies we used to set up the test platform one we describe here:

  1. Machines with CentOS 5.2: These will act as the cloud, cluster and node controller.
  2. Eucalyptus 1.5.1: This open source infrastructure is for the implementation of cloud computing on computer clusters.
  3. Apache Tomcat 6.0.14: This is the popular open source Servlet container.
  4. Jakarta JMeter 2.3.2: This open source tool is designed to perform load testing and functional behavior analysis, as well as measure application performance, mainly Web applications.
  5. MySQL 5.0: This is the popular relational database management system that runs as a server, providing multi-user access to a number of databases.
  6. Pre-bundled CentOS 5.2 image: This a base image for Tomcat, JMeter and MySQL image creation.
  7. JPetStore Web application: This sample application is a working demonstration of the J2EE platform in a real application design.

You will need a basic knowledge on the working principles of cloud computing and Eucalyptus.

The Cloud Test Environment Components

The lab environment we used is composed of four machines; one was a 2GB RAM machine and the others were 1GB RAM machines (see Figure 1). Each machine had CentOS5.2 installed. Eucalyptus cloud and cluster RPMs were installed in the 2GB machine, which acted as the cloud as well as the cluster controller. The remaining three machines, which acted as node controllers, had only node RPMs. One of them, a Linux machine with JMeter installed, will be the JMeter master machine. (For Eucalyptus installation instructions, refer to the Eucalyptus Administrator Guide.)

Cloud Test Environment Setup
Figure 1. Cloud Test Environment Setup:
The lab environment is composed of four machines.

The following are the images we used in our cloud setup:

  1. A Tomcat image: For application deployment
  2. A MySQL image: For database-related stuff
  3. A JMeter image: For testing and monitoring

Creating the Images for the Cloud Test Environment

In this section, we examine the various steps involved in creating each of the three previously listed images, providing the necessary startup scripts in detail. You can create the images in any of the CentOS 5.2 machines. Before we can begin, we need a pre-bundled CentOS 5.2 image. Refer to this OTN article for image creation details.

Creating the Tomcat Image

The pre-bundled CentOS image has to be mounted into a local directory. The first step is to create a directory where you can mount the image. Open a command prompt and execute the following commands.

# Make directorymkdir /mnt/Mount

Now mount the pre-bundled CentOS 5.2 image to the created folder.

#Mount Imagemount -o loop /mnt/Mount#Mount the Procmount -t proc none /mnt/Mount/proc/

Install Tomcat in the mount folder (i.e. place a Tomcat folder inside /mnt/Mount/home). To ensure that Tomcat starts automatically during instance bootup, follow these steps:

  1. Include JAVA_HOME and PATH variables in the /etc/rc.local file (/mnt/Mount/etc/rc.local).
  2. Add the startup script of Tomcat in the /etc/rc.local file as well.

The rc.local file should be as follows.

#!/bin/sh# This script will be executed *after* all the other init scripts.touch /var/lock/subsys/localexport JAVA_HOME=/home/jdk1.6.0_13export PATH=/home/jdk1.6.0_13/bin:$PATH:$HOME/bin/home/apache-Tomcat-6.0.18/bin/startup.sh

The Web application we used for testing is JPetStore. Put jpetstore.war inside the /webapps/ folder. Now the image contains all the necessary software and scripts.

The next step is to unmount the image. Go to the command prompt and execute the following commands.

#Un-Mount procumount /mnt/Mount/proc# Un-Mount Imageumount -d /mnt/Mount

The image that you obtain contains Tomcat 6 and the Web application. This image is now ready to be uploaded into the cloud. For instructions on uploading and running the image, refer to the Eucalyptus Image Management documentation.

Creating the JMeter Image

To create the JMeter image, follow the same steps as those for creating the Tomcat image in the previous section. Mount a CentOS 5.2 pre-bundled image to a specific folder:

#Mount Imagemount -o loop /mnt/Mount#Mount the Procmount -t proc none /mnt/Mount/proc/

Move JMeter 2.3.2 files inside the /mnt/Mount/home folder.

The JMeter master is set up in a physical Linux machine and the JMeter instance acts as slave. First, add the master to the slave machine's list of "known hosts" (refer to Setting up passwordless, passphraseless ssh for details), and then generate a passphrase-less key for the master machine and add it to the slave image. Keep the id_dsa generated on the master machine in the specified folder of the slave image (e.g. /mnt/Mount/home). Hence, each time the slave instance boots up, it will have the master's IP in the list of known hosts.

When the JMeter slave instance boots up, its IP address needs to be updated in the master machine's jmeter.properties file. To add the IP address automatically, we used a shell script. Create a script file within the mount folder (/mnt/Mount/home).

#---------- Find Ip-address of slave -----OS=`uname`IP="" # store IPJMETER_Prop_File=""Master=""KeyPath="/id_dsa" # Master's Passphrase less key.case $OS inLinux) IP=`ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'`;;FreeBSD|OpenBSD) IP=`ifconfig | grep -E 'inet.[0-9]' | grep -v '127.0.0.1' | awk '{ print $2}'` ;;SunOS) IP=`ifconfig -a | grep inet | grep -v '127.0.0.1' | awk '{ print $2} '` ;;*) IP="Unknown";;esac#---------------- writes slaves Ip in master's properties file-----ssh -i $KeyPath root@$Master "sed -e 's/remote_hosts=/remote_hosts=$IP,/1' $JMETER_Prop_File/jmeter.properties>$JMETER_Prop_File/test.chk"ssh -i $KeyPath root@$Master "cp $JMETER_Prop_File/test.chk $JMETER_Prop_File/jmeter.properties"ssh -i $KeyPath root@$Master "rm -rf $JMETER_Prop_File/test.chk"

Save the above file with a .sh extension. Add the path of services that need to start up automatically during the instance bootup in the rc.local file (Refer back to the "Creating the Tomcat Image" section).

#!/bin/sh# this script will be executed *after* all the other init scripts.touch /var/lock/subsys/localchmod 600 //id_dsa/ export JAVA_HOME=//javaexport PATH=//java/bin:$PATH:$HOME/bin//jmeter2.3.2/bin/jmeter-serverservice vsftpd start

Unmount the image as explained in the "Creating the Tomcat Image" section.

Creating the MySQL Image

The steps for creating the MySQL image are same as those for creating the Tomcat image.

Mount a CentOS 5.2 pre-bundled image to a specific folder.

#Mount Imagemount -o loop /mnt/Mount#Mount the Procmount -t proc none /mnt/Mount/proc/

Change the root to mount-point (i.e. /mnt/Mount) and execute the following commands in the command prompt.

cd /mnt/Mount

chroot .

When this is done, the command prompt shows the following to indicate that the root is changed to mount point.

bash-3.2#

Now install all the RPMs required for MySQL, including its dependencies. When all the RPMs are installed, exit from the root.

bash-3.2#exit

exit

[root@localhost centos]#

To learn how to enable remote access to MySQL databases, refer to the tutorial How to Enable Remote Access To MySQL Database.

/etc/init.d/mysqld start

To ensure that MySQL starts automatically during instance bootup, add the startup script in etc/rc.local inside the mount folder.

To configure JPetStore to use the new MySQL instance, begin with this command:

driver=org.gjt.mm.mysql.Driverurl=jdbc:mysql://:3306/JPETSTOREusername=password=

When the instances are up and running, you can change JPetStore application's default database to MySQL, as per our requirements. For that, update the database.properties file of JPetStore in the Tomcat image. To learn how to upload and run the images, refer to the Eucalyptus Image Management documentation.

Start all instances and make sure that an IP is obtained for each instance. You can execute performance testing on these cloud instances in a similar fashion to that of performance tests on physical machines.

Conclusion

Moving a test environment to the cloud has a lot of potential benefits over a physical test environment. We performed many rounds of testing on a physical test environment as well as on a cloud test environment. Both the physical test machines and cloud test instances had the same configuration. Based on the test results, the cloud-based solution reduced the amount of effort and time required to set up a test environment considerably, while the difference in performance metrics was negligible.

About the Authors

Rini Susan specializes in J2EE, client/server architecture, and performance engineering. At Infosys SETLabs, she was a member of a team that built a private enterprise cloud.

Vikas Valikan is a member of the Performance Engineering and Cloud Computing team at Infosys SETLabs. He specializes in .NET, J2EE and performance lifecycle analysis. He also was a member of the team that built a private enterprise cloud with open source technologies.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date