Three years later, Webster, a senior analyst and partner at Data Mobility Group LLC in Nashua, N.H., says, "Things haven't really changed all that much."
So what is it about heterogeneous SANs that inspires such long-standing fear, uncertainty and doubt?
No SAN is a homogeneous island
First, all SANs are multivendor by definition. No one vendor supplies all the networking components, switches, arrays, host bus adapters (HBA) and tape drives required to comprise a SAN. Most SAN configurations are usually sourced from a single vendor such as EMC Corp., Hitachi Data Systems Inc., IBM or Hewlett-Packard Co., each of which typically has a list of prequalified vendors with whom they work.
According to Tom Clark, director of solutions and technologies at McData Corp., agreements among these vendor partners commonly specify certain products down to the microcode level. Because of this granular, coordinated approach, vendors can protect themselves against users who deviate from interoperability dictates. If, for example, a user is attaching HBAs, the supplying vendor can suggest a preapproved list of vendors and that the user use certain specified levels of microcode. Despite its vendor focus, this arrangement is also favorable to users because when they comply, their service calls go a lot smoother.
"What major [resellers] do not like is when customers go on their own and begin including bits and pieces spontaneously into their fabrics," Clark says. "When they have issues, they call the [vendor], but it is not the [reseller's] issue because the customer has gone beyond the recommendations or guidelines."
Clark says that these kind rogue customer confrontations are far less common today than they were five or more years ago.
In fact, Clark says, almost all the major problems relating to interoperability have been well tested and resolved. After all, each supplier wants to make sure that when it brings a product to market, it is qualified and has proven interoperability in its marketplace. It's more likely that a server will lose the path to a storage target due to pathing software than significant hardware interoperability problems.
It is important for users to remember that meeting microcode requirements is not a one-time event, because those requirements change with technology upgrades. Shops that fall two or three revisions behind may find that in addition to losing partial compatibility, they will also be deprived of feature functionality that has been introduced since their last microcode upgrade.
A dispute breaks out
Despite the mutual efforts of vendors and users to create interoperability, they still clash, and when they do, it tends to be in the form of a "he said/she said" exchange that doesn't lend itself to clean-cut verdicts of who is right and who is wrong.
For example, John Blackman, a systems architect at a large West Coast-based bank that he declined to identify, takes issue with switch maker McData.
"McData is the worst when it comes to being interoperable," Blackman says. "They don't like interoperability; they want people to stay with them. They will say one thing and do something else. It's to the point where I'm willing to say, 'Screw you, get out of my shop,' but I can't say that politically and because I've got 11,500 ports of their switches in my environment."
Clark says McData isn't unwilling to try to meet Blackman's requirements. "I would say this probably has far less to do with the willingness of McData than it does with the expectation or the timetable being demanded by the customer," he says.
At the edge of his fabric core, Blackman has blade switches from two vendors, QLogic Corp. and McData. He is rankled because in his opinion, the QLogic switch has become "McData-ized."
"McData went and just said, 'Here QLogic, here's McData's firmware,'" Blackman says. According to Blackman, each McData switch consumes an excessive number of domain IDs. He says that Cisco, which he is also bringing on, has expressed its willingness to work with McData on interoperability, but McData is not receptive to other vendors.
Blackman says that Cisco has told him they are willing to work with McData on interoperability before Cisco comes out with a new rev of firmware to ensure it's qualified.
"That's what you should be doing, right? In a shop that has a true interoperable environment, where you're connecting Ciscos and McDatas. The same should hold true with McData and QLogic," Blackman says.
Clark says he understands users have problems because they introduced additional vendors into a fabric. But, he notes, "if you are talking about a multivendor fabric and you are adding Brocade, McData or Cisco in the fabric itself, then yes, you can have issues, and the issues can be on anyone's side."
Clark says that McData -- along with Brocade Communications Systems Inc. and Cisco Systems Inc. -- is compliant with the FC-SW2 NSI standard that describes a Fibre Channel network in which nodes are connected to a fabric topology by one or more switches. So there's no reason Blackman or others should experience interoperability problems, he says. Beyond that, Clark adds, McData has worked "tirelessly" to develop and support industrywide interoperability standards.
But Clark does acknowledge the inordinate consumption of domain IDs is an issue, and one that McData is working on. Clark says that work revolves around how QLogic does its implementations and on how McData and QLogic work together to satisfy the appetite of the blade switches for domain IDs.
Clark goes on to explain that major switch vendors have an "open mode" to minimize interoperability problems in heterogeneous environments and a proprietary mode for use with homogeneous systems. In open mode, the switches sacrifice their proprietary, value-added capabilities. For example, he says, when Brocade switches are in open mode, they sacrifice some zoning capabilities.
How to preclude problems
Bob Shinn, a former manager of storage and now director of service delivery at State Street Global Advisors in Boston, has a suggestion for would-be multivendor SAN users: Hire a third-party consultant firm to help with implementations.
"Don't overspend on this, but you should absolutely hire someone that you know you can trust," Shinn says. "You need someone you can work with that has experience in this area and [in] maturing a storage environment. That way, you can skip some of the growth pain."
Even with a trusted partner, he says, users should not expect to rapidly reach the highest level of SAN maturity overnight. What they can expect is someone to help develop strategies and be there to support them when they reach crisis points or major milestones. Shinn highly recommends GlassHouse Technologies Inc. and Darwin Partners Inc. as consultants with strong SAN experience and knowledge.
SMI-S: Ahead of the user curve?
Clark is a former Storage Networking Industry Association board member who has held chair positions for SNIA Customer Initiatives and the SNIA Interoperability Committee. He says users have been waiting for SMI-S to reach a point of maturity that makes them feel it is worth their while to cut over. He also says that point has now been reached. The nascent standard has been the subject of rampant speculation and hopeful predictions even as it slowly winds its way through the standards process and into the budgets of storage networking users.
Blackman counts himself as a SMI-S supporter, saying, "I've been an advocate of the SMI-S standard, and part of that is because I think things should be interoperable. I believe I should be able to slice and dice disks and present data from different storage arrays."
Asked to describe the standard's current status insofar as actual implementations are concerned, Clark says, "In this one rare instance in our industry history, I think the industry is ahead of the users. SMI-S capabilities are being supported in hardware today. Platform developers have SMI-S-capable management frameworks, but customer adoption is still lagging."
Shinn is a grudging SMI-S supporter. According to him, "I believe in the concept, I just think it's being oversold."