Is that you in there?

Is that you in there?

An architectural and operational discussion thread surfaced for the first time in a long time in a customer meeting this week, in the form of:

A product subject matter expert said: “You want a manager of managers outside the system, like vSphere’s vCenter sits outside vSphere.”  Wrong!

Admittedly, the person talking wasn’t a vSphere expert which accounts for an incorrect statement like that (why is that statement wrong?  Because vSphere includes vCenter, for one…).

But this statement is a variation on an old topic:  ever heard the question: “should vCenter be run in a VM on an ESX box that it manages, or should vCenter be positioned outside the ESX servers on its own physical server?”

Many a poll has been run on this topic, and usually the answer is 51% say virtual, and 49% say physical.

The answer to this question has nothing to do with whether vCenter runs well in a VM (it does), it has everything to do with vCenter running inside the system it is managing.

There are no technical reasons to NOT run vCenter inside its own virtual data center.  vCenter is loosely coupled to the ESX hosts and virtual machines that it manages: that is, they can keep on working when vCenter isn’t around.  HA keeps working.  DRS doesn’t, because that’s a vCenter thang, but your system keeps working: so, the production line keeps on going if anything happens to vCenter.

If you run vCenter in a VM, and let’s get all crazy and put it in a Management resource pool on a DRS enabled HA cluster along with other Management infrastructure like AD, Logging and Monitoring, now vCenter gets the benefit of HA and all the other goodies.  You could still use vCenter Heartbeat in the vCenter VM, if you need that level of high availability.

So, if there’s no technical reason why vCenter can’t run inside its own virtual data center, and if vCenter actually benefits from it: then why not do it?

One word: CULTURE.  Our old, change-resistant foe rears its ugly face again. Here’s some common verbal clues to this enemy of reason:

  • That’s not the way things are done around here.
  • Our standards dictate that vCenter sits outside the virtual data center.
  • I read on a blog that it wasn’t a good idea.
  • It isn’t a best practice
  • I can’t get my head around it.

Get over it, everyone!  Create your Management resource pool stick all your Management infrastructure in there – EAT YOUR OWN DOGFOOD, if you are the infrastructure team – and move along, nothing to see here.  Once you’ve done this, you’ll feel great: and when you’re having post-VMUG beers you can smile when you hear that question: do you run vCenter in a VM?

I’m going to come across this foe many times in the future deployments of Cisco UCS: I can tell you that it is a waste of resource to dedicate a UCS blade to vCenter, let alone deploy it on a server outside UCS.  That’s just crazy, old, dusty, fusty thinking that has no place in today’s stateless, scalable, unified computing.

Related posts:

  1. vSphere Resource Management: a factory artifact
  2. vSphere Capacity Management
  3. Intel, UCS and vSphere: 10 advances since 2005, and why they matter
  4. vSphere VMM execution modes and Cisco UCS blades
  5. Is UCS just for vSphere? And what does stateless mean?