ADSM-L

Re: [ADSM-L] NBU user considering switch to TSM

2008-10-01 14:58:23
Subject: Re: [ADSM-L] NBU user considering switch to TSM
From: Paul Zarnowski <psz1 AT CORNELL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 1 Oct 2008 14:54:51 -0400
See my responses below..

At 02:04 PM 10/1/2008, Howard Coles wrote:
See in line answers below

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of steve sorenson
> Sent: Tuesday, September 30, 2008 11:44 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] NBU user considering switch to TSM
>
> Thanks so much for all the responses.  I'd like to reply to just a few
> responses for clarification.

You're welcome.

> Regarding simultaneous copies, Howard Coles said:
> I'm not talking about migration and backups happening at the same time,
> or even multiple migrations happening at the same time.
>
> First, let me verify what I was told TSM _could_ do.  I was told that
during
> the initial backup (if you went straight to tape, such as with a large
> dataset), TSM could write to two tape drives simultaneously, making two
> copies in the time it takes to make one.  Is that part true?

Yes.

No, I do not think this is possible.  Howard, the Copy Group DESTination
can only specify one storage pool.  Thus, it is not possible to send
incoming data simultaneously to two different tape drives.  This is by
design, and is not an oversight.  The normal way of doing things is to
receive the data on disk first, and then you can simultaneously migrate the
data from disk to tape, and copy it to a copy storage pool.  Perhaps Howard
missed your premise that you want to go straight to tape.


> I was told that, while it could do that during backups, it couldn't do
> it during migration/copies.  I'm talking about one process reading from
> the disk pool, simultaneously putting a copy of each file in the dataset
> into the primary tape pool and in the copy pool.

False.  It can.

> When used in NBU and disk staging, it means you can back up once to disk,
> then copy once to tape, but when that copy is done, you have an onsite copy
> and an offsite copy, but you only had to do one operation.  It would seem
> that doing it twice would take longer.

Not sure about NBU, but with TSM you can either send a client straight
to tape and make a simultaneous copy to a copy pool, OR if they go to
disk you can then backup to a copy pool, while migrating the data to a
primary (onsite) tape pool.  You can also simultaneously copy the data
to an active data pool, while sending it to the primary disk pool, etc.
etc. (or, at least I think you can I have not tried this last part).
The combinations here are numerous.

> Regarding the TSM server having to do all migrations/copies, Howard
> Coles
> said:
> >Why would you want the client to be worried about that?
> >The server is the box that you want
> >handling the data once its handed off so that the client can go about
> >its main purpose.
>
> NBU has the concept of media servers, which are subordinate to the master
> server.  The master server _controls_ and creates database entries for all
> operations, but the I/O of these operations can be done on these
subordinate
> servers, allowing you to scale a single NBU environment to beyond the
> capabilities of a single NBU instance beyond that of a physical server.
>
> TSM seems to be the opposite, as you sometimes have multiple instances of
> TSM in a single physical server.  Why is that?

I am somewhat aware of this feature of NBU.  TSM does not have this, in the
sense that NBU does.  The reason that you sometimes see multiple instances
of TSM on a single physical server is due to limitations in managing a
database that is too large.  The current version of TSM maxes out at just
over 500GB, but you'd be advised against getting anywhere near that
large.  I think 200-300GB is probably as large as I would feel comfortable
with.  If you need to do a restore, or any kind of auditing, smaller
databases will be much easier to deal with.  Having multiple databases used
to be very rare, used only by the largest sites.  I have a feeling that
they are more prominent now than they used to be.  When the next version of
TSM migrates to DB2, I believe you will be able to have larger databases,
so perhaps the desire to have multiple databases on one physical box will
diminish.  Time will tell.  The current version of TSM is cumbersome to
deal with when you have multiple databases and have some reason to move
nodes from one to another.  This is an area where some forethought can
avoid problems later.


Well, TSM has master and client servers when it comes to sharing a
database, but it never puts that load on clients.  And, I still wonder
why you would want to.

IMHO - NBU obviously has the data handling focused on the wrong box. You
do not have to have multiple instances of TSM, and especially not on the
same box (if you are talking Server side here).  On the client you can
do some very interesting things by using multiple node names for a
client.  And, having a second instance of a TSM server is always handy,
for storing retired nodes, or nodes with legal holds on data in a
certain range, for example.  (which is how we're going to be setup in
the near future).

The issue here is where do you want your data handling, and how much
Network/SAN traffic do you really want?  TSM's principle is, "get the
data from the client, tell the client you have it, and then let the
client go on about its business".  The client doesn't know where its
data is, and doesn't need to know, all it needs to know is that TSM has
it.  As a matter of fact as a TSM admin I have to do some interesting
queries to find out what tapes a particular node's data is on.
There are reasons, and times when you'll need a second instance of TSM,
but in that large of an environment you'll need TSM not NBU anyway.
Just my Not so humble opinion. :-D.

> Howard Coles said:
> >You use the TSM GUI and/or command line to
> >do all the restores whether it be a backup set, or a backup from the
> >TSM server.
>
> But the contents of the backup set aren't in the TSM database, right?
> Isn't that the point of the backup set, to make an archive of a bunch of
> files that aren't tracked in the database, and that can be read outside of
> TSM?  So if the contents of the backup set aren't in the database, how
could
> you do restores the same way as you do with regular backups?

Well, partially.  The purpose of a backup set is to make a client's
backups portable.  You are correct in that the contents of the Backup
Set are not in the database (because they were intended to be removed
from TSM and handed off to a client).  However, you will need the TSM
client, preferably the version that did the backup or newer, to import
the backup set at the client, and hardware to read the tape/media used
to create the backup set.

This is not the only reason to use backup sets.  You do not need hardware
on the client to read the media, unless the point of the backupset is to
have portable media.  You can reference the backupset directly from the
server.  Some folks use backupsets to take snapshots of their current
backups, without having to re-send the data from the client again.

> Thanks again for my overlooking my ignorance.  I'm just trying to
understand
> how I would architect a new system based on TSM.  How do you recommend
> someone mostly new to TSM moving forward with such a thing?

I would echo Howard's suggestion of taking a class.  Another option would
be to go to a SHARE conference or a TSM User Group in your area, where you
will likely find helpful folks who are already using TSM.  The RedBooks can
also be helpful.


Take a class.  There is so much to TSM and so many possibilities that
you'd get weary doing it all over this medium.  There are some great
Redbooks, even though some are a little dated, that will help you with
the principles and practices of setting up TSM and architecting a good
environment.  I still refer to them, and often.

Finding someone that's somewhat local to you who can help you implement
TSM is very helpful as well.  Just make sure they really know TSM,
unlike a consultant we had help us once.  He didn't know you had to run
reclamation on offsite (copy) storage pools.


--
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

<Prev in Thread] Current Thread [Next in Thread>