Harness the power of the cloud with IBM Workload Deployer V3

IBM® Workload Deployer V3 is not just another release of the IBM WebSphere® CloudBurst™ Appliance. While it builds on WebSphere CloudBurst's success, and supports and improves upon all of its original capabilities, Workload Deployer provides new application-centric computing capabilities for your private cloud, and brings you higher utilization, improved ease of use, and more rapid application deployment. This content is part of the IBM WebSphere Developer Technical Journal.


Dustin Amrhein, Technical Evangelist, IBM

Author photoDustin Amrhein joined IBM as a member of the development team for the WebSphere Application Server. While in that position, Dustin worked primarily on web services infrastructure and web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role Dustin is a WebSphere Client Technical Professional.

developerWorks Professional author

Joseph Bohn, Technical Evangelist, IBM

Photo of Joe BohnJoe Bohn is a Senior Software Engineer currently serving as a Technical Evangelist for emerging WebSphere technologies. Previously, he worked on open-source projects involving Apache Aries, Apache Geronimo, and WebSphere Community Edition. Joe began his career with IBM in 1985 as a CICS Systems Programmer, and has held numerous Developer and Architect positions in a variety of areas, including WebSphere Portal and Tivoli.

Brian Stelzer, Staff Software Engineer, IBM

Author photoBrian Stelzer is a Software Engineer and Team Leader on the IBM Workload Deployer team. In his current role, he provides training and architectural solutions for cloud-based environments, focusing on IBM Workload Deployer, WebSphere Application Server, and VMware-based technologies. Previously, he designed migration solutions for WebSphere Application Server and WebSphere Application Server Community Edition.

22 June 2011

Also available in Chinese Japanese Spanish


Enterprise cloud computing is no longer something that companies are just thinking or talking about. Rather, cloud computing has taken hold, and companies are starting to realize the promised benefits of virtualization, standardization, automation, and elasticity.

But the wave of cloud computing occurring in enterprises today is only the first phase. Within the accepted cloud deployment spectrum of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), the vast majority of current implementations are in the IaaS category. Enterprises that design and implement IaaS set a strong foundation for their cloud computing efforts, but it does not stop there. Fundamentally, IaaS focuses on delivering computing resources such as servers, storage, and networking as easily accessible and rapidly provisioned services – usually by way of virtual machines. But companies need to deliver applications to consumers, and rapidly provisioning standard operating system environments only goes so far toward that goal. Therefore, many enterprises are starting to look beyond their current IaaS implementations to enable a more application-centric approach to their cloud efforts. Companies want solutions that deliver the same kind of value offered by IaaS solutions, but do so in terms of applications and application environments. In other words, they are beginning the journey toward PaaS.

IBM Workload Deployer

In light of this increasing interest in PaaS solutions, the announcement of IBM® Workload Deployer V3 is well timed. It enables PaaS in the private cloud through a choice of different delivery models. Why is this newly announced product already at V3? IBM Workload Deployer evolved from the IBM WebSphere® CloudBurst Appliance, which has been available for two years. WebSphere CloudBurst Appliance was at V2, and during development of V3, it became clear that the scope of the offering was larger than any one IBM software brand. Therefore, the name was changed to IBM Workload Deployer V3 (hereafter called Workload Deployer) to reflect the fact that the appliance can deploy and manage a wide variety of platform software in a cloud setting.

All WebSphere CloudBurst functions are still present in Workload Deployer, which means that you can still use IBM Hypervisor Edition images and script packages to create highly customized patterns that you deploy and manage through the appliance. Many WebSphere CloudBurst functions have been improved, as described below. But the most significant update in Workload Deployer is that it now supports two pattern-based deployment models.

First, you can construct, deploy, and manage the same kinds of patterns as with WebSphere CloudBurst. The new name for this kind of pattern is virtual system pattern, and Workload Deployer adds several new features to enhance the use of these patterns.

The second patterns-based deployment model is new in Workload Deployer and is called virtual application patterns. They offer an application-centric approach to building, deploying, and managing environments in a cloud. As opposed to virtual system patterns, you need to know very little about the underlying middleware infrastructure when using virtual application patterns to deploy an environment. You simply provide an application and application artifacts (such as a database schema), declare application dependencies, and specify functional and non-functional requirements for your application via policies. Figure 1 shows an example of this deployment approach:

Figure 1. Using virtual application patterns in the cloud
Using virtual application patterns in the cloud

As shown in Figure 1, Workload Deployer can inspect the provided application and its dependencies and policies, and then construct the necessary middleware infrastructure to host the application. In addition, it installs and configures the application on top of the middleware and provides management capabilities for the deployed, running environment. The result is an application-oriented approach to delivering services in the cloud.

When you use a virtual application pattern to deploy and manage one of your applications, it encapsulates the installation, configuration, and integration of everything you need, and provides a running application. However, because virtual application patterns encapsulate so many actions, you do cede some control to Workload Deployer. Figure 2 shows various cloud deployment models along a continuum of customization and control, total cost of ownership (TCO), and time to value (TTV):

Figure 2. The cloud tradeoff
Figure 2. The cloud tradeoff

You can see that you have various deployment model choices, including custom-built and installed, virtual appliances (Workload Deployer supports simple deployment of OVA images), virtual system patterns, and virtual application patterns. You must select the appropriate deployment model by balancing your needs for customization and control against the TCO and TTV that your business requires. As a rule of thumb, if a virtual application pattern meets the needs of your application, then it offers the most value to your organization. You will learn more about virtual application patterns later in this article.

Besides introducing new deployment models, Workload Deployer includes many other new features, including:

  • Virtual applications
  • Intelligent Management Pack updates
  • Virtual machine mobility
  • Virtual machine add-ons
  • Appliance backup enhancements

Before describing these new capabilities, there is one other important point about Workload Deployer. As with WebSphere CloudBurst, IBM is delivering this solution as a hardware appliance in order to speed the setup process. Updates to the new hardware appliance include a new 2U frame, increased processing and networking capacity, and a six-fold increase in storage. Now let's dive into the new software features of Workload Deployer.

Virtual applications

As described in the overview, virtual applications are a PaaS feature that makes your application the central focus. Simplicity and repeatability are two primary design goals, and most of the infrastructure to support your application is installed and configured by Workload Deployer. In fact, only selected configuration options are available for configuration.

A virtual application has two main parts: virtual application pattern and virtual application instance. The pattern describes the application infrastructure and artifacts, while the instance is the deployed pattern.

To create a virtual application pattern, navigate to Patterns => Virtual Applications and click the green + icon. A panel opens, giving you the option to start from scratch or from an existing preconfigured template. When you are ready to start building your application, click Start Building, as shown in Figure 3:

Figure 3. Starting from a blank template
Starting from a blank template

The Virtual Application Builder, where you build out your virtual application, opens in another browser tab:

Figure 4. Virtual Application Builder
Virtual Application Builder

To show how easy it is to build out a virtual application, here is a simple example. Assume that you have a single enterprise application (EAR) file that requires a database to store user data, and you have already created the schema file to populate the database. To top things off, you have no experience with IBM middleware products.

First, decide which middleware components your application needs to run. This example requires an application server and a database.

Under Assets, expand the Application Components and Database Components sections. Drag the Enterprise Application (WebSphere Application Server) component and Database (DB2) component onto the canvas. Create a link between the Enterprise Application and Database components. This link will open inbound and outbound communication channels between the two components. Figure 5 shows an example of what the virtual application pattern looks like at this point:

Figure 5. Build out middleware components and link
Build out middleware components and link

The final step in building out your pattern is to configure the environment. As noted earlier, few configuration points are surfaced, and what is surfaced usually has an acceptable default for most use cases. However, some configuration points can't be derived by Workload Deployer, such as your schema file or enterprise application archive file. To configure your environment, click each component to bring up its properties. Required properties will have an asterisk next to them. After you fill in the required properties, you are ready to save and deploy your pattern. Figure 6 shows an example of the properties view:

Figure 6. Enterprise application component properties
Enterprise application component properties

After you deploy your pattern, you monitor its status by clicking Instances => Virtual Applications to open the Virtual Application Instances panel. When the status is "running," indicated by a green "play" icon, your application is ready to receive requests. To access your application, you need the URL, which you derive by clicking on the Endpoint link next to the VM that represents your enterprise application component, which displays the IP, port, and context root of your application. Enter this information in a browser or simply click the link to open a new tab. Figure 7 shows an example of an endpoint:

Figure 7. Endpoint information
Endpoint information

That's all there is to it! To keep this explanation simple, some steps and options were not included, including the multitude of available components (such as OSGi, messaging, user registry, and existing components), and policies (such as scaling, logging, JVM, and routing). A future article will provide a more thorough walkthrough of virtual applications.

Intelligent Management Pack

