Server Naming Conventions

Had an interesting discussion a couple of weeks ago about the best way to identify servers in a scalable and sustainable way.  I used to be very keen in naming boxes with generic unconventional unique names. i.e. city names, colours, movie characters,  but have found that this simply does not scale.

Had a very good piece of advice from my friend Christopher Farley that gave me a different insight to this and outlined the importance of getting this right when scalability is a factor.

In his view,taking a functional approach to server naming, in time, proves to be a scalable solution, by making the identification of boxes more efficient and pragmatic, allowing sys admins and network engineers to quickly map a box against an environment profile.  This saves time and a lot of hassle, particularly in a time when network frames are downsized and upsized in very short time spans.

There are a great number of different conventions out there. I searched for common standards, but it seems that there isn’t a cohesive approach across the industry; each organization tends to follow its own way, which makes sense to a certain extent, but also adds a degree of confusion that could possibly be mitigated if there were a set of principles recognized by the industry. 

For large organizations, identifying boxes with names of the geographic locations where the server is hosted, the data centre location, followed by other specifications, might sound logical, but the most obvious constraint to this approach is around what to do when servers need to be repurposed. 

A clear example of this would be moving a box from one location to the other without intending to make a clean install. Since the Hostname is identified with a specific location, repurposing would not be effortless. Now if we are talking about a significant datacentre migration, this would constitute a major risk and an unnecessary overhead to an already complex operation. 

The same set of limitations is also present when attributing other functional attributes to server names  i..e db001 *database server. What if a server needs to be repurposed to a Web frontend box? or a Load Balancer? These are all valid questions, that should be asked before one chooses a specific server naming convention. Unfortunately, as like most IT challenges, bad decisions usually are only apparent when its too late to do anything about them.

On the other hand, the main advantage behind the functional approach is the ease of identification. In theory, the only thing that needs to be clarified is the principle, i.e. Server Type - Server Number - Location of server. From this moment forth, identifying servers in a network, regardless of the size, becomes extremely efficient. DB001NY - Database Server - Number 001 - Located in New York. 

This is particularly useful when working with external providers that do not necessarily know what is, and what should be mapped against. 

The final case that can be brought forward in favor of the functional naming convention, is that in most cases, repurposing servers is not really the right thing to do. Servers are built for a specific purpose, the Hardware and Software should be aligned to what we want to achieve, not the other way around, thus while repurposing a server might seem to be the quickest solution to respond to an immediate need, long term, its not the ideal way to built a scalable infrastructure.

For more information about this subject, there is a very interesting article by Scott Lowe that provides an excellent insight.