Every machine needs a name. As soon as the second server is ready to go, the name
SERVER no longer seems like a great idea. When deciding how to name servers,
there are two primary conventions: functional names and unique names.
Functional names take the job assigned to the server, add a unique identifier if
there is more than one server doing that job, and call it done. Thus if you have
three mail servers, they are
MAIL3. This naming
convention has two perceived advantages over other conventions:
- Quick and Easy
Since the formula for selecting server names is predefined, it's only a matter of seconds before the next server name is determined. Adding a third database server?
The least fun aspect of system administration is documentation. Generally, it's tedious and just no fun at all. By naming servers by what they do, half the job of documentation is already done.
As indicated above, these advantages are really only a matter of perception. This
convention is only self-documenting on a network that experiences no evolution.
Over time, server responsibilities change as the needs of the users change. For
example, a server called
WEBMAIL is obviously the webmail server. But, it is
also a prime candidate for another web-based application (perhaps the IT
department's trouble ticketing system). Once this happens,
WEBMAIL is no longer
just the webmail server.
WEBAPP would be a better name, but renaming the server
is not an easy process. Now the documentation must be updated to note that the
trouble ticket system resides on the webmail server. Unfortunately, since the
staff is used to the "self-documenting" nature of the functional naming
convention, no one remembers to update the documentation, and no one knows where
to look when they can't find a server called
Unique names can be of the human-readable variety (
FRED) or machine-generated
7C0). Any name at all is acceptable, so long as the network documentation is
updated regarding the responsibilities of the server. This naming convention
focuses on the fact that, over it's lifetime, a server will most likely provide
many functions. Rather than deriving generic function names that can (hopefully)
accommodate any changes, the unique naming convention throws that out and avoids
any future confusion. Administrators are trained from the beginning to review
documentation when a question arises, and are more likely to maintain the
documentation when changes are implemented.
In general, both naming conventions have their merits. Over time, the functional naming convention loses out as its benefits lead to a lackadaisical approach to network documentation. The unique naming convention not only encourages maintenance of the network documentation, it requires it. In the end, finding the right server to work on when necessary is the only thing that really matters.