I agree with Paul.
There are 2 technical reasons to split clients into domains:
1) Dividing authority: you can create TSM administrators with "Policy" or
domain-level authority. They don't have the ability to modify TSM storage
pools or devices, but they can create nodes, passwords, and schedules for
clients in ONLY their own domains.
2) Management classes: Clients in a domain all have the same default
management class.
I have some customers that have only 1 domain, because all the clients use
the same default management class; they have few exceptions to the
default, and those are implemented via INCLUDES in teh dsm.opt file.
That's fine from TSM's point of view. However, once you have a large
group of clients that all need different management class rules, it
frequently becomes easier to create a new domain than to handle everything
by exception.
In an environment like Paul's, where you have many distinct groups of
customers, it is usually going to be easier for YOU to manage if you put
those groups of customers in a domain of their own, because as Paul says,
eventually they are likely to want management classes or schedules that
are customized for them.
If you think you may eventually need to split your TSM server, it is also
easier to split out a group of clients that all have the same
requirements.
Changing the domain for a client is extremely easy: you just do UPDATE
NODE xxxxx DOMAIN=yyyyyy.
The 2 tricky things, as Paul noted:
-Schedules belong to a particular domain, so when you change a client's
domain, it is no longer associated with a schedule
-When you change a client from one domain to another, if the target domain
doesn't have management classes with the same NAMES that the client was
using in the source domain, files bound to the missing management class
will go back to the default management class in the target domain, which
may not be what you wanted.
-If you move a client from one domain to another, it's data doesn't move,
even if the mananagement classes in the new domain point to a different
destination storage pool. Already-backed up data stays where it is; only
new incoming data gets directed to the new storage pools.
W
> I'm sure there are many ways to organize and use TSM Policy Domains,
> and I look forward to seeing the responses to your inquiry. Here at
> Cornell, we make heavy use of Policy Domains as you are thinking of
> doing - along organizational lines. Each department here who makes
> any significant use of TSM is given their own Policy Domain. This
> allows us to change the default management class, and provide any
> number of management classes or schedules that are customized to suit
> their requirements.
>
> One thing that we did that I think worked out well is that we tried
> to keep the default STANDARD Policy Domain as simple as possible. If
> a single user from a new department came along, we just put them into
> the STANDARD domain. If, later, they requested specialized
> requirements, at that time we would move them into their own policy
> domain and change the management classes in their private
> domain. Similarly, if that department later added additional systems
> to be managed by TSM, we would at that time move them into their own
> private domain. To create their private domain, we would simply use
> the COPY DOMAIN and COPY SCHEDULE commands. This all works, so long
> as you ensure that the STANDARD domain is always a proper subset of
> all your other domains. This makes it safe to move a node out of
> STANDARD and into a new domain. Otherwise, you risk orphaning the
> management class that an existing file is associated with (i.e., the
> new domain doesn't have the same management class that the old domain
> had). One other caution is that before you move the node to a new
> domain, check which schedule it is associated with, because the act
> of moving a node to a new domain will break all schedule associations.
>
> One other thing I've noticed over the years, related to management
> class definitions. We started out defining management classes
> according to their attributes. E.g., name "1YEAR" was used for an
> archive management class that had a 1 year retention. This works for
> the most part, but now and then we get a large archive user who
> starts out using a management class, only to later want to change the
> retention. It's not easy to change the retention of files that are
> already archived. But - if all the files whose retention you want to
> change are all using the same management class, and none other are,
> then you can simply change the definition of the management
> class. For example, if you want to have a common management class
> for all logfiles, choose a name called "LOGFILES". Then you can
> change the name of that management class to change the backup/archive
> policy for all logfiles, without worrying about what other uses it
> might have. It's much less likely that you will want to change the
> definition of a management class named "1YEAR" to mean that files
> have a 2 year retention period!
>
> I look forward to seeing what others' experiences are..
>
> ..Paul
>
>
> At 04:32 PM 8/14/2007, Keith Arbogast wrote:
>>There may be more suitable or more helpful organizing concepts. We
>>would be glad to know them.
>>
>>How do other TSM admins organize their domains and policy sets
>>conceptually? What does a TSM policy domain correspond to in real
>>life? Is it a customer department, a client OS, the production/test
>>status of the client, a set of retention parameters? How can the
>>hierarchy of policy domain, policy set, management class be
>>implemented so that it is the most helpful in managing a large set of
>>clients with diverse owners, retention demands and backup schedules?
>
>
> --
> Paul Zarnowski Ph: 607-255-4757
> Manager, Storage Services Fx: 607-255-8521
> 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
>
|
