The problem is that as a bikeshed, /everyone/ has an opinion and everyone wants to have that opinion heard. I've been places where we spent more effort arguing about naming schemes than it would have taken to write the database and tools for retrieving groups of hosts.
So generally, when this comes up in situations where I'm in charge, I loudly declare it a bikeshed, and we choose the scheme essentially at random.
for us, we basically have 4 types of information in a fqdn: datacenter, lan, type of host (web server, database, filer, router, switch, etc) and an additional datacenter identifier. after the root domain comes the datacenter, and if there's an additional subdomain that's the lan. after that is the host name which is a number prefixed by the host type. the number is a randomly-selected number within a certain range. the range indicates what datacenter it's in, so 4000-5999 are in one place and 6000-7999 are in another place (incase whatever you're looking at did not include the subdomains). now we can refer to 'ws1234' and know what it is and where it is. it still has much more specific information, but that can be looked up as necessary. since it's less random it's also easier to read hostnames to people and grep through logs.
after having worked with much more confusing naming conventions, i like this simple straightforward method because it's easy to read, talk about, and gives the basic information i need before i look up the specifics in the inventory db. can you do without it? of course. but does that make my job easier or harder?
Given that, as you say, it all ends up in a database anyhow, at work where we have ~100 machines or so with various name, there simply is no scheme. Why should there be? The real key is that it's in the database and we enforce that (via saying that if you grab something and it's taken, the database wins), but beyond that it's all just artificial anyhow. We have romanized japanese numbers and characters from Zork, the Hitchhiker's Guide, and the Legend of Zelda, places where one person took their favorite photos (used as logos for the machines), several other vague schemes I've only caught wind of since I'm not part of the relevant groups, and straight-up utilitarian naming ("printer.subdomain") and so on, and it doesn't cause a problem. (IT itself does have its own naming scheme, we're engineering. It makes good sense for IT, I think.)
IMHO, almost any attempt to create some kind of meaning in the naming convention ends up sub-optimal. For example, I've seen people include information about the server hardware or OS in the name (ie something like dellwinnt01), or locations (atl-row1-01), etc. All of which fail miserably when there are server hardware/software update, data center moves, etc.
In the end, a server name should be easy to say, easy to spell, easy to remember, and shouldn't be anything that's likely to be controversial or offensive. No other criteria really matter.
Currently we are using a "code" to ID servers.
- 2 letter geographical location code
- 2 letter building code
- 4 number computer ID
This was after someone had to spend nearly a whole day working out where computer CU2043 was located :)
My current setup is approaching the 'need a database' scale... (we're at around 60 physical servers I've gotta deal with, if you count co-lo customer boxes, and maybe another 20 virtuals we manage. We've got around 1300 customer virtuals that I don't name or manage. so dealing with that database, either by massaging freeside until it can do what we need to do, or writing something else is one of our next projects.)
- 6-letter department abbreviation
- 3-letter group abbreviation
- 1-letter role/type identifier (e.g. w for workstation, s for server, m for mobile)
- 3-number sequence number, with the highest order digit often grouping related systems together.
It worked out pretty well and it made the systems easy to figure out from the hostname alone.
I like the idea of geographical names, but I would get a little annoyed when I moved a system from one building to another.
The thing is, vendors of expensive MPLS gear like to sell this idea of 'location independent subnets' to upper management as a way to 'simplify' the network.
Now maybe it's just 'cause I don't know layer two well, but god damn it is so much easier to troubleshoot layer three problems than to troubleshoot layer two problems, so I strongly favor making the subnets location and/or rack dependent.
Routers=rt1.datacenter, rt2... (sw1 for switches, fw1 for firewalls, ...)
If you have hundreds of servers, the team of sys admins using them every single day, who stand a good chance of connecting to all of them at least once in a year, should take priority over a manager who might refer to a small portion of them in conversation at a high level a few times per month or year.
Someone who has to use server names in conversations with customers, investors, partners, and the like should take priority over a guy who wants to name production servers after his favorite porn stars.
One solution is to simply declare bikeshed and pick an arbitrary scheme. I think in most cases that wouldn't be necessary if you muzzled the people who really should never have gotten involved in the discussion to begin with. It may be that once you get consensus on a few criteria (eg. no porn-star names) you may stall. That's when you declare bikeshed and pick something arbitrary that fits the criteria.
It would also has the advantage that you could use redily available pokemon stickers to attach to each device, and is a nice way to personify devices if you are so inclined - "Ivysaur is playing up again; time for a trip to the pokecentre"
'xyz241' is a test router
'xyz211' is a second test router
'xyz262' is a production webserver
'xyz546' is a production webserver
'xyz33' is a development database server
'xyz411' is a development database server for a temporary contract dev team.
'xyz101' is the corporate file server
If you have hundreds of devices to track, the weaknesses of using numbers should be apparent. The only advantage of that naming scheme is organization of the entire monolithic collection. It's easy to select new names and it is easy to enumerate the entire collection at once. Those are definitely advantages, but there are some obvious drawbacks, too. There's no obvious way to tell, short of committing it to memory, that "546" is a webserver.
To track of any other pattern, you'll have to encode some sort of information into the names. For example, you could organize the numbers, like most colleges do for classes. <subj> <level-number> * 100 + <course-number>. eg: MUSC 211.
Otherwise, you use numbers, and you treat them like farm animals -- anonymous, members of a species, with shorter lives.
You can get attached to pets, but you shouldn't bond to livestock.
For practicality, you would combine meaningful names (for the groupings) with numbers (web3, dev5, router2) rather than bijecting the entirety of your company's assets onto a set of integers.
I like the use of something like elements because it lets you use the character of the element as a sort of metaphor for the function of the server - but since it's a metaphor and not a clear name it's understood that you can't rely on the name to know what the server does, and you should keep it documented.
(Worst sin I've commited, name-wise: Naming my desktop PC dunsinane and my laptop birnham)
But how do I name my router at 192.168.1.254?
192.168.1.254 bipentquadium bpq
Edit: umich had a lot of funny machine names. The login servers were named for console video games (galaga, moonpatrol, galaxian), while the kerberos servers were (inexplicably) named for schwarzenegger movies: terminator, redheat, lastactionhero, etc.
Um. Ok. That's, um, interesting.
If you start with chemical names and hit the limits of the complexity that permits, are you going to move onward to molecules? Wait for Ununbium to be renamed Copernicium? What's next, molecular host names within the hydroxyl group are assigned to management?
If you're going to use a "corporate-style" naming scheme for your hosts, then just encode whatever it is you want to convey into the host name. Location or whatever.
Or just select random names.
Having the IP address encoded in the name strikes me as particularly problematic, too. Hosts and subnets and VLANs tend to come and go, and names and VLANs and address assignments tend to shift.
And naming based on physical locality is an increasingly quaint concept in the era of virtualization and client mobility.
After a while, most any naming scheme will prove insufficient or will unravel, so why not just have an eye toward the likelihood of distributed management and (increasing) complexity from the onset?
Seems better to spend your time getting (for instance) SNMP and DNS records configured and working for all your boxes, and less time making (more) work for yourself with explaining and maintaining complex host name schemes.
"I admit this naming convention is more for the massive nerd factor than practicality. If you have more than about 20 machines, just give them numbered hostnames and be done with it."
In more than a few places, a Google search string (or the browser's search input box) is the already the preferred contact path; not the URL.
What might replace URL-based navigation more widely, I don't know. We went from ARPA not all that long ago to the Big Seven to however many dozens of TLDs we have now. We'll certainly find out, as the URLs are increasingly hideous, and we're just a few years into this current naming structure.
There are certainly potential business opportunities here, too. Approaches to better solve a distributed planetary-scale address book than "just" based on a domain name, and better than a brute-force search engine.
How about a search engine that ALWAYS returns the canonical page for any techinical/commercial/copyright/patented term FIRST! Instead of somebody's dog named "rfq" or a car for sale by a gal from Concordance, OR.
This lets the suits pick goofy names for their boxes based on whatever they've seen on tv recently and allows us to automatically generate unique hostnames based on physical properties of the actual machines.
The sweet lack of multiple "Gimli's" and "Gandalf's" on my network warms my geek heart.
If you end up having to play games with your MAC addresses, basing hostnames on them is a suboptimal strategy.
Asset tags, on the other hand.....
I just use a naming format of Loc-Cabinet-Rackspace.
In my Seattle datacenter I know that sea-c01-s1 is a server thats in my seattle datacenter, cabinet 1, slot 1. I know it's PDUs are plugged into port 1 of PDU-LEFT and PDU-RIGHT in that cabint. I know it's two ethernet ports are plugged into Port 1 sea-c01-sw-left and sea-c02-sw-right. I know it's LOM cable is plugged into port 1 of sea-c01-sw-mgmt.
(I handle multi-U spaces by naming the server based on the bottom most rackspace it uses, and I stay consistent. If Sea-c01-s1 takes 10 rackspaces, then the server above it is sea-c01-s11. Beyond that, my configuration management tools tag spare resources when needed, and release them when unneeded. Cute hostnames are of no use to me, or anybody building out a datacenter that they'd like somebody else to be able to manage without months of knowledge dump.
Machines should have sequential names, services should be VIPs (or CNAMEs if you must) and everything else should be in a configuration management database.