The design options grow with vCenter 5

vCenter deployments are likely to change for large companies as they upgrade to vSphere 5.  Traditionally vCenter has been installed in one of two designs.  The primary decision was whether to split off the database onto a second server.  Smaller shops simply installed vCenter and MS SQL (or even MS SQL Express for the very small) on the same server.

Medium and large organisations commonly split out the database onto a separate server; their vCenter server is dedicated. As we know, larger companies like to divide out applications and databases onto their own server instances.  This is done for several reasons, not least to help scale up to heavier workloads.  So I think its fair to say, in most medium and large implementations, this is the “classic” vCenter deployment:

Now for very large deployments, some companies create a third separate server for the vCenter Update Manager (VUM).  This was particular important for anyone using the VM guest OS patching feature, as that capability could consume significant resources for a vCenter which managed lots of VMs.  However this guest OS patching was never a particularly popular feature with large enterprises, as they usually already had a working patch solution that they stuck with.  When VMware announced with the release of vSphere 4.1 that it would remove the guest OS patching feature in the next iteration, it really put the nail in the coffin.  So I’d postulate that this 2 server model is the one that the vast majority of vSphere users have at the moment.

So what’s new?

vSphere 5 comes with many more components which you now need to consider (new ones in blue):

• vCenter itself
• vCenter database
• vSphere Update Manager (VUM) – note the vCenter > vSphere name change with v5 for VUM
• VUM database
• vSphere Web Client (* see note below)
• ESXi Dump Collector
• Syslog Collector
• AutoDeploy
• Authentication Proxy

With so many separate components, many deployment possibilities exist.  Arguably the largest of deployments can do this:

However, I think the most likely candidate for the Next Generation, is something modelled around a 3 server deployment for the larger deployments.  Companies can choose which additional components they might want and selectively install them on a Components Server. (Smaller companies can obviously consolidate services as they see fit across 1 or 2 servers)

Personally I think very large organisations with the most demanding of vSphere infrastructures are more likely to scale-out to multiple vCenter instances using Linked Mode, instead of further splitting this 3 server model.

The new Linux based vCenter Server Appliance currently has two limitations which will restrict its adoption in these larger deployments:

• No Microsoft SQL support
• No Linked Mode

Once these are overcome we’ll see an even more diverse mix of designs.  vSphere architects will be able to slice-and-dice with more efficiency, and scale as required in a more dynamic fashion.  For now I think we’ll see this 3 server design become de rigueur.

Note *

The Web Client has a “service” component that should be installed centrally.

The RC version of the vCenter Server and Host Management PDF states:

VMware recommends that you register a given vCenter Server system

with only one vSphere Web Client instance

Once this service is installed, it has to be registered via a browser (with Flash) on the server that it’s installed on.  It cannot be registered remotely.  I’m not sure how good I feel about having to install Adobe Flash alongside my critical vCenter components just for this registration step.