One of the earliest things I’ve learned as I jumped into system management was the importance of standards; not only standards for equipment but also standards surrounding naming conventions. This blog will cover the process around development and implementation of a naming convention standard.
As we begin, I am not going to tell you what kind of naming conventions to use, just a guideline to think about when you are developing them. I have been in many large organizations where there have been many heated debates about “xyz” names and so on. It’s extremely important that once a naming convention has been selected that everyone adheres to it as if it were gospel. This will end up being the starting point for your infrastructure organization to ensure equipment can be quickly identified for support, financial, and audit abilities.
First off, you need to gather all interested parties together in order to develop your naming convention standard. It is best to get all the IT groups together that have a stake in these naming conventions to ensure a seamless deployment of those conventions. Here are the areas that should be involved:
· IP Networking Team
· Storage Team
· Windows and Unix Teams
· Other Potentially Interested Teams
o Database Team
o Application Development
Begin your meetings with the end goal in mind: a naming convention that everyone can live with, something that is easy to understand, and one in which the name adopted fits on the label needs that goes on the device. Once you have decided on a standard, those should be the physical as well as the logical names of the systems and/or storage.
Here are storage naming conventions I have used in the past as it is important that you have some kind of idea of how you are going to structure your naming conventions. Here are a few examples:
· FCS20001 – Fiber Channel Switch – Building 20 – Switch 001
· EVA20001- Enterprise Virtual Array – Building 20 – EVA 001
· HDS20001 – Hitachi Data System – Building 20 – HDS 001
· TLB20001 – Tape Library – Building 20 – TLB 001
· FCB20001 – Fiber Channel Bridge – Building 20 – FCB 001
· FCR20001 – Fiber Channel Router – Building 20 – FCR 001
· WIN20001 – Windows Server – Building 20 – FCR 001
These will allow you and your support staff to know what the device is used for and what building it is in as well as the number of the device. I have also used rack designations in the past as well to allow for even easier device location.
For the FC networking side of things, these naming conventions should translate down into your zoning schema as the more a more these naming conventions proliferate thru your environment, the more rapidly you and your staff will be able to respond to support and configure items.
-FC Zoning Schema-
· EVA20001_FC01_Alias – Alias of EVA 001 – Fiber port 01
· WIN20001_HBA01_Alias – Alias of Windows Server 001
o Host Bus Adapter – PCI Slot 01, this will allow you to both logically and physically trace down this adapter in the environment
o Example of a single initiator zone for Windows Server 001
o (WIN20001_HBA01_Alias, WIN20002_HBA01_Alias, EVA20001_FC01_Alias)
o Multi-Initiator zone, which contains multiple windows servers, typically multi-initiator zones are no longer used for there interference with cross-talk from HBA to HBA
Usage of these conventions in your zoning will allow you to streamline your SAN and allow for simple and easy administration of your zone schema. As a rule of thumb, avoid managing your schema using wwns that become virtually impossible to maintain as your SAN grows larger and larger.
As you move into storage subsystems and tape libraries, continue this process of keeping things similar through the usage of naming conventions. Just remember the lack of naming convention standards with a given piece of infrastructure will cause an overhead in daily administrative tasks as well as adding unneeded pain when trying to address and support issues. It takes some effort but once these standards are implemented and enforced you will see support resolution as well as the completion of daily tasks speeding up dramatically.
Part 1 in this series on data center management covered cable management.
Part 2 in this series on data center management examined label management.