

Ask HN: Servers Naming Convention hierarchical or not? - billias

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.<p>An server example is: jdtdv-app001.domain.int<p>Meaning:
jd = Jon Doe (department)
t  = test (environment)
d  = datacenter
v  = virtual<p>After the -<p>app = application (server type examples: sql, mta)
001 = numbering<p>domain.int (domain internal).<p>I find it difficult to understand and explain, and you always need to check the documentation.<p>on our hadoop we use these:
jdtdv-hnn001.domain.int
jdtdv-hdn001.domain.int<p>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.<p>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)<p>I was thinking of changing this to an hierarchical (at least for me) fqdn.<p>Example of a worker on hadoop:
worker001.dc01.test.company.net<p>explained: &lt;server type&gt;&lt;number&gt;.&lt;datacenter&gt;.&lt;environment&gt;.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.<p>What are your thoughts?
======
caw
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/](https://mnx.io/blog/a-proper-server-naming-scheme/)

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

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

