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
|
