Lets divide this post into three parts.
1. Definition of VPG
2. Requirements of VPG
3. Configuring VPG
1. Definition of VPG
VPG stands for Virtual Protection Group. VPG is there for logically binding VMs together. This concept is same as protection group in Site Recovery Manager (SRM) but VPG is more advanced than the SRM. As with VPG we get lot more options.
VPG helps to identify services and map those to the corresponding VMs. Lets take example of three tier application.
You can create a single VPG and add all 3 VM inside VPG. By creating VPG you are assured of all VMs associated with the service are replicated in synch and when DR event occurs, service is also available
After VPG is created, VMs inside VPG starts replicating to paired site. There on any changes made to protected VM is replicated to remote VM. There is no limit to number of VPG you can create. Limit is applied via number of VMs. You can protect maximum 5000 VMs per site.
2. Requirements of VPG
VRAs are installed.
At least one VM must be there to create VPG
For synch to work VM to be protected must be powered ON
3. Configuring VPG
Figure: 01 –Step01 to create VPG
Figure: 02 –explanation of various field in Manage VPG tab
Some fields in figure: 02 are quite self explanatory. I will skip those. I will speak of two very important field. Default Journal History and Target RPO Alert.
Please note Failover Test Network must be created in DR site. It is not automatically created. All you need to decide if you want this network to be available outside virtual infrastructure. In SRM this is referred as bubble network.
WAN Compression is available only in enterprise license.
Default Journal History
By default 4 hours is configured as default journal history. It means write commands of last 4 hours are saved in the datastore. Journal history is maintained for each protected VM in its dedicated Datastore. Datastore configurable per VPG.
When you wish to recover a VM with default journal size of 4 hours, you have checkpoints (restore points) for last 4 hours. Default Journal history is configurable from 1 hours to 96 hours (5 days).
This default journal size also influences the amount of time DR test can be done. When DR test is initiated VM is formed with the volume size equal to journal size. If default journal size is 4 hours, so all restore points after 4 hours will be overwritten by new restore point. Therefore DR test would be restricted for only 4 hours.
You can customize the journal datastore further especially if you wish to limit Journal size and define which datastore to use.
By default Journal is stored in the datastore which you have selected as recovery datastore
You have the option of specifying dedicated datastore to put Journal files. However during recovery ESXi host must have access to this datastore.
In below figure Journal datastore and recovery datastore are same. One can see both the VMs and Journals in the same datastore. It is worth pointing Zerto identifies VM using different naming convention. e.g. drvm01 is identified as vm-581 and same is reflected in journal volumes
Target RPO Alert
It is maximum time between each automatic checkpoint being written to Journal. So checkpoints are written within 5 min (default value). If they cannot be written or are delayed alert is issued. This alert includes detailed message why checkpoint couldn’t be written.
Lets talk little bit of boot order. Boot order has similar concept as we have seen for vApp or in SRM. All VMs part of group will be boot in any order. If you wish to control the boot order you must create different groups.
In above figure there is default group (you cannot delete). drvm01 and drvm02DB will restart in any order. If you wish to control the boot order, create a different group.
In above case I have configured drvm01 to start up with zero delay but VMs inside DBs group will start after delay of 30 seconds. Please note it says “Start-up delay to next group”. So what ever value you configure in this section actually impacts the VMs in next start up group.
VM level Configuration
You can do VM level configuration. These configuration includes VM HDD and IP configuration in DR site.
You also have option under VM Advanced Settings to configure per VM level recovery host, datastore, recovery folder and Journal sizing. To keep things simpler keep these values in line with VPG default configuration.
However since in DR we tend to use static IP it is strongly recommended to assign IPs to the VM when in DR. Normally network admins will provide a subnet of IP in DR. We vmware administrator must allocate IP to the VMs which need DR services. However this information generally stays in excel sheet and might get lost during DR. I strongly feel that all IPs in DR must be pre-allocated to VMs. This is where NICs section in above screen comes to our help.
when you click on Configure Selected NIC new window pops out. Entire IP details as shown above. If you wish to have same IP for test you can use Copy to test. Though Copy to test button would be used rarely. If you don’t configure NICs, Production IP address scheme is used in DR. In my experience I’ve not seen Prod IP being useful in DR site . So change is must. However one thing I have noticed during DR test, VM automatically restarts to incorporate new IP Address scheme. This is definitely going to add delay, I would look forward to Zerto do something about this. So if you change IP Address scheme for DR or Test your VM is going to take extra boot.
Update: Change of IP Address in this Guest OS will work only if VMware tools are installed. All standard Guest OS are supported.
Also during DR event updating DNS task must be communicated to Network or Active Directory team. DNS updates are key to get application up and running.
I feel I have just scratched the surface of configuring VPGs. There is lot here to think and plan. I couldn’t cover the various field which impact the SLA of VPG. I would cover them in future sections or at least refer them or re-post them.
If you wish to follow entire series of Zerto go to the Landing Page