« Join me at EMC World 2015! | Main | Slow Drains are impacting your SAN! »

05/19/2015

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Stu Miniman

Hi Erik - thanks for the very long post. I completely agree with you that it is very early days for Server SAN and that is a big point of why Wikibon strongly believes in the potential of that new architecture. If you've seen David Floyer's Flash as Memory Extension (FaME) - it is likely that EMC's DSSD will fit under this heading and FaME fits under the Server SAN umbrella - it's about new ways of combining and scaling storage and compute which is different from the traditional FC or iSCSI SAN (or NAS) which separated compute workloads from storage. FC has been a great tool and is not dying any time soon (we expect that by 2020 it will have dipped but even then won't be gone) - IT is never good at stopping anything, it's always additive.
Cheers,
Stu

Erik Smith

Hi Stu, with regards to the length of the post, despite literally hearing your voice in my head saying "keep it to 1000 words or less", I find it hard to strike a balance between "telling the whole story" and "keeping it short". As a result, I always err on the side of providing more information so that my readers can understand exactly what my facts and assumptions are. This tends to make my posts "very long". On the upside, know that I spend days agonizing over my ability to backup every word I write, so hopefully the quality of the post will make up for the excessive quantity.

Thanks for the pointer to David's FaME post, it looks really interesting and I'll spend some time getting familiar with the concept.

With regards to FaME's applicability to DSSD. Let me state up front that I have no idea what DSSD is planning in the short or long term (perhaps you have some insight that I don't) but since they are currently packaged as an array, I'm confused as to how they would fit under the Server SAN umbrella regardless of their choice of connectivity protocol?

In any case, my blog post was intended to call attention to the fact that the enterprise customers that I spoke with have little interest in moving away from FC and have a list of (mostly) technical reasons for this position. I also hoped to encourage those who rely on FC for stability to embrace their inner FC Tree Hugger and stay on FC unless they have a compelling reason (e.g., automation) to move to IP Storage or Server SAN.

Regards, Erik

Gary Olson

My I give you a lossles highspeed Fist bump?
Would you mind terribly if I just attach this whole blog to my next FC SAN RFP?

Erik Smith

Hey Gary, absolutely! Please feel free to use it to advance the cause..

FC Tree Huggers of the world, unite! :)

Yaron Haviv

Erik,

you made good points, but still just need to look at the numbers compare the growth in FC attached storage to Cloud, Hyper-converged, NAS, Object, Hadoop, .. and all the rest of the non FC storage

if FC is so great why don't Amazon, Google, Azure use it ? why do we see Nutanix and other options (including 2 competing EMC hyper-converged solution) growing so fast ? why isn't Oracle Exadata or Teradata built on FC ?

I think the traditional (FC SAN) storage camp will be challenged to provide the same cost effectiveness and usability (and performance) provided by all those IP based solutions, they will find ways to provide high-availability and resiliency without LUNs, WWNs and Zones, having 40Gb or 100Gb is better than having 16Gb with congestion control, and SDN will provide pretty nice isolation and QoS.

talking to FC SAN users in an EMC show, seems a little biased POV IMO, they are not likely to adopt the new technologies, but other groups in the organisation will build their fast growing VDI, BigData, .. solutions without turning to the SAN guys for help, or consume pre-integrated "SANless" appliances, some Application guys may even take out the credit card and use AWS services for non sensitive data without the need to wait for IT to build it all, especially when they can get it at fraction of the cost.

BTW i have a blog post on that topic:
http://sdsblog.com/2014/11/18/why-the-heck-do-we-need-san/


Regards, Yaron

Bob Smith

Hey Erik, great post, as usual. Another thing to consider in Ethernet based storage, iSCSI and NAS in particular is that while TCP will recover the corrupted frame, in the case of high throughput streams, this will invariably pile up additional losses and delays as well. These will eventually affect the SCSI operations at some level. I am reminded of a paper Mikkel Hagen wrote at UNH regarding TCP resends in iSCSI networks, where his experiments showed a lot of BW being used, but a full third of it was resends from dropped packets.
(M. Hagen and E. Varki, “iSCSI on a converged data center network,” in 22nd International Conference on Parallel and Distributed Computing and Communication Systems (PDCCS), pp. 97–102, ISCA, 2009.) - Sorry can't find a link to full text.

His dissertation discussed the issue as well, but not as specifically as in the targeted paper: https://www.iol.unh.edu/sites/default/files/knowledgebase/dcb/mhagen-dissertation.pdf

Regardless, FEC would be a welcome addition to the Ethernet toolbox, that's for sure.

Erik Smith

Hi Yaron, thanks for taking the time to comment. I actually agree with most of your points as they apply to non-traditional (e.g., Platform 3) applications. I'll stand by the statements I made in the post as they apply to traditional apps for the reasons I provided.

Regards, Erik

Erik Smith

Hi Bob, thanks for reading and commenting! I'm familiar with some of Mikkel's excellent work and enjoyed his dissertation.

It sounds like you're describing the difference between throughput and goodput and the approaches we can use to maximize the efficient use of the network.

In any case, great point about the impact of loss on TCP and how it can have secondary effects.

The comments to this entry are closed.

Disclaimer

  • This is not an official EMC blog.
    The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.