Device Naming Theory
What’s in a server name? This question has inspired debate for nearly as long as computers have been around. And it’s a debate worth having, since a poorly thought out naming scheme can create some surprising challenges down the road. There are many differing schools of thought on the subject, but the real “right” answer tends to depend on the scale of your environment and its projected growth.
One popular solution is recognizable names that are completely unassociated with the devices function. Pop culture, mythology, and astronomy are some common choices. Here at Silverback we’ve used Harry Potter names (Albus for executive share, Minerva for manager share, Weasley for corporate share) and natural disasters (Typhoon for mail server, etc.) to name a couple. Some also follow this convention using names that are associated with their industry or product. For example, a bakery might use types of breads (focaccia, brioche, rye, etc.). These names are easy to remember when there aren’t too many, and usually very difficult to confuse with one another. They also offer a margin of risk mitigation as there is no indication to potential outside attackers of the devices’ function or content. But there are a finite number of available names with any version of this scheme, and it scales poorly. The names ultimately run out, and once you get to a certain point it becomes nearly impossible to identify each machine. It can also be difficult for new staff to learn.
Device function is another option. This is much more feasible for large environments, and many larger companies use a version of it as their standard. Location abbreviations or serial numbers are often added as well. For example, Company X’s third file server in their second San Francisco facility would be something like SF2-FILE-03. This method scales very well and is easier for new staff to learn. It can also help simplify trouble shooting, especially in larger environments. Unfortunately it sometimes results in very long names that are easy to confuse with one another. It also clues in outside attackers to the machines function.
Another scheme is rack/RU position, with some reference to location if you’re spread across multiple facilities. For example, Company Y has a machine in Rack 7 RU 25 in their Sacramento facility. By this convention the name would be something like SAC-R7-RU25. This solution also scales well and is easy to teach to new staff. There is some trouble shooting benefit as well, since physically locating devices is a breeze. And since there is no indication of the devices function, there is some risk mitigation in terms of outside attacks. It can get very confusing if a machine is moved and not renamed however, and the names can be similar and somewhat easy to confuse with one another.
There are nearly as many server naming conventions as there are ways to organize a data center, and just as many strong opinions on the subject. This can make it a daunting task to choose the best method for your deployment. No two data centers are the same, so what works perfectly for Company A might not work at all for Company B. But taking the time to think about the scale of your operation and its projected growth is the key to making the right choice for your environment.
By: Leah Rayo
Comments are closed