Functional Server Naming Conventions

Question

I've seen "The Coolest Server Names," and I've seen another smaller-ish question related to mine, which was unfortunately closed.

It's a serious question though, as I'm on an internal applications dev team that manages the apps on a couple dozen servers. The networking folks typically don't care what we call the servers as long as they know about 'em, so we can come up with whatever conventions.

The apps the servers deal with can be home-grown custom apps, or they can be larger vendor ones like SharePoint. They can be:

• In multiple networking environments that can't speak to each other (think firewalled-off external servers versus intranet-esque servers)
• In different physical locations (California office versus New York, etc.)
• In multiple deployment tiers (production, staging, testing, dev)
• Have one or many functions (web server, DB server, mail server, app server)
• Load-balanced or not
• Standby (for disaster recovery purposes) or primary

Whew! Think it's even possible to come up with a convention that can address all of these aspects, or significant ones? It'd be nice to hear a server name (or DNS entry for it) and be able to immediately know what it does, and it works for getting new guys up to speed as well. "sharepoint-IPC-1 is down" could be parsed into "the internal production SharePoint web server in the California datacenter that's the first node in the load balancing is down!"...but that seems overly complicated at first glance.

Another thing in the back of my mind is that an old mail relay server is getting decommissioned, which means we have to scour through a lot of old apps to repoint hardcoded server values (I know... :).

Answer 1

Here are some general guidelines I try to abide by, based on mistakes I've made in the past.

Never base your machine names on...

• Hardware Machines get swapped out all the time, and you don't want to have to do too much work if you change from an IBM server, to a Sun server, to a Dell server.

• Location Equipment and even entire server rooms can be moved based on business requirements or technical issues.

• Intended Use As your product evolves, so too may the intended use of each server. Having a machine named "dbsrv" but eventually acts as a file server too, is confusing.

• Owner The person who "owns" the equipment (an employee) can change, due to firings, layoffs, and moves within the company.

• Subnet As I said before, labs can move, and so can subnets. One of the main goals of DNS is to free you from being tied to a specific IP address, so why tie yourself down needlessly?

Now, some suggestions for the situation you described...

• Machines spread across a region This is what subdomains are for in DNS. You could have "west.company.com" and "east.company.com".

• Have one or many functions Don't name them based on intended use. If you name them based on some large collection of names--Greek gods, for example--you will eventually intuitively know that zeus.east means your master database server and apollo.west is your backup database server. Worst case, look it up in a spreadsheet.

• Load-balanced or not You can take two approaches. You could have a unique name per node behind the load balancer, or you could do something like athena-1.east, athena-2.east, etc. Either way, a load balancer will (hopefully) free you from worrying too much about what each node is named.

• Standby or not This doesn't sound like a criterion that should have an impact on the machine name.

What I'm essentially saying is:

1. Separate your equipment into different regional subdomains
2. Choose a naming scheme with plenty of names (Greek gods in this example)
3. Don't base the names on any of the criteria I mentioned above (intended use, location, etc.)

Trying to do anything more than that will be more trouble than it's worth.

Answer 2

I know that it's tempting to assign names to servers that describe their functions and other similar attributes and in a perfect world that will work but in practice I have found that after a while these things get messed up as functions and other parameters of the servers change (as the requirements of the business change) so the names no longer reflect the reality.

I think you should assign unique names to the servers that do not tell anything about the function or other parameters and have some sort of (up to date) list detailing those things so that your people can look it up. That's what we do here.

The other extreme is using IP addresses only or having names based on IP addresses which can lead to a disaster too if you ever have to change your IP addresses.