As occurs with VMFS and NFS datastores, VMware vSAN prevents multiple virtual machines from opening the same virtual disk (VMDK) in read-write mode. This is to protect the data stored on the virtual disk from corruption caused by multiple writers on the non-cluster-aware filesystems used by most guest OS.
To enable in-guest systems that leverage cluster-aware filesystems that have distributed write (multi-writer) capability, we must explicitly enable multi-writer support for all applicable virtual machines and VMDKs.
This article outlines the process to create shareable VMDKs that reside on VMware vSAN and to enable multi-writer mode. This will permit multiple VMs to access the same VMDKs in read-write mode to enable the use of in-guest shared-storage clustering solutions such as Oracle RAC.
Warning: Do not enable multi-writer mode for any VM/VMDK combination unless the guests are capable of safely arbitrating and coordinating multiple systems accessing the same storage. Enabling multi-writer mode for disks that do not use in-guest cluster-aware filesystems will result in data corruption.
VMDK Clustering allows multiple virtual machines from the same or different ESXi host to simultaneously access a virtual disk on a vSAN datastore. VMware vSAN offers two types of VMDK clustering - "multiwriter" and “clustered VMDK”.
Multiwriter allows admins to make a VMDK accessible for more than one VM simultaneously. However, it does not provide any reservations or locking mechanism for coordinating access to the VMDK for consistency. One of the most popular applications that use multiwriter is Oracle RAC. Oracle RAC manages its own locking mechanism. Several other application clustering solutions have modes for managing the locking / block reservation system. Ensure that your application is managing its own locking and reservations.
“Clustered VMDK” uses a shared virtual SCSI bus. With Clustered VMDKs, vSAN implements SCSI3-PR for Microsoft Windows Server Failover Clusters (WSFC) specifically. Not all of the SCSI3-PR reservation types are supported, only those needed for MS WSFC. If you are trying to use any other application with SCSI3-PR on vSAN, it is not currently supported by VMware.
Note: Enabling multi-writer mode removes support for some virtual machine operations and vSphere features. Please refer to this matrix for operation/feature supportability when multi-writer mode is enabled:
Supported and unsupported actions or features
Actions or Features |
Supported |
Unsupported |
Notes |
Power on, off, restart virtual machine |
✓ |
|
|
Suspend VM |
× |
||
Hot add virtual disks |
✓ |
Only to existing adapters |
|
Hot remove devices |
✓ |
||
Hot extend virtual disk |
× |
||
Connect and disconnect devices |
✓ |
||
Snapshots |
× |
Virtual backup solutions leverage snapshots through the vStorage APIs; for example, VMware Data Recovery, vSphere Data Protection. These are also not supported. |
|
Snapshots of VMs with independent-persistent disks |
✓ |
Only the shared disks need to be in independent-persistent mode | |
Cloning |
× |
||
Storage vMotion |
× |
||
Changed Block Tracking (CBT) |
× |
||
vSphere Flash Read Cache (vFRC) |
× |
Stale writes can lead to data loss and/or corruption |
|
vMotion |
✓ |
|
Supported for ORAC only and limited to 8 ESX/ESXi hosts |
Virtual Use case:
Limitations and Requirements:
Note:
#esxcli system settings advanced set -i 1 -o /VMFS3/GBLAllowMW
vSAN 6.5 and later provides support for vSAN iSCSI Targets feature that presents vSAN based storage as iSCSI LUNs to iSCSI initiators.
If iSCSI initiators are configured in Oracle RAC physical machines, they can share iSCSI LUNs presented from vSAN 6.5 and later.
Refer vSAN 6.5 documentation for instructions on configuring vSAN iSCSI Targets.
The process of configuring an Oracle RAC cluster on a vSAN datastore needs to be done once per RAC cluster at creation time. This requires these steps:
Depending on your Virtual Machine design specifications, you will need to define the VM Storage Policy that will be applied to the RAC shared disks.
Example Storage Policy for vSAN 6.7 Patch 01 and newer: Shared vmdks with multi-writer attribute can be thin provisioned ( OSR=0%)
Example Storage Policy prior to vSAN 6.7 P01 : Shared vmdks with multiwriter attribute must be thick provisioned (OSR = 100%)
Notes:
For more information about storage policy configuration options, please see the VMware vSAN documentation.
Note: Create controllers of the same type and in the same position (SCSI address) on each Oracle RAC virtual machine.
To create shared disks on the first virtual machine using the vSphere Web Client, follow the steps as shown in the section for vSphere version 6.5.
The only change, starting from vSAN 6.7 Patch 01, is shared vmdk’s does not need to be eager zero thick (EZT). You can select the storage policy with OSR set to Thin Provisioning.
The rest of the steps are the same as described in the section for “vSphere version 6.5 or newer but below vSAN 6.7 Patch 01”.
Starting with vSphere version 6.5, the vSphere Web Client has the option to create eager-zeroed thick (EZT) disks on the vSAN datastore.
Note: The virtual disks should be added to the same SCSI positions on each virtual machine. If a disk is in position 1:0 on one virtual machine, it should be in position 1:0 on all virtual machines in the Oracle RAC.
Using the vSphere Web Client
To create shared disks on the first virtual machine using the vSphere Web Client:
To add shared disks to one or more virtual machines using the vSphere Web Client:
In vSphere version 6.0 U1 or later, but below version 6.5 (Example: 6.0 U3), the vSphere Web Client cannot create eager-zeroed disks on the vSAN datastore. While the vSAN Datastore supports eager-zeroed disks, this functionality is not currently exposed in the vSphere Web Client. To accommodate this limitation in the current release, we must use either PowerCLI or the ESXi command line to create the eager-zeroed disks. This section outlines the PowerCLI method to create disks, and is the preferred method.
In vSphere version 6.0 U1 or later, but below version 6.5 (Example: 6.0 U3), the vSphere Web Client cannot create eager-zeroed disks on the vSAN datastore. While the vSAN Datastore supports eager-zeroed disks, this functionality is not currently exposed in the vSphere Web Client. To accommodate this limitation in the current release, we must use either PowerCLI or the ESXi command line to create the eager-zeroed disks. This section outlines the ESXi command line method to create disks.
Note: You must enable the local ESXi shell or SSH access to the host and log in as privileged (root) user to complete the below procedure.
cd /vmfs/volumes/vsan_datastore/VM_Name
cd /vmfs/volumes/vsanDatastore/RAC_0
vmkfstools -c size -W vsan -d eagerzeroedthick `pwd`/vmdk_file_name
vmkfstools -c 12G –W vsan –d eagerzeroedthick `pwd`/RAC_0_1.vmdk
(Optional) As EZT disks created on vSAN are not zeroed automatically, you must use the command “vmkfstools -w <path-to-vmdk>” to zero out all blocks if zeroing is required. Be aware of the additional IO workload on vSAN during zeroing
After the eager-zeroed disks are created, you must add them to the remaining RAC VMs using either the vSphere Web Client or PowerCLI.
Note: The virtual disks should be added to the same SCSI positions on each virtual machine. If a disk is in position 1:0 on one virtual machine, it should be in position 1:0 on all virtual machines in the RAC cluster.
Using the vSphere Web Client
Using PowerCLI
New-HardDisk -VM VM_Name -DiskPath “[datastore_name] folder/disk_file” -Controller controller_name -Persistence IndependentPersistent
New-HardDisk -VM RAC_1 -DiskPath “[vsanDatastore] RAC_0/RAC_0_1.vmdk” -Controller “SCSI Controller 1” -Persistence IndependentPersistent
For vSphere version prior to 6.0 Update 1
The addition of the multi-writer flag is not possible via the vSphere Web Client version prior to 6.0 Update 1. If vSphere 6.0 Update 1 or newer is not installed, use the ESXi shell to enable multi-writer mode on the applicable virtual machines and disks.
Note: As this involves modifying and loading virtual machine configurations, it is recommended that all RAC virtual machines be registered to the same ESXi host for the purposes of making these changes so we don’t have to log in to multiple hosts. The VMs can be distributed throughout the vSphere cluster after making these changes.
echo ‘scsi:.sharing = “multi-writer”’ >> path_to_VMX_file
echo ‘scsi1:0.sharing = “multi-writer”’ >> /vmfs/volumes/vsanDatastore/RAC_0/RAC_0.vmx
vim-cmd vmsvc/getallvms |grep -i VM_name
vim-cmd vmsvc/getallvms |grep -i RAC
vim-cmd vmsvc/reload VMID
vim-cmd vmsvc/reload 24
After the shared disks are created and added to all virtual machines using one of the three methods above, you must apply the storage policy created for the RAC shared disks. The policy must be applied to all applicable disks on all RAC virtual machines.
For more information on a similar process performed on VMFS datastores, see: