Initially when I was asked to blog about out-of-band management I thought to myself, as most people would, “this is too basic!”  What new thing could I cover?  Generally speaking, out-of-band management, like management in general, is an afterthought.  With that typical attitude, we make the mistake of placing low value on access to our network devices, seeing it as a simple back door when in reality it could provide so much more.

The idea of creating the Cumulus® RMP (Rack Management Platform) came about after talking to several customers whose approach was to purchase low-end switching platforms to meet their out-of-band management needs.  These closed network platforms provide such limited feature sets that it’s easy to dismiss their usefulness.  The team sat down and came up with the idea to “complete the rack.” Why not provide the same open networking capabilities that Linux servers and Cumulus® Linux® switches offer for out-of-band management? Thus Cumulus RMP was created.

Typical deployment scenarios

In general there are two basic scenarios when it comes to out-of-band management.  The first provides a simple but versatile L2 flat design leveraging VLANs to manage the switches and servers in the rack.  The Cumulus RMPs would then aggregate to an L2 upstream switch. This design would work best in instances where an economical solution takes precedence over a highly available one.  The second scenario is more robust and would entail dual-homing the RMP upstream to two core devices via an LACP bond.  In this case, an L2 to L3 transition could take place limiting the L2 domain.  David Sinn, one of our CSE’s, created a Cumulus RMP solution brief that covers this in greater detail.

Scenario 1 and 2

 

The value of “completing the rack”

Typically when out-of-band management platforms are considered, connectivity is the main concern without consideration of other options one may have.  The RMP platform is unique as it expands the capabilities of the out-of-band network by providing an open networking environment.  So what’s that really mean to the end user?  First, the entire rack can be managed using the same set of Linux tools used to manage the servers and the top of rack (TOR) switch.  IPMItool can be used to gather statistics from the platforms, and it can power-on or restart servers.  Ganglia, Graphite, and collectd can be used to monitor attached devices.  The possibilities here are incredible; providing an open networking environment also allows one to use widely known orchestration tools like Ansible, Puppet, Chef, and CFEngine.

Default configuration

The default configuration of the RMP platform when it arrives will look something like below.  It’s relatively simple but can be modified from its current form.  The idea is to provide an out-of-band platform that can be dropped in place and simply provide connectivity to attached devices out of the box.

configuration-code-snipit-01

A recent demo showcasing the RMP went something like this:

The management switch was plugged into the network similar to scenario 1 mentioned previously.  It received an IP address, and then to demonstrate the management capabilities, it began to manage the Cumulus Linux TOR and attached servers.  The RMP provided a local DHCP/Web server allowing the TOR to use ONIE to install the latest version of Cumulus Linux and ZTP (Zero Touch Provisioning) to modify the hostname and configuration.  IPMItool was then used to demonstrate the control over locally attached servers.

The power of open networking

You don’t have to be a Linux junkie to understand that providing a consistent look and feel across the data center makes sense.  The ability to use tools that are familiar and already in use can now be extended to the out-of-band management platform, the Cumulus RMP.  Those who choose to “complete the rack” can enjoy the many advantages and the incredible power that open networking provides.

Please register and join us to learn more in our May 27 webinar, “Using Linux to Manage the Entire Rack.”