Hypervisor-Level Replication with Zerto

One of the many benefits of server virtualization is that it makes BC/DR easier by transforming physical servers into files that can then be easily transported over different media. Well, that takes care of the DR portion of the acronym. But, if organizations want to address the BC (business Continuity) portion, they would then need some form of replication and while many solutions exist on the market today, all of these solutions were never designed for virtualization. Instead, almost all were built for an era of physical machines or LUN-based storage replication.

Don't get me wrong, lots of BC solutions work and get the job done with some caveats. Some of them rely on snapshots, which is a fine approach except that it is a single-point-in-time replication. While you can constantly take snapshots and replicate them, you can see how the process becomes frustrating and does not feel like it is a "clean" way of approaching a solution in which the customer wants or aspires for real-time or near real-time replication. LUN-based replication also has some challenges. Some of the solutions here require the same hardware on the other end and a number of other prerequisites that, again, take away from the virtualization value-proposition of abstraction (hardware agnostic) and simplicity.

What I like about Zerto is that it was built specifically for virtualization. Zerto does not care what storage you are replicating from or to; it is completely agnostic, which satisfies and is in line with the virtualization value-prop and also is simplicity: A virtualization admin can administer replication without the need to involve the storage administrator in the process. The storage admin goes back to simply provisioning my storage on both ends and doesn't worry about anything else. Oh, and by the way, you can have any combination of storage matrix on each end -- NFS to FC, iSCSI to local disk, whatever you want.

The way Zerto works is actually pretty cool. It interacts with the vSCSI controller, which passes the I/O from the VM to the hypervisor. Zerto taps into that stream, makes a copy of it and redirects it. This approach means that if you can constantly be tapped into that stream copying the traffic to a different source, your replication is constantly in real-time.

The components that Zerto requires is a master Zerto server that can manage the environment and is capable of deploying Zerto appliances onto each ESXi host in the virtual infrastructure that needs to participate in the replication.

I am sure you're asking about any performance impact and that'd be a good question. Given that Zerto loads a driver into the hypervisor, it must be taxing it from a resource standpoint somehow, right? Something's gotta give. You have Zerto appliances on each ESXi host, the Zerto driver into the hypervisor, so there has got to be some hit in performance hit. The question also is, how much?

I am going to run a demo in the lab and report back in a blog post soon. However, I wanted to test the waters and see how many of you would be interested in a hypervisor-level replication that puts you back in the driver seat from a replication standpoint. Think of Zerto as Site Recovery Manager on steroids -- it tackles the storage replication where you don't need to rely on third-party replication and also tackles the logical pieces of SRM.

Posted by Elias Khnaser on 06/23/2011 at 12:49 PM