DASH Copy with multiple MA's to one MA?

Last post 08-17-2012, 10:06 AM by PhilippeMorin. 8 replies.
Sort Posts: Previous Next
  • DASH Copy with multiple MA's to one MA?
    Posted: 08-15-2012, 5:08 PM

    One of our customers has a CV9 production site with 3 Media Agents (MAs), each with its own DDB and DL. Now the customer would like to start replicating all backup data to a nearby Disaster Recovery (DR) site. There is dark Fibre in between sites.

    Question is how many MA's would be needed. The contents of all three 3 DDB's combined would be able to fit into 1 DDB and all DL's combined would not reach 96TB. Is one MA at the remote site be sufficient to be the target for all DASH Copies in this case? I'm aware that one MA would not be able to use no more than 50 writers at a time.

    I've not been able to track down any information on a many-to-one DASH Copy setup and what rules and best practices apply, so I'm hoping any of you out there is able to provide some input, perhaps based on experience.

    Thanks in advance!

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-15-2012, 5:15 PM

    Hello Herman,

    This should be no problem at all! We actually had for a long time about 7 different sites (one MA per site) all replicating to our main site on a single MA using DASH copies over 10 mbit links. It worked very well and there was no special configuration needed. We had also enabled the "Optimize for concurrent LAN connections" option on the main site's MA and had set it up to 100 streams max (because some backups were running at the main site while it was receiving the DASH copies... exceeding the 50 streams).

    Phil

     

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-15-2012, 5:32 PM

    Thanks Philippe for the quick response. The thing is that I talked to some different people at CommVault Professional Services in EMEA and strangely enough they all seem to disagree on this subject, and since there is no real documentation that I'm aware of I cannot verify which one is the correct answer. Some feel strongly about only having one-to-one relationships (one DR MA for every Production MA), while others - just like you - have no objection at all with a many-to-one setup.

     

     

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-15-2012, 5:49 PM

    I think the real answer would actually be "it depends"!

    Very often, in case of remote/DR sites, Simpana will be able to go faster than what your network link will support. In that case, have a multiple to one relation is most likely fine.

    If you have a dark fiber then it might be right that the MA will not be able to go as fast as the dark fiber thus providing slower throughput than what 3 MAs at your DR site would provide.

    I think the real question would be: is the throughput of a multiple to one MA copy good enough for your DR requirements? Often, we'll want to have all backups done ASAP to free up our production servers and complete backups within the backup window given to us. Copying the data offsite is another story though. Now, you don't have any production servers involved anymore... only MAs and you might not be using the same link as your enterprise uses which makes it possible to have MAs copy data over the dark fiber until 10-11am or even later in the day. This is an answer only you would know.

    Since adding MAs is pretty easy, you could always start with 1 MA and scale up eventually if needed. Just warn your client of that possibility so he doesn't get back to you later on because you need him to buy new hardware, etc.

    One other thing you could also consider though, is keeping 1 DDB per MA for your DR data and having those DR DDBs hosted by each of your source MAs. This way, you will have 1 dedicated MA per DDB and then all that your DR MA needs to do is receive the unique blocks and write them to the maglib which it should definitely be able to do easily. Obviously, this would require a bit more storage at the DR site as the data would be siloed in 3 DDBs but that might be a better solution in your case.

    Last thing, in case you haven't seen it already, you might be interested by what Stephen from Commvault just posted: http://forum.commvault.com/forums/thread/21218.aspx.

    Phil

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-16-2012, 12:43 AM

    The strategy would be to have backups run at night (backup window is 10 hrs) and perform DASH Copy operations during the day (max. 12 hrs). No overlap so reading and writing on production MAs will not occur at the same time to avoid performance degradation during the backup run.

    Your last suggestion though is seemingly confusing and I could interpret this the wrong way. Is this the scenario in which you would use the production MAs in extended mode ie. hosting 2 DDBs at each one, 1x production DDB + 1x disaster recovery DDB, and the production MAs would process the DASH Copies of one another and use the MA on the remote site for storage purposes only (the remote MA would only have a disk library, no DDB). Then the remote MA could restore data in a DR scenario, as it doesn't need a DDB to do this. Please correct me if I'm misinterpreting you. 

    Thanks pointing me to the document Stephen just wrote, hadn't noticed it yet.

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-16-2012, 10:03 AM

    I worded it poorly but you understood correctly! Wink

    Basically, I had slow disks at my DR site that were hosting both the maglib and DDB. By moving the DDB back to my main site's MA (fast disk), I was able to raise the throughput of my DASH copies since the DDB queries were so much faster.

    According to your schedule, that wouldn't be an issue either since your MA would work at night on backups and during the day for aux copies. If you have enough room, you could possibly even host both DDBs on the same drive since technically, they wouldn't be used at the same time. Though if you can, might as well have dedicated disks for both.

    Phil

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-16-2012, 12:06 PM

    Thanks for clearing that up.  I have a final question regarding this topic: Is there any rule of thumb for calculating how fast DASH Copy operations are (assuming network is not the bottleneck) ie. how many Terabytes/hr can be processed by one receiving Media Agent?

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-16-2012, 1:45 PM

    According to the dedup building block guide, you could reach up to 4TB/hr throughput in an ideal setup. See the following doc for more info:

    http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/dedup_disk/building_block.htm

    I'm assuming this would also apply to DASH copies as the concept is very similar to regular backups.

    One way I've been doing to test different hardware/software setups is to copy ideally about 50 streams (doesn't have to be 50 jobs... as long as you can get enough streams) which represent at least 1TB of data.

    Copy it once to your DR site. Then, mark all the jobs as recopy and run the aux copy again. This will remove the network link as a variable and should, as far as I'm concerned, give you the best output possible using whatever hardware/software configuration you've setup. This can be a lenghty process but is an excellent way to test what setup will work best in your environment.

    Phil

  • Re: DASH Copy with multiple MA's to one MA?
    Posted: 08-17-2012, 10:06 AM

    To give you a rough idea, I'm currently thottling aux copy over our dark fiber at 500mbit/s and after about 1 hour, I've copied 1.67TB of data, 310GB actually transfered over the network. Simpana shows a speed of about 1550GB/hr. It is using 25 streams at the moment as all remaining streams for that storage policy have completed by now.

    At this point, I think I could go even faster but 300GB in 1 hour over the network is close to the 500mbit/s limit I've set.

    Phil

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy