Many backup sessions can access a single disk storage pool all at once.
You will want to control how many, though, for the obvious performance
concerns that you already have. Too many backup sessions at once, and
things will get too slow.

This is basically controlled through how you set up the automated
scheduler on your server. You can make the backup window for your
automatic client backups longer. For our client nodes, which are mostly
desktop workstations used by a single human who sits in front of it, we
can spread out backups for the entire time that their human owners are
not at work. Therefore, I have it set to be all night, 5PM to 8AM. You
can increase SET RANDOMIZE to as high as 50%, which controls how far the
server will spread out the start of server-initiated backups within that
time window. This causes backup sessions to start between 5PM and
12:30AM on my system. The effect of all of this is to spread out the
rate of incoming data from clients doing backup over the maximum amount
of time, thereby allowing you to tune and control the performance of
your disks, tapes, and network better.

Migration processes will not tie themselves to a particular physical or
logical disk volume. It's going to be random. However, having said that,
I would say you're on the right track - it would be a good rule of thumb
NOT to have more migration processes than physical disk volumes in a
storage pool. Just use standard operating system tuning tools to see if
you have disk drive contention or not.

Also don't ignore the possibility that you have a bottleneck on the tape
end - there could be SCSI bus contention getting the data out to your
tape drives. Two Super DLT drives can just about saturate one SCSI
channel. If you can't increase the number of SCSI adapters, then you
might want to limit the number of migration processes. Experimentation
is the only way to really find out what's best in this area, and you may
find out that accepting a degree of contention in some area results in
the fastest net migration time for a given amount of data.

If you use it, do not ignore the effects of collocation as you try to
figure this out. Collocation with more than just a few client nodes can
DRASTICALLY increase migration time, as each client node's tape is
rotated in and out of the drives. This would be a case where more
migration processes might really help, by still utilizing the disk
bandwidth you've got while tapes were rewinding and unloading and being
switched by the robot.

RAID5 disk storage is fine for Storage Pool volumes, and for the
Recovery Log. It's just that it is less than optimal for the Database.
(This has been discussed at length on this list.) So if you've got some
amount of plain ("JBOD") ordinary disks, put your Database there and the
rest should be happy in your RAID5 box.

You are probably doing fine with fewer, larger logical "volumes",
because that allows the RAID5 box's own logic to optimize things over
the multiple physical disks it contains. (That's all that goodness that
the RAID sales people love to tell you about.) I would only split it up
if it somehow made it easier for you to manage. For instance, I always
keep my Recovery Log in two halves, because that allows me to move it
around on the fly without taking the server down. Arbitrarily splitting
up the logical volumes within the RAID5 box cannot help, and might hurt,
performance.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====



On Sat, 26 Jul 2003, i love tsm wrote:

>Hi All
>
>A couple of questions about the way in which disk storage pools are used. I
>had a quick look in the manuals but couldn't find an answer
>
>basically, i want to know if more than once backup session can access a disk
>pool volume at a time
>
>also if i have three disk pool volumes and 4 migrations processes running
>will i get contention on disk with two of the migration processes fighting
>over a disk volume.
>
>i have 270 GB (RAID5 which i know is not the best but cannot be changed at
>the moment), which is presented as 1 LUN,  of SAN attached disk storage pool
>at the moment. This is split into 2 x 100Gb and 1 x 70Gb storage pool
>volumes. I'm thinking I should have more smaller disk volumes instead.
>comments??
>
>TIA
>
>_________________________________________________________________
>Sign-up for a FREE BT Broadband connection today!
>http://www.msn.co.uk/specials/btbroadband
>