How To Name Servers
July 18, 2008
How do you go about naming servers? The neophyte might say, “name the server for the job it’s going to do.” The journeyman might say, “name the server for its location - it might have more than one job”. The experienced sysadmin says this:
Name your servers something memorable, simple, and unique - but unrelated to service or location.
Why is this? Because experienced sysadmins know that nothing stays the same forever. If you name a server after the service it runs (Exchange-1) then when you change things, the name becomes non-sensical and confusing. If you name it after a location (Durham-427), when the server is moved the name becomes misleading. On Unix machines, changing the name is relatively easy, unless you’ve done something like point people to it via DNS for a website: exchange1.example.local. On Windows machines it pretty much requires a re-install to get it right. Even seemingly simple naming “schemes” quickly become complex and meaningless unless you have the “key” to their designation - and people always want to add the server’s job to the scheme, which leads back to the name being misleading after a while.
Example: My old company bought a piece of another company. They had a lot of hardware. We ended up shutting down their entire site, and moving everything to Durham. This caused all kinds of confusion in machine naming. some of their servers had names like ABC123-ABTU4, which were meaningless and hard to remember. What do all those letters and numbers mean? Can you remember off the top of your head? Exactly. Others had the same name as machines we had (exchange1), which is ALL KINDS OF BAD in the Windows world - we ended up re-installing them for no reason other than their name.
Memorable: I usually pick a broad theme like video game characters or ancient gods (traditional). For larger sites, a short string will usually do the trick, especially if the first part is a good mnemonic. Anything will do, as long as when you go to talk to someone about the server, they know what the heck you talking about and can remember it. Compare:
“Hey Joe, did you track down the disk problem on MAILA33-DAL yet? No, A33. Yeah, it was moved to the Fort Worth office three months ago. Yeah, he’s a webserver now. Ok, thanks.”
“Hey Joe, did you track down the disk problem on Artemis yet? Ok, thanks.”
“Hey Joe, did you track down the disk problem on alpha-472 yet? Ok, thanks.”
Simple: At 3AM, it’s going to make you angry to misspell Nyarlathotep for the third time trying to SSH into the box. Apply the KISS principal intelligently.
Unique: This is is a lot easier to achieve than you might imagine. Even a four-character string has a lot of uniqueness; probably more than any company or group except the very largest will ever need. Anything more than that and you’re golden.
Once you’ve got names like this, you can then use DNS to assign service names at will. mail.example.com is an alias for Ryu (or Itchy, or alpha-472). The machine name stays the same forever. This vastly simplifies a lot of things - inventory, physical moves, re-imaging, management: all made easier by an independent server name. It’s especially important with OS installs like Gentoo, which will never be re-installed again if you can help it. People learn machine locations, and can easily transition their mental image when it inevitably gets moved. There is never any confusion between the name of a server and the services it provides or its location, giving you the flexibility to move things around at will without your users being impacted in any way - they always just go to mail.example.com and all is well. You can even tie DNS aliases to physical location (row6u17), and adjust DNS as necessary when things are moved.
Now of course, name collisions between companies can still happen, and people can still choose bad names. But it’s a lot less likely if your naming themes are different, and easier to deal with, since changing the machines does not involve user re-training. Happy naming!
July 19, 2008 at 2:46 pm
I used to be a firm believer in friendly names, but having seen a large(r) site with multiple clients, I’ve changed my mind, at least under certain conditions.
The key advantage of functional names is that they can include metadata. Say you have 5 web servers for Foobar International in RTP - if you choose a functional naming convention (say, rtpfiweb01-05), the hostname alone contains several pieces of information:
1) It tells you where the machine is (RTP)
2) It tells you what the client is (fi)
3) It tells you what the machine does (web)
4) It tells you that the machine is one of a number of related machines (05)
5) It tells you how to find those other related machines (by modifying the sequence number).
Now, sure, you could look all of this up in the documentation if you had to, and if you work with the site on a daily basis you’ve probably got it all memorized.
But what if your NOC technician or junior admin gets an alert at 3 am? The functional name reveals everything he needs to properly route his call. There’s no question - if he knows how to read the hostname, he doesn’t need to look anywhere else.
Now, I still like friendly names for small sites, where there are few sysadmins and few servers. In such a situation, it’s absolutely normal for services to move around or are added - “bombadil” may do 10 different things with no logical relationship between them, at which point functional names are impractical. But in large sites - where machine purposes are narrowly defined and largely immutable (until a machine is entirely repurposed and rebuilt, at which point it’s also renamed) - functional names can work quite well.
July 20, 2008 at 12:49 pm
That’s exactly my point - things get moved around, and the metadata is then wrong, and not easy to fix. Servers are only immutable as long as they don’t move … and, inevitably, at some point they get moved. Now your machine name is misleading, and if you rename the machine, other records become misleading because now they have the wrong name.
The names don’t have to be friendly. Larger sites can use generic names, like alpha-472, and dns aliases to define the “rtpfiweb01″ style of information - so that when it changes, a rebuild isn’t necessary. If the warning emails aren’t giving enough information to identify the machine immediately, that’s another problem. :)
July 26, 2008 at 10:11 pm
My recommendation is to have a name for the machine that won’t change, and then add aliases for services. Move the service? Move the alias.