As part of the mega lunch today, we have announced XtremIO 3.0, the interesting about this release for me is that we took was already the number 1 AFA in the market and made it better, better on the existing hardware which is no coincidence when you design your product on commodity hardware and the magic happens on software. part of this announcement was the new snapshot capabilities which we I already covered here

http://volumes.blog/2014/05/12/xtremio-redefining-snapshots/

but here’s another twist on the same topic, XtremIO is a true Scale Out based storage array, that means that with every X-Brick you are adding to the cluster, you capacity grows in ADDITION to the performance, this is done because each X-Brick contains two true Active-Active controllers.

now, one of the claims I hear from other vendors is “who needs so much performance” or “two active/passive (ALUA) architecture is good enough!”

here is why they are wrong

enter the iPhone 3Gs, that was the first iPhone I owned and for the time that it came out in, it was GOOD Enough. the apps were snappy and IOS in inteslf was pretty responsive.

But something happened on the way to paradise

Apple introduced the iPhone 4 and gradually, my iPhone 3Gs became outdated, it actually became SLOWER and things like my mail app and in general, IOS itself became slower and that begs the questions, WHY??

the reason is simple, we are living in an era where performance is a relative term and the moment a new piece of hardware comes out, the developers who write applications for this hardware, quickly leverage it and they leveraging the new performance capabilities of the new, more performing hardware.

ok, but how is this related to XtremIO 3.0 and more importantly, snapshots??

well, think about a production DB, it can be other environments as well but just for the sake of the example, let’s stick with a DB.

in many cases, many spinning drives will be needed just to accommodate the performance needs of the core DB and if you are starting to talk about cloning your DB, the operation itself takes a lot of time and more importantly, consume so much more space which result in many cases of actually limiting the numbers of DB’s clones you can offer.

“but I thought dedupe / compression resolve this, no?”

dedupe and compression are data reduction technologies, they will definitely  assist in lowering the footprint the core DB and it’s clones will consume but how do you drive the IOPS / Bandwidth for all of these clones??

ENTER Scale Out

XtremIO Scale out from the (new) Starter X-Brick to 6 X-Bricks (12 Active-Active controllers) which you NEED to leverage all of these copies, so now you can actually do very interesting things like giving each developer it’s own DB instance!

so the next time a storage vendor tells you that a two controller, let alone an Active – Passive archtecture is good enough, just tell them

“iPhone 3Gs was also good enough” …back in 2009