What you will learn from this tip: How to document
You know the drill: The server team upgrades to a new operating system version and, in doing so, introduces connectivity problems into your storage environment. You discover the only way to fix the problem is to upgrade the firmware. You dig a little deeper only to realize the upgrade has dependencies that will affect your entire environment, launching you into a firmware- and driver-upgrade frenzy filled with lots of planning, lost weekends and late nights.
Many storage administrators don't manage drivers or firmware until something happens, such as an upgrade or new hardware implementation. Of course, the amount of firmware you need to manage is in direct proportion to the complexity of your environment and the systems you've implemented. Some vendors don't stipulate firmware and driver versions as long as the other systems in the environment support installed versions. Other vendors have charts, matrixes, spreadsheets and executables for every proprietary product in the environment, all of which seem to overlap and have cross dependencies, making a firmware upgrade a heavily researched and carefully planned event. Most environments seem to fall between these two extremes.
Get it down on paper
When evaluating and possibly upgrading your environment, the first step is to document everything in the SAN, including:
- Make and model numbers of servers and their firmware versions (motherboard, etc.)
- Operating system versions, service packs and patch levels
- Host bus adapter (HBA) firmware, drivers, failover or redundancy software
- HBA load-balancing software Infrastructure firmware/software versions (switches, directors, SAN extenders)
- Storage resource management (SRM) software package and current revision levels
- Disk subsystems and proprietary software
However you gather this information, make sure you create a document that's easy to access and update by anyone on your team. Some administrators try to keep all of this information in a spreadsheet, some write scripts that pull the data from their SRM tool and stick it in a flat file, while others create and store individual server configuration files tucked away in a shared folder.
If you have an accurate record of your firmware and driver revisions, you're light-years ahead of most of your peers. However, many documentation efforts start with great intentions only to be abandoned within a few months because of the effort required to maintain this information. It's a time-consuming chore, but having all of this information readily available is worth the effort.
Read more of this tip in Storage magazine.
For more information:
Advice: How do I document my SAN?
Advice: More on SAN documentation
About the author: Dean Auger has worked in storage for several years as a technical consultant, implementer, sales engineer and, most recently, in the financial industry.
This was first published in January 2005