Naming Conventions for Your Systems

Through time organizations have adopted many methods for naming servers. Some of these include:

1.) Presidents
2.) Planets
3.) Atomic elements
4.) Greek gods
5.) 50’s movie stars
6.) Pets

In all of the above cases there was a scalability problem as eventually you run out of Greek gods or elements. It is, however, fun to ask someone to log into ‘Sinatra’ or ‘Elvis’.

Eventually, as the above is abandoned a more formalized system is achieved wherein the name is actually an overloaded string containing several smaller identifiers. These identifiers often include one or more of the following:

1.) Operating system(Win, W2k,W3k3,UBU,RH,RHEL,WIN2008, etc)
2.) State(NC, ATL, FL,OH, NY,CA)
3.) Datacenter identifier(10,16, 4,5 for the floor)
4.) Datacenter floor(A,B,C,D,E)
5.) Rack location(totally absurd but seen it done before)
6.) Network availability(P for public, F or firewalled, I for internal, L for local)
7.) Environment function(Dev,D,Test,T,Prod,P,QA,Q, etc)
8.) Server purpose code(APP(C ),APP(N),DHCP,DNS,FILE,FTP ,IIS ,SQL)
9.) Clustered or not
10.) Virtualized or not

The first problem with this model is that the label on a white sticker on the front of the physical case is NOT necessarily in sync with the bits on disk. It is as easy as a couple of right clicks and a reboot to ruin the synchronization between label on front and network identity. Then we are again back to a physical inventory and matching port to ARP entries and KVM-ing machines.

The second problem is derived from the simple fact that servers move. This includes known servers moving from one floor/datacenter/state to another and also from one function to another. Because the servers move, for the naming convention to be accurate servers must be renamed. So a SQL server (as designated on the outward label and bits on disk) needs to be renamed when installing FTP, filshares, converting to a VM or clustering. That’s a tremendous amount of change to handle not even looking at this particular move. In fact, many if not most of SQL servers already break this convention currently. This is due to the image having permutations of FTP, IIS, Reporting Services, File Shares, other APP functionality loaded to what is ‘labeled’ a SQL Database server.

In reality, the end user(that’s me) uses what is either a very specific and difficult re remember name(GA016VTSQL069) or what I call the nifty name(“the Kofax database server”) when speaking to others about a server. The Nifty name is non standard and really inherited verbally from one person to the next for ease of use. On the other hand, should I need to run a script against a production database server, the complexity(or naming convention accuracy) is irrelevant to my script. My script will chew through GA016VTSQL069 just as easily as connecting to a host named “GGSH389FKSJJS” without regard to networking, location, naming, functionality or purpose embedded in the name.

One might argue that putting some network location into the name is helpful for determining physical location. While I agree to ‘helpful’ we have BGP routing and VLAN extensions that render this approach invalid.

Lastly, there is a real world cost to following a naming convention.

– Web servers : .NET and .asp code needs to be reviewed for hard references to altered hostnames
– Registry needs to be corrected for ODBC.INI, SNMP, WSUS, SNMP, etc
– IUSR_[old hostnames] need to be corrected to IUSR_[new hostname]. Same for IWAM_ accounts
– SQL servers need to have the SQL instance renamed and correct linked server hosts
– AD installations and participating node servers need to be rejoined to the new domain

This and any server move would be much easier has we abandoned the naming convention and used non specific hostnames. This is because the act of physically moving servers would have not depended on renaming, correcting code, applications or domain participation. While hosts would be re-ip’d and possibly virtualized, the processes that reference dynamic/randomized hostnames would be oblivious to the local beyond the network interaction.