ADSM-L

Re: Why not use many cheap DISK...

2000-08-02 09:57:34
Subject: Re: Why not use many cheap DISK...
From: Bart Colbert <Bart.Colbert AT RAYONIER DOT COM>
Date: Wed, 2 Aug 2000 09:57:34 -0400
Jochem van Hal wrote:
----------------------------------------------------------------------------
Hi,
Hi,

Recently, we're trying to decide about the various ways in which TSM can be
set up. We need about 2Tb of primary pool space. For primary pool only , we
may either:

1) Get a big library, and a lot of tapes, amounts to >$50.000. (With the
lib
we can also maintain the copy pool)

2) Get a bunch of IDE-disk cabinets, and a lot of 70 Gb IDE disks, amounts
to $25.000 or so (of course we will also need a small library for the copy
pool). These cabinets have a scsi interface.

It seems IDE disks are not only the cheaper, but also the much faster
solution for daily retrieve operations. In this case we would opt for a
RAID-5 IDE set for primary stg (but also a fast(er) SCSI system for the DB
and LOG). With this amount of disks some are bound to crash every now and
then, RAID-5 helps. All in all, the TSM server only 'sees' scsi.

One cabinet would show up like one disk, in reality 70Gb disk times 7 disks
= 0.5 Tb/cabinet, which is a rather big 'disk' size.

Question 1) However, on the forum no-one seems to use a PRimary IDE (PRIDE)
disk pool? Why? I'm i missing something or what?

Question 2) If PRIDE seems like a good solution, would the better way to
use
DISK devices (any TSM limits?, caused by size or sheer number of DISK
volumes on the PRIDE disk) or FILE devices (but fragmenting files all over
the disks, and need of reclaim)

Question 3) Any (other) TSM limits endangering this plan (we are talking
about 2Tb or more on disk...)

Of course OS limits have been accounted for. It seems AIX and NT are OK.

Thank you,


Allshare Personnel BV
Jochem van Hal
TSM admin
jvhal AT allshare DOT nl
------------------------------------------------------------------------------
-
-
Here is my personal opinion of how to think about backup data.
Here is my personal opinion of how to think about backup data.

1) If only backing up data in the event of a disaster, IE: lots of DB
files, and that data is hardly ever required to be restored.
   Keeping this data in a tape library is the best and most cost effective
solution, full tapes are taken out of the library marked unavailable and
the storage pool in the library can be X times the size of the amount of
tapes in.
   Of course no space reclaim is realistic in this case, and tapes would
have to be manually place a tape back in the library if needed. (We use
this method with SAP/Oracle backups and a 7337) consisting of about 40
DLT(14 in library) tapes holding approx 180G each and all changes based on
expiration, no
reclaim. one 180G offsite copy daily runs in the same library.
   (Although it sounds that this library is a little small for you
solution, this library runs about 22 hours a day with 180G to the storage
pool and the offsite copy of said data)

2) If the storage pool which will require some restoration on a limited
basis. It may still be cost effective to use a tape library. Some
considerations are, if many of small files changing constantly tape
transfers are not as good on performance for this, if large amounts of data
that will require a lot of recliam/move of data.. time may become a issue.
The initial cost of a library verse a five year cost on disk failure is not
going to make disk look cheaper and if the library can hold and server the
data in a manner required it will be the most cost effective solution after
the five year window.

3) If the storage pool will require a lot of clients with small files and
is very large and quick online access for restore, then disk is the answer.
Cost is high and failure is high.

I am sure others have methods of making these decisions, and may be better
focused for your need.

Good day,
Bart
<Prev in Thread] Current Thread [Next in Thread>