Specifications

www.ibm.com/support/techdocs 37

Summary of Best Practices for Storage Area Networks

information that is needed for the configuration. The configuration interfaces will not

keep track of which project a given storage allocation was intended for.

Lastly, there may be a great many things that need to be kept track of that a SAN

device will never record, such as the name of the project/application that owns a server;

contact names, in-service date, etc.

NOTE: For obvious reasons, none of this documentation should be stored on a SAN-

attached server. (It is surprising how often this mistake is made.)

Code upgrades

By and large, the most stable SAN environments are ones that carry out major code

upgrades every 12 months, and generally do not use a major code release (for

instance, a 7.x -> 8.x upgrade) sooner than two months after it is released, unless there

is a compelling reason to install the more recent version. One example of an exception

to this guideline is a “field flash” containing a warning of a severe code bug. The

purpose of regular code upgrades is to avoid code and/or firmware levels getting so far

behind that vendors and IBM support are reluctant to examine issues, but not so far on

the bleeding edge that potentially problematic code is introduced into the production

environment.

Another significant best practice guideline concerns similar devices running with a

consistent code version across multiple systems. The purpose for this particular

guideline is to maintain consistency in the behavior of a device group in the solution,

plus the fact that vendor testing rarely includes ANY testing and/or certification of

environments where code levels are mixed. From a practical viewpoint some customer

data centers may have a valid reason for mixing code versions, such as requirements

for a given application, but these situations are extremely rare and should be avoided as

much as possible.

Naturally, if a new level of code becomes available that has an especially desirable set

of new features and/or fixes, there is no hard and fast requirement to wait for the next

“cycle” to perform a code upgrade. Also, the importance of examining the readme file

and/or release notes included with almost all software and firmware packages cannot

be overstated. It is the author’s experience that this crucial step is often overlooked by

administrators around the world. The release notes often disclose important

dependencies of code on another device that can lead to catastrophic results if not

followed.

The following is a list of general best practice recommendations for upgrades: