A fellow technologist asked a very fair and controversial question in a comment to IOPS Matter: VMware Native Multipathing Rule Attribute Affects Storage Failover, which pertains to my VMware-XtremIO environment. Since my response was running quite long, I thought it better to re-post the question here, followed by the answer.
“We are looking at purchasing a new all-flash SAN for our SQL environment running on VMware 5.5 — in your experience between Pure and EMC XIO, if you had it to do over, which would you buy? We are looking at the X-Brick 10TB against the Pure FA-405 6TB models. SQL compression is about 1.7:1 and dedup is almost nothing until we talk about storing multiple copies of our 300GB database for dev, test, staging, etc. Other than consistent finger-pointing from vendor to vendor, I’m not seeing much difference that would concern me in either direction other than price and that Pure’s 6TB might not exactly match the 8-9TB available in the XIO. Feedback?”
That’s quite the question, the answer to which would become headliner marketing material for whichever product was endorsed. Thankfully for me, the politically “safe” response of “it depends” is actually true. Factors like price, observable data reduction, and I/O patterns all sway the arrow.
Personally, I dislike the price factor because it biases the more objective technical virtues of products. In dollars, though, my experience has shown that EMC is willing to go the distance to make sure they aren’t outbid by Pure. That probably varies by VAR and their relationship with EMC, but EMC’s vast empire and capital make them hard to beat in this realm.
It sounds like your environment is similar to ours in data type (we’re heavy MSSQL, too). Thus, I’d expect to see comparable reduction rates for you as for us; it could vary depending on what is stored in your SQL databases, but let’s assume they are close. On Pure, we saw around 4:1 data reduction, due to commonalities in databases and dev/test/stage environments. That’s *reduction*, not just deduplication. We don’t yet know what that ratio will be on XtremIO, because we’re still on 2.4 (3.0 just GA’d and isn’t seamless). Thus, if you have to pull the purchase trigger before we or another XtremIO customer can post real-world compression results, you’ll be comparing “what is” to “what is claimed to be”. I don’t have a good history with that comparison, so if you can wait and see, I would.
The last part, I/O patterns, is related to data reduction because you have to favor one. It’s physics. Pure Storage uses variable-length block deduplication, which takes more time to do, but which also achieves better deduplication ratios (see the strength of EMC Avamar for proof of that). The downsides are post-processing and garbage collection, which EMC Marketing is proud to highlight. XtremIO, on the other hand, uses fixed-length block dedupe (4K in pre-3.0; 8K in 3.0+), which makes it fast to process on the fly (read: no post processing or GC), but which doesn’t achieve the same degree of dedupe. Both of those are physics choices, architecture choices. Personally, I don’t think it’s a good vs. bad comparison; it’s more apples and oranges. Both are fruit but they peel, slice, and scale differently.
Back to the practical in I/O, our patterns required some tweaking of Pure’s deduplication processing intensity in order to maintain low latency. The processing weakness of variable-length dedupe is large block sizes. Backups use large block sizes, and for better or worse, our developers choose to run full SQL backups all at the same time each day, which gave that dedupe processing a run for its money. With help from Pure support, that behavior was mostly mitigated. We didn’t see any other challenges with the handling of our I/O patterns. XtremIO doesn’t flinch with that same backup flood, but it also doesn’t touch even half of the data reduction rate (pre-3.0). Thus, they are *very* different beasts pre-XIOS 3.0. I hope to find out in the next month how they measure up in the 3.0 world. Granted, we don’t have a Pure FA-400 on hand to directly compare with, but our environment hasn’t significantly changed since we gathered our data in late 2013.
I’m including a link below to EMCer Chad Sakac’s blog entry on XIOS 3.0’s disruptive nature. I’m not a big fan of parts of the justification in the post itself, but I found that the dialog in the comments was useful information. You’ll see a good mix of support and push back in the replies. Take a moment to read them and sample some of the emotions swirling around the All-Flash Array market. The replies from current EMC and XtremIO customers are particularly applicable.
Wrapping up, we both know that I could be more definitive in answering the question, but I haven’t. Part of that comes from the fact that I’m biased by some experiences we’ve had (with both products, actually) that are now in each product’s history. It wouldn’t profit you for me to warn you about situations that were addressed in late 2013 or early 2014 software releases, because you won’t see them (unless you figure out time travel and return to repeat them). The other part comes from the current absence of data parity–the “what is” versus “what is claimed to be” comparison.
And that’s the twist. The all-flash storage and data reduction spheres are all about the future, so you would be remiss if you didn’t pay attention to what vendors claim and project for their product road maps. The key is finding harmony between “what will be” and “what is” today. If you do decide to go with a product based on its claims, make sure you get it in writing that the product will deliver on that claim. Worst case, you return it and go with the alternative. Best case, the vendor delivers what it takes to meet the claim, which means bonus hardware. Either way, you gain experience and hopefully only lose time.