Standardizing Host and Server Naming Conventions

Are you looking for some ideas on how to establish and implement standard host / server naming conventions for your organization? If so, you’ve come to the right place…let’s go!

Creating and employing a host naming convention can be fairly straight forward. Effective naming conventions should be both practical and scalable.

Naming your servers after Greek Gods…


wpid2983-greek-gods.png

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.

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
  • The service level of the device
  • The role of the device

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 yours can differ – consider the example in the next section…Anatomy of a Hostname

Anatomy of a Hostname


wpid2980-anatomy-device-of-a-name.png

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
  • Length of name can be a bit of a nuisance for CLI uses

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

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.

Find a tool and use it!


wpid2986-select-device-profile.png

Ok. This is not a sales pitch (well sort of) but consider finding a tool that can generate hostnames based on profiles. Ideally it is included in your datacenter infrastructure management system 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 generating hostname to be used
  • Control access so users can generate new hostnames, but cannot change profile definitions

The image above shows the Device Name Profiles main list. As you can see here, there are 9 existing profiles – all naming profiles are custom (end-user defined) in Device42.


wpid2981-change-device-name-profile.png

The image above shows the device name profile for US NH Chapel Production Servers.

  • Prefix: this is the substance of the name – results shown below
  • Number Length: the unique and sequential identifier appended to the Prefix:

Also shown are the options for define the Starting Number and Last Used number (useful implementing tool where conventions already exist)


wpid2982-device-naming-profile-tool-create.png

Above we see the hostnames (we refer to these as device names in Device42) generated using the US NH Chapel Prod Servers profile. This handy tool allows for generation of one or more device hostnames in bulk, as shown above we created 3 new devices, USNHCS-P005, USNHCS-P006, USNHCS-P007.

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

wpid2984-p005-view.png

The image above shows the record for USNHCS-P005 which was 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/

http://xkcd.com/910/