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.