Well, we have the deduprequiresbackup flag turned on, so data doesn't get
reclaimed until after the backup to copypool is complete. We also stop
reclamation during our offsite window because locks on bitfiles can and
will mess with either reclamation or backup processes.
We also used three backup processes at a time, as it appears to improve
throughput without being too wasteful in terms of sending only partially
full tapes offsite. Something to consider would be to split your VMWare
environment up into multiple nodes. Ours is one giant node at the moment,
but the plan is to split it up into nodes that represent the VM's that are
critical for DR and then others like non-critical production and dev/test
so that we can (eventually) node-replicate DR VM's only to an offsite
location.
Matthew McGeary
Technical Specialist
PotashCorp - Saskatoon
306.933.8921
From: "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: 03/06/2014 09:21 AM
Subject: Re: [ADSM-L] [Pool] Using Dedup with TSM : What kind of
Hardware ?
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
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
|
