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 188.8.131.52 (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).