I found that my view of TSM over the past 4 years is a moving target, as new
situations unfolded. Overall I'll give it an 8.
I'm currently going through a massive storage pool rework due to several
factors. Over time the number of frames on our 3494 has gone from 1 to 8 to 6
(because we've got HA with dual robots so 2 frames became garages). The 3494
has gone from exclusive ADSM/TSM on AIX, to being shared by MVS and AS/400. The
number and type of drives has gone from 2 3490e up to 10 3490e to 4 3590b to 4
3590e to 4 3590ex and soon 6 3590ex. The number of clients has gone from 2 to
150+, retention policies have changed. The amount of disk storage available has
changed from 4G to 144G and soon adding 288G more. There's been moving ADSM/TSM
around from server to server. There's been corporate mergers which require cross
site (midwest/east coast) recovery capabilities. There's been managements'
realization about the capabilities of various TSM features, most notably
co-location. Now a change in DRP strategy is being considered.
What am I getting at? While everyone might suggest that a good storage pool
design is required (and I agree), the real life facts remain that the world is
constantly changing and any given storage pool design must be factored by
available hardware, budgets, and corporate goals. None of these is stagnant.
The biggest shortcoming of TSM is the lack of selective granularity allowed with
regard to moving data around in storage pools or getting rid of it from old
copypools. It is VERY difficult to move all data for a given node to somewhere
else, and this includes the data in copypools.
This all becomes simple with the addition of a NODENAME= parameter on the MOVE
DATA command, and the addition of a STGPOOL= parameter on the DELETE FILESPACE
command, and to have an option to FORCE storage pool reclamations follow current
policy rules. For example, suppose tape1 in stgpoola is eligible for
reclamation, and the tape contains data for multiple clients. If the force
option is specified, the reclamation process would relocate data for each node
to the appropriate storage pool. The result being that TSM would automatically
align data. With the force option off, reclamation works as it does now.
Thoughts?
Al Barth
Scudder Kemper Investments.
|--------+----------------------->
| | Vijay |
| | Havaralu |
| | <vhavaralu@CH|
| | UBB.COM> |
| | Sent by: |
| | "ADSM: Dist |
| | Stor Manager"|
| | <ADSM-L AT VM DOT MA|
| | RIST.EDU> |
| | |
| | |
| | 09/27/00 |
| | 05:27 PM |
| | Please |
| | respond to |
| | "ADSM: Dist |
| | Stor Manager"|
| | |
|--------+----------------------->
>----------------------------------------------------------------------------|
| |
| To: ADSM-L AT VM.MARIST DOT EDU
|
| cc: |
| Subject: Re: Views on ADSM rating question |
>----------------------------------------------------------------------------|
My rating for ADSM is 6.
Reasons, good for central backups, with wide variety of support for
devices and networks.
1. Not possible to restart a backup; especially for long-time consuming
selctive backups,
restarts from start again. Really trouble some.
2. In short all long processes should be restartable, like export,
imports, db-backup.
We lose hours when these processes fail, and system becomes
vulnerable, especially with DR.
3. Can not have backup copy without a database. Even archive may not be
readable, if there is no
entry of it for the node. A raw backup format like tar should be
provided, so that user
can backup at will, and store it locally or centrally for long time,
without any retention periods.
I think this should be necessary at minimal level, for backup and
restores to be flexible, and
easier to handle, without database problems.
4. Performance tuning should be more clear. It should be clear with each
parameter and what effects
are expected. So when some body tunes, it is easy to keep track of
the results.
5. DB restore should be made faster (especially with large db consuming 6
hours), will make users
wait long, before they can restore.
6. Network statistics and trace to be more clear and informative for
tuning purposes.
7. Unix files are not listable without a readwrite access, even to admin.
An option can be built
in system to set it whether they can be at least listable, to monitor
the user backups.
8. It is hard to keep track of tape consumption by node; and hard to
figure out the unnecessary backups.
9. Slows tape speeds, and should be easy to implement multiple threads
into normal backup/restore/db-
backup/restore.
There are several other small problems, but it is good for short time
backups, but trouble-some with
large size backups (even it can handle with some efforts). However
currently, it is hard to find any other alternative exists and reliable in
the market.
> How good do you rate TSM on a scale of 1 to 10. (10 being best).
>
> Would you definately buy it again, or would you shop around.
>
> My gut feeling is that everybody has some complaints with their backup
> solution.
>
>
> Lynn Sattler
> Dana Corp
> Toledo Oh
> lynn.sattler AT dana DOT com
|