The Intelligent Management Pack is an optional feature that you can enable when using WebSphere Application Server Hypervisor Edition. When enabled, the Intelligent Management Pack lets you build and deploy virtual system patterns that result in WebSphere Application Server cells augmented with WebSphere Virtual Enterprise. The Intelligent Management Pack enables you to take advantage of all standard WebSphere Virtual Enterprise features, including policy-based application request management, robust application editioning, and proactive application health monitoring. In addition, you get the fast deployments and simplified configuration from WebSphere Virtual Enterprise features such as health policies, dynamic clusters, and the On-demand Router.

The Intelligent Management Pack has been an option in prior versions of WebSphere CloudBurst and WebSphere Application Server Hypervisor Edition, but using it with Workload Deployer brings a tighter integration between the deployed WebSphere Virtual Enterprise runtime and Workload Deployer.

So when should you use the Intelligent Management Pack? Traditionally, WebSphere Virtual Enterprise has provided policy-based application request management and JVM elasticity for deployed middleware environments, enabling you to define service policies that prescribe performance goals and relative importance for your applications. As requests come into the runtime, WebSphere Virtual Enterprise prioritizes and dispatches the requests in accordance with the policies you specified. If necessary, WebSphere Virtual Enterprise can autonomically start up new application server processes (JVMs) in order to meet the demand. Likewise, WebSphere Virtual Enterprise can shut down JVMs if it determines it can put the resources to better work elsewhere. Elasticity at the JVM level provides you with flexibility and a reasonable assurance that the system is doing what it can to meet the policies you defined for your application. In the past, this elasticity had its limits in that WebSphere Virtual Enterprise could only start up new JVMs on a group of nodes statically defined ahead of time for its use. Therefore, while the system could grow at the JVM level, it could become constrained by the limits of the nodes defined for its use. In other words, the elasticity capabilities of WebSphere Virtual Enterprise stopped at the JVM level.

The new version of the Intelligent Management Pack for WebSphere Application Server Hypervisor Edition that ships with Workload Deployer pushes removes this limitation by introducing a feature called elasticity mode. It enables WebSphere Virtual Enterprise to automatically call back to Workload Deployer to provision more nodes (virtual machines) for use in the deployed environment. Essentially, if WebSphere Virtual Enterprise determines that it needs more resources to meet service level policies but cannot add more JVMs to the current set of nodes due to resource constraints, it sends a request to Workload Deployer to provision more virtual machines. Workload Deployer then provisions these virtual machines and adds them as nodes to the deployed environment. At that point, WebSphere Virtual Enterprise can use those new nodes to host extra JVMs capable of serving application requests. Figure 8 provides an overview of this new integration between WebSphere Virtual Enterprise and Workload Deployer:

Figure 8. Overview of elasticity mode
Figure 8. Overview of elasticity mode

In addition to autonomically scaling up the deployed application environment, elasticity mode can also automatically scale down the environment, thus providing true elasticity and a reasonable assurance that you are consuming only those resources needed to meet the goals defined in your service level policies. This new feature is very easy to use. When building a pattern based on an image with the Intelligent Management Pack enabled, you simply select the Define dynamic clusters, Create dynamic clusters, and Enable elasticity mode configuration options under Advanced Options in the Workload Deployer Virtual System Pattern Editor, as show in Figure 9:

Figure 9. Enabling elasticity mode in Virtual System Pattern Editor
Enabling elasticity mode in Virtual System Pattern Editor

Elasticity mode is not the only new capability delivered in the new version of the Intelligent Management Pack. When you use it, you are deploying WebSphere Virtual Enterprise V7 environments, and therefore you can take advantage of all the functionality in this new version, including improved multi-cell performance management, updated historic charting, simplified service policy definitions, centralized logging, and new SNMP trap capabilities. For more information on these new features, see the WebSphere Virtual Enterprise V7 documentation.

Virtual machine mobility

Virtual machine mobility is an Workload Deployer feature that lets you migrate a Workload Deployer managed VM from one hypervisor to another. The running state of the VMs being migrated can be turned on ("live migration") or off. In the current release, mobility is supported only on the VMware platform, which uses VMware vMotion technology to perform the actual migration. There are two requirements: VMware must be configured to support vMotion, and the shared data store must be of type SAN (which is a requirement of Workload Deployer and not of VMware vMotion).

Why might you need the mobility feature? Here are two possibilities: you might need to move all managed VMs off of the hypervisor to perform maintenance, or resource demand of the managed VMs on a single hypervisor might be approaching hypervisor limits.

Mobility requires admin level permissions, specifically the Cloud administration => Full permissions permission.

To migrate a VM, select Cloud => Hypervisors and click the source hypervisor on which the VM is deployed. Before performing a migration, place the hypervisor in Quiesce mode by clicking the Quiesce icon:

Figure 10. Place hypervisor in Quiesce mode
Place hypervisor in Quiesce mode

Once the hypervisor is in Quiesce mode, you can migrate all of the hypervisor’s managed VMs at once, or migrate each VM individually. To migrate all of the managed VMs, click the Initiate mobility operations icon and choose the destination. There are two destination choices: you can choose, or you can click The System chooses, in which case Workload Deployer queries all available hypervisors and makes an intelligent decision based on current resource usage. Figure 11 shows the available target options:

Figure 11. Migrate all of the hypervisor's managed VMs at once
Migrate all of the hypervisor's managed VMs at once

To have more control over which VMs get migrated, click the Virtual machines twisty to expand the list of VMs. Then click the View link under the Actions column corresponding to the VM that you want to migrate, as shown in Figure 12 below. (The other option is to click Group Actions at the top.)

Figure 12. Migrate VMs individually
Migrate VMs individually

Virtual machine add-ons

Among the themes of WebSphere CloudBurst Appliance that continue into Workload Deployer are simplicity and efficiency, as evidenced by the introduction of virtual machine add-ons, which are specialized scripts to customize the virtual machine configuration. Add-ons let you modify the virtual machine configuration during deployment without the need to modify and save a new image configuration. You can use add-ons to augment the hardware and OS configuration of a virtual machine.

Consider a scenario in which you need additional disk space on a virtual machine. Without add-ons, you can add disk space by extending and capturing one of the IBM-provided virtual images, and then providing a custom script to configure the virtual disk after deployment. Alternatively, you can create an entirely new virtual image with the required disk space already formatted. If you subsequently need a different size virtual disk for another pattern, you would have to create yet another virtual image in a similar fashion, which is tedious and results in multiple images whose only difference is the size and format of the virtual disk.

Add-ons greatly simplify this task. With the new add disk add-on, you only need to drag and drop the add-on from the Pattern Editor palette to the appropriate part and then configure the parameters for the format and size of the disk. The disk is created when the image is deployed and if not locked, the parameters can be further modified during deployment.

You use add-ons like custom scripts -- you create and clone them in the appliance catalog as necessary and then drag them on to parts in the Virtual System Pattern Editor. The primary difference is that add-ons are run before any custom scripts and they target the virtual machine configuration.

Workload Deployer provides the four virtual machine add-ons listed below, and you can copy and modify them as necessary. You can also create entirely new add-ons to suit your environment.

  • Default Add User
  • Default Add Disk
  • Default Raw Disk
  • Default Add Network Interface Controller (NIC)

You can find these add-ons in the catalog. To create new add-ons, click on the green + icon as shown in Figure 13:

Figure 13. Add-ons catalog
Add-ons catalog

Default Add Disk

The Default Add Disk add-on creates a virtual disk on the virtual machine, formats the disk with the selected file system, and mounts the disk. It is available for VMware ESX and z/VM hypervisors. The Default Add Disk add-on includes the following parameters:

Disk size
The default is 10 GB.
File system type
Must be a valid option for mkfs –t. The default is ext3.
Mount point
Location to mount the disk. No default value.

Default Raw Disk

The Default Raw Disk add-on is similar to Default Add Disk but includes a default file system type of raw and does not include a mount point.

Default Add User

The Default Add User add-on defines a new user on the virtual machine. It runs a simple add user command and is guaranteed to run before any user-level script packages. It is available on the three hypervisors currently supported by Workload Deployer. The Default Add User add-on includes the following parameters:

  • User name
  • Password
  • Password verification

Default Add NIC

The Default Add NIC add-on does not include any parameters in the initial implementation. It must be used with environment profiles. Use of IP pinning results in IP address fields being displayed during deployment to define and initialize the additional NIC. If IP pinning is not in use, then the NIC is initialized and the IP assigned using the normal placement process. The network add-on is available for VMware ESX and z/VM hypervisors.

More about add-ons

Add-ons are like scripts, but there are significant differences. First, add-ons are not listed with the custom scripts. They have their own category in the catalog. Add-ons execute before any custom scripts for a part at the time of deployment. Unlike custom scripts, you cannot specify the order of add-on execution on a part. Add-ons are run only during system creation -- you cannot initiate them on demand. They use hypervisor-level APIs to configure new hardware in virtual machines during deployment.

When dropped on a part in the Virtual System Pattern Editor, add-ons appear as unique icons to distinguish them from custom scripts. You can add values for the parameters and optionally lock the settings so that they cannot be changed during deployment. Figure 14 captures the icons for each default add-on and the parameters. The Default Add NIC add-on is the icon without any parameters displayed.

Figure 14. Add-on parameters
Add-on parameters

Appliance backup enhancements

The appliance backup process now includes two options: On-demand Backup and Continuous Backup, providing much more flexibility than with the WebSphere CloudBurst Appliance. The backup and restore process is also enhanced to facilitate creation and storage of your certificate and private key. On-demand Backup is equivalent to the earlier version in behavior. Continuous Backup provides substantial performance improvements by backing up only those component pieces that have changed since the previous backup. Therefore both the duration of subsequent backups and the network bandwidth required are significantly reduced. This improvement helps ensure that an up-to-date backup will be available it in the event of an unplanned outage.

To view the backup and restore features, select Appliance => Settings, then expand the Backup and Restore twisty:

Figure 15. Backup and restore
Backup and restore

Preparing for your backups

In Figure 15, Steps 1-3 provide the necessary information to enable the secure creation and restoration of an appliance backup. One item required is the remote location where your certificate and private key are stored, which is also the location used by Workload Deployer when you request that it create the certificate and key pair. This procedure is different from WebSphere CloudBurst Appliance, where the credentials were uploaded into the appliance itself. Of course, you must specify a location with enough storage to hold the backup images as they are generated.

Enabling or disabling backups

Step four in Figure 15 enables or disables the backups and selects the type of backup you require. As mentioned earlier, there are now two options: On-demand and Continuous:

Default backup mechanism. It performs a full backup of everything on the appliance including all of the virtual images, virtual system patterns, virtual application patterns, and scripts. On-demand backups can take a considerable amount of time and consume lots of network resources. For the duration of the backup, the appliance is placed in maintenance mode.
Continuous backup
Run every 60 minutes and persist only those items that changed since the previous backup. Changes are split between two categories; changes made to virtual images, and all other changes such as pattern or virtual system changes. Because virtual image backups can consume lots of network bandwidth you can restrict the time when these backups are performed to non-peak periods to avoid placing additional stress on your system. Figure 16 shows the options for both types of backup.
Figure 16. Enable or disable backup options
Enable or disable backup options

Restoring from a backup

The purpose of doing backups is to enable recovery when required. Step 5 in Figure 15 is the step to perform that task. To choose a backup for restoration, specify the date and time of the desired backup plus the private key password, as shown in Figure 17. You do not need to specify the exact time of your backup image. The system searches backward from the date and time you provide to find the most recent backup before that. The information provided in Steps 1-4 is used as the basis for the backup operation. You can also restore a backup from one appliance to another.

Figure 17. Restoring to a previous time
Restoring to a previous time


Many customers have already invested in WebSphere CloudBurst Appliance and may be thinking of moving up to Workload Deployer. Rest assured that all of your existing investment in patterns, scripts, and images will work unchanged in Workload Deployer, and you will gain additional benefits from the many new features. You can simply migrate your current environment to the new appliance, as described in the Workload Deployer documentation. In a nutshell, you simply back up your current WebSphere CloudBurst appliance and then from within an Workload Deployer appliance that has been configured, you migrate the backup to duplicate your environment (the initial configuration data of Workload Deployer will not be overwritten). That's all there is to it! You will be able to work with all of your previous patterns, scripts, images, and other data while exploring the new features of Workload Deployer.

This article has explained some of the features that make Workload Deployer such a valuable appliance for managing your private cloud. The expanded capability is applicable to more than just the WebSphere family of products (thus the name change). The article showed how flexibility and ease of use have been improved via the new mobility and virtual machine add-ons. The article also described the benefits of tighter integration with WebSphere Virtual Enterprise, the new capabilities in the Intelligent Management Pack, and the improvements in backup and recovery. And the article covered what is perhaps the most significant improvement -- a new application-centric model for virtual applications that can increase savings, simplicity, and agility in the deployment and management of your applications.

Workload Deployer is not just another release of the WebSphere CloudBurst Appliance. While it builds on CloudBurst's success and supports and improves upon all of its original capabilities, Workload Deployer provides new application-centric computing capabilities that can take your private cloud to the next level with higher utilization, improved ease of use, and more rapid application deployment. It can thus free your staff to spend more time and energy focused on your business rather than on the middleware necessary to support it.



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 WebSphere on developerWorks

Zone=WebSphere, Cloud computing
ArticleTitle=Harness the power of the cloud with IBM Workload Deployer V3