Skip to content
iland Cloud Official Site
iland Cloud Official Siteiland Cloud Official Site
  • Why iland
    • Submenu
      • Column 1
        • iland secure cloud console
          Secure Cloud Console
          iland compliance
          Compliance
          iland proven technology
          Cloud Platform
          iland pricing
          Pricing

      • Column 2
        • iland Security
          Security
          iland global regions
          Cloud Regions
          iland networking
          Cloud Connectivity
          iland interactive tour
          Interactive Tour

      • WHY CHOOSE iland
      • OverviewYour business is unique, your cloud should be too.
      • About ilandThe making of a market leader.
      • LeadershipMeet our experienced & knowledgeable executive team.
      • News & MediaFind out what’s new and happening at iland.
      •  
      • CareersYour future starts here. Join the #ilandlife today.
      • Technology PartnersGreat partnerships are built on great technologies.
      • Customer StoriesDiscover why customers are choosing iland Cloud.
      • BlogTips, tricks, opinions, and news from iland experts.
  • Products & Services
    • Products & Services
      • PRODUCTION HOSTING
      • Secure Cloud Overview
      • Secure Public CloudRun VMware natively. No refactoring required.
      • Secure Private CloudDedicated cloud for performance and security.
      • Object StorageS3-compatible storage for long-term retention.
      • BACKUP
      • Secure Backup Overview
      • Secure BackupSecure cloud backup for no-compromise data protection
      • Microsoft 365Complete data protection for Microsoft 365
      • DISASTER RECOVERY
      • DRaaS Overview
      • DRaaS with VeeamSimplified Disaster Recovery for your unique business
      • DRaaS with ZertoContinuous availability for 24×7 IT resilience
      • AutopilotFully-managed disaster recovery as a service.
      • DRaaS for Physical ServersReplicate physical servers to iland.
      • MANAGED SECURITY
      • Managed Security Overview
      • Continuous Risk ScanningDiscover and monitor vulnerabilities
      • Managed SIEMManaged security information and event management
      • Managed EDRManaged endpoint detection and response
      • Managed FirewallSimplify and improve network edge security
      • SUPPORTING SERVICES
      • Cloud Labs
      • Cloud Connectivity
      • Colocation/Bare-Metal
      • Managed Services
      • Migration Services
      • 24x7x365 Support
      • Strategy, Assessment & Planning
  • Solutions
    • Solutions Submenu
      • INDUSTRY
      • Education
      • Financial
      • Government
      • Healthcare
      • Column 2
        • iland Health Solutions

          Keep IT healthy.

          See our healthcare expertise.

          What's next in finance?

          Transform & modernize your IT.
          Learn More
          Learn More
  • Partners
    • Partners Submenu
      • Overview
      • Become a Partner
      • Login to Portal
  • Resources
    • Resources Submenu
      • Events
      • Webinars
      • News & Media
      • Whitepapers
      • Podcast
      • Datasheets
      • Customer Stories
      • Innovation Blog
  • Support
    • Support Submenu
      • Contact Support
      • Success Center
      • API Documentation
Search:
  • Console Login
  • Contact Us
Header Right Menu
Free Trial
  • Why iland
    • Secure Cloud Console
    • Compliance
    • Cloud Platform
    • Pricing Model
    • Security
    • Cloud Regions
    • Cloud Connectivity
    • Interactive Tour
    • WHY CHOOSE iland
    • OverviewYour business is unique, your cloud should be too.
    • About ilandThe making of a market leader.
    • LeadershipMeet our experienced & knowledgeable executive team.
    • News & MediaFind out what’s new and happening at iland.
    •  
    • CareersYour future starts here. Join the #ilandlife today.
    • Technology PartnersGreat partnerships are built on great technologies.
    • Customer StoriesDiscover why customers are choosing iland Cloud.
    • BlogTips, tricks, opinions, and news from iland experts.
  • Products & Services
    • PRODUCTION HOSTING
    • Secure Cloud Overview
    • Secure Public CloudRun VMware natively. No refactoring required.
    • Secure Private CloudDedicated cloud for performance and security.
    • Object StorageS3-compatible storage for long-term retention.
    • BACKUP
    • Secure Backup Overview
    • Secure BackupSecure cloud backup for no-compromise data protection
    • Microsoft 365Complete data protection for Microsoft 365
    • DISASTER RECOVERY
    • DRaaS Overview
    • DRaaS with VeeamSimplified Disaster Recovery for your unique business
    • DRaaS with ZertoContinuous availability for 24×7 IT resilience
    • AutopilotFully-managed disaster recovery as a service.
    • DRaaS for Physical ServersReplicate physical servers to iland.
    • MANAGED SECURITY
    • Managed Security Overview
    • Continuous Risk ScanningDiscover and monitor vulnerabilities
    • Managed SIEMManaged security information and event management
    • Managed EDRManaged endpoint detection and response
    • Managed FirewallSimplify and improve network edge security
    • SUPPORTING SERVICES
    • Cloud Labs
    • Cloud Connectivity
    • Colocation/Bare-Metal
    • Managed Services
    • Migration Services
    • 24x7x365 Support
    • Strategy, Assessment & Planning
  • Solutions
    • INDUSTRY
    • Education
    • Financial
    • Government
    • Healthcare
    • Column 2
  • Partners
    • Overview
    • Become a Partner
    • Login to Portal
  • Resources
    • Events
    • Webinars
    • News & Media
    • Whitepapers
    • Podcast
    • Datasheets
    • Customer Stories
    • Innovation Blog
  • Support
    • Contact Support
    • Success Center
    • API Documentation
  • Contact Us
  • Console Login
  • Free Trial
Tags: Disaster Recovery
Author: Mike Mosley
Date: January 30, 2017

Zerto Replication to the Cloud – VPG Considerations and Best Practices

Secure_cloud_blogSo, having covered an introduction to Zerto and installation and configuration best practices in my two most recent blogs, I’m now going to tackle the very important topic of Virtual Protection Groups (VPGs). Zerto VPGs allow you to create a group of VMs to be protected together, giving you many different options for replication and recovery configuration. With your ZVM and VRAs installed, you are now ready to create Virtual Protection Groups (VPGs). In this blog, I’ll delve into the key things you need to consider when creating a VPG as well as best practices to ensure your Zerto cloud DR environment is optimized.

VPG Grouping Considerations

When creating a VPG, the main thing to consider is how you wish to group your VMs for replication and recovery. You may have a large variety of servers that manage different services or applications as well as servers on multiple networks. Ultimately, the decision on how to create VPGs will be up to you, but reviewing the considerations below during the VPG creation process will help greatly.

First, you may want to consider creating a VPG that is reserved for your Domain Controllers or Active Directory Servers. In the event of a failover, you want to make sure this is the first VPG to failover to ensure your domain is established on the recovery side before the other servers failover. You may run into issues if a SQL or Web server powers on before the Domain servers do as that will restrict access or communication with the domain.

When it comes to creating VPGs for the rest of your servers, there are several ways to group up VMs. A good idea might be to group servers that are dependent on each other for running an application. If you have a web server that works with a backend database server, you might want to group these servers together. This way, if there is a failover scenario, you know these two servers will failover together. You can also set a boot order within the VPG, so in our case, we may want to make sure that during a failover, our database server powers on first, then the web server. Depending on your set up, you may have multiple servers, exchange servers and application servers. You could consider grouping servers by their services. For instance, placing the AD/DC and other critical domain servers in 1 or 2 VPGs. Next, you might have the exchange and database servers in their own groups. Lastly, applications servers would be grouped together in one or more VPGs. So, during a failover, you would first kick off the critical domain groups, then the exchange and database VPGs and lastly your application servers. The goal is to try to have your VMs grouped so that it provides an easy and understandable flow during failover scenarios.

Optimizing RPOs with VPGs

Another thing to consider is that servers will replicate and failover as a group. What this means is that the sum of all data change between all servers in the VPG are replicated in one group. So, if you have 1 SQL server and 4 web servers in 1 VPG, that VPG must replicate the changes made by all 4 servers. This can possibly cause issues in VPGs where there is one server that creates a significant amount of data change as compared to others servers in the VPG. For instance, in our case the SQL server may be causing a large amount of change, while the web servers are mostly static. The Recovery Point Objective (RPO) of this VPG as a whole may suffer, as Zerto may hit points where it is struggling to keep up with the changes caused by our SQL server. In this case, it may be best to separate the SQL server to its own VPG. This way, our 3 web servers will stay in sync as the VPG is only concerned with their changes, the SQL server will also see a boost in performance as the bandwidth for this VPG is reserved only for SQL changes. The SQL VPG can also be given a High Priority, which tells Zerto to allocate more bandwidth to this VPG. This also means that during a failover, all VMs in the group are failed over. So with our VPG containing the 3 webservers, all 3 will be failed over together, there is no way to failover just one of the servers in the VPG.

Finally, keep in mind the number of VMs you put in one VPG. If you are only protecting 10 VMs, you may create just 1 VPG so you are able to easily failover the servers and control their boot order in the VPG. However, you lose some granularity with this. If only one of the servers is down or needs to failover, you have to failover the whole environment. Depending on your bandwidth, you may also start running into issues like the 3 web servers and 1 SQL server described above.

Creating VPGs

