VMWare vSAN: Controlled shutdown to single host in power failure - does it work?

[BlizzardX]

Will do thanks, clearly this is not a professional setup and its designed to ensure that my partner doesn't kill me when she tries to access the TV (TVheadend), email, plex etc. I could run it on a single host with my Dell R710 holding lots of memory but then an update to that host will kill all VMs however breifly and I'd prefer some redundancy in that case!

 

[ginjaninja]

if i have read the op correctly there are 2 qu.

1. can you maintain data availability when a 3 node vsan looses two nodes
2. can you gracefully shutdown vsan hosts.

i run a 4 node all flash vsan in the enterprise with power cli scripts to control shutdown.

re. 1
i suspect yes, as vsan storage policy allows n+2 but you would be trippljng the cost of storing every bit. given a media server use case, diskio wont be limiting factor and compute cant be well distributed by any single media server i am aware of..so 3 node vsan does not sound like an ideal platform.

re.2 you definitely can use power cli to gracefully manage shutdown, i do. afaik when i last checked my ups brand apc did not support the maintenance mode flags graceful vsan shurdown requires. so i had to write a powercli script to get the job done.

as an aside i dont think vsan likes some nodes of a cluster being off for long periods of time..when we shutdown we shudown all hosts.

 

[Hellsmk2]

It will happily cope with a host being out of the cluster for an extended period of time - there is no issue whatsoever (assuming your cluster has the capacity to cope). It's extremely resilient in that aspect.

Four nodes should be the absolute minimum for a cluster, and is for an FTT=2 configuration. However, four for an FTT=2 really isn't enough - five should be the minimum nodes if you're going down that route.

In terms of the FTT=2 option, from 6.2 onwards, the storage costs of using this have drastically reduced too, as you can now set a R5/6 policy, rather than just R1. It's much more sensible to do this now.

 

[ginjaninja]

It will happily cope with a host being out of the cluster for an extended period of time - there is no issue whatsoever (assuming your cluster has the capacity to cope). It's extremely resilient in that aspect.

We have a four node cluster, i was under the impression that if a node was shutdown for a long period of time (i had 1hr in my head), remaining nodes would start to replicate data to get back to the prescribed ftt level...ie a lot of disk thrashing..is this not the case? presumably vsan has to repair itself at some point...the node may not be coming back? or is that a manual step?

 

[Hellsmk2]

We have a four node cluster, i was under the impression that if a node was shutdown for a long period of time (i had 1hr in my head), remaining nodes would start to replicate data to get back to the prescribed ftt level...ie a lot of disk thrashing..is this not the case? presumably vsan has to repair itself at some point...the node may not be coming back? or is that a manual step?

I've never heard of it behaving like this. The host is in maintenance mode, not dead. For a rebuild to happen you would need to remove the node/ disk groups from the cluster.

The only operation I can think of that would increase disk activity drastically would be selecting Full Data migration when placing a host in maintenance mode, which I would say is necessary if a node will be down for a long time; however, this doesn't tickle the sides of an all flash vsan, and shouldn't pose much hassle for traditional spinning disks either.

The biggest performance/ stability killer for any vsan cluster I have worked with has always been down to controller drivers & cards, either due to unsupported drivers or cards with a low queue depth. Maintenance mode has never caused an issue

 

[ginjaninja]

i can confirm that if the host is in maintenance mode, all vsan services are still 'up'....but if you turn the host off and VSAN.ClomRepairDelay timer expires, the cluster will start rebuilding (even if you put that host (now switched off) into maintenance mode gracefully)