Introduction to Protecting Virtual Machines
Virtual machines are protected in virtual protection groups (VPGs). A VPG is a group of virtual machines that you group together for recovery purposes. For example, the virtual machines that comprise an application like Microsoft Exchange, where one virtual machine is used for the software, one for the database, and a third for the Web Server require that all three virtual machines be replicated to maintain data integrity.
Once a virtual machine is protected, all changes made on the machine are sent to the remote site. The remote site can be recovered to any point in time defined for the VPG or if a period further in the past is required, a retention set can be restored.
Any virtual machine whose operating system is supported in both the protected site and AWS can be protected in a VPG.
When a VPG is created, application data and the data required to recreate the protected virtual machines are copied to AWS during a process of synchronization. This synchronization between the protected site and AWS takes time, depending on the size of the virtual machines.
After the initial synchronization completes, only the writes to disk from the virtual machines in the protected site are sent to AWS. These writes are stored by the Virtual Replication Appliance (VRA) in the journals in an S3 bucket for a specified period, after which they are promoted to the replica virtual disks managed by the VRA, which are also in an S3 bucket.
The number of VPGs that can be defined on a site is limited only by the number of virtual machines that can be protected.
For the maximum number of virtual machines, either being protected or recovered to a site, see Zerto Scale and Benchmarking Guidelines
Note: | If the total number of protected virtual machines on the paired sites is 5000, then any additional machines are not protected. |
Any virtual machine that is supported by the protected site hypervisor can be protected. The protected virtual machines must also be supported by the recovery AWS site.
The following topics are described in this section:
• | Configuring Virtual Protection Groups |
• | The Role of the Journal During Protection |
• | What Happens After the VPG is Defined |
Configuring Virtual Protection Groups
The number of VPGs that can be defined on a site is limited only by the number of virtual machines that can be protected.
For the maximum number of virtual machines, either being protected or recovered to a site, see Zerto Scale and Benchmarking Guidelines
Note: | If the total number of protected virtual machines on the paired sites is 5000, then any additional machines are not protected. |
VPGs can be created on the on-premise site or in AWS. The virtual machines on the on-premise site can be defined under a single hypervisor host or under multiple hosts.
To create a VPG that will be recovered to AWS, you must have a virtual instance in AWS with a Zerto Cloud Appliance installed on it. This virtual instance must be paired with the protected site.
The VPG definition consists of the following:
• | General: A name to identify the VPG and the priority to assign to the VPG. |
• | Virtual machines: The list of virtual machines being protected as well as the boot order and boot delay to apply to the virtual protection groups during recovery. |
• | Storage: The default storage volume to use for the recovered virtual machine files and for their data volumes. If a cluster is selected for the host, only storage accessible. |
• | Recovery: The networks, subnets, security groups, instance families, and instances types to use for failover/move and failover test procedures and the scripts, if any, that should run at the start or end of a recovery operation. |
• | Retention Status: The properties that govern the VPG retention including the repository where the retention sets are saved. |
• | Summary: The details of the VPG configuration defined in the previous components. |
The Role of the Journal During Protection
After defining a VPG, the protected virtual machine disks are synced with the recovery site. After initial synchronization, every write to a protected virtual machine is copied by Zerto to the recovery site. The write continues to be processed normally on the protected site and the copy is sent asynchronously to the recovery site and written to a journal in a bucket in S3 managed by a Virtual Replication Appliance (VRA). Each protected virtual machine has its own journal.
In addition to the writes, every few seconds all journals are updated with a checkpoint time-stamp. Checkpoints are used to ensure write order fidelity and crash-consistency. A recovery can be done to the last checkpoint or to a user-selected, crash-consistent checkpoint. This enables recovering the virtual machines, either to the last crash-consistent point-in-time or, for example, when the virtual machine is attacked by a virus, to a point-in-time before the virus attack.
Data and checkpoints are written to the journal until the specified journal history size is reached, which is the optimum situation. At this point, as new writes and checkpoints are written to a journal, the older writes are written to the virtual machine recovery virtual disks. When specifying a checkpoint to recover to, the checkpoint must still be in the journal. For example, if the value specified is 24 hours then recovery can be specified to any checkpoint up to 24 hours. After the time specified, the mirror virtual disk volumes maintained by the VRA are updated.
During recovery, the virtual machines at the recovery site are created and the recovery disks for each instance, managed by the VRA, are attached to the recovered virtual machines. Information in the journal is promoted to the virtual instances to bring them up to the date and time of the selected checkpoint.
Each protected virtual machine has its own dedicated journal.
What Happens After the VPG is Defined
After defining a VPG, the VPG is created. The VRA in AWS is updated with information about the VPG and its protected virtual machines. Until a recovery operation is performed, all data managed by the VRA is stored in an S3 bucket.
The synchronization process can take some time, depending on the size of the virtual machines, the amount of data in its volumes, and the bandwidth between the sites. During this synchronization, you cannot perform any replication task, such as adding a checkpoint.
For synchronization to work, the protected virtual machines must be powered on. The VRA requires an active IO stack to access the virtual machine data to be synchronized across the sites. If the virtual machine is not powered on, there is no IO stack to use to access the protected data to replicate to the target recovery disks, and an alert is issued.
Once synchronized, the VRA in AWS includes a complete copy of every virtual machine in the VPG. After synchronization the virtual machines in the VPG are fully protected, meeting their SLA, and the delta changes to these virtual machines are sent to the recovery site.
Recovery
After initializing the VPG, all writes to the protected virtual machines are sent by the VRA on the relevant host for each virtual machine on the protected site to the VRA on AWS. The information is saved in the journal for the virtual machine with a timestamp, ensuring write-fidelity. Every few seconds the Zerto Virtual Manager writes a checkpoint to every journal on AWS for every virtual machine in the VPG, ensuring crash-consistency.
The data remains in the journal, in an S3 bucket, for the time defined by the journal history configuration, after which it is moved to the relevant mirror disks, also in the S3 bucket, for each virtual machine. Both the journal and the mirror disks are managed by the VRA.
When recovering, either a failover or move, or testing failover or cloning protected virtual machines in the recovery site, you specify the checkpoint at which you want the recovered virtual machines to be recovered. The mirror disks and journal are used to recover the virtual machines to this point-in-time. The recovered virtual machines are created as new instances in EC2.
File and Folder Recovery
After initializing the VPG, instead of recovering a virtual machine, you can recover specific files and folders in the protected virtual machines from a checkpoint.