Anyone using DataDomain as primary storage for VM files?

[is_nt_admins]

We've been wrestling with backup scenarios and at one point someone asked "why not just host your VM's directly on DataDomain?" We tried a couple and they seem to run fine (no real testing at this point other than firing them up).

I'm sure there must be reasons why this is a bad idea but it sure solves the problem of how to move all that backup data across the LAN to the DD...

[thickclouds]

My thought would be it may be performance due to DD being in-line dedupe. Your bottleneck may be I/O performance. Do you have any tests where you can share data to the performance you are getting?

[DougBaer]

I agree that this is a great solution for creating excellent disk I/O bottlenecks and contention.

I have heard of people using NetApp filers as primary storage with dedup enabled -- performance was absolutely abysmal.

What I generally see is that decisions along these lines sound great, but tend to result in performance issues down the line. Unfortunately, users/consumers attribute them to the 'virtualization' and it jeopardizes your entire implementation/project.

If you are considering this solution for lab/test machines, it could be a fine solution, but you may also want to look at Lab Manager. We fired up 55 machines from a 20 GB base image and had an average actual VM size of less than 2 GB due to the way that LM utilizes COW disks rather than full VMDKs for each virtual machine.

My $0.02

(oh, and I do not believe that the Data Domain device is on the ESX HCL... so you'd be unsupported)

[thickclouds]

agree. do you have any data to back this up though? I will need it soon. Also - on the de-dupe, was the performance issue during the de-dupe process or overall on netapp since netapp is not in-line de-dupe?

[DougBaer]

As for the supportability, that one's easy

As for the other, I don't have any data on hand, but I would be surprised to see if anyone has achieved acceptable performance for anything but low loads.

I believe the NetApp was constantly running the de-dupe process. Due to the amount of data churn, I don't think it could keep up -- but I am not 100% sure.

[ehportal]

EMC's Avamar software does de-dupe at the source system meaning the backup data is never sent unless it is unique. Very powerful especially for VMWare and it works with Guest OS, VCB, or console backups. . Different than all the target based de-dupe technologies like Data Domain, Quantum, EMC Disk Libraries, etc.

[Rodos]

EMC's Avamar software does de-dupe at the source system meaning the backup data is never sent unless it is unique. Very powerful especially for VMWare and it works with Guest OS, VCB, or console backups. . Different than all the target based de-dupe technologies like Data Domain, Quantum, EMC Disk Libraries, etc.

Avamar is for backup, with what the Netapp and DD do you can dedupe a live virtual disk which is something quite different. I have not see how this can be done with Avamar yet apart from backup.

[is_nt_admins]

I have heard that the Avamar strategy puts quite a load o the ESX host CPU to accomplish the pre-stream de-dupe.

Anyone have actual experience with this?

[mreeds]

In our experience with the initial backups we didn't see any CPU contention on our ESX host because we chose to deploy agents at each guest rather using VCB. One of the main factors for this was due to the high deduplication rates (95-98%) we were gettting from each of the guests, in fact our initials were averaging 3-4 hours. In comparison, some of our guest backups were averaging 16 hours a day. Even more amazing is that the recurring deduplication times have been averaging in the minutes to complete across a large number of our guest. All I can say is that we've been very satisfied with the performance and even planning Q2 to deploy a number of Avamar nodes to other sites both domestically and internationally.

[is_nt_admins]

Sorry, can you clarify the different deployments and backup times you are comparing here? I'm not following. Sounds very promising though...

Avamar agent deployed inside guests = 3 to 4 hours

Networker(?) client in guests = 16 hours?

Thanks!

[mreeds]

Avamar agent deployed inside guests averaged 3 to 4 hours for the initial backup. Mind you the initial backups will vary based on the size and duplication of the vmdk.

CA Brightstore Agent in virtual machine guests averaged 16 hours to tape without VCB

Again the duplication deltas are now backed up in minutes

[mreeds]

Another thing if you're considering the Avamar solution I would highly recommend contacting the representative we worked with, his name is Ethan Haim from EMC. He is well-informed on the solution and has the best engineers supporting him.

[is_nt_admins]

So, even though the agent is inside the VM you can still do machine level / DR backups and restores? Or just file level?

I thought the Avamar agent was typically installed in the ESX host for machine level DR. Did you try that configuration?

Thanks for all you time.

[mreeds]

Avamar supports both recovery points (file and .vmdk). However, it you're looking to recover an ESX host it wouldn't make sense as you could kick out your images in under 15 minutes via scripts or even from the CD source. Now your point concerning Avamar on the host, I believe your alluding to VMware's VCB that Avamar can use but we elected to go with the guest based agents. One of the main factors was actually cost, since the agents were free it made most sense.

[depping]

you can host you vm's on the DD, but still this would not be a backup because it's you primary storage. So if the DD fails, all is gone.

just use VCB to write the images to the DD.

Duncan

My virtualisation blog:

[mreeds]

So, even though the agent is inside the VM you can still do machine level / DR backups and restores?

Actually, you've brought up a great question and it was, can the guest agent also perform machine (.vmdk) level? No but you do have a number of options, you could use VCB, snapshots or templates. The latter process I prefer as I can easily and quickly deploy specific role based VM's, for instance if were an IIS server that was affected, I would just deploy the new VM from an IIS template containing the Avamar agent. Next I would then perform the file-level/system state restore to the new VM.