by Vinny Valdez (Red Hat)
The following is an excerpt of a post originally published on June 29, 2012, on Vinny’s Tech Garage.
I’m really excited about CloudForms. In my recorded demo at Summit, I showed a RHEL 2-node active/passive cluster with GFS off an iSCSI target. Then I moved all the underlying CloudForms Cloud Engine components to shared storage. I was able to launch instances, fail over Cloud Engine, and see the correct status. After managing the instances, fail back, and all was good. All of this works because the RHEL HA cluster stops the databases and other services first, moves the floating ip over, then starts the services on the active node. This was a very basic deployment, much more could be explored with clustered PostgreSQL and sharded Mongo.
In the demo booth at Summit I showed customers what CloudForms is, how to walk through a typical workflow, and demonstrated launching a 4-node JBoss cluster based on Scott Collier’s great Reference Architecture, which I had the pleasure of technical reviewing. I had a local RHEV 3.0 datacenter. I wanted to add a VMware vSphere 5.0 environment, too, but it didn’t support the laptop NIC, so I settled for 2 RHEL systems attached to RHEV. I know I’m biased, but the snapshot method RHEV uses is exponentially faster as more instances are launched simultaneously. Boot time of 4 instances (2GB ram each) was under 3 minutes. On my enterprise class lab hardware, just 6 nodes takes about 8 minutes to fully copy and deploy on vSphere 5.0 due to the way each VM is copied from the template. I also had my EC2 account connected, and launched instances in both environments.
So, what exactly is CloudForms? The core focus is on lifecycle management of virtual machines. However, rather than attempting to displace existing virtualization management infrastructure, CloudForms acts as an abstraction layer above virtualization and uses deltacloud to interact with VMware vCenter, RHEV Manager, or Amazon EC2 . This means customers aren’t asked to waste any investments in infrastructure. Virtual machines deployed by CloudForms are referred to as instances. One or more instances can be deployed from CloudForms and managed as a single entity and are referred to as applications. The user that launches the applications can choose which infrastructure to launch on. CloudForms has three major components:
• CloudForms System Engine – manages content, image definitions, and software updates – based on the upstream Katello
• CloudForms Cloud Engine – manages the lifecycle of images, instances, and applications – based on the upstream Aeolus
• CloudForms Config Server – provides post-boot configuration for instances – based on the upstream Audrey
If you want to get started with CloudForms check out this great overview from Jacob Liberman.
For a deployment guide with use cases, this one by Steve Reichard I also helped review.
Of course, we’ll help you get it up and going fast.
 CloudForms 1.0 supports VMware vSphere 4+/5+, Red Hat Enterprise Virtualization 3.0+, and Amazon EC2. Support for more virtualization environments are in the works.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.