Comments on: Storage Convergence: Fibre Channel over Ethernet http://www.linux-mag.com/id/7234/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: kensandars http://www.linux-mag.com/id/7234/#comment-6135 kensandars Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7234/#comment-6135 Beware the vendor of a legacy technology which starts spouting catch phrases such as "based on established technology", "derived from mature software", and "uniquely positioned to enable heterogeneous deployments". This is marketing blurb and needs to be recognized as such.<br /> <br /> With 10GbE you can roll out iSCSI/TCP/IP now and have convergence without buying funky unproven switching technology. Alternatively if your company is heading down the Infiniband path then consider iSCSI/iSER/IB as your storage protocol (or SRP/IB if you prefer).<br /> <br /> One of the Fibrechannel requirements is a reliable and predicable physical network. This was the whole reason to invent FC in the first place. Does ethernet technology (when augmented by the NEW features in the article) now provide this? What happens when limits are reached in these new switches which must deployed in order to allow the FCoE traffic to flow? How does this "mature software" react to the different characteristics of the ethernet fabric? How is your company's financial officer going to react when you tell her these bleeding edge switches must be purchased (at what cost?) rather than submitting a request for more of the same switches that were purchased last time? Beware the vendor of a legacy technology which starts spouting catch phrases such as “based on established technology”, “derived from mature software”, and “uniquely positioned to enable heterogeneous deployments”. This is marketing blurb and needs to be recognized as such.

With 10GbE you can roll out iSCSI/TCP/IP now and have convergence without buying funky unproven switching technology. Alternatively if your company is heading down the Infiniband path then consider iSCSI/iSER/IB as your storage protocol (or SRP/IB if you prefer).

One of the Fibrechannel requirements is a reliable and predicable physical network. This was the whole reason to invent FC in the first place. Does ethernet technology (when augmented by the NEW features in the article) now provide this? What happens when limits are reached in these new switches which must deployed in order to allow the FCoE traffic to flow? How does this “mature software” react to the different characteristics of the ethernet fabric? How is your company’s financial officer going to react when you tell her these bleeding edge switches must be purchased (at what cost?) rather than submitting a request for more of the same switches that were purchased last time?

]]> By: ibh http://www.linux-mag.com/id/7234/#comment-6136 ibh Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7234/#comment-6136 Another protocol, ATAoE, was very interesting. Simple enough to be implemented in hardware, it was an inventive solution that leveraged the strengths of every technology it involved. FCoE, in comparison, seems like it was levered (eg, with a prybar) to fit the involved technologies. What's next, IB over WiFi? Really, I'm at a loss to understand what problem this is destined to solve. Another protocol, ATAoE, was very interesting. Simple enough to be implemented in hardware, it was an inventive solution that leveraged the strengths of every technology it involved. FCoE, in comparison, seems like it was levered (eg, with a prybar) to fit the involved technologies. What’s next, IB over WiFi? Really, I’m at a loss to understand what problem this is destined to solve.

]]> By: robaronson http://www.linux-mag.com/id/7234/#comment-6137 robaronson Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7234/#comment-6137 If you have worked in the storage arena before you'd kow there are many challenges to be overcome when building out a new storage environment. Many of today's protocols have limitations such as security and reliability in iSCSI. If you are running a mission critical data base you can't afford to lose a packet due to congestion or latency in your switch fabric. Fiber channel prevents these problems from disturbing data flow but a significant cost in both hardware and expertise. As an installer of SAN equipment I can attest to the difficulty people have in configuring FC fabrics. <br /> <br /> On the other had, when customers build iSCSI storage systems they are often too casual with the deployments and give up a significant level of performance and reliability by using generic ethernet adapters and shared switches that are usually busy doing other tasks.<br /> <br /> With the advent of the new FcoE and the new CCE protocols we can reap the benefits of using a well understood infrastructure like ethernet while removing some of the limitations of existing protocols like iSCSI. If you have worked in the storage arena before you’d kow there are many challenges to be overcome when building out a new storage environment. Many of today’s protocols have limitations such as security and reliability in iSCSI. If you are running a mission critical data base you can’t afford to lose a packet due to congestion or latency in your switch fabric. Fiber channel prevents these problems from disturbing data flow but a significant cost in both hardware and expertise. As an installer of SAN equipment I can attest to the difficulty people have in configuring FC fabrics.

On the other had, when customers build iSCSI storage systems they are often too casual with the deployments and give up a significant level of performance and reliability by using generic ethernet adapters and shared switches that are usually busy doing other tasks.

With the advent of the new FcoE and the new CCE protocols we can reap the benefits of using a well understood infrastructure like ethernet while removing some of the limitations of existing protocols like iSCSI.

]]> By: kensandars http://www.linux-mag.com/id/7234/#comment-6138 kensandars Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7234/#comment-6138 Quote: "... limitations such as security and reliability in iSCSI".<br /> Do you intend to support this ambit claim with specific examples? Are you concerned about the protocol or certain implementations?<br /> <br /> Quote: "... I can attest to the difficulty people have in configuring FC fabrics."<br /> How does FCoE address these difficulties?<br /> <br /> Quote: "... often too casual with the deployments ..."<br /> Why are customers going to be any less casual with deploying FCoE?<br /> <br /> Quote: "If you are running a mission critical data base you can’t afford to lose a packet due to congestion or latency in your switch fabric".<br /> That's plain fear-mongering. Packet loss (which happens significantly less frequently than some people try to suggest) is handled by different layers in different protocols. The reality is that unless there is catastrophic system failure the data transfer is delayed (either queued or retransmitted). Customers pay large money for HA solutions to protect data and to ensure continuity of services in the case of system failure.<br /> <br /> Quote: "well understood infrastructure like ethernet"<br /> Now your argument implies that ethernet is good enough to transport mission critical data. ;-) But it's not ethernet; it's Converged Enhanced Ethernet. It's a new hack to an existing protocol layer which requires new network hardware to support it. How will non-CEE switches handle the accidental presence of the new (hence unrecognised) frame type? What will customers have to learn to configure this new infrastructure? How much will they have to pay? Quote: “… limitations such as security and reliability in iSCSI”.
Do you intend to support this ambit claim with specific examples? Are you concerned about the protocol or certain implementations?

Quote: “… I can attest to the difficulty people have in configuring FC fabrics.”
How does FCoE address these difficulties?

Quote: “… often too casual with the deployments …”
Why are customers going to be any less casual with deploying FCoE?

Quote: “If you are running a mission critical data base you can’t afford to lose a packet due to congestion or latency in your switch fabric”.
That’s plain fear-mongering. Packet loss (which happens significantly less frequently than some people try to suggest) is handled by different layers in different protocols. The reality is that unless there is catastrophic system failure the data transfer is delayed (either queued or retransmitted). Customers pay large money for HA solutions to protect data and to ensure continuity of services in the case of system failure.

Quote: “well understood infrastructure like ethernet”
Now your argument implies that ethernet is good enough to transport mission critical data. ;-) But it’s not ethernet; it’s Converged Enhanced Ethernet. It’s a new hack to an existing protocol layer which requires new network hardware to support it. How will non-CEE switches handle the accidental presence of the new (hence unrecognised) frame type? What will customers have to learn to configure this new infrastructure? How much will they have to pay?

]]>