Operating system upgrades
Microcode is the firmware--or embedded software--that drives the hardware. It resides in special memory on arrays and switches, and functions as an operating system for the managed hardware. Upgrading this software is like upgrading a server operating system such as Windows. Simple patches to the operating system are easy to deploy and usually non-disruptive, but major revisions are complex and require careful consideration. "With all the appropriate preparation," says Arun Taneja, founder and consulting analyst at Hopkinton, MA-based Taneja Group, "there's still a moment when you close your eyes and pray."

				Microcode upgrade dos and don'ts
				Avoid just-released microcode updates; wait for them to go through real-world testing in other customer environments. Read the fine print. It may tell you that I/O will be temporarily suspended during an upgrade. Read the release notes carefully to see if the upgrade is qualified with your stack. For non-standard configurations, this is critical. Most vendors publish some kind of compatibility matrix. Have a back-out plan; make sure you can back up to the previous version. Load the upgrade but, if possible, keep the previous version in the buffer so you can move back to it if needed. If you have the means, build a test fabric to experiment with firmware before implementing it in production.

A product's microcode is critical to performance as it contains all the rules and definitions of how the hardware should work. Among the most common reasons for a code upgrade is to update a piece of hardware to work with a new standard or to deliver a "next-generation" feature.

A classic example of an OS on a never-ending upgrade cycle is EMC's Clariion midrange array, which is well over a decade old. It still runs Flare, the original operating OS. Steve Duplessie, founder and senior analyst at the Milford, MA-based Enterprise Strategy Group (ESG), estimates that there have been "between 30 to 50 revs" of Flare, not including patches and minor releases.

Upgrading versions of Flare released after 2001 but prior to Flare 14, which shipped in July 2004, is a non-disruptive process as long as the user applies each release without skipping any. Since Flare 14, however, users have been able to skip from 14 to 16, or 14 to 19 without loading interim releases. (There's no version 15 or 18, and version 17 specifically enables iSCSI support.)

"We realized that not all customers can run off and do an upgrade, [that] there are times when they fall behind [or] they want to skip releases and still have a non-disruptive upgrade," says Barry Ader, senior director of Clariion marketing at EMC.

EMC added code to the software that would help change how the data was laid out, a process that previously took several ordered steps and resulted in the enforced sequential upgrade. The ability to let users skip releases means more work for EMC in the testing process because the company has to support a larger number of potential upgrade paths. "The simple way was to make users go through the logical steps A to B to C," says Ader. "The more options, the larger the investment on our part."

However, EMC realizes that many of its customers--and there are tens of thousands of sites running multiple Clariions--don't keep up to date with releases. "Not all those customers have upgraded to the current code ... if [an older version is] stable, they may not want to go through an upgrade," says Tom Joyce, vice president and general manager of IP storage at EMC. He believes that because many users have been burned in the past with disruptive upgrades, some EMC customers still have upgrade policies that don't reflect the improved state of today's upgrade technology.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   NEXT PAGE  >