Hi Matthew,

I was quite happy when I read your message, because your system (size) 
seems to be very similar to mine with just one difference: your's is 
allready deduplicated.
A lot of numbers really fit my system, so yours gives me a glue, what I 
need to size it, and: it confirms the numbers I calculated whith this 
document (which is highly recommended ro read!):
https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Storage%20Manager/page/Effective%20Planning%20and%20Use%20of%20IBM%20Tivoli%20Storage%20Manager%20V6%20Deduplication

Could you maybe please answer the following questions:
- are you using server side or client side dedup or both (percentage)?
- the 95 TB you stated here: Is this what your TB-lic reports, your 
occupancy (logical_mb) tells you, the storage pool states (in %) or what 
you see on disk? The last one is for sure higher, as it also includes the 
pending volumes for let's say 7 days of reuse dealy. It would be 
interesting, what numbers you have there, because this is the only value 
that counts for sizing.
- how happy are you with the 4TB disks? I also plan to use them, as my 
daily ingest is quite low as yours, so I don't see a problem. Expecially 
with client side dedup I think this won't matter that much...
- do you use client side dedup for DB-(DB2, Oracle, ...) Backups?
- how many objects have you stored in primary- and copypools? (select 
sum(num_files) from occupancy)

In my case I also plan a "cache" filepool with smaller 10k disks for 
backups which need higher performance in writing the data to TSM. Those 
backups will be server side deduped and migrated to the big 4TB disk 
filepool

some information about my system:
~200 TB native data (Occupancy)
daily ingest: ~3,5 TB / day
530.000.000 objects (primary + one copy)

Regards,
Alex




Von:    Matthew McGeary <Matthew.McGeary AT POTASHCORP DOT COM>
An:     ADSM-L AT VM.MARIST DOT EDU, 
Datum:  05.03.2014 16:21
Betreff:        Re: [ADSM-L] [Pool] Using Dedup with TSM : What kind of 
Hardware ?
Gesendet von:   "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



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