ADSM-L

Re: ADSM dasd pool migration

1998-09-09 16:29:53
Subject: Re: ADSM dasd pool migration
From: Anthony Jones <Jones4A AT KOCHIND DOT COM>
Date: Wed, 9 Sep 1998 15:29:53 -0500
I would suggest lowering you thresholds, this would give your tapes more
time to keep space available.   I would also look into trying to empty your
diskpool during off peak times.  I setup a separate admin schedule to
migrate the rest of my diskpool down to 0 when the server is least busy.  If
you have a fast enough server the load of migrating and client backup
sessions should not be that great.

--- Anthony Jones
    Koch Industries, Inc.
    Koch Industries, Inc.


> -----Original Message-----
> From: Jeff Connor [SMTP:connorj AT NIMO DOT COM]
> Sent: Wednesday, September 09, 1998 8:43 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: ADSM dasd pool migration
>
> Add mine too.  This is one of my biggest pet peeves.. I have my disk pool
> thresholds at hi=80 lo=65 on a 70GB disk pool.  Migration is to four 3590
> tape drives in an STK Silo. Backups fill my disk pool faster than it can
> migrate to tape sometimes reaching 100% utilization.  Sad part is when
> migration catches up, and disk pool utilization drops below my high
> threshold of 80%, many backup sessions remain in mediaw status, some for
> hours. Even when pool utilization falls below the low value of 65% there
> always seems to be at least one, of the four max migrations processes,
> that
> keeps running and doesn't end until the pool is nearly or completely
> empty.
> My temporary work around was to define a second tape pool and
> automatically
> issue an admin command to update the nextpool value for the disk pool
> swapping tape pools every half hour daily from 23:00 to 7:00am. This
> seemed
> to work fairly well although I had some intermittent server hangs that I
> suspected might be caused by my frequent changes to the migration
> hierachy.
> My long term solution is to add 4 more 3590 tape drives to the silo and
> double the size of my disk pool which I finally got management to
> approve..
> It would be nice if the ADSM server could periodically re-check disk pool
> utilization and re-route the backup sessions to disk if pool utilization
> has dropped. It should stop sending sessions directly to tape that could
> have fit on disk..
>
>
> Jeff
>
>
>
>
>
> Dwight Cook <decook AT AMOCO DOT COM> on 09/08/98 04:58:05 PM
>
> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> To:   ADSM-L AT VM.MARIST DOT EDU
> cc:    (bcc: Jeffrey P Connor/IT/NMPC)
> Subject:  Re: ADSM dasd pool migration
>
>
>
>
>      Nice to see I'm not alone...
>      But just wait until you have all 50 clients in a media wait and your
>      tape drives manage to clear the diskpool and you are watching about
>      40-ish clients still in media wait with an EMPTY DISK POOL !
>      Yes, I've had disk pools fill and all the inbound sessions call for
>      tape mounts, then the migration processes clear the diskpool and
> there
>      ain't no way to point those specific sessions back over to the
>      diskpool.
>      I even tried pointing my tapepool's "nextpool" over to my diskpool
>      (yes, I removed diskpool's next of tapepool first) in hopes that when
>      the next tape swap took place that the other jobs waiting on mounts
>      might recalculate their needs and see they could go to a nice empty
>      diskpool BUT NO!
>
>      anyway, just adding my 2 cents worth
>
>      later,
>            Dwight
>
>
> ______________________________ Reply Separator
> _________________________________
> Subject: ADSM dasd pool migration
> Author:  jack.revette (jack.revette AT dowcorning DOT com) at unix,mime
> Date:    9/8/98 2:20 PM
>
>
> Had 10 GB dasd storage pool backed up by a 3590 tape storage pool (one
> thread, migration threshholds set at 0% - 70%).  After some recent
> improvements in the server (AIX Server Version 3, Release 1, Level 1.5)
> and the network, believe I encountered for the first time a situation in
> which I could fill the dasd storage pool faster than I could migrate it.
> I have 3 tape drives and 50+ clients.  So if I had 25 clients active
> backing up data to the disk storage pool, when it filled, one tape drive
> was in use for a migration, and the other two would be allocated for
> client backups (ADSM was 'smart' (??) enough to recognize that there was
> no room on disk, so let's go to the next pool - tape).  The other 23
> clients went into media wait status waiting for a mount point.  When the
> migration processed reached an end of volume condition, one of the other
> 23 clients in a media wait status 'stole' the migration mount point,
> making the situation worse rather than better. (i.e. if migration
> maintains priority, other 23 clients will be able to backup to disk,
> as/once migration completes).
> I've opened an ETR (33873,422) with IBM, and the response is that
> backups have priority over migration and this cannot be changed.  I've
> been requested to submit a product Design Change Request.  I'm very
> willing to do this, but just wanted to pass this by the users and
> developers on the listserv to make sure I'm on the right track.
> (By the way, I've put some circumventions in place - dasd storage pool
> is now 20 GB, largest client will now backup directly to tape, there are
> now 2 threads on the migration).
>
> ***********************************************************
> This email transmission and any files that accompany it may
> contain sensitive information belonging to the sender. The
> information is intended only for the use of the individual
> or entity named. If you are not the intended recipient, you
> are hereby notified that any disclosure, copying,
> distribution, or the taking of any action in reliance on the
> contents of this information is strictly prohibited. If you
> have received this email transmission in error, please
> immediately notify the Security Administrator.
> Security.Administrator AT dowcorning DOT com
> **********************************************************
<Prev in Thread] Current Thread [Next in Thread>