Why use the Datacenter object in vCenter?

This a response to Gabrie van Zanten’s question – Design question: Why vCenter Server Datacenter?

To summarize, Gabe argues that the datacenter object in vCenter creates artificial limits on his operational abilities and asks why he shouldn’t just use folder objects across sites. Gabe postulates that perhaps the default for our designs should be to avoid multiple datacenter objects.

There are several reasons to use the datacenter object in your design. Primarily it’s there as a logical container for items that you want to create limits around. Yes, that’s right, you want to artificially limit mobility in the design because you recognize that those items have characteristics which should be contained. A folder object can contain those same sub-objects, but it’s precisely because you recognize that the physical equipment represented in the containers are best grouped together that you use datacenters.

To recap, the vCenter hierarchy is important for many reasons. Quoting from our VMware vSphere Design book:

The inventory structure creates a delineation that serves a number of purposes. It helps you organize all the elements into more manageable chunks, making them easier to find and work with. Monitoring can be arranged around the levels with associated alarms; events trigger different responses, depending on their place in the structure. You can set security permissions on hierarchical objects, meaning you can split up permissions as required for different areas and also nest and group permissions as needed. Perhaps most important, the inventory structure permits certain functionality in groups of objects, so they can work together.

It is not only VM mobility that is contained within a datacenter object. If you switch views in the vSphere client to Storage (called Datastores in the Windows client), you see datastores and datastore clusters are contained within a datacenter. You can create folders in there, but they are distinct to that view. Datacenter objects span each view. If you switch to the Networking view, datacenters are the containers for vDS and Port Groups. There’s a reason for this. The crux of datacenter objects, and what they do for you over and above folders, is logically explain where the network and storage boundaries are (and by association, host boundaries as well). Your design identifies these physical confines and implements it in vSphere using these logical objects.
– Where will you stretch your layer 2 networks?
– How far are you going to stretch your VMs from their storage (IP and/or FC)?
When you design your vCenter hierarchy, these choices are affected by things such as bandwidth, latency, storage fabric topology, etc.

If you recognise a datacenter as a separate physical location, then in the majority of cases you’ll split the location’s components into a separate datacenter object. There are certainly cases where this decision becomes less clear – for example, a campus-style design, where server rooms are only a couple of kilometers apart.  The rooms are commonly recognized as two distinct sites (or not), but it’s feasible that with the right dark fiber links you could logical treat this as one datacenter. To quote from the vSphere Design book again:

Remember that despite the moniker, a datacenter doesn’t necessarily have to align with a physical datacenter or server-room location. However, network and storage connections do tend to be determined by geographical location, so it’s common to see this parallel used.

You can stretch layer 2 networks and storage across much larger distances, and this can provide very interesting highly available solutions, but this requires a substantial amount of planning. For example, during regular operations you don’t want your VMs’ disks on the remote storage array.

The vSphere datacenter object should be used in your design precisely because of the limitations it creates on your operational mobility. Without them, if you elect to only use folders, then you’ll need to create extremely complex operational processes to prevent problems. So I say, “by default, use datacenter objects to represent your datacenters” – they’re essential constructs in your design.


3 thoughts on “Why use the Datacenter object in vCenter?

  1. brilliant explanation. I got a question for you FORBES GUTHRIE. I got multiple sites and each sites has got a 5 hosts at the movement and they may grow to 10/site. We have vcentre for every site manging the hosts in the site. What i’m planning t do is, instead of having multiple vcentres across 5 sites, why not use single vcentre and add the each site as a datacentre with in the vecntre? will this work? is it a best practice? what are the pros and cons? what are the advantages of having multiple vcentre servers? adding DC to a single vcentre creates lots of traffic from host to central vcentre server? what sort of BW we should look for for every host we add?FYI we got site to site VPNS across all sites.


    1. Hi Reddy, that’s a lot of sub-questions 🙂
      I can’t really do it justice without knowing a lot more about an environment (yeah, “it depends”), but here’s some quick responses:
      Why not use single vcentre and add the each site as a datacentre with in the vecntre?
      Perfectly feasible. That’s the way I’d start and find reasons not to. I’d regard this as a more typical model.
      What are the pros?
      Less licenses, less vCenter servers, less DB servers, only one copy of any tools you have which talk to vCenter, etc… Single point of management. Less is more.
      The Cons? What are the advantages of having multiple vcentre servers?
      Not many. Less reliance on WAN if you regularly experience outages and local staff need to manage hosts and need vCenter-only features during those outages. If you have extremely high latency WAN links (e.g. satellite links) then you might want to for performance reasons. If you have a very compex AD/permissions setup maybe.
      Adding DC to a single vcentre creates lots of traffic from host to central vcentre server?
      Nope, that shouldn’t overload it. The hosts won’t regularly talk to the DC, just to vCenter.
      What sort of BW we should look for for every host we add?
      I don’t have an exact number, I’d be guessing. Very low to be honest. Most of that is performance roll-ups which could be disabled if you are concerned. To test, measure WAN usage – move one remote host to the central vCenter – measure again – extrapolate.
      HTH, Forbes.

  2. Nice. I’m new to all this vmware stuff, and this was a question I had…”why not use folders instead of datacenters?” This post answered clearly of what to think about when designing. Thanks for the awesome answer/explanation!

Leave a Reply