Mapping Okta Groups to Keycloak (SAML 2.0)

March 12, 2024March 12, 2024 Gene Torres 1 Comment

So you’ve followed the guide to integrate Keycloak with Okta via SAML 2.0. The next logical step to simplify that configuration would be to automatically map user groups in Okta (if they should have access to Zerto) to corresponding groups in Keycloak to reduce management even more. Guess what? It’s actually pretty straightforward, and the nice part is I have “RH” to thank for taking what I’ve previously done with user mapping and bringing it to groups; so huge shoutout to him for the assist!

Let’s face it, no one wants to manage application access via users, especially at scale. And no one wants to have another step to take once a user logs into something for the first time. By mapping an Okta group to an existing group in Keycloak this will take any additional administrative work to wait for a user to login, only to get denied access, just so the admin can add them to the group to try again.

Properly managing access to applications shouldn’t be a burden. It should be as seamless and without admin overhead as possible. For example, if I’m defined as a Zerto Admin in Okta, when I first login to Zerto, I want to be let right in with the proper access; not have to bug another admin to add me to a group. What if my group membership needs change? It should be able to be done in Okta and then reflected in Zerto on my next login, so we want to also account for group membership updates without any additional work. The following procedure will be the icing on the cake and make your Keycloak/Okta integration pretty much hands-off once you’ve set it up; and you can go back to doing great things again.

Don’t Jump Ahead!

