Fibre Channel over Ethernet is coming to Windows environments!

Although there is no word on a Fibre Channel over Ethernet (FCoE) initiator in the vein of their wildly successful iSCSI offering, Microsoft announced today that they will be creating a logo program with test requirements for the new protocol. This certification program will likely follow the company’s similar work with iSCSI and Fibre Channel adapters and a host of other products to improve functionality and interoperability in the Windows market.

This announcement shows that Microsoft recognizes the potential of FCoE as a major force in future data centers as well as the possibility of difficulty once these products are released. Reading between the lines of the release leads one to a few other conclusions:

• The Windows FCoE logo is still a year off, suggesting either that Microsoft has some work ahead of them to develop logo requirements or that FCoE implementation isn’t likely to come before then, or both
• There is no mention of a native FCoE initiator, suggesting that no such product is imminent despite calls for such a move
• Microsoft is drawing a sharp line between existing Fibre Channel products and drivers and new FCoE offerings, firmly separating the two markets and requiring that no FCoE products bear a FC logo and vice versa

The full release is in Microsoft’s Windows Logo newsletter for March 10, 2009, which has been mailed but has not yet appeared on the company’s web site.

© Stephen Foskett for Gestalt IT, 2009. | Microsoft Recognizes FCoE With Logo Program
Read more posts categorized as All, Exclusive, Featured, Networking, Storage, Top Story

It does not cover SAN in any detail and the FC coverage is limited to this is how you present a LUN as a fibre channel device but this led on to some interesting conversations around the complexity of FC vs iSCSI.

I, for sometime, have been saying that the complexity of FC is over-stated and actually it is not really any harder than iSCSI. This often leads to looks of disbelief and complete disagreement, it is almost as if I am spouting heresy. The iSCSI camp think I am mad and the FC camp seem to think that I’m diminishing them.

But, if you take OnTap; there is really very little difference in how you present a iSCSI LUN compared to how you present an FC LUN. It is certainly no harder to do FC from an array management point of view.

And then we go to the host; lets take Windows for example. Now this is where I think a lot of the perception of the simplicity of iSCSI comes in; Microsoft have implemented a very nice software initiator, it’s there and it’s standard. A bit of pointing and clicking and you are there.

Unfortunately, traditional FC cannot be implemented completely in software and needs FC HBAs, hence we need to install additional drivers and software to make it work; these are not part of the standard Windows build and suddenly it all becomes ‘complex’.

If we go to Unix, we end up mucking about configuration files in general for both iSCSI and FC; so really it’s not any harder to do FC than iSCSI.

So if it’s not hard to do at the host level and if it’s not hard to do at the array; where is it hard? And this is where I think it becomes more interesting; it’s the network! Is a large Data Centre IP network harder to set-up than a large Data Centre FC network?

Arguably, the FC network is easier but it is different. In the FC network you have a lot less to worry about; you run less protocols, services, it’s non routeable, the security model is simpler, there is less potential for different workloads to clash, you do not have address space management to worry, you do not have name services to worry about and if I were a Network Admin, I would argue that it’s them who are being diminished by this constant claim that iSCSI is easier.

To do either iSCSI or FC properly is probably equally hard. If you just want to bung a block-level array in and do not care about segregation of traffic, quality of service, don’t care whether your IP back-up traffic and IP storage traffic contend and make your back-ups over-run. If you know you’ve got enough headroom on your existing IP network to carry your block traffic, go ahead with iSCSI; it’s easier because you’ve already got the infrastructure in place.

But if you want put in place a dedicated storage network; the choice is not as clear-cut as people would like to make out. Even when you start looking at cost; yes GbE is cheaper than FC but FC is generally running at 4 gig now and is faster. FC ports are in my experience are significantly cheaper than 10GbE ports. So if you need the throughput, then FC might well be cheaper than iSCSI.

There might be a small saving in the number of FTEs you require as you could have a single Network team but I believe that FC is actually so simple that if you get over the politics, you could have a single Network team which manages both FC and IP. This is purely politics and a turf-war!

If you are a small shop and you have just a few administrators who do everything, iSCSI might also make sense but don’t believe FC is hard; administering a small SAN with a couple of switches might not add a huge amount of additional overhead.

Neither iSCSI or FC are wrong answers but make sure that when you have got to the answer, you show your working. And when a vendor tells you what the answer is, ask them to show your their working and challenge it.

Of course, if I was building a green-field data-centre and could simply start again, I’d probably look at putting in Data Centre Ethernet which would give me the option of FCoE. I would have a single Network team from the get go.

It’ll be interesting to see if Microsoft bundle a software initiator for FCoE into Windows at some point; then I think we’ll see perceptions of complexity change again.

Yes, I’ve completely ignored NAS but actually many of the same arguments apply.

I’d welcome some thoughts; that’s if anyone is still reading and not exploded in apoplectic rage at the heretic!

© Martin for Gestalt IT, 2009. | Protocols, Religions and Heresy!
Read more posts categorized as All, Featured, Storage