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

All information submitted is secure.

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.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Application environment migration with WebSphere CloudBurst

Preserving the fidelity of application environments through patterns

Dustin Amrhein, Technical Evangelist, IBM

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, Dustin worked on the development of Web services infrastructure and Web services programming models. In addition, Dustin lead the technical effort in the development of a Java RESTful services framework. In his current role, Dustin is a technical evangelist for emerging technologies in IBM’s WebSphere portfolio. His current focus is on WebSphere technologies that deliver cloud computing capabilities, including the WebSphere CloudBurst Appliance.

Ruth Willenborg, Senior Technical Staff Member, IBM

Ruth Willenborg is a Senior Technical Staff Member in IBM's WebSphere Technology Institute where she is currently working on WebSphere cloud computing and virtual appliance initiatives and is the technical evangelist for the new IBM WebSphere CloudBurst Appliance. Prior to her work on virtualization and appliance initiatives, she was the manager of the WebSphere Performance team responsible for WebSphere Application Server performance analysis, performance benchmarkingm and performance tool development. Ruth has more than 20 years of experience in software development at IBM and is co-author of Performance Analysis for Java Web Sites (Addison-Wesley, 2002) and numerous articles on both WebSphere performance and using WebSphere with virtualization technologies.

Summary: In this tutorial, the authors demonstrate how to use WebSphere® CloudBurst to build patterns you can use to represent the configuration of both your application and application infrastructure. They also show you how to use these patterns to consistently deploy the application environment as it moves through the four life-cycle stages — development, test, QA, and production. The tutorial offers a complete, step-by-step example of using patterns to handle changing topologies, underlying platform architectures, and configuration properties.

Date: 01 Jun 2010
Level: Intermediate
PDF: A4 and Letter (908 KB | 36 pages)Get Adobe® Reader®

Activity: 20289 views
Comments:

Moving on to quality assurance

The Account Management application will not remain in the test environment forever. Its ultimate home is running live in production so that it is available to the larger enterprise, but you cannot just jump from test to production.

First, you want to move the tested and verified Account Management application environment into a quality assurance (QA) setting. Specifically, this means five changes:

The WebSphere Application Server environment must run on the AIX® platform.
The IBM HTTP Server should run on its own separate host and not be collocated with the deployment manager.
The Account Management application environment should utilize compute resources dedicated for our QA and disaster recovery purposes.
The application binaries should be retrieved from a different repository.
The data source should be configured to refer to a different database instance.

Like with the move from development to test, the changes start with cloning a pattern. As part of this transition, you have to make sure your WebSphere Application Server environment runs on the AIX platform. Traditionally, moving an entire application environment and associated application infrastructure stack from one platform (in this case SUSE Linux® running on VMware) to an entirely different one (AIX running on PowerVM) can be complex, time-consuming, and error-prone. With WebSphere CloudBurst, that is no longer the case.

To rebase your application environment on AIX for PowerVM, simply clone the existing Account Management Cluster — Test pattern and choose a different image on which to base the pattern. Do this in the initial dialog panel during the pattern clone process as illustrated in Figure 18.

Figure 18. Creating the Account Management QA pattern

Select the WebSphere Application Server 7.0.0.7 (PowerVM) image as the basis for your QA pattern. This image runs on the IBM PowerVM hypervisor platform and includes an AIX operating system. In a matter of seconds and with a few clicks, you have rebased our Account Management application environment on an entirely new operating system! Further, all of the customizations built into the pattern, such as the topology of the cell, installation of the Account Management application, and the configuration of the DB2 data source, are preserved.

After creating the new pattern, enter the pattern editor interface. Once there, remove the Add IBM HTTP Server node script package from the deployment manager part and drag and drop an IBM HTTP servers part from the list on the left-hand side to the pattern canvas.

Figure 19. Account Management cluster: QA pattern

It is worth pointing out that when you alter a pattern containing advanced options, those advanced options may reset. In this case, after removing the script package from the deployment manager part, the Cluster configuration and JVM tuning script packages (created because the Define clusters advanced options setting was selected) disappear. To reset these options, simply click Advanced Options and re-select the option to define clusters.

After making the necessary changes in the pattern editor, you are ready to begin the deployment process.

Though not discussed to this point, every time you deploy a pattern in WebSphere CloudBurst, you target a specific cloud group. A cloud group is a collection of hypervisors used by WebSphere CloudBurst to host the virtual machines it creates during deployment. At least one cloud group is required, but you can define multiple cloud groups in order to more effectively divide shared resources across the organization as seen in Figure 19.

Figure 20. WebSphere CloudBurst cloud groups

Within a particular cloud group, all of the hypervisors must be of the same type (like, all VMware ESX hosts or all PowerVM hosts). Create your new pattern using the WebSphere Application Server Hypervisor Edition packaged for the PowerVM platform. You need to ensure that you deploy to a cloud group that is managing a collection of PowerVM hosts. With that need in mind, it is a good time to point out that not only can WebSphere CloudBurst manage multiple cloud groups, but also one appliance can manage multiple cloud groups which in turn manage different hypervisor platforms.

Figure 21. Managing a heterogeneous cloud

As seen in Figure 21, WebSphere CloudBurst effectively abstracts the underlying infrastructure so that the end-user experience when deploying patterns is the same. To deploy your new pattern to the PowerVM platform, simply choose the QA Cloud Group that happens to be a PowerVM cloud group. Other than that, configure the pattern for deployment in exactly the same way, likely changing certain information about the application and data source configuration as you have done for previous deployments.

Figure 22. Selecting the QA cloud group

Next, configure the virtual parts similar to the way you did for the previous deployment of the Account Management Cluster — Test pattern. The only change for this deployment is specifying different information for application and data source configuration.

Figure 23. Application and data source configuration for QA

Like in the previous migration step, change the application binaries, database username, and database host name values. Again, you could change any or all of these values as necessary. After configuring the deployment manager part, configure the custom node parts and the IBM HTTP Server part (because you included that as a separate part of your pattern) with the necessary password information.

Now you can deploy to our quality assurance cloud; once the virtual system is up and running, login to the WebSphere Application Server administration console as before. If you want, you can confirm the correct makeup of your cell by going to the nodes listing. This time you should see different hosts for each of the nodes in your cell.

Figure 24. Node listing for QA environment

Other than different hosts for each of your nodes, the resulting environment is much the same. You still have your Account Management application configured to run on a WebSphere Application Server cluster and utilize a DB2 data source.

Again, you have accomplished the migration process via changes made in a drag-and-drop interface and small deploy-time modifications. And you can measure the entire process in minutes rather than in days (or worse yet, in weeks).

Comments