You can use VMware Virtual SAN datastores as target datastores when configuring replications. Follow the guidelines when using vSphere Replication with Virtual SAN storage.

Note:

VMware Virtual SAN is a fully supported feature of vSphere 5.5 Update 1 and later.

Because user-friendly names of Virtual SAN datastores might change and cause errors during replication or recovery operations, vSphere Replication automatically replaces the user-friendly name of a datastore with its UUID, which is constant. Therefore, the UUID is displayed everywhere in the vSphere Replication user interface, though you selected a human-readable name during replication configuration.

Limits of Using vSphere Replication with Virtual SAN Storage

For reasons of load and I/O latency, Virtual SAN storage is subject to limits in terms of the numbers of hosts that you can include in a Virtual SAN cluster and the number of virtual machines that you can run on each host. See the Limits section in the VMware Virtual SAN Design and Sizing Guide at http://www.vmware.com/products/virtual-san/resources.html.

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 Virtual SAN storage by using vSphere Replication depends on your infrastructure. If you notice slower response times when you configure replications for virtual machines in Virtual SAN storage, monitor the I/O latency of the Virtual SAN infrastructure. Potentially, reduce the number of virtual machines that you replicate in the Virtual SAN datastore.

Note:

When you stop a replication, vSphere Replication does not delete the replica directory at the target datastore. As a result, stale directories remain on VMFS and NFS target datastores, and unused namespaces remain on Virtual SAN and Virtual Volume target datastores. Because the maximum number of directories and namespaces on a datastore is limited, you must manually clean them up to free resources on the datastore. See Clean Up the Target Datastore After You Stop a Replication.

Retaining Point-in-Time Snapshots when Using Virtual SAN Storage

Virtual SAN storage stores virtual machine disk files as a set of objects and components. Each disk object in Virtual SAN storage has mirror and witness objects. In the default Virtual SAN storage policy, a disk object has 2 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 Virtual SAN 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 Virtual SAN storage policy, the disk object will have 2 mirror components of 256 GB each and 1 witness, to make a total of 3 components.

  • If a virtual machine has one 512 GB disk and you use the default Virtual SAN storage policy, the disk object will have 4 mirror components of 256 GB each and 1 witness, to make a total of 5 components.

See the VMware Virtual SAN Design and Sizing Guide at http://www.vmware.com/products/virtual-san/resources.html for explanations of objects, components, mirrors, witnesses, and Virtual SAN storage policies.

If you enable multiple point-in-time (PIT) snapshots, you must make allowances for the additional components that each snapshot creates in the Virtual SAN storage, based on 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 Virtual SAN 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 Virtual SAN 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 Virtual SAN storage policy:

    • 2 (number of disks) x 10 (number of PIT snapshots) x 3 (2 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 Virtual SAN storage policy:

    • 2 (number of disks) x 10 (number of PIT snapshots) x 5 (4 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 Virtual SAN storage.