DPM Insider

Welcome to my world of DPM, Study of Management and Films.

Snapshot Provider Considerations while backing up a CSV Cluster

Snapshot Provider Considerations while backing up a CSV Cluster

  • Comments 3
  • Likes

DPM traditionally supports software snapshots (Volsnap à which is available in the Windows OS by default). In DPM 2010, for protection of CSV Clusters, we strongly recommend the usage of hardware snapshots over software snapshots. Note that the recommendation applies to Production servers only. On the DPM side, only software snapshots are supported.

 

Now why do we recommend hardware snapshots for CSV Clusters?

To understand this we first need to understand the basic backup mechanism of CSV clusters.

 

A common Cluster Shared Volume (CSV) deployment would have the VHDs of the virtual machines on a CSV, with virtual machines distributed across the nodes of the cluster. Each virtual machine would have direct I/O access to its respective VHD on the CSV, irrespective of its location in the cluster. Now when a scheduled backup is triggered by the backup agent, the CSV on which the VHD of the VMs lie, need to be brought local to the node where the VM presently resides. The Backup agent triggers this CSV volume movement, takes the snapshot and starts the backup.

 

This is where the difference in software and hardware providers kicks in. When the backup agent takes a backup using a software snapshot, the CSV volume remains pinned to a single node not only for the entire duration of the snapshot but also for the duration of the actual backup. There is a two-fold impact on performance because of this behavior. Firstly, as Copy on Write behavior is invoked by Volsnap, Direct IO (which greatly improves performance on CSV) is impacted for the entire duration of the backup. Given that for a fully loaded cluster, backup would continuously happen on each node, you will hardly get any Direct I/O. Secondly, because of the CSV volume being pinned to a node for the entire duration of the backup, the number of VMs (on the same CSV but different nodes) that can be backed up in parallel gets severely impaired and all backups are serial. This again impacts the backup performance.

 

Hardware snapshots on the other hand, are ideal for the CSV environment. They allow the CSV to resume direct I/O mode as soon as the hardware snapshot has been taken. This duration is typically very short, about 2 minutes. As a result more VMs can be backed up in parallel with hardware snapshots than software snapshots.

 

The question that I typically get at this point is this - "Let’s assume the VMs on the same CSV are doing something disk intensive stuff. During the snapshot (even it is hardware based) there will be ~2 minutes, while the disk I/O to the CSV volume from all VMs running on node other than the one doing the backup go through the network (Redirected mode) to be written by the coordinator node (the node running the actual backup). I think these VMs can easily generate enough data that can overload the coordinator node NIC and the node itself. What should I do?"

 

The effect of redirected I/O during backup is one of the factors a customer needs to consider when deciding how many/how large his CSV’s should be. The redirected I/O will flow over a network dedicated to CSV, and we recommend that this link be at least GigE.  As pointed out, the use of H/W snapshots will greatly mitigate this issue. Using 5+ Gig links for CSV traffic would mitigate this further for both System provider and H/W provider snapshots.

 

Comments
  • To check if I understand you correctly:

    * Install VSS hardware providers from your storage vendor on each Hyper-V cluster node

    The DPM2010 server needs to have access to the storage system via FC or iSCSI (????)

    * There is no need to run the DSConfig.ps1 script to create the serialization XML file for DPM2010

    * When creating a recovery point for multiple child partitions on a Hyper-V R2 cluster with CSV, a hardware snapshot is created for each VM (including configuration, VHD's, Hyper-V snapshots etc).

    * The hardware snapshots are NOT auto-imported back to the cluster (else a conflict would occur with the disk signatures in the cluster)

    * The DPM2010 maintains the hardware snapshots as if they were software shadowcopies under ..\dpm\volumes

    Are these hardware snapshots also deleted after after the retention time has passed?

    Regards,

    Hans Vredevoort

  • My CSV hardware doesn't yet support snapshots, althought I'm told that feature is coming.

    Is there a way I can make DPM 2010 aware of this and set the CSV backups to run in serial?

    At the moment the snapshots all try to start at once and I get errors as some fail due to the others being in progress.

    I would like to keep them in the same protection group if possible.

    Thanks,

    Jonathon

  • Hi Asim,

    Can we use this Hardware Snapshot provider for Exchange 2010 backup????

    best regards,

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment