|To continue with the series of blog posts regarding WebSphere CloudBurst FAQs, I want to take a look at one aspect of the deployment process.|
|When you leverage WebSphere CloudBurst to push patterns (complete WebSphere Application Server configurations) into a private cloud, the appliance provides an advanced placement algorithm to determine exactly where the resulting WebSphere virtual systems will reside. It attempts to match the needs of the pattern to the correct set of hypervisors that have been defined. WebSphere CloudBurst considers things like storage, CPU, memory, and high availability characteristics when placing the pattern, and this is all done by the appliance without you having to intervene at all.|
|This is certainly nice in that it absolves you from having to make such placement decisions. Having said this though, you may be thinking of a question that comes up quite often:|
|If WebSphere CloudBurst controls the placement of the pattern, how can I make sure that certain deployments end up on certain servers (hypervisors)?|
|Considering what I just told you above, it may not seem that it's possible to control what machines end up hosting your virtual system since the appliance takes care of that placement for you. However, the organized use of WebSphere CloudBurst cloud groups allows you to take advantage of the intelligent placement provided by the appliance while retaining a level of control over which machines end up hosting particular deployments.|
|In WebSphere CloudBurst all patterns are deployed to cloud groups. Cloud groups are a collection of hypervisors that have been defined within the appliance. The basic deployment mapping is depicted in the image below:|
|As seen above, you can create a cloud group for any purpose (dev, test, QA, production, etc.), including any hypervisors that you desire as long as a given hypervisor only belongs to a single cloud group. When you are ready to deploy a pattern, you simply select the cloud group you want to deploy to:|
|By selecting a cloud group for deployment, you are implicitly selecting the physical machines that will host your deployment. The cloud group could consist of anywhere from one to N hypervisors, so you are afforded the ability to restrict the location of your virtual systems as necessary.|
|I hope this helped explain a little bit about cloud groups in WebSphere CloudBurst. If you're looking for more information about WebSphere CloudBurst cloud groups, I'd also suggest you watch this video on our YouTube channel.|
|-- Dustin Amrhein|
A view from the clouds: Cloud computing for developers
DKA 0600026VJ2 Tags:  cloud websphere cloudburst websphere_cloudburst cloud_computing 5,079 Views
DKA 0600026VJ2 Tags:  cloudburst cloud_computing websphere_cloudburst private_cloud virtualization 3,271 Views
The more and more we visit with customers about our new WebSphere CloudBurst Appliance, the more we see a common thread of questions emerge around the offering. In an attempt to address some of these questions in a more accessible medium, I figured I'd start a series of blogs that relays some of these questions and of course the answers. Today I want to start with what is perhaps the most frequently asked question about WebSphere CloudBurst.
One thing I've noticed while talking to customers is that virtualization and virtualization management tools are widely used today. When we talk to customers already using these tools, they immediately understand the benefits WebSphere CloudBurst delivers in the form of virtualizing WebSphere Application Server environments and bringing a set of lifecycle capabilities to this virtualization. However, almost invariably they ask why they would use WebSphere CloudBurst over their existing tools, for instance VMware's vSphere offering.
There's a two-word answer to this question: WebSphere intelligence. What exactly does that mean? WebSphere CloudBurst was built with WebSphere in mind, and it knows how to configure, tune, and maintain WebSphere Application Server environments without the need for custom scripting.
For instance, when a user is building a WebSphere CloudBurst pattern (if you are wondering what a pattern is, or just want to learn the basics of WebSphere CloudBurst, take a look at this article) the relationships among the various WebSphere Application Server parts are automatically configured. This means that custom nodes are automatically federated into the Deployment Manager cell, web servers are automatically configured to route to application server nodes (and the web server's config file is setup to be automatically propagated), and much more. In addition to establishing these relationships, WebSphere CloudBurst also applies best practice tuning to the WebSphere environment. This tuning of course is just a suggestion and can be easily changed by users.
In addition to configuring and tuning a topology, WebSphere CloudBurst allows users to apply both fixes and service level upgrades to running virtual systems. Through the console, users can select virtual systems and apply either a fix or upgrade directly to the system. All the while, WebSphere CloudBurst automatically backs up the state of the system before the change is applied, and users can easily roll back to the previous system state if undesired behavior is encountered after the change.
I'm not disputing that all of these actions could be potentially accomplished using some "black-box" virtualization management tool, but the burden of supplying WebSphere intelligence is placed directly on the user. In order to configure, tune, or maintain virtualized WebSphere Application Server environments, users would accompany their virtual machine definitions with a heavy dose of scripting. These scripts only add to the pile of IT assets that need to be owned, updated, and maintained over time, and they only serve to distract users from the end-game of getting their applications up and running.
It's important to note too that WebSphere CloudBurst was only just released, so I would expect that the WebSphere intelligence it provides will only grow and get better over time. If you want to learn more about WebSphere CloudBurst, or if you think your company would be interested in a briefing and demo please get in touch. You can reach me at firstname.lastname@example.org. We would love to explain both the business value and technical capabilities of the appliance.
-- Dustin Amrhein
I have written in this blog before about how using WebSphere CloudBurst, users can achieve fully customized WebSphere Application Server environments. Those customizations start at the operating system level by extending the shipped virtual images, modifying those images, and recapturing the custom image in the WebSphere CloudBurst catalog. On top of operating system level customizations are customizations made to the WebSphere Application Server middleware environment.
Customizations to the middleware environment are mainly achieved through what WebSphere CloudBurst calls script packages (click here for the script package section in the WebSphere CloudBurst Information Center). Very simply script packages are merely ZIP files that users uploaded into the WebSphere CloudBurst catalog and include in their custom WebSphere CloudBurst patterns as necessary.
The ZIP file that is stored in the catalog includes an executable script and optionally a set of artifacts used or needed by the script. In addition to uploading this ZIP file into the WebSphere CloudBurst catalog, users tell WebSphere CloudBurst how to invoke the script package and provide other information like environment variables that need to be present during script execution. WebSphere CloudBurst then uses this information to invoke the script packages upon completion of pattern deployment.
Script packages are very open-ended. As long as WebSphere CloudBurst can execute the script in the operating system environment, then it can be included in a pattern. So, users can create script packages that utilize the WebSphere Application Server wsadmin tool to install applications, set server trace settings, or otherwise alter the WebSphere Application Server configuration. Alternatively, users can supply operating system executables like shell scripts that otherwise configure the application environment. As long as a valid executable is supplied, then there are really no imposed limits on what a script package can do.
However, just because script packages can do just about anything doesn't mean they should! You can read this developerWorks article for a more complete discussion about WebSphere CloudBurst customizations and the use of script packages, but the bottom line is that script packages are best suited to deliver customizations that vary over application environments (like installing applications). For customizations that are needed in just about every application environment (required anti-virus software comes to mind), creating a custom virtual image is the way to go.
If you want to learn more about WebSphere CloudBurst script packages, I'd suggest you check out the WebSphere CloudBurst Information Center link and the developerWorks link above. As always, let us know if you have any questions by commenting here, sending us a tweet (@WebSphereClouds), or by sending an email to email@example.com.
-- Dustin Amrhein