Before you follow this guide, please make sure you’ve already set up the integration (steps are in my previous blog titled: Zerto 10 Keycloak and Okta SAMLv2.0 Integration. You may have also got to the end of my previous guide and followed the link to this one; so if that’s how you ended up here, then you’re right on track!

Create the Keycloak Groups for Zerto Roles

When Zerto is deployed, there are some out-of-the-box pre-configured roles with the necessary permissions attached to them, so that’ll save you some time. You can view what those roles are and what privileges have been assigned to them in this Zerto document: ZVM Appliance Roles and Permissions

For the most part, these are generally all you need, but just know, that if you want to create any custom roles, you can, and Keycloak already contains the privileges within – so you can use what you need if you have to.

Before you start: If you don’t know how to manage Zerto Role-based Access Controls, please see my previously written blog titled “Zerto 10 Role-based Access Controls” and scroll down to the section titled “Managing Zerto Roles by Using Groups” to create the groups in Keycloak if you haven’t already done that.

Configure the Okta to Keycloak Group Mapping

The first thing you want to do here is make sure you’ve already created the groups you need in Okta and added users to that/those group(s). Once you’ve done that, go to the Zerto SAML application you created for the SAML 2.0 provider in Keycloak.

Create the Group Attribute Statement in Okta

When you get to the app:

Click on the General tab, then scroll down to the SAML Settings area, and click Edit.
Under General settings, click Next.
Scroll down to Group Attribute Statements and for the name, type groups.
For the Filter, select starts with and enter the prefix for all groups related to Zerto. In my example, I have two groups; one for admins called ZertoAdmins, and one for viewers (read-only) named ZertoReadOnly.
Click Next, then on the next page, click Finish
Now switch over to Keycloak.

Create the Group Mapper in Keycloak

Log into Keycloak, switch to the Zerto realm.
Click on Identity Providers, then click on your Okta SAML provider.
Click on the Mappers tab at the top.
Click Add Mapper.
Provide a name to identify the mapper (i.e. ZertoAdmins, or ZertoReadOnly)
Select Force as the sync mode override. This will force an update to group membership if one was made in Okta (i.e. moving a user from the ZertoReadOnly group into the ZertoAdmins group).
Select Advanced Attribute to Group as the Mapper Type
Type in the key for the attribute (this is the “name” in the group attribute statement from Okta). This is typically “groups” without the quotes.
For the Value, input the actual name of the group in Okta (i.e. ZertoReadOnly).
Click Select group
Find the group in the list, click the arrow to the right, the click the Select button.
Click Save.
Now try logging in to Zerto.

Conclusion and Troubleshooting

After you’ve completed this step to map groups from Okta into Keycloak automatically, Keycloak will look for group memberships in the claims that come through with the login request. If Keycloak sees a match based on the mappers you have set up, then the user will automatically be assigned to the right group/role in Zerto and be allowed access.

Troubleshooting Note: Make sure when you created the group in Keycloak that you have added the necessary role to the group, because if the group isn't assigned to any Zerto role, then on login that user will get kicked back to the Okta login page.
rcFederation Tracer: If you’re setting this up for the first time and want to see what claims are coming through on your requests (again, thanks for the recommendation on this utility, RH!), take a look at SAML, WS-federation and OAuth tracer (installs as a browser add-in) to be able to see what is in your web requests as the communication between Keycloak and Okta take place.

Here’s an example of seeing the attributes Okta passes over to Keycloak on authentication:

Well, I hope this was helpful, and as always, if you have questions or comments, I’d love to hear your feedback. Please also share this with anyone who may find it useful.

Share This:

Zerto 10 Keycloak and Okta SAMLv2.0 Integration

February 29, 2024March 12, 2024 Gene Torres 1 Comment

Did you know that when the Linux-based Zerto Virtual Manager Appliance (ZVMA) was released, the way Zerto handled permissions has completely changed, giving you more control over who has access and what type of access they have?

In the old days (like a year ago, and to some still currently on the Windows-based ZVM), Zerto permissions were really an extension of vSphere permissions. When Zerto got installed on a Windows VM, part of that installation process created roles and permissions within vCenter that you could use to grant users access to certain Zerto functionality, if not all functionality. This was because Zerto mainly relied on whether or not you or any user trying to get into Zerto had an account with access to vCenter. For those who knew about it and used it, it worked, however, it left much more to be desired, like true RBAC and eliminating the possibility for any old vSphere Admin to have complete control over Zerto.

Today, as of the Zerto 9.7 Linux appliance and into 10, managing access in to Zerto has been decoupled from vSphere permissions and brought into Zerto through Keycloak, not to only provide RBAC, but to also provide an additional layer of security and more integration options for access management. Now the only connection into vSphere is a service account, and all user access into Zerto is based on having access granted through Keycloak.

Identity Provider Options

When you take a look at what type of integrations are available with Keycloak, it can be a little overwhelming, however, as long as it has what you need, you likely won’t care for what else is there, right? There are currently 18 built-in options for identity providers and user federation options (pictured below). I’d say there are likely many more when you consider that anything else that can be connected to with OpenID Connect, SAML v2.0, Kerberos, and LDAP/s are also available.

Keycloak User federation options screenshot

With a plethora of options available, the two most common ones I hear as customer needs today are Okta and Active Directory, and I’ve already published a YouTube video for Active Directory integration via LDAPs, so this update is going to be specific on how to set up Okta integration via SAML v2.0.

The goal here in this post is to list out the order of operations and the steps required to perform so that when you log in to Zerto, instead of pre-creating an account in Keycloak, you’re going to rely on an existing account in Okta that has access to Zerto, with the added benefit of push-button MFA.

Configuration

Procedure Overview

So I’ve tested this with both OpenID Connect, and SAML v2.0 Identity providers, and I’ve come to the conclusion (and verified with some customers I’ve encountered who were also Okta customers) that configuring this integration via SAML v2.0 is much simpler, and doesn’t require banging head on keyboard. Having no prior experience setting this identity provider up took less than an hour from start to finish, so it was extremely simple.

So if you want to do this in one sitting, there are five main steps in the procedure that I counted.. okay, 6 if you want to include deploying the ZVMA and getting it on the network, which I won’t cover here:

Note: Keycloak and Okta have the tendency to automatically log your session out if you leave them idle for too long, so be sure to keep those sessions active while you’re jumping between the two.

Deploy, configure, and license the ZVMA
Configure the SAML 2.0 provider in Keycloak
Create the Okta Application and download the signing certificate
Configure mappers to map user attributes from Okta into Keycloak
Upload and import the Okta signing certificate to the ZVMA and Keycloak trust store
Logging in to Zerto

One thing to note is that when you’re performing steps 2,3, and 4 above, you may want to have both Keycloak and Okta open at the same time, because there are some values that they will be trading back and forth. Having both open allows you to complete them in parallel and make for a smoother experience.

I will also include at the end of this write up a “next steps” optional but recommended step that comes after logging in for the first time, so be sure to read all the way through, because it will be about RBAC assignment to the Okta user that has been logged in.

If you have any questions, please ask them in the comments.

Configure the SAML v2.0 Provider

Log into the Keycloak administrator interface on the target ZVMA via https://[FQDNorIP]/auth (replace [FQDNorIP] with the FQDN or IP address of your ZVMA).
After you’re logged in, you will see a drop-down list at the top left that defaults to “master.” Click there and select zerto from the list to change into the Zerto realm of settings.
In the left navigation bar, under configure, select Identity providers.
From the selection screen, choose SAML v2.0
Enter the information as shown in the screenshot below, and note that you cannot change the Redirect URI, however, you will need this when configuring the Okta app, so copy it and have it ready to go when you get to the Okta configuration portion below.
In the SAML Settings area, disable the setting labeled “Use entity descriptor.” Once disabled, more fields will appear below in the SAML settings.
Before filling anything out further, open another browser window and log in to the Okta admin site to create an app for Zerto, because now you’re going to need to gather/enter URIs in both Keycloak and Okta.

Create and Configure the Okta Application and Download the Signing Certificate

In the Okta admin, expand Applications in the left navigation bar, and select Applications from the nested options.
Click on Create App Integration
For the name, enter Zerto SAML, then click Next.
Under General, where it asks for the Single sign-on URL, enter the Redirect URI that was automatically created in Keycloak. Refer to step 5 above where you started setting up the SAML v2.0 provider in Keycloak.
Enable the ckeckbox labeled “Use this for Recipient URL and Destination URL.”
Leave everything else as default, then scroll down and click Next.
The next page is for feedback, so select the following options and click Finish. You will be returned to the applications page.
On the applications page, click the gear icon to the right of the Zerto SAML app you just created, and select Assign to Users.
For each user that requires access to Zerto, click the Assign link to the right of their name to add them to the app. Without assigning them, they won’t be able to login to Zerto using their Okta account. Optionally, you can create a group in Okta and assign your users to that instead of individually here.
When you click on Assign, another box will pop up with the user name in the box. Click Assign and go back to be returned to the main list of users. If there are more users to add, repeat the previous step, otherwise, you can close the window with the list of users.
Back on the applications page, if you click on the app, you will see your added users/groups in the list.
Now, download the signing certificate. Click on the Sign On tab at the top.
Scroll down to the SAML Signing Certificates section and find the active certificate. At the right of that active certificate, select Actions > Download Certificate. This is what you will be uploading to the ZVMA and importing to Keycloak, so keep track of it. Save the certificate as a .cert file (which should be what it defaults to).
Now you need to get a couple of URLs from Okta to use in Keycloak. Click on the Sign On tab for the Okta application.
Scroll down to the SAML 2.0 section. Beneath the Metadata details header, click on the link that says more details.
Copy the Sign on URL and the Sign Out URL
Now return to Keycloak to continue the SAML v2.0 provider configuration.

Return to Keycloak

In the SAML Settings section of the SAML v2.0 provider you’re configuring in Keycloak, find the Single Sign On Service URL field and enter the Sign on URL that you copied from Okta in the previous step.
For the Single Logout Service URL, past the Sign Out URL you copied from Okta in the previous step. When done, it will look similar to the image below:
Leave all other fields as default. Click Save.
Scroll down to the Advanced Settings and verify the following settings:
- First login flow: first broker login
- Post login flow: none
- Sync mode: Import
Click Save.

Configure Mappers for Attribute Import From Okta to Keycloak on Login

Mappers will be used between Okta and Keycloak to easily import user attributes on login to Zerto. If you do not provide mappers, then on first login, the user will be prompted to enter their e-mail address, first name, and last name. The idea with configuring mappers is to bring those attributes over from Okta to populate the fields in Keycloak for the user automatically, so the login is much more seamless.

First we will configure the attribute mapping in Okta, followed by the mapper configurations in Keycloak.

Okta Mapper/Attribute Configuration

Log onto the Okta administration page.
Go to the SAML Application that you previously configured in Okta (probably named Zerto SAML).
On the General tab of the application, scroll down to the section labeled SAML Settings and click Edit.
Click Next.
On the Configure SAML step, scroll down to the Attribute Statements section and add the following attributes. These will map Okta user attributes to Keycloak user attributes for simpler login as mentioned above.
Scroll down and click Next.
Click Finish.

Keycloak Mapper Configuration

Configure the Mappers for users’ e-mail, first name, and last name in Keycloak to be brought over to their Keycloak account automatically on login.

In Keycloak, click on the Okta SAML provider you configured.
Click the Mappers tab at the top, then click Add Mapper.
Add the mapper for the user’s first name. Complete the fields as shown in the image below, then click Save.
Go back to the Mappers tab, and add another mapper for the user’s last name this time (see image below for values to use). Click Save.
Go back to the Mappers tab, and add another mapper for the user’s e-mail address this time (see image for values to use). Click Save.

Upload and Import the Okta Signing Certificate to the ZVMA and Keycloak Trust Store

Update: I decided to include the certificate import steps here, but left the link to the original Zerto documentation as others have been asking for it and felt this would be more “complete” with it inline.

Upload the Okta certificate to the ZVMA. Put the file in the following location: /var/data/zerto/zkeycloak/certs/
Use PuTTy or other SSH client to log onto the ZVMA. If you are doing this via the vSphere console, select 0 from the appliance manager menu to exit to the shell.
Run the following command to add the certificate to Keycloak’s trust store:

kubectl exec -i zkeycloak-0 -- /usr/bin/keytool -import -alias oktacert -file /opt/keycloak/conf/certs/[oktacertfilename].cert -keystore /opt/keycloak/conf/certs/truststore.jks
You will be prompted to enter the keystore password. Use the password below. If for some reason you are asked to change that password, use the same one, don’t change it.

truststorepass
When prompted to trust the certificate type yes and press enter.
Finally, fun the following command to kill the current pod and run the updated one with the certificate in place

kubectl delete pod zkeycloak-0
You can now end your SSH session and start logging in to Zerto via the Okta SAML login method.

Original Zerto documentation for importing certificates into Keycloak’s truststore:

https://help.zerto.com/bundle/Linux.ZVM.HTML.10.0_U3/page/Importing_the_AD_FS_Certificate_to_Keycloak.htm

Next Steps

After you’ve completed all the steps previous to this section, you can start logging in to Zerto. One thing to note is that when you login via your Okta credentials, the user loggig in (if given access to the Zerto SAML app via Okta) will be logged into Zerto, and if you look in the Users section of the Keycloak Zerto realm, there will also be an account created in there for the user.

By default, the user being given access through this method will have admin rights to Zerto. If you would like to minimize permissions or access into Zerto with, for example, read-only access, you can visit the following URL where I have previously wrote about how the Role-based Access Controls work within Zerto. Optionally, you can import group attributes from Okta the same way you mapped user attributes, however, that is out of scope here.

Zerto 10 Role-based Access Controls (RBAC) via Keycloak: https://www.genetorres.me/2023/10/13/zerto-10-role-based-access-controls-via-keycloak/

That’s all I’ve got for this time. I hope you’ve found this useful and if so, please share it with others who you feel will find it useful as well. For any questions, please leave a comment!

Update: Mapping Okta Groups to Keycloak Groups

After you’ve gone through this, you’re probably wondering how you can also automatically map Okta groups into Keycloak for Zerto access. Please see my follow-up blog post on Mapping Okta Groups to Keycloak (SAML 2.0) to continue from here and get your groups mapped over automatically. By doing this, you will avoid having to add users to Keycloak groups after their first login.

Share This:

Configuring AWS for Zerto Virtual Replication

March 30, 2018April 4, 2018 Gene Torres Leave a comment

By now, it’s no secret that the IT Resilience Platform that Zerto has come to be known as offers complete flexibility when it comes to multi-cloud agility. This agility allows businesses to accelerate their digital transformation and truly take advantage of what the public cloud platform offers – ensuring even more freedom to choose your cloud and to be able to replicate workloads to, from, and even between public clouds. As there have been great improvements in Zerto’s any-to-any story, one in particular I’d like to focus on in this article is AWS (Amazon Web Services).

Starting with Zerto Virtual Replication 6.0, customers now have:

Orchestration allowing not only targeting AWS for DR or for workload migration, but now the ability to come back out of AWS to on-premises datacenters, or even the ability to replicate between public cloud providers (AWS, Microsoft Azure, IBM Public Cloud) and Cloud Service Providers (CSPs).
Zerto Analytics visibility between all sites, including public cloud, now with network statistics and 30-day history.

Now, while these improvements are exciting and offer even more cloud agility to customers, one can’t help but realize that before you can actually start taking advantage of ZVR 6.0 to achieve a hybrid cloud architecture or DR in the cloud (specifically AWS), there are some pre-requisites to complete before doing so. That said, meeting those requirements may not seem as intuitive as you’d hope at first glance.

While having a cloud use-case is usually the first step, and is determined by business requirements – the challenge lies within understanding what exactly needs to be configured in AWS for ZVR functionality, and how to accomplish it. If you take a look below, the workflow itself is a multi-step process that may not be very easy to perform, until now.

ZVR AWS Workflow — Figure 1: Configuring AWS for ZVR – Workflow

In my usual fashion of wanting to know exactly how things are done and then sharing it with everyone else, I’ve written a how-to document for configuring AWS for Zerto Virtual Replication, which I am happy to say has been turned into an official Zerto whitepaper and is now available for download!

>> Whitepaper – Configuring AWS for Zerto Virtual Replication <<

As usual, feedback, is welcomed with open arms. If you find this useful, please share and be social!

Share This:

Zerto Virtual Manager Outage, Replication, and Self-Healing

February 14, 2018February 15, 2018 Gene Torres 1 Comment

I’ve decided to explore what happens when a ZVM (Zerto Virtual Manager) in either the protected site or the recovery site is down for a period of time, and what happens when it is back in service, and most importantly, how an outage of either ZVM affects replication, journal history, and the ability to recover a workload.

Before getting in to it, I have to admit that I was happy to see how resilient the platform is through this test, and how the ability to self-heal is a built in “feature” that rarely gets talked about.

Questions:

Does ZVR still replicate when a ZVM goes down?
How does a ZVM being down affect checkpoint creation?
What can be recovered while the ZVM is down?
What happens when the ZVM is returned to service?
What happens if the ZVM is down longer than the configured Journal History setting?

Acronym Decoder & Explanations

ZVM	Zerto Virtual Manager
ZVR	Zerto Virtual Replication
VRA	Virtual Replication Appliance
VPG	Virtual Protection Group
RPO	Recovery Point Objective
RTO	Recovery Time Objective
BCDR	Business Continuity/Disaster Recovery
CSP	Cloud Service Provider
FOT	Failover Test
FOL	Failover Live

Does ZVR still replicate when a ZVM goes down?

The quick answer is yes. Once a VPG is created, the VRAs handle all replication. The ZVM takes care of inserting and tracking checkpoints in the journal, as well as automation and orchestration of Virtual Protection Groups (VPGs), whether it be for DR, workload mobility, or cloud adoption.

In the protected site, I took the ZVM down for over an hour via power-off to simulate a failure. Prior to that, I made note of the last checkpoint created. As the ZVM went down, within a few seconds, the protected site dashboard reported RPO as 0 (zero), VPG health went red, and I received an alert stating “The Zerto Virtual Manager is not connected to site Prod_Site…”

The Zerto Virtual Manager is not connected to site Prod_Site

Great, so the protected site ZVM is down now and the recovery site ZVM noticed. The next step for me was to verify that despite the ZVM being down, the VRA continued to replicate my workload. To prove this, I opened the file server and copied the fonts folder (C:\Windows\Fonts) to C:\Temp (total size of data ~500MB).

As the copy completed, I then opened the performance tab of the sending VRA and went straight to see if the network transmit rate went up, indicating data being sent:

VRA Performance in vSphere, showing data being transmitted to remote VRA in protected site.

Following that, I opened the performance monitor on the receiving VRA and looked at two stats: Data receive rate, and Disk write rate, both indicating activity at the same timeframe as the sending VRA stats above:

Data receive rate (Network) on receiving/recovery VRA Disk write rate on receiving/recovery VRA

As you can see, despite the ZVM being down, replication continues, with caveats though, that you need to be aware of:

No new checkpoints are being created in the journal
Existing checkpoints up to the last one created are all still recoverable, meaning you can still recover VMs (VPGs), Sites, or files.

Even if replication is still taking place, you will only be able to recover to the latest (last recorded checkpoint) before the ZVM went down. When the ZVM returns, checkpoints are once again created, however, you will not see checkpoints created for the entire time that ZVM was unavailable. In my testing, the same was true for if the recovery site ZVM went down while the protected site ZVM was still up.

How does the ZVM being down affect checkpoint creation?

If I take a look at the Journal history for the target workload (file server), I can see that since the ZVM went away, no new checkpoints have been created. So, while replication continues on, no new checkpoints are tracked due to the ZVM being down, since one of it’s jobs is to track checkpoints.

Last checkpoint created over 30 minutes ago, right before the ZVM was powered off.

What can be recovered while the ZVM is down?

Despite no new checkpoints being created – FOT or FOL – VPG Clone, Move, and File Restore services are still available for the existing journal checkpoints. Given this was something I’ve never tested before, this was really impressive.

One thing to keep in mind though is that this will all depend on how long your Journal history is configured for, and how long that ZVM is down. I provide more information about this specific topic further down in this article.

What happens when the ZVM is returned to service?

So now that I’ve shown what is going on when the ZVM is down, let’s see what happens when it is back in service. To do this, I just need to power it back up, and allow the services to start, then see what is reported in the ZVM UI on either site.

As soon as all services were back up on the protected site ZVM, the recovery site ZVM alerted that a Synchronization with site Prod_Site was initiated:

Synchronizing with site Prod_Site

Recovery site ZVM Dashboard during site synchronization.

The next step here is to see what our checkpoint history looks like. Taking a look at the image below, we can see when the ZVM went down, and that there is a noticeable gap in checkpoints, however, as soon as the ZVM was back in service, checkpoint creation resumed, with only the time during the outage being unavailable.

Checkpoints resume

What happens if the ZVM is down longer than the configured Journal History setting?

In my lab, for the above testing, I set the VPG history to 1 hour. That said, if you take a look at the last screen shot, older checkpoints are still available (showing 405 checkpoints). When I first tried to run a failover test after this experiment, I was presented with checkpoints that go beyond an hour. When I selected the oldest checkpoint in the list, a failover test would not start, even if the “Next” button in the FOT wizard did not gray out. What this has lead me to believe is that it may take a minute or two for the journal to be cleaned up.

Because I was not able to move forward with a failover test (FOT), I went back in to select another checkpoint, and this time, the older checkpoints were gone (from over an hour ago). Selecting the oldest checkpoint at this time, allowed me to run a successful FOT because it was within range of the journal history setting. Lesson learned here – note to self: give Zerto a minute to figure things out, you just disconnected the brain from the spine!

Updated Checkpoints within Journal History Setting

Running a failover test to validate successful usage of checkpoints after ZVM outage:

File Server FOT in progress, validating fonts folder made it over to recovery site.

And… a recovery report to prove it:

Recovery Report - Successful FOT

Summary and Next Steps

So in summary, Zerto is self-healing and can recover from a ZVM being down for a period of time. That said, there are some things to watch out for, which include known what your configured journal setting is, and how a ZVM being down longer than the configured history setting affects your ability to recover.

You can still recover, however, you will start losing older checkpoints as time goes on while the ZVM is down. This is because of the first-in-first-out (FIFO) nature of how the journal works. You will still have the replica disks and journal checkpoints committing to it as time goes on, so losing history doesn’t mean you’re lost, you will just end up breaching your SLA for history, which will re-build over time as soon as the ZVM is back up.

As a best practice, it is recommended you have a ZVM in each of your protected sites, and in each of your recovery sites for full resilience. Because after all, if you lose one of the ZVMs, you will need at least either the protected or recovery site ZVM available to perform a recovery. The case is different if you have a single ZVM. If you must have a single ZVM, put it into the recovery site, and not on the protected site, because chances are, your protected site is what you’re accounting for going down in any planned or unplanned event. It makes most sense to have the single ZVM in the recovery site.

In the next article, I’ll be exploring this very example of a single ZVM and how that going down affects your resiliency. I’ll also be testing some ways to potentially protect that single ZVM in the event it is lost.

Thanks for reading! Please comment and share, because I’d like to hear your thoughts, and am also interested in hearing how other solutions handle similar outages.

Share This:

Zerto Automation with PowerShell and REST APIs

October 26, 2017October 26, 2017 Gene Torres 2 Comments

Zerto is simple to install and simple to use, but it gets better with automation! While performing tasks within the UI can quickly become second nature, you can quickly find yourself spending a lot of time repeating the same tasks over and over again. I get it, repetition builds memory, but it gets old. As your environment grows, so does the amount of time it takes to do things manually. Why do things manually when there are better ways to spend your time?

Zerto provides great documentation for automation via PowerShell and REST APIs, along with Zerto Cmdlets that you can download and install to add-on to PowerShell to be able to do more from the CLI. One of my favorite things is that the team has provided functional sample scripts that are pretty much ready to go; so you don’t have to develop them for common tasks, including:

Querying and Reporting
Automating Deployment
Automating VM Protection (including vRealize Orchestrator)
Bulk Edits to VPGs or even NIC settings, including Re-IP and PortGroup changes
Offsite Cloning

For automated failover testing, Zerto includes an Orchestrator for vSphere, which I will cover in a separate set of posts.

To get started with PowerShell and RESTful APIs, head over to the Technical Documentation section of My Zerto and download the Zerto PowerShell Cmdlets (requires MyZerto Login) and the following guides to get started, and stay tuned for future posts where I try these scripts out and offer a little insight to how to run them, and also learn how I’ve used them!

Rest APIs Online Help – Zerto Virtual Replication
- The REST APIs provide a way to automate many DR related tasks without having to use the Zerto UI.
REST API Reference Guide – Zerto Virtual Replication
- This guide will help you understand how to use the ZVR RESTful APIs.
REST API Reference Guide – Zerto Cloud Manager
- This guide explains how to use the ZCM RESTful APIs.
PowerShell Cmdlets Guide – Zerto Virtual Replication
- Installation and use guide for the ZVR Windows PowerShell cmdlets.
White Paper – Automating Zerto Virtual Replication with PowerShell and REST APIs
- This document includes an overview of how to use ZVR REST APIs with PowerShell to automate your virtual infrastructure. This is the document that also includes several functional scripts that take the hard work out of everyday tasks.

If you’ve automated ZVR using PowerShell or REST APIs, I’d like to hear how you’re using it and how it’s changed your overall BCDR strategy.

I myself am still getting started with automating ZVR, but am really excited to share my experiences, and hopefully, help others along the way! In fact, I’ve already been working with bulk VRA deployment, so check back or follow me on twitter @EugeneJTorres for updates!

Share This:

Zerto: Dual NIC ZVM

November 23, 2016February 2, 2017 Gene Torres 5 Comments

Something I recently ran into with Zerto (and this can happen for anything else) was the dilemma of being able to protect remote sites that (doesn’t happen often) happen to have IP addresses that are identical in both the protected and recovery sites. And no, this wasn’t planned for, it was just discovered during my Zerto deployment in what we’ll call the protected sites.

Luckily, our network team had provisioned two new networks that are isolated, and connected to these protected sites via MPLS. Those two new networks do not have the ability to talk back to our existing enterprise network without firewalls getting involved, and this is by design since we are basically consolidating data centers while absorbing assets and virtual workloads from a recently acquired company.

When I originally installed the ZVM in my site (which we’ll call the recovery site), I had used IP addresses for the ZVM and VRAs that were part of our production network, and not the isolated network set aside for this consolidation. Note: I installed the Zerto infrastructure in the recovery site ahead of time before discussions about the isolated networks was brought up. So, because I needed to get this onto the isolated network in order to be able to replicate data from the protected sites to the recovery site, I set out to re-IP the ZVM, and re-IP the VRAs. Before I could do that, I needed to provide justification for firewall exceptions in order for the ZVM in the recovery site to link to the vCenter, communicate with ESXi hosts for VRA deployment, and also to be able to authenticate the computer, users, service accounts in use on the ZVM. Oh, and I also needed DNS and time services.

The network and security teams asked if they could NAT the traffic, and my answer was “no” because Zerto doesn’t support replication using NAT. That was easy, and now the network team had to create firewall exceptions for the ports I needed.

Well, as expected, they delivered what I needed. To make a long story short, it all worked, and then about 12 hours before we were scheduled to perform our first VPG move, it all stopped working, and no one knew why. At this point, it was getting really close to us pulling the plug on the migration the following day, but I was determined to get this going and prevent another delay in the project.

When looking for answers, I contacted my Zerto SE, reached out on twitter, and also contacted Zerto Support. Well, at the time I was on the phone with support, we couldn’t do anything because communication to the resources I needed was not working. We couldn’t perform a Zerto re-configure to re-connect to the vCenter, and at this point, I had about 24VPGs that were reporting they were in sync (lucky!), but ZVM to ZVM communication wasn’t working, and recovery site ZVM was not able to communicate with vCenter, so I wouldn’t have been able to perform the cutover. So since support couldn’t help me out in that instance, I scoured the Zerto KB looking for an alternate way of configuring this where I could get the best of both worlds, and still be able to stay isolated as needed.

I eventually found this KB article that explained that not only is it supported, but it’s also considered a best practice in CSP or large environments to dual-NIC the ZVM to separate management from replication traffic. I figured, I’m all out of ideas, and the back-and-forth with firewall admins wasn’t getting us anywhere; I might as well give this a go. While the KB article offers the solution, it doesn’t tell you exactly how to do it, outside of adding a second vNIC to the ZVM. There were some steps missing, which I figured out within a few minutes of completing the configuration. Oh, and part of this required me to re-IP the original NIC back to the original IP I used, which was on our production network. Doing this re-opened the lines of communication to vCenter, ESXi hosts, AD, DNS, SMTP, etc, etc… Now I had to focus on the vNIC that was to be used for all ZVM to ZVM as well as replication traffic. In a few short minutes, I was able to get communication going the way I needed it, so the final thing I needed to do was re-configure Zerto to use the new vNIC for it’s replication-related activities. I did that, and while I was able to re-establish the production network communications I needed, now I wasn’t able to access the remote sites (ZVM to ZVM) or access the recovery site VRAs.

It turns out, what I needed here were some static, persistent routes to the remote networks, configured to use the specific interface I created for it.

Here’s how:

The steps I took are below the image. If the image is too small, consider downloading the PDF here.

zerto_dual_nic_diagram

On the ZVM:

Power it down, add 2nd vNIC and set it’s network to the isolated network. Set the primary vNIC to the production network.
Power it on. When it’s booted up, log in to Windows, and re-configure the IP address for the primary vNIC. Reboot to make sure everything comes up successfully now that it is on the correct production network.
After the reboot, edit the IP configuration of the second vNIC (the one on the isolated network). DO NOT configure a default gateway for it.
Open the Zerto Diagnostics Utility on the ZVM. You’ll find this by opening the start menu and looking for the Zerto Diagnostics Utility. If you’re on Windows Server 2008 or 2012, you can search for it by clicking the start menu and starting to type “Zerto.”
Once the Zerto Diagnostics Utility loads, select “Reconfigure Zerto Virtual Manager” and click Next.
On the vCenter Server Connectivity screen, make any necessary changes you need to and click Next. (Note: We’re only after changing the IP address the ZVM uses for replication and ZVM-to-ZVM communication, so in most cases, you can just click Next on this screen.)
On the vCloud Director (vCD) Connectivity screen, make any necessary changes you need to and click Next. (Note: same note in step 6)
On the Zerto Virtual Manager Site Details screen, make any necessary changes you need to and click Next. (Note: same as note in step 6)
On the Zerto Virtual Manager Communication screen, the only thing to change here is the “IP/Host Name Used by the Zerto User Interface.” Change this to the IP Address of your vNIC on the isolated Network, then click Next.
Continue to accept any defaults on following screens, and after validation completes, click Finish, and your changes will be saved.
Once the above step has completed, you will now need to add a persistent, static route to the Windows routing table. This will tell the ZVM that for any traffic destined for the protected site(s), it will need to send that traffic over the vNIC that is configured for the isolated network.

Use the following route statement from the Windows CLI to create those static routes:

route ADD [Destination IP] MASK [SubnetMask] [LocalGatewayIP] IF [InterfaceNumberforIsolatedNetworkNIC] -p

Example:>
route ADD 192.168.100.0 MASK 255.255.255.0 10.10.10.1 IF 2 -p
route ADD 102.168.200.0 MASK 255.255.255.0 10.10.10.1 IF 2 -p

Note: To find out what the interface number is for your isolated network vNIC, run route print from the Windows CLI.  It will be listed at the top of what is returned.

zerto_dual_nic_1_10

Once you’ve configured your route(s), you can test by sending pings to remote site IP addresses that you would normally not be able to see.

After performing all of these steps, my ZVMs are now communicating without issue and replications are all taking place. A huge difference from hours before when everything looked like it was broken. The next day, we were able to successfully move our VPGs from protected sites to recovery sites without issue, and reverse protect (which we’re doing for now as a failback option until we can guarantee everything is working as expected).

If this is helpful or you have any questions/suggestions, please comment, and please share! Thanks for reading!

Share This:

Protecting a VM with vSphere Replication

November 3, 2016November 1, 2016 Gene Torres Leave a comment

Continuing on from the previous blog about configuring array-based replication with SRM, in this blog post we’ll be going through configuring protection of a VM using vSphere Replication. The reason I’m doing this instead of jumping right into creating the protection groups and recovery plans is because vSphere Replication can function on its own without SRM. That said, we’ll go through the steps to protect a virtual workload using vSphere Replication, and follow this up with creating protection groups and recovery plans, which come into play in either situation (ABR vs vR) when we get to the orchestration functionality that SRM brings to the table.

vSphere Replication is included with VMware Essentials plus and above, so chances are you have this feature available to you to should you decide to use it to protect VMs using hypervisor-based replication. In my experience, vSphere Replication works great and can be used to either migrate or protect virtual workloads, however, as stated above, can be limited. See this previous post for the details of what vSphere Replication can and can’t do without Site Recovery Manager.

Procedure

In this walkthrough for protecting a VM using vSphere Replication, I will be performing the steps using a decently sized Windows VM as the asset that needs protection. This VM is a plain installation of Windows, however, I use the fsutil to generate files of different sizes to simulate data change.

In your vSphere Web Client, locate a VM that you wish to protect via hypervisor-based replication.
Right-click on the VM and go to All vSphere Replication Actions > Configure Replication.
When the wizard loads, the first screen asks for the replication type. Select Replicate to a vCenter Server, and click Next.
Select the Target Site and click Next.
Select the remote vSphere Replication server (or if you only have 1, then select auto-assign), wait for validation, then click Next.
On the target location screen, there are several options to configure, so we’ll go through each one by one:- Expand the settings by clicking the arrow next to the VM, or click the info link.– Click edit in the area labeled Target VM Location, select the target datastore and location for the recovery VM, then click OK to be returned to the previous screen.– Typically, the previous step would be enough, however, if you want to place VMDKs in specific datastores, edit their format (thick vs. thin provisioned), or assign a policy, use the edit links beside each hard disk. Once all your settings are how you want them, click Next.

Specify your replication options, then click Next.

Notes:
- Enable quiescing if your guest OS supports it, however, keep in mind
  that quiescing may affect your RPO times.
- Enable network compression to reduce required bandwidth and free up
  buffer memory on the vSphere Replication server, however, higher CPU
  usage may result, so it is best to test with both options to see what
  works best in your environment.

how-to_vspherereplication_1_7

Configure RPO to meet customer requirements, enable point in time instances (snapshots in time as recovery points – maximum of 24) if needed, then click Next.
Review your configuration summary, make changes if necessary, but when you’re done, click Finish. As soon as you finish, a full sync will be initiated.

There you go, configuring vSphere replication for a VM. The next post will cover creating protection groups and recovery plans, which we will then tie into what we’ve just performed here and with the array-based replication post.

Share This:

VMware SRM 6.1 – Configure Array-Based Replication

November 2, 2016November 1, 2016 Gene Torres Leave a comment

Introduction

This how-to will walk through the installation and configuration of array-based replication features for VMware Site Recovery Manager 6.1.

Before configuring array-based replication for use with VMware SRM, there are some pre-requisites. First of all, you’re going to need to visit the VMware Compatibility Guide, which will help you determine if your specific array vendor is supported for use with SRM. Second, there are steps to take to configure array based replication on the storage side, and that portion is out-of-scope for this blog, as I did not have access to do so.

vmware_hcl_example

There are several ways to search the compatibility guide, but to be specific, you can select entries from the areas highlighted above. The bottom section that is highlighted will be your results once you click “Update and View Results.” The reason why I wanted to point this step out is because if you assume your array vendor is supported, and don’t verify first, you could end up wasting your time planning and designing.

For this example, we are using SRM 6.1 with the Fibre Channel protocol on IBM SVC-fronted DS8K’s in both sites. I wanted to point that out because when I first set out to find the SRAs for use with our solution, I attempted to use the “IBM DS8000 Storage Replication Adapter”, later to find out it wasn’t the correct one. The correct SRA for use with my environment is the “IBM Storwize Family Storage Replication Adapter”, so there may be a little bit of trial and error with this; however, if you do it up front during testing, you’ll save yourself some time later when deploying to production.

That all said, once you’ve verified your storage is supported, and what version of the SRA to download, you can get it by visiting the VMware downloads (you will need to login). Be sure to also verify that the version of the SRA you are downloading is compatible with the version of array manager code you’re running.

Installing the SRA

Before you Begin – Prior to installing the SRA on the SRM server in each site (protected and recovery), you should have already paired the sites successfully. Also, if you haven’t installed SRM yet, you will need to, otherwise the SRA installer will fail once it discovers that SRM is not installed.

Installing the SRA should be straightforward and painless, as there are not many options to configure during installation. Once the installation is completed on both the protected and recovery SRM servers, proceed.

Verify That SRM Has Registered the SRAs

Once you’ve installed the SRA on each site’s SRM server, log into the vSphere Web Client, and go to Site Recovery > Sites and select a site.
From this view, you can see what SRA has been installed, its status, and compatibility information.
Click the rescan button to ensure the connection is valid and there are no errors.

Configure Array Managers

After pairing the protected and recovery sites, you will need to configure the respective array managers so SRM can discover replicated devices, compute datastore groups, and initiate storage operations. You typically only need to do this once, however, if array access credentials change, or you want to use a different set of arrays, you can edit the connections to update accordingly.

Pre-Requisites

Sites have been paired and are connected
SRAs have been installed at both sites and verified

Procedure

In the vSphere Web Client, go to Site Recovery > Array Based Replication.
On the Objects tab in the right window pane, click the icon to add an array manager.
Select from one of two options for adding array managers (pair or single), then click Next.
Select a pair of sites for the array manager(s), and click Next.
Enter a name for the array in the Display Name field, and click Next.
Provide the required information for the type of SRA you selected, and click Next.
If you chose to add a pair of array managers, enter the paired array manager information, then click Next.
Click-to-enable the checkbox beside the array pair you just configured, and click Next.
Review your configuration, then click Finish when ready.

Rescan Arrays to Detect Configuration Changes

SRM performs an automatic rescan every 24 hours by default to detect any changes made to the array configurations. It is recommended to perform a manual rescan following any changes to either site by way of reconfiguration or adding/removing devices to recompute the datastore groups. If you need to change the default interval at which SRM performs a rescan, you can do this in the advanced settings for each site, editing the storage.minDsGroupComputationInterval advanced setting:

srm_abr_settings_1_11

To perform a manual rescan after making any configuration changes:

Go to Site Recovery > Array Based Replication
Select an array for either site
On the Manage tab of the selected array, click the Array Pairs sub tab
Click the rescan button to perform a manual rescan.

Once you’ve got all of the above configured, you can begin setting up your protection groups and recovery plans.

Share This:

Product Comparison: VMware SRM & Zerto Virtual Replication

October 28, 2016October 25, 2017 Gene Torres 9 Comments

Introduction

Obviously, based on my previous blog posts, it’s apparent that I’ve been spending some time in the past few months testing VMware Site Recovery Manager and Zerto Virtual Replication to see which product best meets our business continuity and disaster recovery requirements. My task was to compare the two products, feature for feature based on our use cases, which are primarily protection, recovery, re-protection, and workload migration.

Get comfortable, this could take a while…

Blue vs. Red

As of today, SRM and Zerto have been tested in a sandbox environment, consisting of 2 sites (Seattle and Denver), 2 vCenters, 2 physical hosts in a cluster in each site, and 1 test workload which consisted of a Windows Server VM with auto-generated files of different sizes. The two sites, being geographically separated are joined by a dual 20 Gb/s connection, and there are no bandwidth throttling mechanisms in place outside of what’s available in the software, and it’s only used to throttle down during business hours. The physical networking at the host level in both sites is 10GbE.

VMware’s Site Recovery Manager is the only one of the two products that has the array-based replication feature, so to make this more of an “apples-to-apples” comparison, that feature isn’t heavily reported on here, but has been tested, and it works well, so I’m happy.

Both hypervisor-based product tests that were performed have been completed in each direction, in terms of recovery testing, failover, re-protection, and migration. The results of both solutions are similar, however, based on results, we are leaning more toward one product in terms of simplicity, flexibility, scalability, monitoring capabilities, and user experience.

Below are images of what the topology for both test environments looks like, with SRM on the left, and Zerto on the right.

If you are interested in seeing these diagrams up close, you can download the PDFs for each here:

topology_showdown_generic

^^ Not pictured in the Zerto Diagram: External PSCs for vCenter, vCenter SQL Servers, and all port communication native to vCenter components.

Product Comparison

While VMware Site Recovery Manager creates a complete solution with vSphere Replication (which can also be used without SRM), Zerto also protects using hypervisor replication. But to compare the two, we must first compare the capabilities of each solution by comparing vSphere Replication (without SRM) to Zerto Virtual Replication. Note that without SRM, vSphere Replication can be rather limited when it comes to several features. The tables will lay out the use cases for either product, and their features.

Use Cases

VMware vSphere Replication Use Cases	Zerto Virtual Replication Use Cases
Data protection and disaster recovery within the same site and across sites Data center migration Replication engine for VMware vCloud Air Disaster Recovery Replication Engine for VMware vCenter Site Recovery Manager	Replication & Disaster Recovery Offsite Backup and Data Protection Data Migrations & Workload Mobility Automated Failover, Failback & Testing Reduce RTO/RPO Complete BC/DR solution: Business Continuity and Disaster Recovery Storage Savings AWS Migrations: Cloud migration to Amazon Web Services (ZVR 5.0 introduces DRaaS to Azure) Cross-Hypervisor Replication: MS Hyper-V to VMware vSphere/VMware vSphere to MS Hyper-V

VMware vSphere Replication Use Cases

Zerto Virtual Replication Use Cases

Data protection and disaster recovery within the same site and across sites
Data center migration
Replication engine for VMware vCloud Air Disaster Recovery
Replication Engine for VMware vCenter Site Recovery Manager

Replication & Disaster Recovery
Offsite Backup and Data Protection
Data Migrations & Workload Mobility
Automated Failover, Failback & Testing
Reduce RTO/RPO
Complete BC/DR solution: Business Continuity and Disaster Recovery
Storage Savings
AWS Migrations: Cloud migration to Amazon Web Services (ZVR 5.0 introduces DRaaS to Azure)
Cross-Hypervisor Replication: MS Hyper-V to VMware vSphere/VMware vSphere to MS Hyper-V

Feature Comparison: vSphere Replication (Without SRM) and Zerto Virtual Replication

	VMware vSphere ReplicationFeatures & Benefits	Zerto Virtual Replication Features & Benefits
Licensing Requirement	VMware Essentials Plus and Above	VMware Essentials
Automation/Orchestration of Disaster Recovery	Manual, PowerCLI to get basic automation (add to inventory, power on/off) ; otherwise, use SRM with vSphere Replication	Full automation/orchestration features
Version Compatibility	vSphere Replication version must match vCenter version	Zerto can be used with vSphere 4.0 and later, no ties to having every component match versions in respect to hypervisor/vCenter.
Automated Recovery Capabilities	Each VM in the recovery site will need to manually be powered on.	Fully automated recovery capabilities.
Automated Connection to correct network(s)	Manually done when recovering with vSphere Replication. For automation of post-recovery tasks, use SRM.	Fully automated
WAN Compression	Network compression capable with 6.1 at the cost of vSphere replication appliance CPU resources. Note: 1 vR appliance per vCenter instance is supported for a maximum of 2000 VMs protected per appliance.	Built-in, often seeing a 50% compression ratio. Replication appliances are assigned a 1:1 ratio (host to VRA) with automated resource reservations to ensure best performance of replication appliances.
IP Re-Addressing	Manual process. For automated re-IP, use SRM	Built in to failover plan (assigned in VPG)
Non-Disruptive Testing	Not available since you cannot power on the replica VM if the original VM is still running and reachable. Use SRM with vSphere Replication to allow for recovery testing.	Real or bubble networks can be used for recovery testing and isolation.
Cloning Capability	None	Allows for recovery site clones. This allows for full long-term archival backups of the VMs or file-level recovery from a point-in-time clone.
Failback Option	None - SRM required.	Automated failback workflow capability
Point-in-Time Recovery	Available with vSphere Replication 6.x - maximum of 24 PIT instances. Uses VMware Snapshots.	Configurable, however, when using Offsite Backup Feature, up to 1 year. Does not use VMware Snapshots.
RDM (Raw Device Mapping) Support	No physical RDM support, but virtual RDMs are supported.	Both physical and virtual mode RDMs are supported.
Bandwidth Control	None	Throttling and priorities are available in Zerto to reduce bandwidth consumption during certain times, and unlimited at others, via schedule.
vApp Support	Not Supported	Zerto leverages vApps to make administration easier. If a vApp is configured for protection with a VPG, then any VM added to the vApp is automatically protected.
Storage DRS Support	Not supported, SRM is required.	Storage DRS is supported and works with Zerto.
RPO Range	15 minutes to 24 hours	Seconds
How VMs are Chosen	Selected individually or through multi-selecting in the interface, but protection grouping is not available.	VMs can be organized into Virtual Protection Groups.

Feature Comparison: vSphere Replication (with SRM) and Zerto Virtual Replication

	VMware vSphere Replication with SRM	Zerto Virtual Replication
Provides planning, testing, and execution of disaster recovery for vSphere:	Yes	Yes
Designed for:	SRM was designed for disaster recovery orchestration only	Designed for hypervisor-based replication AND disaster recovery orchestration
Licensed:	Per-VM	Per-VM
Replication granularity:	Per-VM or multi-select but virtual protection grouping is not available	Per-VM and/or Per-Virtual Protection Group
Configure consistency groups (virtual protection groups)	No	Yes
Replication recovery points:	Yes, up to 24 snapshots	Yes, up to 14 days with standard recovery, up to 1 year with extended recovery using the Offsite Backup feature.
Compatibility:	vSphere Replication works with ESX 5.x and above. SRM requires the same version of vCenter and SRM be installed at both sites.	Zerto works with ESXi 4.0 U1 and above. Zerto can replicate between different versions of vCenter. Zerto can also protect and recover from vSphere to Hyper-V, Hyper-V to vSphere, and either virtualization platform to the cloud (AWS, Azure(Zerto v5.0)).
Managed with:	vSphere Client Plugin	vSphere Client Plugin and standalone browser UI
Replication is performed with:	vSphere Replication	Zerto HyperVisor-based replication through VRAs deployed to each host with protected VMs

Feature Comparison: VMware Site Recovery Manager & Zerto Virtual Replication API Availability

The following table displays the availability, use cases, and capabilities of both the VMware Site Recovery Manager and Zerto Virtual Replication APIs for access, integration, and automation.

	VMware Site Recovery Manager	Zerto Virtual Replication
Availability	Similar to vSphere API, uses web service that allows access to the API in Java C#, or any language that supports WSDL (Web Services Definition Language).	REST APIs are available to automate virtual infrastructure, allowing for benefits of software defined replication and recovery.
Use Cases	Automation of protection operations	Automation of protection operations Automation of product deployment Querying and Reporting
Capabilities	Create protection groups Initiate testing Initiate recovery Re-protection Revert Operations Collect Results	Bulk automated VRA deployment Bulk automated VPG creation Automating VM protection by vSphere Folder Automating VM protection with vRealize Orchestrator Listing unprotected VMs Listing protected VMs & VPGs Long Term RPO & Storage Reporting to CSV Resource reports VPG, VM, VMNIC & Re-IP settings report Emailing Reports
Programming Environments/Supported Languages	Java JAX-WS Framework C# and Visual Studio Java Axis Framework Managed Objects as WSDL All require SDK installation for each environment	PowerShell cURL Python C#

System Requirements

The following tables below outline system requirements for both VMware Site Recovery Manager and Zerto Virtual Replication.

	VMware Site Recovery Manager 6.1	Zerto Virtual replication 4.5 U3
Virtualization Management	VMware vCenter 6.0 U2 in both protected and recovery sites.	VMware vCenter 4.0 U1 Microsoft SCVMM 2012 R2 As long as protected and recovery sites meet minimum versions, cross-version protection and recovery is supported.
Hypervisor	Minimum VMware vSphere ESXi 5.0	Minimum VMware vSphere ESXi 4.0 U1 Microsoft Windows Server 2012 R2 and Server Core
vSphere Replication Appliance	Minimum vSphere Replication 6.0	Not Required
Storage Replication Adapter	Depends on SAN vendor and code level, availability, and support.	Not Required
Client	vSphere Web Client - by default will match currently installed version that matches vCenter requirement for SRM.	vSphere Client Console (Thick Client) 4.0 and higher vSphere Web Client 5.0 - 5.0 U3 - Not supported vSphere Web Client 5.1 and up - Supported Zerto Standalone Web UI
vSphere Replication Appliance Resource Requirements (per site)	2 vCPU 4 GB RAM 18 GB Storage According to VMware, CPU and memory resources consumed by vSphere Replication on a host or guest OS is negligible. The numbers seen above are how the appliance is configured by default.	N/A
Zerto Virtual Replication Appliance (VRA)	N/A	1 vCPU 2GB RAM (minimum) 12.5GB Storage 1 of these appliances needs to be deployed (via Zerto UI) to each host that will be protecting VMs in VPGs. DRS Affinity rules are created automatically by Zerto during the deployment process, so VRAs always stay on the hosts they are installed to.
Recovery Orchestration Provided By	Site Recovery Manager 6.1 (see versions above for compatibility) or review VMware's product interoperability matrix for all version information.	Zerto Virtual Replication (required before VRAs can be deployed)
SRM6.1/ZVM 4.5U3 Server Requirements (1 per site)	At least 2 CPUs, 4 for large environments 2 GB RAM minimum - at least 6 GB if including OS requirements 5 GB storage (in addition to OS requirements) At least 1Gb/s NIC Windows Server 2008 R2 (64-bit) Windows Server 2012 R2 (64-bit)	Protecting up to 750 VMs and up to 5 peer sites: 2 CPU (reserved) 4GB RAM (reserved) Protecting 751-2000 VMs and up to 15 peer sites: 4 CPU (reserved) 4GB RAM (reserved) Protecting over 2000 VMs and over 15 peer sites: 8 CPUs (reserved) 8GB RAM (reserved) 2GB Storage space for binaries
Supported Databases	Microsoft SQL Server 2008 Express R2 SP2,SP3 (32-bit and 64-bit) 2008 Standard/Enterprise R2 SP3 (32-bit and 64-bit) 2008 Standard/Enterprise/Datacenter R2 SP2 (32-bit and 64-bit) 2008 Standard/Enterprise R2 SP1 (32-bit and 64-bit) 2012 Express SP2 (32-bit and 64-bit) 2012 Standard/Enterprise SP2 (32-bit and 64-bit) 2012 Standard/Enterprise SP1 (32-bit and 64-bit) 2012 Enterprise (64-bit) 2014 Standard/Enterprise (32-bit and 64-bit) Oracle 11g Standard ONE Edition, R2 (32-bit and 64-bit) 11g Standard/Enterprise Edition, R2 (32-bit and 64-bit) 12C Standard ONE Edition, R1 (32-bit and 64-bit) 12C Standard/Enterprise Edition (32-bit and 64-bit)	Embedded SQL database for protecting up to 4 sites, 40 hosts, and 400 VMs/li> Microsoft SQL Server Standard & Enterprise Editions for anything more than the above Microsoft SQL Server Express Supported MSSQL Database versions: 2008 2008 R2 2012 2014
Bandwidth Requirements	> 10Mb/s (dedicated to move 40GB in an hour)	> 5Mb/s
Number of Firewall Ports for Cross-site Communication, Replication, and Recovery	WAN - 7 (in addition to all vCenter related ports) See topology diagram for port listings.	WAN - 3 (in addition to all vCenter related ports) - See topology diagram for port listings.

Steps from Installation to Protection

The following table compares the high-level installation tasks/steps for VMware Site Recovery Manager and Zerto Virtual Replication. These steps assume necessary pre-requisites such as vCenter installation and firewall rules have been created.

Please note, that SRM appears to have many more steps, because SRM supports both array-based replication, in addition to vSphere Replication. If you don’t use one or the other, these steps are dramatically decreased. In my test environment, both features have been tested, and because of that, SRM has more steps.

VMware Site Recovery Manager	Zerto Virtual Replication
Build Windows VMs to host SRM in each site Build SQL Server/leverage existing, or use embedded vPostgress db. Install SRM in Protected and Recovery Sites and license Connect SRM instances in Protected and Recovery Sites Note: This requires a functional error-free vCenter/PSC infrastructure. PSCs should be in-sync with no errors. Pair SRM instances Install & configure Storage Replication Adapters (SRA) Pair Array Managers Configure inventory mappings Create Protection Groups and Recovery Plans Test, validate, protect, test recovery, monitor, and alert. If using vSphere Replication - Install, configure, & pair vSphere Replication Appliances in each site	Build Windows VMs to host Zerto in each site Install Zerto on each ZVM and apply license on login Optional: Build/leverage existing SQL Server, or use the embedded database See Database requirements in the above table for explanation on sizing the DB and when to use an external SQL server. Pair the Zerto instances Edit site settings, schedule throttling if using a shared WAN connection, and configure alerts, thresholds, etc... Deploy ZRAs (Zerto Replication Appliance - one per host that will be protecting VMs) Build Virtual Protection Groups (the VPG configuration also includes recovery options such as re-IP or pre/post scripts). Test, validate, protect, test recovery, monitor, and alert.

VMware Site Recovery Manager

Zerto Virtual Replication

Build Windows VMs to host SRM in each site
Build SQL Server/leverage existing, or use embedded vPostgress db.
Install SRM in Protected and Recovery Sites and license
Connect SRM instances in Protected and Recovery Sites
Note: This requires a functional error-free vCenter/PSC infrastructure. PSCs should be in-sync with no errors.
Pair SRM instances
Install & configure Storage Replication Adapters (SRA)
Pair Array Managers
Configure inventory mappings
Create Protection Groups and Recovery Plans
Test, validate, protect, test recovery, monitor, and alert.
If using vSphere Replication - Install, configure, & pair vSphere Replication Appliances in each site

Build Windows VMs to host Zerto in each site
Install Zerto on each ZVM and apply license on login
Optional: Build/leverage existing SQL Server, or use the embedded database
- See Database requirements in the above table for explanation on sizing the DB and when to use an external SQL server.
Pair the Zerto instances
Edit site settings, schedule throttling if using a shared WAN connection, and configure alerts, thresholds, etc...
Deploy ZRAs (Zerto Replication Appliance - one per host that will be protecting VMs)
Build Virtual Protection Groups (the VPG configuration also includes recovery options such as re-IP or pre/post scripts).
Test, validate, protect, test recovery, monitor, and alert.

Protection Workflow

The following workflows have been created to illustrate the process involved in protecting virtual workloads using VMware Site Recovery Manager with vSphere Replication, and Zerto Virtual Replication.
Individual files for each protection workflow in full-size view are here:

srm_zerto_protection_workflows

In the above images, SRM on the left, and Zerto on the right; visually, you can see that SRM clearly has many more steps performed in multiple places, compared to Zerto. Majority of the additional steps in the SRM protection workflow deal with the multiple layers where protection is configured via the vSphere Web Client for a single VM using vSphere Replication. On the right side (Zerto), you see that most of the steps (if not all) for protecting virtual workloads takes place at the top layer, which is the Zerto Virtual Manager UI.

In SRM, protecting a single VM using vSphere Replication involves selecting the VM enabling vSphere Replication, going into Site Recovery, building a protection group and configuring it, followed by creating a recovery plan and configuring. The recovery plan portion of that is where customization such as boot priority and IP address changes are completed.

In Zerto, protecting a single VM is as easy as logging into the ZVM UI, creating a VPG, and providing protection and recovery settings all within one wizard.

Recovery Workflow

The following workflows have been created to illustrate the process involved in recovering from a site failure using VMware Site Recovery Manager with vSphere Replication, and Zerto Virtual Replication.

Individual files for each protection workflow in full-size view are here:

srm_zerto_recovery_workflows

In the above images, SRM on the left, and Zerto on the right; visually you can see that the steps to recovery are fairly similar, with the exception that recovery in SRM is performed via the vSphere Web Client, while recovery from Zerto is performed from the ZVM UI (recovery performed at the recovery site in both scenarios). The most complex part about recovering in any scenario is the organization of admins/engineers/business stakeholders to recover, re-configure, and validate the recovery process. Of course, if routine recovery testing had been taking place, a failure should basically mimic a recovery test, although, more of a commitment at this point, instead of an exercise.

In SRM, there really is one place to take care of a recovery, and that is in Site Recovery > Recovery Plans. Locate the recovery plan for the application(s) you want to recover, and click the red button – its a no-brainer!

In the Zerto UI home screen, toggle the failover type from test to “live”, and click the recover button. When you click the button, you will be presented with a 3 step wizard, where you will select the VPG(s) to recover; select the checkpoint to recover from, set the commit policy, re-protect; and click the “start failover” button. Recovery and re-protection all in 1 place. The re-protection process in either product is straightforward, however, if there already isn’t a site built to re-protect to, there will be some work to do (in either case).

Implementation Time and Complexity

Planning, designing, and implementing either of these two products shouldn’t be difficult for anyone, except there are several pre-requisites that take time, change management processes and schedules to follow, or firewall rules to create and verify. With SRM, I’ve found that since this product ties to closely in to vSphere and version matching is a requirement, this could delay anyone who doesn’t have a version-aligned environment; or doesn’t have experience with vSphere or SRM. The biggest requirement for SRM? vSphere – you will have to have a vSphere deployment fully functional, and at an exact minimum version in both sites, in order to deploy SRM successfully. Zerto doesn’t care if the vCenter/ESXi versions on both sites match, as long as the minimum supported version is in use.

Granular requirements can make for administrative overhead and total team collaboration in the case of upgrades, maintenance, recovery, etc… because SRM relies heavily on version compatibility (as do other VMware products). In cases like this, there are specific orders of operations required for upgrades or power-on operations. These requirements are out of scope, but it pays to understand that they exist; so be sure to do some research, and if you can, test it before performing in production.

When installing Zerto, what took the most amount of time was building the Windows VMs (a few hours x 2) to house ZVM in each site… that and firewall rules (about 2 weeks, in my case following approval, change management, and implementation). Once the VMs were built and the firewall rules were in place, the actual time taken to install Zerto was about 10-15 minutes per ZVM, and approximately 10 minutes to deploy each VRA, which can also be bulk scripted. Zerto works as long as the hypervisor and vCenter are at a minimum version supported by Zerto, but it can protect across versions, or even hypervisors (VMware vSphere & Microsoft Hyper-V)! VPG creation can vary, depending on how many VMs per VPG you want to protect, and customization of all options, with one of the longer taking items being recovery and test IP settings. That’s it. Once you have a VPG created, initial synchronization starts, and as soon as the sites are in sync, you’ll ready to test, recover, or migrate and re-protect.

Monitoring and Reporting

Monitoring and Reporting with VMware Site Recovery Manager

VMware Site Recovery Manager provides monitoring and reporting, however, is limited depending on where you are in the object hierarchy (but the data is there!):

number of replicated VMs per host
amount of data transferred
number of RPO violations
replication count
number of sites successfully connected

These reports can also be expanded to show more detail, and data range can be modified. In my experience during testing, monitoring replication status and information isn’t as intuitive and centrally located as you would expect. There are several different places to monitor protection status and get additional information.

Some of this is at the VM level, where you will see replication status, last sync point, target site, quiescing (enabled/disabled), network compression (enabled/disabled), RPO, Points in time recovery (enabled/disabled), disk status.

Monitoring at the VM Object

vm_replication_status

At the VM (protected VM) level, you can monitor replication performance, however, it is limited to 2 counters, which are:

Replication Data Receive Rate (Average in KBps)
Replication Data Transmit Rate (Average in KBps)

srm_vm_counters

Monitoring at the Site Recovery > Sites Level

At the site level, you can monitor things like issues, recovery plan history, and also get basic protection group and recovery plan information for Array Based Replication, Protection Groups, and Recovery Plans:

srm_site_monitors

Monitoring at the Protection Group Level

At the protection group level, the summary tab will give you information such as status, number of VMs that are in the protection group, configuration status of those VMs, and any replication warnings (not clickable for more detail):

srm_pg_summary

Selecting a protection group gives you a list of recovery plans, and VMs, and general protection information, but no logging or reporting.

srm_pg_monitors

Monitoring at the Recovery Plan Level

At the recovery plan level, when you select a recovery plan you the plan status, VM status, and recent history if the recovery plan has been run for testing or failover:

srm_rp_summary

Digging deeper into a recovery plan, you have the ability to see recovery plan steps, history, protection group general protection information, and virtual machine general protection information:

srm_rp_monitors

Monitoring vSphere Replication at the vCenter Level

One more place that I was able to find monitoring and reporting is at the vSphere Replication level. Going to vSphere Replication in the vSphere Web Client, then clicking on a vCenter. From there, going to the Monitor tab, and clicking on vSphere Replication will take you the the screen in the image below where you can monitor Outgoing Replications, Incoming Replications, View Reports and Cloud Recovery Settings. The reports section looks to contain the most information, however, there isn’t a way in the UI to export reports if a customer requests a report to show history of their replication jobs.

Monitoring Outgoing Replications (per vCenter)

This section displays any Point in Time snapshots that can be recovered to if it has been configured, and replication information (although very general) such as:

Status
VM
Target Site
vR Server used
Configured Disks
Last Instance Sync Point
Last Sync Duration
Last Sync Size
RPO
Quiescing (enabled/disabled)
Network Compression (enabled/disabled)

monitoring_vsphere_replication_outgoing_rep

Monitoring Incoming Replications (per vCenter)

This section displays Point in Time Snapshots, Recovery history, and Replication information (again all general) such as:

Status
VM (when a VM is selected above)
Target Site
vR Server
Configured Disks
What manages the incoming replications (in this case, it’s SRM)
Last instance sync point
Last sync duration
Last sync size
RPO
Quiescing (enabled/disabled)
Network Compression (enabled/disabled)

monitoring_vsphere_replication_incoming_rep

Reporting for vSphere Replication (per vCenter)

This section contains statistical information that can be filtered by date range. This section is a little more detailed (my favorite view), and actually contains numbers on graphs. It contains information such as:

Count of replicated vs non-replicated VMs
Replicated VMs per by host(s)
Transferred bytes
RPO violations
Replications Count
Site connectivity status
vR Server Connectivity (not pictured)

While this is great information, there is no way from the interface to export the reports if needed.

monitoring_vsphere_replication

Cloud Recovery Testing

This section contains general information on any replications to the cloud. Since we are not replicating to the public cloud, this section is empty, but I have shown it to display what detail it contains.

monitoring_vsphere_replication_cloud_settings

Based on the findings for monitoring vSphere Replication and SRM, as shown above, there are multiple places to look for information, statistics, and reports. The problem here is that monitoring any ongoing replication jobs and/or recoveries and performance is a multi-tiered approach, and there is no centralization of information that is exportable for review. There are too many places to look for information, and it would be too tedious to effectively monitor protection jobs, recoveries, and performance out-of-the-box.

Monitoring and Reporting in Zerto Virtual Replication

Monitoring protection status in Zerto has been intuitive, detailed, and centralized. Zerto has decided to separate the two functions into “tabs” within the UI. One tab for monitoring (includes tasks and alerts), and one tab for reporting. The ability to set Zerto up to alert via e-mail and send reports at a regular interval (and scheduled!) are natively built into the product. The product doesn’t stop with 1 e-mail address destination, as it also allows for multiple recipients via comma or semicolon separator in the site settings. In the resource reports, you can set up the sampling rate, and the sampling time interval. In terms of BC/DR solutions, it would be much more preferred to receive more information than necessary, rather than waiting for a problem to surface. Nothing is more embarrassing or resume-generating than finding out at the point of a failure that your replication product hasn’t been replicating much or hasn’t been able to meet your RPO/RTO.

In the Zerto UI, monitoring alerts, events, and tasks is as simple as clicking on the “monitoring” tab. You can search for specific events or alerts (or both), and also modify the timeframe that you are targeting. In the reporting tab, you can get reports for the following items, and you can select any of them per VPG, or for all VPGs (and customize the reporting dates).

VPG Performance (RPO in seconds, IOPs, Throughput (MB/s), and WAN traffic (MB/s))
Outbound Protection Over Time (data in GB) – for each recovery site
Protection Over Time by Site (Journal Usage in GB, VMs protected by count)
Recovery Reports by VPG, type, and/or status
Resource Report – shows resources used by protected VMs, which is required by Zerto to ensure recovery capability. (Exports to Excel)
Usage – exports to CSV, PDF, or ZIP

zerto_monitoring_tab

zerto_reports_tab

Conclusion

In conclusion, both products work as advertised, and deciding which product to go with may come down to trust, flexibility, simplicity, scalability, monitoring & reporting, re-protection capabilities, and of course, cost. When considering the cost of either solution, be sure to also include the cost of human hours required to successfully deploy and support either one. Both products have their benefits and quirks, but the bottom line is that THEY BOTH WORK GREAT!

Since I also went through the entire process from design to implementation, to protection, testing, and recovery – it took a considerable amount of time for VMware Site Recovery Manager to become usable due to some external problems we were having, so that sort of left a bad taste in my mouth (it was frustrating – but that was specific to my environment). Because Zerto wasn’t affected by those existing problems in terms of being prevented from working, it felt much simpler, but don’t get me wrong, you still have to plan for your deployment. The time that it took to deploy and have both products functioning varied considerably, with Zerto coming in as the winner in terms of time to protection versus Site Recovery Manager in my experience (again related to the underlying problems in my environment).

Array-based replication is an optional feature of SRM, and once we figured out what was needed on the SAN side for this to work properly, it actually runs nicely. This method has historically an expensive route to go due to the requirement of needing to have the same storage (vendor at least) in each site (protected and recovery). This also introduces another layer of complexity in configuration, administration, maintenance, and support alignment, which will involve SAN administrators. vSphere Replication, on the other hand, is easy to set up and you can be replicating VMs using this method in a short period of time.

Scalability of the products is another area I researched and determined that both products can protect up to 5000 VMs per vCenter instance (refer to comparison tables).

vSphere replication (without Site Recovery Manager) has a limitation of 1 vSphere Replication Appliance per vCenter instance. When leveraging the additional (limit) of 9 more vSphere Replication Servers per vSphere Replication appliance, you can protect up to 2000 VMs – see here for details. When pairing vSphere Replication with Site Recovery Manager and array-based replication, you can achieve protection of up to 5000 VMs per vCenter instance. (SRM Operation Limits)

Zerto can scale out to take advantage of cluster resources by deploying a VRA (virtual replication appliance) to each host in a cluster where you are protecting VMs. The VRAs come at no additional cost (both products are licensed per VM being protected) and can be sized as needed for best performance. When deploying Zerto VRAs, you will need IP addresses, so that’s one downside to having one per host, especially in large environments. On the plus side, you can deploy all those VRAs from one screen and their deployments can be automated, so that saves time.

Compatibility of each product and their requirements vary as well, with SRM having more requirements in both sites (protected and recovery). Since Zerto is basically deployed on top of a virtualization infrastructure, it is not tightly integrated into the base vSphere product nor does it rely on the same version requirements as SRM. Zerto is very flexible in versioning for both protected and recovery sites, and it also can protect and recovery to/from vSphere and Microsoft Hyper-V, or cloud providers.

Lastly, while I’m not seasoned programmer or script guru – at a high-level, both products can be programmatically managed, and both support PowerShell (with SRM requiring the PowerCLI add-on from VMware). Both products can also leverage vRealize Orchestrator, allowing workflow automation for protection tasks. Both products include support for multiple scripting/programming languages and have their APIs documented, however, in the case of SRM, the creation of recovery plans and forced-failovers cannot be automated (per the API documentation). Zerto can be managed through a feature-rich RESTful API that allows management of pretty much every aspect of the product and its capabilities, and their documentation is clear and full of example scripts in each of their supported languages for everyday tasks.

I hope this information has been helpful for those who are trying to decide which product to go with, and as always, comments or questions are welcome! And if you find this to be useful information, please share it!

Share This:

Zerto: Perform a VPG Move (VM Migration)

October 24, 2016October 21, 2016 Gene Torres Leave a comment

In a situation where a workload needs to be migrated from a protected to a recovery (or site A to site B) in an effort to change where the production workload runs from, you can perform a VPG move.

From what I’ve seen, in terms of VPG move versus Failover, is that when using the Failover option, there is an assumption that the protected site has failed, so systems may not automatically be cleaned up on the protected site. When performing a move, the protected site is cleaned up as soon as that move is completed and committed unless you select to re-protect the workload in the other direction (can be automatic or manual for commit, maximum time you have to do it is 24 hours, and that is configurable).

One recommendation I have here is that before you perform these steps, perform a recovery test on the VPG you’d like to move to ensure that recovery steps are completed as expected, and that the system is usable at least in a testing capacity.

Log in to the Zerto UI
From the dashboard screen, go to Actions > Move VPG.
Select (tick the checkbox) for the VPG you want to move, and click Next.

Select your options for the Execution Parameters, and click Next. For this example, I will select “none” for the commit policy, to demonstrate where to commit the migration task when you are ready to. zerto_perform_vpg_move_1_4

> Commit Policy: Auto-Commit - you can delay up to 24 hours (specified in minutes), or select 0 
to automatically commit immediately when the migration process is completed.
> Commit Policy: Auto-Rollback - You can delay up to 24 hours (specified in minutes), default 
delay is 10 minutes
> Commit Policy: None - You must manually select whether or not to commit or rollback, based 
on your results.
> Force Shutdown - Use this in the event VMware Tools isn't running, therefore, allowing an 
automatic shutdown. Force shutdown will first attempt to gracefully shut the VM down, and if that doesn't work, 
it will power off the VM on the protected site.
> Reverse Protection - This will automatically sync changes from the recovery site back to the 
protected site in case you want to be able to re-protect a system after a migration. This eliminates the need 
to have to re-initialize synchronization in the other direction. If reverse protection is selected, a delta 
sync will take place to re-protect after the migration is completed. Caveat - You cannot 
re-protect if you select "NONE" as the commit policy.
> Boot Order -(Defined in VPG Configuration, but displayed here)
> Scripts - (Defined in VPG configuration, but displayed here)

Review the summary, and when ready, click Start Move.

During promotion of data, you cannot move a VM to another host.  If the host is rebooted
during promotion, make sure the VRA on the host is running and communicating with the ZVM before 
starting up the recovered VMs.

zerto_perform_vpg_move_1_5

Since we have selected a commit policy of “none”, once the migration is ready for completion, the Zerto UI will alert you letting you know there is a task awaiting input. Click on the area highlighted below.Select to either Commit (checkmark), or Rollback (undo Arrow):
At this point, you can also choose whether or not to reverse-protect. Make your selection and click Commit.The task will update as seen below:
Once you commit the move, the data in the protected site is then deleted, thus completing the migration.

Share This: