To a system administrator, a server is your baby. You take care of it; you replace its readers; and it keeps you awake at all hours of the night. Just like a baby, a server needs a name – some sort of label to distinguish it from all the other servers. But there are a lot of things to consider when naming your server. And while a bad name won’t make your server pick in the playground, it could make your job harder later on, so I’m going to discuss some tips for developing a scalable and informative naming scheme, while still having a style. that is unique to it.
Functional names versus unique names
While I will admit that this is not a hard and fast rule, I do believe that every server on a network should have a unique name that does not directly describe its potential use. I have had many heated debates with other administrators who strongly disagree with me on this point. When administrators are faced with a large number of servers, it is certainly tempting to name the servers according to 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, does not always have a defined fate at birth. For example, suppose you have a server that acts as your internal DNS and LDAP server. How would you stay consistent and scalable according to a functional naming scheme? Would you call it dnsldap01, directory01, or maybe just ns01? Servers with more than one function can easily confuse functional naming schemes. Also, what happens in a year when the LDAP directory gets so big that you have to split it into its own server? You must then modify the host name of the server as well as the configuration files of all the servers that refer to it.
In a unique name-based server naming scheme, each server has a host name that it retains throughout its life. No matter what this server ends up doing, its hostname helps you keep track of this machine through any hardware glitches or other issues that the server might have. That said, there are some very good reasons for working naming schemes. I’ll discuss a simple method for getting the best of both worlds in a moment.
Choose a scheme that will evolve
Scalability is probably the aspect of a naming scheme that is most likely to bite you down the road. What happens to your Seven Dwarfs naming scheme when you need to add an eighth host? Whenever you choose a naming scheme, you should be mindful of the number of servers that you will ultimately name with the scheme, and make sure that you will have plenty of alternate names for the new servers.
Choose patterns with subcategories
An effective method of keeping track of an abundance of servers is to assign a naming scheme to a category of server, such as all servers at a particular site. Then, further divide the names into subcategories, such as names based on a particular subnet or type of server.
For example, let’s say you have a site with 15 servers. Three of these servers are virtual machines on a special subnet. Also, let’s say you’ve chosen Presidents of the United States as your naming scheme, which will expand to 42 servers starting today. You can name virtual machines after the presidents who use the currency.
Developing subcategories can seem like extra work, which increases the likelihood that you won’t be able to keep up with them. But it’s amazing how quickly you’ll get used to it. When you see a problem with Lincoln, you immediately think of “virtual machine”.
Choose names based on what you know
If you are a music buff, name the machines after the musicians. If you’re a history buff, name the machines after the world’s top leaders. The point is, the more you name servers after something familiar, the more you’ll be able to remember what that server does and its general history. It’s easier to remember that you’ve replaced Nero’s hard drive a few times this year if that’s a name you recognize. It’s even easier if you’re inclined to mnemonics and can imagine Nero playing the violin while his data burns.
Choose friendly names
Even if you are the only one accessing these servers by name, and especially if you are not, you should try to keep names short and easy to spell when possible. After all, you will have to type these names hundreds, if not thousands, of times. Short and simple names ensure fewer typos and headaches when you need to log into the machine at 3 a.m.
Always use functional names
I realize I just said don’t use functional names for servers, but there are a number of benefits associated with using them. Plus, in an ever-changing data center, there are going to be issues that no naming scheme can really address. For example, if the users accessed an FTP server named Bob, but you need to move the FTP service to a new machine, then you need 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 serve as aliases for A records. Continuing with our Bob / FTP example, all of your clients would be configured to access ftp1, but on your DNS server it would be a CNAME pointing to Bob. If you were to move the 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 without any change in their configuration.
This way, you have the best of both worlds: you can assign working CNAMEs to servers while they still have unique names that they retain throughout their lifetimes. You also have the option of assigning multiple functional CNAMEs to the same server. So if your Plato server serves both DNS and LDAP, you can create both ns1 and ldap1 aliases that point to Plato. If you are splitting the services on two servers, you only need to change the appropriate CNAME, but the hostname may remain the same.
Pre-assign host names
When you manage a large number of servers, you are ultimately automating so much of the server setup process that choosing an appropriate hostname can actually take a large percentage of the setup time. Once you’ve decided on a naming scheme, not only choose names for your current set of servers, but choose a few ahead of time. If you also assign subcategories and working CNAMEs, 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 said to be one of the perks and privileges of a system administrator, just as naming a baby is for a parent. Pick a naming scheme that makes it fun. Just try not to tempt fate – naming a server Titanic only asks for trouble.
ABOUT THE AUTHOR: Kyle Ranking is a systems administrator in the San Francisco Bay Area and author of several books, including Knoppix Hacks and Subunit Hacks for O’Reilly Media.