Fixing Stupid, An FCoE Response
I’ve read Henry Newman’s article on FCoE and vendor stupidity three times now, and I’m afraid it hasn’t gotten any clearer for me.
Given the nature of the title, “FCoE Gets Lost in Vendor Stupidity,” and given the fact that I work with FCoE on a daily basis for Cisco, can I help but raise an eyebrow at being called “stupid?”
Okay, okay, so he’s not calling me stupid. He’s talking about the nature of the industry as a whole (I think), and he’s talking about what could happen with FCoE adoption if it’s not handled properly (I think), and he’s comparing the lack of object storage as a metaphor for a lack of FCoE storage (again, I think).
This is not to say that Mr. Newman’s numbers aren’t interesting – they are – but I just can’t help but wonder how he comes to his conclusion about FCoE given that the entire article discusses iSCSI.
In fact, half of the article is spent lamenting published benchmark tests (something that I agree with, by the way) and goes into fascinating detail about the IPv6 overhead implications of iSCSI (something I also think is valid, by the way).
How the article comes to be entitled “FCoE Gets Lost in Vendor Stupidity,” however, is lost on me. After all, Mr. Newman admits that FCoE is still a relatively new technology, and iSCSI “got off to a very slow start.” He also concedes that vendors have had much longer timeframes within which to optimize their iSCSI deployments than they have had with FCoE.
He seems to lament the fact that there is no Object Storage as evidence for his FCoE argument, but if he’s correct in that there isn’t Object Storage it is not true about FCoE storage. Listed alphabetically, Compellent, EMC, and NetApp have all announced FCoE-based storage devices and support. HP even has FCoE accessibility to their EVA and XP storage through the mpx200 protocol router.
Interoperability is also a main concern of Mr. Newman’s, and rightfully so. Having participated in the FCIA FCoE Plugfests for many years, I can say from personal experience that there is a great deal of effort and work put towards FCoE interoperability. After all, it is in the industry’s best interest to make sure that customers can expect their equipment to work together.
Finally, there seems to be a lamentation that FCoE didn’t “replace” FC storage. This comment confuses me, because it seems that there is an expectation that 1) FCoE is a panacea for the ills of the Data Center (it’s not), and/or 2) FCoE is something different than FC (it’s not). After all, converging networks so that both LAN paradigms and SAN paradigms are facilitated isn’t something that can be or should be rushed. We’re talking about making sure that we can leverage existing deployments while future-proofing the Data Center at the same time.
Trivial? I think not.
If there seems to be some sort of grievance that FCoE has not dominated the marketplace in the short span of time it has been available, well, there’s little that I can do about tempering a mad rush to worldwide dominance.
But if it comes down to ensuring success from both a LAN deployment and SAN deployment scenarios, it seems to me that at least this vendor is striving for the intelligent way of deploying FCoE. By maintaining both LAN and SAN requirements at each stage (tier, or layer) in the Data Center, we are providing customers a greater choice without forcing them to choose.
As of this writing, true Multihop FCoE has only been available since late 2010, and Director Class Multihop FCoE for less than a month. It seems to me that discussing FCoE adoption in terms of “dramatic changes” in the data center in that time frame might be just a wee bit premature.Tags: