The server naming convention is dead, long live the server naming convention!

Summary:

  1. Get rid of conventions that can be cross-referenced from other data sources in a programmatic fashion.  
  2. Consolidate or present those cross-referenced data points into one pane of glass.
Rant:

In times old, server's had cool names like Ferrari, Robotech, etc.  Although cool, this drove the need for a server naming convention which served useful purpose.  It could tell us a good many things about a server just by looking @ its name.  Some things could be:

  1. Location
  2. OS
  3. Application
  4. Etc.
Because of limitations in previous technologies, you had to limit your server name to a certain number of characters (coming from a Windows background).  Each of these data points needed to be shortened to acronyms or numbers.  This essentially requires a decoder ring for each section of the server name to understand it's hidden meaning.  When dealing w/ a small environment, not a big deal, but scalability becomes a problem.

Using the examples given above:
  1. Location Sources
    • IP Space
    • Active Directory Sites and Services
    • Virtualization Management systems like vCenter or SCvMM
    • Local iLOM/IDrac/OOB
  2. OS Sources
    • Active Directory
    • WSMan
    • Bash
    • Virtualization Management systems like vCenter or SCvMM
  3. Application - a bit more complex, but use sources.
    • WSMan
    • Other tools to extrapolate the installed applications and convert those to 'tags'
Bottom line:
Any modern naming convention should not contain any crypted metadata that can be programmatically cross-referenced from a trusted source.

Comments

Anonymous said…
For small environment, I mean less than 50 VMs, I'm fine with the metadata included in the VM name.

But for large virtual infrastructure, I would rather use web client's categories and tags to hold metadata...

Rgds,
Didier

Popular posts from this blog

NSX-T: vCenter and NSX-T Inventory out of Sync (Hosts in vSphere not showing up in NSX-T)

MacOS: AnyConnect VPN client was unable to successfully verify the IP forwarding table modifications.

Azure VMware Solution: NSX-T Active/Active T0 Edges...but