Tips for configuring your Zerto Commit Policy

What is a Zerto Commit Policy?

If you are a Zerto customer, you have probably seen this phrase when doing Moves and Live Failovers. But, unless you are the manual reading type, you probably have no idea what it means. I used Zerto for a year or so before Sean Masters (www.seanmmaster.com) was like “you idiot, do you not know what a commit policy is?” (I would venture to say that is verbatim how he said it too.) So don’t feel bad if you don’t know. Plus I’m going to explain it to you. 🙂

A Zerto commit policy allows you to either automatically commit or delay committing to a particular point in time when going to a recovery site copy of your data. This is a major differentiator for Zerto because it means that you aren’t stuck with a bad copy of the data after you failover. If the point in time (or checkpoint in Zerto speak) isn’t what you want, then you can get out of that copy and move to a different checkpoint quickly and easily.

Real world example

If your file server gets hit with a cryptovirus and all of you data is encrypted, you are probably going to want to fail over to your DR copy. But do you know EXACTLY when the virus started? Zerto gives you incredible granularity with its checkpoints, so if you know exactly when it started, you can recover with minimal data loss. (If you don’t you can always roll back farther, but the idea is to minimize data loss.)

We will assume that the virus hit at 10 AM; therefore our first checkpoint selection might be from 9:59:35 in the journal. Next, we tell Zerto to do a live failover, and the VM boots up. After logging in, we realize that the virus is still there and files are already encrypted. I guess that checkpoint isn’t going to work. So how to we go to a different point in time? EASY!

We tell Zerto to rollback instead of commit. Then we are essentially right where we started; we can again go through and pick a new checkpoint, say 9:55:00, and fire up that copy. If it looks right, we will “commit” to this copy of the data. Why do we have to commit? Well, we want Zerto to know that this checkpoint is good and that we are ready to start reverse replication back to the other site. Committing to a checkpoint will allow that process to start.

Zerto Commit Options

There are three options that you can pick from for commit policy.

zerto commit policy
Zerto’s Global Failover/Move Commit Policy

None

None is the easy one to explain. Commits do not happen automatically when you select “None”. You must manually come back to Zerto after checking the failed over virtual machines and tell Zerto to Commit or Rollback. The “None” commit policy is what I illustrated in the example above.

The downside to the “none” commit policy is that if you leave a VM in a not-committed state for too long, it can run out of scratch disk space. This will cause the VM to lock up. The “none” policy also does not consolidate the journal and base disk automatically, so it will cause your VMs to use more datastore space than needed after a while.

Auto-Commit

Auto-Commit means that after a predetermined amount of time, Zerto will assume that everything is OK with the virtual machines it has failed over and automatically commit those VM’s. Reverse replication can then start if it was supposed to. By default, Zerto waits for zero (0) minutes before auto-commit happens. In other words, if you haven’t modified your commit policy either manually during VPG failover or move, or globally, Zerto will automatically commit you to whatever checkpoint you picked without asking you to confirm.

Why is that a bad thing? Well, when you commit to a checkpoint, all other checkpoints in the journal are consolidated and removed to save disk space. So by committing, you are essentially saying “I no longer need my journal history, this is the point in time that I want.” Sounds like a that could be risky if you don’t know what you’re doing, doesn’t it? (Mainly because once the journal is consolidated Zerto can’t magically go back to any other point in time… hence why we call it “commit.”)

However, in a situation where your goal is to failover to a DR site after a disaster, this option is the “easiest.” After clicking failover you literally have nothing else to do, everything is automated to bring VMs online at the DR site. Which is super awesome, if that is your goal. But again, it can be a problem if you are trying to recover from data corruption and you aren’t sure exactly what checkpoint to use. Bottom line, if you are unsure of the checkpoint you want to use, change the time before auto-commit from zerto to something else (10-60 are good options).

Auto-Rollback

Auto-Rollback is the opposite of Auto-Commit. However, because Auto-Rollback is not the default option, you will have to specify the number of minutes to wait before the rollback happens. The process then looks something like:

  • Failover the VMs
  • wait for “X” minutes
  • if the user doesn’t manually commit to the failed over VMs
    • power off failover VMs
    • assume it didn’t work and allow the admin to start over
  • if the user does manually commit consolidate the journal
    • turn the failed over VMs into “regular” VMs
    • Start reverse replication if desired

