Deploying Microsoft Failover Cluster using VMware Cluster-in-a-box setup - what are the disk requirements?

[John4321]

Hi

I'm deploying a Microsoft Failover Cluster using 2 VMware vm's. The setup I propose to use is "Cluster in a Box".

https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-setup-mscs.pdf

Based on this site, I have assumed that the disk format requirements are:

• https://theitbros.com/share-disk-between-vms-on-vmware-esxi/
  • Disk Provisioning = Thick provision eager zero
  • Sharing = Multi-Writer
  • Virtual Device Node = separate SCSI Controller
  • Disk Mode = Independent - Persistent

When I look at the following VMware sites:

• Page 18/19: https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-setup-mscs.pdf
• https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.mscs.doc/GUID-738F12C4-C157-4C49-A7...

It only seems to talk about having the disk in "eagerzeroedthick" format and the separate SCSI controller, it doesn't mention "Independent - Persistent" or "Multi-Writer".

Site 1	Site 2

Does the disk need to be "Independent - Persistent" and "Multi-Writer"?

I'm interested in this as we use Veeam to do a server level backup and so having a persistent disk prevents this.

Thank you.

John

[daphnissov]

Is this for a lab/test/PoC environment only? Because otherwise CIB should almost never be used in production. If the one ESXi host goes down which is running those VMs, everything is down (which defeats the purpose of WFC to begin with).

[John4321]

Hi.

We are thinking of using CIB in production.

If the one ESXi hosts goes down when running the VMs, they would be brought up on another host.

The following guide mentions "Caution Limit the number of hosts to two when you define host DRS group rules for a cluster of virtual machines on one physical host." (Page 34)

• https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-setup-mscs.pdf

You are right that if the ESXi host goes down, then the disruption would be no different from if we had 1 server.

However, the purpose of using CIB in production would be that when we had maintenance (i.e. windows updates) we can do it on one of the file servers and therefore the users wouldn't lose availability to the data.

Given that we have a more limited purpose, would you still recommend against CIB?

We are currently not choosing cluster across boxes as we wanted to avoid RDM disks as it is not something we have used before and it is a learning curve. However, if we were to find that CIB has too many advantages for this limited purpose, then we would need to look at cluster across boxes or another solution.

I look forward to hearing from you.

John

[daphnissov]

The only benefit that CIB buys you is the ability to manage availability for planned outage events for the guest, but its severe detraction is no avoidance for non-planned outages plus the added negative of having no vMotion support. In addition to this meaning no DRS for those nodes, it means you cannot evacuate the given ESXi host on which those nodes reside even limiting you to planned outage (maintenance) events for said host. Don't forget that patching of ESXi is critical as well as patching your guests, so you don't want to lock yourself in there. I've seen it too many times where CIB causes hosts to lay unsecured, unstable, and then when it comes to migration efforts once again you're locked in. In my opinion, if you absolutely must do WSFC, CIB should not be used in production because of these limitations. Using CAB instead, while requiring a pRDM, gives you more flexibility and freedom that using vSphere was designed to bring in the first place. I have using RDMs and they should seriously perish in a fire here soon, so what's even better is something like DFS with redundance name spaces. This sidesteps all the faults of WSFC and restore the benefits of vSphere. I'd recommend you look into that as an alternative.

[John4321]

Hi

What you say is true and will be included in our decision process.

We have got DFSR working in production and we're trying to move away from that due to a couple of limitations:

a) When applying a snapshot to a DFSR file server (during a Veeam backup), the snapshot grew very large. We therefore turned off the replication during the Veeam backup window. We never resolved the root cause of this.

b) The IO on the storage increased after the deployment of DFSR.

We haven't yet found a perfect solution for deploying 2 file servers in a cluster - and Windows has so many similar technologies.

Thanks

John