Once you have an idea of how to group your servers in VPGs, the next step is to create them. In your Zerto console, you can click on the VPGs tab which will show a page similar to the one below. By clicking the New VPG button, you can start creating your first VPG.

 

Zerto_vpg-list

The first step is to give the VPG a name and set its priority. Priority can be given a High, Medium and Low priority, and this determines how Zerto will prioritize bandwidth allocation. For instance, a VPG with High priority will be given more bandwidth than VPGs with Medium or Low bandwidth. In the case where you have 3 VMs with High priority, more bandwidth is allocated to the group that has the larger amount of data change. This can be helpful during the initial replication period, times where the production environment is experiencing high load or after network disconnects. If you have servers that are more critical, or maybe have higher change rate than the others, you may want to give those VPGs a high priority. This will ensure that your critical servers consume the bulk of your bandwidth and stay in sync.

create_vpg

Next, you will pick the VMs to add to your VPG. In the left-hand column, you will see all your servers that are on hosts with a VRA. To add a server to the VPG, check the box next to one or more of the servers and click the Right Arrow button.

create_vpg_test

Once you have added the servers to the VPG, you can alter the boot order by clicking the Define Boot Order button above the Selected VMs. The boot order is determined by grouping your VMs into different folders. In my screenshot, I have the iland-test server booting first in the Default Folder. I have moved the iland-test-1 server to NEW GROUP 2. To create a group, click the ADD GROUP button in the Boot Order window. To create a boot order, set the Boot Delay to the number of seconds you want to wait before the NEXT GROUP is powered on. The screenshot is set to have iland-test boot first, wait 60 seconds, and then boot iland-test-1. When the boot order is set, click OK and then Next.

boot_order

VPG Rules and Alerting

Under the Replication Tab, we can change many of the rules and alerting for the VPG:

  • Recovery Site: This is the failover environment the servers are replicating to and will failover to. Typically, you will just have the iland datacenter as an option here. If you are replicating to multiple sites, just make sure the server to be protected to iland has the iland datacenter selected.
  • VC/VCD: You may only see this option if you are using a vCloud Director environment on the source site. The iland ECS environment is based off vCloud Director, so you will choose VCD if you have this option.
  • ZORG: This is your customer dedicated organization in the ECS environment. You will most likely just have 1 option for this setting, which is your iland provided Org name.
  • Recovery Org vDC: This is the Virtual Datacenter created for your ECS organization. Again, you will typically just have on option here. This is where the resources for your environment are allocated.
  • Service Profile: By default, a system Service profile is used that is just a template for setting the remaining settings. To make a change to the VPG’s Journal History, RPO Alert or Test Reminder, select Customer on this dropdown.
  • Journal History: By default, this is 4 hours. The Journal History determines the amount of time that is safe for recovery. With a 4 hour journal history, you will be able to recover to a point 4 hours prior. This can be set to a higher amount, but keep in mind that a larger journal history consumes more storage as it saves more restore points.
  • Target RPO Alert: This is the alert threshold set when monitoring the RPO of a VPG and is set to 5 minutes by default. In most cases, your RPO should be around 15 or 20 seconds. However, if the bandwidth is saturated by high change rate or network issues, the RPO may begin to grow. In this case, if the RPO reaches 5 minutes, meaning Zerto has not been able to create a checkpoint in 5 minutes, Zerto will begin alerting you of the RPO breach.
  • Test Reminder: Set to none by default, this sets a reminder for Zerto to alert you when you have gone a certain period of time without conducting a failover test.
  • There are advanced settings for the journaling that can be changed, but it is best to leave this to default unless instructed otherwise by iland or Zerto support.

create_vpg_3

Click Next to continue to wizard. Under the Storage tab, you will see the disks attached to all servers in the VPG. You may notice that the Thin check box is checked for some of the disks. This means that the source server disk is using Thin Provisioning. On the iland side, the disks are deployed using Thick Provisioning. The source side may have a 100GB thin provisioned disk with only 50GB used. This means the amount of space used by this server is just 50GB. To prevent over provisioning on iland’s side, we will convert this to Thick provisioning. So, the disk set to 100GB will actually consume 100GB of storage. You will see more accurate storage usage numbers in the Zerto console if you uncheck all of the checkboxes under the Thin Column.

The Swap column allows you to set a disk to be ignored by Zerto. Keep in mind that during the initial replication, this disk will be replicated. However, after the initial sync, the disk is no longer replicated. This can be helpful if you have swap files on servers or dedicated disks for log files or backups that are not necessary during a failover scenario. Click Next to continue.

create_vpg_storage

