ADSM-L

Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices

2013-05-08 11:46:35
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices
From: "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 8 May 2013 15:44:34 +0000
I find that shocking.
Changing domain structure shouldn't do that.
Did you open a performance PMR, or get any feedback from Tivoli?

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Rick Adamson
Sent: Wednesday, May 08, 2013 11:34 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices

Just my 2 cents :)

One of my TSM worlds consists of several TSM servers and roughly 900 clients 
(mix of BA, TDP, etc.).

When the time came for an upgrade the original system was configured where 
domains and storage boundries were designed by platform.
My management team asked the question "why not just have one, or multiple, 
generic domains and storage pols, would it not be easier to manage?".
So I set out to combine and streamline where possible.

One thing that I learned an wished I'd have given more consideration to when 
making these decisions was processing time.
Since the operation is tapeless mount-points were not an issue, but the time 
required to perform migrations, storage pool backups, etc. increased 
exponentially.

You may find it helpful to also consider these issues when making your design 
decisions...
~Rick



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Prather, Wanda
Sent: Wednesday, May 08, 2013 11:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices

Agreed.  No reason to create different domains due to platform, TSM doesn't 
care.

I always tell my new customers to stick with minimal domains until they have a 
reason to add more.  Start simple.  It's easier to get more complex later, not 
as easy to merge/simplify.  

The primary reasons to create more domains:

a) different default retention requirements or storage hierarchies that make 
sense in your organization
b) the ability to give a different group of administrators control of "their" 
systems to define nodes, change passwords, set schedules (always outsource the 
work if you can!)
c) different reporting requirements  (this isn't strictly necessary, but sure 
makes it easier to segregate reporting.)
d) domain for "Frozen" or "litigation hold" clients

W  



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Bill Smoldt
Sent: Tuesday, May 07, 2013 4:23 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices

Sergio,

Having developed some of the early training, way before V5, I can tell you that 
the rationale for platform domains was strictly organizational.  In those days, 
most IT shops were organized by platform and had retention control over their 
own systems.  

Free of the organizational restriction it makes sense to create and populate 
domains specific to common retention parameters so that you aren't stuck with a 
lot of include <mgmtclass> statements.
___________________________
Bill Smoldt
President
www.storserver.com
719-266-8777 x7103


On May 7, 2013, at 1:58 PM, Sergio O. Fuentes <sfuentes AT UMD DOT EDU> wrote:

> Hello all,
> 
> Back in the early TSM 5 days, or at least once when I went to training,  it 
> was advised that each individual platform had its own DOMAIN for retention 
> and destination control.  Now, since I'm evaluating a TSM v6 environment, I'm 
> rethinking whether that is necessary across the board.  Sure, it's advisable 
> to have platform domains for TDP or NDMP type nodes, because of the way those 
> platforms handle retention settings for backups.  However, have any of you 
> decided to 'squish' each of the standard OS B/A client domains into one 
> singular domain?  I'm imagining having just one domain for standard B/A 
> client nodes.    (In reality, I'll have many domains for standard B/A client 
> nodes, but that's for other reasons, i.e. different stgpool hierarchy).
> 
> Is there any reason not to do this?  Domain definitions have a default 
> management class that defines a copy group with retention, destination and 
> serialization parameters.  I can see serialization getting in the way, but 
> that has only happened ONCE in 8 years of TSM 5.  Other domain specific 
> options like frequency, and mode don't really impact us much.  For Windows, 
> the system state mgmt class is non standard, but since it's not the default, 
> I don't see why I can't just add it as a non-default Management Class.  I'm 
> already moving away from a directory management class, how about moving away 
> from the platform-specific domain?
> 
> Thoughts, ideas?  Gotchas, that I might be missing?
> 
> As always, thanks,
> 
> Sergio
>