Ask HN: Servers Naming Convention hierarchical or not? | Hacker News Reader

Ask HN: Servers Naming Convention hierarchical or not?

2 pointsbillias3 comments

We currently use an Naming convention which I personally to not find it so easy to use, and confusing. I would like your opinion on the current one, and my thoughts.

An server example is: jdtdv-app001.domain.int

Meaning: jd = Jon Doe (department) t = test (environment) d = datacenter v = virtual

After the -

app = application (server type examples: sql, mta) 001 = numbering

domain.int (domain internal).

I find it difficult to understand and explain, and you always need to check the documentation.

on our hadoop we use these: jdtdv-hnn001.domain.int jdtdv-hdn001.domain.int

Can you find the difference? there is a small d and n in the middle of the server type. this means Datanode (worker) and Namenode.

This is making it ever more complex The production name node from Test has this difference: jdtdv-hnn001.domain.int jdpdv-hnn001.domain.int (production)

I was thinking of changing this to an hierarchical (at least for me) fqdn.

Example of a worker on hadoop: worker001.dc01.test.company.net

explained: <server type><number>.<datacenter>.<environment>.company.net so from a specific point to a more generic. Of course this is not my final setup of a host name, but just an example.

What are your thoughts?

I've done both an encoded data name scheme (what this is) and the cattle method (srv0001, srv0002, etc etc). SRV can even encode a bit of information like datacenter location. Avoid rack/row because stuff gets moved around. Airport codes are popular to distinguish datacenters.

As far as encoded name schemes go, and even with the cattle method, I like the physical/virtual distinction. It lets me know whether I can iLO/IPMI/drac or need to open vSphere/equivalent for when SSH doesn't fix everything.

Where I don't like encoded schemes is because your departments and users inevitably want to change the environment or service. Experimental/test servers tend to feature creep into production because "it works, let's just promote and build a new test box". Also you end up with weird combo servers with multiple services because "it's only this one thing and we can't wait for a new box just for it". So now the web server isn't just a web server or an app server.

My opinion is to keep naming however you're naming. I'd consider dropping the environment and most likely department. Encode that into the CNAME, or keep another database of ownership.

This article is pretty good on naming schemes: https://mnx.io/blog/a-proper-server-naming-scheme/

I also bookmarked that article at mnx.io and think it is very straight forward naming schema.

I used till now the mnx.io style of naming, which is from more specific to more generic approach... and found it also easy to remember.

Last but not least, on multiple environments you have the same local naming, and your applications can work without even touching them.

Reply on news.ycombinator.com