I've tried something similar (AIX server 3.1.1.5) on SSA disks.
It did not work. In fact, I would say that it was disastrous.
I'd considered doing something like this for a couple of years,
and finally "just did it" and paid in pain. For one thing, the
combination of MAXSCRATCH and MAXCAP with multiple storage pools
is very tricky. If you have a total of 50GB of disk, with 5
storage pools, you might think to set MAXCAP at 1GB and
MAXSCRATCH at 50. But which storage pool will get the MAXSCRATCH
of 50? If you set all five of your storage pools to
MAXSCRATCH=50, and your devclass MAXCAP=1GB, you will end up in
the situation where *each* of the five storage pools will attempt
to create 50 1GB volumes. At some point, when your filesystem is
full, ADSM will complain that your server is out of storage
space, because it has gone and created 250 partially full volumes
in each of your five storage pools.
I never quite understood or investigated why, but
backups/archives would fail at that stage, rather than simply
move on the the pool defined by NEXTSTGPOOL. I was too frustrated
by the experience to bother.
I had wanted to implement something exactly as you described. I
had a bunch of disk space for my disk pools, and I needed to have
multiple disk pools so that they could migrate to different pools
(if you search the depths of the archives, there is a thread from
'98 or so regarding one disk pool migrating to multiple tape
pools). All we really want is one big landing pad for all
incoming data. We don't want to have to micromanage that set of
disks. It's all there, and it's all available, but the way ADSM
is currently structure, you must preallocate that storage space
to one pool or another.
With my experience, I would recommend against what you are trying
to do. Go with regular disk pools.
CAVEAT: We are on 3.1.1.5 of the AIX server--yes it's down rev,
it also works; we're not in the QA business :-). I can't speak to
whether these issues are addressed/fixed in any newer releases of
{AD,T}SM.
-- Tom
Thomas A. La Porte
DreamWorks SKG
tlaporte AT dreamworks DOT com
On Wed, 2 Aug 2000 asr AT ufl DOT edu wrote:
>Greetings, all.
>
>I'm kicking around a near-total reconstruction of my disk pools, as we're
>getting some new DASD in before too long, and I'll therefore have an "empty
>tile" to play with. I wanted to trot out the plan I was considering, and let
>some other clue poke holes in it. :)
>
>
>Currently, we've got ~54G of primary DISK pools. These are partitioned in a
>fairly copplex way, with the aim of maximizing the number of spindles I can
>hand to my stgpools, regardless of their size.
>
>So, a ~4G stgpool gets two 1.7G volumes, each on a different spindle. My
>biggest stgpool (18G) has four 4G and a 1.7G, each on different spindles.
>
>And so on.
>
>This is useful so long as I am correct in my incremetal-size estimations, but
>I have to plan each stgpool for the "reasonable maxiimum" of an incremental,
>which means that for some I have, say, 4G allocated but almost never use more
>than 2.
>
>So much for the sad story. Now to what I plan to do about it:
>
>
>When I get my new disk in, I plan to make a single RAID5 volume, and make a
>directory on it for a FILE devclass. I'll permit something large like 50
>mounts on that class, and I'll make the volume size somewhere around 250M.
>
>I'll define stgpools against this devclass, and I'll control their peak size
>with MAXSCRATCH directives. My 2G stgpool will have maxscratch=8, and so on.
>
>This will give me most of the speed of my current solution (minus the RAID
>overhead) and permit the stgpools to grow and shrink as demand varies.
>
>I could even generate a second stgpool on the same AIX volume, for my dinky,
>numerous workstation backups, with a volume size of ca. 100M, and colocate it.
>
>
>
>Thoughts? Is the raid5 on the stgpools a _drastic_ performance hit? (my
>bottleneck is currently the database, and then the network. Disk speed is a
>distant third)
>
>
>- Allen S. Rout
>
|
