ADSM-L

Re: Management Classes

2015-10-04 17:31:35
Subject: Re: Management Classes
From: Rick Smith [SMTP:richard.smith.hs45 AT STATEFARM DOT COM]
To: ADSM-L AT VM.MARIST DOT EDU
Rick,

I would have to disagree with the local expert also.  As already mentioned
in
some of the other responses, you can tell what files belong to what
management
classes.  You are correct in your assumption that multiple policy domains
would
require multiple clients installed on a single machine, as a node can only
belong to one policy domain.

I think that using one Policy Domain and policy set only would work.  You'd
just
have to have an all inclusive include statement, on all clients that should
not
use the default management class, that points all the client files to the
proper
management class.  I think that in some cases, even though it is not
necessary,
it is easier to create separate policy domains for like clients (at a high
level
like Servers and workstations).  Then use different Management classes to
distinguish differences within those domains (such as file/print servers vs.
e-mail servers).

Rick Smith
ADSM LTSB Team
State Farm Insurance
309-735-3086




From: O1=INET00/C=US/A=IBMX400/P=STATEFARM/DD.RFC-822=ADSM-L\@VM.MARIST.EDU
on
04/05/2000 08:50:37 AM
To:   ADSM-L
cc:
Subject:  Re: Management Classes

Type "dsmc query backup <filespace>", and you'll see what management
class
each file is bound to.

I have to strongly disagree with your local expert.

I go the OPPOSITE route, i.e, have one policy domain for everything, and
use
the include-exclude list to set management classes as needed on each
node or filespace or directory.  I do this for simplicity - I have seen
ADSM setups with a bewildering array of policy domains and policy sets,
for no good reason.

If users will do archiving, then you'll need some different management
classes
anyway, to give them options like 90-day archive, 180-day, 3-year, etc.
(otherwise the user has to ask that a new MC be set up every time they
want
to archive something with a different retention length.)

Since we have to have different management classes anyway, why not use
them for
everything, and not use policy domains at all?  (I mean, just have one
policy domain and one policy set.)  I think the domain-set-MC-copygroup
structure is overly complex.  Maybe it's useful in some rare situations,
but most installations don't need all that.

Debate welcome....

> Subject: Management Classes
>   Date: Tue, 4 Apr 2000 15:55:20 -5
>   From: "Richard L. Rhodes" <rhodesr AT FIRSTENERGYCORP DOT COM>.
>
>
>
> WHile talking with our local IBM *SM expert, I told him (if we
> purchase *SM) we would want to use multiple management classes (in
> one domain) for the file systems from a host.  Each filesystem has
> different policy needs.  He STRONGLY suggested that we NOT do this.
> He said the problem is that, on the *SM server,  there is no way to
> determine what management class a file belongs to, which will cause
> great confusion.  He suggested that I use separate domains (with only
> one management class - default) for each filesystem that needs
> different policies.  And, to do this, will require separate *SM
> clients on the computer per domain.
>
> Is this correct?  Thoughts?  Suggestions?
>
> THanks
>
> Rick
--
Mr. Lindsay Morris
Mr. Lindsay Morris
Gresham Enterprise Storage
lmorris AT openmic DOT com
606-253-8000
<Prev in Thread] Current Thread [Next in Thread>