Steve, I envy your memory!

Unfortunately, we are still under a permanent hold notice due to pending
litigations.  And, yes, I'd say that is the primary reason why our database
grew so large.  As large as it is, the size itself was never a big problem,
except that DB restores in Disaster Recovery Tests took about 5+ hours.  In
our last test, just after the split, it took only three minutes to restore
our new 12GB "DR" TSM DB.  Many folks with large TSM DBs seem to have
problems with expirations running  too long.... but we haven't done one for
over two years now, so wasn't an issue for us.  I suppose we may have had
some performance issues with the large DB, but it's difficult to quantify.

Anyway, the biggest problem we have with the permanent retention is with
tape consumption.  We now have about 6,000 LTO2 volumes... about half
onsite.  We have a STK L700 library with 618 slots, so we are constantly
moving media out to make room for new tapes and returns from the vault.
That's compounded because last October, our IT group moved to a new office
about eight miles from our data center.  We now have some of the PC techs
in the data center doing our daily moves, but sometimes we have to travel
to handle problems, emergency mount requests, etc.

Now that we've split to five TSMs (the old one, the new LM, one for Lotus
Notes, one for Windows, and one for DR and the remaining Unix and Oracle)
the daily tape moves have become more complicated... but we're getting a
handle on it.  The key was to create a server group and use it to broadcast
all the DRM commands to all servers.

Regards,
Robin Sharpe
Berlex Labs



             Steven Harris
             <steve@STEVENHARR
             IS.INFO>                                                   To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .EDU>                     Re: multiple instance
                                       recommendations

             05/28/2006 08:56
             AM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






Robin,

If I recall correctly a while back you were stuck with having to keep
everything forever.  Is that still the case and is that why your
database got to 530GB?

If it is still the case I'd be interested in how you handle this,
problems encountered and so on.

Regards


Steven Harris

AIX and TSM Administrator,
Brisbane Australia



On 27/05/2006, at 12:43 PM, Robin Sharpe wrote:

> I just did this about a month ago... first the "why":  My single TSM
> database had grown to its architectural limit: 530GB.  I had no choice
> other than splitting TSM into multiple instances (well, I could have
> "frozen" the big TSM and started over... and we actually ended up
> doing
> that also... but multiple instances seemed like a good approach for a
> number of reasons).  We didn't have the budget for new servers, and
> our TSM
> server is pretty hefty - an HP rp7410 w/ 8 CPUs and 12GB RAM.  All
> DB and
> log volumes are on an HP XP512 (Hitachi Lightning).
>
> Now the "how":  Use the same TSM install directory as per the install
> guide.  Use the same host name/IP address for each instance, but
> assign a
> unique set of ports (TCPPort, HTTPPort, SHMPort) for each
> instance.  Then
> assign the appropriate port in the dsm.sys/dsm.opt in each client.
> And of
> course register the clients in the corresponding TSM instance.
>
> As far as tape access, using one server means you only need to have
> the
> drives physically connected to that server (unless you're doing LAN
> free
> backups)... and this may enable sharing your SCSI connected drives,
> although I haven't tried that... we have two SCSI connected DLT
> drives, but
> we almost never use them anymore.
>
> One other recommendation, which I did... do not run all of your TSM
> instances as root (you are on Unix , right?).  Doing so, if you do
> a "ps
> -ef|grep dsmserv" command, you can't tell which process belongs to
> which
> server without doing more research .. looking up the PIDs.
> Instead, create
> a unique user for each TSM and run it under that user.  Make sure you
> "chown" all of your config files and DB/log/stgpool volumes to that
> user.
> This will also prevent the wrong TSM from accessing another TSM's
> storage... this can be easy to do if you use raw logical volumes as
> we do.
> And now, your ps output will show the user for each dsmserv.
>
> It's actually quite easy to set up an additional instance once you
> get all
> the steps down...  I'll share my approach in more detail if anyone is
> interested...
>
> Regards,
> Robin Sharpe
> Berlex Labs
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 05/22/2006
> 05:28:32 PM:
>
>
>> Other than the obvious hardware cost savings, I don't really see the
>> advantage of multiple instances on the same hardware.  (I haven't
>> decided yet if we would use one beefy server or two medium
>> servers.)  If
>> you load up multiple instances on the same server, do you give them
>> different IP interfaces to make distinguishing between them in client
>> configs and administration tools easier?  Tape access-wise, is
>> there a
>> hardware advantage putting multiple instances on the same system?
>>
>> Any recommendations on any of this?  Your help is appreciated.
>>
>> Dave
>>
>
>