2 node vsan for production?

[Drewy]

Quick question for those folks that have vsan experience in production environments.
We’re in the process of migrating some workload to virtual machines on vmware. Storage will be provided by vsan, each of the 2 nodes will contribute storage while a 3rd machine will provide quorum for the small cluster.
We have lots of way larger vsan clusters, anywhere between 5 and 15 nodes. Nothing as small as 2.
The architecture folks are telling me, yeah it’s fine, it’s a supported configuration. And while I’m sure it is supported, is it a good idea?
Personally I’m inclined to think not.

Any thoughts?

 

[IamSpartacus]

It's fine if you don't need maximum uptime. Anytime there is a disk group failure or you need to do maintenance / updates / reboot one of the hosts the cluster will be down. IMO 3 is the minimum for production and at least 4 is best so you can still tolerate a failure while doing maintenance.

 

[MiniKnight]

I'd feel better with 4 nodes

 

[Drewy]

Thanks guys

 

[ecosse]

It's fine if you don't need maximum uptime. Anytime there is a disk group failure or you need to do maintenance / updates / reboot one of the hosts the cluster will be down. IMO 3 is the minimum for production and at least 4 is best so you can still tolerate a failure while doing maintenance.

Probably me being dumb here but I thought the witness appliance element meant you could survive a node failure in 2 node config?

 

[IamSpartacus]

Probably me being dumb here but I thought the witness appliance element meant you could survive a node failure in 2 node config?

You are correct, I mispoke. The big problem with a 2 node ROBO is if one of the nodes is offline for more than 60 minutes. It's a major headache trying to get data redundancy back.

See here.

 

[ecosse]

You are correct, I mispoke. The big problem with a 2 node ROBO is if one of the nodes is offline for more than 60 minutes. It's a major headache trying to get data redundancy back.

See here.

Wow thanks for the link. I never realised how flawed a 2 node VSAN was.

 

[Connorise]

I Read the title and shuddered.

>Wow thanks for the link. I never realised how flawed a 2 node VSAN was.

True statement, VSAN should be considered for production from 5 nodes, that's when erasure coding comes into play and vSAN starts to shine. vSAN shouldn't be on the list in any case with less than 4 nodes. When it comes to minimalistic setup I would recommend few solutions, for example, HPE VSA and Starwind. They both can do 2 node clusters out without risking your production.

HPE VSA: 2 Node VSA - Hewlett Packard Enterprise Community
Starwind: StarWind Virtual SAN Hyper-Converged 2 nodes scenario with VMware vSphere |

I may lack experience in using them, but from what I am aware Starwind, is doing proper resiliency on 2 nodes providing local storage redundancy by utilizing hardware RAID + redundancy at the nodes level (network mirroring).
Another important dimension is the availability of Web GUI, DRAM/flash caching and tons of technical papers... in short, what all good software-defined storages must do IMHO.

 

[ecosse]

I've used the HPE VSA in my latest build. It works quite well but like all HPE bought services it hasn't kept up with the times. I would have used Starwind but it needs better documentation IMHO and I can't be doing without a GUI which I believe you don't get with the latest "free" version offer.

 

[BoredSysadmin]

I have deployed 3 node vsan in home lab. host stayed overnight in maintenance mode. I used default ensure data availability (not full data migration). After taking the host out of maint. vsan health went back to green pretty quickly. Not sure about 2 node behavior, I'd only use 2-3 node in remote sites anyhow. 2 especially appealing since you could connect each other using Twinax cables and have no need for 10gig switch ports.
Is vSAN recovery is better in latest vSAN7 - I sure hope so.

On pain sides, this evening I fought vsan warning such as
SCSI controller is VMware certified and Max component size - later one is fairly easy to fix using a GUI and advanced host settings, but prior is a much more tricky beast to shut up permanently. it has to be done in RVC, which is Ruby Virtual center shell. annoying to connect to, use and navigate. took me 2 hours and much google to figure this crap. As per usual VC bloggers making the false assumption that they are dealing with intelligent reading (