ADSM-L

Re: Co-location

2002-11-06 17:52:30
Subject: Re: Co-location
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 7 Nov 2002 00:22:23 +0200
---> We turned on co-location on the onsite tape pool a couple of weeks ago,
because we just started using the SQL TDP, and the doc recommended
colocation.  We turned it back off this morning, because we were running
out of tapes and had a lot of them that were only 5% full.

There is another very simple solution - set a reasonable MaxScratch on the
tape pool (total # of your tapes - copypool tapes - DB backup volumes).
This would result "partial" collocation - data for each node will tend to
stay on minimum number of volumes but you will have more than one node's
data on single volume.

Zlatko Krastev
IT Consultant






Matt Simpson <msimpson AT UKY DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
22.10.2002 16:46
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Co-location


At 3:53 PM -0400 10/21/02, Thach, Kevin said:
>The person that installed our environment basically set up 6 Policy
Domains:
>Colodom, Exchange, Lanfree, MSSQL, Nocodom, and Oracle.
>
>99% of the clients are in the Nocodom (non-collocated) domain, which has
one
>policy set, and one management class which has one backup copy group with
>retention policies set to NOLIMIT, 3, 60, 60.

This is away from the topic of Kevin's question, but his background
info led to a question that we're looking at right now.

We currently have one big disk pool for all our backups, which
migrates to one tape pool, which we copy to another tape pool for
offsite.

We turned on co-location on the onsite tape pool a couple of weeks
ago, because we just started using the SQL TDP, and the doc
recommended colocation.  We turned it back off this morning, because
we were running out of tapes and had a lot of them that were only 5%
full.

We would like to do what Kevin says he's doing: specify colocation
for a small number of our clients and leave it off for a bunch of
them.  But, if I understand correctly, colocation isn't specified
directly in the management  class.  It's specified on the tape
storage pool definition. So specifying colocation for some  clients
but not all would require multiple tape storage pools, which wouldn't
really be a problem.  But it looks like that would also require
multiple disk storage pools, because, as far as I can tell, the only
way to get a client into a different tape pool is to have it in a
different disk pool.

We'd really like to avoid carving up our disk space into more smaller
pools.  But, as far as I can tell, that's the only way to use
colocation selectively.  Am I missing something, or is that the way
it works?
--


Matt Simpson --  OS/390 Support
219 McVey Hall  -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe --   An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders.  And this year's run twice as
fast
as last year's.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Co-location, Zlatko Krastev/ACIT <=