VMware vSphere Replication (VR) is a replication feature that is included with vSphere Essentials Plus Kit and higher editions of vSphere. Replication is configured on a per-VM basis with RPOs as low as five minutes. It is compatible with vSAN, as well as, other datastore types such as VMFS, NFS, and vSphere Virtual Volumes (vVols). VR is often used with VMware Site Recovery Manager to provide a tightly-integrated, reliable, automated disaster recovery solution.
vSAN is an excellent, cost-effective choice for storage at a secondary/disaster recovery site. It has the necessary performance to handle starting many VMs concurrently – also known as a “boot storm” – which is typical in a disaster recovery scenario. You can see a video here that shows Site Recovery Manager recovering 1000 VMs on a 4-node all-flash vSAN cluster in less than 30 minutes.
As mentioned a moment ago, VR is configured on a per-VM basis. This enables precise control over which VMs get replicated regardless of what storage the VMs’ files reside on. When configuring replication for a VM at the source location, it is possible to select a storage policy that is applied to the VM when it is recovered at the target location. What is not well known is what storage policy gets assigned to the replica of the VM at the target location (before recovery).
There is no way to see in the vSAN UI what storage policy is assigned to a VR replica at the target location before it is recovered. I decided to give the RVC command line interface (CLI) tool a try. If you are not familiar with the RVC tool, a quick search for vSAN RVC will bring up some leads.
Let’s look at a basic example. Using the latest GA builds of vCenter Server Appliance (VCSA) 6.5 and vSphere 6.5, which includes vSAN 6.6, I created a simple storage policy containing the rule FTT=0. I configured replication using the latest GA build of VR 6.5. The “FTT=0” policy was selected when configuring replication for a VM named “photon”.
I started by listing the objects on the vSAN datastore using the RVC tool:
/<vcenter ip>/datacenter/datastores/vsanDatastore/files> ls
0 d8d80159-4784-2605-ce8f-005056adeafe
1 wdcpod06vm16
2 3cc2db58-b8c6-0a5b-88fe-005056adf8d8
3 vm04
4 2c6dd158-2c4a-6581-70ed-005056adf8d8
5 .vsan.stats
6 56badb58-007e-7e89-12b6-005056adf8d8
7 vm02
8 31c1db58-8ee3-178b-753b-005056adeafe
9 vm03
10 2cb6db58-90a8-33c2-2827-005056adf8d8
11 vm01
12 48370259-8bca-3bca-545a-005056ad76e4
13 photon
There are five VMs running on the vSAN datastore. There is also the .vsan.stats object which is my vSAN performance service data. The last two lines (12 and 13) are the VR replica for the VM named “photon”. Here is what I saw when running the vsan.object_info cluster RVC command for the VR replica object:
/<vcenter ip>/datacenter/computers> vsan.object_info cluster 48370259-8bca-3bca-545a-005056ad76e4
DOM Object: 48370259-8bca-3bca-545a-005056ad76e4 (v5, owner: wdcpod06vm11.eng.vmware.com, proxy owner: None, policy: hostFailuresToTolerate = 0, spbmProfileId = dd669141-7941-4f01-bef9-e6c2413d43c2, stripeWidth = 1, spbmProfileName = FTT=0, proportionalCapacity = [0, 100], spbmProfileGenerationNumber = 0, CSN = 2)
Component: 48370259-4e7b-b5ca-407e-005056ad76e4 (state: ACTIVE (5), host: wdcpod06vm11.eng.vmware.com, md: naa.6000c2968e4f8a5f30cfe0d0aa1b87a2, ssd: naa.6000c292346b4c1ef2c3f53731687269,
votes: 1, usage: 0.4 GB, proxy component: false)
This is exactly what I expected. The replica is assigned the storage policy that was selected (“FTT=0”) when initially configuring replication. There is one component, which is evidence of the FTT=0 policy rule being applied.
Here is what I did not expect: I reconfigured replication for the VM using the VR “Reconfigure…” option and changed the selected storage policy to a policy named “RAID-5 Erasure Coding”. I assumed this would change the policy assigned to the replica. It did not. The replica still had the “FTT=0” policy assigned.
/<vcenter ip>/datacenter/computers> vsan.object_info cluster 48370259-8bca-3bca-545a-005056ad76e4
DOM Object: 48370259-8bca-3bca-545a-005056ad76e4 (v5, owner: wdcpod06vm11.eng.vmware.com, proxy owner: None, policy: hostFailuresToTolerate = 0, spbmProfileId = dd669141-7941-4f01-bef9-e6c2413d43c2, stripeWidth = 1, spbmProfileName = FTT=0, proportionalCapacity = [0, 100], spbmProfileGenerationNumber = 0, CSN = 2)
Component: 48370259-4e7b-b5ca-407e-005056ad76e4 (state: ACTIVE (5), host: wdcpod06vm11.eng.vmware.com, md: naa.6000c2968e4f8a5f30cfe0d0aa1b87a2, ssd: naa.6000c292346b4c1ef2c3f53731687269,
votes: 1, usage: 0.4 GB, proxy component: false)
However, when I recovered the VM using VR, the “RAID-5 Erasure Coding” policy was assigned to the newly recovered VM. There are four components that make up this object now, each on a separate host. This is evidence of the RAID-5 erasure coding rule being applied.
/<vcenter ip>/datacenter/computers> vsan.object_info cluster 48370259-8bca-3bca-545a-005056ad76e4
DOM Object: 48370259-8bca-3bca-545a-005056ad76e4 (v5, owner: wdcpod06vm11.eng.vmware.com, proxy owner: None, policy: stripeWidth = 1, replicaPreference = Capacity, CSN = 13, proportionalCapacity = [0, 100], spbmProfileId = 210cca00-6099-4737-aaac-ff637d17c981, spbmProfileName = RAID-5 Erasure Coding, hostFailuresToTolerate = 1, spbmProfileGenerationNumber = 0)
RAID_5
Component: cf3e0259-786f-a39b-87d5-005056adf56e (state: ACTIVE (5), host: wdcpod06vm11.eng.vmware.com, md: naa.6000c2968e4f8a5f30cfe0d0aa1b87a2, ssd: naa.6000c292346b4c1ef2c3f53731687269,
votes: 2, usage: 0.2 GB, proxy component: false)
Component: cf3e0259-b1c7-a59b-a198-005056adf56e (state: ACTIVE (5), host: wdcpod06vm06.eng.vmware.com, md: naa.6000c29db3a70f242ed1bd366628cad3, ssd: naa.6000c29af1da88377b4bbee35692e860,
votes: 1, usage: 0.1 GB, proxy component: false)
Component: cf3e0259-f4b2-a79b-b6b1-005056adf56e (state: ACTIVE (5), host: wdcpod06vm08.eng.vmware.com, md: naa.6000c2994f2ccdb916bebd6b559f91d5, ssd: naa.6000c29b39cdfc81c5d9b97e7864510a,
votes: 1, usage: 0.2 GB, proxy component: false)
Component: cf3e0259-670e-a99b-c447-005056adf56e (state: ACTIVE (5), host: wdcpod06vm09.eng.vmware.com, md: naa.6000c29698cfd423bbca0ec4379291c2, ssd: naa.6000c293745e71aae14e370f2132e926,
votes: 1, usage: 0.1 GB, proxy component: false)
In other words, selecting a different policy for a VM when reconfiguring replication does not change the policy assigned to the replica. The newly selected policy is assigned when the VM is recovered.
Summary:
1. A VR replica is assigned the policy selected when replication is initially configured.
2. If you reconfigure replication, the policy assigned to the replica does NOT change.
3. When you recover the VM, the policy that was selected when reconfiguring replication is applied to the recovered VM.
@jhuntervmware on Twitter
