This is a guest post by Steve Thomsen, Zerto’s Director of Central US Sales.
If you could ask a virtualized application, “What is your definition of storage?” the reply would probably be, “the hypervisor”. This makes sense; after all, the application is still doing block-level data writes, just not to SCSI devices but rather to virtual SCSI devices, aka VMDKs.
One of the really interesting capabilities of Zerto is providing replication consistency for VMs residing on different hosts, clusters or disparate storage arrays. This means multiple VMs and their VMDKs comprising an application can be faithfully replicated and recovered with write order fidelity regardless of the source location of the VMs from a host or storage perspective. This is all performed at the VMDK level and does not require an agent on the VM. Zerto’s logical entity for recovery for these VMs (multi-tiered app) is called a Virtual Protection Group (VPG).
Alternative methods of replication, host, snapshot and storage-based, are not as flexible.
- Host-based replication solutions can replicate at the VMDK level, but they have no knowledge of what is happening to other VMs – on the same host or otherwise. This precludes them as viable options to protect multi-tiered applications while maintaining write-order fidelity.
- Snapshot-based replication suffer from some of the same issues of host-based replication solutions in terms of protection but they also introduce a performance penalty when taking snaps. As well, they tend to scale very poorly as the number of VMs and size of snapshots increase.
- Storage-based replication solutions can protect VMs residing on different hosts, but there are restrictions. If you have a SAN you have to consolidate those VMs on a specific LUN or set of LUNs. This works the same for volumes with NAS. Once those VMs are migrated over to the new LUN/volume(s), they aren’t going anywhere. To move one of those VMs off that LUN/volume means you are not protecting it anymore; which means your entire application is in an inconsistent state in terms of recoverability. This is also a very cumbersome set-up with a lot of moving parts (except the VMs). From a VM perspective it is very static and “un-virtualization-like”.
In a previous blog post about protecting and recovering virtualized applications, Zerto’s Virtual Replication Appliance (VRA) was discussed in terms of the ability to choose which VMs are replicated and which are not. Recall each VRA resides on a host (VM).
Now step back and think about that for a minute. What if Zerto had a VRA on each host in your environment? The answer is Zerto could in effect see all I/O across your vCenter instance. To Zerto, the entire vCenter instance is now the array. Think of the VMDKs as the LUNs. Zerto is simply performing controller level services, in this case replication, across the VMDKs that it is protecting. What we have done is move block-level services up the stack. From a high level the concepts and terms we understand from legacy host and storage-based replication technologies still apply. However the implications of being in the hypervisor are profound. Virtualization is all about allocating the appropriate resources to the data/application at the appropriate time. Today storage does not allow for that.
Note: Zerto’s VRA uses on average only 3-5% or less of host resources. There is minimal overhead for replication.
When we Zerto-ites talk about reducing complexity many in the audience naturally think of our ability to replicate across block and file storage systems or across vendors. Or maybe that Zerto can replicate RDMs (physical or virtual), etc. However the real value of Zerto is de-coupling your VMs from your storage. You can potentially reduce LUN count, design complexity, and reclaim storage.
When setting up a storage array an organization settles on a standard LUN size. To protect and recover virtualized applications individually you have to consolidate the VMs comprising the application on a LUN or set of LUNs. You then replicate the LUN(s) to the target. Here is the scenario:
You have a standard LUN size of X. You are buying a new array and moving more and more applications into VMware. However in order to leverage storage-based replication and recover applications individually, you start architecting a lot of LUNs into your to-be-acquired array. Keep in mind you have a standard LUN size. Well those virtualized applications don’t care about standard LUNs sizes. Next thing you know you have lots of LUNs all over the place. And those LUNs have white space.
With Zerto that goes away. Now you can failover and recover virtualized applications without implications to other applications on the same source LUN or volume. That is big. Now you can design your storage for I/O and consolidation vs. data protection; which is what shared storage is supposed to be about. Consolidating LUNs and volumes also reduces white space, which in turn reduces storage footprint.
Now think about the impact of only replicating VMDKs vs. full LUNs on bandwidth requirements.
One Zerto customer saw these results: 1. reduced their LUN count by over 40%, 2. a 40% decrease in bandwidth requirements and 3. the storage footprint of the LUNs of the replicated VMs decreased by 25%!!!
Being in the Hypervisor is the place to be.
