Choosing between meaningful and meaningless hostnames

Question

Assume an environment with a puppet-managed cluster of different servers - various hardware, software, operating systems, virtual/dedicated, etc.

Would you choose meaningful hostnames (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, etc.) or would you prefer meaningless hostnames such as characters from a book or movie?

The problem I see with meaningful hostnames is that names usually represent a single service and if a server has more than one purpose it gets really messy (especially if server roles change often).

Isn't mapping a service name to an IP address and maintaining that mapping what DNS is supposed to do?

What are the advantages and drawbacks of both approaches and what actual problems have you had to tackle with the approach you chose?

Answer 1

Once upon a time I had an opportunity to decide on a naming scheme. So I went round and asked my developers, who after all were the people who had to work with these names on a day-to-day basis, whether they preferred functional names (that is, names which represent, in some encoded form, the purpose of the machine) or mnemonic names (that is, names drawn from some pre-existing human naming scheme, which contained no implicit content about the machine's purpose).

Out of 38 developers, 37 preferred mnemonic names; only one preferred functional names. So I named them all after rivers (there's a very large pool of possible names, and many of them are short, easy to remember, and quick to type).

The human brain is pretty well-designed for attaching meaning to names. If you provide names that are memorable, people will pretty quickly remember what those names are used for, and use them. If you use names drawn from some common background (eg rivers, elements, stars, counties, drinks, you get the idea) it helps people to immediately recognise a company hostname when they come across it; otherwise statements like "all the email ended up on betelgeuse" can be a bit confusing).

Conversely, my developers felt that they had in previous jobs had a really hard time remembering exactly what pr1ms001 was.

But I should add that we used CNAMEs in the internal DNS to provide a functional name to mnemonic name mapping, so if you really found it easier to remember that the main mail server at the first cluster at the PR site was pr1ms001, then the DNS would let you know that that was currently orwell. Also, that let us have many functional names per machine, so as long as you always used the functional name relevant to the function you were working on, you could be sure that pr1imap001 would always point to the IMAP server, even if we moved that functionality from orwell to rhine. And when hudson died, we could change the name of the replacement without affecting operational functions, so that we never had the "do you mean new hudson or old hudson?" confusion.

Answer 2

This largely comes down to whether your servers are pets or livestock.

Pets get individual names. They're distinct from each other, and we care about those differences. When one gets sick, we usually try to nurse it back to health. Traditionally, servers have been pets.

Livestock get numbers. They're mostly identical, and what differences there are, we don't care about and usually try to minimize. When one gets sick, we put it down and get another one. Fully virtualized servers, especially IaaS servers such as AWS, are livestock.

In most complex environments, you have a mix. Your web backends, for instance, are almost certainly livestock. If you need more, you spin up a few more with the standard config; if you don't need as many you turn some off. Your database servers, in some configurations, are pets. There may be a lot of special setup on each; you may even be running them on bare metal instead of virtualization.

Of course, in either environment, you can name SERVICES and address those directly. This is a best practice in any case; your developers shouldn't need to know or care what the actual hostname of a service is. The hostname should be a purely operational detail. Think, then, of encoding information that is useful to your ops staff in the hostnames - for instance, it's often helpful to denote which datacenter a server is in.

Answer 3

This has been covered here before...

My recommendation is a combination of functional names and mnemonic names...

If you're writing an application and it needs to address ccts-logserver1, use that name throughout, but make that a CNAME or an alias. The real hostname can be whatever you want: a fruit or vegetable, greek mythology or Seinfeld character... but it gives you some flexibility when you need to associate real functional names, but keep something that people can remember.

Think of the example where mango, the DB server fails... but is replaced with something else, say peach. Perhaps existing processes and applications need to see cmt-prod-db1. You can swap the systems, build them without naming conflicts and keep the applications (and developers) happy.

Answer 4

Where I work we manage multiple sites, multiple companies, in multiple cities. For us mnemonic names can't work. Instead we use a shorthand form that describes our servers. This works well in our case as we have some clients which may have multiple offices on different domains (or a single office on multiple domains, or multiple offices on the same domain, or all of the above!)

For us, the information contains Company/Domain, city, function, number. So for a domain controller for company, say Cypress in Chicago it would be:

CYPRCHDOM001 (We would refer to this as Cypress main DOM in conversation)

CYPRCHSQL001 would be it's SQL server, CYPRCHMGM001 would be its management (ie, anti-virus, backups, etc), and CYPRCHAPP001 would be a mixed applications server. Easy to remember, easy to sort, easy to teach.

Answer 5

The only requirement for hostnames is that they should be unique on the network.

The meaning doesn't have to only be to do with the servers function. Location can be very useful if you have to deal with physical devices. Knowing if a device is virtual or physical can also be useful. Being able to tell the difference between a network device, a linux server or a windows box can be very handy when it comes to figuring out what tool to use to login.

The way we handle it is to try and put this information into the device name as follows:

L or T - Live or Test P or V - Physical or Virtual S or N - Server or Network (we don't have any Linux servers) a sequential number to ensure uniqueness An ISO 3166-1 three letter country code indicating where the device is located.

We then use CNAMES in DNS to map various service names through to the hostname.

I have mixed feelings about this. It certainly saves time in having to look up where a certain device is located. On the other hand it is much harder to remember what a given server does when presented with its hostname, when compared to our previous system which used gemstones. The gemstones didn't imply any meaning at all, but they were easy to remember because each person could create their own connections.

I guess the only advice would be to settle on one schema as the greatest confusion arose when we transitioned from one system to the other.