Microsoft is a controversial company, generating a mix of criticism and praise everywhere they are involved. Although I’m definitely a Microsoft skeptic, I’ve been pleased by much of the work they have done in my field of enterprise storage. Their client-side (“initiator” to us storage folks) work has been especially notable, making me wonder why no other operating system vendor has as diverse and full-featured storage support as Microsoft. I would go so far as saying that the iSCSI SAN revolution would not have happened if not for the folks up in Redmond.
Enterprise storage is in the midst of another shift these days. iSCSI moved low-end and midrange servers to SANs by leveraging Ethernet for connectivity. Now, the storage and networking industry is pushing to do the same for high-end Fibre Channel SANs, bringing Fibre Channel over Ethernet (FCoE) to life before our eyes. Although users are not yet on board, the dominance of FCoE seems almost certain to many industry watchers.
Where Is Microsoft?
But where is Microsoft when it comes to FCoE? I see no public statements of support for the protocol. I see no participation in FCoE standards-setting (though the company did recently join the FCIA as an “Observer”). Most importantly, I see no software features developing solid enterprise support for FCoE within the Windows operating system. Put simply, Microsoft does not seem to be participating in FCoE development, either on the initiator or target side.
Some may say Microsoft doesn’t need to get involved. After all, most FCoE integration will rely on third-party hardware and drivers that appear to be standard Fibre Channel HBAs to Windows. But this argument is spurious: Microsoft never got very involved in Fibre Channel either, and the confusing state of third-party FC SAN connectivity in Windows is a stark contrast to the solid and reliable iSCSI initiator. The fact that Microsoft embraced iSCSI while allowing third parties to “own” FC is an indictment of their stance towards FCoE.
Then there is Microsoft’s FCoE logo program. In March, I was pleased to note that Microsoft would at least add FCoE to their Windows Logo program. Yet there has been no sign of the Logo Kit, promised for December, and just one mention of this program in the last year: Microsoft delayed enforcement of FCoE Logos until December of 2010. As far as an outside observer would know, Microsoft hasn’t moved forward with even the most basic FCoE support, a Logo program, in a year.
I am not suggesting that Microsoft must develop software FCoE targets. In fact, a Microsoft FCoE target might prove to be counter-productive, discouraging storage vendors from competing. A software initiator would be welcome, but the high-end target audience makes this less critical than for iSCSI. Instead, Microsoft should begin to develop a converged I/O framework around the DCB standards, including a detailed FC and FCoE integration architecture for third-party hardware and software.
Unacceptable
The current state of affairs is simply unacceptable. Consider the systems using FCoE: Many criticize Microsoft’s presence in the data center at all, but no one can deny their power there. Microsoft Windows Server powers most enterprise compute tasks today, running on almost three quarters of data center servers. Windows Server will almost certainly be the leading user of Fibre Channel over Ethernet connectivity.
On the other side of the equation, storage and networking vendors from EMC and NetApp to Cisco and Emulex are pushing hard for the FCoE transition. Regardless of end user indifference, FCoE will dominate SAN deployments in the next few years. It’s a question of “when” not “if” – DCB and FCoE will take the data center by storm.
Certainly, Microsoft can simply allow the FCoE ship to sail without them on board. They can allow third-party HBA/CNA, server, and networking vendors to bring FCoE support to Windows. But this represents a massive missed opportunity for the company and a capitulation in the high end of the enterprise market. Microsoft must immediately move to take leadership in FCoE: Add corporate resources, step up standards efforts, publish the Logo Kit, and develop a framework of support.
Disclaimer: I am a Microsoft MVP in the area of storage. Their kind treatment of me obviously didn’t color my perception of them with regards to FCoE. I also have an NDA with Microsoft, and they have briefed me on future Windows Server and storage developments. Nothing in this post should be construed to reveal the company’s future plans.
Good thoughts Stephen, let me add a couple of points:
– Microsoft did attend some of the T11 FC-BB-5 meetings (Bob Griswold can be found in the attendance logs)
– See this MS Logo Program newsletter http://www.microsoft.com/whdc/whql/resources/news/WHQLNews_061708.html for their “official position”
– The CNA adapter vendors and storage vendors are supporting Windows environments (really to the OS, it just looks like the same certified FC HBA), but I agree with your point that Microsoft should embrace the solution.
– VMware was also a big participant in the iSCSI revolution & VMware also supports FCoE, so any perceived lack of flexibility from Microsoft has the potential to drive people to put their Windows in an ESX VM
– What in the world is that logo??
Thanks for the quick FCoE responses, Stu!
– I don’t know who attended what meetings or what they did. I appreciate the info and am glad Microsoft is present!
– That newsletter is from June ’08 and was superseded by the March 10, ’09 announcement of logo support. We need word more than once a YEAR.
– VMware should be applauded for their iSCSI work, especially in ESX 4. This is all the more reason Microsoft should work hard to lead here – any Windows Server work benefits Hyper-V!
– Funny you should ask about the logo – I’ll cover that another time. Hint: It’s official!
Stephen-
I had a chance to work with FCoE prior to the release of GA hardware from Cisco, Emulex and QLogic. I’m an advocate of the technology, so don’t take my statements as against FCoE.
From an OS perspective, FCoE is no different than FC. A storage controller (HBA, CNA) connects to a storage target over a SCSI protocol.
But FCoE does require a CNA, so it’s more like FC (from Microsoft’s perspective) than iSCSI, which requires only a software initiator.
Anyhow, my perspective is from the technical side: If FCoE is no different than traditional FC from the OS perspective, why should MS take proactive position on it at all?
MS created an iSCSI initiator because other operating systems had free/included initiators. Certainly a software solution plays to their hand, but I’m confident that they were simply enabling solutions competitive to similar Linux and other OS solutions that were free or included in the base operating systems.
MS is not in the business of manufacturing HBAs or CNAs. Why should they be treating FCoE with preference over any other connectivity option?
Maybe I am missing something with my recent move from the world of network-connected SAN arrays to internal PCIe connected NAND Flash storage. Is there something from an OS perspective that MS can do to manage/support FCoE over and above what the CNA vendors can provide? Or are you simply stating that they should support the FCoE transition from a programatic/marketing perspective? There isn’t a SCSI logo vs. FC logo vs. iSCI logo, an FCoE logo would stand out like a sore thumb, IMO.
Counter arguments welcome, willing to listen!
Excellent points, Stephen.
However, I remember reading one of Greg Ferro’s posts (http://bit.ly/aOSSto) recently from last year, where he laid out a case against FCoE.
If his assumptions are correct, and when the datacenter inevitably converges, would FCoE still be a player?
Should Microsoft deploy resources to create products for FC0E if it is, in fact, an interim step?
I simply want Microsoft to be an active participant in the FCoE ramp-up. I think their help will ease adoption pain and would be good for them in the long run.
As for the “why” question, I do see the point that Windows does not *need* any special Microsoft-created FCoE support. But neither did iSCSI, TCP/IP, Wi-Fi, etc. Microsoft could have left all of this to the ISVs and OEMs. But that was a disaster! Remember the bad old days of 802.11 drivers? PPP software? Assuming FCoE becomes popular, I don’t want it to look like that…
Finally, there is the question of a software initiator. Although again Microsoft doesn’t need one, it would be nice if they created one. The iSCSI initiator is a major positive from Redmond, and other operating systems have FCoE support now. Linux, for example, has Open-FCoE in the kernel (as of 2.6.29). Again, Microsoft doesn’t need to do this but would benefit if they did.
Thanks for the comment, Bill!
Actually, I never thought about the possibility of a software-only initiator (ala iSCSI). That’s actually an intriguing way for them to influence the technology without playing favorites. I can see you point.
right on @sfoskett
the problem is that there are no third party fcoe targets for windows either. starwind has a fcoe initiator, but that’s it. as far as I understand, iSCSI (for all its faults) just has a bigger mindshare. it is also vastly easier to hire someone with iSCSI expertise than a FC one. I could teach my mom on creating a iSCSI target on Server 2012, or even FreeNAS. FC is only for the high end datacenters.