ADSM-L

Re: (Matt) ADSM dasd pool migration

1998-09-10 17:27:21
Subject: Re: (Matt) ADSM dasd pool migration
From: Dan Giles <Dan_Giles AT MANULIFE DOT COM>
Date: Thu, 10 Sep 1998 17:27:21 -0400
Matt, your assumptions are correct.

Also, lowering the himig value will give you a little more time for
migration to work before the dasd fills.

Dan Giles
Application Specialist
Manulife Financial, Corporate
Phone: 416-926-3549 Fax: 416-926-5234





From: Matt Cleland <adsmrus AT STLNET DOT COM> on 09/09/98 03:57 PM GMT

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: ADSM)
Subject:  Re: ADSM dasd pool migration




My understanding of the migration process is that ADSM will begin migrating
data from a "full" storage pool to the next level in the hierarchy one
client at a time.  That is, for each migration process, ADSM will move the
data (ALL the data) for a particular client to the next level.  The reason
you are seeing a process continue for a long time *may* be related to the
amount of data from a particular client that is being moved off.

I'm not sure on the client selection criteria, but I think I was told that
ADSM will pick the client with the most data in the pool first, and then
down the line.  Is it possible that you have a client that has almost all
the disk pool storage in use, and then just a few other, smaller clients?
That would account for one migration process continuing to run longer than
the rest.

These are just speculations, but I'm interested to hear if they fit your
environment...

--------------------------------------------------------------
Matt Cleland                            mcleland AT msiinet DOT com
Matt Cleland                            mcleland AT msiinet DOT com
IBM Certified Specialist - ADSM
Midland Systems, Inc.                   (618) 345-0864
St. Louis, MO                           (618) 346-1779 FAX


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Jeff Connor
> 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>
  • Re: (Matt) ADSM dasd pool migration, Dan Giles <=