Greg Beech's Website

When naming servers, please name them sensibly!

At my house I have a bit of a north pole theme with my hardware naming conventions. The laptop I'm writing this on is called ICECAP, my media center is called GLACIER, and my desktop is called ICEBERG. Even my wireless network is called AURORA BOREALIS. Now this is a bit of fun in a home environment because there aren't many computers, it's only me who has to remember which is which, and none are exactly mission critical (unless GLACIER crashed while recording MotoGP in which case I would get a bit upset).

But please, please don't use this type of naming convention in a server environment!

One of my clients named all of their servers after british birds, so the production rig consisted of machines named things like JACKDAW, WREN, BLACKCAP and so on. It wasn't very easy to work out which of these was the primary SQL cluster node, which was the secondary one, and which were the BizTalk servers. In fact, it was so difficult even for people in the company to remember, that they occasionally accidentally shut down or deployed to the wrong machine.

Another client I went in to had all the machines named after metals. ALUMINIUM, BRONZE, TITANIUM and so on. Can you work out from this which is the SQL Server, which is the OLAP server, and which ones are the web servers? Or which ones are the test servers and which were production ones? No, of course not. And nobody who came into the company could either, necessitating a load of tables mapping the name to the function.

So please, use a sensible naming convention which incorporates the following:

  • Customer or department - If you're hosting services for a customer, then use a 2 or 3 letter abbreviation of the customer name at the start of the server; if you're hosting an internal application use an abbreviation of the department name. This makes it easy to work out which servers belong to who, and lists them all sequentially when looking at the network. For example if you were in the financial services department, you might begin all your server names with FS.
  • Project or purpose - Often servers are set up to host an individual project, so again use a 2 or 3 letter abbreviation of this; if it's a more general purpose environment then use an abbreviation which indicates what it is for. For example if your financial services environment was used for your SWIFT messaging hub then you might use SMH as the purpose.
  • Environment type - Typically you'll have a number of environments such as development, test, UAT and production. You should incorporate this into the machine names so that nobody gets confused and accidentally deploys to the wrong machine because they can't remember which environment it is on. For your production environment you might use PROD.
  • Role - Each machine will have a specific role in the environment such as being a SQL Server, BizTalk server, web server etc. Again you should encode this into the machine name so it's easy to identify the purpose of the machine. For your SQL Server you might use SQL.
  • Number - Even if you only have one machine at the moment, you may want to add more in future. Also the number can be used to indicate which is the primary node in an active-passive configuration, for example if you have two SQL Servers numbered 01 and 02 then 01 should be the primary (active) node in the cluster.

Using this naming convention we might now come up with a name such as FS-SMH-PROD-SQL01 for the active SQL node in the production environment of the SWIFT messaging hub in the financial services department. Sure, it's not as catchy as JACKDAW or ALUMINIUM but it's a hell of a lot more descriptive, and will help both you and contractors find their way around the environments.


Posted May 08 2007, 07:15 PM by Greg Beech
Filed under: ,

Comments

No Sense wrote re: When naming servers, please name them sensibly!
on 05-25-2007 11:11 AM

From a security point of view the names of servers should not give any indication as to their function.

From an internal or external point of view? I'm assuming that we are talking about servers in a corporate environment which are well protected behind firewalls and cannot be directly accessed externally, so the naming from an external aspect is a non-issue. If it's from an internal point of view then if untrusted people can access the servers and/or are able to attempt to hack them unnoticed you've got a far bigger problem on your hands than the naming convention - Greg

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

Enter the numbers above:
Copyright (C) Greg Beech. All rights reserved.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems