One of the more hotly debated topics among sysadmins is what to name servers. Some people use this as an outlet for their creativity or pop culture references. Servers named after Lord of the Rings characters, super heros, greek mythology abound. There’s a strong push from those of us who have moved past the ‘clever’ phase of our careers to name machines in logical consistent manners. web0X, db0Y, rackXpduY, all get bandied around and are debated with often the same fervor as Vim vs Emacs (vim for the record). The truth, sadly is that all the good names are taken ™©®. The grizzled veterans who’ve done time on a VAX will exclaim, “This naming scheme is crap, lets just use IPs, they are immutable.” Well for one they are wrong, ips are not immutable. Take a look at EC2, have fun with that. Second humans are bad at remembering numbers, 10 digits is the longest number most people can retain (why phone numbers are that length) and usually not for very long.
Names also provide a very important psychological edge for our poor meat brains. Names allow us to recall information in a similar way that a key allows you to recall information from a database. A message from your alert system saying ‘Alert gandalf.example.com is DOWN!’ would (in theory) trigger something in your memory. Gandalf is a wizard, that’s the master DNS server! This key isn’t as good as a more meaningful name but it’s a key none the less. I prefer names which are functional and overload information into the rest of the domain. proxy01.atl.example.com tells me very quickly this is a proxy server, it’s one of a multinode cluster, likely load balanced, and is located in Atlanta. All of this allows me to asses the situation at hand faster. All of the pertinent details should be written down in a wiki, or some other document source, but the naming gives me a fast way to access that without having to go look it up. 188.8.131.52 is DOWN only tells me something is broken, not how important, how impacting or anything about it. Maybe that’s a dev box or 1 node in a 40 node cluster, but I don’t know that (unless I just memorize it which stresses the meat brain) until I look it up.
Consistency is the key, I don’t in general like ‘clever’ names not because they are unprofessional or silly, but because they only mean something to the person who came up with it. I know why I named the database ‘pearl’ (bonus points to anyone that guesses), but my other team members might not and likely that someone coming behind me wouldn’t either. I’m a huge fan of code names and clever names for software / service names / etc just not machine names. Here are some of the conventions I use.
Multinode clusters are numbered 2 digit starting at 01.
10 servers in a web cluster, web01 – web10. Using 2 digit precision gives you 99 machines before you end up changing field sizes.
Short hostnames are the most common functional purpose.
Sometimes it’s ok to call it a server and put more information into the sub domain. ‘Web’ in general sucks, it’s too generic and means very little, what does it ‘do’.
If you think they’ll be more than one, name it 01.
Don’t use a sequential numbering system for unrelated things.
If you have two webservers that serve different content/services/etc don’t name them web01 / web02. This creates a logical grouping of those two machines which are not actually tied together from a service standpoint. I’ve heard of shared filesystems being named fs01, fs02, fs03, fs04, etc. They aren’t related other than that they are all shared filesystems, why are you grouping them into something that looks like a cluster. People assume that 1 is related to 2 to 3 to 4. Put some thought into it and give it a name based on what it does or what’s important about it.
Use A / B notation for duality relationships.
I name my netapp filers: filer01a / filer01b. They are both addressable services but provide failover for each other. There will never be a ‘c’ since netapp doesn’t support wheel based failover. They are a matched set, so they are named as such. A vs B gives less cardinality than 1 vs 2 and that’s a good thing.
Use subdomains in a consistent manner to produce a lightweight hierarchy of information.
proxy01.www.internal.nyc.example.com lets me denote physical location, security context (internal), content type (www), and functional purpose (proxy) all in one name. Granted this assumes a high degree of machine / service separation and may not work for everything, but you can use that name to store quickly accessible information.
Order is important, remember that.
In english we read left to right. Information is ordered in that direction as well. Put the thing you care about most (or quickest) to the left and less immediate information flows to the right). database01.hr.alt tells me it’s a database (important!), it’s part of a cluster (less important than being a db but still relevant), HR database (eeek will I get paid?!), and finally location which may not matter (alt is a backup site, I can deal with that later). Order frames your response into the correct context. database.atl.hr.clusternode1 tells me this machine is a database (important), in Atlanta (wait that’s the dr site I might not care right away), it’s HR (wait we don’t have a primary b/c it died last week), and that it’s a clusternode. Is this better or worse? Depends on the context, order is important.
The crux of the whole point is that names are useful things, humans name things not because they want to be clever but because it’s an effective way to partition information about something without having to memorize it all. It comes down to the difference between knowing something and memorizing it. You design a convention and stick to that convention until it doesn’t work, then you redefine that convention. The convention saves you time but only if everyone ‘gets’ the convention or it can be easily explained. If your convention is a complicated scheme involving lollipop guild chairmen’s you are requiring the audience to have immediate intrinsic knowledge of Mid 1930’s Judy Garland films, which is the same as asking them to look it up.