• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

Virtual SAN / EVO:RAIL use cases versus supported

Duncan Epping · Sep 8, 2014 ·

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:

evo:rail 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.

Related

Server, Software Defined, Storage, vSAN evo:rail, virtual san, VMware, vsan, vSphere

Reader Interactions

Comments

  1. speakvirtual says

    8 September, 2014 at 16:03

    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.

    • Duncan Epping says

      8 September, 2014 at 17:09

      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 🙂

  2. Vic Camacho (@Virtual_Vic) says

    8 September, 2014 at 18:19

    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.

  3. Jason Burroughs says

    8 September, 2014 at 19:47

    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.

    • Michael Rudloff says

      8 September, 2014 at 21:52

      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 🙂

  4. Ryan B says

    9 September, 2014 at 05:18

    This does make me wonder though… *Is* Exchange 2010 supported on VSAN?

    • Michael Rudloff says

      10 September, 2014 at 19:19

      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

      • Michael Rudloff says

        10 September, 2014 at 19:20

        * SP1

      • maishsk says

        12 September, 2014 at 11:44

        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

        • Ryan B says

          12 September, 2014 at 13:47

          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.

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

May 24th – VMUG Poland
June 1st – VMUG Belgium
Aug 21st – VMware Explore
Sep 20th – VMUG DK
Nov 6th – VMware Explore
Dec 7th – Swiss German VMUG

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in