ADSM-L

[ADSM-L] Fw: How to Incorporate a CDL into TSM environment?

2007-06-12 11:55:44
Subject: [ADSM-L] Fw: How to Incorporate a CDL into TSM environment?
From: Nicholas Cassimatis <nickpc AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 12 Jun 2007 11:54:36 -0400
I'm not looking at the spinning through the volume to find the file, I'm
focused on the fact that a volume can only be accessed by one client at a
time.  You have to read the data to be restored, which takes time.  If you
have one client reading the volume, any other access to that volume has to
queue up.  With a slow client (or a fast one pulling a large file), you can
develop some access contention, which is a bottleneck that collocation
resolves.  That's why I still see collocation playing with VTL's.

It all comes back to "Why do you want a VTL?" which is another way of
asking, "What problem are you trying to solve/avoid?"  I'm sure there are
people who are getting VTL's because they have to spend their budget or
they lose it - and the rest of us are jealous of them for that!  But, as
with most other technologies, implementing a VTL just moves the
bottleneck/weakest link to another spot, which may not be the best solution
for a given environment.

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 06/12/2007 11:41 AM
-----

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 06/12/2007
11:13:30 AM:

> As I see it, there are two areas where you get performance hits when
> restoring from non-collocated volumes:
> 1) Tapes Mounts:  In my experience my VTL makes this problem
> insignificant.
>
> 2) Spinning Sequential Media:  Yes, VTL volumes are sequential and if
> you define your tapes as 50GB native and then with compression get 100GB
> written to the tape, you may have to spin through 99.9GB of data to
> retrieve a 0.1Gb file.  However if you define 10GB volumes you only have
> to spin through 1/5 of the data to reach your 0.1GB file.  Also with
> smaller volumes you are more likely to get "natural collocation" because
> a client that writes directly to tape is more likely to fill up a tape.
> Obviously if you define smaller and smaller volumes at some point you
> will have a "tape mount bottle neck".
>
> Just one way to manage the trade offs.
>
> H. Milton Johnson