Hacker News Reader

Comment by lsc | Hacker News Reader

Naming is a classic bikeshed. Sure, a good naming system is a good thing, and helps you recognize what box is where. But once you hit between 20 and 200 hosts (depending on your memory) you are going to need to stick 'em in a database and sort 'em into groups to manage them in a sane manner anyhow, and at that point, naming schemes won't mean much anyhow.

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.

View on HN

as a person who deals with tens of thousands of machines/network devices, i disagree that it's a bikeshed. yes you have to refer to a database for specific information. but it can be a huge time saver if the information that is most generally needed is just there, not needing to be looked up.

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?

Declaring bikeshed should be like calling shotgun--whoever declares it should make the decision.

But... what if they make the wrong decision!? I think we need more time to consider our options here.

"choose the scheme essentially at random."

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

I wish I could upvote you a thousand times. Naming discussions are classic bikeshedding. Everyone has an opinion, they'll argue endlessly and vigorously for their preferred naming scheme, and in the end it has very little real impact.

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.

Yeah. I remember one place that did the thing where they named the box based on the rack and the 'slot' in the rack. the problem was that this was the /primary key/ in the database so as troublesome hosts got swapped out for diagnostics, we lost their history. We had no idea if this was the second time the box was sent in for diagnostics, or the 50th.

Easy solution to that: put a label on the box and put a line there when it comes in for diagnostics.

This place had something like five thousand servers over several data centers. Like most places that size or larger, the admin never actually sees the servers. You (the admin) get a serial console and at best tell the monkey to replace part X or Y. At worst, it gets shipped back to dell, and reported as a new box when dell doesn't fix it (dell never fixes intermittent problems, unless you can tell them /exactly/ what the problem is. )

We have several very very large clusters - as you say, the names become problematic.

Currently we are using a "code" to ID servers.

- 2 letter geographical location code

- 2 letter building code

- 4 number computer ID

(e.g. LIMB0001)

This was after someone had to spend nearly a whole day working out where computer CU2043 was located :)

yeah. every time i've worked on multi-thousand box clusters you always did operations on sets of servers... and you'd grab those sets using a tool that would pull from a database. if you got an alert for a particular server, you'd go back into the database and you could then pull up all details you have for that server, including how to access it physically or remotely.

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

Whenever the list of systems gets too large I find I need to come up with a very boring scheme like that. At the university where I worked I set them up as:

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

Couldn't they have just used the IP address of the computer to figure out what subnet the computer was on?

many people have big, flat layer two networks... e.g. one subnet might span locations. Now, personally, I think this is a bad idea in nearly all cases, but many other people disagree with me.

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.

The very idea makes the network engineer in me cringe. There are so many good reasons to establish layer 3 boundaries before crossing any relatively low speed or high latency connections.

No, we don't control the network infrastructure at most of the locations - so two computers could easily have the same IP address on the local internal network as a computer several hundred miles away.

Unless you're nating between those locations, that's not possible.

It's a distributed cluster - I was trying to avoid being too specific for that reason :) my post was just about our practical example of naming many many computers

Naming schemes by people who haven't had to deal with at least three or four large environments are typically poorly done and result in confusion more than helping you. People think they understand naming, but inevitably they have no clue. Find the sysadmin/network engineer with 15+ years experience in real world environments and just let them come up with a naming scheme. Speaking as one of those people - server A-records = m1, m2, ... M9999, etc..

Routers=rt1.datacenter, rt2... (sw1 for switches, fw1 for firewalls, ...)

Yes, everyone has an opinion and everyone wants their opinion heard. Some people get much too passionate about naming. But in my experience, it's often been the people with the least vested interest who have the strongest opinions, and rather than 'calling bikeshed' the smart thing to do would be to identify the real stakeholders and get their opinions.

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.

"I admit this naming convention is more for the massive nerd factor than practicality."

Reply on news.ycombinator.com