The SAN FUD factor

Storage analyst John Webster recalls telling attendees at a conference three years ago that there are users who make multivendor storage-area networks (SAN) work but that most shy away from heterogeneity because the prospect is too scary. Users in the audience at the time agreed that multivendor SANs can work, but many said they preferred to stay with a single vendor because it is easier.

Three years later, Webster, a senior analyst and partner at Data Mobility Group, 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, Hitachi Data Systems, IBM or Hewlett-Packard, 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, 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 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.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark