You can use VMware Virtual SAN datastores as the source and target datastores when configuring replications. Follow the guidelines when using vSphere Replication with Virtual SAN storage.
- You can use Virtual SAN in production environments with vSphere Replication 5.5.1 and vSphere 5.5u1.
- Virtual SAN is an experimental feature in vSphere 5.5. You can perform testing with Virtual SAN with vSphere Replication 5.5.0 and vSphere 5.5, but it is not supported for use in production environments. See the release notes for the vSphere Replication 5.5.0 release for information about how to enable Virtual SAN in vSphere 5.5.
vSphere Replication does not support replicating or recovering virtual machines to the root folders with user-friendly names on Virtual SAN datastores. These names can change, which causes replication errors. When selecting Virtual SAN datastores, always select folders with UUID names, which do not change.
Configuring Replications
When configuring replications for a single virtual machine, vSphere Replication creates the destination folder that you choose, obtains the UUID reference for that folder, and then uses the UUID name rather than the user-friendly name. The UUID name is visible when vSphere Replication displays the target folders when reconfiguring replications.
When configuring replication for multiple virtual machines, create a root folder in the Virtual SAN datastore, obtain its UUID name, and use the folder that is identified by the UUID in the replication wizard.
Configure vSphere Replication on batches of a maximum of 30 virtual machines at a time.
Configuring Replications by Using Replication Seeds
When copying replication seed files to the target datastore, you can use the vSphere Web Client to create a new root folder on a Virtual SAN datastore, or place the files in an existing folder. When you configure replications that use replication seeds, you must select the folder by using its UUID name. Selecting the user-friendly folder names is not supported.
Reconfiguring Replications
- Select the UUID name of an existing folder.
- Allow vSphere Replication to create a new folder and obtain its UUID name.
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 vSphere Replication 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 vSphere Replication 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.
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.
