SolidFire pulls off gloves for unholy storage ding-dong. Ding-ding! Punchy all-flash array startup SolidFire has taken the gloves off in its competition with EMC, NetApp and Pure Storage by releasing competitive architectural comparisons singling out weaknesses in their products. You can get comparison docs vs NetApp all-flash FAS, EMC’s XtremIO and Pure Storage’s FlashArray by filling in …
Hi all, Dimitris from NetApp here.
It's really easy to point to features the competition doesn't have. For instance, SolidFire has a weak FC and zero NAS capability.
That's stuff that's pretty hard to implement.
In the grand scheme of things, if the inline data efficiencies in ONTAP plus frequent dedupe (say every 5 minutes) are enough, the comparison becomes a mostly religious one.
Ultimately data reduction is just one way to save costs, and there are many places where costs can be saved.
This might help:
http://recoverymonkey.org/2015/06/24/netapp-enterprise-grade-flash/
Thx
D
Amazing, a NetApp'er who thinks NetApp is good with efficiency.
Dedupe and compression (dont turn this on if you dont want performance to stink on anything but AFF) is only a sticking plaster to the fact that WAFL is hideously inefficient and has horrendous RAW to usable capacity. Post process dedupe is pretty poor, even if 5 mins afterwards as you still have to buy the capacity in the first place.
Then you have management complexity, expensive training to learn how to optimise the things, numerous places to manage, aggregates, pools blah, blah etc.
FAS might be efficient compared to EVA but not the newer tech.
"FAS might be efficient compared to EVA but not the newer tech."
FAS was never particularly efficient compared to EVA anyway, where it did win was FAS had all the latest must have features (even if you couldn't use them together) that EVA lacked due to lack of investment.
Chris, thanks for holding us accountable. These documents are meant to highlight the differences in architecture between SolidFire and some of the other leading AFA vendors, much in the same way Dave Wright did in his Tech Field Day presentation.
We only release competitive reviews for products that are GA, which Pure //m is not (Q3 this year and they are still only selling FA-400) and even though EMC has claimed 4.0 is GA on June 30, their own website has not yet updated their product docs to reflect the 8 X-Brick. Since we are trying to help customers and partners understand what's available today, comparing shipping features with future functionality isn't very useful. We plan to refresh our comparison docs for both Pure and EMC when their offerings are actually available in market, and the documentation is publicly available.
I think we've done a good job of walking the line between the blatantly negative "kill sheets" that we've all seen before and something that is useful to people learning about SolidFire and how we can help them bring flash into their data centers. We don't want to be negative, and we try to focus on what we do really, really well. There's always risk: this information is based on public sources from each company and aims to highlight design decisions and tradeoffs made in each approach.
This is a common thread in the industry and in my opinion it needs to stop.
As a reseller infrastructure architect I have to sit through presentations from some companies comparing their latest array to competitor products that are up to 3 years old and that have been replaced or upgraded once or even twice in that time. In the worst example HP compared the 3Par F400 against an EMC Clariion CX3-80!!!!!
If a marketing team cannot have up to date product info then stop issuing the competitive documents.
In the end question EVERYTHING a vendor tells you and apply the smell test.
Inline compression is inline compression. The algorithms (LZ4 and LZO) are standards and widely used. It is a straightforward and easy to add efficiency feature for a storage array. The code for a fully developed implementation can even be purchased from Permabit.
The CPU utilization of these algorithms will be similar for similar compression block sizes. The compression ratios will depend the size of the compression block.
Inline implementations will have lower latency if smaller compression block sizes are used. Post process implementations will have higher compressibility if larger compression block sizes are used.
Storage vendors generally are not staffed by idiots. They know the information I just stated, and will implement inline compression in a manner to balance CPU performance, latency, and compression ratio.
Any vendor's marketing droids who claims their implementation of inline compression had a negligible performance hit while a competitors implementation has a significant performance hit has to be questioned on their technical knowledge.
In the real world, the one I inhabit, this is simply nonsense. I worked for NetApp for a long time, admittedly before AFF so I can't comment on that 'product' but the standard implementation of FAS is not something that I ever recommended to my customers that they should turn on.
I did twice,and I regretted it.
ONTAP 8.3.1 compression is totally different (very high performance - check http://recoverymonkey.org/2015/06/24/netapp-enterprise-grade-flash/) plus AFF has a ton of extra optimizations (including about 70% usable to raw with ADP, to address another comment).
Tech evolves. Most people leaving a storage company have maybe 6 months before their knowledge becomes obsolete.
Maybe focus on the pertinent question:
Which current technology solves more customer problems reliably?
Thx
D
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
