To maintain many servers, how do you give a name to your servers?
By only server's hostname, I would like to classify the server's kind of service, whether virtual machine or not, stages(alpha, beta, real), hardware specs and so on.
Is there an idea?
closed as not constructive by Sven♦, Shane Madden♦, Iain Oct 11 '12 at 7:02
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.
There are probably as many of these as there are organizations. Most organizations I've seen don't name servers after their function, but some do (some just number them arbitrarily). The server's location is often added, but I've pretty much never seen anyone do it based on hardware specs.
Any combination of data used to make a server name will have equal disadvantages (particularly, the information will be long and you will need to know it all to know the server's name). You could, however, use some kind of code, like 2-4 characters of the service name, optional v for virtual, one character for stage (typically the names used are dev, UAT, and prod), and some code that corresponds to the hardware. Perhaps you might name a production domain controller dc1pvnv522us. It can be deciphered and I think it's within legacy naming requirements, but it is ugly.
I really can't think of any practical way of putting hardware specs in there. You could use the model number, but this wouldn't work for VMs, and wouldn't talk about anything you have added. I'd advise against it. Typically, that kind of data is managed in detail using some kind of inventory system (maybe a spreadsheet, or maybe asset tracking software).
I have seen people use location and a numerical asset code before (eg. vax00313d for server number 313 in Vauxhall, part of the dev environment; the server's specs would be kept elsewhere), and also, conventions like the server's function, location, environment, and number for uniqueness are common (eg. dc-vaxp1 for the first production DC in Vauxhall).
Use whatever you find neat, but avoid trying to pack too much information into a hostname.
Whilst I would normally move to close a question like this, this particular issue is one I feel very strongly about, so I'll bite.
Naming schemes can generally be divided into two kinds: mnemonic names, and functional names.
Mnemonic names are names re-used from some other field; Lord of the Rings characters are popular, as are elements, and I'm sure you've seen many others; I myself favour rivers. But the thing about mnemonic names is that they're all tried-and-tested names from some other field of human endeavour, and they embed no implicit information about a machine. They're just names.
Functional names are names which embed some function of the machine, sometimes in a simple form (solaris-database-5.example.com), sometimes in a more opaque form (s10db01.example.com). In functional names I include names which contain no information whatsoever as long as they're not mnemonic (s00345.example.com).
In my experience, IT groups and managers love functional naming schemes. But the last time I took upon myself the authority to found a naming scheme, I went and asked the people who would be using those names most, on a day-to-day basis: the developers.
Of about 40 developers, all but one said they preferred mnemonic names. There's something about a good name that is easy for the human brain to remember, and we are well-designed for hanging notes about function onto those names (Steve Gregson lives next door. Steve is a baker. Steve drives a Land Rover. Steve lent me his angle grinder). We are not, as a species, well-designed for hanging similar memory structures onto random numbers.
As a secondary scheme, they asked for functional names to be embedded in CNAME records. So each host got a mnemonic name as a primary name; that lived and died with the chassis; when a chassis was upgraded, it got a different name. But the functional names could still be used by anyone for whom they were appropriate, and because they were CNAMEs, many could point to a single host.
So the DBAs would use pr1db01.example.com; the mail chaps would use pr1ms01.example.com; the applications guys would use pr1je03.example.com. But all three CNAMEs pointed to nile.example.com. If a function moved off, the CNAME was repointed. If nile was upgraded, the CNAMEs would point to a different chassis. But when you logged into the host, whether as pr1db01 or pr1ms01, the system prompt said "nile". When I sent around an email saying that nile would go down from 2300 to 0330 the following day, everyone read what they needed to into that name, because nile is a human-usable name, on which it's easy for the brain to hang internal records.
That's what I'd recommend. And don't forget that the DNS is a hierarchical namespace; use hierarchy as part of your naming scheme, to simplify it, if you need to; sol1.dba.example.com can be a different CNAME to sol1.mail.example.com).