SAN interoperability still a burning issue

Storage-area networks are gaining in popularity, but mixing different vendors' products is still problematic, one user says

Storage analyst John Webster recalls telling attendees at a conference three years ago that there are users who make multivendor storage-area networks (SANs) 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, Webster says. But many said they preferred to stay with a single vendor because it was easier, he recalls.

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?

First, all SANs are multivendor by definition. No one vendor supplies all the networking components, switches, arrays, host bus adapters (HBAs) 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 switch maker McData, agreements among these vendor partners commonly specify certain products down to the micro-code 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 pre-approved list of vendors and that the user use certain specified levels of micro-code. Despite its vendor focus, this arrangement is also favourable to users because, when they comply, their service calls go a lot more smoothly.

“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 of 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 because of significant hardware interoperability problems.

It is important for users to remember that meeting micro-code 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 micro-code upgrade.

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 a clean-cut verdict of who is right and who is wrong.

For example, John Blackman, a systems architect at a large US bank, takes issue with McData.

“McData is the worst when it comes to being interoperable,” he says. “They don’t like interoperability; they want people to stay with them. They will say one thing and do something else. It’s got 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-ised.”

“McData went and just said, ‘Here QLogic, here’s McData’s firmware,’” Blackman says. He says each McData switch consumes an excessive number of domain IDs. He says 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.

He says that Cisco has told him it is willing to work with McData on interoperability before it comes out with a new revision 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 to 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 and Cisco — 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, he adds, McData has worked “tirelessly” to develop and support industry-wide interoperability standards.

However, Clark acknowledges that the inordinate consumption of domain IDs is an issue, and one that McData is working on. He 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.

He says major switch vendors have an “open mode” to minimise 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.

Bob Shinn, a former manager of storage and now director of service delivery at financial services provider State Street, 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,” he 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.

McData’s 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 the SNIA’s SMI-S (storage management initiative specification) 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.”

State Street’s Shinn is a grudging SMI-S supporter. According to him, “I believe in the concept, I just think it’s being oversold”.

Join the newsletter!

Error: Please check your email address.

Tags managementinteroperabilitysan

More about Brocade CommunicationsCiscoEMC CorporationFibre ChannelHewlett-Packard AustraliaHitachi AustraliaHitachi DataHitachi VantaraHitachi VantaraIBM AustraliaMcDataQLogicSNIAStorage Networking Industry Association

Show Comments

Market Place

[]