Server names: A checklist for scalable schemes

Naming a server is like name a baby, except babies don't have to have a scalable naming scheme built in. This checklist on how to come up with scalable server names will keep you out of server admin hell.

To a system administrator, a server is your baby. You take care of it; you replace its drives; and it keeps you up all hours of the night. Just like a baby, a server needs a name--some sort of label to distinguish it from all of the other servers out there. But there are a lot of things to consider when you name your server. And while a bad name won't get your server picked on in the playground, it could make your job more difficult down the road, so I am going to discuss some tips for developing a naming scheme that is scalable and informative, while still having a style of its own.

Functional names versus unique names

More on server management:
Active RFID tags automate server asset management

CA aiming to ease mainframe software licensing costs

ITIL implementation in the data center videocasts

Although I will admit that this is not a hard-and-fast rule, I believe that each server on a network should have a unique name that does not directly describe its potential use. I have had plenty of heated debates with other administrators who completely disagree with me on this point. When administrators face large numbers of servers, it is certainly a temptation to name servers based on their function, ie. web01 for the first web server, db03 for the third database server, and so on.

The downside to functional naming schemes is that a server, like a child, doesn't always have a set destiny at birth. For instance, say you have a server that acts as your internal DNS server and LDAP. How would you remains consistent and scalable according to a functional naming scheme? Would you name it dnsldap01, directory01, or maybe just ns01? Servers with more than one function can easily confound functional naming schemes. Furthermore, what happens in a year when the LDAP directory becomes so large that you need to split it off into its own server? You then have to change the server's hostname along with the configuration files of any servers that refer to it.

In a server naming scheme based on unique names, each server has a hostname that it keeps throughout its life. No matter what that server ends up doing, its hostname helps you keep track of that machine through any hardware problems or other issues the server might have. That said, there are very good reasons for functional naming schemes. I will discuss a simple method to get the best of both worlds in a moment.

Pick a scheme that will scale
Scalability is probably the aspect of a naming scheme most likely to bite you down the road. What happens to your Seven Dwarves naming scheme when you need to add an eighth host? Whenever you choose a naming scheme you should have in mind how many servers you will ultimately name with the scheme and make sure that you will have plenty of spare names for new servers.

Choose schemes with subcategories
An effective method for keeping track of a server abundance is to assign a naming scheme to one category of server, such as all servers at a particular site. Then further divide names into subcategories, such as names based on particular subnet or server type.

For instance, let's say that you have a site with 15 servers. Three of those servers are virtual machines on a special subnet. Furthermore, let's say you chose the Presidents of the United States as your naming scheme, which will scale to 42 servers as of today. You might name the virtual machines after Presidents that are on currency.

It might seem like extra work to develop subcategories, adding to the likelihood that you might not be able to keep track of them. But it's amazing how quickly you will get accustomed to them. When you see a problem with Lincoln you immediately think "virtual machine."

Choose names based on what you know
If you are a music buff, name machines after musicians. If you are a history buff, name machines after major world rulers. The point is, the more you name servers after something familiar, the more likely you will be able to remember what that server does and its overall history. It's easier to remember that you replaced Nero's hard drive a few times this year if it's a name you recognize. It's even easier if you are prone to mnemonics and can picture Nero fiddling while his data burns.

Pick user-friendly names
Even if you are the only one that accesses these servers by name, and especially if you aren't, you should try to choose names that are short and easy to spell when possible. After all, you will have to type these names in hundreds if not thousands of times. Short, simple names ensure fewer typos and headaches when you need to log into the machine at 3 a.m.

Do still use functional names
I realize that I just said not to use functional names for servers, but there are a number of benefits associated with using them. Furthermore, in a forever shifting data center, there are going to be issues that no naming scheme can truly account for. For instance, if users have been accessing an FTP server named Bob, but you need to move FTP service to a new machine, then you have to go to each client and change the configuration to point away from Bob and to the new machine. Even if you named the server ftp1 you would still have the same problem.

The solution is to use CNAMEs on your DNS server so that all functional names point to unique hostnames. CNAMES are DNS records that act as aliases to A records. Continuing with our Bob/FTP example, all of your clients would be configured to access ftp1, but on your DNS server that would be a CNAME that pointed to Bob. If you needed to move ftp service from Bob to Fred, you would just need to change the CNAME record to point to Fred and all of your clients would migrate over without any changes in their configuration.

This way you have the best of both worlds--you can assign functional CNAMEs to servers while they still have unique  that they keep through their lifetime. You also have the flexibility to assign multiple functional CNAMEs to the same server. Thus, if your server Plato serves both DNS and LDAP you can create both ns1 and ldap1 aliases that point to Plato. If you ever split the services across two servers, you just have to change the appropriate CNAME yet the hostname can stay the same.

Pre-assign host names
When managing a large number of servers you ultimately automate so much of the server configuration process that choosing an appropriate hostname can actually take a large percentage of the setup time. Once you settle on a naming scheme choose names not only for your current set of servers but pick some in advance. If you assign subcategories and functional CNAMEs as well go ahead and assign IP addresses and CNAMEs in DNS. That way when the time comes for a new server all you have to do is pick the next name on the list.
Finally, have fun. Naming servers is supposed to be one of the perks and privileges of a system administrator just like naming a baby is for a parent. Choose a naming scheme that makes it fun. Just try not to tempt fate--naming a server Titanic is just asking for trouble.

ABOUT THE AUTHOR: Kyle Ranking is a systems administrator in the San Francisco Bay Area and the author of a number of books including Knoppix Hacks and Subunit Hacks for O'Reilly Media.

Dig Deeper on Server hardware strategy