July 24th 2012 Update:
August 5th 2011 Update:
While still relevant and accurate, the information on this page does not reflect the latest information about the now Apache 2 released Crowbar code. In the 4+ months following this post, we substantially refactored the code make make it more modular (see Barclamps), better looking, and multi-vendor/multi-application (Hadoop & RHEL). If you want more information, I recommend that you try Crowbar for yourself.
Original March 14th 2011 Text:
I’ve been getting some “how does Crowbar work” inquiries and wanted to take a shot at adding some technical detail. Before I launch into technical babble, there are some important things to note:
- Dell has committed to open source release the code for Crowbar (Apache 2)
- Crowbar is an extension of Chef Server – it does not function stand alone and uses Chef’s APIs to store all it’s data.
- The OpenStack components install is managed by Chef cookbooks & recipes jointly developed by Dell, Opscode and Rackspace.
- Crowbar can be used to simply bootstrap your data center; however, we believe it is the start of a cloud operational model that I described in the hyperscale cloud white paper.
Here’s what you need to know to understand Crowbar:
Crowbar is a PXE state machine.
The primary function of Crowbar is to get new hardware into a state where it can be managed by Chef. To get hardware into a “Chef Ready” state, there are several steps that must be performed. We need to setup the BIOS, RAID, figure out where the server is racked, install an operating system, assign IP networking and names, synchronize clocks (NTP) and setup a chef client linked to our server. That’s a lot of steps!
In order to do these steps, we need to boot the server through a series of controlled images (stages) and track the progress through each state. That means that each state corresponds to a PXE boot image. The images have a simple script that uses WGET to update the Crowbar server (which stores it’s data in Chef) when the script completes. When a state is finished, Crowbar will change the PXE server to provide the next image in the sequence.
During the Crowbar managed part of the install, the servers will reboot several times. Once all of the hardware configuration is complete, Crowbar will use an operating system install image to create the base configuration. For the first release, we are only planning to have a single Operating System (Ubuntu 10.10); however, we expect to be adding more operating system options.
The current architecture of Crowbar (and the Chef Server that it extends) is to use a dedicated server in the system for administration. Our default install adds PXE, DHCP, NTP, DNS, Nagios, & Ganglia to the admin server. For small systems, you can use Chef to add other infrastructure capabilities to the admin server; unfortunately, adding components makes it harder to redeploy the components. For dynamic configurations where you may want to rehearse deployments while building Chef recipes, we recommend installing other infrastructure services on the admin server.
Of course, the hardware configuration steps are vendor specific. We had to make the state machine (stored in Chef data bags) configurable so that you can add or omit steps. Since hardware config is slow, error prone and painful, we see this as a big value add. Making it work for open source will depend on community participation.
Once Chef has control of the servers, you can use Chef (on the local Chef Server) to complete the OpenStack installation. From there, you can continue to use Chef to deploy VMs into the environment. Because Chef encourages a DevOps automation mindset, I believe there is a significant ROI to your investment in learning how this tool operates if you want to manage hyperscale clouds.
Crowbar effectively extends the reach of Chef earlier into the cloud management life cycle.
3/21 Note: Updated graphic to show WGET.