What’s in a name? – The importance of naming conventions

namebookAll to often I find myself in the following situation – I’m in the midst of deploying a new service or project into our environment.  I have gone through tons of user manuals and articles, went through weeks of training and technical tutorials, successfully completed proof of concepts and pilots, yet as I’m beginning the production deployment I sit at my desk puzzled, staring into space in deep thought, perplexed by the multitude of options running through my mind over what I am going to name this server.  In the Windows world, those 15 simple characters allowed in the NetBIOS name puts my mind in such a tailspin – sure, we have our own naming conventions for servers, first three digits are dedicated to a location code, followed by a dash, then whatever, then ending in a “-01” and increment – so that leaves me now with 8 characters to describe the whatever part that I’m deploying, and in some instances, it’s those 8 simple characters that tend to be the most difficult decision in the project – even with somewhat of a server and endpoint naming convention in place.

But it goes beyond just servers and endpoints.

Sure, most companies have naming processes in place for their servers and workstations – and I’ll eventually come up with something for those 8 characters after a coffee and some arguments/advice from others.  The most recent struggles I’ve had though, apply not to servers, but to inventory items within vSphere.  There are a lot objects within vSphere that require names – Datastores, PortGroups, Switches, Folders, Resource Pools, Datacenters, Storage Profiles, Datastore Clusters…..I can go on for quite some time but you get the point.  All of these things require some sort of a name, and with that name comes a great deal of importance in terms of support.  For outsiders looking in on your environment and their understanding of what something is, as well as for your own “well-being” when troubleshooting issues – a name can definitely make or break your day.

So how do we come up with a naming convention?

boy-61171_640This sucks but there is no right or wrong answer for your environment – it’s your environment and you need to do whatever makes sense for you!  Unlike naming children we can’t simply pick up a book called “1001 names for vSphere Inventory Items” and say them out loud with our spouses till we find one that works – we need something descriptive, something we can use when troubleshooting to quickly identify what and where the object is.

Back to my recent struggle – it had to do with datastores.  For a long time I’ve had datastores simply defined as arrayname-vmfs01 and increment.  So, vnx-vmfs01, vnx-vmfs02, eva-vmfs01, etc…  This has always been fine for us – we are small enough that I can pretty much remember what is what.  That said, after adding more arrays and  a mixture of disk types (FC, SAS, NLSAS, SATA) I began to see a problem.  Does eva-vmfs01 sit on SAS or SATA disks?  Is it on the 6400 or 4400?  Is it in the primary or secondary datacenter?  Is this production or test storage?  Does it house VMs or backups?  What is the LUN ID of eva-vmfs01?  I know – most of the questions can be answered by running some CLI commands, clicking around within the vSphere client or performing a little more investigation – but why put ourselves through this when we can simply answer these questions within the objects name?

So I set out to Twitter, asking if anyone had any ideas in regards to naming conventions for datastores – and I got a ton of responses, all with some great suggestions, and all different!  So to sum it all up, here are a few suggestions of what to include in a datastore name that I received.

  • Array munufacturer/model/model number
  • Disk Type (SAS, FC, NLSAS, SATA, SCSI)
  • Lun Identifier/Volume Number
  • Destination Type (Backups, VMs)
  • Storage Tiers (Gold, Silver Bronze/Tier 1, Tier 2, Tier3)
  • Transport type (iSCSI, NFS, FC, FCoE)
  • Location/Datacenter
  • Raid Levels
  • vSphere Cluster the datastore belongs to
  • Of course, Description

Yeah, that’s a crap-load of information to put in a name – and maybe it makes sense to you to use it all but in my case it’s just too much.  That said, it’s all great information, the toughest part is just picking the pieces you need and arranging them in an order that you like.  Having something named DC1-TOR-HP-EVA-6400-FIBRE-FC-R6-VM-GOLD-CLUSTER1-L15 is a little much.

And in the end

So what did I chose?  Well, to tell you the truth I haven’t chose anything yet.  I thought by writing this post I might spark some creative thinking and it would pop into my head – but no – I’m more confused than ever.  Honestly, I’m leaning towards something like array-disktype-lunid, like EVA-FIBRE-L6 or VNX-NLSAS-L4, but I just don’t know.  This stuff is certainly not a deal breaker, but I’m just trying to make my life a bit easier.  If you think you have the end all be all of naming conventions feel free to leave a comment!  I’m always open for suggestions!

  • Rob Nelson

    Naming conventions need to capture what humans will need to interpret at a glance. Destination type and tiers? Check. Location and cluster? Check. LUNs? Probably not. Array manuf and protocols? Doubtful. RAID and Disk type? What you care about should be captured in the tiers. Of course, that’s my view – take a look at the last 50 issues you’ve had with datastores and see what information you required quickly. The things you leave out can be looked up by a human when needed, which will be infrequently, and the computer can do it automagically when required.

    The other thing to remember about naming schemes is that they’re living. You can’t write them in stone and leave them that way forever. 15 chars sounds tight? We ran into some devices that top out at 11. Which we didn’t figure out until after we standardized our scheme. Prepare for such things and be ready to adjust rapidly. Document the standard and all the exceptions, and continue to do so over the lifetime of the scheme’s use.