A while back, I talked about the new multi-image pattern capability introduced in WebSphere CloudBurst 2.0. This capability allows you to build patterns that include more than one product, or more than one version of the same product.

The kind of pattern that is top of mind for me here, and the one I referenced in the previous post, is one that includes both WebSphere Application Server and DB2 components. In this regard, you can deploy the configured application and data containers as a single pattern deployment.

In the pattern above, I include the WebSphere Application Server and DB2 components, along with configuration to create a data source and database. This makes setting all of this up completely automated and much simpler than traditional means. However, if you know something about configuring data sources in WebSphere Application Server, and you know a little bit about the deployment process for WebSphere CloudBurst, this may leave you scratching your head a bit!

What do I mean? Well, when you configure a data source in WebSphere Application Server, you need to know the hostname for your backend database. That shouldn't be an issue, right? After all, I can simply declare parameters for my Create DB2 Data Source script package (which I have), one of them being the hostname, and pass those in during the deployment of the pattern. The catch is, since I'm deploying DB2 as part of this pattern, I will not know the hostname to pass in when configuring the parts for deployment. This is because WebSphere CloudBurst automatically assigns a unique hostname to each part during the deployment process. So, how do you deal with these kinds of issues?

The answer is simple. You use the deploy-time variable substitution capabilities present in WebSphere CloudBurst 2.0. Specifically, when I'm deploying the pattern, I can pass a special variable to the hostname parameter defined by the Create DB2 Data Source. Before invoking the script package to create the DB2 data source, WebSphere CloudBurst automatically resolves the variable to the actual value, thus passing the correct hostname to my script.

As you can partially see above, I passed in the value ${DB2DatabaseServer.hostname}.${DB2DatabaseServer.domain} as the hostname to my script to create the data source. As a result, during deployment WebSphere CloudBurst determines the hostname and domain name assigned to the DB2 part. The appliance passes this value into my script, and thus the script can correctly create the data source in the WebSphere Application Server instance as shown below.

For more information on this variable substitution mechansim, check out the Information Center.

In a previous post, entitled Layers of Elasticity, I talked about the new dynamic virtual machine operations in WebSphere CloudBurst. Specifically, I showed you how to use the WebSphere CloudBurst web console to add more virtual machines (nodes) to an existing virtual system. Well, you can do this with the WebSphere CloudBurst command line interface as well.

First, let's assume I start off with a basic WAS ND environment represented by the pattern below:

When I deploy this pattern in WebSphere CloudBurst, I end up with two virtual machines: one for the deployment manager with an embedded IHS instance, one for my custom node federated into the cell. After deployment, suppose I want to use the CLI to interact with this virtual system. Assuming the name of my virtual system is Cluster, I can view my custom node virtual machine with the following CLI code:

I confirm the addition of the node by checking the number of virtual machines in the system:

>>> len(cloudburst.virtualsystems['Cluster'][0].virtualmachines)
3

The call to the clone function above takes care of creating a new profile and federating the new node into the cell. In addition, WebSphere CloudBurst automatically invokes any script packages from the source virtual machine marked to run at virtual system creation. All because of this single line of code!

The WebSphere CloudBurst CLI is a powerful interface that enables you to automate the function of the appliance. Check it out, become familiar with it, and make WebSphere CloudBurst processes a seamless part of your overall data center management approach.

A few nights ago, I went for a casual jog around the neighborhood. There is nothing notable about this since I do it regularly, and more to the point why should you care?? Well, it's what I did before and after the jog that may be of interest.

Sometimes when I present WebSphere CloudBurst I note a hint of skepticism in the room. It's not that the audience does not see the value in the WebSphere CloudBurst approach, since to a person they nearly always do. However, in some cases, the hardcore, impressively knowledgeable WebSphere administrators in the room are a little doubtful that they can create the same kind of heavily customized environments they rely on daily using WebSphere CloudBurst patterns. Well, I contend that you can!

I decided that rather than just make a claim, I would build a heavily customized, integrated environment in the form of a pattern. In particular, I wanted to build a pattern to accomplish the following:

I would consider this a fairly complex target environment with multiple integration points (XC10 and DB2). In WebSphere CloudBurst, I started by creating a custom virtual image and installed the necessary WebSphere eXtreme Scale binaries. This provided me the basis to achieve integration with the WebSphere DataPower XC10 Appliance. After creating the image, I built the pattern pictured below.

With a combination of parts, scripts, and advanced options provided by WebSphere CloudBurst (to setup my dynamic cluster), the pattern above encapsulates each one of my goals from above. And, before you throw your hands up and tell me how much scripting that is, the longest script is less than 50 lines! Better yet, I only have to write these scripts once, and I only have to provide invocation instructions once. Once completed, the invocation of my scripts is an automated process. This means I cannot muck up the configuration work.

So, what does all of this have to do with my jog? On the way out of the house that evening, I hit the deploy button for the above pattern. When I walked back in the house, I logged into WebSphere CloudBurst, pulled up my virtual systems and saw it was up and running. I logged into the WebSphere Application Server administration console and verified that the resulting environment met every last one of my deployment goals. How is that for low-touch? I simply clicked the deploy button, went for a run, came back and I had a pretty interesting application environment up and going.

When it comes to building and using WebSphere CloudBurst patterns, people always ask me if I have any best practices. It turns out, I do. In fact, I have a singular piece of advice that wraps it all up: Build WebSphere CloudBurst patterns in a way such that once deployed, there is no after-the-fact, manual configuration for the running environment. That means, build the pattern so that it not only contains all the nodes necessary for your application environment, but it also contains all the configuration necessary for the environment.

Put like this, most everyone I talk to agrees with me. However, they quickly recognize that, absent this really cool integration with Rational Automation Framework for WebSphere, this means they will be writing scripts for many configuration actions and including them in patterns in the form of script packages. For users not familiar with configuration scripting for our WebSphere products, this can be a daunting proposition. But... it shouldn't be!

Recently, I put together a short presentation that lays out an iterative approach for developing script packages for WebSphere CloudBurst. Specifically, the presentation focuses on developing configuration script packages for the WebSphere Application Server (though the general concepts apply to all Hypervisor Edition products equally). I believe this method is useful for anyone, from novice users to WebSphere scripting gurus. The basic process goes something like this:

Develop and Test: Develop and test your configuration script. Not a WebSphere Application Server scripting ninja? No worries. Use the Command Assistance feature in the WebSphere Application Server v7 administration console. This feature shows you the wsadmin commands that match the actions you manually take in the console. This affords a lower barrier of entry for those not familiar with wsadmin.

Package: Package up the resulting scripts into a script package along with metadata that describes the package.

Modify and redeploy: Load the new script package into your appliance, add it to your pattern, and then redeploy. Upon deployment completion, verify the scripts produce the desired result.

The presentation provides detail on the above steps and walks through an example scenario for this process. I am embedding it below, and I hope it proves useful. As always, feel free to send in any questions or comments.

For the last post in my FAQs Revisited series, I'm going to cheat a little bit. Instead of addressing one particular question, I'm going with a grab bag of a few different questions. These are questions that I get asked quite frequently, but do not demand an entire blog post explanation. Let's get on with it.

Question: Do the new software license management capabilities provided in WebSphere CloudBurst 2.0 depend on ILMT or other supporting components?

Answer: No. The license management features are completely standalone. Of course, you can still take advantage of ILMT (through easy integration in WebSphere CloudBurst I might add) to track licenses in your cloud if you so choose.

Question: Can I deploy a pattern, make changes to my virtual system, and then recapture that as an updated pattern?

Answer: You cannot do this with WebSphere CloudBurst alone, but you can use WebSphere CloudBurst in conjunction with the Rational Automation Framework for WebSphere to do just this. Check out this article (shameless plug alert!).

Question: What if I have an urgent operating system fix to apply before IBM delivers an update to the OS in the Hypervisor Edition image?

Answer: You can either manually apply the fix to the appropriate virtual machines, or you could package up the fix as a custom WebSphere CloudBurst fix, load it into the catalog, and use the appliance to automate the application of said fix.

Question: Can I change the install location for WebSphere Application Server in the virtual image?

Answer: I've just shown you all this really cool, useful, and easy to use stuff, and you worry about install locations? Seriously though, I understand the genesis of this question usually has to do with existing scripts that assume a certain install location for WebSphere Application Server. I certainly do not advocate changing those scripts, but you cannot change the install location for WebSphere Application Server in the images. There is nothing to keep you from creating a symbolic link however.

Question: Once I deploy a pattern, what do I need to do to add more processing capacity (i.e. more application server processes)?

Answer: You have a couple of options here. You can use normal WebSphere administration techniques to add more application servers to an existing node. If that will not work (perhaps a particular node is operating at max capacity), you can use the new dynamic virtual machine operations in WebSphere CloudBurst to add an entirely new node/virtual machine. If you find yourself consistently making these types of adjustments to the runtime environment based on ebb and flow of demand, you may also want to consider the Intelligent Management Pack option for WebSphere Application Server Hypervisor Edition.

I hope this FAQs Revisited series was helpful. Stay tuned for a look at some recent work I did to integrate WebSphere CloudBurst deployments with the new WebSphere DataPower XC10 appliance.