82

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?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
keymone
  • 958
  • 8
  • 10
  • 10
    If you control DNS, you can can always do both. – jscott Feb 18 '13 at 14:05
  • 18
    I'll just leave it here: [RFC 1178](http://tools.ietf.org/html/rfc1178) – gelraen Feb 18 '13 at 14:17
  • 1
    Though superficially an opinion-based question, the actual answers are fact-based with empirical polling and based on human cognitive function (how the human brain remembers things). In my opinion this question should be reopened. – dotancohen Apr 07 '15 at 08:46

5 Answers5

99

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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • thank you, i'll wait for answer from another camp and see which one i'll accept(although i'm not sure this question has right or wrong answer) – keymone Feb 18 '13 at 14:13
  • @MadHatter: presumably a decent idea, if the structure of the naming scheme is documented and published to the end-users. Otherwise those names just suck because one doesn't have anything to associate it with. We have that situation at the moment because our operations team uses such mnemonic names but doesn't disclose the underlying scheme. – 0xC0000022L Feb 18 '13 at 14:24
  • 7
    You might think that, but my developers said that the mnemonic scheme was better whether or not anything much else was communicated, because they all built their own internal state tables of what was where, and that sort of memory is easier to build on names that the human brain likes to remember. – MadHatter Feb 18 '13 at 14:25
  • Just a +1 as we use the same thing here, but don't restrict ourselves to one grouping (like rivers). There's been human names, the seven dwarves (from Snow White), and other names from popular cartoons. So we also never have the problem of "old `foo` or new `foo`?" - we never repeat the names. – Izkata Feb 18 '13 at 15:14
  • 11
    You should have named them after volcanoes in Iceland. – Chloe Feb 20 '13 at 04:50
  • 2
    +1 for "pool of rivers" ;) – Konerak Feb 20 '13 at 07:18
  • I do this exact same thing (mnemonic name for the machine, CNAME for the function) because I used to have some hassles migrating functionality/upgrading servers. This way you can use one name to refer to the metal, another to refer to the function. Usually, customers only see the functional names because they only care about function, not about the metal. – drxzcl Feb 20 '13 at 21:33
  • Philosopher names are cool. – Laurent Couvidou Feb 22 '13 at 23:57
  • 2
    This is an awesome idea, and I'm stealing it. – SpacemanSpiff Feb 28 '13 at 02:13
  • If you're naming servers like this, you're likely not leveraging server build automation (unless you're also creating and maintaining a database of these names - yuck busy work). This is probably fine on a small scale, but at "cloud-scale" this just isn't feasible. As Ian says in his answer, in today's cloud-first world, servers should be livestock, not pets. – MDMarra Jun 11 '15 at 11:59
  • 1
    I agree that naming servers this way is more work with an autobuild system, but I note that the point of building them is for other people to use them - and the data above are from the people who had to **use** them. It may be that what they want has changed, but I think our decisions on server admin should be predicated on more than what makes our jobs easy. – MadHatter Jun 11 '15 at 18:06
95

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.

Thaeli
  • 1,186
  • 1
  • 7
  • 11
19

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.

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
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.

Insomnia
  • 507
  • 4
  • 10
  • 1
    So how do you remember what applications run on CYPRCHAPP001 as opposed to CYPRCHAPP003? I'll admit this is a problem with mnenomic names as well, but if you're going for some kind of functional names, might as well be specific. – user Feb 18 '13 at 19:44
  • 2
    @MichaelKjörling Fine grain specifics of what is on a server don't belong in a name, they belong in some sort of documentation. If someone needs to know what is running on CYPRCHAPP001, they read the documentation. Besides applications move, CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc will be a misnomer when the company moves their payroll software to a hosted solution. – Wulfhart Feb 19 '13 at 23:17
  • 2
    @Wulfhart I agree with your point, but what's wrong with having CNAMEs for `pointofsale`, `payroll`, etc.? That way, nobody but the sysadmins need concern themselves with exactly where the payroll software is running; for everyone else, it just works. Want to move something to another datacenter? No problem at all. Want to move the point of sale system database to its own dedicated server? Just update the `pointofsale-database` CNAME to point to the new location. And so on. – user Feb 20 '13 at 08:47
  • 1
    Suppose you need to replace a machine: once you've built CYPRCHSQL002 and tested it, do you just retire the name CYPRCHSQL001 (never to be replaced), or do you rename 002 to 001 after you've removed the old 001, or something else? – nickgrim Feb 20 '13 at 11:22
  • @MichaelKjörling That seems like a great idea to me. By "specifics don't belong in a name" I meant not in the machine's hostname. – Wulfhart Feb 20 '13 at 22:39
  • @MichaelKjörling, generally we have a sheet which will list more specific info. The description is just to give us an idea of what it's used for. APP means multiple applications, SQL would mean SQL db, FIN could be used for Financial apps, etc. The problem with CNAMEs in our case is the multitude of domains and clients. Eg, we have multiple clients that use Simply, so calling a server SIMPLY still doesn't tell us who it is attached to. This is helpful with monitoring, and while currently we don't host client systems it's something we're looking into. – Insomnia Feb 25 '13 at 20:25
  • @nickgrim, generally we don't re-use names unless it would cause problems not to (embedded DNS names in applications, or other such random craziness). We do go sequential, although SQL002 might not always replace 001 (depends on how many instances a client needs to run). For most of our sites this also applies to user PCs, so DPC032 should never exist on the network after DPC032 is decommissioned. Note that we assign this name to the hardware, not the image, so if a computer crashes and we rebuild it, it takes on the original name. We do this for inventory management reasons. – Insomnia Feb 25 '13 at 20:31
  • Ah, one exception to the hardware rule: names on virtual systems usually refers to a single instance. If SQL001 crashes, the rebuilt image is SQL002. – Insomnia Feb 25 '13 at 20:34
2

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.

dunxd
  • 9,482
  • 21
  • 80
  • 117
  • 1
    I do disagree with this : "Knowing if a device is virtual or physical can also be useful" in the context of a *naming* discussion. Of course it's useful information, but it's not the first thing you need to know about a server from reading its name. Further, P2V or V2P either breaks your scheme, or requires renaming of the server, which may break other things. – mfinni Feb 19 '13 at 15:38
  • 1
    In my experience P2V or V2P breaks a whole bunch of things and should be avoided where possible - we do, hence it isn't an issue with our naming convention. The naming convention needs to meet the requirements of whoever designed it - in the org I work in it was designed by the team who manage all the servers and network equipment, and they want to be able to tell the above things. It might not be right for you, but then it is all open to debate. The only technical requirement is uniqueness. – dunxd Feb 20 '13 at 12:46