This past weekend I had the pleasure of joining the Zerto team “Masters of Disaster” in running the 24+ hour Ragnar team relay in the beautiful Adirondacks. The run started Friday morning 6am all the way through to Saturday afternoon with 2 vans, 6 runners in each, taking turns to complete the 200-mile run from Saratoga to Lake Placid. I had an amazing time completing this fun challenge with my friends and can’t wait for next year, but running a few hours in the US backcountry got me thinking. What is the most underrated Zerto feature?
Is it the RPOs in seconds? No snapshots? Journal based point in time recovery? RTOs in minutes? Nope, you probably know all those. It’s prioritization (or prioritisation in my language!). This simple little box when creating a Virtual Protection Group (VPG) is way more powerful than you may have imagined:
So, what does it do and why is it so underrated? Put simply; priority is a built-in QOS mechanism within Zerto. Defined as high, medium or low, it sets the priority of the replication traffic of all the VMs within that group. This ensures that Zerto maintains the lowest Recovery Point Objective (RPO) for your most critical applications, which is key for any actual DR scenario to reduce data loss. The real beauty of this feature isn’t just this, its that the prioritization only kicks in when the bandwidth becomes constrained!
If the bandwidth is available every VPG maintains a sub 20 second RPO giving you the lowest average RPO possible and maximum utilization on your WAN link. If the bandwidth starts to strain or hit your configured throttle limit, then Zerto automatically starts tiering the replication streams making sure your most important VPGs maintain the lowest RPO. When the bandwidth pressure decreases it then automatically self-heals and returns all the VPGs to sub 20-second RPOs. Each application can then easily stay within your defined SLAs and you only have to configure the RPO Alert setting to notify you if they are breached, all without ever having to manage the scheduling again. Pretty cool huh?
This becomes even cooler when you consider how you might even try to do this with storage-based replication solutions. Yes, you can configure different replication schedules, but how can you ensure that your key applications replicate in preference to lower tiers? Your job relies on ensuring minimal data loss in key applications in the event of a disaster, yet you have no way to guarantee their replication traffic streams are treated with this level of importance. If everything starts to overlap, all your RPOs are fighting for bandwidth and you put your data at risk. Therefore, this feature is hugely important. With Zerto VPG priority you set it, forget it, then just monitor the RPO alerts on the back end.
I’m still thinking about it, but in my next blog post, I will cover the most underrated Rubrik feature that I’ve seen in my relatively brief 6 months working with the technology. In the meantime, live the dream (as my first co-worker Nick used to say every day as we slummed it in our minimum wage jobs hating every day!).
Joshua
Couldn’t agree more Josh. How anyone could consider a DR solution enterprise-ready without the ability to give priority to, say, their mission-critical SQL servers over a less-critical file server is beyond me. DR is about planning and eliminating potential issues through the use of focused and granular policy consideration/implementation. Prioritization of virtual protection groups is an important and often-overlooked feature within Zerto that really differentiates from other solutions in the market today. In a perfect world, bandwidth would always be robust and available. In the world we live in, it’s best to prepare for the unexpected and this is how one can ensure that the most, critical applications are categorized accordingly in the DR sequence. Great post as usual!
That there is definitely an underrated and often overlooked feature. We actually make use of it to increase priority for several high use Exchange servers we’re going to be migrating to another Datacenter. Since we throttle during business hours they often end up falling behind, so to overcome that we have them set higher to maintain the lower RPO and keep them from falling too far behind. So far, it’s been working great! Thanks for sharing, and congrats on participating in the Ragnar!