In-Depth

Reader Mail: A Response to the FCIA

The author outlines 10 reasons why he disagrees with the FCIA's view of FC SANs

• By Jon William Toigo
• 04/08/2004

In his words, “During one of our meetings someone brought up this article written by you. Some people certainly thought that the writer did not know FC at all. Well, we know different. So here is my question: Would you be interested in coming into the lion’s den and present at a FCIA meeting? I believe many of our members would benefit from an outside view. They might not like it, but maybe it would rattle them. … This would NOT be an adoring crowd so think about it carefully.”

We deferred on the invitation for several reasons, which are enumerated below.

1. FCIA pushed FCP into service as the interconnect for a SAN because it was the fastest interconnect available in the late 1990s. They knew that it was not a true network and lacked in-band services (for management, security, etc.) that are part of any real network in business use today.

   FCP was, in fact, an implementation of serialized SCSI over a point-to-point channel interconnect. The FCP inventors at IBM explicitly noted that they had not set out to create a network protocol and had deliberately excluded all "IP stack like functions" from FCP. They just wanted to replace the fat SCSI cables they kept tripping over every time they walked around the back of their rack storage!

   In 1998 and 1999, the deficiencies of the FC protocol were clearly understood and documented. In the words of the white paper I helped write, FCIA was “going to work to add services into the protocol to make it more network like" over the next few years.

   My opinion of FCIA soured when that white paper was shelved "for marketing reasons." The industry was touting FCP as the ONLY interconnect for building SANs (oxymorons abound) and wasn't taking kindly to suggestions that the protocol wasn't quite up to snuff.

2. As iSCSI began to be developed at IETF, it seemed that a credible contender to FCP—one based on a true network protocol—was in the offing. When I suggested that SANs might eventually be based on IP rather than FCP, many FCIA member companies responded with hostility.

   I remember a senior member of a FC HBA manufacturer at Networld+Interop a few years back telling me there was no way that IP would ever be a storage interconnect. When I reminded him of this encounter a year and a half later, when his company announced the industry's first iSCSI HBA, he claimed to have forgotten the incident completely.

3. I have followed the development of both iSCSI at IETF and FCP at ANSI. Both standards-making efforts are imperfect, given the omnipresence of vendors in the standards process, but the politics surrounding FC switching standards at ANSI was over the top. Standards like FC-SW2, for example, were written with sufficient wiggle room for any vendor to create a switch to the letter of the standard that would be completely non-interoperable with other standards-compliant switches from competitors. I agreed with the 10-page critique submitted by Cisco Systems at the time condemning FC-SW2 and concluded that FC protocol development had become a microcosm of the industry itself.

4. At conference after conference, FCIA articulated the same themes: FCP rules, everything else drools. The problem was that FC Fabrics really weren't delivering on the SAN vision as articulated in the original ENSA white paper from Compaq.

   With an FC SAN, you needed the services of a true network, IP, to provide all management and control on an out-of-band basis that wasn't being provided in-band by FCP. So, a SAN was actually a “dual-network" architecture at a time when many companies were looking to consolidate voice, video, and data on a single IP network. It made scaling an SAN an even more problematic undertaking since you had to scale both the IP and the FC fabric components. The word "kludge" comes to mind.

5. FCIA tried to convince everyone that SANs were the best platform for all data. Nonsense. The differences between applications and their data storage requirements make a one-size-fits-all topology a complete myth.

   In point of fact, some apps actually do very well with FC SANs—and I have recommended them in certain instances. However, others do best with NAS or with DAS because of application requirements. All do not want the same drink of storage from the same SAN pool. There can be no one-size-fits-all storage topology because applications are all different. “SAN everywhere” is oversell.

6. FCIA members have started pitching "FC SANs for the rest of us" (i.e., the SMB market). Most SMBs don't need SANs. They don’t have high-end tape libraries (what motivated about 70 percent of early SAN adoptions) to share. Those needing a topology for scaling block storage behind certain apps (a key motivator for SANs today) will be better served by much less-expensive Serial Attached SCSI (SAS) or iSCSI configurations than by dumbed-down FC HBAs and switches—an opinion born out by site visits and conversations with IT staff in SMB shops.

7. Claims that "FC SANs are needed for real data protection" are simply not true. While a stable SAN might provide a platform for expeditious data replication and failover, I wouldn’t trust a SAN-based data replication scheme unless all of the equipment was from a single vendor at both the primary and all remote sites. Heterogeneous SANs create more downtime than they avoid.

8. "FC SAN interoperability has reached a new level": Hundreds of press releases with this theme came out this past year. Behind the scenes, technicians painted a different story: "Interoperability issues are worse now than they were five years ago," I was told by one test lab guy, while another noted, "We were lucky if we could keep the fabric alive for longer than 15 minutes at a time." Perhaps I was talking to the wrong people? Maybe. But, my clients tell a different story.

9. If there is so much inevitability behind the ascension of FC SANs as the dominant storage topology, why does FCIA exist? What is its purpose?

10. At the end of the day, topology is not the big issue—provided it is stable. The challenges of storage have little to do with topology, but rather with data and its management: how data is characterized and named, how access frequency is counted, and how storage platforms are characterized by cost and capability so a policy engine can migrate data to the right platform and protective process automatically. SAN standards are tinker toys compared to what will be required to make this happen.

I will agree that FCIA has been remarkably successful in convincing the top tier of the market that FCP is all there is. My industry friends complain they can’t sell a port of anything that isn’t Fibre Channel. But most Fortune 500 shops have been wasting money on high priced gear with poor capacity utilization efficiency for years. Many are already planning for the replacement of storage gear just as they deploy their most recent acquisition. I have interviewed IT managers in such shops who say they are on their third FC SAN deployment—and quickly add how little they thought of their first two.

Going forward, I expect FCIA will have a bigger challenge from vendors in the SMB space. For one thing, they do not have the deep pockets of their wealthier cousins, and they have a distinctly "show me" attitude. For another, these folks possess the common sense to realize that the value products deliver to their organizations is the true measure of success.

I’m thankful for the invitation to the FCIA meeting, but I'm happier discussing these issues in a public forum. Why not set up a public meeting: FCIA on one side of the table, and many disgruntled SAN users on the other? That would give the FCIA a more comprehensive “outside view” than anything I could possibly say.