Re: [ADSM-L] [Pool] Using Dedup with TSM : What kind of Hardware ?

We have been unable to successfully do backup stgpool from a deduped primary 
pool to tape.
It's sooooo slow, can't get 4 TB backed up in 24 hours.

Haven't been able to figure out whether it's because identify duplicates and 
reclaim stgpool are running at the same time (locks?) or because it's all 1 
filespace (VMware) so can only do 1 stream, or because of throughput issues in 
the DB.  Can't tell why it's sooooo slow.
 
Solution is currently to backup to a (random) disk pool of 5 TB, then backup 
stgpool, then migrate to the dedup (file) disk pool.

How do you manage the backup stgpool?  Multiple processes?

Thanks!
Wanda

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Matthew McGeary
Sent: Wednesday, March 05, 2014 10:19 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] [Pool] Using Dedup with TSM : What kind of Hardware ?

I know this is a bit of a necro-reply, but I just saw this question and thought 
I'd discuss our config

- Total data in dedup pools (Native/Deduped) We have a single deduplicated 
primary storage pool that is currently in the ~95 TB range.  Our copypool 
resides on LTO4 and occupies ~228TB
- Total data ingested daily (Native, server side/Deduped, client side) Our 
90-day daily average intake is 3.3 TB.  It can peak up to 8TB during our 
monthly cold backup of production Oracle data.
- Size of your DB
The DB fluctuates between 1.7 and 2TB presently, depending on reorg state.
- Do you backup your STG to Tape ?
Yes, as mentioned above.
- Disk subsystem for DB ?
V7000 SSD in RAID5. 
- Disk subsystem for Active Log ?
Our active logs are on a tiering pool and archive logs are on NL-SAS
- Opinion on that disk subsystem ? Enough, too few ?

A little more detail on our disk configuration:
1 V7000 with 4 drawers.  One is a mix of SSD and 15k SAS.  Another is pure SSD 
and the remaining two are 3TB NL-SAS.
1 DCS3700 populated with 36 3TB NL-SAS and 24 4TB NL-SAS.
Our primary storage resides in an extent pool that spans the DCS3700 NL-SAS and 
the V7000 NL-SAS.  Both use RAID6.
The TSM server itself lives on a P740 and is configured to use all available 
resources on that system, so 16 POWER7 cores at 3.6 GHz and 120 GB of RAM.  We 
use VIOS for NPIV storage and networking, which takes up the remainder of the 
RAM and steals CPU cycles when necessary.

Overall this system has managed data intake growth in excess of 50% 
year-over-year and database growth of 400%  The DCS3700 in particular is a
champ: great value for money.  We originally went with V7000 because it was 
pitched to us with compression for the storage pools in mind. 
Unfortunately, this was a bad fit due to the inherent (but poorly documented at 
the time) performance penalties that the IBM compression solution has for 
sequential workloads.  Other than this shortcoming, the
v7000 has been a good fit for TSM and has handled everything we've thrown at it.

Matthew McGeary
Technical Specialist
PotashCorp - Saskatoon
306.933.8921



From:   Erwann Simon <erwann.simon AT FREE DOT FR>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   01/28/2014 11:09 PM
Subject:        [ADSM-L] [Pool] Using Dedup with TSM : What kind of 
Hardware ?
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Hi,

I'm wondering what kind of hardware you are using if you're using TSM Dedup 
facilities (client and/or server) ?

Can you fill the following fields :
- Total data in dedup pools (Native/Deduped)
- Total data ingested daily (Native, server side/Deduped, client side)
- Size of your DB
- Do you backup your STG to Tape ?
- Disk subsystem for DB ?
- Disk subsystem for Active Log ?
- Opinion on that disk subsystem ? Enough, too few ?

Here's an example from one of my customers
- Total data in dedup pools (Native/Deduped) : a bit less than 10 TB 
(logical_mb), 21,5 TB (reporting_mb)
- Total data ingested daily (Native, server side/Deduped, client side) : 1 TB 
(native), no client side
- Size of your DB : 220 GB
- Do you backup your STG to Tape ? Yes, to LTO4
- Disk subsystem for DB ? 2*RAID1 15krpm (4 internal disks), 2 volumes, 2 
directories
- Disk subsystem for Active Log ? 1*RAID1 15krpm (2 internal disks)
- Opinion on that disk subsystem ? Disk for DB are 100% busy most of the time 
(expire inventory, reclaim stg...) I think adding two more disks (one
RAID1) to the DB would be really effective.

Your turn now ! 

Thanks a lot.
--
Best regards / Cordialement / مع تحياتي
Erwann SIMON