iscsi-or-fcoe-flogging-obsolete-dead.html

---
date: 2014-02-24T06:27:00.000+01:00
tags:
- data center
- SAN
- FCoE
title: iSCSI or FCoE – Flogging the Obsolete Dead Horse?
url: /2014/02/iscsi-or-fcoe-flogging-obsolete-dead.html
---

<p>One of my regular readers sent me a long list of FCoE-related questions:</p>
<blockquote class="cite">I wanted to get your thoughts around another topic – iSCSI vs. FCoE?  Are there merits and business cases to moving to FCoE? Does FCoE deliver better performance in the end? Does FCoE make things easier or more complex? </blockquote>
<p>He also made a very relevant remark: “<em>Vendors that can support FCoE promote this over iSCSI; those that don’t have an FCoE solution say they aren’t seeing any growth in this area to warrant developing a solution</em>”.<!--more--></p>
<p>I think FCoE or iSCSI is the wrong question to ask. A better question would be “<em>FC or iSCSI?</em>” If you <a href="https://blog.ipspace.net/2011/02/why-would-fcfcoe-scale-better-than.html">believe that Fibre Channel management capabilities</a> outweigh the complexity of yet another layer-3 protocol in your network, then it makes sense to stick with Fibre Channel protocol stack, and introduce FCoE in the access network. If you’re a smaller shop with only one or two storage arrays, I don’t think the potential advantages of FC management justify introducing an additional protocol stack. </p>
<p class="info">Regardless of <a href="https://blog.ipspace.net/2011/07/is-fibre-channel-switching-bridging-or.html">what people think</a>, FC is a full-blown protocol stack with its own routing protocol and hop-by-hop forwarding behavior. Running FC or <a href="http://blog.ipspace.net/2011/06/beauties-of-dense-mode-fcoe.html">FCoE in dense mode</a> is equivalent to running IPX (or AppleTalk or DECnet or OSI) in parallel with IPv4 and IPv6 (you do run IPv6, don’t you?).</p>
<p>Assuming there’s a reason to use FC protocol stack, does FCoE make sense? Absolutely, at least in the access (server-to-ToR switch) layer – FCoE reduces the number of physical server interface cards, cables, and switch ports, while offering better performance than 8 Gbps FC (and I have yet to see a server that really needs two 8Gbps FC uplinks).</p>
<p>Beyond the access layer we’re dangerously close to an area polluted with religious wars, and I have no plans to start another one.</p>
<p>However, while <em>FC or iSCSI </em>might have been a crucial question a few years ago, we should start looking past LUN-based storage in heavily virtualized or cloud environments and ask other questions:</p>
<ul class="ListParagraph"><li>Should we use SCSI-based (FC, FCoE, iSCSI) or file system based (NFS, SMB) protocols for virtual disk access?</li>
<li>Should we use LUN-based storage arrays or storage solutions with a distributed file system (which makes redundant architectures and storage replication infinitely easier than LUN-based solutions)?</li>
<li>Should we use dedicated storage devices (storage arrays) or servers with DAS disks and a distributed file system?</li>
<li>Should we run DAS-based distributed file system on hypervisor hosts (example: VMware VSAN, Nutanix) for a truly converged solution?</li>
</ul>
<p>We’ll have a bit more in-depth discussion in the upcoming <a href="http://www.ipSpace.net/BCloud">Designing Private Cloud Infrastructure webinar</a> and during the <a href="http://www.interop.com/lasvegas/schedule-builder/session-id/18">Infrastructure for Private Clouds Interop workshop</a>, and I know how major public cloud providers answered those questions (hint: they don’t have storage arrays). What would you do if you were planning to build a new data center or private/public cloud?</p>