Are you looking for some ideas on how to establish and implement a standard host and server naming convention for your organization? If so, you’ve come to the right place!
We’ve been pretty impressed by what a popular topic this has been (since 2014 – but still relevant in 2019!). It seems no matter what the year, someone is always going to think “Birds of Prey” and “Mammals of the Ocean” are great naming schemes (hint: they aren’t!)!
Creating and employing a host naming convention can be fairly straight-forward with a little up-front planning. Without planning, they can be a nightmare (but that’s why you’re here, right?!). Effective naming conventions should be both practical and scalable, while still remaining human-understandable.
Naming Your Servers After Greek Gods…
[/responsive]
I have to admit that there is an entertaining aspect to theme based host naming conventions. Naming your servers after Apollo, Zeus, Poseidon, and Ares is entertaining and can work quite well in a small/single location environment. Perhaps you have been there and done that – or at some point considered it.
But themes just don’t scale. Face it, once the list of Immortals and Titans are used, naming a server after a lesser deity like Epimetheus gets old really fast – and who wants a server named after “the father of excuses” anyway?
Also, theme-based names aren’t practical because they don’t provide information that helps to identify a device.
As it turns out, naming servers is hard. Why?
- Deploying them has become incredibly easy. With automation & virtualization, servers can be deployed in seconds.
- SysAdmins that were once responsible for ten servers can now be in charge of hundreds, if not thousands. You just can’t think up that 429,736 (good) names! Many people only get to name a dog, their children (maybe?), and possibly a goldfish – admins name things daily.
- Pets-vs-cattle. We used to nurture our servers, building them by hand and caring for them like a pet — Well, hopefully your pets do get more — but you get the idea. Now that servers are built in seconds, destroying one and rebuilding is often quicker than fixing a broken or possibly compromised server.
- The cloud. Before, you could only build as many servers as you had hardware for, but now, it’s quite common for a tech company not to own a single server. Why? SaaS (software as a service), and now IaaS (infrastructure as a service), e.g., the cloud.
- Automation. Last, but by no means least, Automation. It both makes things easier, and is required because managing all the “things” you can easily make — becomes hard again. It’s the old chicken and the egg adage, all over again.
So that said, naming more than a few things IS HARD. And that’s why this topic is so popular, and therefore so important. Now on with the show!
What about numbering your servers?
So running out of Greek gods is an obvious problem which will eventually lead to repeated names. You could (as I actually saw done once) pick and entirely different theme for each type of device… But then you’d need a chart just to track the categories. Few people know the names of all the Greek Gods, all the Birds of Prey, AND the Mammals of the Ocean…
So why not turn to the experts of tracking extremely large numbers of things – Like the US Government, which tracks each and every one of the nearly ~400,000,000 of US just counting the United States?!
We all have a Social Security number, so why not numbers? You’ll never run out, as they go to infinity, and you’ll never repeat. You can even start with a large enough number so that all your servers have the same number of digits, prefixing the initial ones with zeros!
…This also doesn’t work. Maybe in the future when automation is completely and fully in control and human interaction is never necessary, it’ll be OK, but until then, picture a troubleshooting conversation with your co-worker:
“I know the problem is on your end, 00084296 isn’t talking to 00085327 or 00085238!”.
Numbers also aren’t practical, by themselves. They don’t provide any human-readable information to immediately help identify a device and its role.
Sure, you could have a database … but does that really make sense?
One Size Fits All … Not!
There is no “one size fits all” approach for naming conventions. But coming up with a host naming convention can be pretty straight forward. Your goal should be a standard naming convention for all infrastructure devices (i.e. host names) across the organization. Consider starting by establishing a set of basic criteria, for example, host names must include:
- The location of the device [three digit abbreviations work well here, like nh-]
- The service level of the device [think dev,qa,prod … so nh-p]
- The role of the device [web, database, mq… now we have nh-pweb]
- A two/three digit sequential number [for dealing with multiple servers … nh-pweb01]
Optionally, the host names can include other information such as customer, service name, and device type (e.g. physical vs. virtual) that helps provide information about a device.
The criteria listed above are just one possible set of criteria. The set that will be used for the your specific situation can (and probably should) differ – consider the example in the next section… The Anatomy of a Hostname
Anatomy of a Hostname
[/responsive]
The naming convention in the above image has become a popular approach because it works well. While it is not perfect for all scenarios, a variation of it will likely do the trick.
Pros:
- Scalable so it can work well for any size organization
- Easy to identify location, role, and service level
- Active Directory / LDAP – location and/or role based – rights, permissions, or policies can be easier to manage due to logical relationship. For example, an Active Directory group policy may be applied to all workstations based upon location, so adding all workstations from New Haven Chapel street to its corresponding organization unit for New Haven Chapel street workstations is an easy task.
Cons:
- Location, role, or service level change requires name to be changed
- P2V requires a hostname change
- Length of name can be a bit of a nuisance for CLI uses
- Length of name (over 8 chars) is still unsupported by some legacy software (think AD “shortname”, for example, though thankfully this is becoming increasingly rare)
Options and Variations:
- Customer identifier: USNHCDBRD-D001 – where RD is Research and Development
- Software or service identifier: USNHCW2K8-P001 for Windows 2008 Server or USNHCSP-P001 for Sharepoint Services
- Pre-fix names with local airport short codes, thus condensing Country, Location, and Unique site code into (usually) 3 letters – LGA for Laguardia, CLT for Charlotte, IAD for Dulles International
Other considerations:
Physical servers may be converted to virtual servers, or vice-versa. While you may want to know if a device is physical or virtual, consider the work involved in changing the name before committing to this approach; the good news is this is making less and less sense as virtualization is now pretty much the norm.
Feel free to adjust complexity to suit the size of your organization, however, do leave room for growth, as well. The key is that once a naming convention is established, a seasoned tech should be able to deduce a server’s name based solely on the convention.
Find a tool and use it!
[/responsive]
Ok. This is not a sales pitch (well, sort of not exactly 🙂 – but do consider finding a tool that can automatically generate new hostnames based on profiles you pre-define. Ideally it is included as part of your configuration management database toolset, as it is in Device42. If you use a tool that can generate hostnames based on profiles that contain definitions of the variables and how to combine them into hostnames, you’ll obtain the following advantages:
- Ensure that all new hostnames are standardized and conform to convention
- Eliminate errors by automatically generating hostnames to be used
- Control access so users can generate new hostnames, but cannot change profile definitions
- Be one step closer to that fully automated deployment system you’ve been dreaming of implementing
The image above shows the Device Name Profiles main list. As you can see here, there are 11 existing profiles – all naming profiles are completely customizable (end-user defined) in Device42.
[/responsive]
The image above shows the device name profile for US NH Chapel Prod Production Servers:
- Prefix: this is the substance of the name – results shown below
- Suffix: the end of the name; this usually consists of your domain name
- Number Length: # of digits in the unique, sequential numerical identifier appended to the Prefix
Also shown are the options for defining the ‘Start Number’ and ‘Last Used’ number (useful when implementing the tool where a conventions already exists, skipping over a manually created or already existing device, etc.)
[/responsive]
Above we see the hostnames (we refer to these as ‘device names’ in Device42) generated using the US WH Sawmill Prod Web Server profile. This handy tool allows for generation of one or more device hostnames in bulk, as shown above – we created 5 new devices: lga-pweb04, lga-pweb05, lga-pweb06, lga-pweb07, and lga-pweb08 – in one click!
In addition to generating the device names, a record for this device is also created, the following options can be assigned when generating names:
- Service Level
- Type
- Asset Number (also profile based)
- Customer
[/responsive]
The image above shows the device’s record (or CI, Configuration Item) for USNHCS-P005 which was automatically generated when the device name was created.
It’s a wrap!
In closing, let’s review the main points:
- Effective naming conventions should be both practical and scalable
- Avoid theme based host naming conventions
- The goal should be a standard naming convention for all infrastructure devices (i.e. hostnames) across the organization
- Establish a basic set of criteria to define what information your hostnames must include
- Find a tool that can generate hostnames based on profiles that contain definitions of the variables and how to combine them into hostnames
Happy Trails!
Grab a FREE fully functional trial of the Device42 virtual appliance! — Click HERE.
Learn more about Device42, please visit: www.device42.com/features/
