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.mcge...@potashcorp.com> An: ADSM-L@VM.MARIST.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@VM.MARIST.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.si...@free.fr> To: ADSM-L@VM.MARIST.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@VM.MARIST.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