There are a lot of tools out there for monitoring datacenter environments, and there are many different components. The key is to consolidate the dashboard while still reporting the needed metrics for planning. Anyone who has tried to configure a tool across their enterprise understands there are tools that can grab just about any piece of data, but customization allows that data to be useful.  There will need to be many different views based on the job function of the reviewer. Most of the customization time is spent getting the data out of the repository and displaying it in a way that makes it easy to manage and report on the environment.

I’ve decided on a couple of tools – VMware Operations Manager and EMC Data Protection Advisor – for my environment, and will be tasking my team to bring them together. I will be focusing on a couple of aspects of my environment that will help with the testing:

• Storage consumption in my virtual environment.  I’m getting a little tired of people asking for virtual disks of 500 GB but only leveraging 10% of the space over a few months.  We will be leveraging this to size future projects and make sure unconsumed space is allocated to other people.
• Performance of my VMware environment from a CPU, memory and disk perspective, and I wouldn’t be complete if I wasn’t looking for backup performance and contention.  We will be leveraging this report to see how backup is affecting our production environment.

I’ll be using this blog to keep you posted on our implementation. Be sure to keep checking back for updates on our progress. Also, if you have anything that you think would be good to add or want to share any stories, comment away!

What would you rather do recover 2GB or 500GB?

Recovery is the final end game – after all, it is the point of backing up. With Avamar, files can be recovered into a VM without the need for agents within the guest OS.  But this is not the revolution. The revolution is about “changed block recovery,” or CBT restore, and Avamar is the only software that can do this. (For more of my thoughts on CBT, check out my previous posts.)

Here again, this is due to Avamar’s block-based architecture. By retaining a block as a block during the backup process, Avamar can re-scan the existing CBT reference file and compare it to the CBT information stored from the backup the administrator is recovering from, and only send back the blocks needed. This significantly reduces both the amount of data that needs to be recovered and the time to achieve full recovery.

Since other vendors’ solutions store the file, they have no way to convert a file back to a block and ensure where that block was within the VMDK at backup time, which means they don’t have a changed block recovery options. This means long restore times when doing an image recovery.

Proof Is in the Use Case
It is nice to have restore options, but they need to be practical or they are just a “check box” on a slide deck. So, let’s look at a real-world example.

Consider the scenario in which there’s an issue with 500GB SQL DB running in a VM. The SQL DB could be recovered with any backup software running within the guest OS, but the entire 500GB DB would need to be restored. However, with changed block recovery, if only 2GB have changed since the last backup, the VM would simply restore the blocks needed and get the VM restored and running in minutes. Avamar completes this without any background processes occurring after the VM is “recovered,” so there are no resources consumed from VMware ESX after that short process. Without this capability, backup software would have to recover either the full 500GB VMDK, or copy back the 500GB DB files to the VM and attach them.

It’s not just talk, check it out: http://www.youtube.com/watch?v=3YWh07A3Cxg.

In my last post, I walked through what VMware’s Changed Block Tracking (CBT) enables from a VM protection standpoint and how – at a high level – EMC Avamar takes advantage of the API.

Now, let’s dig a little deeper and look at how backup software integrates with VMware’s vStorage API for Data Protection. Remember, it’s this API that enables backup vendors to leverage CBT and it’s the way that EMC Avamar does this that differentiates it from competitive solutions.

The Challenge…
If you recall, CBT provides supporting backup software with the modified data that needs to be protected. Typical backup software has to take the modified data (i.e., the list of blocks) from the CBT log and figure out which files the blocks are part of.

For example, let’s consider an actual example of Exchange running within a VM. Though the application may only change 1 block (4k) within the vmdk, the CBT log refers to an aggregate 64K total change for the vmdk file. The backup application needs to scan it completely even though only 4k was modified because VMware marks the entire 64k block for scan. That 64k block may consist of many different parts of different files from the guest OS perspective.

This may not seem like an issue, but most backup applications need to store this data natively as the VM sees the data. The backup application can then provide file level recovery from an image backup. The backup’s performance is now related to the amount of change within the VM as well as the number of files within the VM, which makes sizing a solution difficult.

The Solution…
What makes Avamar’s “block-based” architecture more efficient is its ability to identify only the unique blocks (e.g., the 4K Exchange block described above) from the CBT log, compress and store them.

Because Avamar scans the CBT log on a block-by-block basis, it doesn’t have to do any translation, meaning that it doesn’t have to figure out which blocks belong with which files. As a result, backup performance scales linearly as the VMDK/change rate goes up – regardless of the number of files within a VM.  Plus, users get the added benefit of file-level recovery from the image-based backup. 

There’s been a lot of talk lately about how Changed Block Tracking (CBT) can improve the efficiency of VMware backup, but what is it all about really? How does CBT differ from deduplication? Are the two technologies complementary? Do I need both?

A quick definition…
Let’s start with a quick definition. CBT is a new VMkernel feature that keeps track of virtual disk block changes, or disk sectors, that have changed. The tracking is done from the virtualization layer – i.e., outside the VM itself – and the changed blocks are transmitted to requesting third-party applications during backup operations.

This has implications for both backup and recovery, as I will explain. But before I do, I should note:

1. 1.  CBT is supported on vSphere 4.0 or later
2. 2.  CBT is accessed by third-party backup applications via VMware vStorage APIs for Data Protection (VADP)
3. 3.  CBT is a replacement for VMware Consolidated Backup (VCB)

How CBT works…
By default, CBT writes at a 64k size. This means that even if you change 4k within the VM, VMware will mark the full 64k block as changed. At backup time, the backup software requests the changed data (consisting of the 64k block that was defined in the VM-ctk.vmdk file) and the backup process begins. You may also decide to include deduplication to further enhance the backup process. Deduplication technologies will now have less data to compare and have the ability to further reduce the data stored by the backup while not impacting performance.

So, if it is an API available to all backup vendors, how has Avamar leveraged it to make it better for the VMware consumer?
The first change is the way Avamar handles the data during the CBT based backup.  CBT by default, as mentioned above, is a reference file of 64k in length containing the list of blocks that have changed within the VMDK.  Avamar uses CBT in an unmodified fashion from the VMware implementation. So, if there are changed blocks within the VMDK, VMware will identify the blocks that need to be scanned by a backup application. From that point, the Avamar deduplication process is performed on those changed blocks listed in the CBT reference file.

Why this is cool – and unique?
This is most beneficial when an organization has to protect larger VMs. For example, if you have a 500GB VM and only 2GB has been modified. With CBT enabled for backup, only the modified 2GB needs to be scanned.  Previously, the complete 500GB file had to be scanned by the backup application to determine the changes.

Regardless of the backup application that you are leveraging, if you can utilize CBT for backup you will reduce your backup window dramatically.  This will reduce the load on the backup infrastructure, and that means backups that were taking hours can now be done within minutes.

Stay tuned for a follow on post that will discuss how EMC backup and recovery solutions leverage this API in a way that revolutionizes backup.