I have seen this being debated many times on twitter now, and I’ve seen various Virtual SAN (VSAN) and EVO:RAIL competitors use this in the past to mislead potential customers.
@vmwevorail Exchange/SQL etc is use case for EVO:RAIL? No objection by VMware for whatever reason to run such apps on rail?
— Marcel van den Berg☁ (@marcelvandenber) September 7, 2014
I think we have all seen these slides at VMworld or at a VMUG when it comes to VSAN or EVO:RAIL. The slide contains a couple of primary use cases:
So what does that mean? Does this mean that VMware does not support Exchange or MS SQL on top of VSAN or EVO:RAIL? Does that mean that VMware does not support it as a DR target? Or what about a management cluster? Or what about running Oracle? Or maybe SAP? Or what about my WordPress instance? Or what about MySQL? Or although you mention VDI, would that only be VMware View? What about… Yes by now you get my drift.
Let me try to make it really simple: Primary use cases says nothing about support. Primary use case means that this where the vendor expects the product or solution to fit best. In this case it is where VMware expect VSAN/EVO:RAIL to fit best, this is the target market VMware will be going after with this release.
Why include this in a slide deck? Well it allows you (the user / consultant / architect) to quickly identify where the majority of opportunities will be with the current version for your environment or for your customers. It does NOT mean that if your use case, like running your Exchange environment for instance on top of VSAN, is not listed that it is not supported. (Try listing all use cases on a slide, it will get pretty lengthy.)
Running Tier-1 applications on top of VSAN (or EVO:RAIL) is fully supported as it stands today, however … your application requirements and your service level agreement will determine if EVO:RAIL or VSAN is a good fit. One example would for instance be that if your agreed SLA requires an RPO (recovery point objective) of zero then sync replication is the only option (or stretched clustering), now you will need to determine if this is possible with the platform you want to use (this goes for any solution!). (Yes, you can make that happen with the platform pretty soon before anyone wants to go there…)
I hope that clears things up a bit.
I like this clarification. However, for customers, it doesn’t inspire much confidence in a solution to hear a vendor say “we’ll support Tier 1 apps…it’s just not our primary use case”. I think this is going to create a lot of confusion for customers and fodder for competitors. I think VMware would have made it easier for “the user / consultant / architect” if they would have left that off their slides.
Yes, in hindsight that may have been a better approach… But it is out there, so I am trying to explain what it means to help others who get this FUD thrown on their plate 🙂
Hindsight is 20/20 indeed 🙂 As this starts to pick up more visibility\momentum, I’m sure that we will be fielding many more of these questions. Glad to see the clarification getting out there via you blog.
I would be interested in seeing slides from the early days of ESX. I wonder what language was used about virtualizing tier 1 servers. I use the comparison quite often that when first doing P2V, pick the low hanging fruit of tier 2/3 workloads, test/dev, BC/DR, etc. As you develop more confidence with the product and technology, and more published whitepapers and customer references are available, consider moving up the stack towards tier 1.
Similarly, with new architecture such as VSAN or EVO, it makes sense to go after these same workloads initially.
Also, with the position in the industry that VMware occupies, it seems logical to gear the initial product launch towards that part of the IT stack. It takes time and resources to do the extensive testing for various apps and workloads, as well as building out a credible message through marketing. By focusing first on the “easy” workloads, credibility in the technology is established, confidence in the company is maintained, and momentum is built for future expansion.
In the early ESX days Microsoft was often saying that virtualization of apps like SQL, Exchange etc., is not supported 🙂
When customers ask ‘can I virtualize SQL’, the answer will most likely be ‘depends’. Is it supported ? Yes. Will it work ? ‘Depends’. We had a customer who needed to Raid 0 four FusionIO cards to get the performance they needed (having multiple of those obviously). Would to virtualize it ? Not in a million years 🙂
This does make me wonder though… *Is* Exchange 2010 supported on VSAN?
Virtualizing Exchange is supported and as of SP, including UMS. I have never seen any restrictions on storage to be honest. In fact, due to the DB design Microsoft even recommends low cost storage.
VMware did release a white paper however, concerning Exchange performance using vSAN.
http://blogs.vmware.com/vsphere/2014/09/vmware-virtual-san-performance-microsoft-exchange-server.html
* SP1
Microsoft has never certified or supported exchange running on NFS, including vmdk’s running on NFS as far as I remember.
This reminds me of the endless discussion of supported hardware and vSphere. Will it work? Yes. Does it work? Yes.
Can you call someone at 02:00 when things hit the fan?
Nope! you are on your own.
This is the same question you should ask yourself in every single scenario. Including running exchange on VSAN
VMware KB 1037959: “MSCS is currently NOT supported with VMware Virtual SAN (VSAN)”. Maybe you can get away with Exchange on VSAN if not using DAGs, although I’ve only seen one DAG-less Exchange 201x install. SQL AlwaysOn falls into this same bucket.
I have seen Microsoft pull the “we don’t support that” card when troubleshooting Exchange 2010 performance issues and finding out the OS vmdk was on NFS, even though Exchange data was all in-guest iSCSI.