Failover/SQL Cluster on VVOL

[Regnor]

I know 6.7 is only supported since a short time, but does anyone here have experience with Failover or SQL Clusters on VVOLs with vSphere 6.7?
Can we backup those with Veeam in a supported way(ignoring the CBT bug)?

[ctg49]

I too am interested in this. From my understanding, the VVOL CBT bug still exists within the most recent esxi 6.7 patch, so I'd assume that either the hosts utilizing VVOL clustering shouldn't be vmotioned, or CBT should be disabled in backup jobs. Does that CBT bug also have any bearing on failover events? If I set up affinity rules to prevent VMs from ever vmotioning off a given host, would I be able to leverage CBT for backups on clustered VVOLs?

Finally, does snapshotting work with VVOL-backed clusters, or are we still using 'physical' agent-based cluster backups?

Thank you!

[Regnor]

Finally, does snapshotting work with VVOL-backed clusters, or are we still using 'physical' agent-based cluster backups?

That's the question.
We could work around the CBT bug (although it's still critical).

[ctg49]

So, I did some testing of my own. Built a failover cluster of two VMs with a single 10GB shared disk between them, created a file server cluster role, and ran some tests against that. The VMs still aren't snapshottable (I assume due to the physical bus sharing of a disk), so we still back them up as 'physical' agent-based backups, using the failover cluster option. I did several tests involving failing over the disks, migrating the VMs themselves, and noticed no corruption with any files/volumes, so I assume the CBT bug doesn't manifest due to not using VMWare's CBT system (as it's not leveraging snapshots for this).

Based on this information, I'd say it's safe to migrate data from pRDMs to VVOLs if you're running ESXi 6.7, I plan on doing this with my failover clusters (going to start with low-hanging fruit to vet further, move from there).

I'm super stoked for VMware to fix the actual CBT bug though, so I can migrate everything to VVOLs, they really do simplify the whole storage -> VM stack.


EDIT:
Couple quirks I ran into when playing with these:
Cannot extend shared cluster VVOL while VMs are powered on. All associated VMs must be powered down first. It's probable that you could avoid this by detaching a VVOL from all VMs but the one you shut down, but that would still take the one cluster node offline (would prevent taking others offline I guess). See link:
https://communities.vmware.com/thread/569973

After creating VVOL & attaching on second VM, if VVOL size is increased, second VM reflects OLD size in properties. Persists until CPU Vmotion of secondary VM. Restart of vCenter probably would fix too, as would a detach/reattach.

When deleting VMs with a shared VVOL disk, it doesn't actually delete the shared VVOL. I just dumped my two test VMs and the 10GB shared volume stayed behind in one of the VM folders (the one I originally created the disk for). Just a note for anyone fiddling around with test/prod cluster VMs.

[Regnor]

Thanks for doing some tests.
I have to admit that I didn't see that physical bus sharing was still required with VVOLs, so I thought that we could snapshot those shared VVOLs...
So Agent backup is still the only valid way to backup a SQL Cluster and CBT bugs probably won't hurt us anywhere

[ctg49]

Just throwing this out:

I've successfully migrated a 5-instance SQL cluster (plus Quorum and OS disks) from RDMs for all shared disks to VVOLs. All total, 13 disks migrated (2x OS, 1 quorum, 2x per instance for DB/Logfiles), and now successfully backing up via VEEAM. Even had to do a recovery via VEEAM due to an unfortunate misclick when deleting the wrong VVOL after a test (measure 4x, cut once) which happened without a hitch. Failover and SQL behaving as expected.

[Regnor]

Does your cluster run on a single host or over multiple hosts?

[ctg49]

Multiple, two hosts with one VM each, utilizing an anti-affinity rule to keep separated for DRS purposes unless i'm patching.

[Regnor]

And snapshoting the shared disks works although using physical shared-scsi mode?

[ctg49]

Negative. You cannot snapshot a VM with a physical shared-bus mode SCSI interface/adapter. This method of having disk sharing still depends on physical-mode backups.

[Regnor]

So just to clarify; when you say you backup the cluster with Veeam, you mean the agents?

[ctg49]

Correct, failover cluster backups are done the same as they were with pRDMs, via agents.

[Regnor]

Ok; at first I thought that you were using VBR to backup your VMs.

[ctg49]

I think we've got wires crossed; we are using VBR to back up 'normal' VMs, and we're using VBR to back up our SQL cluster (also set in VMs, shared VVOLs). With the SQL cluster however, you have to use physical agents as VBR cannot snapshot VMs with bus sharing SCSI connectors.