Where VSAN doesn't shine: Sources explain EMC's ScaleIO purpose
One is for small biz and the other is for enterprise providers
EMC introduced its scale-out ScaleIO Node virtual SAN a couple of weeks ago, with hybrid flash-disk and all-flash server chassises. It overlaps as a product with EMC-owned VMware's VSAN, and therefore EMC's EVO:RAIL implementation of that, and also competes with scale-out all-flash arrays.
Discussions with sources have clarified EMC's thinking on the topic, and showed that the overlap is less than originally thought.
ScaleIO and VSAN
Here's a chart to indicate our understanding of how EMC's thinking is developing, with a two-axis space delineated by frequency of occurrence in the market (low to high) and customer complexity (low to high).
Two curves show the relative positioning of VSAN and ScaleIO. Remote and branch offices (ROBO), hyper-converged infrastructure appliance (HCIA), small/medium enterprises (SMB), and small enterprise see the most need for VSAN. Enterprises see a need for both, with ScaleIO meeting more complex needs than VSAN, or non-vSphere hypervisor needs.
Our whiteboard chart of ScaleIO and VSAN market sweet spot differences
The largest use cases for ScaleIO are enterprise data centers and service providers.
ScaleIO doesn't sing out SMB because it doesn't really fly unless you have 10 nodes and up. VSAN isn't winning in giant service providers because it can't scale so high and it's designed for simpler use cases.
VSAN and ScaleIO come from different architectural design centers, with VSAN needing to be transactional and dealing with an object, a virtual machine. Locality is important, with a VM and its data kept on the same host and mirroring for two copies, meaning reads can be done in parallel in aggregate.
ScaleIO deals with volumes and LUNs with data carved into 1MB slices and shotgunned onto two nodes, with the next chunk going onto two more nodes. The write throughput is the aggregate of all hosts. The read bandwidth is the bandwidth of all the nodes in the ScaleIO cluster.
ScaleIO and SolidFire
How does ScaleIO compare to SolidFire? There's a lot of respect inside EMC for Dave Wright, SolidFire's CEO. He's seen as a great engineering CEO who has created great leadership culture.
SolidFire has a flash-optimized and service provider-optimized storage stack; ScaleIO not so much, so it can be used in both capacity-dense and performance-centric workloads.
ScaleIO doesn't have particularly strong write avoidance in its code stack. It often gets deployed in a service providers' use case for hybrid or disk.
The scaling sweet spots of ScaleIO and SolidFire are different. With ScaleIO it's very easy to scale to 1,000s of nodes, even to infinity and beyond, as one person said. SolidFire can't scale the same way.
SolidFire nailed quality of service (QoS) and the API model for service providers, but ScaleIO has more flexibility in how it can be used and may even have greater performance.
It seems to us here in El Reg that EMC has internal startups in the Emerging Technologies division inside EMC II (Information Infrastructure) with XtremIO, DSSD, and ScaleIO being the obvious ones. These all overlap, at least to a degree, and also overlap with VMware's VSAN initiative and VCE's VSPEX Blue.
Isn't this chaotic and wasteful?
Overlap inside a company's product ranges is not new. Think of NetApp with its all-flash FAS and all-flash EF series of arrays. The design centers and marketing sweet spots are different.
We can find similar overlapping product examples inside, for example, IBM, Dell, or virtually any other mainstream supplier. Startups are characteristically single-trick ponies with no overlap. Lucky for them. Startups are front and center of many people's view of the storage market today, and inform our assumptions.
But the normal way of things in mature companies, meaning the suppliers supplying the bulk of storage products today, is to have some overlap. EMC, seeing the way the storage and server markets and needs are developing, is more aggressively developing products for younger market niches than others.
Until those niches are fully formed and their needs widely understood, the amount of product overlap between neighboring niches can stand out. It is a temporary thing, hopefully, and will enable EMC, and other suppliers like Cisco who have this development characteristic, to have product ready to sell and deliver when the niche matures and has attracted its own set of dedicated startups. ®