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
|
