Welcome to Communites.
"(a) does this environment work on a 1-live, 1 /2/3/4 mirrored copies"
Objects stored on vSAN (.vmdk, namespaces, .vswp) have Storage Policy defined properties that dictate their Failures To Tolerate - Default being FTT=1 (FTM=RAID1) which has 2 'mirror' data-components + a witness component for quorum.
An FTT=2 Object would have 3 'mirror' data-components + 2 witness components for quorum
What this means with respect to storage-utilization: if FTT=2 is required then these Objects would take up 3x what they use on SAN.
If the workload does not have very high performance requirements then the other option is RAID5/6 as the FTM which uses significantly less space for the same FTT (1.33x for FTT=1 with RAID5 - requires 4-nodes minimum | 1.5x for FTT=2 with RAID6 - requires 6-nodes minimum)
"(b) Where should , on best practice t, should the witness appliance reside, on a cluster or somewhere separate on another cluster"
Witness appliances are only required in stretched clusters - e.g. 2 nodes at one physical location, 2 nodes in second physical location, witness at third site (as an aside - yes these should be running on a different cluster).
Many thanks for your reply - before addressing your points, the thrust of what is making for is an over-view of how one would convert a sample 5-node cluster to VSAN (or even what design considerations would there be). This would enable me to understand VSAN from
IN Regards to Point (A) Form what you’re saying, the FTT Level and to an extent the RAID level defines the number of Nodes in a cluster
Also "An FTT=2 Object would have 3 'mirror' data-components + 2 witness components for quorum" - I'm not sure i understand this, as if 1 Quorum and 2 nodes fail - that 3 failed components, but 1 Node is running and a quorum is running - isn't that enough for the cluster to remain operational ?
(b) I though Witness/quorums are essential to every environment
Lastly, I’m getting ain impression that in a VANS environment there is 1 master and ‘many’ mirrors as opposed to the mutli-node cluster of vSphere - sounds right ?
"IN Regards to Point (A) Form what you’re saying, the FTT Level and to an extent the RAID level defines the number of Nodes in a cluster"
Yes, the desired FTT and specific FTM(s) used define what the minimum nodes per cluster are from a functional perspective as this many Fault Domains are required for component placement - and of course if N+1 for maintenance/fault recovery this is additional to the minimum required.
"as if 1 Quorum and 2 nodes fail - that 3 failed components, but 1 Node is running and a quorum is running - isn't that enough for the cluster to remain operational ?"
Actually the requirement for accessibile Objects is majority (>50%) of components + a full data-mirror, this is the reason why as the FTT (with R1) increases additional witness components are required. This is only the basic layout description of how this works - in reality with striping and votes etc. only relatively small Stripe-Width=1 FTT=1 R1 Objects look like this (2x data + 1x witness).
As an aside, yes it is technically feasible to restore/create a functional Object from the remnants of an FTT=2 Object with a single active (and current!) data component + witness component - though this is not a trivial task if reliability and data-safety is concerned (and as with most things this has a ghetto-method and a safe-method).
"(b) I though Witness/quorums are essential to every environment"
They certainly are(!) but there is a distinction between witness component placement based on configuration:
- Regular clusters store witness components on any available node not storing data or other witness components of that Object (these are relatively .
- Stretched clusters (with FTT=1) store witness components only on a dedicated Witness Appliance (which is essentially a nested ESXi running from a VM on another host).
"Lastly, I’m getting ain impression that in a VANS environment there is 1 master and ‘many’ mirrors as opposed to the mutli-node cluster of vSphere - sounds right ?"
Writes to data components are synchronous - writes are 'committed' as soon as they hit cache so yes mirrors not a 'shared-disk' (unless Objects are FTT=0).
Article that explains this functionality (yes I am aware this is for '2-node cluster' but the principles are them same):
Hope this helps clarify things.