Naming Revisited

Yes! It’s time for another post on naming conventions! Specifically, naming servers but there are many many objects to be named when setting up layered systems since vSphere, vCloud director etc. But lets stick to servers.

I may have stated the (obvious) requirements before but no harm to do it again. The most important rule is that names need to be:

a) unique

thats the really only hard and fast rule and is pretty obvious since you don’t want to end up with six servers all called “fred”.

Of course even that simple statement leads to my meta rule: even if the name is unique, it should also

b) sound unique.

Unless it sounds unique then when people (or alarmpoint) use the name to communicate there’s no point in it being unique. For example “unipro1” and “unibro1” are unique but rubbish since they sound the same.

The implicit assumption is that the names will be communicated orally, and I’ve never come across an organisation where that is not the case. It implies my next rule which is the word must be:

c) sayable

Now uniqueness can be got pretty easily with numbers but as mentioned before you should only use a given number once in any name. For example prodserver0001 and devserver0001 are unique and sound different but both use 0001, which to me adds a level of risk.

What information can you encode in your name? Well, it depends. On personal taste and the priorities of an organisation.  Consequently no two systems will be the same. What you need to do is decide the three most important things for you or your organisation and use codes for that. If three bits of information compromises “sayability” then go back to two and use your CMDB to hold information on your server (you do have one, right?)

As an aside, one popular system is to use proper nouns. We used Scottish Islands when I was at Uni and people use things like Simpsons characters. These systems have several drawbacks. Typically you run out of names. Some may sound the same. Most of all it is a wasted opportunity because even if you put one piece of information in a name, that’s better than nothing.

Back to codes. Popular ones are location, operating system, function, support level. If you are a virtualisation company, say, it might be important to know if a server is physical or virtual. This is an example of a scenario when two totally different naming conventions might be useful. There’s no need to squeeze everything into one size of shoe, provided there’s no danger of overlap. I would be wary of more than three systems in one org though.

Personally I like location and OS in a physical server, and whether it is Unix or Windows. Consequently I would end up with:

lonuni0001
lonuni0002
lonuni0003
lonwin0004
lonwin0005
lonwin0006
sanuni0007
sanwin0008

It would be nice to get in prod/dev/qa but it makes it unsayable but you could get creative and carve ranges out of 0001-9999.

Location is not as important in a VM so we could sneak in prod, dev, qa:

uniprod0001
unidev0002
uniqa0003
winprod0004
windev0005
wintest0006

Now you might find it hard to remember what server does what but I would always advocate creating a CNAME (without any rules) which makes sense to you; that’s what they’re for! e.g:

speeddb -> uniprod0001
vclouddir -> unidev0002

fred -> wintest003
virtualcenter -> winprod0004

dnsserver -> winprod0005
paulsserver -> windtest0006

But enough rambling from me. I really should do some proper work as the list grows longer and the solutions do not. But don’t cop out and say names are not important. They are.

If names are not correct, language will not be in accordance with the truth of things.  ~Confucius

Names are not always what they seem. The common Welsh name BZJXXLLWCP is pronounced Jackson. ~ Mark Twain.

Leave a Reply