Hi, 

We run dedup stgpools to a VNX of some calibre.  We're on 6.3.4.300 code
on Solaris 10.  Deduprequiresbackup=no and we use source-side client
dedup.  We also struggled with getting good performance on our backup
stgpools in an earlier architecture.  Aside from the issue of backing up
deduped stgpools (which is generally much slower than non-dedup), the big
take-away from our experience was two-fold:

1.  Use large volumes... 50GB minimum (you do that, good)
2.  Spread out devclass directories for the file pool to as many
directories (and LUNS) as possible.  We currently have 8 directories.  In
our new environment, we'll have up to 16.  In this way, you'll definitely
start utilizing your storage HBA's and you'll see disk utilization on your
V7K go up.  Still shouldn't break much of a sweat though.

Not sure what level of code you're on or what platform, but make sure it's
patched and up-to-date. You also don't state if you've broken out your
devices like #2 above.  Check that, might that be an issue?  How much data
are you trying to spin to your LTO4's?  We do about 2TB over six hours
which isn't too bad considering we're backing up dedup data.  Plus our
backend SAN is more likely our bottle neck.

In contrast, we have a non-dedup pool that only has ONE underlying
directory.  We migrate that to LTO5 and simultaneously write to a backup
stgpool... man is that stgpool migration a DOG.  It takes literally, 12+
hours to migrate 2TB's of data.  Part of that is because of the way
migration works in 6.3.4.300 (large nodes migrate data first), but the
underlying FS can only push about 50-40MB/sec no matter how many migration
processes we throw at it.

SF



On 9/17/14 9:47 AM, "Matthew McGeary" <Matthew.McGeary AT POTASHCORP DOT COM>
wrote:

>Hello All,
>
>We've been struggling with somewhat anemic backup performance from our
>dedup storage pools to LTO4 tape over the past year or so.  Data is
>ingested from clients and lands directly into our dedup pool, but doesn't
>get deduplicated until the offsite operation is complete.
>(deduprequiresbackup=yes)  Our dedup pool is comprised of 50GB volumes,
>residing on a V7000 pool of NL-SAS drives.  The drives don't appear taxed
>(utilization is consistently in the 30-40% range) but average throughput
>from the storage pool to tape is only 100-100 MB/s.  This is starting to
>present challenges for meeting the offsite window and I am stumped as to
>how I might improve performance.
>
>The TSM server is running on AIX and has four 8Gb paths to the storage,
>running sddpcm.  Mountpoints containing the data are mounted rbrw and are
>JFS+ volumes.  Our tape drives are running off of two dedicated 4Gb HBAs
>and our backup DB throughput is excellent, averaging 350-400 MB/s.
>
>For those of you that are running TSM dedup, how are you managing your
>offsiting process?  Are you using a random devclass pool as a 'landing
>zone' for backup/offsite operations before migration to the dedup stg? Are
>there tuning parameters that you have tweaked that have shown improvement
>in FILE devclass stg pools to LTO devices?
>
>Any and all tips would be appreciated.  I've been through the parameters
>listed in the perf guide and have allocated large memory pages to the TSM
>server but I haven't seen much, if any, improvement.
>
>Thanks!
>
>Matthew McGeary
>Technical Specialist
>PotashCorp - Saskatoon
>306.933.8921