I like to think of auto-rollback as the “dead man’s switch,” meaning that if you go grab a pizza after starting a failover, Zerto will take control of things after the number of minutes specified have passed. Its goal is to put things back to the way they were before you clicked failover. So essentially, “tell me everything is good to go, or I’ll reverse everything we have failed over.”

The only real downside to this option is the lack of automation. If you have someone who isn’t familiar with Zerto at the controls during an actual disaster, and you walk them through the failover process, you will also have to walk them through the Commit process as well.

So what is the best option?

Good question, but I’m not going to give you an answer. This is one of those questions where there is no right or wrong answer, it just depends on what is best for you and your situation. I’m sure there has been an internal debate at Zerto about what to make the default option. Each option has pro’s and con’s, so it’s not always an easy decision, but hopefully this article has helped you understand what each of the options will do and situations in which you would want them.

Personally, I think that once you are educated on what the options are and how to use them, that you should change the global policy to something other than Auto-Commit after zero minutes. (at least increase it to 5-10 minutes) As this locks you into whatever your first choice is. Why do I think this? More than likely, you will have disasters consisting of virus’s or data corruption many more times then you run into an actual natural disaster.

Also keep in mind that after making a choice for the default policy, you can always change it on a per failover/move basis on the execution parameters tab of the failover wizard.

Commit policy manual change
Changing the commit policy manually in the wizard

Thanks for reading, and let me know if you have any questions!

 

Zerto Cloud Service Provider How To – Part 3 Networking

Zerto Cloud Service Providers are the group of people who leverage Zerto Virtual Replication to provide disaster recovery as a service to customers who do not wish to own a DR site. Essentially they (the service provider) have all of the needed infrastructures in place to allow customers to fail over their virtual machines into that service providers environment. So what does it take to be a Zerto cloud service provider?

This article is the third in a series and will describe how I’ve done multi-tenant networking in my cloud provider lab, as well as what some of the other options are.

Overview

Networking in a multi-tenant cloud is the most interesting part of the series, for me anyhow.

Essentially the goal of networking in a multi-tenant cloud is to provide a secure, isolated network for each customer while still allowing them to get to their data.

To make these goals happen, there are several categories of networking that you will need to configure.

The first type is internal VLAN networking, meaning the networking that lives inside of your four walls and separates one customer’s data from another’s. There is also external networking, meaning networking that brings customer traffic from their site to yours. The third type is the networking that glues the previous two together; like firewalls, VPNs, and routers.

It doesn’t matter if you are the smallest ZCSP or the biggest, you will always have these three networking components in some form. Lastly, before we get started, you should note that Zerto doesn’t really care about which WAN type you pick, or what firewalls you use, etc. It works with them all equally well. The only concern Zerto has is that it can route data from one site to another.

Conceptual Layout

The easiest way to start is probably to show you one way that Zerto Cloud Provider networking can be configured.

What the following diagram is trying to show is that you can have customers with a variety of different WAN connectivity types terminating into your facility. Once inside of your four walls the traffic is processed the same way for everyone. It is first put into a VLAN, then sent to the ZCC. From there the ZCC gets the data to the proper Zerto component on the management network.

Some ZCSP’s use dedicated replication VLAN’s; others allow replication to flow through the “Failover Production” portgroup / VLAN. To Zerto it doesn’t really matter.

 

In my environment, I terminate remote sites into the same VLAN as the “Failover production” VLAN. Here is what it looks like:

ZCSP Block Diagram

Also in this diagram, you can see that the ZCSP’s Management network is completely separate from any of the customer VLAN’s. All of the shared Zerto components like the ZVM, ZCM, and VRA are all installed in the management network.

This is important the understand. For infrastructure to be multi-tenant it has to be effective at isolating tenants from each other as well as isolating ALL backend management components so that tenants cannot access them. If they are not properly isolated you do not have a secure environment.

So a ZCSP should have all of their Zerto components as well as all of their VMware vSphere components in one or more management networks that are isolated. Personally, I keep my VMware and Zerto management components all in the same management VLAN.

Replication Traffic Flow

Zerto has created a method to get replication traffic from the client data center to the management network at the ZCSP. If you look at the diagram again, you can see the component that straddles the two networks, this is the Zerto Cloud Connector or ZCC for short.

Here is an animated version of the diagram to help you visualize what is going on with replication to a ZCSP.

ZCSP data flow animation

Replication traffic generated by the client site VRA’s is sent across the WAN to the ZCC that sits at the ZCSP datacenter. The ZCC verifies the data needs to be transferred to the management network, then forwards it to the proper VRA at the ZCSP site. Management traffic is also passed through the ZCC to get back and forth through the client network.

In a sense, the ZCC is acting as a proxy server for replication traffic as well as Zerto management traffic. When you are configuring your ZORG’s (we will talk about these more in a later article), you will set up your ZCC to have an IP and default gateway pointing to the VPN router that can talk to the client site as well as an IP in your management network. The ZCC then configures the needed static routing and default gateway to make this all work.

During reverse replication, or in situations where the production VM’s are running at the ZCSP site, the data flow is the same but in the opposite direction.

 

My ZCSP networking and other options

Internal Networking

My setup

Inside my infrastructure things look almost identical to the diagrams I have used in this article. I have two VLAN’s defined for each ZORG, one production VLAN, and one test VLAN. Inside of VMware I use a distributed virtual switch and create port groups for each of the VLANs. I also create all of the VLANs on my switching gear as well.

If you read the first two articles in this series you know I’m not using NSX, so these are just regular 802.1q VLANs.

Each customer also has a pfSense Firewall doing routing and VPN work. (again because I’m not using NSX)

Other options

Internal network architecture and product selection will vary depending on budget, and how large you want to scale your environment. Remember there are about 4000 usable VLAN’s. That may seem like a lot, but if you allocate each client 5 VLAN’s each, you are now limited to about 800 customers. Plus you will probably use a few VLAN’s for management too. So to be safe let’s say that 600 is the practical limit (since some customer will probably want more than 5 VLANs.)

Keep in mind too, that I am saying that this maximum would be per core switch. So even if you have 5 POD’s as we talked about in the last article, this maximum would be imposed on as many pods as there are sharing a core switch.

 

Each customer will need at a minimum 2 VLAN’s. One for their Zerto fail-over test network, and another for their production fail-over network and replication traffic. This minimum assumes several things:

  • The customer wants a test VLAN
  • The customer only needs one production VLAN
  • Replication traffic will flow through the production VLAN

If any of the above isn’t the case, then your VLAN count per customer will vary. (That’s why I said figure 5 per customer just to be safe)

The takeaway here is that if you plan to scale more than 600-800 customers, then you may need to look at VXLAN. The only other option would be to build an entirely different POD, with different core switching. Because of the second, independent core switch, you have another 4000 VLANs to work with.

VXLAN, on the other hand, will give you about 16 million segments.

Bottom line if scalability is a concern VXLAN is probably the answer, but it comes at a premium price from VMware. It’s been a while since I reviewed the VMware service provider license agreement, but if you check you will see that there is probably still an upcharge for leveraging NSX.

External Networking

My setup

In my ZCSP lab, I am using VPN connections to remote sites. The are provided by the pfSense firewall VM’s that I talked about earlier. While they are not an enterprise class solution, they are proving to be pretty reliable and work very well for my use case. The two that I have in place have been operating flawlessly for over a year now, probably because once they are configured they “just work” and have had no config changes, just security updates.

Other options

In the real world external networking is going to vary with almost every customer. The biggest thing to remember here is that Zerto does not encrypt traffic between VRA’s and Zerto does not support NAT between any Zerto components. So, protecting replication traffic is the job of the network layer.

There are two things to remember when determining if a particular WAN connection with work with Zerto:

  • Zerto does not support NAT between any Zerto components; or between Zerto and vCenter
  • Zerto does not encrypt network traffic

 

This means that you will need to provide a single layer two network shared between sites, or you need to have layer three routing between sites. Make sure that NAT is not anywhere in the middle.

Remember Zerto does not support NAT between any Zerto components

 

WAN security is provided via a VPN or MPLS or some other type of connection that is natively secured.

Conclusion

Zerto is very flexible regarding networking. The only real requirements are no NAT and a secure connection from the client site to the ZCSP. Outside of that Zerto has no preference as to what vendor, or what type of connection you are using.

Another thing to take away is that Zerto doesn’t list a “best practice” or specific requirements on how you setup your cloud networking. All of the decisions are up to you and what is best for your customers, as long as you can deploy ZCC’s and get replication traffic from the client site through the ZCC and into the management network.

Lastly, Zerto networking is more complicated to setup than some of the other “offsite backup/DRaaS” offerings. But what good is VM recovery if it isn’t accessible? When you configure a client for Zerto replication, they are also configuring everything they need to take advantage of those VM’s once they fail over. This isn’t something that you get out of the box with a solution that is tunneling recovery data over a single SSL connection.

ZCSP Post Series

This post is post 3 of many in a series. I’d love for you to follow along and provide feedback and input as I go. If you are not already following my blog, I encourage you to sign up on the right under the sponsor ads. Don’t worry; you will only get mail when new articles get published.

For a list of other articles in this series, please visit the series homepage here.

Need more info on how to be or get started with a ZCSP? Let me know.

 

Zerto 5.0 Host Maintenance Mode Automation

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

VMware Host Maintenance Mode has been around since the first version of vSphere. It allows administrators to place certain hosts into a state where they are excluded from cluster HA and DRS calculations. This is extremely important if you have a host that is acting up or needs patches.

VMware also leverages maintenance mode as part of its Update Manager product for applying patches and upgrades to ESXi hosts.

Unfortunately, in all previous version of Zerto, the VRA running on each host would cause the maintenance mode operation to fail, and the host would never enter maintenance mode. The only way around this was to manually shut down your VRA before placing the host into maintenance mode.

While it sounds like more of a formality, this actually creates some interesting problems when automating administrative tasks in VMware.

What’s New

Starting with version 5.0, Zerto will recognize when you place a host into maintenance mode. Once it has recognized this, it will shut down the VRA that lives on the host and allow the host to go into maintenance mode, just like if Zerto wasn’t installed.

When exiting maintenance mode, Zerto will also automate the powering on of the VRA so that as other VM’s are migrated back to the host they can be protected.

The Video

The best way to show how this works is with a video. So this video will walk through what happens with Zerto 4.5 and then show you how the new ZVR 5.0 features help fix the issues.

Thanks for watching!

Upgrading to Zerto 5.0 Video Guide

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

VMware Host Maintenance Mode has been around since the first version of vSphere. It allows administrators to place certain hosts into a state where they are excluded from cluster HA and DRS calculations. This is extremely important if you have a host that is acting up or needs patches.

VMware also leverages maintenance mode as part of its Update Manager product for applying patches and upgrades to ESXi hosts.

Unfortunately, in all previous version of Zerto, the VRA running on each host would cause the maintenance mode operation to fail, and the host would never enter maintenance mode. The only way around this was to manually shut down your VRA before placing the host into maintenance mode.

While it sounds like more of a formality, this actually creates some interesting problems when automating administrative tasks in VMware.

What to remember

Before starting your Zerto upgrade to 5.0, make sure that any existing alerts have been remediated. Also keep in mind that during some Zerto upgrades the VIB driver will also need to be upgraded. This can cause a delta sync to occur if protected VMs are not migrated off on the ESXi host that you are upgrading. In the video, In the video, I walk through the workaround and how to minimize delta syncs during upgrades.

Also keep in mind that while you can mix and match different versions of Zerto Virtual Replication, you should have a plan to bring all ZVM’s and VRA’s up to the latest version. This will minimize the work that will need to be done during future upgrades and will ensure that you can support the latest version of your hypervisor platform as well.

The Video

The first thing I want you to remember is that my video editing skills are “newb” at best, so keep that in mind while you check out this video. 🙂

So without further delay, here is the video of doing a Zerto 4.5 to 5.0 upgrade. Also for the best viewing experience make sure to select 1080p as the video format. Enjoy.

Zerto Virtual Replication 5.0 Generally Available

The wait is over!

waitisover

Zerto announces General Availability of Virtual Replication 5.0!

Whether you are a current Zerto customer or not, you will want to check out the latest release of ZVR 5.0. The team pulled out all the stops to release two major releases in the same calendar year, and both are jammed packed with features!

In release 4.5, Zerto added File-Level Recovery, journal compression, enhanced API support, and AWS S3 encryption.

Now new features in 5.0 include

  • 30-day journal
  • Replication to Microsoft Azure
  • One to Many Replication
  • Mobile SaaS monitoring
  • VMware Host Maintenance Mode Support
  • Zerto Licensing Tiering

Several other features and improvements have been added in 5.0 as well. Check out the release notes for the complete details.

For each of the major new features, I have put together some deep dive posts that explain how the new feature works. Some are even complete with video walkthrough as well!

Zerto 5.0 New Feature Deep Dive Posts

Replication to Azure

One to Many Replication

Mobile SaaS Monitoring

30-Day Journal

ZVR 5.0 Video Posts

VMware Host Maintenance Mode Support

Upgrading to Zerto 5.0 Video Guide

Licensing Changes

Zerto licensing has a couple of new changes that affect 5.0. For all the details check out this deep dive post.

Zerto 5.0 Licensing Deep Dive

Feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to improve constantly, and the best way to do that it to understand your real world use cases.

Zerto 5.0 Licensing Deep Dive

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

If you have known Zerto for any amount of time, you know that licensing is the easiest thing possible. For the longest time, there were probably only three SKU’s (I’m kidding of course), one SKU for the product, and two SKUs for maintenance (one being 8×5 and the other being 24×7).

Zerto’s price tag has been rock solid as well. In fact, there hasn’t been a price change for maintenance or the product in over 5 years. (Has any other software vendor made it that long?)

However, with 5.0 some things have changed.

What’s New

Starting with version 5.0, Zerto will now have three licensing models for customers to choose from, there were 2 models before 5.0. The two existing models are the standard package for VMware and Hyper-V platforms (private cloud), as well as the public cloud platform(AWS and Azure). The new version is called “Enterprise Cloud Edition” or ECE for short.

With ZVR 4.X licensing you could essentially replicate between private cloud hypervisors and you paid per protected VM. If you wanted to go to the public cloud, you had to purchase a second license that was a subscription based license and was only good for VM’s destined to AWS.

In ZVR 5.0 things stay the same for the two existing license packages, but one of the enhancements for ECE is that you can shift your protected VM’s between private cloud and public cloud while using the same license. So if you are considering replication to Azure or to AWS, and also have a private cloud workload, ECE is probably the best choice for you!

What version fits you

Here is a matrix of what licensing looks like to help you select what is best for you:

Platform Zerto Virtual Replication ZVR to Public Cloud ZVR – Enterprise Cloud Edition
VMware vSphere
Microsoft Hyper-V
Replication to Azure
Replication to AWS
Replication to ZCSP

ECE Features

These features are NOT included in ZVR 5.0 Standard – Only ZVR 5.0 ECE, so if you want to use any of the below you will need to upgrade to ECE.

  • License mobility – use license for private or public cloud replication
  • Multi-Site Replication
  • Zerto Cloud Manager
  • Cross Hypervisor replication

Why the new changes?

Please note that this section is 100% my opinion. It may or may not be the view of my employer, but I did not check with them before writing this post.

The features that are included in the new Enterprise Cloud Edition of Zerto hold a significant value for the customer that need them. Customers who are replicating from site A to site B, however, would see little to no value added to the product.

So the powers that be had a decision: continue to provide all features to all customers – but raise the price for all customers. Or split the more advanced features into a premium version so that customers who need the premium features can pay for them, while keeping the price tag the same for the customers who do not. They choose to do the latter.

At first, I have to say that I was sort of mad about splitting the product into two versions, but since the initial internal announcement I have found that it makes sense and will be the best direction for the product long run.

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to constantly improve, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – 30 Day Journal

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

With the 5.0 release of Zerto Virtual Replication, the maximum journal history has been increased from 14 days to 30 days. In a typical disaster recovery situation, being able to rewind time all the way back to 30 days in the past is not that useful. I mean come on, who would really give up an entire month of data to recover from a datacenter fire? No one.

However, if you pair a 30-day journal with Zerto’s Journal File-Level Recovery, introduced in version 4.5, you can see where we think the value is. There certainly is a use case for being able to quickly recover individual files as old as 30 days in the past.

Is there value in an extended journal?

You might be saying, well I have backup software for file restores, and I wouldn’t argue with you if you did. However, Zerto gives you granularity that you will never find in backup software.

Because Zerto is “always-on” and essentially streaming data changes to the other side, you literally can recover data from almost any point in time during the previous 30 days. If you don’t think there is value in any point in time recovery, I would ask you to talk to your accounting person. Ask them how upset them would be if they had worked on a document from 8 am until 4:30 pm, and then a virus encrypted the file. Essentially causing their entire day to be lost. If you told them that your backup software had a copy from yesterday, but all of their work today was gone, they might be upset. (Probably not as upset as if you told them that you didn’t have a backup, but still upset).

Data Protection with Snapshots and Backups
Data Protection with Snapshots and Backups

Zerto, on the other hand, would have a BUNCH of restore points that have that file in it. In fact, if you have sufficient bandwidth you can have checkpoints as often as every few seconds. So if your data gets encrypted at 4:30 pm, you could recover a copy from 4:29:50 pm.

Zerto's Journal Technology - now with 30 days of history
Zerto’s Journal Technology – now with 30 days of history

With a 30 day journal, you can now offer similar recovery all the way back to 30 days ago.

Do I still need backup software?

In my opinion yes. Zerto is meant for disaster recovery and for file recovery from points as late as 2 seconds ago or as old as 30 days ago.

If you need something from day 31 you would have to be using the Zerto Offsite Backup function. The downside to Zerto’s Offsite backup is that it’s done on a VPG basis. So if you want a single file or a single VM from a VPG with many VM’s, you would need to recover an entire VPG to grab a single item.

So for granular recovery older than 30 days, you will probably want something that looks more like “backup” software.

Zerto also has no intention (that I know of) to go to tape or to protect physical servers, so backup software is still a must in certain situations.

Bottom line, Zerto can now augment your backup strategy and may reduce your dependence on your regular backup software. But having multiple copies of your data, grabbed by multiple technologies is NEVER a bad thing.

How do I get started?

Getting started with Zerto’s 30-day journal is super easy. All you do is edit your VPG and change your Journal SLA to a new value, up to 30 days.

It will then automatically be available for both file restores as well as moves, failovers, and test failovers.

The only requirement is to be running ZVR 5.0 code.

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to improve constantly, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – Mobile Monitoring

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

With the release of Zerto Virtual Replication 5.0, there is a brand new way to monitor your Zerto infrastructure.

DR monitoring in your hand

How many times have you wondered if vSphere Replication or your SAN based replication was working? Chances are if you wanted to know, you had to break out your laptop, probably start a VPN client, and then remote in.

Zerto Mobile aims to simplify the process by putting the data right on your mobile device.

Zerto Mobile Main Screen
Zerto Mobile Main Screen
VPG Status Screen
VPG Status Screen

 

How it works

Zerto Mobile is delivered as Software as a Service, meaning that all the data resides in “the cloud.” The data is sent to Zerto’s cloud server from your Zerto Virtual Managers and is then retrieved by your mobile from the cloud server.

It’s important to note that there is no VPN connection needed. Instead, all data travels over SSL encrypted connections. Just to make things even more secure, the only people who can see your data, are those who you authorize to see your data.

Bottom line, we secure it the bests ways possible and look to you to give authorizations to people you trust.

Check your alerts from the golf course

Besides showing off your LOW RPO to all your buddies, you can also investigate any alerts that might be present.

Mobile Alerts List
Mobile Alerts List
Alert Details
Alert Details

