This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

17 Answers
17

First off, anyone picking a naming scheme should read RFC 1178 - "Choosing a Name for Your Computer". People have been talking about this issue for as long as computers have been given names, so read up on what others have said before re-inventing the wheel.

My own thoughts - I tend to break up naming policies into themes and schemes.

Using a theme (e.g. greek gods, characters from Dr. Who, brands of vodka) works well in a small network. If you have less than 20 hosts then chances are you have multiple hardware configurations - possibly every host has a unique configuration. In such cases it's good to be able to think of each machine as having a unique personality, because - chances are - it does.

Using a scheme (e.g. a name constructed from elements of the geographical location, rack position, hardware ID, etc) works well when you have large numbers of machines with identical hardware and/or software configurations. It also works well if you'll need to be communicating about the machine with people who don't deal with it on a day to day basis. For example if you need to tell NOC staff to reset a machine, a name which helps them locate it in the rack can be better than having them search through the racks for a machine with a particular label.

Using a functional name (e.g. mail, web, fileserver) is a good idea for virtual machines, but a bad idea for physical hosts in my experience. Physical hosts will often end up performing multiple functions (even when this is not ideal), and individual functions will change in resource usage and requirements over time, such that they will be migrated to other hosts.

The problems with themes include:

They generally provide a small pool of names. Once you run out of Roman gods, do you switch to Greek? Do you reuse a name from a retired host which fits your naming theme, or pick a new name from a new theme to avoid the problems and confusion that can arise from name reuse?

They let your anthropomorphise your machines. That's bad - computers don't like that. If you treat your machines as though they have a distinct personality, you run the risk of ignoring evidence that is counter to your assumptions about how that machine "behaves", as well as sometimes assuming that a fault lies with a particular machine because "it's always misbehaving".

The problems with schemes include:

They result in hostnames that are harder to remember. This is much less of a problem when you have good systems management in place, but it's sometimes useful to be able to instantly recall that a particular problem has manifested more than once on a particular machine, or that a particular machine is the one responsible for performing some particular function.

If the scheme changes, you may have to rename all of your hosts. This could result in
a large number of DNS changes, configuration changes, access list and permissions changes, etc.

In the real world you find both systems in use, sometimes side by side. For example, in my experience high performance computing clusters always have names. The name is often assigned to a head node (which is used interactively), while the various cluster nodes will have names such as compute-01, highmem-01, storage-01, etc.

And, as mentioned earlier, it's common (and useful) for virtual machines and physical hosts to have different naming schemes.

I'm a VERY strong believer in naming physical servers by their location (i.e. country-code/city-code/data-centre-code/floor/rack/rack-U-height) and software/VM servers by their function only (platform/function/cluster/iterance). I know this can make names longer than naming them after the seven dwarves or whatever but it's a great way of ensuring that you're more 'future-proof' and deals with virtualisation in a structured manner.

As an example we have VMWare servers called 044LONTH72G216 (this locates a server exactly in the world) with guest server VMs such as NESQLC11S08. You can always create short names for them for internal IT team work each referring back to these longer, more organised, names.

We began by naming our servers with a particular theme (books of the Bible), but as our IT team (and the number of servers) grew and became more specialized - and as we had more staff turnover, we discovered that any naming system that didn't somehow relate to the function (or location) of the server became confusing.

People knew the servers they worked on regularly, but when working on a new project, cross-training, or trying to help another admin with something, things would get missed because "nobody knew that psalms was a mail server" or the like.

I try to avoid doing this as much as possible as its a pain if servers ever change purpose, you lose track of which server was which. A lot of servers have multiple purposes also.
–
Adam GibbinsMay 3 '09 at 20:38

2

If a server changes purposes, it should probably be reformatted (and hence renamed) anyways.
–
PortmanMay 4 '09 at 1:40

4

That's something you can have as CNAMEs. The A-record should be unique to the host and not say anything about its function. Users shouldn't need to know A-records, only CNAMEs imo.
–
Commander KeenJun 3 '09 at 7:53

1

Taken to the extreme ... someone named an entire domain RTC-2k. RTC was the domain, and 2k was because ... it was a 2000 domain. Now all the clients and domain are bound to RTC-2k which makes no sense to users or new admins. Name a server by what it does, not by what it is.
–
Joseph KernJun 22 '09 at 13:09

In my experience, servers with non-human-readable names (i.e. the scheme method) are not manageable. I've often seen mistyped characters resulting in the wrong server having operation xyz applied to it, sometimes with disasterous results.

A human readable name with associated metadata stored in a description field or similar seems to be less prone to PEBKAC issues.

We started with Bert and Ernie back in the days when a cluster of 2 microVAX 3400s was a big deal for the company. We stuck with Sesame Street for a while - Bigbird, Elmo, Grover, thecount (financial system), but eventually had to go with a scheme. Exactly what elements are in the scheme depend on the size of your company, we had to include:

Location (2-letter abbreviation for the city)
Division (company was formed by merging 4 co.s, so we had 3-letter abbrev. for those)
Function (PDC, mail, print, www, etc.)
Serial number (I've always liked having year and month as part of a serial number)

Had a client once who named servers after Playboy bunnies. That was not widely publicized outside of IT, however. ;-)

I liked naming them after large cats, but then OS X came along and ruined that for me.

Another fave is types of alcohol. JimBeam, Beefeater, Stoli, etc. Different classes of alcohol were different classes of server. Gin for mail servers, whiskeys for databases, the PDC was always Moonshine.

Starting with any new systems this year, we'll start using boring descriptive names (mail, print, etc.), but until now we used animals - with different types of animals for different purposes: birds, fish, jungle animals, etc.