Using Snap Creator to Offload Backups in RHEV & KVM

Several months ago I highlighted the use case for mixing thick and thin hypervisors in the context of Red Hat Enterprise Virtualization. Today, I’d like to build on that to provide more detail on using an agent on the thick hypervisor (RHEL 6 and KVM) to streamline the process of backing up data volumes. And as the title suggests, we’re offloading that backup requirement away from the hypervisor. Why?

Because we can (and should).So where are we offloading the backup to? The storage array. Specifically, we’re taking advantage of the SnapShot copies available in a NetApp FAS controller as well as a (free) backup framework called Snap Creator. We’ll get into why’s and the how’s in a moment.

First, we still need to address the reason for offloading in the first place – aside from you just taking my word for it. We offload away from the hypervisor for 2 main reasons:

  1. We can do it (much!) faster and use less storage space on the storage array
  2. Forcing the hypervisor to copy/backup/clone takes serious I/O away from the virtual machines.

If you haven’t read the post I referenced on Mixing Thick & Thin Hypervisors in the beginning, go read it now. I’ll wait. It’s important to understand why we need the thick hypervisor in this case. And don’t worry, because this is targeted at the thick hypervisor, it works equally well regardless of whether or not you are using RHEV. All of the communication happens between the Snap Creator server and the agent that runs on the hypervisor.

So, enough talking, let’s get down to brass tacks. Below are 3 different demos. If you just want to see things in action, go to the 3rd video, but you’re missing out if you skip the first 2. It’s insanely quick/easy to deploy Snap Creator server then the agent and those pieces are covered in the first 2 demos. The total time for all 3 videos is 6.5 minutes, so it’s hardly a commitment.

Snap Creator Server Install

As the demo shows, it’s as easy as downloading/extracting the tarball, launching & walking through the installer, and starting the service.

Snap Creator Agent Install

Using the same tarball (different directory), we deploy the agent and start the agent service.

Snap Creator Profile Configuration and Execution

Now that we’ve installed the server and agent, we complete our configuration, choose our options, and set a schedule. But being the impatient lot we are, we go ahead and manually launch the backup rather than wait for the schedule to run..

So there’s the run down on offloading backups away from the hypervisor and how easy it is with Snap Creator. It comes down to allowing the storage array and the hypervisor to focus on the things that they are good at respectively.

But what was that bit about a KVM module that I saw in the 3rd demo? I’m glad you asked. In the examples above, we rely solely on the Snap Creator agent to run the quiesce/unquiesce commands. It works well, but it’s not exactly eloquent. As highlighted in the 3rd video, there are currently several “plugins” available for specific applications. These plugins handle all of the backup and recovery activities using the native api’s for the application specified.

We’re working on an open source KVM plugin that would handle most of the needed activities needed for backing up and restoring application and vm data needed in a KVM environment. The “pre” and “post” SnapShot commands will still be available, but the KVM plugin will be a much more tightly integrated solution.

If you’d like more information, check out the Snap Creator Developer Community at http://snapcreator.com. There’s a ton of great information on Snap Creator including on how you can get involved. Additionally, there are a ton of other Snap Creator videos on YouTube if you want to see more.

hope this helps,

Captain KVM

Agree? Disagree? Something to add to the conversation?