You can even dig into each alert to see details of what is causing it.

If you determine that further investigation is needed, you can always break out your laptop and that VPN connection. But if things are OK then you saved yourself a lot of time and can get back to the rest of your day faster.

No mobile remediation… yet

I know what you’re thinking. If you have kids like I do, you know that they love to go into whatever apps are available. Have no fear; Zerto Mobile is currently for MONITORING only.

Let me repeat; currently, you cannot initiate a failover or any other actions from Zerto Mobile.

These features are TBD and may be included at a later date, but remember I’m just an SE so until you see an official statement it’s just my opinion.

How to get started

There are only a few requirements to get started with Zerto Mobile.

  • At least 1 ZVM running ZVR 5.0
    • Make sure to enable Mobile reporting during the installation/upgrade
    • It must have internet access
  • Mobile Device with “Zerto Mobile” installed
  • MyZerto account using your corporate email address

Once you have your MyZerto login information, and you have upgraded to Zerto 5.0, you can download the mobile application and sign in using your MyZerto credentials.

Once signed in status information will automatically start downloading to your mobile.

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to improve constantly, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – Replication to Microsoft Azure

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Zerto has expanded its public cloud support with the release of Zerto Virtual Replication 5.0. With the release of ZVR 4.0, support for Amazon Web Services was added to Zerto’s replication package.

Architecture

If you are familiar with Zerto’s architecture for AWS you will find that Azure operates the same way from the Zerto perspective. All of the Zerto components at your private cloud site (ie VMware / HyperV) are the same – you still have a Zerto Manager and VRA’s.

There is only one component at the Azure site, a ZCA, or Zerto Cloud Appliance.

Zerto's Azure Architecture
Zerto’s Azure Architecture

Your replicated data is stored as Azure blobs. Journals get 16MB block blobs, and replica disks are stored as single page blobs. If you don’t know how to set up Azure blobs, don’t worry, Zerto takes care of all of the Azure storage requirements for you.

Requirements

The Azure specific requirements include a working Azure account, a connection to Azure, and a ZCA to be configured. Connectivity options include VPN, or Azure ExpressRoute, and the ZCA should be configured as size: D3 v2.

In order to replicate to Azure you will need to be running ZVR 5.0 at your VMware/HyperV site, and you will need to contact your Zerto account team in order to get access to the Azure bits.

Limitations

As with anything, there are some limitations with Zerto replication for Azure. The largest of which is that today replication is only “to” Azure, and any failback operations have to be done with a V2V type tool. Microsoft’s level of involvement has been tremendous from what I have heard though, and I suspect that automated reverse replication and failback is right around the corner.

Some other things to keep in mind:

  • Maximum disk size of 1TB (per disk), which is the maximum Azure page blob size
  • Only Windows and Linux OS versions supported by Azure are supported for replication
  • RTO’s are much better than they are with AWS

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to constantly improve, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – Multi-Site Replication

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

It’s finally here

I don’t know how many customers have asked (but it has been a lot!) if Zerto does multisite replication in the short time I have been at Zerto, but up until now I had to say no.

Starting today I can say yes!

What does it do?

Pretend for a second you are a university, or a business with a fairly large campus. Ideally you might want to failover from one building one to building 2 across campus if possible. However, for larger events, like a tornado or flood or something, you might want to failover to a facility 50 miles away.

Multi-Site replication
Multi-Site replication

Zerto now offers customers the ability to replicate any VM to as many as three different locations. You get to pick what those destinations are, as well as the SLA and journal history for each destination.

Other uses

Multi-site replication works by allowing a VM to belong to as many as three Virtual Protection Groups at the same time. Each protection group can contain one or more VM’s. This means that multi-site can also be used for protecting an entire site to a DR site, while also protecting individual application stacks locally.

Mix and Match VMs in VPGs
Mix and Match VMs in VPGs

Bottom line: A VM can now be in 3 VPG’s at the same time, which combination and where you choose to send those VPG’s is completely up to you.

Requirements

To get multi-site replication going you will need to following:

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to constantly improve, and the best way to do that it to understand your real world use cases.