-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 19 Mar 1998, Allen S. Rout wrote:
On Thu, 19 Mar 1998, Allen S. Rout wrote:
> Greetings, all.
>
> I'm getting ready to define a set of disk storage volumes for my ADSM setup,
> with the intent that I would be using them as a more-or-less "landing pad";
> i.e. they can accept data more efficiently than the optical or tape, and I can
> run more simultaneous sessions against them, but I don't really plan to keep
> data on them for long: my nightly incrementals might regularly exceed the
> size of the disk pool.
I have implemented the same solution, and find it to be the best performance
wise. Not only can disks accept data more efficiently, but more simultaneous
sessions in most shops I've seen is a must.
> Someone here noted today "but that might cause migration, which I would want
> to avoid during the backup window". Is there a reason to avoid that, _other_
> than simply losing access to the migrating volume during the migration period?
Migration during a backup is not a horrible thing as long as it is controlled
and "massaged". If migration is forced to kick off, chances are that it
won't go fast enough, and the disk-pool will fill up. That is the situation
to be avioded. With 2 simple admin schedules, it is fairly easy to control
the flow of the data. Example:
Disk Pool NT_DISK_POOL is normally set to %high 90 and %low 70 and is a total
of 50GB in size.
According to your client backups schedules, and armed with the
knowledge that your regular incrementals run more than 50GB,
schedule an admin job to run about 1/2 or 2/3's of the way
through your backup window. The admin schedule is called
FLUSH_NTPOOL and runs the command;
upd stg NT_DISK_POOL high=0 low=0
This will affectively start controlled migration prior to pool
space becoming a crisis. Make sure tape drives are available
for the migrating data. Observing how long it takes to migrate
data from disk to tape, leave the migration threshold at 0,0
until all the data has been moved, and then with your second
admin schedule, called RESET_NTPOOL, run the command;
upd stg NT_DISK_POOL high=90 low=70
to get the disk pool ready for the next nights backups.
For data safety's sake, I try to get the data off disk (faster but less
stable media) to tape (sequential, slower but more stable media) as soon
as possible to avoid a disk failure causing me a data loss.
> Is this a dumb idea for some other reason? I plan to have rather a lot of
> fairly small spindles for disk pool: I won't lose a lot if a few of them go
> into migration during a session, and I can migrate _all_ the data off
> gradually during the day, so I can have a clean slate for the next night.
>
> Any input, or references to Fine Manuals that I might Read, would be welcome.
>
>
> -Allen S. Rout
>
Hope that helps,
Sean
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o
o 0
0 Sean P. Garvey, System Engineer phone: (540) 370-4184 o
o Phaedo Consulting, Inc. 0
0 www.phaedo.com email: sgarvey AT phaedo DOT
com o
o 0
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o
|
