A lot of the earlier discussions on the list were related to the IBM
3494 VTL, which was designed for handling small chunks of seldom-used
sequential data. It is prone to performance issues when handling LARGE
chunks of sequential data, so it is not a good fit for backup products
like TSM, which are designed to FILL a volume, whether virtual or real.
The 3494 VTL uses a combination of disk and tape, whereas the newer
VTL's are all disk - a very different architecture. And so these newer
types of VTL's will have different issues.
When considering performance issues, know thine own hardware
architecture.
Now, back to the original point of this thread, sizing a library (real
or virtual):
The biggest mistake people make when sizing a TSM library is in just
summing up the total amount of data they will back up.
Not only do you need additional space in the library for your inactive
versions, you must allow for the fact that your volumes WILL NOT BE
FULL. Data is constantly expiring, and on a given day a significant
number of your volumes will be partially full, but below your
reclamation threshold.
My rule(s) of thumb:
1.For file server backups, start with the amount of data you will back
up. Add .05 (5 per cent) multiplied by the number of VERSIONS you will
keep. (IBM recommends 10% as a starting point, but I find the rate of
change on most file servers to be far less than that).
2.For large data bases, (Oracle, Exchange, etc.) start with the amount
of data you will back up. Multiply by the number of versions you will
keep.
3.Add some additional tapes for your DB backups and scratch pool.
4.Assume that you will get at most a compression ratio of 1.5.
5.Assume that your tapes will be, on average 60% full.
6.Now that you have a total, remember that most data centers experience
a rate of growth in data storage of 50-100% PER YEAR. Whatever you buy
for TSM, it better be expandable.
Wanda Prather
"I/O, I/O, It's all about I/O" -(me)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, November 30, 2004 10:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: size of active vs. inactive?
On Nov 30, 2004, at 9:58 AM, Johnson, Milton wrote:
> ...Needless to say, I disagree with the statement that TSM doesn't
> appear
> to be a good fit for a VTL. Remember a VTL is just a library that can
> mount/unmount a tape in less than one second and read/write to the
tape
> at disk speeds. Why wouldn't TSM work well with a library on
> steroids? ...
Thanks for sharing your experience with VTL in a TSM environment:
it's helpful to have the perspective of experience.
As we've seen in past tape vs. disk discussions, though, don't regard
"disk speed" as some kind of ultimate data processing I/O attainment:
high performance tape technologies streaming to sequential media can
in many cases out-pace disk throughput. It is in mounting and tape
positioning that tape is a poor performer relative to disk, where one
can wait a minute or more before I/O can proceed. That's were VTL
shines.
Richard Sims
|