Under the Recovery tab, you can set the networks to be used by the VMs in the VPG on failover. Usually, iland will create a network that mimics your production network(s). If you group VMs together that use different networks, we will be able to change the networks for individual NICs on the next page. This setting helps you to set the bulk of the VMs to use one network. You can also choose different networks for a Live Failover and Test Failover. For instance, if you want the failover environment to use the same subnet as production, but a different subnet during a test, that can be configured here. Keep in mind that changing the network requires the IPs to change on the failed over servers, which might break certain ties between servers or applications when communicating.

There is also a vCD Guest Customization checkbox on this page. vCD Guest Customization is a VMware vCloud Director feature that allows you to change guest operating systems for a server from outside the VM. This can be helpful for templates, but with servers already configured it can be tricky. The server’s hostname, IP address and DNS servers could be changed and domain controllers or services may be severely affected. Therefore, this feature is not typically recommended for use. If you are changing IPs, iland engineers will work with you on this feature to make sure we prevent any unwanted changes. When you have the networks selected, click Continue.

create_vpg_recovery

The NICs tab will show the NICs for each VM, the Network they are attached to, if they will be connected on failover, and the IP/MAC address used. Here you can change the network for individual NICs and their IP assignments. For instance, if a VM has 2 NICs that connect to 2 different networks you can match that configuration here. Or if you have all servers on a Production Network with one of the servers being on a DMZ network. You can also choose to have a NIC disconnected, in a case where it might be attached to a network not needed in a recovery situation. The IP should be pulled from the VMware tools in your environment. If the IP is not automatically added, you may need to input the IP manually, or add a new IP to be used if you are switching subnets. The MAC Address should match the source servers MAC Address and stay the same on failover. Keep in mind that there is a Live Failover/Move tab and a Test tab. So you can change the network settings for a test, but leave everything the same during a Live Failover.

create_vpg_nic

It may be easier to adjust network settings for a NIC by checking the box on the left-hand side and clicking the EDIT SELECTED button. This brings up the Edit vNIC window where you can change and copy over settings for Live and Test failover scenarios. Once you have your networks set as desired, click OK and Next to continue.

edit_vnic

The next page will be for Zerto Backups. Right now, that is not being utilized by iland and can be skipped. If you need more information about the Zerto backups, please contact your account manager. Continue on to the Summary tab.

The last Summary tab will show your VPG settings. Verify these settings are correct and click Done to create the VPG. You should now see your VPG listed under the VPGs tab and once created it will being its initial replication. You can continue to create more VPGs from here, but keep in mind that the more VPGs initializing, the more bandwidth that will be consumed by Zerto. You may find that it is best to allow VPGs to finish their initial sync before creating another one.

create_vpg_summary

I hope you found this overview of Zerto VPG considerations and best practices useful. It is certainly worth taking the time to carefully allocate your VMs to VPGs before going live with your Zerto Cloud replication. Doing this could save you a lot of heartache during a failover situation! In my next blog, I’ll cover live and test failovers.

Categories: DRaaS, ZertoBy Mike MosleyJanuary 30, 2017
Tags: Disaster Recovery

Author: Mike Mosley

Mike Mosely is a cloud engineer at iland and has worked at the company for over 3 years. He holds a number of VMware certifications including VCP5 as well as the Veeam VMCE certification. Mike works closely with customers to build cloud solutions that fit their requirements.

Post navigation

PreviousPrevious post:Your Own Private iland: Secure Private CloudNextNext post:Zerto Cloud Disaster Recovery – Installation and Configuration Best Practices

Related Posts

What Our Customers Have to Say About 2022’s Most Pressing Cloud Challenges
June 10, 2022
Multi-Cloud, Agents, and You
May 31, 2022
Why DR will matter even more in 2022
January 27, 2022
Surviving the Data Protection Horror Show
November 4, 2021
2022 Data Protection
November 2, 2021
Is Disaster Recovery a good business investment?
September 28, 2021
iland, an 11:11 Systems Company
PRODUCTS & SERVICES
  • Secure Cloud
  • Backup
  • Disaster Recovery
  • Managed Security
  • Cloud Connectivity
  • 24x7x365 Support
  • Compliance
  • Free Trials
COMPANY
  • Why iland
  • Cloud Platform
  • Customer Stories
  • Careers
  • Leadership
  • Technology Partners
  • News & Media
  • Contact Support
CLOUD LOCATIONS
  • Dallas, TX
  • Los Angeles, CA
  • Northern Virginia
  • Toronto, Canada
  • London, UK
  • Manchester, UK
  • Amsterdam, NL
  • Singapore
  • Melbourne, AU
  • Sydney, AU
CONNECT
  • LinkedIn
  • Twitter
  • Facebook
  • Youtube

© 2022 iland™ All Rights Reserved | Privacy Notice

Go to Top