Why does Microsoft prefer iSCSI over FCoE?

A month ago Stephen Foskett complained about lack of Microsoft’s support for FCoE. I agree with everything he wrote, but he missed an important point: Microsoft gains nothing by supporting FCoE and potentially a lot if they persuade people to move away from FCoE and deploy iSCSI.

FCoE and iSCSI are the two technologies that can help Fiber Channel gain its proper place somewhere between Tyrannosaurus and SNA. FCoE is a more evolutionary transition (after all, whole FCoE frames are encapsulated in Ethernet frames) and thus probably preferred by the more conservative engineers who are willing to scrap Fiber Channel infrastructure, but not the whole protocol stack. Using FCoE gives you the ability to retain most of the existing network management tools and the transition from FC to FCoE is almost seamless if you have switches that support both protocols (for example, the Nexus 5000).

You’ll find introduction to SCSI, Fiber Channel, FCoE and iSCSI in the Next Generation IP Services webinar.

However, as FCoE is a simple wrapping magic, Ethernet infrastructure in your data center has to provide lossless transport required by Fiber Channel. No problem, Data Center Bridging addresses that need ... but might also require a forklift upgrade of your networking infrastructure. The need for infrastructure upgrade is (in my opinion) Microsoft’s problem: if their customers deploy FCoE, they’ll spend their budgets on infrastructure upgrades; if they embrace iSCSI, their existing infrastructure will work just fine and they will be able to spend their money elsewhere (for example, buying more Microsoft products).

Obviously, that’s just my personal opinion ... please use the comments to tell me how wrong it is.

9 comments:

  1. I think you have been reading my mind. Microsoft makes most of its money from medium and small companies, and these people have finite budgets. Fibrechannel doesn't reduce cost, it increases cost by forcing companies to deploy low latency, high speed, zero loss networking when other technologies are good enough.

    I agree with your opinion. Fibrechannel looks like SNA to me.
  2. In M$ doesn't support FCoE natively then this is opportunity window for manufacturers of FCoE HBA's which looks like native FC HBA's looking from the bus side. This solves the problem of performance, CPU offload and every OS which support FC adapters will work with this solutions.
  3. So if Fibre Channel is a dinosaur, does that make FCoE a Komodo Dragon or a platypus?
  4. If Fibre Channel is a dinosaur FCoE is a duck. Dinosaurs evolved into birds ya know. :)
  5. Ah, you mean like ATM 8-)

    http://blog.ioshints.info/2009/06/atm-is-like-duck.html
  6. So is it pretty safe to say that for new installs it makes sense to just go with iSCSI?
  7. "Guest" I'll take a unpopular stance and say I like FC. Is it limited in it's life? Probably.. But right now there are things that make it the lowest common denominator. When setting yourself up for tape or backup to tape too often the interface thats available is FC. When looking at inline encrypting from vendors like brocade or cisco it's FC. When looking at vendor extension tools like V-Plex from EMC it's based off of FC.

    So while I agree with the arguments from the Author it's more from a networking perspective. If you look at it from a SAN admin's perspective you see things a little differently. Ultimately though FCOE or iSCSI will eventually be adopted more and FC will go away.

    Thats just the way I see it.
  8. I stopped caring about "popular" years ago and decided it matters more to get things working.

    First of all, thanks for a healthy dose of reality. I was focused too much on storage arrays and forgot to check the tape part of the equation.

    However, looking at the bigger picture, FCoE by itself makes no sense to me. It's a viable integration technology if you have FC network (or are forced to use one, as you explained), but I see no reason why I'd deploy it by itself. Am I wrong?
  9. 1. FC is supported by Windows. Hyper-V even has a virtual FC capability.
    2. You don't need built-it OS support to deploy something. That's what the install button is for. The built-in iSCSI target on WIndows is s*** anyway. You can't make disks into LUNs. LUNs can only be made from VHD files, not even VHDX.
    3. FCoE advocates can argue that FCoE makes sense since many new iSCSI deployments use DCB anyway.
    4. I agree. The different SAN protocols provide too many solutions to the same problem. At most we should have two protocols. Raw L2 ones like AoE (I don't think FCoE has a networking layer either) or TCP/IP ones like iSCSI. We don't need 40 different protocols like iFCP or FCPIP. There is a reason the whole world use TCP/IP and ethernet. You don't need custom (overpriced) hardware to get better bandwidth. Just make Ethernet faster and everyone is happy.
Add comment
Sidebar