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.
I want to stay in the realm of the deployment process for our next frequently asked question regarding the WebSphere CloudBurst Appliance.
The ability to quickly deploy entire WebSphere Application Server cells (anything from single node cells, to multi-node clustered cells) is a hugely compelling feature of the appliance. Instead of spending days or hours deploying a WebSphere Application Server cell, users can deploy these in a matter of minutes (less than twenty minutes for clustered environments)!
For the most part, WebSphere CloudBurst patterns represent entire cells. This includes management parts (AdminAgent, DeploymentManager), managed parts (custom nodes), and proxy parts (IHS). When you deploy a pattern, the result is a complete and fully functional WebSphere Application Server cell running in your private cloud.
So, now that you have a complete cell out in your cloud, what happens if you need to add more nodes? If the the user-demand for the applications on your cell has exceeded the initial topology, can you use WebSphere CloudBurst to add more cells? Sure you can!
In short, this involves creating a pattern that contains only a custom node part, and then at deploy time, providing information about the existing cell. WebSphere CloudBurst then takes over the deployment of that custom node and federates the node into the existing cell based on the information supplied about that cell. I won't go into an entire explanation here, because I think the demo I put on our YouTube channel explains it pretty well.
In my experience with the WebSphere Application Server, this represents a much more seamless and automated process for deploying new nodes into an existing cell than what exists outside of WebSphere CloudBurst today. Of course, we value your comments and feedback above all else. So let us know what you think!
Over the last three posts I've been discussing a few of the most frequently asked questions regarding the WebSphere CloudBurst Appliance. I'd like to wrap up today with a fourth and final installment.
If you have read some of my entries before, or if you have read any of our WebSphere CloudBurst articles on IBM's developerWorks, then you know that the appliance brings extreme simplification and safety to applying fixes and service level upgrades to running WebSphere Application Server virtual systems. Users select a virtual system, choose a fix or service level upgrade, and then WebSphere CloudBurst drives the application of the fix or upgrade to the system. Before applying the fix or upgrade, the appliance takes a snapshot of the virtual system, and users can simply click a button to roll back to the previous state if the process produces undesired results.
This is a pretty strong value add to WebSphere Application Server management and one that our users typically immediately understand. Almost always though, after users see this they are curious about another aspect of rolling out fixes and upgrades in WebSphere CloudBurst. In particular, they want to know how they ensure that all subsequent deployments (after applying the fix to a specific virtual system) can be ensured of having the correct fixes and service levels.
The answer to this inquiry is that there are a couple of different ways to achieve this, and it depends on what you are try to accomplish and your preferences. For instance, if you want to make sure all of your subsequent deployments have a particular interim fix, you will likely go the route of image extension. First, you pick the WebSphere Application Server Hypervisor Edition image in your catalog to which the fix applies. Next, you extend that image, and once a virtual machine based off the image is accessible, you use existing WebSphere Application Server tools (Update Installer) to apply the fix. After the fix has been applied, you can capture the updated image and then use it as the basis for patterns created from that particular version of the WebSphere Application Server.
On the other hand, if you are looking to ensure subsequent deployments are based on a new level of the WebSphere Application Server, your process will be a bit different. First you would load a new WebSphere Application Server Hypervisor Edition image (based on the new level of WebSphere Application Server) into your WebSphere CloudBurst catalog. Then you would select any of your customized patterns you wanted to upgrade to the new level, clone that pattern, and simply select the new image as the basis for the pattern. All of your other customizations are preserved. Really, it's that simple!
I hope that over the last month I have answered some of the more common questions about WebSphere CloudBurst. At any point if you have any questions feel free to email me or leave a comment right here on the blog.
Over the past several months industry focus on cloud computing seems to have only intensified. Within IBM and for the purposes of this blog, WebSphere, there have been several announcements and offerings that indicate our commitment and belief in the cloud computing approach.
To further highlight WebSphere's focus and offerings in the cloud computing realm, we are embarking on a "WebSphere in the Clouds" campaign during the months of September and October. Our intent is to virtually deliver information about our cloud strategy and offerings directly from the experts to you, our WebSphere users.
The event will be kicked off by WebSphere's Director of Product Management, Kareem Yusuf, on September 23rd from 9-10 EDT. Kareem will talk about cloud computing in the enterprise, and its unique relationship to SOA thoughts and principles. In addition, he'll give an overview of what WebSphere has been doing in the cloud computing space. This will be followed by sessions from technical experts that detail WebSphere offerings in both the public and private clouds, as well as sessions that discuss enablers of application and application infrastructure elasticity.
To find out more about the "WebSphere in the Clouds" campaign, you can check out the main announcement page. To sign up for the series of virtual events visit the registration page. We hope you will join us for the series of webcasts to learn all about WebSphere's work in the clouds.
I've blogged previously about some of IBM's work in the public cloud and specifically on our partnership with Amazon to deliver IBM offerings on the Amazon EC2 cloud. Mostly on this blog I've been focused on IBM WebSphere offerings on the Amazon cloud, but coming up on October 1st, you'll get a chance to hear about and see the full breadth of IBM software offerings available on the Amazon EC2 cloud. Better than simply hearing and seeing, by attending the virtual developer's day, you'll get access to try out some of this software absolutely free!
By leveraging IBM software on Amazon EC2, users can very quickly benefit from the advantages of a cloud computing approach to IT. Instead of focusing valuable time and resource on installing, updating, and otherwise maintaining software, users can simply activate instances of the IBM software of their choosing on Amazon's infrastructure. Besides delivering this rapid approach to getting up and going, users can also leverage cloud computing techniques to quickly and dynamically scale up and down their entire application infrastructure. This ability to dynamically scale up and down means your end-users will always enjoy a satisfactory experience when accessing your applications on the cloud.
You can sign up for the Cloud Computing for Developers day here. In the meantime you can learn more about IBM offerings on the Amazon EC2 cloud by visiting the IBM/Amazon EC2 landing page. I hope you can take advantage of a chance to hear both IBM and Amazon experts and learn how IBM software delivered on the Amazon EC2 cloud can make a real difference for your business.
I’m going to take a different approach this week in the blog. Instead of me telling you about some of the features or uses of WebSphere CloudBurst, I thought I would catch up with someone using the product everyday, WebSphere Test Architect Robbie Minshall. Robbie is responsible for a team of testers that harness a lab of over 2,000 physical machines to put our WebSphere Application Server product through some pretty rigorous testing. Toward the beginning of this year Robbie’s team started to leverage the WebSphere CloudBurst Appliance in order to create the WebSphere Application Server environments needed for their testing.
Robbie, can you tell us a little bit about what the WebSphere Application Server test efforts entail?
In WebSphere Application Server development and test we have two primary scenarios. The first is making sure that developers have rapid access to code, test cases and server topologies so that they can write code, test cases and then execute test scenarios on meaningful topologies. The second scenario is an automated daily regression where in response to a build, we provision a massive amount of WebSphere Application Server topologies and execute our automated regression tests.
Previously we have supported these scenarios through the deployment of the Tivoli Provisioning Manager for operating system provisioning, some applications for checking out environments, and then a lot of automation scripts for the silent install and configuration of WebSphere Application Server cells.
Given those scenarios and the existing solution, what are your motivations for setting up a private cloud using WebSphere CloudBurst Appliance?
We are supporting these scenarios through a pretty complicated combination of technologies. These include silent WAS install scripts, wsadmin configuration scripts, a custom hardware leasing application and the utilization of Tivoli Provisioning Manager for OS Provisioning. This solution is working very well for us though as always we are looking for areas to improve, opportunities to simplify and to reduce our dependency on investment in our custom automation scripts. Mainly, there were 3 areas where we wanted to improve our framework: Availability, Utilization and Management. This is why we started looking to the WebSphere CloudBurst Appliance.
Can you expand a bit on what you are looking for in those three areas?
The first focus area we have is availability of environments. We really wanted to lower the entry requirement for the skills and education necessary to get a development or test environment. Setting up these environments has just been too hard, too time consuming, and too error prone. Using WebSphere CloudBurst we can provide an easy push button solution for developers to get on-demand access to the topologies they need.
The second area we are looking for significant improvements on is hardware utilization. Our budgets are tight and in our native automation pools we are only using between 6-12% of the available physical resources. In order to improve this we were looking at leveraging virtualization. WebSphere CloudBurst offers the classic benefit of virtualization with the nice additions of optimized WebSphere Application Server placement and really good topology and pattern management. In our initial experiments we were able to push the hardware utilization up to 90% of physical capacity and consistently were leveraging around 70% of our physical capacity.
Finally we are looking to improve and simplify our management of physical resources and automation. We work in a lot of small agile teams and organizational priorities change from iteration to iteration. Not only does WebSphere CloudBurst allow us to maintain a catalog of topologies or patterns for releases but it also allows us to adjust physical resource allocation to teams through the use of sub clouds or cloud groups.
Basically we felt that WebSphere CloudBurst would improve the availability of application environments, enhance automation, and improve hardware utilization all with very low physical and administrative costs.
What were some of the challenges involved with getting a cloud up and running in your test department?
One of our challenges seems like it would be common to many scenarios, especially in today’s world. Our budget for new hardware to build out our cloud infrastructure was initially very limited. Most cloud infrastructure designs depict very ideal hardware scenarios including SANs, large multicore machines, and private and public networks within a dedicated lab. Quite frankly we did not have the budget to create this from scratch. It was important for us to demonstrate value and data to warrant future investment in dedicated infrastructure. After some performance comparisons we were very happily surprised to see that we could leverage our existing mixed hardware within a distributed cloud. The performance of application environments dispensed by WebSphere CloudBurst on many small existing boxes in comparison to large multicore machines with a SAN was very comparable. This allows us to leverage existing hardware, with minimal investment all the while demonstrating the value and efficiencies of cloud computing. That data in turn has allowed us to obtain new dedicated hardware to iteratively build up a larger lab specifically for use with WebSphere CloudBurst.
Specifically with WebSphere CloudBurst, are there any tips/hints you would offer users getting started with the appliance?
Sure. First, we quickly realized as we added hypervisors to our WebSphere CloudBurst setup it was critical to have someone with network knowledge on hand. This is because the hypervisors came from various sections of our lab, and we really needed people with knowledge of how the network operated in those different sections. Once we had the right people we were able to setup WebSphere CloudBurst and deploy patterns within an hour and a half.
Moving forward we continued to have challenges as we dynamically moved systems between our native hardware pool and our cloud. Occasionally the WebSphere CloudBurst administrator would move a system into the cloud but incorrectly configure the network or storage information. This lead to some misconfigured hypervisors polluting our cloud. We overcame this, quite simply and satisfactorily I may add, by creating some simple WebSphere CloudBurst CLI scripts which add the hypervisors, test them individually, by carrying out a small deployment to that hypervisor, and then move the correctly configured hypervisors into the cloud after verifying success. Misconfigured hypervisors go into a pool for problem determination. This has allowed us to maintain a clean cloud, and we are able to dynamically move our hardware in and out of the cloud to meet our business objectives.
We also use the WebSphere CloudBurst CLI to prime the cloud so to speak. Before using a given hypervisor in our cloud, we execute scripts that ensure each unique virtual image in our catalog has been deployed to each of our hypervisors at least once. When the image is first deployed to a hypervisor, a cache is created on the hypervisor side of the connection, thus meaning subsequent deployments do not require the entire image to be transferred over the wire. This gives us consistent and fast deployment times once we are using a hypervisor in our cloud.
I would assume that like many applications deployed on WebSphere Application Server, your team’s applications have several external dependencies. Some of these dependencies won’t necessarily be in the cloud, so how did you handle this?
You’re right about the external dependencies. Our applications and test cases run on the WebSphere Application Server but are dependent upon many external resources such as databases, LDAP servers, external web services etc. WebSphere CloudBurst allows us to deploy WAS topologies in a very dynamic and configurable way but the 1.0.1 version does not allow us to deploy these external resources in the same manner. This was overcome by using script packages in our patterns. These script packages allow us to associate our test applications with various patterns we have defined. The script package definition also allows us to pass in parameters to the execution of our scripts. We supply these parameter values during deploy time, and these values are used to convey the name or location of various external resources. The scripts that install our applications can access these values and ensure the application is properly integrated with the set of resources not managed by the appliance.
What is your team looking to do next with WebSphere CloudBurst and their private cloud?
The next challenge on our plate is to keep up with the demand of our expanding cloud and to develop a more dynamic relationship between our native pools and our cloud using the Tivoli Provisioning Manager. These are fun challenges to have and we look forward to sharing our progress.
I'm glad I got to spend some time with Robbie to glean some insight into their work and progress with WebSphere CloudBurst. I hope this information was useful to you. It's always nice to hear about a product from practitioners who can give you hints, tips, gotchas, and other useful information. Be sure to let me know if you have any questions about what Robbie and his team are doing with WebSphere CloudBurst.
When we talk about the WebSphere Application Server Hypervisor Edition, we often get a lot of questions about whether or not SUSE Linux is the only flavor of the Linux operating system that we support. The short answer to that question is no.
While it is true that we only deliver the WebSphere Application Server Hypervisor Edition with a SUSE Linux operating system, we will support the use of the virtual image packaging with Red Hat Enterprise Linux as the base operating system. The basic process consists of creating a virtual machine disk based off of a suitable Red Hat install, altering the OVF file in WebSphere Application Server Hypervisor Edition to reference this virtual disk instead of the SUSE virtual disk, and then packaging a new OVA file that contains all the same WebSphere virtual disks (profiles, binaries, IBM HTTP Server) but swaps out the Red Hat virtual disk for the SUSE virtual disk. We have done this many times in both the lab and field, and we offer services to users who need help in creating the image.
Customers often ask if there is any difference in using Red Hat versus SUSE Linux. The answer is, of course, yes and no. The answer is yes in that users must bring their own licenses of Red Hat (SUSE Linux licenses are included in the WebSphere Application Server Hypervisor Edition), and users must support and maintain the Red Hat operating system on their own. However, once the image is built, there is absolutely no difference in the use of that image within WebSphere CloudBurst.
Once built, users upload the image into their WebSphere CloudBurst catalog and it is available for use in pattern building just like any other image. I mentioned that users are responsible for updating and maintaining the image, well users can use WebSphere CloudBurst to create these updated images. When patches or updates are ready for the Red Hat operating system, the Extend/Capture facility available for images in WebSphere CloudBurst can be used to create a new custom Red Hat operating system with your desired fixes. This is all done without ever having to worry about actually recreating and repackaging the image again.
I know seeing is believing, so with respect to the "sameness" of using a Red Hat version of the WebSphere Application Server Hypervisor Edition within WebSphere CloudBurst, I've created a short demo you can watch here. As always, let us know what you think and send any questions our way.
If you've attended one of our WebSphere CloudBurst sessions then you've undoubtedly heard us talk about the "special sauce" or "WebSphere intelligence" delivered by the WebSphere CloudBurst Appliance. If you haven't attended one of our sessions, trust me, we talk about it a lot, but there's good reason. This "special sauce" truly sets WebSphere CloudBurst apart from other virtualization management tools.
Essential to the uniqueness of the WebSphere CloudBurst solution is the WebSphere Application Server Hypervisor Edition virtual image that it dispenses. In one sense, the intelligence comes in the format of pre-installed, tuned, and configured software. The operating system and WebSphere components are all pre-installed, and the WebSphere Application Server configuration is tuned based on best performance practices. In addition, the image comes with a pre-configured instance of each WebSphere Application Server profile type that is available in the version that is bundled. This saves time during deployment since the unneeded profiles are simply removed.
The pre-installed, tuned, configured software only sets the foundation for what truly sets apart the WebSphere CloudBurst solution. The activation framework built inside of the WebSphere Application Server Hypervisor Edition allows WebSphere CloudBurst to deliver unique value. This activation framework allows the single virtual image to turn into many different flavors of WebSphere Application Server (Dmgrs, Standalone nodes, Custom nodes, Job Managers, etc), and it provides the facilities to change WebSphere cell and node names, IP addresses, host names, and more while a running virtual machine instance is being created.
On a mostly unrelated topic, the changing of WebSphere cell names, node names, host names, is done with documented, publicly available commands in either wsadmin or other WebSphere Application Server binaries. I know many customers want to do this exact same thing in their existing environments, so if you are wondering how it is done, drop me a line below.
Anyway, I won't get into anymore detail here because you can get a much better assessment of this special sauce elsewhere. Ruth Willenborg, one of the lead architects for the WebSphere CloudBurst Appliance, did a developerWorks Comment lines piece about this special sauce. Ruth provides a deeper look at the topics I hit on above, and it's a really good read. You can check it out for yourself here.
One of the things I haven't written about much here is how the WebSphere CloudBurst Appliance integrates with other IBM software solutions. One of those interesting integration scenarios, and one I think is particularly useful for developers, involves Rational Build Forge.
Very simply put, Rational Build Forge is an adaptive execution framework that allows users to define completely automated workflows for just about any purpose. These workflows are represented as projects that contain a discrete number of steps. When looking at Rational Build Forge through the software assembly prism, the offering allows users to fully automate and govern the process of building, assembling, and delivering software into an application environment.
Now, on to the integration of WebSphere CloudBurst and Rational Build Forge. Users can build custom patterns in WebSphere CloudBurst that include a special script package (which I'll eventually provide a link to from here). This script package provides the glue between the deployment process in WebSphere CloudBurst and Rational Build Forge. When deploying a WebSphere CloudBurst pattern that contains this script package, users provide the name of a Rational Build Forge project as well as information about the Rational Build Forge server on which the project is defined.
Once the necessary information is supplied, the deployment process gets underway. Toward the end of the deployment, like all other scripts included in patterns, the special Rational Build Forge script is invoked. This results in the project specified during deployment being executed on the virtual machine created by WebSphere CloudBurst.
Because the Rational Build Forge project executes on a virtual machine setup by WebSphere CloudBurst, the individual steps of the project can very easily access the WebSphere Application Server environment. Thus, the Rational Build Forge project could very easily contain steps to build, package, and deploy an application into the WebSphere Application Server cell. The result is a fully automated process that includes everything from standing up the application environment to delivering applications into that environment.
I put together a short demonstration of this integration, and you can take a look at it here. As always, please let us know if you have any questions or comments. Your feedback is much appreciated!
There have been quite a few announcements from IBM lately that keep referring to the "IBM Cloud". Since IBM has been moving at a pretty substantial pace with cloud offerings as of late, I thought it may help to give readers a concise idea of exactly what the IBM Cloud provides.
Put very simply, the IBM Cloud is a public cloud offering that allows users to provision and utilize IBM Software on an infrastructure hosted by IBM. From the IBM Cloud's web-based dashboard, users choose a software package, provide some deployment information about the particular instance they wish to create, and then simply click OK. In a matter of minutes the software is up, running, and available for full use. At the time I wrote this blog, I saw software from our Information Management, Rational, and WebSphere brands available for use. In addition, users can launch plain SUSE Linux instances out onto the IBM Cloud.
Within WebSphere, users can choose from either the WebSphere Application Server or WebSphere sMash. I just went through a WebSphere sMash deployment, and in about 6 minutes the sMash instance was up and running, and I was able to log into the App Builder development environment. The WebSphere Application Server package that's available on the IBM Cloud is particularly interesting because it contains an embedded Rational Controller Agent. This makes it very easy to integrate some of the Rational offerings on the IBM Cloud (or elsewhere) with the WebSphere Application Server. Many of these integration scenarios focus on making it easier to very quickly build, package, and deploy applications from Rational development tooling to WebSphere Application Server environments.
The best thing about the IBM Cloud is that you can sign up and give it a whirl with absolutely no costs! Go and sign up for a free account and you'll immediately be able to spin up IBM Software in IBM's cloud. You can access and use that software, and then when you are done you can simply delete the running instance. There's no need to download anything to your computer, the interface to the IBM Cloud is completely web-based, and the launched software runs on IBM infrastructure. All of this adds up to give users a super easy way to kick the tires on some of our software. Sign up now by visiting the landing page for the IBM Cloud.