Comment from: Greg Carter [Visitor]
Greg CarterI understand why SSD's aren't a complete panacea when incorporated into block storage systems but, being aware of disk enclosure bandwidth limitations and the cost of SS's.

Understanding where NAS came from and where it plays (sold for Auspex), I wonder which technical issues/limitations have prevented someone like NetApp from incorporating SSD's into arrays managed by the "SAN Mode."

As I said, I know what some of hte challenges are, but I don't think SAN Mode has been a game changer, and as innovative as NetApp and others have been, I would think they would have looked at this unless there were some serious obstacles.

Any thoughts on this (and feel free to let me know if this is a stupid question though I have to admit I will be very hurt and offended :-) would be appreciated and of interest.
01/14/11 @ 20:02
Comment from: Tony Asaro [Member] Email
Greg - thanks for engaging in a discussion on my blog.

The issue of SSDs to me is a question of price/performance. I think the only way to make SSDs universally valuable to customers is leveraging sub-LUN tiering. This is technology that moves dormant data within a volume and moves it to lower cost storage - effectively spreading a volume across different cost tiers of storage within an array. Depending on the vendor the size of the "page" will range - 2k, 42 MB, 256 MB, etc.

Since you are joining Dell you will be happy to know that Compellent is the leader in this technology and does it at the 2k page size (arguably smaller is better in this case). They also uniquely can move active read data to lower tiers - which is valuable and cool.

01/17/11 @ 11:10
Comment from: Ian Duncan [Visitor]
Ian DuncanTony,

Interesting view - I agree wholeheartedly that there is too much cold data on expensive, high-performance systems. It could be argued that Scale-Out NAS is actually going to perpetuate the issue (the easiest thing to do is keep doing what you're doing and if the Tier 1 systems allow you to get bigger then you could keep doing stupid things for longer). The issue of why people don't put in place a dedicated archive tier goes beyond migration (and/or stubbing) - it needs to be economically very compelling (I'd suggest somewhere in the region of 25% of the cost of doing what you're already doing) and non-disruptive to the work-flow. This raises the point you make about an application still being able to find the data when it's moved but even where there isn't an application that's accessing that content (general file shares etc) you still need to be able to balance retrieval needs (albeit most likely on a very infrequent basis) and retention (whether it's for compliance, governance or just plain 'keeping-it-for-as-long-as-I-think-I-should-have-it-around-reasons'). I do believe that the shift in recent years to much more ubiquitous disk-based DR tiers is likely to be the straw that breaks the camels back for many customers. They may be happy with their primary and DR tiers in terms of performance and scalability but every new MB of information that is generated is now needing to be stored, managed and protected across multiple, expensive and high performance tiers and as such they are at least open to the idea that a dedicated archive tier (one that is is designed exclusively for retrieval and retention) might make more sense...
03/07/11 @ 17:35
Comment from: Tony Asaro [Member] Email
Ian - I believe there are two challenges - there are too few solutions that can provide the discovery you need and then move that file data efficiently, out-of-band and heterogeneously. And even if you did - what do you move it to? There are solutions out there but they are still relatively new, or they were just provided by startups, or they just haven't been marketed sufficiently. I think companies are open to a solution but no one has stepped up with the answer yet.
03/09/11 @ 11:25
Comment from: Ian Duncan [Visitor]
Ian DuncanTony,

Identification and the subsequent migration are clearly the major challenges. In the interests of disclosure I work for a storage company that focuses exclusively on storage for long-term data retention. We regularly see customers who don't have a dedicated data mover (either an archive or ECM application or something home-grown) address project data first (it's easier to identify, it's less likely to be accessed regularly and in many cases it's not inextricably linked to an application which causes the stubbing issues you mention). To your point about 'where' do you place your long term data this issue historically has been that it's a binary decision - either it stays on disk (just because it's easiest and it checks the 'it's there if I need it' box) or it goes to tape (it's cheap) but then they worry that on the off-chance that they do want to retrieve the data they'll appear to be sluggish in the eyes of their users. I think the future state is actually a tiered archive (as opposed to an archive tier) - a platform that can balance retrieval, retention and recovery for data and if the performance is adequate then why not place the data there initially (thus mitigating the original concerns about migration).

03/16/11 @ 15:06

Leave a comment

Your email address will not be revealed on this site.
(Line breaks become <br />)
(For my next comment on this site)
(Allow users to contact me through a message form -- Your email will not be revealed!)
« Nirvanix: Cloud Storage for the Enterprise (For Real)Dell and Compellent: The Implications »