One aspect of our industry that I find especially annoying is the "pay-to-say" analyst model. The usual scenario is that one vendor wants to discredit one or more other vendors to make themselves look better. They contract with a freelance analyst, who hopefully brings more expertise and the appearance of independence to the table.
The few analysts who use this model fiercely brand themselves "independent", perhaps in the sense that they are not affiliated with one of the big name industry analyst firms.
I guess by the same standard my lawyer is "independent", but I certainly pay for results!
Shortly after VMware announced VSAN's general availability, George Crump and Colm Keegan of Storage Swiss published a short piece entitled "The Problems With Server Side Storage, Like VSAN", which appears to be sponsored by GridStore.
Despite taking substantial criticism from many IT practitioners in a number of forums, George has stubbornly defended his statements, encouraging those who object to offer up a "professional response".
I find myself doing so reluctantly: weighing the need to correct many of George's and Colm's erroneous statements vs. giving unwarranted attention where none is deserved. All of my responses are based on widely published information; a simple Google search can disprove many of the assertions.
And, to be fair, I know many independent analysts who do very good work on behalf of their vendor clients.
Unfortunately, this isn't an example of that.
What You Need To Know About VSAN
Thanks to the widespread success of vSphere, it also has a built-in audience of virtualization admins who can uniquely appreciate what it brings to the table.
By comparison, most storage professionals look at the world through an established lens, so -- in general -- it takes them a few ticks longer to appreciate what VSAN is all about.
If you as a vendor sell external storage, you're concerned about server-based storage displacing external storage arrays. If you're one of the newer "hyperconverged" appliance vendors, you're concerned about vSphere + VSAN seriously eroding your nascent market opportunity. And if your storage product is entirely software-based, you're concerned about VSAN's deep integration with the hypervisor, and all the advantages that brings.
Having been in this storage business for twenty years now (!) I tend to measure the impact of a new product by the visceral nature of the competitive reaction it evokes.
And, when it comes to VSAN, I have not been disappointed ...
The Basis Of The Storage Swiss "Argument"
While the piece starts out by acknowledging much of the appeal of VSAN (the obligatory "head nodding" portion), it quickly gets to its core (incorrect) assertion: that the ratio between compute and storage is limited with VSAN. Thus, all manner of problems will potentially arise when attempting to scale storage.
Frustratingly, the truth is quite the opposite.
Let's begin with the easily verifiable facts, starting with capacity. A given VSAN server may have as many as five (5) disk groups, each with seven (7) disk drives, for a total of 35 disk drives per server. The size of a VSAN cluster ranges from 3-32 servers, which may be single socket servers if you choose -- keeping in mind that with VSAN, all servers are used to provide both compute and storage services.
Using 4TB drives, that yields 140TB of raw capacity per single-socket server. Needless to say, as VSAN is licensed per socket, this would be an impressively cost-effective capacity-oriented configuration. While it is true that some specialized environments might want more capacity per server socket (e.g. enormous video archives), I think this good enough to cover off >95% of real-world use cases.
Not to pile on, but in a maximal 32 node config, this maximum would rise to 4.4 petabytes, and an even more-impressive 6.7 PB when the new 6TB drives become more widely available.
I think most reasonable people would agree that VSAN's storage capacity scales rather independently of server capacity.
Just for fun, let's go the other way, and scale compute and IOPS with a minimum of capacity.
Using a four-socket server design, a maximal VSAN cluster would have 128 sockets and support as many as 160 high-end PCI-e flash cards, each with a small disk drive behind it. A pricey rig, but -- hey! -- you could build one if you wanted to. And I would guess it to likely deliver far greater performance than the 2M IOPS announced in March -- that test used a much more modest configuration :)
Here's the point: with VSAN, compute and IOPS can scale quite independently of capacity as well. Better yet -- VSAN clusters do not need to be homogeneous, although limiting rampant diversity will certainly make your life easier: any mix of HCL-listed components is technically acceptable.
After all, it's software.
From Here, It Gets Worse
The article claims that adding capacity with a server-side storage solution (such as VSAN) may force disruptive upgrades when additional capacity is needed.
Once again, not at all true.
VM administrators are quite comfortable with putting individual servers in maintenance mode, and vMotioning as needed -- and have been doing so for many years. With VSAN, a simple policy setting will delay a reprotection rebuild if all you want to do is add a few disks and your server doesn't support a hot-add.
A few paragraphs later, the article states that -- as additional storage capacity is needed -- new servers will have to be "racked and stacked" simply to gain more capacity. Not exactly true. If your existing server enclosures have room for more storage media, that's where it goes. VSAN supports hot-add if the server does. If you're out of places to put things, a new server comes in, or you replace small capacity drives with larger ones.
Let's not forget the obvious comparison with external storage arrays -- it sort of works the same way. When you need more capacity, you bring in more hardware. Except with VSAN, you're working with one flavor of tin; not two or more.
From there, a vague assertion is made that VSAN requires three copies of data for protection, therefore you'll inevitably be growing servers at 9x rate using server-side storage. No, I don't know how they got to 3 copies required, nor is it clear how one gets from there to a rather preposterous 9x server growth claim.
The published facts are quite different.
Unlike external storage arrays, VSAN implements per-VMDK data protection -- it is quite unique in that regard. Storage objects that aren't all that important can have a single, unprotected instance if you choose. Important data should have at least two copies. And, if you're extremely conservative, three copies are supported as well.
All on a per-VMDK basis, entirely policy-driven and easily adjusted simply by changing a few settings. To make things even easier, just take the defaults and go.
Try that on an external array.
This is followed by another strange assertion: that since VSAN does not need a separate, external storage network, therefore "network complexity is increased". Huh. VSAN uses the exact same network (and the same network configuration and management tools) as other cluster-wide services. Once again, the truth appears to be precisely the opposite of what is claimed.
And It's Not Either-Or
One of the things I find myself reminding folks about is that it's not an either-or proposition when it comes to VSAN -- feel free to use external storage alongside server-side storage. You'll find that vSphere's policy-based mechanisms make it relatively straightforward to place new workloads where you want them to go, and Storage vMotion them back and forth as needed.
Now, A Word From Our Sponsor!
From there, the article pivots into attempting to make a case for GridStore's product: SLA-driven provisioning. pay-as-you-grow, and more. While it's easy to deconstruct many of the points made here, that's not my goal. [Update: I have since discovered that GridStore's product isn't even on the vSphere HCL, so their motivations in funding an attack are not exactly clear]
I have no qualms with any vendor emphasizing their strong points -- and paying an analyst to do so -- however, in this particular case though, a detailed comparison would show that VSAN does a far better job in achieving these stated goals.
Where Does That Leave Us?
At some level, everyone has to make a living, including "independent" analysts. I'm certainly OK with that. And, as before, there are some great ones I know who do a great service to the community.
What I'm not OK with is polluting the commons with flatly incorrect assertions that fly in the face of widely-published documentation and real-world experience.
Someone either didn't do their homework, or didn't care about being accurate.
Many IT pros will simply dismiss the article as another piece of random flotsam on the internet. That's encouraging. The theoretical worst case would be an unfortunate IT pro who takes this article at face value, and later finds out just how greatly they were misled.
Caveat emptor, baby.