1. IT DEPENDS. (You KNEW I was going to say that, didn't you?!?)
2. There is no "right" answer (so you will probably be getting LOTS of
opinions back about this question ;>).
3. If you only have a few clients to back up, it just doesn't matter.
4. The purpose of your disk pool is to act as a "buffer", so that you can
have many more clients backing up concurrently than you have tape drives.
As long as your disk pool is large enough so that your clients can back up
without waiting for a tape, you have an "adequate" configuration.
5. The rule of thumb is that you want to have enough space in your disk
pool to hold at least one day's backups. That way if there is a tape
problem (more common than disk problems), you will have time to fix it when
you arrive in the morning without any backups failing. Now you have a
"better" configuration.
6. After that, what you do with your disk pool is work on increasing
throughput/performance, ie. the "best" combination of function and
throughput. And it depends a lot on your client mix and a lot on your
hardware.
IF you have "n" clients backing up concurrently, and you have at least "n"
disk pool volumes, TSM will start "n" I/O's in parallel to the different
disk pool volumes. So to take advantage of MANY volumes, you have to have
MANY concurrent backups in progress. But, if you are writing to 1 spindle
of disk with a zillion tiny diskpool volumes, you will get more thrashing of
the disk than throughput.
So, if writing to a raw (not RAID) spindle, you proably want 2-3 diskpool
volumes per spindle.
On the other hand, lots of people use some type of RAID these days. The
disk pool I/O is sequential; some people have reported good results with
striping across multiple physical spindles. And if you are writing to a
Shark with gobs of cache memory in front of it, that buffers the effect of
the disk head movement and you may not be able to come up with many
configurations where you can measure the difference between a "few" and
"many" disk pool volumes.
6. NONE of that is really going to affect your throughput to LTO.
- no matter how many (or few) diskpool volumes you have, if they are full
of lots of itty bitty files (actually aggregates of files), remember that
TSM has to update the data base each time it moves one. It's hard to stream
enough data to the tape during this process to get great throughput numbers.
- no matter how many (or few) diskpool volumes you have, if they contain a
few BIG files, TSM has a better chance of pushing the data to LTO fast,
because it doesn't have to make data base updates as it goes.
- many people report better thoroughput on BIG files when writing direct
from the client to tape, not the disk pool.
This should give people LOTS of targets to respond to!!
Wanda Prather
Johns Hopkins University Applied Physics Laboratory
443-778-8769
"Intelligence has much less practical application than you'd think" -
Dilbert/Scott Adams
-----Original Message-----
From: Mitch Sako [mailto:msako AT CADENCE DOT COM]
Sent: Thursday, August 21, 2003 8:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Disk Storage Volume Pool Sizing
Simple Question:
In a disk storage pool which migrates to LTO tape, what is the optimal size
for
the volumes to be?
Let's assume the following:
Fast network connection(s)
1-to-many clients (depending on the time of day)
1000GB of fast local storage (SAN, SCSI, Fiber, etc.)
UNIX/Linux/AIX/Solaris (not Win32) server
1000x1GB volumes?
500x2GB volumes?
100x10GB volumes?
10x100GB volumes?
1x1000GB volume?
I have done extensive testing in the lab with this but have not really
reached
any consistent conclusions. Does it matter?
Mitch
|
