I agree that the "multiple clients" statement is misleading.
And in your situation, the need to give control and responsibility to
one admin for a subset of nodes makes using domains ideal.
But for most cases (even within your domains, maybe) a domain mostly
means "retention policies".
In other words, a node will, by default, use the versions/retention
numbers in
the backup copygroup in
the default management class in
the active policyset in
the node's domain.
Now, if you want DIFFERENT policies than that default, you have to make
a different mgmtclass, right? So where do you put it?
You can either:
put the new mgmtclass in a DIFFERENT domain, and "update node ...
domain=new", or
put the new mgmtclass in the SAME domain, and add "include * mgmtclass"
to your inclexcl file.
If you use a different domain, you have two problems:
1. You can't use open registration, which dumps all new nodes into
domain STANDARD.
2. You can't have different policies for a filesystem - unless you use
the inclexcl file.
So if you have to use the inclexcl file anyway, why not use it for
everything, just to keep life simple?
On a slightly different thread, how should we separate out nodes into
domains? It's sort of obvious to say "NT nodes here, UNIX nodes there"
but if "domain" mostly means "retention policies", then it doesn't
make a lot of sense to group nodes by OS. AIX node A and NT node B
might well have the same retention requirements. Better to group them
by business function.
That's my thinking anyway. Comments welcome.
Ison wrote:
>
> SpamCop - Report spam:
> http://members.spamcop.net/sc?action=report&id=1043881
>
> Rick,
>
> While I agree with the sentiments of Rick Smith, his statement:
>
> multiple policy domains would require multiple clients installed on a single
> machine, as a node can only belong to one policy domain.
>
> is somewhat misleading in my opinion. While it is true a client can belong
> to only one domain, you could install a single set of software and run
> multiple schedulers pointing to different options files. The different
> options files could contain unique node name parameters, thus having a
> single physical node belonging to multiple domains. This would raise the
> issues of system performance with possible multiple *SM scheduled tasks
> running concurrently.
>
> On the issue of multiple domains, I have 14 domains on an OS/390
> server with 160+ clients. My situation may be somewhat unique. We function
> as a service agency for all of our states' governmental agencies. We chose
> to allow each agency to have a *SM administrator responsible for their
> respective server backups. Since we have such a diverse community with
> varying needs with respect to backup functions (retention periods,
> archiving, databases, etc.), it is easier for us to separate the *SM
> administrative functions above the domain level from the user community of
> local admins. Each local admin then has the ability to do actions for their
> domain only, without affecting other agency strategies. This relieves me
> from having to do daily tasks regarding verifying backups, maintaining
> options files, upgrading clients, etc. and places these duties back where
> they belong and where the best control should be - with the users. I still
> have enough to do with double checking some functions such as backup
> performance, pool levels, and other resource balancing; not to mention the
> resolution of user problems and trying to stay on top of everything else
> with *SM.
>
> Gary L. Ison
> Governor's Office for Technology
> 101 Cold Harbor Drive
> Frankfort, Ky. 40601
> Phone: (502) 564-8724
> Fax: (502) 564-6856
> E-mail: Gary.Ison AT mail.state.ky DOT us <mailto:Gary.Ison AT mail.state.ky
> DOT us>
>
> -----Original Message-----
> From: Rick Smith [SMTP:richard.smith.hs45 AT STATEFARM DOT COM]
> Sent: Wednesday, April 05, 2000 10:46 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Management Classes
>
> 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
> Gresham Enterprise Storage
> lmorris AT openmic DOT com
> 606-253-8000
--
Mr. Lindsay Morris
Mr. Lindsay Morris
Gresham Enterprise Storage
lmorris AT openmic DOT com
606-253-8000
|
