Menu
Field CTO - Hybrid Data Center
With the first post in the Zerto series, I ran through the history of Zerto and some features that Zerto Virtual Replication provides. Continuing the series on Zerto with the second post, we’ll cover the typical Zerto Virtual Replication deployment requirements and compare a Windows-based deployment versus the newer Linux-based deployment. While this post will focus more specifically on VMware deployments, the terminology and concepts will mostly hold true across the different environments Zerto may be deployed within. At the core, the functionality of the Zerto product is not that much different between the Windows-based and Linux-based installations, however the direction for Zerto to move to the Linux-based appliance allowed them to accelerate features while also enhancing security within the product.
Let’s take a quick look at the topology of a Zerto deployment. With Zerto, the typical deployment will have a mirrored configuration on each of the sites, which will include a Zerto Virtual Manager (“ZVM”) server, as well as one or more Virtual Replication Appliances (“VRA”). While there is only a single ZVM per site, there will be potentially multiple VRA’s per site based on the number of Hosts that Zerto will be protecting virtual machines from.
For the VRA’s, they are deployed and pinned directly to the host they are installed on, which allows Zerto to enable replication at a Per-VM level, and pick up all changes to that VM within the I/O path on that host.
While the ZVM role was historically Windows-based and the VRA’s Linux-based, starting with the release of 9.5 a Linux-based ZVM appliance was made available. While the early releases of the Linux-based ZVM will sometimes be tricky to deploy, it got much better through 9.7 as it related to feature parity with the Windows-based ZVM. Finally, with the release of v10, Zerto released only a Linux-based ZVM appliance, and the Windows-based ZVM installation was fully removed. This has also allowed Zerto to move from a monolithic application to a container-based application, giving them flexibility for development and scalability.
I’ve posted in the past about the Linux-based ZVM, but let’s take a look at why the transition from a Windows-based installer for the Zerto Virtual Manager (ZVM) to a Linux-based appliance brings several key benefits that address both operational efficiency and performance improvements. Here’s a quick breakdown of the advantages of moving to the Linux-based ZVM:
I want to say that the Windows-based ZVM was stable, and I rarely ran across many issues with it through deployments in the last 10 years. However, as we’re seeing more and more management functions moving to an appliance-based model, continuing to manage Windows and then the Zerto software updates, as well as a heightened security focus and simplifying the architecture—the move to Linux for the ZVM role made sense.
In this next section, we’ll do a quick comparison of the Windows and Linux-based ZVM deployments, as well as the differences between them.
Let’s quickly review the installation steps for the deployment of Zerto prior to version 10.
Let’s briefly explore the installation steps for the deployment of Zerto leveraging the appliance-based deployment. While versions 9.5 and 9.7 did include the appliance-based deployment, it was a much more manual deployment than v10.
With the Windows-based ZVM, making configuration changes to the Zerto service was done using the Zerto configuration tool. With the Linux-based appliance, to eliminate the need to directly connect to the ZVM (through SSH), Zerto created a management page for the ZVM functions, very similar to the management page for vCenter.
Authentication for Zerto with the Windows-based ZVM was done through vCenter rather than using any direct authentication by Zerto. This allowed Zerto to natively integrate with any authentication providers that vCenter was using, whether it be local accounts within the vsphere.local SSO domain or an external provider, such as LDAP or AD Authentication that was currently in use. While this was easy, it did not allow for easy additional security functions, such as MFA or identity sources not directly supported by vCenter. It’s also required that vCenter was available to be able to log into the Zerto GUI.
With the appliance deployment, Zerto removed the reliance on tying into vCenter for authentication and instead moved to a centralized authentication method using the open-source identity and access management solution, Keycloak. Keycloak now provides the authentication to Zerto, allowing organizations to create locally significant roles and users, configuring LDAP and/or Kerberos authentication and leveraging the built-in Keycloak MFA provider to add additional layers of security.
Finally, let’s talk about the process of upgrading Zerto. With the legacy Windows-based deployment, administrators would patch Windows through normal mechanisms (Windows Update, WSUS, Admin Center, etc.), and then download and install the Zerto software separately. With this version, while there was a notice in the Zerto console about version upgrades, there was no automated upgraded process for the ZVM role, and thus required manual intervention. This did not have any sort of online requirement, so it was very easy to work within a dark site if required.
With the appliance-based deployment, we now have a fully automated upgrade process from the Zerto Management Console. This upgrade process not only handles the updates for the Zerto software, but also handles the Debian OS updates to keep the appliance secure and up to date. Due to the nature of the container deployment, this also provides a rollback function, which is really helpful. I still recommend taking a snapshot before the upgrade though!
With initial versions of the Linux appliance, working in a dark site or offline mode was not possible. Starting with version 10 update 2, Zerto now allows for the ability to work within a dark site and download the bits ahead of time, and manually upload.
In the second part of this series, we briefly looked at the deployment and some nuances between the Windows and Linux-based deployments. While the result is the same awesome Virtual Replication for Disaster Recovery, the latest releases and the Linux-based appliance deployments provide a much simpler and arguably more secure topology.
In the next part of the series, I’ll describe the process of migrating an existing Windows-based deployment to a Linux-based deployment using the Zerto Migration tool.
If you have questions about Virtual Replication for Disaster Recovery, or Zerto Windows and Linux-based deployments, contact our team at info@eGroup-us.com or complete the form below.
Contact our team today to get help with any of the updates mentioned above!
