Application Recovery Across Multiple LUNs
By Zerto, on 9 April, 2014
Guest post by Justin Nordeste, Zerto Cloud Technical Engineer
Today we’re going to talk about multi-tiered applications and disaster recovery (DR) strategy. You’re probably just like everyone else; you want the lowest Recovery Point Objectives (RPO) possible, but don’t want your SAN design to conflict with the needs of your Array Based Replication (ABR) solution, right? Well, Zerto is here to help!
Traditionally, ABR is an all or nothing sort of thing. All of the VMs for the application are on a single LUN or multiple LUNs and these LUNs are added to a consistency group. This could give you consistent recovery points, but then everything on the LUNs will be part of that consistency group. This can lead to a few things. For example, you can architect your storage to align with your BC/DR strategy. This can take a lot of configuring, planning, and overall adds a lot of management complexity for the storage team. Replicating this way could also mean that any IO for VMs that aren’t needed for the application but happen to be on those LUNs gets replicated too; this consumes additional bandwidth and could increasing overall recovery time. There’s got to be a better way, right?
With Zerto Virtual Replication (ZVR), your VMs can reside on any datastore connected to the host; ZVR even supports individual disks for the VM being spread across different datastores. When configuring ZVR, we place the protected VMs in a Virtual Protection Group (VPG – think ‘application consistency group’). When configuring this VPG, you get the flexibility to choose which recovery datastore the disks replicate to at the disaster recovery site. This applies to all disks for any VM in vSphere – even RDMs!
What exactly does this mean? It means that your storage design can be focused on what it should be focused on – ease of management, high performance, and efficient design focused on the application needs. It also means that any storage that can be seen by the remote hosts can be used – no more vendor lock-in!
Let’s take a look at this in action! Here’s a basic example with a small test VM in my lab. Check out how the VM has 2 disks, each on a different datastore:
Now, let’s see how we can protect this VM in Zerto. Here is the VM in a VPG. I’ve selected a few default values for recovery resources, but we will go in and configure this VM individually instead of just accepting the default values.
Everything looks good, but we want to replicate this VMs disks from multiple datastores and too multiple datastores, right? This is where things get a bit more interesting, let’s dive in and configure the individual VM by selecting it in the table and clicking the ‘Configure’ button.
The “Volumes” table shows the source location on the two different datastores as well as the path to these disks on the datastore itself. Note how we can select each volume and configure it individually. Let’s see what other datastores are available for this volume at the DR site.
Here, I’ll select a different datastore available to the disaster recovery host, cluster, or resource pool that this VM will replicate to. Once I click save, note how the target is now updated.
Everything looks great! We now have each disk for the VM configured to replicate to different datastores at the recovery site. I hope this basic example illustrates this game-changing feature and how easy it is to set things up.
Regardless of what the source storage is or where the VMs disks are located, Zerto can protect it and help your ease your storage configurations for BC/DR. Still not convinced? Contact our sales team and get your hands on a free trial so you can test it yourself!