Starting in WebSphere CloudBurst 2.0, there are different levels of elasticity that you can achieve in your WebSphere deployments. As I mentioned in a previous post, the Intelligent Management Pack allows you to define dynamic clusters. This means cluster membership and the number of instances of a given application adjusts on the fly to meet SLAs for your application. This enables a more dynamic environment as opposed to static cluster definitions, but there is a layer of elasticity below this that bears exploring.
Dynamic clusters work with WebSphere nodes that already exists. Users define the nodes available for use by a dynamic cluster, and the runtime uses SLAs and current system state to determine the actual nodes used and application instances started. So, what if you need more nodes than what you currently have in a given WebSphere environment? A dynamic cluster will not create a new node, so you have to define extra nodes. Starting in WebSphere CloudBurst 2.0, this is as easy as pushing a button.
Dynamic virtual machine operations allow you to add and remove nodes on the fly for a given virtual system. For instance, take the pattern in the picture below:
If you were to deploy this pattern, you would end up with a WebSphere Application Server cell with a node makeup similar to the below:
Now that the environment is out there (in mere minutes I should mention), suppose you want to add more nodes? Before WebSphere CloudBurst 2.0, you could have done it, but it would involve creating another pattern with a custom node part and deploying it. This results in two different virtual systems and complicates the maintenance stream. Now, in WebSphere CloudBurst 2.0, you can simply click a button to add a node to the existing virtual system.
From the virtual systems view, if you expand the virtual machines, by each virtual machine you will see an Actions column with a View link. If you want to add a node to the environment shown above, you simply click the View link, and then click the clone icon highlighted in green below:
WebSphere CloudBurst prompts you for the number of nodes to add. You make the selection and then click OK. The appliance creates the new node and federates it into the cell for you. For instance, if you chose to add a single node, at the end of the clone not only would you have another virtual machine in your virtual system, but also another node automatically federated into your WebSphere Application Server cell:
On the flip side, you can remove a node by clicking the delete icon in the same dialog as the clone icon above. This removes the node from the WebSphere Application Server cell and deletes the virtual machine.
The ability to easily add and remove virtual machines from your WebSphere CloudBurst virtual systems enables a very valuable level of elasticity. Now you can very easily add and remove nodes on the fly based on the current demands of your system. As always, let me know if you have any questions or comments.
When writing a new tool for the WebSphere CloudBurst samples gallery last week, I got the chance to use an API in the CLI that was new to me. Specifically, I got a chance to use the WebSphere CloudBurst CLI in order to retrieve an audit log from the appliance for a specified date period. In case this is new and interesting to you, I thought I would share what I found.
First off, let's take a look at the API I am talking about. It's pretty simple: cloudburst.audit.get(file, start, end). Here, start is the start date for the audit entries and (naturally) end is the end date for those entries. The file parameter simply denotes the location or file object you want to use to store the audit archive retrieved via the get method.
This is a simple enough API. The only wrinkle comes in dealing with calculating the start and end dates. According to the WebSphere CloudBurst Information Center, both the start and end times are 'specified as the number of seconds since midnight, January 1, 1970 UTC. Floating point values can be specified to indicate fractional seconds.' For my use case, I wanted to let a user or calling program pass the start and end times as arguments to the CLI script that retrieves the audit archive. Check out the relevant portion of my script below:
As you can see, the script takes in the start and end time in the MM/dd/yy HH:mm format (i.e. 05/20/10 15:30). It parses the value to produce a date, gets the long value of the date (which is in milliseconds according to the java.util.Date API), and divides that value by 1000. This is to account for the fact that the cloudburst.audit.get method expects you to express the start and end times in seconds. The script passes the converted dates along with the output file location to the get method. The result is a ZIP file that contains an appliance audit, license audit, and PVU audit file for the specified date range.
One of my favorite things about the WebSphere CloudBurst CLI is that it is Jython-based. This means I can leverage Java APIs from my CLI scripts, and that is huge for me because of my existing knowledge of the Java language. You certainly can substitute Python APIs for my use of Java APIs to handle the start and end date calculation. I hope this is helpful, and good luck with the WebSphere CloudBurst CLI!
A while back I had a four part FAQ series inspired by questions arising from customer visits discussing the first release of WebSphere CloudBurst. With the recent release of WebSphere CloudBurst 2.0, I think it is a good time to revisit an FAQ series with an entirely new set of questions.
For the first part of the series, I want to address a question we get all the time now: "What is the difference between WebSphere CloudBurst and WebSphere Virtual Enterprise?" This question was always fairly common, but now even more so because the new Intelligent Management Pack option for WebSphere Application Server Hypervisor Edition allows you to deploy WebSphere Virtual Enterprise cells using WebSphere CloudBurst.
Fundamentally, the difference between the WebSphere CloudBurst Appliance and WebSphere Virtual Enterprise is a complementary one. WebSphere CloudBurst provides a means to create your application environments, deploy them into a shared, cloud environment, and then manage them over time. In this respect, the appliance focuses on bringing cloud-like capabilities to the application infrastructure layer of your application environments. WebSphere CloudBurst does give you management capabilities for your running, virtualized application environments (i.e. applying maintenances and fixes), but for the most part those capabilities do not extend into the application runtime environment.
Now, you may ask why WebSphere CloudBurst does not extend its reach into the application runtime. The answer is simple: We already have a solution that does just that, WebSphere Virtual Enterprise. WebSphere Virtual Enterprise provides capabilities that allow you to dynamically and autonomically manage your application runtime. You can use WebSphere Virtual Enterprise to not only assign performance goals to your applications, but also to declare the importance of a given application meeting its goals relative to other applications in your organization. This enables the dynamic management of your applications and their resources such that your applications perform according to their goals and relative importance to your business. Simply put, you get an elastic runtime at the application layer of your application environments.
As I said, WebSphere CloudBurst and WebSphere Virtual Enterprise are complementary solutions. Both enable notions of cloud computing, but at different layers of your application environments. WebSphere CloudBurst hones in on the application infrastructure components, while WebSphere Virtual Enterprise zeros in on the applications running in those environments. The new Intelligent Management Pack for WebSphere Application Server Hypervisor Edition means that WebSphere CloudBurst can now dispense WebSphere Virtual Enterprise environments into your on-premise cloud. That means you can take advantage of these complementary solutions from a single and simple management plane.
I hope this helps to clear things up. As always, questions and comments are welcome!
For the next installment of this series of FAQs, let's move from product positioning and integration, square into the land of operational procedure. For this post, we will consider you are getting ready to deploy a pattern based on the WebSphere Application Server Hypervisor Edition. During the deployment process, you provide configuration information, which includes a password for a user named virtuser.
You read the documentation, and you understand that virtuser is both an operating system user and the user that WebSphere CloudBurst configures as the primary administrative user for WebSphere Application Server. Naturally, this user owns the WebSphere Application Server processes that run in the virtual machine. While it is convenient that this is all pre-configured for you, you want to know one thing: "Can I define a user besides virtuser?"
It certainly would not be the first time this question came up. The short answer to this is yes, but there are of course caveats. You can define another user and have that user own the WebSphere Application Server processes, but you cannot completely remove the virtuser user, nor should you remove virtuser as the primary administrative user. The reason for this is that WebSphere CloudBurst relies on virtuser when it carries out certain actions such as applying maintenance, applying fixes, or otherwise interacting with the WebSphere Application Server environment.
All that being said, I recently put together a script package that allows you to utilize a user other than virtuser. I hope to put the script package in our samples gallery soon, but here's a basic overview of using the script package and what it does:
Attach the script package to all parts in a pattern that contain a WebSphere Application Server process.
Deploy the pattern and provide the necessary parameter values. These include the name of the new user, a password, a common name, and a surname. The last two bits are necessary when creating a new administrative user in WebSphere Application Server.
During deployment, the script package first creates a new OS user with the specified password.
The script adds the new user to the existing OS users group.
The script creates a new WebSphere Application Server user with the same username and password and grants administrative privileges to the user.
The script shuts down the WebSphere Application Server processes.
The script changes the runAsUser value for all servers to the empty string and sets the runAsGroup value for those servers to users. This allows members of the OS users group to start the WebSphere Application Server process.
The script starts the WebSphere Application Server processes.
There are a few other activities in the script, but that should give you a basic overview. Again, note that the script does not remove the virtuser user or change that user's OS or WebSphere Application Server permissions in anyway. I would also point out that if you use WebSphere CloudBurst to apply maintenance to the WebSphere Application Server environment, it will do so as virtuser and it will restart processes as virtuser, so plan accordingly.
I hope this sheds some light on a very common question. I hope to get the sample up soon, and as always let me know if you have any questions.
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.
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:
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.
When it comes to provisioning and managing WebSphere application environments in a cloud, nothing approaches WebSphere CloudBurst in terms of expertise and instant value. However, I bet there is more to your data center provisioning and management activities than just WebSphere application environments. You probably deploy and manage a wide variety of both IBM and non-IBM software. While some of these activities may be beyond the scope of the WebSphere expertise you get with WebSphere CloudBurst, they fall well within the reach of offerings from IBM Tivoli.
One of the Tivoli offerings that comes to mind in the service delivery automation arena is the Tivoli Service Automation Manager (TSAM). TSAM delivers capabilities to request, deploy, monitor, and manage a broad range of IT services within a cloud environment, in large part by using both virtualization and automation as delivery vehicles. Even better for WebSphere users, you can integrate TSAM and WebSphere CloudBurst to make use of TSAM capabilities in concert with the WebSphere deployment and management expertise delivered by WebSphere CloudBurst. When using these two together, you actually deploy and manage WebSphere CloudBurst patterns directly from the TSAM user interface.
The integration starts by providing information about a target WebSphere CloudBurst Appliance (essentially the location of the appliance and login credentials) within TSAM. After that, you run a discovery process included with TSAM to gather information about patterns on the target appliance. Once you discover the pattern information, you perform one last configuration step, and you are ready to go.
As far as actually initiating a pattern deployment, it works much like other project requests in TSAM. From the TSAM user interface, you create a new project based on a WebSphere CloudBurst pattern. The request goes into the queue, where an administrator can approve or reject the request. This gives a nice touch of workflow governance to WebSphere CloudBurst deployments. If approved, the project request proceeds and TSAM, by way of the WebSphere CloudBurst REST APIs, initiates the deployment of the selected pattern from the appliance. Of course, there is also a means to remove the virtual system directly from the TSAM user interface. You can cancel any WebSphere CloudBurst based project, and if approved by an administrator, TSAM again leverages the WebSphere CloudBurst REST API to trigger the deletion of the virtual system.
The integration of TSAM and WebSphere CloudBurst provides the best of both worlds really. You can use a single portal as a gateway for provisioning and managing a broad range of IT services within a cloud environment, while still leveraging the significant out-of-the-box know-how and value provided by WebSphere CloudBurst for WebSphere environments. Check out a demo of this integration here, and as always, let me know if you have any questions or comments.
I point this out about script packages because recently I put one together that is not a WebSphere Application Server administration task, but does provide configuration logic common to many WAS deployments. Specifically, I put together a script package that configures an IBM HTTP Server to be a reverse proxy server. This of course, allows clients to send requests to the IBM HTTP Server and have those requests pass through to a specified back-end destination (i.e. a service hosted on WebSphere Application Server) based on URI paths.
The script package is not all that different from many of the ones I put together. It contains a shell script (which provides configuration and orchestration logic) as well as a cbscript.json file that defines the script package's characteristics when I upload it into WebSphere CloudBurst. The notable difference in this script package is that I include a Perl script that modifies the IBM HTTP Server configuration file. This just reiterates the point that you are not limited to only wsadmin and shell scripts within your script packages.
The workings of the script package are quite straightforward. It starts with a call to the shell script that modifies the IBM HTTP Server's configuration file to ensure the loading of a couple proxy modules:
sed -i s/"#LoadModule proxy_module modules\/mod_proxy.so"/"LoadModule proxy_module modules\/mod_proxy.so"/g $HTTP_CONF
sed -i s/"#LoadModule proxy_http_module modules\/mod_proxy_http.so"/"LoadModule proxy_http_module modules\/mod_proxy_http.so"/g $HTTP_CONF
As you can see, the createProxy.pl script accepts a single argument. This argument represents the reverse proxy configuration information provided by the user during deployment. The Perl script parses the single argument and creates the appropriate proxy directives in the IBM HTTP Server's configuration file:
After the invocation of the script above, control returns to the shell script. The shell script restarts the IBM HTTP Server so that the configuration changes take place. The result is an up and running IBM HTTP Server acting as a reverse proxy based on information supplied during deployment. The listings here do not show the full script package, but I hope to have it up on our WebSphere CloudBurst Samples Gallery soon.
If the script above provides some configuration logic you can use, that is good. However, my main point for bringing it up here is to point out that WebSphere CloudBurst script packages can be more than shell and wsadmin scripts that perform WebSphere Application Server configuration tasks. You can use them to do any sort of scripted activity that is essential to your application middleware deployment process. Happy scripting!
Yesterday, we kicked off a WebSphere in the Clouds campaign designed to connect you with IBMers that can help you to leverage WebSphere solutions to build clouds. The campaign consists of webcasts, podcasts, live Q&A sessions, and online JAMs. You can listen to replays and sign up for upcoming events by visiting the Global WebSphere Community website.
Next week, the campaign delivers a series of podcasts that discuss the WebSphere technologies that form the building blocks of clouds. These podcasts will discuss both the business and technical aspects of these solutions, and they will cover topics like application infrastructure in the cloud, policy-based workload management using application virtualization, hybrid cloud integration, and more. Over the past few days, I had the opportunity to catch up with the various presenters of these podcasts to ask them a few questions about their solutions. These interviews provide a nice sneak peak at what is coming in the podcasts, and I will be posting them here in the coming days.
To kick things off, I'm posting a video interview with Marc Haberkorn. Marc is the WebSphere Product Manager for WebSphere CloudBurst, WebSphere Application Server Hypervisor Edition, and WebSphere Virtual Enterprise. My colleague, Ryan Boyles, caught up with Marc and got his thoughts on how these solutions enable virtualization and automation for your cloud environments. Enjoy!
The concepts that govern users and user groups in WebSphere CloudBurst are fairly basic, but I get asked about them enough that I believe they warrant a short discussion. First things first, you can define users in WebSphere CloudBurst and optionally define user groups to assemble users into logical collections. For both users and user groups, you can assign roles that define the actions a particular user or group of users can take using the appliance.
All of that is straight forward, but it can get a bit tricky once we start considering the effects of user permissions when managing at the user group level. The basic premise is that when a user belongs to a group or groups, the user's effective permissions are a sum of the permissions to all of the groups to which they belong. While that is easy to say, and maybe even to understand, I feel like an example always helps.
Consider that we have a single user WCAGuy that belongs to the PatternAuthors, ContentCreators, and CloudAdmins groups. The permissions for those groups are as follows:
PatternAuthors: Users in this group have permission to create and deploy patterns
ContentCreators: Users in this group have permission to create catalog content as well as create and deploy patterns
CloudAdmins: Users in this group have permission to administer the cloud, create catalog content, and create and deploy patterns
Naturally then, it follows that the WCAGuy user can administer the cloud, create catalog content, create patterns, and deploy patterns. So then, what happens if we remove the WCAGuy user from the CloudAdmins user group? Well, as you may expect, there is an update to the user's permissions. The WCAUser user can no longer administer the cloud, but they can still create catalog content, create patterns, and deploy patterns (owing to their membership in the other two groups). Similarly, if we next removed the WCAGuy user from the ContentCreators group, then the user would retain only the permission to create and deploy patterns.
Just one more thing, let's talk about what happens when I remove a user from a group and they no longer belong to any groups. Consider that I created the WCAGuy user with the permission to create catalog content as well as create and deploy patterns. Next, I added the user to the CloudAdmins group, meaning the user now has the permission to administer the cloud. I promptly decide that the user has no business with those permissions, so I remove the user from the CloudAdmins group. What happens? The user retains the permission set of the last group to which they belonged. In this case, that means the WCAGuy user retains cloud administration rights. I have to update the user's permission set if I want to take that right away, but in this case, it will not automatically disappear upon removing them from the CloudAdmins group.
I hope this helps clear up any ambiguity you may have had concerning users, user groups, and permission sets in WebSphere CloudBurst.
It seems like it was announcement day across IBM, and specifically in WebSphere. While the announcements were numerous and touched many different topics, I want to focus on a couple of announcements of particular interest to those of you interested in WebSphere CloudBurst and IBM Hypervisor Edition virtual images.
First, for all of our WebSphere Process Server and WebSphere Business Monitor users, there are a couple of important pieces of information in this announcement. This announcement outlines the availability of WebSphere Business Monitor Hypervisor Edition. The new image allows you to dispense WebSphere Business Monitor 7.0 environments using WebSphere CloudBurst to VMware hypervisors. In addition, the announcement outlines the expansion of the existing WebSphere Process Server Hypervisor Edition image to support the z/VM platform and the Red Hat Enterprise Linux (RHEL) operating system for VMware.
Moving beyond our BPM set of solutions, IBM also announced the availability of a WebSphere Message Broker Hypervisor Edition. This virtual image allows you to construct and deploy WebSphere Message Broker and WebSphere MQ environments using WebSphere CloudBurst. The stack includes the RHEL operating system, and it is ready to run on VMware hypervisors.
With that in mind, here's an update to the WebSphere CloudBurst supported product matrix:
* Availability subject to dates documented in referenced announcement letters
As you can see, we are continuing our effort to expand the choice you have when using WebSphere CloudBurst to create and deploy application environments to your cloud. If you are interested in using WebSphere CloudBurst for WebSphere Business Monitor, WebSphere Process Server, or WebSphere Message Broker, check out the above announcements. You will find more technical information as well as planned availability dates.
Just one last scrap of food for thought. Feedback from you, our users, is instrumental as we continue to expand software choice with WebSphere CloudBurst. Please continue to let us know your thoughts and needs!
It's really hard to complain about my work week right now. As I write this blog, I'm sitting in the Congress Center in Düsseldorf, Germany looking out over the Rhine River. As an aside, in Germany it is the Rhein River, and I have a historical connection to this body of water. My surname, Amrhein, translates (loosely) to 'on the Rhein'. It does not take an expert in genealogy to conclude that I have ancestors who at one time or another lived very close to this important German waterway.
Okay, putting the family tree aside for a minute, there is a good reason that I am in Düsseldorf this week. The city, and specifically the Congress Center, is playing host to the IBM European WebSphere Technical Conference. I am here presenting sessions that include a WebSphere CloudBurst overview, a WebSphere CloudBurst hands-on lab, and an up-close look at one of our internal team's use of the appliance. I have done each of these sessions once so far, and attendance was great, audience participation high, and feedback forthcoming. I am hearing and seeing the same thing in other sessions, which is of course, ideal for us presenters.
Now, to focus in on WebSphere CloudBurst for a bit, it seems that I am hearing a recurring question this week from the mostly European audience: "Why is WebSphere CloudBurst delivered as an appliance?" I am sure that I addressed this question in a previous blog post, but I believe it bears revisiting. There are various reasons I could give for the appliance form factor, but I like to distill all of that down into three major reasons: Consumability, Performance, and Security.
From a solution consumability perspective, nothing beats the appliance approach. WebSphere CloudBurst is an integrated hardware and software solution that delivers a specific set of function. You do not have to install software, procure and maintain storage for resources on the appliance (images, patterns, scripts, etc.), and maintain software components over time. You simply drop the appliance in to your data center, perform a one-time initialization, hook it up to the network, and you are ready to start leveraging WebSphere CloudBurst to build out your private cloud. While there is definitely work to setup the cloud infrastructure that WebSphere CloudBurst deploys environments to, we can completely eliminate a significant portion of solution implementation lead time by delivering everything you need in the appliance.
The performance benefits of an appliance approach are a natural result of building an integrated hardware and software stack. Design and development teams provide optimizations in both the hardware and software based on the fact that both the hardware and software have intimate knowledge of each other's design. In other words, this is not a 'least common denominator' tuning approach. Rather, the integrated design leads to enhanced performance for the specific set of functionality provided by WebSphere CloudBurst.
Finally, appliances enable us to deliver a very hardened, secure device. We provide private key encryption of every resource stored on the appliance. That private key is unique to each appliance and cannot be modified. In addition, the physical casing is tamper-resistant. If someone removes the casing, a 'Get Smart' style kill switch puts the appliance in a dormant state. You must send the appliance to IBM so we can reset it before further use, thus providing an additional layer of physical protection on top of the encryption. These security features, plus more, like a shield that prevents anyone from executing code on the appliance, come right out of the box and require no end-user configuration activity. In this way, you can simply focus on leveraging the user security and access controls provided by WebSphere CloudBurst.
If you had any questions on the rationale behind the appliance form factor of WebSphere CloudBurst, I hope this helps. I am off for now... back to the conference and the wonderful city of Düsseldorf.
I write a lot about WebSphere CloudBurst script packages. Typically, I write about what they are, how to create them, and even provide some samples from time to time. I find that most of the time I'm either writing or talking about script packages from the standpoint that they allow you to automate the delivery of customizations to environments you deploy with WebSphere CloudBurst. More specifically, I usually explain how you can include these script packages in your patterns to ensure that your custom scripts execute as part of every pattern deployment. The truth is, that is not the whole story. In fact, it's only 1/3 of the story.
In WebSphere CloudBurst, when you define a script package you also define its execution mode. The execution mode can be one of three values, and it indicates the invocation time for the script. The default value is at virtual system creation, and that tells WebSphere CloudBurst to automatically invoke the script as part of the deployment process. This seems to be the most commonly used execution mode, and in the original version of WebSphere CloudBurst it was the only available mode (which probably attributes to why I only usually tell 1/3 of the story here). As you may expect, there is a wide range of usage scenarios for this class of script packages including installing applications, activating monitoring agents, registering cells with an externally managed DNS server, and much more.
If you are like me (and many humans), you enjoy and actually expect symmetry. In that regard, it probably comes as no surprise that there is a script package execution mode called at virtual system deletion. As the name indicates, this class of script packages executes as an automatic part of the virtual system deletion process. When a user tells WebSphere CloudBurst to remove a virtual system, before it shuts down the machines in the system, it will run each script package marked to execute at virtual system deletion. Typical use cases for these scripts include removing information about the cell from externally managed DNS servers, freeing up connections with external systems, and other external 'clean up' activities.
So this leaves the final execution mode for script packages, the when I initiate it mode to be precise. This class of script packages executes when explicitly triggered by a user. In the virtual machine detail section for a deployed virtual system, you can see a list of user-initiated script packages for a given machine. There is a start button by each of the user-initiated script packages that allows you to invoke the script when, and as many times as you need to. While these script packages have many different use cases, the most common use case is to deploy application updates. Users build these application update scripts, attach them to a pattern, and invoke them whenever they want to deliver an updated application into their already deployed environment.
WebSphere CloudBurst script packages are one of the main vehicles for delivering your customizations to your cloud environments. The three execution modes mentioned above allow you to determine when the right time to deliver those customizations is.
In keeping with the impressive release pace, WebSphere CloudBurst 126.96.36.199 is now available for download from the IBM Support site. In some ways, this release is typical of what you may expect from a service release. In other words, there are defect fixes and other general enhancements in the new version of the firmware. However, this release is a bit more than your typical service release in that there are a couple of major additions of which you should be aware.
First, starting in WebSphere CloudBurst 188.8.131.52, you will be able to provision WebSphere CloudBurst patterns to IBM Power7 systems. We already supported both Power5 and Power6 systems, and this new addition allows you to take advantage of some of the significant enhancements in the IBM Power7 hardware. In addition, this means that from a single appliance you can provision environments to multiple different releases of VMware, IBM z/VM, and IBM PowerVM hypervisor technologies. The best thing about this is that WebSphere CloudBurst provides an effective abstraction layer over the underlying infrastructure so that no matter which of the hypervisor solutions you use, the end-user experience with the appliance remains the same. You get all of this from a single device!
The other major element in WebSphere CloudBurst 184.108.40.206 is the introduction of Environment Profiles. Traditionally, WebSphere CloudBurst controlled most of the pattern deployment process. While this allows the appliance to provide a lot of configuration activity without input from the user, it made some usage scenarios hard to accommodate. For instance, historically you have not been able to assign specific IP addresses to machines in your deployment, and you have not been able to deploy a pattern across multiple cloud groups. Now, with environment profiles you can. Environment profiles give you more control over deployment behavior, including the ability to assign IP addresses (as opposed to WebSphere CloudBurst automatically doing so), deploy parts across multiple cloud groups, and apply virtual machine naming standards. The use of these new resources is completely optional, so you can still use the traditional deployment model, but this provides you with flexibility if you so choose. You can learn more about this new capability by watching the short demonstration here.
As an aside to the above information concerning WebSphere CloudBurst 220.127.116.11, I should also point out new WebSphere Hypervisor Edition announcements detailed here. I encourage you to read the announcement, but to summarize there are two major pieces of information. First, when you buy PVUs of entitlement for WebSphere Application Server Hypervisor Edition or WebSphere Message Broker Hypervisor Edition, those entitlements also apply to WebSphere Application Server and WebSphere Message Broker respectively. You can use the Hypervisor Edition images and traditional software packages in any combination, up to the level of use based on your Hypervisor Edition entitlements. Second, there is a new licensing for WebSphere Application Server Hypervisor Edition called IBM HTTP Server for WebSphere Application Server Hypervisor Edition. This allows you to deploy IBM HTTP Server instances using the WebSphere Application Server Hypervisor Edition without paying for the full Hypervisor Edition license. Again, for more details and term information, please read the announcement referenced previously.
There will be more to come about WebSphere CloudBurst 18.104.22.168, including an article on the use of environment profiles, but I wanted to give everyone a quick heads up. Let me know if you have any questions or feedback for us.
In my last post, I concentrated on the new enhancements to WebSphere CloudBurst 22.214.171.124. One of the major new additions was the introduction of Environment Profiles, and I promised a developerWorks article would be forthcoming. The article is now live along with a demo that showcases the capability of environment profiles.
As I mentioned in my last post, environment profiles center around giving you more customization capability during the pattern deployment process. In WebSphere CloudBurst, the pattern deployment process consists of the five main steps depicted below.
Traditionally, WebSphere CloudBurst controlled the entire deployment process, thus closing it off to the deployer. Environment profiles extend the customization reach of users to be able to effect steps 1-3 in the above diagram. Specifically, environment profiles give you the following control:
Control over the assignment of IP addresses and hostnames to pattern parts: Instead of having WebSphere CloudBurst automatically assign IP addresses, and thus hostnames, to virtual machines during deployment, you can explicitly set both values during the deployment process.
Ability to deploy single patterns to multiple cloud groups: Previously, when deploying a pattern you selected a single cloud group and WebSphere CloudBurst deployed all the parts in the pattern to machines within that cloud group. While this may be okay for many cases, other cases may require you to deploy some parts of the pattern to one group of machines while other parts map to a separate set of machines. Before environment profiles, you could accomplish this with multiple patterns. With environment profiles, you can accomplish it with a single pattern.
Ability to supply virtual machine naming standards: As part of deploying a pattern, WebSphere CloudBurst creates one to many virtual machines with distinct names. Environment profiles allow you to supply a naming standard that WebSphere CloudBurst will use when creating the machines as opposed to default naming schemes previously used.
It is important to note that the use of environment profiles is completely optional, and you can continue to use the traditional deployment process, thereby leaving WebSphere CloudBurst in control. That said, the introduction of environment profiles is a direct response to consistent user feedback we received regarding the need for more control during the deployment process. Based on my user conversations, these profiles address many of said needs in an easy to use, straightforward manner. We are, of course, eager to know what you think. As always, you can let me know right here, through email, or on Twitter (@damrhein).