The State of Statelessness: Cisco UCS vs. HP Virtual Connect

Apr. 5th, 2010

One of the many industry buzz words these days is “Stateless”. Unfortunately, even within data center technology circles, the term “stateless” or “stateful” can refer to many different things.

In this blog post, the “state” that I am referring to is the “server configuration state”… defined as a collection of settings and identifiers used for deploying a new server in the data center. What the “state” ends up representing is the “identity” of a particular server. The identity of a server is not just an IP address or a hostname. That’s about like saying that my identity is “M. Sean McGee”. No, that’s not my identity; that’s just my name. My name is one of many things that make up my identity. Other things that make up my identity are: mailing address, email addresses, family & friends, likes & dislikes, hobbies, social security number (ugh), telephone number, certifications, etc. The collection of all those things makes up my identity. It’s the collection of those things that, together, make me very unique from every other human on the planet. It’s the same with a server.

A server’s identity is made up of a collection of configuration settings on the server hardware, as well as, the configuration settings on the network and storage devices that it’s connected to.

As an example, see Figure 1. This server’s identity is made up of its RAID settings, disk scrub settings, number of HBAs, HBA WWNs, FC boot parameters, HBA firmware, FC fabric assignments, QoS settings, NIC speed, VLAN assignments, number of NICs, NIC firmware, remote keyboard/video/monitor IP address, server UUID, boot order, IPMI settings, BIOS firmware, BIOS settings, etc. I think you get the idea. It’s a LONG list of “points of configuration” that need to be configured to give this server its identity and make it unique from every other server within your data center.

So where are all those points of configuration kept in your environment? I would imagine that some are kept in the hardware of the server itself (like BIOS firmware version, BIOS settings, boot order, FC boot settings, etc.) while some settings are kept on your network and storage switches (like VLAN assignments, FC fabric assignments, QoS settings, ACLs, etc.)

Let’s play “what if?” for a minute.

What if you could keep all those settings in one place instead of 15 different places?
What if you could configure all these settings independently of the physical server?
What if you could assign this identity to any physical server with the click of a mouse?
What if you could replace a failed motherboard and NOTHING changed from the perspective of the OS?
What if you could replace a failed HBA without bugging the SAN admin to re-zone new WWNs?
What if you could stop paying for 4 hour server hardware warranty because you could failover to a spare physical server with a click of a mouse and an OS reboot?
What if you could do all this remotely from Aruba while your servers are in Alaska?

Would any of these “what ifs” simplify server deployment in your data center? Or minimize ‘fat fingering’ during configuration? Or help with troubleshooting at 3 am? Or…<gasp>… reduce costs? I definitely think so. Then again, I may be biased. JLet’s go back to “stateless”. Within the context of this discussion, “stateless” means that the physical server doesn’t own the server’s identity. The architecture owns the identity. The identity is assigned to a physical server to use until the admin decides to move the identity to a different physical server. Since the physical server doesn’t retain any ‘state’ for any particular server identity, the servers are said to be “stateless”.

Side Note: Boot from SAN helps complete the ‘stateless’ scenario. If you are booting from local disks, your server is not truly stateless since there is a state stored on the local HDDs. You don’t HAVE to adopt BfS, but you give up some benefits (like replacing a failed server in Alaska with a click of the mouse while lying on the beach in Aruba). As a result, many customers find that migrating to boot from SAN allows them to fully utilize the power of ‘statelessness’.
Cisco Unified Computing System (UCS) servers are considered “stateless”. UCS provides the ability to manage a server’s identity as a single object called a “UCS Service Profile” (see Figure 2). A single UCS Service Profile is created, configured, and then assigned to a single physical server. The UCS Service Profile contains the ‘knobs and buttons’ related to the identifying information for that physical server – from the network and storage configuration to the RAID configuration to the firmware versions used for BIOS, NIC adapters, HBA adapters, etc. See Cisco UCS Service Profile Demo.

Now that we have level set on what “statelessness” means and what a Cisco UCS Service Profile is, it’s time to tackle the topic: Who does “statelessness” better? Cisco or HP?

HP was the first mainstream x86 server vendor to deliver the concept of managing a portion of a server’s identity using something called a Virtual Connect Server Profile. (Side note: As a former engineer in HP’s BladeSystem development group, I participated in the design and delivery of Virtual Connect.) Virtual Connect allowed the server admin to assign VLANs and MACs to NICs, WWNNs and FC fabrics to HBAs, configure FC boot parameters, and assign serial number and UUID.  This was a good start… but what about the rest of the server’s identity? What about the rest of the server’s “state”? What about BIOS/NIC/HBA/iLO firmware? What about IPMI or advanced NIC settings or QoS or boot order or RAID settings or NIC Teaming or all of the other items that I have to configure in conjunction with the deployment of a server?

Cisco delivers at least eight times the number of managed settings in a UCS Service Profile when compared to what HP delivers in a Virtual Connect Server Profile.

Here’s the comparison chart (updated 2010-08-27):

Click to Enlarge

In all honesty, I am sold on the usefulness of statelessness. I’ve seen it deployed with huge success at a multitude of customers over the past several years. Centralizing AS MANY server configuration ‘knobs and buttons’ can only lead to quicker, more efficient, and more error-free server deployments. This allows the Server, LAN, and SAN teams to effectively coordinate the roll out of a new server with minimal effort. No one has to go look in 15 different locations to collect all the configuration information for a server to make sure it was done right or to troubleshoot a problem down the road. Cisco’s UCS Service Profile delivers this capability to customers today and delivers more than 8 times the features than HP.  And… we’re just getting started, folks. J

Apr 5th, 2010 | Posted in Cisco UCS