Choosing between meaningful and meaningless hostnames [closed]

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?

Solution 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.

Solution 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.

Solution 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.