| 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? |
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/