Part:05 Creating and Configuring VPG in Zerto

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.

  • Web Layer
  • Application Layer
  • Database Layer

    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


    image

    Figure: 01 –Step01 to create VPG

    image

    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.

    image

    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.

    Journal Datastore


    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

    image

    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

    image

    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.

    Boot Order


    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.

    image

    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.

    image

    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.

    image

    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.

    image

    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.

>Next post we will deal with Advance configuration

If you wish to follow entire series of Zerto go to the Landing Page

Technorati Tags: ,,,
Advertisements

One thought on “Part:05 Creating and Configuring VPG in Zerto

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s