Key features#

The following features are some of the key capabilities of VM Replication:

• Continuous availability: Deliver an always-on customer experience

  • Hypervisor-based block-level replication

• Outages and disruption: Protect your brand from all disruptions

  • Continuous data protection provides RTOs and RPOs measured in seconds and minutes
  • Complete automation and orchestration of recovery with no manual steps
  • Simplicity with failover and failback in only three clicks

• Ransomware attacks: Avoid ransomware cost, data loss and downtime

  • Point-in-time recovery for seamless roll-back to moments before the attack
  • Journal provides rewind capability in approximately five-second increments for up to seven days

• Complete data protection: One platform for all your data protection needs

  • Automated testing to ensure recoverability with no impact to production
  • Reports for full compliance that are consistent with regulations like Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry (PCI), and General Data Protection Regulation (GDPR)

Architecture#

The following diagram illustrates the VM Replication architecture, including the following key components, as defined by Zerto IT Resilience Platform documentation:

Zerto Virtual Manager (ZVM): The ZVM manages everything required for the replication between the source and target sites except for the actual replication of data. The ZVM is deployed in the Rackspace management infrastructure and interacts with the vCenter Server to get the inventory of VMs, disks, networks, hosts, and so on. The ZVM also monitors changes in the VMware environment and responds accordingly.

Zerto Virtual Replication Appliance (VRA): The VRA is a virtual machine that manages the replication of protected virtual machine writes across sites. A VRA is installed on every hypervisor that hosts virtual machines that require protecting in the source site and on every hypervisor that hosts the replicated virtual machines in the target site.

Zerto Virtual Protection Group (VPG): The VPG groups virtual machines for replication purposes. For example, all the virtual machines that comprise an application, such as the database, application server, and web server, should be replicated to maintain data integrity. VPGs allow you to protect, recover, and test VMs together.

Zerto Journal: While processing transactions on the source site, ZvRA intercepts every write to a protected virtual machine and sends a copy of the write, asynchronously, to the target site. The target site adds the write to a journal managed by the ZvRA. Each protected virtual machine has its own journal. By default, the Zerto Journal is located on the Target VM Recovery Datastore. Each journal can expand to a size specified in the VPG definition and automatically shrinks when the expanded capacity is not needed.

How protection works#

With Zerto's hypervisor-based continuous data replication, Zerto copies every write to the VM and sends it, asynchronously, to the target site. At the same time, the source site continues to process the write.

On the target site, Zerto writes the write to a journal managed by the Zerto Virtual Replication Appliance (VRA). Each protected virtual machine has a unique journal. Every few seconds, the system writes a checkpoint to each journal. These checkpoints ensure write-order fidelity and crash-consistency to each checkpoint. During recovery, one of these crash-consistent checkpoints is selected and recovered to this point.

The Zerto VRA manages the journals for every source VM that will be recovered to the hypervisor hosting that VRA. It also manages the images of the protected volumes for these target VMs. During a failover, you can specify that you want to recover the source VMs in the VPG by using the last checkpoint. Alternatively, you can specify an earlier checkpoint, in which case the system synchronizes the recovery of the mirror images under the VRA to the chosen checkpoint. Thus, you can recover the environment to the point before any corruption and ignore later corrupted journal writes. The cause of the corruption, such as a crash in the source site or a ransomware attack, doesn't affect the recovery process.

Initial synchronization#

After you define a Virtual Protection Group (VPG), the system updates the Zerto VRA in the target site with information about the VPG. Then, the data on the source VMs is synchronized with the target VMs managed by the VRA on the target site.

For the synchronization to work, the source VMs must be turned on. To synchronize across the sites, the Zerto VRA requires an active IO stack to have access to the virtual machine data. If the virtual machine is not running, you have no IO stack to use to access the protected data for replication to the target site recovery disks.

The synchronization process can take some time, depending on the size of the source VMs, the amount of data in its volumes, and the bandwidth between the sites. During this synchronization, you cannot perform any replication task, such as failover operations.

After synchronization completes, the VRA on the target site includes a complete copy of every VM in the VPG. At this time, the source VMs in the VPG are fully protected, and the system sends the delta changes on these virtual machines to the recovery site.

Continuous data replication#

The following image illustrates continuous data repliction:

After the initial synchronization, Zerto copies every write to a source VM to the target site. At the same time, the source site continues to process the write and sends the copy asynchronously to the target site, where the system writes it to a journal managed by a Zerto Virtual Replication Appliance (VRA. Each protected source VM has a unique journal.

In addition to the writes, every few seconds, the system updates all journals with a checkpoint timestamp. These checkpoints ensure write-order fidelity and crash-consistency. You can recover to the last checkpoint or a user-selected, crash-consistent, checkpoint. The choice of recovery point enables you to recover the source VMs to either the last crash-consistent point-in-time or a point-in-time before a ransomware attack.

The system writes data and checkpoints to the source VM's Zerto Journal until the specified journal history size is reached, which is the optimum situation. At this point, while new writes and checkpoints are written to a journal, the older writes are written to the target VM recovery virtual disks. When you specify a checkpoint to recover to, the checkpoint must still be in the journal. For example, if the journal's history is seven days, you can specify recovery to any checkpoint within the previous seven days. After the time specified, the system updates the mirror virtual disk volumes (VMDK) maintained by the Zerto VRA.

Defining VPGs#

VPGs enable you to protect, recover, and test VMs together while maintaining write-order fidelity. The Zerto VPG must include at least one VM. After Rackspace creates the VPG, you can add or remove VMs as required. You can define how to group your source VMs into VPGs. Following are a few examples:

Group by customer: If you host a set of VMs in VMware Server Virtualization for each of your customers, you can create a VPG for each customer. This configuration ensures that you maintain write-order fidelity across all the VMs belonging to individual customers.

Group by workload or application: If you host multiple workloads or applications, you can group your VMs by each individual workload or application. For example, for your production application, which comprises a database, application, and web server, you can group these VMs into a single VPG to ensure write-order fidelity across all three tiers.

VMs that you cannot replicate#

You cannot configure VMs that have one of the following characteristics for a source VM:

• Active Directory VMs (We support and recommend Active Directory native replication.)
• VMs with raw device mappings (RDMs) (We plan to add support in the future.)
• Multi-write disk mode
• Oracle clusters
• RHEL clusters

VPG properties#

For each Source VM, you need to provide Rackspace the following properties:

• VPG name: The customer-defined name for the VPG to help you easily identify the contents of the VPG.

  For example, if you group VMs by customers, use the customer name or ID. If you group VMs by application or workload, use a descriptor, such as ProdCRM, to represent your Production CRM application.

• Journal history days: The length of time you can roll back VMs within a VPG upon recovery.

  Each VM can have a value of up to seven days. We recommend setting the Journal History Days to the maximum of seven days to ensure that you have the desired checkpoint for recovery in the Zerto Journal. For example, setting the Zerto Journal History to seven provides the ability to specify a recovery point-in-time within the last seven days.

  For example, if you accidentally decommission the wrong VMs and need to recover the VMs, but it takes you five days to identify the mistake, you can select the checkpoint before the decommission because you have a seven-day journal full of checkpoints.

• Boot order: The order in which the VMs contained within a VPG boot upon recovery. VMs boot in ascending order.

  For example, if the VPG includes a database, application tier, and web server tier and the database must be available before the application tier or web server, you can set the database boot order to 1, application tier to 2, and web server to 3.

• Failover IP range preference: Specify the range of IP addresses assigned to a VM upon failover via vSphere Guest Customization.

• High change rates:

Failover Operations#

To improve the RTO during recovery, you can start working even before the target VM volumes on the target Site have been fully synchronized. The system analyses every request and response returned from the Target VM directly or from the journal if the information in the journal is more current. This process continues until the recovery site virtual environment is fully synchronized, up to the chosen checkpoint when the integrity of the protected site was assured.

Roles and responsibilities#

The following table identifies the roles and responsibilities for Rackspace VMware Server Virtualization VM Replication:

Sizing

Deployment

Configuration

Testing and recovery

Monitoring and management

Official terms and conditions#

See the official terms and conditions at the following locations:

• VM Replication Terms and Conditions
• Rackspace (Intensive) Terms and Conditions