Complexity is the enemy of efficient and effective IT Operations

You can read a lot about the UCS architecture, but in most cases this refers to the physical component architecture rather than equally if not more important logical components.

If you’re a fan of Visible Ops, if you believe in efficient and effective operations, then UCS logical components are where the efficiency and effectiveness comes in to play.  It takes literally minutes to physically connect up a UCS system: the hard work and head scratching happens at the UCS Manager interface when you come to define your system with logical, managed objects.

Think of a sixty-four blade UCS system, where each blade can have in the region of twenty-eight or more configuration components, then you have 1792 configuration items to track.

But first, what do I mean by efficient and effective?

• Effective is Getting the Job Done, of achieving The Goal (shout out to Goldratt fans).  Objectives in the Goal should be about work rate and throughput, think Useful Work in DCeP terms, and it should also be about IT being available so the business can do its job.
• Efficient is Getting the Job Done for a Reasonable Cost. Anyone can be efficient at doing the wrong thing, and anyone can do the right thing for the wrong cost.  So being efficient is about being effective for a reasonable cost that makes Getting the Job Done a beneficial activity (in other words, benefit is greater than cost).

We know that the biggest cause of poor IT throughput and poor IT availability is mostly down to us humans.  Right?

One of the key methods of becoming more efficient and effective is to control human involvement in IT operations.  Control means reducing the amount of things a human does by either (a) not doing it, or (b) getting a reliable automated process to do it.  Control also means watching what the human does and preventing mistakes, or alerting when things go wrong.

How good are you at doing the same thing, every day, with no variation?  How good are you at remembering configurations six months after they were implemented?  How good are you at creating and maintaining documentation?  About as good as I am, I expect.

That’s why I believe that the system should be self-documenting and, as much as possible, self-regulating and self-maintaining.

And this, my friends, is what UCS logical components do.  In essence, they capture the smarts of a few people into logical, managed objects that can be used repeatedly to provide a predictable and reliable (=mature) service to the business.

UCS Logical Components (click to enlarge)

What are these objects?

• Profiles are a collection of other managed objects, such as virtual NICs, virtual HBAs, boot policies and IPMI profiles.  A Service Profile is the most important because each one of these represents a logical server.  The logical server can be imprinted on any blade and voila! Your “server” is now mobile and not fixed to any single piece of hardware.  Hardware broken?  No problem, associate Service Profile with another blade.  Bang, you’re up.  No configurations to remember.  No rebuild steps required.  No human intervention smarts required.
• Pools are like stacks of plates in a canteen.  Need a MAC address?  Go to the pool (stack) of MAC addresses and get one off the top of the pile.  There are also pools for servers (need a blade?  Don’t need a human to work out which one, just get one off the top of the pile).
• Policies are like recorded commandments that Shall Be Obeyed.  These are attached to other objects like Server Pools – a blade can only join this server pool if it has 384GB RAM.
• Objects are logical versions of their physical counterparts, like NICs and HBAs – you _could_ inherit the qualities of the physical NIC (MAC address), _or_ you can over-ride that with a logical version.
• Templates are there to make life ridiculously easy.  Fed up of going through seven screens to create a service profile?  Be Smart and Lazy and just copy from a template instead.
• Cloud objects connect you to the outside world.  VLANs and VSANs are examples of cloudy objects.

Cisco have a phrase for UCS: Wire once and walk away.  The way this is made real is through the logical components.  Get your smart compute, network and storage guys together to work out the configurations and then capture them forever in the logical objects.

There are at least twenty-eight logical components in UCS.  Imagine you had a sixty-four blade UCS system: because those logical components affect each blade, you could _estimate_ that there are 64 x 28 = 1792 configurations to deploy and track (minimum).

And the best thing about using logical components instead of having to configure hardware by hand means you can keep out of the data center – that used to be great news because the data center was freezing cold – nowadays data centers seem to run in swamp mode without cooling, so perhaps the benefit is not having to wear jungle shorts…

Related posts:

1. 25 ways that Cisco UCS frees you to do other things
2. Cisco UCS and vSphere Management: Inside, or outside?
3. Easy access to the Cisco UCS API via the Ruby UCSAPI Module