ADSM-L

Re: [ADSM-L] VTL and TSM - Hyper Reclamation ????

2008-06-03 21:59:06
Subject: Re: [ADSM-L] VTL and TSM - Hyper Reclamation ????
From: Wanda Prather <wprather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 3 Jun 2008 21:57:52 -0400
Well,  I set up a disk-only backup environment for a customer using an
external disk array and TSM sequential disk volumes as the primary backup
pool - pretty much the same thing.  After some playing around, we settled on
100GB volumes with a  25% reclaim threshold.  Having more smaller volumes
let us reclaim volumes more frequently, and keep the utilization of the disk
very high.

Reclamation was pretty much invisible, since there was no waiting for
mountpoints; and it just didn't make sense to spend the money on an all-disk
backup system and leave a whole lot of the space empty waiting for
reclamation.  If you think about it, do you want more than 25% of that VTL
disk being dead space?

So I'm  in agreement about the reclaim threshold.  Whether a smaller VTL is
better, is a different question:

1) I believe you should never buy any storage hardware that can't expand,
unless you are going to be happy throwing it away in 3 years

2) Check all the vendors specs on throughput rates and how the VTL is
constructed.  I've seen many that have only 1 wimpy head/controller, and
unimpressive throughput rates.  And many of the vendors published throughput
rates are only sustainable if you have multiple I/O operations going on at
once, i.e., more than 1 backup/restore operation.

Suppose you have your backups going to a fast fibre disk pool, then
migrating out to the VTL instead of the current tape.  Speed/throughput of
the VTL may not be too important.

But suppose you need to do a restore of a single 20GB data base backup - how
fast can you get that back from the VTL?  Would it be faster coming straight
from LTO tape at 200MB/sec?  And do you care?

3) In many VTL implementations, compression is an option, so that you can
stuff more data in the same space.  In most of those implementations, the
compression is done in the software, and slows throughput down.  If extra
processors are offered to boost compression efficiency, buy them.

4) Same questions with vendor dedup - is it done in line, and if so does it
slow down throughput?

5) The Yuk factor:  The VTL is is a disk array with some software in front.
At some point, for some operation, you'll hit the limitations of the
hardware underneath.  If somebody offered you the same hardware components
marketed as a disk array, not a VTL, would you say "Yuk"?

Wanda


On Tue, Jun 3, 2008 at 9:08 PM, Richard Rhodes <rrhodes AT firstenergycorp DOT 
com>
wrote:

> We are investigating VTL's as a replacement for our 3494 libraries.
> A vendor was describing their sizing calculations and
> assumptions.  One of their assumptions BLEW US AWAY!!  The
> vendor recommended that reclamation  be done
> on VTL volumes at a 20-30% Reclamation Percentage.  YES,
> that's right, they recommend that a volume get reclaimed
> when only 20-30% of the data is expired.  They claim that
> this is possible due to the efficiencies and speed
> of the VTL, and thus allow us to run at a much higher
> average utilization.  The argument is that with a
> higher average utilization we can purchase less disk, and
> thus a less expensive VTL.
>
> Currently, for our tapes, we reclaim at 55-60%.
>
> Q)  Has anyone every heard of performing
> reclamation at a percentage as low as 20-30%?
>
> Q)  Is anyone with a VTL actually performing
> reclamation at 20-30%?
>
> Thanks!
>
> Rick
>
>
> -----------------------------------------
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
> the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error
> and that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete
> the original message.
>