When configuring replications, you can use VMware vSAN datastores as target datastores. Follow the guidelines when using vSphere Replication with vSAN storage.
User-friendly names of directories on vSAN datastores might change and cause errors during replication or recovery operations. Because of this reason, vSphere Replication automatically replaces the user-friendly name of a directory with its UUID, which is constant. As a result you may see the UUID displayed in the Site Recovery user interface instead of a human-readable name.
Limits of Using vSphere Replication with vSAN Storage
Because of load and I/O latency, vSAN storage has limits for the numbers of hosts that you can include in a vSAN cluster and the number of VMs that you can run on each host. See the Limits section in the VMware vSAN Design Guide at https://core.vmware.com/resource/vmware-vsan-design-guide.
Using vSphere Replication adds to the load on the storage. Every virtual machine generates regular read and write operations. Configuring replications on those virtual machines adds another read operation to the regular read and write operations, which increases the I/O latency on the storage. The precise number of virtual machines that you can replicate to vSAN storage by using vSphere Replication depends on your infrastructure. If you notice slower response times when you configure replications for virtual machines in vSAN storage, monitor the I/O latency of the vSAN infrastructure. Potentially, reduce the number of virtual machines that you replicate in the vSAN datastore.
Retaining Point-in-Time Snapshots When Using vSAN Storage
vSAN storage stores virtual machine disk files as a set of objects and components. Each disk object in vSAN storage has mirror and witness objects. In the default vSAN storage policy, a disk object has two mirrors and one witness. The number of mirror components is determined by the size of the virtual machine disk and the number of failures to tolerate that you set in your vSAN storage policy. A mirror object is divided into components of a maximum size of 256 GB each.
- If a virtual machine has one 256 GB disk and you use the default vSAN storage policy, the disk object has two mirror components of 256 GB each and one witness - a total of three components.
- If a virtual machine has one 512 GB disk and you use the default vSAN storage policy, the disk object has four mirror components of 256 GB each and one witness - a total of five components.
See the VMware vSAN Design Guide at https://core.vmware.com/resource/vmware-vsan-design-guide for explanations of objects, components, mirrors, witnesses, and vSAN storage policies.
If you enable multiple point-in-time (MPIT) snapshots, you must make allowances for the additional components that each snapshot creates in the vSAN storage. You must consider the number of disks per virtual machine, the size of the disks, the number of PIT snapshots to retain, and the number of failures to tolerate. When retaining PIT snapshots and using vSAN storage, you must calculate the number of extra components that you require for each virtual machine:
Number of disks x number of PIT snapshots x number of mirror and witness components
Examples of using this formula demonstrate that retaining PIT snapshots rapidly increases the number of components in the vSAN storage for every virtual machine that you configure for vSphere Replication:
- You have a virtual machine with two 256 GB disks for which you retain 10 MPIT snapshots, and you set the default vSAN storage policy:
- 2 (number of disks) x 10 (number of PIT snapshots) x 3 (two mirror components + 1 witness) = 60 components for this one virtual machine.
- You have a virtual machine with two 512 GB disks for which you retain 10 PIT snapshots, and you set the default vSAN storage policy:
- 2 (number of disks) x 10 (number of PIT snapshots) x 5 (four mirror components of 256 GB each + 1 witness) = 100 components for this one virtual machine.
The number of PIT snapshots that you retain can increase I/O latency on the vSAN storage.
