There’s often a debate in my office about what we should name our servers or projects.
Today, I had an engineer become visibly upset, bordering on yelling because I don’t like the method that he likes when it came to picking a name for a server. Maybe it wasn’t so much that I didn’t like it — but perhaps that I didn’t completely agree with his reasoning for using that particular method this time.
There are two distinct concepts about how one should name a server (or project)
1. Use functional names, so we know exactly what a server does and where it is just by looking at its name, or
2. Use a theme-based, pronounceable name
No matter what, we always end up with very committed supporters on each side of the argument.
Functional naming means that you name a server based on an abbreviation of its purpose, maybe its location, and sometimes with a number if it should be part of a cluster or farm. Indeed, functional naming is ideal when you have a large number of very similar or identical servers. For example: web01, web02, db27, db28, etc.
Some security types may object to using functional names because it may give a would-be attacker additional information about what a system’s significance may be. In reality, this isn’t an issue — if somebody can gain access to a system, they’re going to find out what it does on their own. The name of the server isn’t relevant.
Using functional names for unique servers isn’t always as effective. A single-domain environment may be perfectly suited to having its domain controller named simply dc or maybe ns, perhaps even dc1 and dc2 if you need a backup (you do have a backup domain controller, don’t you?).
But what if you have multiple domains? Say, you have a few dozen domains across a few different datacenters? You’re now faced with the task of explicitly identifying every domain controller by its domain or by including an identifier in the server’s name to indicate what domain or datacenter it’s a member of.
Multiple domains accessible and manageable by many people across several organizational units will all need to understand the naming convention so they can mentally decode it. Having many different servers named “dc1” but in different domains will create a degree of complexity that can increase the risk of damage to systems within each domain.
“Okay, I rebooted antivirus1.”
“In production or in the test environment?”
“Don’t know — I just went to antivirus1 and rebooted it…”
**a flood of production antivirus alerts come pouring in**
The argument gets round to somebody posing the question, “Why not just add an extra character or two or three to each server name?”
This, too, may seem effective on the surface. Certainly, in some deployments, this may be useful. But choosing what letter or other designation to append to a server name can be tricky. Use the physical location? Say, row and rack number? Use a designation for the datacenter it’s housed in? Sure, this is great if you have a large number of servers in a farm, but when it comes to things like virus scanners, domain controllers, and monitoring systems, not so much.
“We rebooted dc1p.”
“Wait! What?!? You rebooted the production domain controller?”
“No, it’s the one at the Philadelphia datacenter. That’s what the ‘p’ is.”
“No, the ‘p’ means it’s production.”
**a flood of production authentication alerts come pouring in**
Obviously, it would be important that everybody completely understood exactly what the naming convention was and how to correctly decode it. But your non-technical users — who may have a legitimate business need to know server names — have no concept, nor do they wish to have any understanding of server locations or often of different environments. But we can all more easily associate a name to an object.
“But why not educate the user?” you may ask. Indeed, why not force them to learn the standard?
For the same reason you don’t require them to memorize your phone number and cubicle location to get support. It simply isn’t realistic to expect people who are not technically-minded to memorize technical concepts much in the same way that it’s not realistic to expect non-neurosurgeons to memorize the names and locations of the structure of the human brain.
“But you’re lowering the bar!” No, I’m not. I’m just not setting unrealistic expectations of other people. Yes, I keep mental maps of every datacenter, row, rack, and server location, but I never expect people to have the same skillset as I do to remember things like that.
Yes, for the Engineer who feels compelled to keep everything nice, neat and numbered in a NET VIEW list, it makes perfect sense to devise a numeric/location-based naming scheme. You may want to call a server MacUtil1CorpTest.corpdomain.com because it’s an OSX Xserve, providing utility functions, the first of up to nine similar servers, in the corporate environment, used for testing, on the corporate domain.
Now, try to tell one of your internal, non-IT customers over the phone that they need to go to the web site http://macutil1corp1Btest.corpdomain.com to validate a website you want to publish before you push it to the production-level system…
“Wow, I have no idea what all that means, but I typed h-t-t-p-colon-forwardslash-forwardslash-mack-you-tell-won-corp-won-bea-test… Is that right? [click] Well… It says Server Not Found… Why does this need to be so difficult? Why is it nobody can understand you technical people?”
Your user base has quite enough things to keep track of without having so much additional complexity presented to them that they simply don’t need to know. Their expertise lies elsewhere.
One may find it would have been better to just use a name that can be spoken and relatively-easily understood by the customer, like hades.domain.com or, if they’re on the same domain as the server already, they just need to type “hades”. Done.
“Oh, Hades — like that Greek Mythology stuff — I hated that in school… H-A-D-E-S [click]… site looks great. Please publish it.” And done. We gave them a name. It’s an obscure name and references some ancient mythology that has nothing at all to do with science and reality, but it’s still a name that your customer has probably heard before. They already have a mental connection of some kind to that name, so you’ll probably spend much less time handholding them through the process.
Note: You could just set up DNS aliases and host headers to do the same thing, but then you’re also getting into the added complexity of updating DNS, creating site aliases, restarting web services — to say nothing of other services that don’t have aliasing capabilities.
Give a server a name and odds increase greatly that it will be easily remembered as useful information instead of noise or jargon consisting of random letters and numbers.
Naming Themes
So, how do we pick names?
Here are a few ideas for server names for your environments:
- Continents
- Classical Greco-Roman Mythology (my favorite)
- – Planets and their moons
- – Constellations
- Biblical references or characters
- Science-Fiction
- – Star Trek ships, characters (also a favorite)
- – Star Wars characters, planets
- – Harry Potter characters
- – Sci-Fi authors
- – Battlestar Galactica
- States (or provinces)
- – Counties
- – Cities or Towns
- Rivers
- Mountain ranges
- Fourteeners (very popular in Colorado; also for conference rooms)
- Ski resorts
- Islands (also one of my preferences)
- Island resorts
- Major world cities
- Ancient cities (Microsoft had used this for Windows projects codenames)
- Airports (general or commercial, codes or common names)
- Auto makers
- Species of tree, insect or breeds of cats, dogs, etc
I personally very much prefer using names from classical mythology. I’m not Greek, nor am I from Rome. I’m also an atheist. But the stories of Greco-Roman mythology have many corollaries to modern life and the structure of society.
So, for clusters, go nuts with numbers. Absolutely. But for unique servers in your environs, consider some actual names.
Besides, you’ll be exercising your creativity — you might even enjoy the project a bit more.
the rest of me 