Naming conventions for servers

Arseni Mourzenko
Founder and lead developer
June 4, 2015
Tags: rant 34 datacenter 4

The rant se­ries of this blog will be in­com­plete if I wouldn't men­tion the nam­ing con­ven­tions for servers, es­pe­cial­ly since I've nev­er even seen a con­ven­tion which would make at least some sense in any com­pa­ny.

The three pre­vail­ing nam­ing con­ven­tions which are used in com­pa­nies are:

But couldn't we do bet­ter?

When dis­cussing servers nam­ing con­ven­tions with sys­tem ad­min­is­tra­tors, they usu­al­ly ex­plain that at some stage of their ca­reer, they tried two things, and both failed:

  1. Choos­ing mean­ing­ful names which cor­re­spond to the un­der­ly­ing ser­vice host­ed by the serv­er. So a serv­er which hosts Mi­crosoft SQL Serv­er 2012 be­comes MSSQL2012-01 and a serv­er which hosts the Share­Point 2010 por­tal be­comes SP2010-FRONT-01.

    And then, the com­pa­ny moves from Mi­crosoft SQL Serv­er to Or­a­cle Data­base and from Share­Point to some Java ap­pli­ca­tion, and names be­come com­plete­ly awk­ward, but no­body dare change them, be­cause no­body knows what could be the con­se­quences and how many of those names are al­ready hard­cod­ed by de­vel­op­ers in their code.

  2. Choos­ing a good pat­tern which re­sponds ex­act­ly to the cur­rent needs and makes it pos­si­ble to have very clear and ex­plic­it names for 35 ma­chines which are cur­rent­ly de­ployed.

    Then, two years lat­er, every­one blames the au­thor of the con­ven­tion for in­vent­ing some­thing which is ab­solute­ly im­pos­si­ble to work with, now that the com­pa­ny is host­ing 500 ma­chines.

So they start us­ing the names from Greek mythol­o­gy, which, be­ing com­plete­ly mean­ing­less from the be­gin­ning, re­main mean­ing­less for­ev­er, avoid­ing bad sur­pris­es lat­er.

At Pel­i­can De­sign & De­vel­op­ment, we made a mis­take of hav­ing a (over­ly) com­plex pat­tern used for nam­ing both servers and end-user ma­chines. Sur­pris­ing­ly, it worked well and re­mained valid for years (but we weren't scal­ing to thou­sands of servers ei­ther), but it had its flaws, such as the fact that the name con­tained the lo­ca­tion (the name of the data cen­ter and the lo­ca­tion with­in the data cen­ter). The ma­jor prob­lem with the con­ven­tion is that those long names were com­plete­ly cryp­tic to any out­sider (and frankly it was even cryp­tic to me, giv­en that I doc­u­ment­ed the pat­tern.) I was sure we can do bet­ter. And bet­ter we did. When the op­por­tu­ni­ty came to move to Lin­ux in­fra­struc­ture, I de­cid­ed to aban­don any nam­ing pat­terns and to keep it sim­ple stu­pid.

To­day, servers are named ac­cord­ing to their role. Trust ap­pli­ca­tion, for in­stance, is host­ed on, sur­prise, sur­prise, trust-http and trust-http-failover, the Mon­goDB data­base be­ing on trust-db and trust-db-failover; would I mi­grate Trust to Post­greSQL, the ma­chine name won't be af­fect­ed. If you want to lo­cate Iris ser­vice, you should be ex­pect­ing it on servers which start by iris. In the same way, dns-dhcp hosts guess what? Right, our DNS and DHCP ser­vices.

We have some is­sues with the names, such as when it comes to giv­ing de­scrip­tive names to de­vel­op­er ma­chines. Cur­rent­ly, it's dev1, dev2, etc., but this is just ugly, and I can nev­er re­mem­ber which ma­chine is mine. Names such as dev-arsene are wrong too, since a ma­chine is not af­fect­ed to a spe­cif­ic per­son. I start hav­ing a sus­pi­cion that there is no right an­swer for such cas­es, but any sug­ges­tion is wel­come.

In gen­er­al, I'm pret­ty sure every­one can do an ef­fort when nam­ing their servers in or­der to have mean­ing­ful, ex­plic­it names. So in­stead of BAY7-STB25-R14, please name your pri­ma­ry Ac­tive Di­rec­to­ry back­up serv­er ldap-backup-primary, be­cause frankly, no­body likes to work with BAY7-STB25-R14 and no­body re­mem­bers what is host­ed on Poseidon, and I'm not even talk­ing about Artemis in the data clos­et (is it even on­line?)