I suspect I wasn’t the only one last week who was scratching his head at the latest idea from NetApp which sees them offering a VMware EVO: RAIL solution that incorporates Data ONTAP filer technology. In case that last statement is unclear to you, yes, NetApp are suggesting that EVO: RAIL, the solution that uses VSAN and commodity disk to specifically remove the need for a dedicated shared storage array, actually should be packaged with one.
What possible reason could there be for doing this I hear you say? Have a look at this page on NetApp’s community website. The text implies that VSAN either can’t meet “corporate guidelines”, or is deficient in the ability to provide consistent backup/DR, storage efficiency or Quality of Service (QoS). The good folks at Nutanix and SimpliVity must have been cracking open the Champagne and high-fiving themselves when they read that one. It’s a tacit acceptance that VSAN isn’t fit for purpose as a storage solution in other than the most basic circumstances.
Some of the comments made in the previously shared link are of course true. VSAN has no direct way to support file data (NFS/SMB), unless a specific VM is built for the purpose. VSAN uses replicas for data protection that are tied to server resiliency and so in many instances two replicas may not be sufficient. This represents a massive waste of disk capacity, even when using commodity disks and takes us back to 1990’s computing. VSAN doesn’t use flash as a tier, but rather uses it for read & write caching, which can be a weakness in solutions like VDI. VSAN supports no space reduction technologies like data de-duplication or compression. VSAN has poor data recovery algorithms that can seriously affect or kill system performance.
I could go on, but the message is clear, VSAN has limited applicability and if you want enterprise-class functionality, then it’s the wrong product altogether.
(Side Note: Don’t be taken in by the snake-oil marketing types who will try and tell you that storage is better integrated into the vSphere kernel. We broke the dependency on storage in the O/S through the use of SAN, which has been a spectacular success over the last 15 years. Read the comments by Dheeraj Pandey on this post from Nigel Poulton to understand why kernel-based storage is a red herring).
If we look at the use-case suggested, NetApp are recommending the splitting of data in a VDI solution into VMs on VSAN and user/shared data on one of their FAS filers. This configuration makes no sense at all. NetApp offers hardware that ranges from Enterprise to SMB, making Data ONTAP affordable in all but the smallest environments. In addition, Data ONTAP supports de-dupe, which is a perfect fit for VDI VM’s, resulting in very high data reduction rates. The idea of combining a Data ONTAP array with VSAN for VDI goes against everything NetApp recommend – just check out this page as an example of how NetApp are pushing dedicated VDI solutions. It would be easier (and potentially cheaper) to host the whole solution on a NetApp Filer and drop VSAN completely.
So what’s going on here? NetApp are desperate to try and keep Data ONTAP and their hybrid arrays relevant by combining with technologies that are creating news. The trouble is, the underlying architecture of the two platforms (EVO:RAIL and Data ONTAP) are so different that a combined solution is just wrong. Each platform has different levels of resiliency, availability and performance. Taking availability as an example, in a VDI environment if either the VSAN or NetApp component were to fail, then the VDI solution would be unusable. So the availability of the overall solution falls to the lowest common denominator, in this case, VSAN, despite the fact that the solution contains a highly available storage platform. It’s like continuing to boot servers with a single disk drive with the application data on SAN and expecting the solution to have SAN-level availability.
The Architect’s View
I really do wonder what the future holds for NetApp. All of their recent product innovations have focused around trying to lever Data ONTAP and FAS hardware into inappropriate solutions. Trying to be part of EVO:RAIL just continues this trend. We will be being told soon that NetApp is the perfect fit for delivering Docker and container-based solutions next. At the same time, we’re starting to realise that VSAN has flaws. Some of these may be remedied in release 2.0 due next year, but VSAN is still an immature product.
One final note; NetApp may have announced “NetApp Integrated EVO: RAIL” as a product, but according to this article by Chris Mellor have been shy on explaining exactly who will be providing the server hardware. The revealing of that piece of information could make for interesting reading, especially in light of NetApp’s existing FlexPod partnership.
Comments are always welcome; please read our Comments Policy first. If you have any related links of interest, please feel free to add them as a comment for consideration.
Copyright (c) 2009-2016 – Chris M Evans, first published on https://blog.architecting.it, do not reproduce without permission.