For the final chapter of our Zerto Replication install series, we will create a Virtual Protection Group (VPG) and start replicating virtual machines. As a recap, we have already installed the ZVM, paired the protected and recovery sites, and deployed VRAs.
What is a Virtual Protection Group?
Virtual Protection Groups essentially enable virtual machines to be affinity grouped. Meaning you can define a group of vms that must be recovered together. For example, an application that is comprised of a web server, database server, and app server could be grouped together, so they are recovered jointly. VPGs can also be grouped into tiers based on target RPOs. Virtual machines requiring different RPO levels can be grouped so that all critical machines recover together and less critical tiers can be brought up subsequently. It is also entirely possible to include just one virtual machine in a protection group. This provides flexibility in the event a single vm needs recovered as opposed to a group of vms.
Yesterday, news broke about vulnerabilities affecting AMD, Intel, and ARM CPU’s. These vulnerabilities, termed Meltdown and Spectre, have the potential to expose information that the machine(s) process. Check out this post for an in-depth look. At this point, it appears that VMware is not vulnerable to Meltdown; however, they have released patches for Spectre. It has been speculated that patching the flaws will cause performance hits. To what degree varies by reporting source. As always, test patches before deployment and contact support if you have any questions.
As per the initial VMware Security Advisory, the specified patches should be applied for remediation. Remember, these patches remediate known issues. Definitely, watch for additional patches as exploits may continue to surface. If you are needing to patch your ESXi host per the advisory, you can do so through VMware Update Manager (VUM).
Update – VMware has removed patches to address Hypervisor-Assisted Guest Mitigation (VMSA-2018-04).
As a recap, patches have been released to address Hypervisor-Specific Remediation (VMSA-2018-02) and
Hypervisor-Assisted Guest Remediation (VMSA-2018-04). For more detail, check out this VMware KB detailing these responses.
VMware Patch Numbers for ESXi Versions (VMSA-2018-02):
- ESXi 6.5 – ESXi650-201712101-SG
- ESXi 6.0 – ESXi600-201711101-SG
- ESXi 5.5 – ESXi550-201709101-SG
- This 5.5 patch only addresses CVE-2017-5715, not CVE-2017-5753
VMware Patch Numbers for ESXi Versions (VMSA-2018-04)
ESXi 6.5 – ESXi650-201801401-BG, ESXi650-201801402-BG
ESXi 6.0 – ESXi600-201801401-BG, ESXi600-201801402-BG
ESXi 5.5 – ESXi550-201801401-BG
For this example, we will be patching VMware ESXi 6.5 with patch ESXi650-201712101-SG. Additional patches can be applied in the same manner. Read the release notes or security advisories before patching as other components may need to be patched first.
For the second part of our Zerto Replication install series, we are going install the Virtual Replication Appliances (VRAs) as well as pair our protected site to a recovery site.
First, let’s look at the Virtual Replication Appliance(s). VRAs are lightweight, Linux-based virtual machines that handle replication between sites. These VRAs are installed on each host that houses either a protected or a recovery virtual machine. As part of replication, the VRAs compress the data before traversing between sites.
VRA Requirements (Zerto 5.x – VMware Environment)
- 5 GB datastore space
- A minimum of 1 GB memory
- VMware ESXi 4.0U1 or higher
Install Zerto Virtual Replication Appliances (VRA)
From the ZVM Dashboard, navigate to the Setup tab.
One of my favorite aspects regarding Zerto Replication is the ease of deployment. In this series, we will run through the installation and configuration of Zerto 5.5 for VMware environments. The series will consist of three parts to get Zerto Replication up and running.
- Zerto Virtual Manager (ZVM) Install
- Virtual Replication Appliance (VRA) Deployment/Site Pairing
- Virtual Protection Group (VPG) Setup for Virtual Machines
The focus of today’s post is the Zerto Virtual Manager (ZVM) installation. If you are unfamiliar with the ZVM, it is the centerpiece of the Zerto solution, which oversees replication. It taps into vCenter server to monitor your environment and update Zerto components. Furthermore, the ZVM runs as a Windows service and serves up a user interface to manage Zerto activities. Typically, the ZVM is installed at both the recovery and protected sites.
Before we start, let’s look at some pertinent requirements.
Today, Zerto released a field notice for customers running Zerto 5.0 or 5.5 in VMware vSphere environments. The issue pertains to duplicate MoRef entries residing in the Zerto Virtual Manager database. These duplicate entries are being created by the ZVM or by the installer during an installation. Alone the presence of duplicate MoRefs doesn’t cause the issue. However, certain tasks or changes on the duplicated object can cause disruptions to synchronization or replication. This could force VPGs into an error state; consequently, rendering them unrecoverable. Zerto states that some environments may contain duplicated MoRefs, but not be impacted. Regardless, they recommend users on ZVR version 5.0 or 5.5 to upgrade to version 5.5U2P2. P2 will identify and delete duplicate entries. If you are unable to upgrade, Zerto Support can aid in identification and further mitigation of the issue.
ZVR Affected Versions: 5.0, 5.0 U1, 5.0 U2, 5.0 U3, 5.0 U4, 5.5, 5.5 U1, 5.5 U2
What is a MoRef?
Managed Object References are unique identifiers given to all objects in a vSphere environment for identification and tracking purposes. MoRef’s are designated by the object type followed by an identification number. For example, vm-110 or host-95.