Frequent Disk pool migration

[JeanSeb]

Hi,

Could somebody please explain to me the main disadvantage in having our disk pool being emptied on average 3 times a day to an onsite tape (LTO3) pool ?

Currently 1 migration is scheduled in the morning, 1 at night, and usually an automatic migration kicks in in the middle of the night from the migration threshold setting (95%) which empty the pool completely.

I know we are not following IBM guidelines which are that you should have a disk pool twice as big as your daily backups, but i just don't know which impact it has on our daily operations so that i can justify the expense to management.

Thank you.

 

[Justin]

When migrating from disk to tape you will be:
1. Mounting tapes which could cause resource contention with your direct to tape backups.
2. Performing alot of IO on your disks causing performance degradation for backups to disk.
3. Making many updates to TSM database which will contend for resources with your backups.

In general migration is going to be a resource intensive process which will contend for server resources with your backups. I am not sure why you need a disk pool 2x as big, I would be pretty happy with enough disk pool for 100% of daily backups plus a buffer. say 15-20%?

 

[JeanSeb]

Here is the explanation from IBM on the 2X rule:

"The size of the primary disk pool should be twice the amount of data you expect to write during one day. This ensures that the second day's data can start to be written before the first day's load has finished being offloaded to tape. It allows you the full 24 hours to offload the data from disk if necessary."( http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FQ121000 )

Thank you for the explanations

 

[BBB]

There's no problem with doing it 3 times a day as long as you don't have any performance issues.

Some of my servers 2 it twice a day - first thing in morning, and in the late afternoon. One thing is you should do "ba stg" before doing the migrations, as disk->tape ba stg will cause less tape mounts than tape->tape.

Generally you could consider doing a db backup after each of your 2 daily sets of maintenance operations if you do it that way.

 

[BBB]

Actually, with regards to migrations during your backups due to pools filling up, that is not a problem as such, as long as your backups perform as you need them to. However if you are having performance issues when the automatic migrations are happening, you need to enlarge your disk pools.

 

[n9hmg]

If you're getting automatic migrations, your incoming pool is either too small, or improperly configured.

First thing to look at is whether your incoming data stream has some rather large files - say 1G or more? Pull a tabdelimited "q cont f=d" on it before the morning and evening migrations, and set one to go off if a migration starts during the night. Look at the size distribution. You may find that there is a component of your input stream that is large objects, which could be "seived" on to the NEXT pool - a sequential pool. For instance, I have two clients which each send me a pair of 256GB files every night, and everything else is 1G or less. I set the maxsize on the incoming pool to 1GB, and the big files skip the DISK pool, and only two nodes ever need the sequential pool... no contention, no unexpected migrations, no full DISK pool, and a lot less data to migrate.

Some places are required to run with insufficient resources, and they use a DISK pool as almost a 'buffer" leading to a tape-based pool. Fortunately, they're also usually small enough that there's no real hardship in that. If you're in that situation - I guess there's no problem. If you grow, though, you may well be looking at some rearchitecture.