• 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

SMP-FT support for Virtual SAN ROBO configurations

Duncan Epping · Oct 12, 2015 ·

When we announced Virtual SAN 2-node ROBO configurations at VMworld we received a lot of great feedback and responses. A lot of people asked if SMP-FT was supported in that configuration. Apparently many of the customers using ROBO still have legacy applications which can use some form of extra protection against a host failure etc. The Virtual SAN team had not anticipated this and had not tested this explicit scenario unfortunately so our response had to be: not supported today.

We took the feedback to the engineering and QA team and these guys managed to do full end-to-end tests for SMP-FT on 2-node Virtual SAN ROBO configurations. Proud to announce that as of today this is now fully supported with Virtual SAN 6.1! I want to point out that still all SMP-FT requirements do apply, which means 10GbE for SMPT-FT! Nevertheless, if you have the need to provide that extra level of availability for certain workloads, now you can!

Related

BC-DR, Server, Software Defined, Storage, vSAN 6.0u1, 6.1, fault tolerance, ft, smp-ft, virtual san, vsan, vSphere

Reader Interactions

Comments

  1. Mario Lenz says

    12 October, 2015 at 20:33

    Does this mean SMP-FT is also fully supported for non-ROBO “stretched cluster” deployments? From an architecture point of view there seems to be no difference, ROBO looks like just a packaging / licensing model to me.

    • Duncan Epping says

      16 October, 2015 at 07:30

      SMP-FT is not supported for ANY type of stretched storage at the moment. This is because of the latency and the impact it would have on performance.

      • Mario Lenz says

        18 October, 2015 at 21:58

        I’ve seen clusters that are stretched across the street and that shouldn’t have a severe impact on latency.

        Instead of not supporting a special design, wouldn’t it be better to have latency requirements? Because it’s the latencies that are the problem, not the stretched cluster design itself.

  2. Vince says

    15 October, 2015 at 21:46

    Where are you getting your stencils? 🙂

    • Duncan Epping says

      16 October, 2015 at 07:29

      Internally at VMware, combination of various slides etc.

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

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in