ADSM-L

Re: ?Can LTO replace 3590E tape for busy TSM backup/restore service?

2003-01-30 18:31:14
Subject: Re: ?Can LTO replace 3590E tape for busy TSM backup/restore service?
From: Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 31 Jan 2003 09:25:37 +1000
Jim,

You have a good grasp of the issues and what looks to be an interesting 
environment.

Would it be possible to add complexity to get each drive type to do what its 
best at?
What I'm thinking of is a three level hierarchy

disk -> 3590 -> lto

Allow sufficient headroom in your 3590 pool for a day or two of new data, and 
migrate down in a scheduled fashion as you would a disk storage pool. Because 
you are semi colocated the migrate should be a reasonably efficient streaming 
operation.  You will also get efficient use of the lto media. 

If you have enough disk, I'd also consider a disk reclaim storage pool for any 
LTO primary pool reclaims. Alternatively, you could script a move data of 
primary LTO volumes back into your primary disk pool and let normal migration 
do the rest.

I've not tried any of this, but I hope the ideas are useful.

Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia

>>> Jim.Owen AT YALE DOT EDU 31/01/2003 5:36:33 >>>
???     Do you have experience w/ or plans for replacing 3590E with LTO tapes
        for a busy enterprise TSM backup service?  Is LTO performance OK ???

We expect to double business for one of our TSM services over next 4 years.

Last year, for space and cost savings, future enhancements, etc...
we bought new LTO (100GB/tape) libraries to use for Copy STGpools,
replacing existing 3590E (20GB/tape) Copy STGpools which made all of
those 3590E tapes available to expand our primary STGpools.)

Now, we are considering whether we can use LTO tapes for new primary tape
STGpools or should we continue to expand our existing 3590E tape STGpools?
We have performance concerns about using LTO tapes for primary STGpools!

Our current environment:
-----------------------
        TSM v4.2.3.2+   (upgrading to v5... soon, before 5/2003)
        AIX v4.3.3      (upgrading to v5... soon, before 5/2003)
        IBM 7025-6F1 w/ 2*600Mhz CPUs and 1GB memory

        IBM 3494 w/ 6 3590E drives for 1700 primary backup tapes
        IBM 3584 w/ 4 3580 LTO drives for 300 copy + 10 TSM DB backup tapes

        2700 active clients (>100 Servers, >2500 Win*,Mac,Linux,etc. PC's)
        backup 5-600GB/night (some 1-4GB files, mostly much smaller files!)

        TSM DB:  74-76% of 120GB
        TSM LOG:  12GB (w/ LOGM=R needs 1 full + 1-2 incr.DB bkups daily)

Our expectations for next 4 years:
---------------------------------
        clients: +25%/year, @+4 years = +2800 clients: +100 S, +2700 PC's
        backups: +25->50%/year, @+4 years = 2-4 * current backup load!
        how:  ??? replicate another or "super-size" current TSM service?

Our current LTO tape experience:
-------------------------------
        We use LTO tapes ONLY for an online Copy STGpool and TSM DB backups.
        LTO seems to be ~100% faster than 3590E tape for TSM Backup DB...
        LTO can be 30-50% slower than 3590E tape for TSM BAckup STGpool...
                w/ EMC SAN disks or 3590E tapes -> LTO vs 3590E Copy tapes.
        LTO can be 30-50% slower than 3590E tape for our online Copy STGpool
                reclaiming LTO Copy tape -> LTO Copy tape vs 3590E -> 3590E.

Do you see similar or better performance?
----------------------------------------

Our concerns about replacing 3590E w/ LTO tapes for primary STGpools:
--------------------------------------------------------------------
We are worried about start/stop and seeking performance using large capacity
LTO tapes for restoration or reclamation of aggregated small/medium-sized
files on "semi-collocated" tapes.  [We use collocation, but currently have
350/1700 "filling" 3590E tapes available for 2700 clients, so we often have
multiple clients' backups sharing the same 3590E tape.  This problem could
be much worse with 100GB LTO tapes as we might have only 70/320 "filling"
LTO tapes.]  Even w/ full-collocation, we believe restoration/reclamation
of a highly active client's aggregated backups of many small/medium-sized
files might involve substantial start/stop and seeking operations and would
probably perform poorly on LTO when compared to 3590E tapes.

Are our concerns warranted?
--------------------------
In IBM's 2003-01-28 announcement of new Ultrium 2 LTO technology,
the last paragraph under the heading "Product Positioning" states:

For mission-critical data protection, optimized for
enterprise multi-mode and host attachment, high-cycle
and start/stop intensive tape applications, consider the
proven IBM TotalStorage Enterprise Tape Drive 3590 or
the IBM TotalStorage Enterprise Automated Tape Library
3494.

Are TSM restores and reclamation of aggregated files start/stop intensive?

Has anyone done TSM performance comparisons of LTO vs 3590E for:
---------------------------------------------------------------
        - DR or FS restore from (semi-collocated) tapes?
        - primary (semi-collocated) tape->tape reclamation?

Thank you for any experienced advice you will share with us.
--
Jim.Owen AT Yale DOT Edu   (203.432.6693)


**********************************************************************
This e-mail, including any attachments sent with it, is confidential 
and for the sole use of the intended recipient(s). This confidentiality 
is not waived or lost if you receive it and you are not the intended 
recipient(s), or if it is transmitted/ received in error.  

Any unauthorised use, alteration, disclosure, distribution or review 
of this e-mail is prohibited.  It may be subject to a statutory duty of 
confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this 
e-mail in error, you are asked to immediately notify the sender by 
telephone or by return e-mail.  You should also delete this e-mail 
message and destroy any hard copies produced.
**********************************************************************

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